MZ-80A / MZ-80K extra RAM

[mz-80a]

Hi,

Just a note that I realised recently there is, obviously, a section of video RAM which is unused and could store programs / data.

On the MZ-80A you have the memory locations $D7D0 to $D7FF (48 bytes) which are not sent to the screen but is still RAM so is usable. The RAM from $D800 to $DFFF unfortunately doesn't exist physically so there's no extra RAM there.

On the MZ-80K you have the 24 bytes at the end of each 'page' of video RAM (each mirrored so you can't have 96 bytes, only 24), so for instance from $D3E9 to $D401

Just an interesting observation (and confirmed with John @ SUC)

Who knows, somebody could make use of 24 or 48 bytes

[hlide]

MZ-80 K: because it mirrors 1Kbyte video page in the range of $D000-$DFFF, only 24 bytes in the end of the common video page are effectively usable for non video purpose (but fear snows if you abuse them).

MZ-80 A: No mirror but only first half (two video pages) in the range of $D000-$DFFF is VRAM-ed, so 48 bytes in the end of the last video page are effectively usable for non video. BUT, more can be usable if you don't use the hardware scrolling: 1048 bytes can used for non video.

MZ-700: No mirror but two video pages (one for characters and the other for attributes) and two non-video pages in-between, so two separate 1048 bytes are usable for non video purpose. As a fact, $D400 or $DC00 can be used to store programs when there is no attempt to handle a software scrolling.

[hlide]

MZ-700 games could also effectively use that "second" memory to store a background to be restored when redrawing software sprites for instance.

[mz-80a]

Thanks Hlide. Yes, I could have been clearer. Of course, I nearly always end up using the two pages of V-RAM on my 80A But indeed you could get 1048 bytes from the unused 2nd page if that's preferable.

[Jo Even]

MZ-700 games could also effectively use that "second" memory to store a background to be restored when redrawing software sprites for instance.

That's what I've been using it for in my current game project, but if I understand it correctly you should be able to use the second page for scrolling too, atleast on the 700. But how does it work? And does it work on other machines than the 700?

[hlide]

I say SOFTWARE scrolling. There is no hardware to handle it, you need to LDIR so it's slow. Only the first kilobyte is output on the screen, the second is invisble. MZ-700 monitor 1Z13A doesn't handle a two-page content but the BASIC 1Z13B appears to do so (this is not an infinite scrolling).

[Jo Even]

Ahh... That's a bit diappointing, I've always believed that the 700 had hardware scrolling. Not that much use in the extra VRAM then. Isn't access to VRAM slower than RAM too? It looks like it's only accessed during blanking periods?

[hlide]

After reading the manual, it seems worse than I thought: "Accessing of the VRAM is carried out within the blinking period (BLNK = "H"). If BLNK = "L", then WAIT is applied to the CPU (WA = "L")." So if you want to modify the VRAM content immediately, you must wait the BLNK to be "H". That's... 25.80295µs at most versus 64.05603µs per line.

[hlide]

By the way, if you want to get a BLNK interrupt, I see it fed to 8253.CKL1 and 8253.OUT1 is feeding 8253.CLK2. 8253.OUT is driving /INT1

So it should be possible to have the interrupt to monitor the lines per pixel, per character or per frame.

[Jo Even]

Yes, the HBL is used as "master clock" for the timer interrupt, so it's possible to get one interrupt per VBL by dividing the clock by the number of lines per frame. If you time the initialisation of the timer to the VBL signal it should be possible to get a reliable interrupt when the last line of the frame has been drawn. This could be used to avoid tearing in games.

That's... 25.80295µs at most versus 64.05603µs per line.

Yes, it seems so. So using the second VRAM page to buffer sprite background is not a good idea if you're short on CPU cycles.