New Hires Games: Hero, Beamrider, Magic Floor

[RetroTechie]

Many thanks for releasing these!

Starfight - very nice shooter (be it rather challenging at times).
Magic Floor - nice little puzzler, I couldn't seem to find all possible moves though...
(had the above 2 running on a real ZX81)

Beamrider - impressive port given the ZX81's limitations, excellent gameplay.

H.E.R.O. - can't get it to work on EightyOne (version 1.0). Does anyone know if this game works on EO, and if so, what settings to use? Can't run on real hw either due to not enough RAM...

[nocash]

As these machines - MSX, CPC (etc) - are all Z80 based were these titles created by literally converting over the original code to run on the ZX81, by updating the graphics and keyboard routines?

Yes, they are direct ports. I've disassembled the CPC/MSX versions until getting the fully working "original" source code, and then ported them to zx81. For the MSX games, I needed to replace the hardware sprites by software-drawn ones, and tried to keep it working at reasonable speed (the games are a bit slower as on MSX, but they do still feel quite smooth). The on-screen instructions are typed-up from the original booklets; I've tried to reproduce the original games as close as possible.

When adding Spectrum emulation (after porting the games), I found out that it might have been ways easier to port spectrum games to zx81; as the spectrum video controller works almost identical to the zx81 in hires mode.

They look amazing - I really need to update my software page when I get time to add in all the new titles!!
Can I add downloads of these games to my website?

Yes, no problem.

Very nice, all work on real hardware, starfighter and Magic carpet need the ;X when loading from ZX-pand,

Okay. What is the ;X doing? Changing the rom-mapping? Theoretically the games aren't doing too unconventional things and should work either way, unless the ZX-pand bios is using totally different memory map than the zx81.
And Hero and Beamrider are working without ;X? Or is hero needing too much RAM?
Btw. zx-pand looks nice, but why is it limited to 32K ram? I think 128K SRAMs (even when using only 56K bytes of it) are same price or even cheaper than 32K todays.

Many thanks for releasing these!
H.E.R.O. - can't get it to work on EightyOne (version 1.0). Does anyone know if this game works on EO, and if so, what settings to use? Can't run on real hw either due to not enough RAM...

It's using the 56K RAM upgrade from krbaker, http://nocash.emubase.de/zxdocs.htm#hw56kramupgrade the schematic is quite old, and I hoped it would be the standard mapping... are there different mapping schemes?
The trick for accessing RAM at C000h-FFFFh is to handle data-reads (extra ram) different as than opcode-fetches (video ram mirror).

[sirmorris]

Hi Martin,

the ;X prefix disables the ZXpand rom overlay. As the external ROM is paged out for video generation I could replace the character map data with driver code. This interferes with hires programs which access the character map data directly.

I only used 32k ram because 1. they're available in skinny DIP (I was working to a particular size of board because I had a case in mind) and 2. There was until yesterday virtually no software which used more than 32k

The circuit you mention which allows execution of code in the upper pages of RAM is commonly known as the 'M1-NOT' mod. I'm sure you know that already

[yerzmyey]

starfighter and Magic carpet need the ;X when loading from ZX-pand,

Aaaah, thanks a lot for this information.

[kmurta]

Hi nocash!

Congratulations for the emulator and the new games! It's wonderful to see them running on the real ZX81

Just missed the sound effects, why not keep them?!

I imagine this would be simple, since the msx uses the same PSG as used in Zon-X81.

Anyway, you turn a beautiful job with these games, I just have to thank you for them.

Thank you!!!

[RetroTechie]

It's using the 56K RAM upgrade from krbaker, http://nocash.emubase.de/zxdocs.htm#hw56kramupgrade the schematic is quite old, and I hoped it would be the standard mapping... are there different mapping schemes?

Not 100% sure, but I think above circuit translates as: "/M1 NOT circuit enabled" and "RAM in 2000-3FFFh" (beside 4000-FFFFh). There's options for both in EightyOne, I've set RAM to 48K (highest choice available), and tried all combinations of "M1 NOT" / "RAM in 2000-3FFFh". But alas, no cigar...

ZX81 software for >32K is quite rare, and 32K RAM can mean "2000-9FFFh" or "4000-BFFFh" (some memory modules might support both using the same 32K chip(s), some may not). AFAIK, beyond 16K the use of RAM in 2000-3FFFh (24K total) is most common. Also some RAM extensions may support executing Z80 code in 8000-BFFFh area, others might treat that as DFILE execution like in C000-FFFFh area. Standard ZX81 has ROM mirrored in 8000-BFFFh, and does DFILE execution in entire 8000-FFFFh area. So you can't execute Z80 code in 8000-BFFFh without a hardware mod or suitable RAM extension.

Does H.E.R.O. use RAM in 2000-3FFFh area? Does it execute Z80 code in 8000-BFFFh range? What RAM area does it use overall, and where is the DFILE located? Knowing that might help to find a fix for running on EightyOne.

When adding Spectrum emulation (after porting the games), I found out that it might have been ways easier to port spectrum games to zx81;

Hehe, start with a ZX Spectrum game next time! A number of them also have sources available. MSX uses a dedicated videochip (TMS9918 compatible) which can do very nice things if programmed well, but it's very different from the simple memory location -> screen location mapping on ZX Spectrum & ZX81. Which are also different, but like you said, not that much. Basically when porting a game from MSX to ZX Spectrum or ZX81, you can throw all video code away... With ZX Spectrum -> ZX81 or vice versa, you might be able to re-use some video code.

[kmurta]

Basically when porting a game from MSX to ZX Spectrum or ZX81, you can throw all video code away... With ZX Spectrum -> ZX81 or vice versa, you might be able to re-use some video code.

With the appropriate video drive at ZX81, you can use the video code of ZX Spectrum practically without change. The code below simulate the ZX Spectrum screen in ZX81 (extracted from SP81 sources):

Code: Select all

scr:    equ     $2000

hron:   ld      ix,hr
        ret

spsto:  dw      0

hr:     ld      (spsto),sp   ;
        ld      sp,dspstk    ;
        bit     0,a          ;[8]
        ld      b,$05        ;[7]
hr1:    djnz    hr1          ;[13/8]

rscl:   add     hl,de        ;[11]
        dec     de           ;[6]
        dec     de           ;[6]
        jp      hdsp+$8000   ;[10]

hr2:
        ld      sp,(spsto)
        call    $292         ;return to application program
        call    $220         ;extra register push and vsync

break:  call    $f46         ;check break key                   \
        ld      a,$1e        ;restore pattern table pointer      | this is optional, used to restore
        ld      i,a          ;                                   | the standard video with BREAK key
        jr      nc,stop     ;skip the hr vector load if break   / 

        ld      ix,hr       ;load the hr vector

stop:   jp      $2a4         ;return to application program


hdsp:
        pop     hl              ;[10]
        ld      a,h             ;[4]
        ld      i,a             ;[9]
        ld      a,l             ;[4]
        ld      r,a             ;[9]
        db      $00,$00,$00,$00,$00,$00,$00,$00   ;[32]
        db      $00,$00,$00,$00,$00,$00,$00,$00   ;[32]
        db      $00,$00,$00,$00,$00,$00,$00,$00   ;[32]
        db      $00,$00,$00,$00,$00,$00,$00,$00   ;[32]
        ret                     ;[10]
        ;Total=[174]+[33] from rscl = [207] cycles for scanline

dspstk:
        dw    scr+$0000,rscl,scr+$0100,rscl,scr+$0200,rscl,scr+$0300,rscl
        dw    scr+$0400,rscl,scr+$0500,rscl,scr+$0600,rscl,scr+$0700,rscl
        dw    scr+$0020,rscl,scr+$0120,rscl,scr+$0220,rscl,scr+$0320,rscl
        dw    scr+$0420,rscl,scr+$0520,rscl,scr+$0620,rscl,scr+$0720,rscl
        dw    scr+$0040,rscl,scr+$0140,rscl,scr+$0240,rscl,scr+$0340,rscl
        dw    scr+$0440,rscl,scr+$0540,rscl,scr+$0640,rscl,scr+$0740,rscl
        dw    scr+$0060,rscl,scr+$0160,rscl,scr+$0260,rscl,scr+$0360,rscl
        dw    scr+$0460,rscl,scr+$0560,rscl,scr+$0660,rscl,scr+$0760,rscl
        dw    scr+$0080,rscl,scr+$0180,rscl,scr+$0280,rscl,scr+$0380,rscl
        dw    scr+$0480,rscl,scr+$0580,rscl,scr+$0680,rscl,scr+$0780,rscl
        dw    scr+$00a0,rscl,scr+$01a0,rscl,scr+$02a0,rscl,scr+$03a0,rscl
        dw    scr+$04a0,rscl,scr+$05a0,rscl,scr+$06a0,rscl,scr+$07a0,rscl
        dw    scr+$00c0,rscl,scr+$01c0,rscl,scr+$02c0,rscl,scr+$03c0,rscl
        dw    scr+$04c0,rscl,scr+$05c0,rscl,scr+$06c0,rscl,scr+$07c0,rscl
        dw    scr+$00e0,rscl,scr+$01e0,rscl,scr+$02e0,rscl,scr+$03e0,rscl
        dw    scr+$04e0,rscl,scr+$05e0,rscl,scr+$06e0,rscl,scr+$07e0,rscl

        dw    scr+$0800,rscl,scr+$0900,rscl,scr+$0a00,rscl,scr+$0b00,rscl
        dw    scr+$0c00,rscl,scr+$0d00,rscl,scr+$0e00,rscl,scr+$0f00,rscl
        dw    scr+$0820,rscl,scr+$0920,rscl,scr+$0a20,rscl,scr+$0b20,rscl
        dw    scr+$0c20,rscl,scr+$0d20,rscl,scr+$0e20,rscl,scr+$0f20,rscl
        dw    scr+$0840,rscl,scr+$0940,rscl,scr+$0a40,rscl,scr+$0b40,rscl
        dw    scr+$0c40,rscl,scr+$0d40,rscl,scr+$0e40,rscl,scr+$0f40,rscl
        dw    scr+$0860,rscl,scr+$0960,rscl,scr+$0a60,rscl,scr+$0b60,rscl
        dw    scr+$0c60,rscl,scr+$0d60,rscl,scr+$0e60,rscl,scr+$0f60,rscl
        dw    scr+$0880,rscl,scr+$0980,rscl,scr+$0a80,rscl,scr+$0b80,rscl
        dw    scr+$0c80,rscl,scr+$0d80,rscl,scr+$0e80,rscl,scr+$0f80,rscl
        dw    scr+$08a0,rscl,scr+$09a0,rscl,scr+$0aa0,rscl,scr+$0ba0,rscl
        dw    scr+$0ca0,rscl,scr+$0da0,rscl,scr+$0ea0,rscl,scr+$0fa0,rscl
        dw    scr+$08c0,rscl,scr+$09c0,rscl,scr+$0ac0,rscl,scr+$0bc0,rscl
        dw    scr+$0cc0,rscl,scr+$0dc0,rscl,scr+$0ec0,rscl,scr+$0fc0,rscl
        dw    scr+$08e0,rscl,scr+$09e0,rscl,scr+$0ae0,rscl,scr+$0be0,rscl
        dw    scr+$0ce0,rscl,scr+$0de0,rscl,scr+$0ee0,rscl,scr+$0fe0,rscl

        dw    scr+$1000,rscl,scr+$1100,rscl,scr+$1200,rscl,scr+$1300,rscl
        dw    scr+$1400,rscl,scr+$1500,rscl,scr+$1600,rscl,scr+$1700,rscl
        dw    scr+$1020,rscl,scr+$1120,rscl,scr+$1220,rscl,scr+$1320,rscl
        dw    scr+$1420,rscl,scr+$1520,rscl,scr+$1620,rscl,scr+$1720,rscl
        dw    scr+$1040,rscl,scr+$1140,rscl,scr+$1240,rscl,scr+$1340,rscl
        dw    scr+$1440,rscl,scr+$1540,rscl,scr+$1640,rscl,scr+$1740,rscl
        dw    scr+$1060,rscl,scr+$1160,rscl,scr+$1260,rscl,scr+$1360,rscl
        dw    scr+$1460,rscl,scr+$1560,rscl,scr+$1660,rscl,scr+$1760,rscl
        dw    scr+$1080,rscl,scr+$1180,rscl,scr+$1280,rscl,scr+$1380,rscl
        dw    scr+$1480,rscl,scr+$1580,rscl,scr+$1680,rscl,scr+$1780,rscl
        dw    scr+$10a0,rscl,scr+$11a0,rscl,scr+$12a0,rscl,scr+$13a0,rscl
        dw    scr+$14a0,rscl,scr+$15a0,rscl,scr+$16a0,rscl,scr+$17a0,rscl
        dw    scr+$10c0,rscl,scr+$11c0,rscl,scr+$12c0,rscl,scr+$13c0,rscl
        dw    scr+$14c0,rscl,scr+$15c0,rscl,scr+$16c0,rscl,scr+$17c0,rscl
        dw    scr+$10e0,rscl,scr+$11e0,rscl,scr+$12e0,rscl,scr+$13e0,rscl
        dw    scr+$14e0,rscl,scr+$15e0,rscl,scr+$16e0,rscl,scr+$17e0,hr2

[nocash]

Hero is using RAM at 4000h-FFFFh. The program code execution is all within 4000h-7FFFh. The "hr" function is at 477Dh (and portions mirrored/exectuted at C7xxh accordingly), one uncommon thing there is that the 32 dummy/drawing bytes have bit7 set as invert attribute, ie. 32 bytes with value 80h, instead of the more common 00h bytes. And the bitmap is at AEC0h.

The PSG sound was half removed for saving memory, and half because the PSG sound expansions appeared so rare to me that it wouldn't be worth to support them. Until recently I didn't even knew which I/O ports they there mapped to. I guess still don't know the exact mapping - the stuff I know of is this: http://nocash.emubase.de/zxdocs.htm#zx81soundexpansions (additions or corrections welcome!)

Until last weekend, I didn't knew about ZX-pand. Are the PSG chips still widely available? And its joystick port, is that a new feature, or was it supported by original ZON-X81, too (the original manual didn't seem to mention anything like that). The stuff I know about joysticks is this: http://nocash.emubase.de/zxdocs.htm#zx8 ... expansions yes, to make a greater mess, I've brewed up my own design there - it's dated back to before I knew about the other joystick adaptors, and it's still having a few advantages (hardware-wise it doesn't require any logic/drivers/decoders, just some wires, and software-wise it's almost same as reading cursor keys, except for two bits that must be read separately).

For RAM, I thought it'd be usually at 4000h and up, and that 2000h-3FFFh would be least common. Especially 2000h-9FFFh sounds odd, does that really exist? Is there a list of which expansions use which memory mapping?

[RetroTechie]

Beyond 16K RAM, there can be various schemes:

• An extra 8K in 2000-3FFFh, so you get continuous RAM from 2000-7FFFh (24K). There's various software that uses this, for example for storing machine code that survives a reset, or an alternate character set.
• An extra 8K in 8000-9FFFh, so you get continuous RAM from 4000-9FFFh (24K). Probably not as common & used as previous scheme.
• An extra 16K in 8000-BFFFh, so you get continuous RAM from 4000-BFFFh (32K). Possibly the most common way to arrange 32K. But personally I consider ZX81 software that needs 32K RAM (or more!), rare in general.
• And one could divide 32K over 4000-7FFFh and C000-FFFFh areas, with 8000-BFFFh having the normal ROM mirror. About as easy to decode as previous scheme, but probably very few RAM expansions work that way.

Of course other arrangements or full 56K RAM are possible. For example: suppose you have a 32K RAM chip tied to Z80 address lines A0...A14 and simply enable it for all Z80 addresses except the first 8K, then you'd get a memory map like this:

0000-1FFFh: ROM
2000-3FFFh: RAM
4000-5FFFh: RAM (regular 16K area)
6000-7FFFh: RAM (regular 16K area)
8000-9FFFh: RAM
A000-BFFFh: mirror of 2000-3FFFh area
C000-DFFFh: mirror of 4000-5FFFh area
E000-FFFFh: mirror of 6000-7FFFh area

In that configuration, you could use continuous RAM anywhere within 2000-FFFFh, just not more than 32K total. Where the DFILE can be and in what areas you could execute Z80 code, would depend on how it's decoded. The only safe area for Z80 code execution is the lower half (up to 7FFFh). Above that it may work with some RAM expansions, and be seen as DFILE execution with other expansions. Most expansions that have RAM in 2000-3FFFh, will likely allow placing the DFILE there, which would prevent Z80 code execution for A000-BFFFh area.

Is there a list of which expansions use which memory mapping?

Not that I know of, indeed this would be useful. For the ZXpand it's configurable I believe - see its manual.

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...

[kmurta]

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.

I ask humble apologies for my precipitation. I deleted the post to avoid further confusion