This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Messages - Runer112
Pages: 1 ... 20 21 [22] 23 24 ... 153
316
« on: May 18, 2014, 11:25:03 am »
Yes but Zstart does, I was talking about not breaking Zstart's compatibility.
Ah okay, in which case, see DrDnar's post. 
317
« on: May 18, 2014, 12:15:29 am »
Looks great! The only thing I would change is the sprite, which would be to make the legs shorter and add more detail to the head.
You can't really make the legs much shorter, they're already only 2 (2.5?) pixels long. And a single pixel for the head is about the right size relative to the size of the rest of the sprite, so there isn't much room to add detail there. For the tiny size in which the sprite has to fit, I think Builderboy's original version might be as good as one can get.
318
« on: May 18, 2014, 12:07:33 am »
Well, ZStart's extra RAM storage can't be moved to another RAM page as there's only one extra page available on post 2007 84+'s. However, modifying Omnicalc to change the pages it uses is feasible, it's just a matter of using some find/replace and reassembling the app. More investigation needs to be done on that matter.
Virtual calc doesn't even work on the newer calculators with only 48KB of RAM.
319
« on: May 17, 2014, 12:50:03 pm »
I don't know if you're aware of this but on both the small font editor and normal versions, opening the editor, switching to Omnicalc's vcalc and going back crashes instantly.
I'd suspect that this could be due to zStart not knowing about the virtual calculator and only having one copy of its off-page data, thus causing a state conflict when switching between the two virtual calculators. To fix this, explicit support for the virtual calculator would have to be added, which might be infeasible. Or, it could be due to virtual calculator and zStart vying for the same extra RAM storage space. This could potentially be fixed by zStart's extra storage being relocated, but I'm not sure there are any other better spaces for it.
320
« on: May 16, 2014, 08:17:06 pm »
Your delay figures don't count the amount of cycles spent in the out/in instructions, do they? I believe that could account for the discrepancy you're seeing. It may not add exactly 11 cycles of delay though, as a physical port write might not happen after the same amount of time/cycles relative to the start of the instruction as a physical port read. All my tests were made using OUT (1),A and IN A,(1), without including any cycles spended by the instructions themselves.
Mainly because i think it's easier for the programmer to just know how much delay he has to put between the two lines.
From what i've tested, the delays are about the same when using the C register (delay-1 or so...).
I understand that you don't count the cycles spent in the in/out instructions for simplicity purposes. I just wanted to clarify why the 6MHz and 15MHz delays you recorded are not in a ratio of 6:15.
321
« on: May 16, 2014, 05:25:42 pm »
The size of the (usable) graph screen on non-color calculators is 95*63 pixels, which is 1*1 smaller than the total screen size of 96*64 pixels. A typical window range for a 1:1 ratio of pixels to points is [0..94]*[0..62].
The size of the (usable) graph screen on the 84+CSE is 265*165 pixels, which is a fair amount smaller than the total screen size of 320*240 pixels. A typical window range for a 1:1 ratio of pixels to points is [0..264]*[0..164].
Not sure if this information is even helpful, but I'll just dump it here anyways.
322
« on: May 16, 2014, 01:10:17 pm »
Whoa nice. Only weird thing is that it looks like it takes 4 times more cycles for 15-16MHz but it's not even 3 times the speed.
Yeah, i really never figured out why myself...
Your delay figures don't count the amount of cycles spent in the out/in instructions, do they? I believe that could account for the discrepancy you're seeing. It may not add exactly 11 cycles of delay though, as a physical port write might not happen after the same amount of time/cycles relative to the start of the instruction as a physical port read.
323
« on: May 15, 2014, 08:52:06 am »
All set bits will disable the corresponding groups, but it will take some time (the famous delay).
Note that when you ask the keyboard to disable a group that is already disabled, it will do nothing (no delay).
So, basically, the keyboard only needs a delay when changing a group bit from 0 to 1.
That's been my suspicion for years, but I don't have any knowledge of how the hardware actually works so could never definitively say so. Good to hear that my suspicion can now be upgraded to a probable truth. It appears that when you enable all groups, and then ask the port to disable them, my calc needs exactly 121 cycles to perform a full disabling, in cpu speed 1.
In other words, that's the time the keyboard needs to switch all 8 groups from 0 to 1.
That's about 16 cycles per group, which is huge.
Anyway, my second theory was right : the more groups the port has to disable, the longer it takes.
Whoa, that I did not expect. I'll definitely want to play with that myself on hardware. Maybe that could explain the rare occurrences I still hear about of mis-registered keypresses in Axe, as the getKey(0) command reads from all groups to check if any key is pressed and might be causing issues for any subsequent single key read attempt.
324
« on: May 15, 2014, 08:40:13 am »
I was strictly talking about the presentation of the app store. Primarily, having things like top downloads and featured pages. The featured pages would contain new uploads (and potentially updates), but could also contain hand-picked categories like "back to school" which would feature quality reference programs. A personalized updates page that shows you updates for programs that you previously downloaded would also be neat.
325
« on: May 14, 2014, 05:47:45 pm »
This is starting to sound a lot like the functionality of a good downloads section, with app store-like presentation. Looks like the downloads section could use some TLC anyways.
326
« on: May 13, 2014, 05:29:29 pm »
That is a known bug, due to abusing L2 as a whole buffer, and there is no way around fixing that except getting rid of double-buffering and thus have it flicker all over the place or by using up 768 more bytes of user ram which is IMO not worth it.
Try using ClrDraw(L2+103) before exiting.
still giving that bug >.<
I'll try to investigate a way to solve it.
327
« on: May 12, 2014, 12:51:44 pm »
I'm of the opinion that resetting the group port is not necessary. Axe's direct key input routine has never done so, and if it didn't work, I'm sure we'd have heard about it from any one of its hundreds of users by now. (I did actually hear about problems a few times, but simply upping the delay seemed to fix any issues)
For reference, the current version of the direct key input routine explicitly waits for a fairly generous 40 cycles, or if you want to count the cycles of delay in the out/in instructions themselves, 51 cycles.
Wow that's a lot.  is it for 15MHz compatibility ?
It is. If you look at the old data the_mad_joob collected, some people's calculators were recorded as needed up to 29 cycles of delay at the high CPU speed. So I overshot that to be safe.
328
« on: May 12, 2014, 08:33:01 am »
I'm of the opinion that resetting the group port is not necessary. Axe's direct key input routine has never done so, and if it didn't work, I'm sure we'd have heard about it from any one of its hundreds of users by now. (I did actually hear about problems a few times, but simply upping the delay seemed to fix any issues)
For reference, the current version of the direct key input routine explicitly waits for a fairly generous 40 cycles, or if you want to count the cycles of delay in the out/in instructions themselves, 51 cycles.
329
« on: May 09, 2014, 12:32:13 pm »
Maybe I can learn hex though? I not always have acess to my computer and would like to program without it:)
You can write assembly programs on-calc with Mimas. It's an amazing on-calc assembly editor that supports most of the important things any computer-side assembler does.
330
« on: May 08, 2014, 05:11:55 pm »
That is a known bug, due to abusing L2 as a whole buffer, and there is no way around fixing that except getting rid of double-buffering and thus have it flicker all over the place or by using up 768 more bytes of user ram which is IMO not worth it.
Try using ClrDraw(L2+103) before exiting.
Pages: 1 ... 20 21 [22] 23 24 ... 153
|
Show Posts
