Futuro MZ by Genesis Project

Is there such a thing as an MZ demoscene?
Sdw
Posts: 15
Joined: Wed Jul 08, 2020 10:27 am

Futuro MZ by Genesis Project

Post 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! :)
hlide
Posts: 681
Joined: Thu Jan 25, 2018 9:31 pm

Re: Futuro MZ by Genesis Project

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

Re: Futuro MZ by Genesis Project

Post by hlide »

Now a space invader with, say, 112x100 pixels :p.
ysblokje
Posts: 18
Joined: Fri Aug 14, 2020 8:06 am

Re: Futuro MZ by Genesis Project

Post 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.
User avatar
mz-80a
Posts: 403
Joined: Thu Jan 25, 2018 10:46 am
Location: Devon, UK
Contact:

Re: Futuro MZ by Genesis Project

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

Sharpworks (Sharp MZ homebrew)
https: //mz-sharpworks.co.uk/
User avatar
Pacman
Posts: 172
Joined: Mon Feb 05, 2018 2:59 pm

Re: Futuro MZ by Genesis Project

Post by Pacman »

very nice demo ! Bravo.
Sharpals
Posts: 27
Joined: Sat Jul 14, 2018 5:39 am

Re: Futuro MZ by Genesis Project

Post 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
Last edited by Sharpals on Sun Apr 11, 2021 6:03 pm, edited 1 time in total.
hlide
Posts: 681
Joined: Thu Jan 25, 2018 9:31 pm

Re: Futuro MZ by Genesis Project

Post 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.
User avatar
mz-80a
Posts: 403
Joined: Thu Jan 25, 2018 10:46 am
Location: Devon, UK
Contact:

Re: Futuro MZ by Genesis Project

Post by mz-80a »

What actually is the /WAIT for? Would be nice to have a decent explanation.
MZ-80A Secrets
https://mz-80a.com/

Sharpworks (Sharp MZ homebrew)
https: //mz-sharpworks.co.uk/
hlide
Posts: 681
Joined: Thu Jan 25, 2018 9:31 pm

Re: Futuro MZ by Genesis Project

Post 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).
Post Reply