MZ-80A / MZ-80K extra RAM

User avatar
mz-80a
Posts: 168
Joined: Thu Jan 25, 2018 10:46 am
Location: Devon, UK
Contact:

MZ-80A / MZ-80K extra RAM

Post by mz-80a » Thu Sep 26, 2019 11:25 am

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 :D
MZ-80A Secrets
https://mz-80a.com/

Sharpworks (Sharp MZ homebrew)
http://mz-sharpworks.co.uk/

hlide
Posts: 285
Joined: Thu Jan 25, 2018 9:31 pm

Re: MZ-80A / MZ-80K extra RAM

Post by hlide » Thu Sep 26, 2019 1:09 pm

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
Posts: 285
Joined: Thu Jan 25, 2018 9:31 pm

Re: MZ-80A / MZ-80K extra RAM

Post by hlide » Thu Sep 26, 2019 1:13 pm

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

User avatar
mz-80a
Posts: 168
Joined: Thu Jan 25, 2018 10:46 am
Location: Devon, UK
Contact:

Re: MZ-80A / MZ-80K extra RAM

Post by mz-80a » Thu Sep 26, 2019 1:14 pm

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.
MZ-80A Secrets
https://mz-80a.com/

Sharpworks (Sharp MZ homebrew)
http://mz-sharpworks.co.uk/

Jo Even
Site Admin
Posts: 110
Joined: Wed Jan 17, 2018 9:28 pm

Re: MZ-80A / MZ-80K extra RAM

Post by Jo Even » Fri Sep 27, 2019 6:56 am

hlide wrote:
Thu Sep 26, 2019 1:13 pm
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
Posts: 285
Joined: Thu Jan 25, 2018 9:31 pm

Re: MZ-80A / MZ-80K extra RAM

Post by hlide » Fri Sep 27, 2019 8:09 am

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
Site Admin
Posts: 110
Joined: Wed Jan 17, 2018 9:28 pm

Re: MZ-80A / MZ-80K extra RAM

Post by Jo Even » Fri Sep 27, 2019 8:32 am

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
Posts: 285
Joined: Thu Jan 25, 2018 9:31 pm

Re: MZ-80A / MZ-80K extra RAM

Post by hlide » Fri Sep 27, 2019 10:43 am

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
Posts: 285
Joined: Thu Jan 25, 2018 9:31 pm

Re: MZ-80A / MZ-80K extra RAM

Post by hlide » Fri Sep 27, 2019 10:53 am

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
Site Admin
Posts: 110
Joined: Wed Jan 17, 2018 9:28 pm

Re: MZ-80A / MZ-80K extra RAM

Post by Jo Even » Fri Sep 27, 2019 11:45 am

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.
hlide wrote:
Fri Sep 27, 2019 10:43 am
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.

Post Reply