MZ-700 demos

Is there such a thing as an MZ demoscene?
Post Reply
hlide
Posts: 681
Joined: Thu Jan 25, 2018 9:31 pm

Re: MZ-700 demos

Post by hlide »

@Sdw

So I install my LA1010 to get the extact timings of my stock PAL MZ-700:

Code: Select all

BLNK  :	(1) 22.6µs   , (0) 41.4/41.5µs		-> TOTAL=64/64.1µs
/HBLK : (1) 36/36.1µs, (0) 28µs			-> TOTAL=64/64.1µs
/HSY  : (1) 59.5µs   , (0) 4.6/4.5µs		-> TOTAL=64/64.1µs
/VBLK : (1) 12.8149ms, (0) 7.1764ms		-> TOTAL=19.9913/19.9913ms
/SYN  : (1) 19.799ms , (0) 192.3µs		-> TOTAL=19.9913/19.9913ms

|/HBLK-HSY|=9µs
|/HBLK-BLNK|=5.3µs (manual says 2.165081µs!)

BLANK signal is captured from 8253 input and is very regular! this is the one used for setting CPU /WAIT=0 if BLANK=1. I think EmuZ-700 is using /HBLK period instead of the shortest BLNK period.

Count of BLNK in the frame by the logic analyzer: 312!

So it looks the timer counting of 306 BLNKs per frame instead of 312 by stock MZ-700 is not due to irregularity of BLNK.

I will modify the timings in EmuZ-700 according those values.

Could you provide you program so I can test with it?
Sdw
Posts: 15
Joined: Wed Jul 08, 2020 10:27 am

Re: MZ-700 demos

Post by Sdw »

Fantastic to hear that you are looking into this, will be interesting to see the results!

I've uploaded a .mzf of the small test program here:
http://ag1976.com/tmp/emutest.mzf
hlide
Posts: 681
Joined: Thu Jan 25, 2018 9:31 pm

Re: MZ-700 demos

Post by hlide »

Thanks!

I have a big difficulty with the big messy hack the EmuZ-700 uses to block CPU access to VRAM. On a real CPU, the /WAIT state will make the CPU wait until BLANK is active. On EmuZ-700, it seems to use the /BUSRQ signal but in a way too hackish that is pretty hard to inverse /HBLNK and BLNK at the begining of a line the way it is on my logic analyzer. Not even properly commented so I can understand that weird logic... gosh!
Sdw
Posts: 15
Joined: Wed Jul 08, 2020 10:27 am

Re: MZ-700 demos

Post by Sdw »

Perhaps patching in proper MZ-700 timing support to Chakys MZ-800 emulator would be an easier alternative?
I don't have the setup to compile it, but I did download the source code and poke around a bit, but I have to admit that I got totally lost after a while.
Also, given that it is an MZ-800 emulator and that strange write-latch behavior is emulated (which doesn't seem to be present on the MZ-700) it might be even worse trying to get it to work there.

I haven't looked at the EmuZ-700 source code, I'll see if I can download it and be of any assistance (though I doubt it! :) )
hlide
Posts: 681
Joined: Thu Jan 25, 2018 9:31 pm

Re: MZ-700 demos

Post by hlide »

Inverting the /HBLK and BLNK signals in the vertical line event is making things complicated so I just add BLNK signal with its shortest period: it does solve the 112 issue I had with PAL EmuZ-700. But I still get around 13s instead of 16s.

What I had beforehand:
2020-06-01_20-40-28.png
2020-06-01_20-40-28.png (10.99 KiB) Viewed 9978 times
What I had if I reduce the character lines to 19 instead of 25:
2020-06-01_19-16-19.png
2020-06-01_19-16-19.png (8.94 KiB) Viewed 9978 times
What I have now with a full 112x200:
2020-07-11_19-27-28.png
2020-07-11_19-27-28.png (11.26 KiB) Viewed 9978 times
What I got when trying to invert horizontal period as shown in the logical analyzer:
2020-07-11_18-55-56.png
2020-07-11_18-55-56.png (12 KiB) Viewed 9978 times
I cannot say I'm satisfied. The EmuZ-700 made some silly choice about how to handle wait states I don't agree with. I also don't agree with the choice with using /BUSREQ to handle VRAM access because of the poor way to handle wait states.

Not only that, the way to handle the BLNK counter (PIT CLK1) is not even synchronized with the BLNK signal. And the /HBLK signal is not even used for the MZ-700 joysticks ports (well I guess EmuZ-700 is not even handling any analog joystick, so it is less a surprise).
Attachments
2020-07-11_18-55-56.png
2020-07-11_18-55-56.png (12 KiB) Viewed 9979 times
2020-07-11_19-27-28.png
2020-07-11_19-27-28.png (11.26 KiB) Viewed 9979 times
2020-06-01_19-16-19.png
2020-06-01_19-16-19.png (8.94 KiB) Viewed 9979 times
hlide
Posts: 681
Joined: Thu Jan 25, 2018 9:31 pm

Re: MZ-700 demos

Post by hlide »

There is a serious issue with multiple images insertions on this forum when updating a post.
hlide
Posts: 681
Joined: Thu Jan 25, 2018 9:31 pm

Re: MZ-700 demos

Post by hlide »

So the emulator considers there are 228 cycles per line, it wants for a line to start with BLNK=0 until N cycles then to toggle it to BLNK=1 (then the CPU should be able to access VRAM). As a note, my logic analyzer tells me the line starts with BLNK=1 then toggle it to BLNK=0 after 81 cycles.

I had to keep the emulator order choice, so I played with N to try to reach 16s. N is too higher when I reach 16s and 112.mzf cannot run properly. So I don't think the BLANK signal emulation is the only issue about the speedness inaccuracy.

With the logic analyzer, I'll add the CLOCK input to count it during the line, the BLANK period, etc. so I can compare to the chosen ones of emulator.
hlide
Posts: 681
Joined: Thu Jan 25, 2018 9:31 pm

Re: MZ-700 demos

Post by hlide »

So here is what I measured with my logic analyzer (using pulse measurement feature):

Unit is CPU cycle. Order of signal values is from left to right (that is in chronological order).

Code: Select all

LINE	: 227
	Genuine MZ-700starts its LINE here
	   |	
	   |			EmuZ-700 starts its LINE here
	   |				   |
	   v				   v
BLNK	: (1) 80			| (0) 147	-> TOTAL: 227
/HBLK	: (0) 99			| (1) 128	-> TOTAL: 227
/HSY	: (0) 32	| (1) 16	| (0) 179	-> TOTAL: 227
So I updated PAL EmuZ-700 to the measured cycles value according when it starts the LINE from BLNK=0.

112.mzf works perfect but still around 13s.
hlide
Posts: 681
Joined: Thu Jan 25, 2018 9:31 pm

Re: MZ-700 demos

Post by hlide »

@Sdw EmuZ-700 source is not that hard to read but it made some choice I wouldn't do.
Sdw
Posts: 15
Joined: Wed Jul 08, 2020 10:27 am

Re: MZ-700 demos

Post by Sdw »

It's very interesting following your work hlide, unfortunately I have far from enough knowledge about the internal signals to come with any meaningful input.
In your current test compile of PAL EmuZ-700, how many cycles per line is VRAM-accessible?

A while ago MooZ sent me this link:
https://twitter.com/youkan700/status/10 ... 7077280768
Where some guy from Japan have written a program that somehow tests the size of the VRAM access window. I have to admit that I don't really understand exactly how it's working, but playing around with it on my MZ-700 I get a bugfree access window at 82 cycles (and lower) and bugs if I set to to 83 and higher.
So, if 82 cycles/rasterline checks out, I did some quick math and came up with the following:

My test program runs 1000 loops of LDIRs of 1000 bytes. Each LDIR takes 21 cycles, so we are looking at 21 million cycles of VRAM access for it to run (now, this isn't the *exact* truth, since not every cycle of the LDIR 21 cycles actually needs VRAM access, so the first and last of the LDIR instructions that fit into the window may stretch out a bit before and after).
Anyway, if we skip these, we at least get an upper bound on how long it should take.

312 lines * 82 accessible cycles per line * 50 frames per second = 1279200 VRAM accessible cycles per second.

21000000/1279200 = 16.4 seconds.

My manually timed tests shows that it runs a bit below that, which makes sense as I said, LDIR doesn't necessarily get absolutely blocked outside the VRAM-window.
Post Reply