Posted By
Rybags
on 2010-11-11
01:48:10
|  Re: Assembly and interrupts: my first attempt. Help needed!
Calculating a text screen address given X/Y - a good quick way is to just have a table with all the X=0, Y=n addresses, that only costs you 50 bytes.
Then you can just grab the address from the table, put it into your z-page pointer or self-modify your code, and use X or Y as an index using the "X position".
CPU speed - OK I couldn't find the proper info, so this is from memory and probably isn't 100% right.
A full PAL frame is 312 scanlines (262 if NTSC). Regardless of system you have 114 cycles per scanline.
On any scanline except a "badline", 5 cycles are lost for RAM Refresh (DRAM has to constatnly be refreshed so it doesn't lose it's contents).
In the onscreen area you have the additional "lost cycles":
- in any line including "badlines", you lose 40 cycles for the character bitmap data fetches.
- in a "badline" where TED has to fetch the attribute or character code bytes, you lose another 40 cycles. There are 50 badlines in a normal display, they occur 1 scanline before and on the scanline where a row of characters begins.
* This is the part I'm not 100% on - since so many cycles are lost already during a badline, only 1 Refresh cycle occurs instead of the usual 5.
Also, the CPU is throttled at 50% during the display window portion, but the net effect is as described above.
So, from a programming perspective, even though the offscreen area is barely half that of the onscreen area - 112 vs 200 in PAL, the amount of cycles available to the CPU is roughly equal for each. Different story for NTSC though, only 62 scanlines vs 200 - the significantly smaller amount of CPU cycles per frame is why many modern demos for 8-bit computers work on PAL but not NTSC.
|
