Page 1 of 2

Futuro MZ by Genesis Project

Posted: Fri Oct 16, 2020 8:54 pm
by Sdw
Finally the demo I've been working on is finished, thanks to everyone here on the forums for their help!

Youtube video

MZF binary

Technically it a bunch of standard "demoscene" effects, trying to optimize as best as I could with interleaved VRAM access and stack abuse to get as much speed as possible, and finally a hires routine with a little twist to it! :)

Re: Futuro MZ by Genesis Project

Posted: Fri Oct 16, 2020 10:51 pm
by hlide
Yeah, without looking at the code, I'm pretty sure you use 112 pixels per line, but instead displaying a rectangle, you shift the X character start position X at each pixel line Y. ;P

Re: Futuro MZ by Genesis Project

Posted: Fri Oct 16, 2020 11:09 pm
by hlide
Now a space invader with, say, 112x100 pixels :p.

Re: Futuro MZ by Genesis Project

Posted: Sun Oct 18, 2020 9:29 pm
by ysblokje
Sdw wrote: Fri Oct 16, 2020 8:54 pm Finally the demo I've been working on is finished, thanks to everyone here on the forums for their help!

Youtube video

MZF binary

Technically it a bunch of standard "demoscene" effects, trying to optimize as best as I could with interleaved VRAM access and stack abuse to get as much speed as possible, and finally a hires routine with a little twist to it! :)
Not wearing one, but I take my hat of to you! Very impressive even if you find it to "standard" stuff. Almost makes me wish I had not sold my 800. When I owned a 700 as a kid not in my wildest dreams could I have imagined this being possible and the sound even being tolerable.

Re: Futuro MZ by Genesis Project

Posted: Tue Oct 20, 2020 2:02 pm
by mz-80a
Very cool. Presume splitting VRAM by chasing the beam to get the hi-res pic. Must take a lot of different character swaps!

Re: Futuro MZ by Genesis Project

Posted: Thu Oct 22, 2020 4:47 am
by Pacman
very nice demo ! Bravo.

Re: Futuro MZ by Genesis Project

Posted: Sun Apr 11, 2021 8:57 am
by Sharpals
hello, can you tell me how did you created the hires PCG picture ?

I tested on my emu , the first of your demo looks fantastic !!! But my emu fails at the last part of your demo.

I have maped the MZ700 beeper to Gneral Midi :

https://www.youtube.com/watch?v=g3EBYAbtNiY

and

https://www.youtube.com/watch?v=_zG83LFHlgg

Re: Futuro MZ by Genesis Project

Posted: Sun Apr 11, 2021 12:43 pm
by hlide
You need my PAL version of EmuZ-700 (https://github.com/SHARPENTIERS/EmuZ-700-1500/releases) or the last version of mz800emu. The video timing was problematic on every emulator because they were not respectful about the wait states cycles accuracy that demo demands.

Re: Futuro MZ by Genesis Project

Posted: Thu Apr 15, 2021 9:06 am
by mz-80a
What actually is the /WAIT for? Would be nice to have a decent explanation.

Re: Futuro MZ by Genesis Project

Posted: Thu Apr 15, 2021 6:43 pm
by hlide
When Z80 tries to access memory or I/O port, there is a moment when you drive a chip to read/write a byte, you need the Z80 to be paused because that chip may need more time to handle the operation. For that purpose, a chip may set the Z80 /WAIT input pin to make the Z80 inserting more cycles (idling) before reading/write a byte. When Z80 wants to try to access VRAM, LSI decodes the wanted address and understands that is a VRAM address. LSI also needs to read bytes from VRAM to build the current pixel during the horizontal drawing so when Z80 wants to read/write VRAM, LSI sets /WAIT to 0 to freeze Z80 during the horizontal drawing and sets /WAIT to 1 back during horizontal blank to allow Z80 to resume and finish its VRAM access. As long as Z80 is not accessing VRAM, it will fully execute with /WAIT = 1 (DRAM). There is an exception for ROM as LSI sets /WAIT = 0 for one cycle when Z80 tries to read a byte from Monitor ROM. The reason is to allow using slow ROM. The "bad" effect is if you copy the ROM content into the DRAM at the same address range (so you have a working Monitor running in DRAM) and try to save a program, you won't be able to load that program through Monitor ROM because Monitor runs faster in DRAM and the time polling used to build tape signals makes them too shorter (saved as 1400 baud instead of 1200 baud).