Any emulators able to pause on completon of loading?

[SkoolKid]

Not surprisingly, the other games in the Wally Week series all do post-LOAD RAM checks. Here's how to take a snapshot after the check for each one:

Code: Select all

tap2sna.py --start 65274 https://worldofspectrum.net/pub/sinclair/games/a/Automania.tzx.zip
tap2sna.py --start 65292 https://worldofspectrum.net/pub/sinclair/games/e/EveryonesAWally.tzx.zip
tap2sna.py --start 65292 https://worldofspectrum.net/pub/sinclair/games/h/HerbertsDummyRun.tzx.zip
tap2sna.py --start 65290 https://worldofspectrum.net/pub/sinclair/games/t/ThreeWeeksInParadise48.tzx.zip

[8BitSC]

Oddly, only two of the above resulting z80 files will convert using Tom's Z80onMDR tool. The other two produce errors, even though the z80 files produced by tap2sna.py will load on OqtaDrive perfectly well.

I say oddly, because the z80 import code in OqtaDrive is (If I read correctly) based on Tom's Z80onMDR code?!

Here's the output I get from trying to convert the Herbert's Dummy Run Z80 file to MDR:

Code: Select all

+-------------------------------------------------------------------------------
| Z80onMDR v3.0 (c) 2020 Tom Dalby
+-------------------------------------------------------------------------------
| Single Snapshot Mode: "Herbert's Dummy Run.z80"
| Microdrive Cartridge Name: "HerbertsDu" -> Total Space 127kB, Sector Gap 1
| Single Snapshot to transfer, no menu required just run file
| - Writing File: "run       " (BASIC A:10 L:38) #Sectors Used:1
+-------------------------------------------------------------------------------
| Processing: "Herbert's Dummy Run.z80"
| - Options:
|   - Screen: Default from Snapshot
|   - Filename: Default, From Input
|   - Default, 4 Stage Launcher
| "Herbert's Dummy Run.z80" [46966bytes]
| Z80 Snapshot Decode: [v3(54)-48k]
+-----------------+---------------+---------------+---------------+-------------
| a=0xfb	  | f=0x6a	  | bc=0x0000	  | hl=0xff24	  | pc=0xff0c
| sp=0x0000	  | i=0x3f	  | r=0x6f	  | bcol=7	  | de=0x00fb
| bc'=0x8000	  | de'=0x369b	  | hl'=0x2758	  | a'=0x7f	  | f'=0x6d
| iy=$5c3a	  | ix=$ff25	  | di		  | im 1	  |
+-----------------+---------------+---------------+---------------+-------------
| AY Chip Registers Set-up        | 0xfffd=0x00	  | ay1=0x00	  | ay2=0x00
| ay3=0x00	  | ay4=0x00	  | ay5=0x00	  | ay6=0x00	  | ay7=0x00
| ay8=0x00	  | ay9=0x00	  | ay10=0x00	  | ay11=0x00	  | ay12=0x00
| ay13=0x00	  | ay14=0x00	  | ay15=0x00	  | ay16=0x00	  
+-----------------+---------------+---------------+---------------+-------------
| Extracting Pages from Z80:
*ERROR: page number issue with 48k valid 4,5 or 8: 254
[E06]
| - 5(14103) 2(16386)

OqtaDrive itself will load the z80 file and convert it to a working MDR file, if I select the z80, load it onto the real 48K speccy and then export/save it locally as an MDR from the OqtaDrive web-interface.

[TomD]

I say oddly, because the z80 import code in OqtaDrive is (If I read correctly) based on Tom's Z80onMDR code?!

It is but I created a different version to use in my own Microdrive project (https://github.com/TomDDG/ZXPicoMD) which Alex ported to Oqtadrive. I needed a lite version which was able to run quickly on limited hardware, such as a Pico or Raspberry Pi Zero, so created a version with a more simplistic, and much faster, compressor. I also removed all the options including ability to create compilations, you can check out the lite version here https://github.com/TomDDG/Z80onMDR_lite.

Anyway this is either a bug in the original Z80onMDR which I fixed in the lite version and forgot to back port, or something is up with the Z80. I'm going with the former as the Z80 works fine with Z80onMDR_lite and also loads into emulators. I will investigate but if you don't need compilations or any of the extra options such as replacing the loading screen, please just use the lite version or the on fly conversion.

TomD

[8BitSC]

Hi @TomD

Thanks for confirming it’s a bug.

As I’m primarily focusing on 1 game/1 mdr, I’ll try the Lite version later.

BTW, I also own one of your ZXPicoMD devices and it (like OqtaDrive) will load some protected images, which the vDriveZX won’t load. A truly excellent product.

Thanks for making your OqtaDrive PCBs available too. It’s due to your boards, I’m enjoying messing around with OqtaDrive just now.

[TomD]

BTW, I also own one of your ZXPicoMD devices and it (like OqtaDrive) will load some protected images, which the vDriveZX won’t load. A truly excellent product.

Thanks for making your OqtaDrive PCBs available too. It’s due to your boards, I’m enjoying messing around with OqtaDrive just now.

No problems and thanks for the feedback out of interest what protected images are you working with? My guess on why these don't work on vDriveZX is that Oqtadrive and ZXPicoMD both just stream the data with the same order, timings etc... as a real Microdrive and I think vDriveZX manipulates the stream to speed up loading. Not 100% on that as vDrive is closed source but I ran some tests for somebody once that took a long time on real hardware, Oqtadrive and ZXPicoMD, but ran very quickly on a vDriveZX.

On the bug I've found and fixed it, will pop the new version on my website later. It was a very simple bug to do with how a Z80 snapshot compresses each of the 16kB memory banks. In Herbert's Dummy Run it can't compress some of the banks so they end up being >16384 bytes long (16386bytes). In Z80 snapshots you can switch off compression (no idea why you would) and originally this was indicated by having a memory bank stored in exactly 16384bytes. However this was changed in v2 & 3 of the Z80 standard which SkoolKit generates. My original code incorrectly just checked for >=16384 thinking that would indicate an uncompressed block, basically didn't distinguish between v1 and v2+ snapshots. It should have checked for 0xffff on a v2+. I'd already changed this in my lite version but just forgot to do it on the older code. These compression issues are rare as most compress to <16384, I've only really seen it on games which have compressed code already Codemaster ones spring to mind.

TomD

[8BitSC]

Out of interest what protected images are you working with? My guess on why these don't work on vDriveZX is that Oqtadrive and ZXPicoMD both just stream the data with the same order, timings etc... as a real Microdrive and I think vDriveZX manipulates the stream to speed up loading. Not 100% on that as vDrive is closed source but I ran some tests for somebody once that took a long time on real hardware, Oqtadrive and ZXPicoMD, but ran very quickly on a vDriveZX.

IIRC, It's an MDR image of TransExpress 85.2 which works on ZXPicoMD and OctaDrive but won't load at all on vDriveZX and I think the other one was uMate (MicroMate).

Also, I just noticed you've uploaded v3.1 of Z80onMDR to your site already but there's No MacOS binary included this time?

[TomD]

Also, I just noticed you've uploaded v3.1 of Z80onMDR to your site already but there's No MacOS binary included this time?

Mac version added.