I would'nt have thought to join such conversation, but I feel that too much unverified allegations have been made here... Coincidentally, last days while porting an old emulator of the "best selling of all time Z80-based home video game console
, I had to rewrite the CPU interrupt handling and related instructions, and I can say that roughly 100% of the 300 commercial games for it start with these bytes : F3 ED 56 (DI and IM 1)!
Indeed Interrupt Mode 0, while the default, is pratically never implemented, and it is the sole source of hardware interrupt, usually triggered at the end of each frame, so coders can take advantage of the interrupt routine to do things like to start offscreen VRAM writes during VBLANK.
hlide a écrit : ↑01 déc. 2018 22:19
Using 'halt' is a curious thing which should not be usually put in the hands of a "user".
Using 'halt' for such thing is no a good practice.
Are you a direct descendant of Moses ??
Because it really sounds like the "Ten Commandments of HALT"...
Do you have any proof or example of such categorical statements ? (or did the God of Z80 whispered them to you in your sleep ?
My test rom this week was a very famous and demanding game (one of the bestsellers for this platform, codename : "Le Retour du Hérisson Bleu"
) and (like W_oo_d does) it uses HALT to wait for next VBLANK interrupt, in this case, to show a progressive, synchronised frame by frame, fading to black between each level and presentation screens.
So it is perfectly valid to use it when your code has, at some point, nothing else to do than to wait for the next interrupt that will "wake" the CPU, with the benefit of some energy efficiency... and anything that help to "développement durable" seems like a totaly recommanded pratice !
hlide a écrit : ↑
From [linked message], it seems there is a 20ms periodical timer: 50 Hz. But it is not clear if it is a hardware timer to emulate or it is just a emulator timer to emulate the 50 Hz refresh. But the author talks about interruptions so I guess there is an effect on 'halt' - at least on VBHector.
Unless that "50Hz timer" is just the vsync feeded as an interrupt (and be the only one interrupt possible on Hector apart from NMI).
If it's not clear, then why do you just guess (or make assumptions only based on a few vague words like "the 20ms interrupts" in linked message) instead of looking for the real answer ?
You probably know that http://hectorvictor.free.fr/
provides a lot a reference documentation in its "Literature" section , like the schematics (that you seem able to analyze the circuit, like you do with with IO addressing on forum.sharpmz.org) of the Hector HR, so could have check first.
I spent 10 minutes doing just that, and I can already see that the NMI input is disabled (only pulled up in 'high' state) on schematic 4 :
On schematic 6A, named "Comptage Video
" you can see it is articulated around a counter which is probably dedicated to scan the video RAM, along with some logic that uses this addressing sequence to get dividers by 76 and 103 (!) to obtain and trigger VSync, and you can even see this formula of its period (so we can even tell that the exact framerate is approximately 50.57 Hz !