New Hires Games: Hero, Beamrider, Magic Floor

[nocash]

Now I am confused.
Which post are you taking about?
:-)

[kmurta]

Now I am confused.
Which post are you taking about?

Oh, thank goodness you did not read it

I thought I discovered a bug in the HR driver of HERO, which supposedly would prevent the operation of the game in real ZX81. But it was just an embarrassing mistake, forget it, please.

[kmurta]

Anyway I don't see why H.E.R.O. wouldn't work - maybe it's just an EightyOne quirk. Shall check on real hardware some time...

I discovered what happens: EO wait for a byte 80h at the end of the file and HERO.P not own this byte.

Attached the corrected file for the EO. It is necessary to adjust the vertical hold on EO (Options/TV Emulation or F9).

[PokeMon]

I think I made a terrible mistake, I assumed that the instruction JP (IX) had only 1 M-cycle, when in fact it has two. So everything that I have outlined earlier is wrong.

The IX/IY instructions have a prefix ($DD or $FD).

[RetroTechie]

I discovered what happens: EO wait for a byte 80h at the end of the file and HERO.P not own this byte.

I'm impressed... how on earth did you discover that?

Anyway, finally got it to work on EightyOne. I'm really impressed by this port. Apart from black and white, look & feel is very authentic compared to the Spectrum version (which is still my favorite btw - MSX version is okay but a sloppy port). Very 1st game got me to level 8 and score 33k+, I must have played this game too often when I was young...

It is necessary to adjust the vertical hold on EO (Options/TV Emulation or F9).

Let's hope that's not an issue on real hardware, because that would be a problem: a 20 year old monitor often has controls for horizontal / vertical hold, but a modern TV / monitor likely won't. Maybe such a monitor will manage to produce a stable image, but if not there isn't a thing the user can do about it.

Looks like # of screen lines was altered, so that vertical refresh deviates too much from 50 Hz? If so, I'd suggest fixing that. A few more or less blank lines on top / bottom never hurt no-one...

Also: looking at the rock formations, I suspect this might be relatively easy to convert to pseudo hi-res. That would cut down on the amount of graphic data (and perhaps reduce memory requirements), and remove true hi-res capability from the requirements so that it works on more machines / emulators. Any chance of releasing the source for this baby?

[nocash]

I discovered what happens: EO wait for a byte 80h at the end of the file and HERO.P not own this byte.
It is necessary to adjust the vertical hold on EO (Options/TV Emulation or F9).

The 80h is missing? Ah, yes, right. I've saved the file in FAST mode (video disabled), so I could omit the D_FILE stuff at the end of the file (even if it's empty / filled with HALT opcodes, it would be just wasting memory), and alongsides, I've dropped the 80h, too.
The file-end check at BIOS:01FCh does just check the end address (not the ending data), I think, the 80h isn't really required on real hardware... or is it needed?
In no$zx, I am skipping the 7-minute cassette loading part, and do just copy the file into RAM (both when testing in emulator and when uploading the file to real zx81), so I may have missed problems in the original cassette loading functions.

And, yup, on the video side I've cheated a bit: Increased upper/lower blanking times, which is dropping the frame rate to 43Hz, but increases the available cpu time during vblank, so it's altogether making the game faster.
The analog CRTs that I've tested it with worked without problems (without needing to do any manual centering). But newer digital TFTs (or even CRTs from other manufacturers) might be getting confused there - would be interesting if the frame rate is causing problems on some TV sets.

[nocash]

Pseudo hires is needing same amount of memory as real hires. Or even a bit more memory: Extra HALT opcodes inserted in the bitmap, and (when doing the conversion on the fly) also an extra translation table.
I've thought about pseudo hires too, but the old hires-incompatible 16K expansions are too small for that game, and newer 48K expansions are (hopefully) hires-compatible.

[kmurta]

The file-end check at BIOS:01FCh does just check the end address (not the ending data), I think, the 80h isn't really required on real hardware... or is it needed?

You're rigth, the 80h isn't really required on real hardware, this is a problem only with the EO emulator

And, yup, on the video side I've cheated a bit: Increased upper/lower blanking times, which is dropping the frame rate to 43Hz, but increases the available cpu time during vblank, so it's altogether making the game faster.

This is very interesting, could you give more details of how to do this?

The Zeddy always surprising me, it seems that there is always some new trick waiting to be revealed.

[PokeMon]

I discovered what happens: EO wait for a byte 80h at the end of the file and HERO.P not own this byte.
It is necessary to adjust the vertical hold on EO (Options/TV Emulation or F9).

The 80h is missing? Ah, yes, right. I've saved the file in FAST mode (video disabled), so I could omit the D_FILE stuff at the end of the file (even if it's empty / filled with HALT opcodes, it would be just wasting memory), and alongsides, I've dropped the 80h, too.
The file-end check at BIOS:01FCh does just check the end address (not the ending data), I think, the 80h isn't really required on real hardware... or is it needed?

Well $80 at the end is needed by real hardware, I am sure about this. Dr. Beep missed this last byte by his 1k games which have been tested in EO only and were working there and now we know why.

And by the way, it is just one single byte, you can not really name it as "waste of memory".

[RetroTechie]

You can't change horizontal sync frequency AFAIK, since hsync's are always generated and can't be disabled by software. So duration / frequency of any single screen line is fixed. Well, theorically, perhaps, you might double that freq. by software-generating short sync pulses halfway screen lines. Probably not useful.

But vertical sync frequency is determined by # of screen lines (+ duration of vsync itself), and that's basically up to the programmer. The ZX81 ROM reads an ULA pin to determine 50 or 60 Hz refresh, and uses that to set a system variable (MARGIN), which decides how many empty screen lines are above & below the active display area. But no reason why the programmer of a Hi-Res routine can't mess with that...

FWIW: I think 43 Hz vertical refresh is asking for trouble, nocash is lucky that works at all. But I understand his reason for doing so. And OTOH: the # of people running H.E.R.O. on real hw, can probably be counted on one hand. (I for one, am not among them)