Page 4 of 9

Re: MZ-700 demos

Posted: Sun May 31, 2020 11:35 am
by hlide
The original emulator doesn't emulate correctly the BLNK as I already told on an earlier post.

|/HBLNK| = 64.05603 µs - 36.088 µs = 27.96803 µs -- PHIOx|/HBLNK|--> 99,19910640625‬ cycles
|BLNK| = |/HBLNK| - 2.16508 µs = 25.80295 µs -- PHIOx|BLNK|--> 91,51983828125 cycles

The emulator does |/HBLNK| == |BLNK|. I'm not sure how to correct that because the emulator starts |BLNK| = 0 at the same time as |/HBLNK| = 1 whereas it should be |BLNK| = 1 at the same time as |/HBLNK| = 0. And I see no easy way to do so with its current implementation of events.

I don't know the exact sequence you use : there are two requirements to obseve, the PUSH sequence must be under 91 cycles, and the update raster should be under 227 cycles. If you miss one requirement, you screw up the graphics drawing.

Re: MZ-700 demos

Posted: Sun May 31, 2020 12:01 pm
by hlide
Et sinon, je vois un début prometteur sur ta photo puis ça se gâte à la deuxième ou troisième ligne de caractères.

The timings appear a little off after several raster updates so the issue is probably the length in cycles of your raster code which is two close to the end of the raster and makes the next raster to miss the BLNK synchronization at one moment: after that you only will get characters displayed.

Re: MZ-700 demos

Posted: Sun May 31, 2020 12:50 pm
by hlide
I tried two ways through my Unicard.

VGA output from Unicard: the timings is totally off. Just plain characters. It looks like the VGA output of Unicard is a no-go for games/demos using display precise timings.

SCART output from MZ-700: there is a rough mix of characters at the first lines, mostly like yours indeed. Ok the first lines are not exactly the same ones as expected as in my previous post.

Re: MZ-700 demos

Posted: Sun May 31, 2020 3:04 pm
by MooZ
This one works (at least on my machine...), but fails every 2 frames on the emulator.

Re: MZ-700 demos

Posted: Sun May 31, 2020 4:48 pm
by hlide
The most important thing is it works on the real machine. It does work on mine. I will try to understand why it fails on the emulator. And thank you for your efforts and your source!

Re: MZ-700 demos

Posted: Sun May 31, 2020 9:55 pm
by hlide
What I discovered:

1) Genuine MZ-700:

- /HSY[NC] starts the next line.
- /HBL[AN]K goes LOW 9µs BEFORE /HSY going LOW, and HIGH AFTER 28µs.
- BL[A]NK (connected to Z80 /WAIT) goes HIGH 2µs BEFORE /HBLK going LOW, and LOW AFTER 26µs.

-/[V]SYN[C] starts the next frame.
- /VBL[AN]K goes LOW 4ms BEFORE /SYN going LOW, and HIGH AFTER 7ms.

2) EmuZ-700:

- /HSY[NC] starts the next line.
- /HBL[AN]K goes LOW 28µs BEFORE /HSY going LOW, and HIGH WHEN /HSY going HIGH.
- BL[A]NK (connected to Z80 /BUSRQ!?) is doing the same as /HBLK as an inverted signal.

-/[V]SYN[C] starts the next frame WHEN line number is 240.
- /VBL[AN]K goes LOW WHEN line number >= 200, and HIGH WHEN line number is < 200.

Re: MZ-700 demos

Posted: Mon Jun 01, 2020 5:25 pm
by hlide
So if I change the number of displayed character lines from 25 to 19 (removing 6 lines), I get a stable image. Above 19, I get an unstable image.
2020-06-01_19-16-19.png (8.94 KiB) Viewed 3096 times

Re: MZ-700 demos

Posted: Mon Jun 01, 2020 7:44 pm
by hlide
At least it works with mz800emu from Chaky :

Re: MZ-700 demos

Posted: Fri Jul 10, 2020 11:05 pm
by Sdw
Very interesting to see other people who want to have a proper emulator for PAL MZ700!

I've started doing some coding on a demo, but not being able to properly test if my code will run fullspeed or not is a real show-stopper, testing on real hardware via tape port transfer is very cumbersome.

mz800emu unfortunately isn't correct, it gives too much VRAM access time. Or rather, it's probably correct for a MZ800 in MZ700 mode, but that's not the same as a MZ700!
I've been mailing quite a bit with the author (chaky) and we concluded that there were differences in speed (possible related to some RAM-latch that was present on the 800 but not on the 700).
I tried to convince him to do a cycle exact MZ700 version as well, but unfortunately it doesn't seem to be happening.

Because of that I was very excited when I saw that you had modded a PAL-version of the MZ700 emulator, hlide, but my tests indicate that it gives too much VRAM acess time as well.

Me and chaky did testing using this simple test program I wrote:

Code: Select all

; Copy buffer to entire VRAM 1000 times
ld bc,1000
push bc
ld hl,0xa000
ld de,0xd000
ld bc,1000
pop bc
dec bc
ld a,b
or c
cp 0
jr nz,testloop
; Change to red background to show test finished
ld hl,0xd800
ld de,0xd801
ld (hl),0x72
ld bc,999
jp inf 
It's simply a "bad" non-optimized copy-to-VRAM code, but that doesn't matter, what is interesting is to see how long it takes to run it.

On my real hardware (MZ700, PAL) it takes 16 seconds.
In MZ-800 emulator, it takes 11 seconds.
hlide's PAL-modded MZ700 emu also takes 11 seconds.

Chaky also ran it on some of his real machines:
MZ-700 (EU version - PAL) - 16 sec
MZ-700 (JP version - NTSC) - 21 sec
MZ-800 (PAL) - 11 sec
MZ-1500 (NTPL) - 21 sec

This indicates that somehow every raster line, VRAM-access is allowed for too many cycles in the emulators compared to real hardware, and for some reason it seems to match the MZ-800 timings.

I'm not sure where the problem lies, but if we could somehow get an emulator to at least be more reasonably close in VRAM access time, it would be very helpful.
The next step is of course to get it cycle exact (needed for hires stuff like MooZ works on), but I guess that is even harder...

Re: MZ-700 demos

Posted: Sat Jul 11, 2020 12:53 am
by hlide
Video timings of mz800emu is the closest to stock mz700. EmuZ-700 PAL uses the same video timings than EmuZ-800. Look at viewtopic.php?f=8&t=407&start=10#p1672 for my vsync checker which tries to count the BLNK count in a frame: mz800emu appears more consistant. I certainly wish to have EmuZ-700 PAL to be closer. Now the question of having only 11s instead of 16s needs more insights. Do you have any idea?