Add support for other Z80 CoPro ROM versions?

[rjpontefract]

I've been playing around with CPM, in particular the modifications to allow it to run from a hard disk from here https://mdfs.net/Software/CPM/Acorn/HardDrive/.

This only works with version 1.20 of the Z80 ROM which isn't currently offered in the menu in b-em.

Would it be possible to add other ROM versions to the tube menu? 1.20 would be most helpful for the hard disk support.

The versions I know of are 1.20, 1.21, 1.22, 2.00, 2.2c and 2.30. The ROM images can be found here: https://mdfs.net/Software/Tube/Z80/ZTUBEROM.zip

I can submit a pull request if it would help.

Thanks!

[SteveFosdick]

If you want to do this, check out the table of tube processors in model.c You could duplicate the current Z80 line towards the top of the table and replace the name of the ROM file in the 2nd from right column with v 1,20. Then put the file in the roms/tube directory.

I am not entirely sure what the difference are between 1.20, 1.21, 1.22 - I'll have a look.

[SteveFosdick]

It turns out version 1.20 is already in the roms/tube directory in b-em.

I also found the differences between 1,20 and 1.21 described by JGH: https://mdfs.net/Software/Tube/Z80/Patch121.txt

I assumed the HD BIOS was his creation too.

[rjpontefract]

I did see that 1.20 was already in b-em along with 1.22 and 2.00. JGH did create the HD BIOS and it only works with the version 1.20 or 1.21 ROMS. I don't see version 1.22 on mdfs.net and I don't know what it does differently to 1.20 and 1.21 other than not work with the HD BIOS.

BeebEM only provides version 1.20 and piTubeDirect has support for 1.21, 2.00, 2.2c and 2.30.

Do you see any benefit in adding some or all of these versions to the b-em menu? If that's not desirable, would making 1.21 the default version be useful so that it works with the HD BIOS?

Maybe finding out where 1.22 came from and what it does would be useful.

[rjpontefract]

I already have code locally that includes all of the different versions in the tube menu:

I can create a pull request, but I'd like your opinion on the best way to approach this.

[SteveFosdick]

On JGH not having a version 1.22, it turns out that was a version of 1.21 which I had further patched. There is some discussion at: https://stardot.org.uk/forums/viewtopic.php?p=247812#p247812

So this patch was to make the Z80 client ROM compatible with MOS 3.50, i.e. for the Z80 co-pro not to crash immediately on start-up when the host is running MOS 3.50, by not allowing the Z80 client in RAM to be overwritten via a tube transfer. The issue with MOS 3.50 is that the version of BASIC included can be relocated, so it loads into high memory on a second processor, i.e. it becomes the equivalent of HiBASIC. The complication is that, while you can refrain from having HiBASIC in the ROM configuration of a machine you use with a Z80 2nd processor, this relocatable BASIC is in the 1Mbit ROM of MOS 3.50 so it is always there.

JGH does say the CP/M BIOS needs to be able to overwrite the RAM copy of the client, but the non-HD version of the BIOS does not seem to be broken by 1.22 so, if there is any overwriting, it is presumably done from the Z80 side, not as a tube transfer from the 6502.

So reverting to 1.21 as the "one true Z80 client" would fix HD BIOS and break compatibility with MOS 3.50.

I will have a further look at what is going on to see if there is something that could be done that would work in both cases. In the meantime, another thought is that perhaps the set of "tubes" available should be in the config file in the same way as the set of models. Obviously a new processor type needs actual code and therefore there has to be an array of similar of those, but the config file could be used to allow different combinations of speed and client ROM.

[rjpontefract]

Happy to hear that you know the reason for 1.22 existing and look forward to seeing what solution you come up with for this.

[SteveFosdick]

The whole business of the Z80 client ROM, CP/M BIOS and the behaviour of the tube host on MOS 3.20 is a dogs dinner. With 1.22 it seems the BIOS was being loaded so it partially overlapped the RAM copy of the Z80 client ROM so the tail of the BIOS was being discarded, but nothing I tried used that bit so nothing went wrong.

Then, once I had disabled VDFS, it seems sector access via OSWORD &7F uses the 256-byte tube transfer that I had modified, but the Z80 BIOS uses OSWORD &FF instead, which it installs a handler for in the I/O processor. That, I think, maintains some sort of cache in the I/O processor. So the floppy-based BIOS worked fine with 1.22 as it didn't need to use that tube transfer.

The hard disk BIOS instead opens a file and uses OSGBPB to read/write sectors from the virtual disk that file represents. The filing systems would use the 256-byte tube transfer and the HD BIOS maintains some sort of cache in address space that is part of the RAM copy of the Z80 client ROM - space occupied by code that has been run once and won't be needed again.

So the BIOS and the Z80 client ROM are really too tightly integrated. For now, I have implemented a different bodge in b-em and put this on branch: https://github.com/stardot/b-em/tree/sf/z80rom This changes the preferred language ROM read from CMOS so if the Z80 is enabled it isn't one that relocates over the client ROM. This would enable the default ROM to be 1.21 which then seems to work fine with both the original or HD BIOS.

[rjpontefract]

That was quite some investigation you did there, thanks for the explanation.
I'll checkout the z80rom branch and give it a try.

Update: After a small battle with allegro and macOS Sonoma I'm happy to say that initial impressions are that it works fine. Thanks.

Another update: Unrelated to this issue, but the rebuild of allegro and b-em on Sonoma have made the F11 full screen functionality work correctly. Previously it would go to full screen but not return to a window. So now, I'm extra happy.