New Utility to Transfer Z80 Snapshot to +3 Disk

edited May 2019 in Development
Since getting a Gotek for my +3 it has been my go to machine. The biggest downside however is the lack of older games on disk format with pretty much everything 1986 and earlier missing. Although there are few compilations covering bits and pieces. I've been messing with a few of the utilities (tap2dsk, sna2dsk etc...) to transfer some of the older games to disk but haven't really found anything that works great, doesn't corrupt the screen or require a lot of tweaking to get to work. I've therefore decided to write my own and have finally got it working.

My utility currently utilises the popular z80 format (v1, v2 or v3) and basically re-compresses it and adds a custom loader so that it can be easily loaded on a +3. The custom loader is in MC and it uses the 3DOS ROM routines and RAM paging to load the snapshot from disk without any screen corruption including restoring all the registers as defined in the z80 snapshot. You can even add a loading screen if you want, which is compressed and added to the MC loader so it is decompressed at the beginning. Finding I can get between 5 & 6 48k games on one disk, obviously a few more if they are 16k ones. I use my LZF compressor for this, which is much better than z80 compression but it could be improved upon.

I initially just used the standard RAM pages but noticed some games still didn't work once loaded, often crashing. After a bit of messing about I found that swapping the +3 48k ROM with the original Sinclair one improved compatibility so I adapted my utility to use the +3 special mode which allows you to swap in another ROM (bank 4->ROM). This improved things with some games which I've never been able to get working on a +3, even via loading from tape in 48k basic, now working. It's not 100% though and some still don't work no matter what I've tried but these are in the minority.

I've called the utility Z80onDSK even though it currently only creates a tap with the files ready to be transferred to disk :-) I did that as I find it easier to transfer multiple games to one disk via tape in an emulator at the moment, although straight to disk is on my to-do list. Currently only works with 48k snapshots although I do plan to add 128k support.

At the moment the utility needs a bit of a tidy up before first release but I'll pop it on my website (and put a link here) once I've done which should be in the next day or two.

TomDD


Post edited by TomD on

Comments

  • I thought I had seen a similar utility before, but I was wrong. The old utility I was thinking of was a .SNA loader by John Elliot:

    https://www.seasip.info/ZX/spectrum.html

    There is a topic in this forum about game fixes/mods so older games can be loaded on the +2A or later models. Maybe you could try those modified games on your +3.

    I don't have a +3 anymore but it's great to see a utility like this. Thank you.
  • Congratulations, I got a large part of the way to achieving this (although with a tiny bit of screen corruption) with a branch of my Microdrive version, but never got around to finishing it!
  • RobeeeJay wrote: »
    Congratulations, I got a large part of the way to achieving this (although with a tiny bit of screen corruption) with a branch of my Microdrive version, but never got around to finishing it!

    Thanks, it was actually your Microdrive utility that gave inspiration to do this utility. I was using it to create the disks but found a few snapshots still didn't work so decided to make my own just for the +3 with the ROM swap.
  • v1 is now ready, hopefully no bugs but let me know if you find any. You can download it from my website tomdalby.com/speccy/Z80onDSK.zip
    Z80onDSK v1.0 (c) 2019 Tom Dalby
    -------------------------------------------------------------------------------
    usage: Z80onDSK input.z80 number [options]
      -s screen.scr add an alternate loading screen
      -m dump banks and compression to binary files
      -t create tap file with just the data (no basic) @ 16384
         this is useful for snapshots >40960bytes which cannot be loaded via
         basic which loads the code @ 24576. Use tap2dsk or similar to transfer
      -b1,2,3 use an alt mem location for 17byte run code, default 23734 (CHANS)
        -b1 @ top left of screen pixel area
        -b2 @ bottom right of screen pixel area
        -b3 @ space in Print Buffer (23296-23552). Program will scan for space
            (continuous block of zeros) if no space exists program will error
    -------------------------------------------------------------------------------
    
    In it's basic form to use the utility take any 48k Z80 snapshot and type:
    Z80onDSK snapshot.z80 1
    
    This will de-compress the z80 snapshot, re-order, re-compress and create a tap file called "1.tap". This tap file contains the converted snapshot, called "1", and a piece of basic code which, when run on a +3, copies the snapshot from tape to disk. You can use any number from 0-9 with the resultant file named after that number.

    The supplied dsk file contains the M/C loader routine, which you need, and a simple disk menu which I've just added in case anybody will find it useful, and as an example. I've gone with a generic loader rather than embedding it within the snapshot code as it was always my intention to use this for compilation disks, plus you always need a basic loader to launch the M/C anyway. To use the loader simply load it and then poke the file number in ascii to 32766. This is then read by the loader code to load the rest. Obviously the "1" code file needs to be on the same disk.

    A simple basic loader code would be as follows:
    10 CLEAR 32414
    20 INPUT "Game 0-9?",a
    30 LOAD "loader" CODE
    40 POKE 32766,a+48
    50 RANDOMIZE USR 32768
    
    In theory the loader will handle any single char (a-z,0-9) which means you could have up to 36 snapshots on each disk which should be enough unless you are using some kind of hard disk which I may cater for in a later release. At the moment the utility will only output numbered filenames although it is easy to rename them in 3DOS.

    The above work fine for most snapshots, however, there are some exceptions. To help with these, and make the loading look nicer, there are a few options:

    Alternate Loading Screen (-s screen.scr)
    As default the loader uses the z80 snapshot screen ($4000-$5b00) as a loading screen. This is often fine as many z80 snapshots have a pause screen after loading which just so happens to be the loading screen. Some however don't, or you might not like the one in the snapshot, so you have the option to replace it with another compressed screen with the original loaded in right before run time. This obviously adds to the total snapshot size.

    Large Snapshot Support (-t)
    As default the utility creates a tap file with some basic code which when run on a +3 saves the snapshot to disk. This has the downside that it can only work with snapshots <=40960bytes. For larger snapshots I've added an option to create a tap file with just the snapshot file, which will then need to be transfered to a disk using a utility such as tap2dsk. The maximum snapshot size for this method is 47907bytes which is 15969bytes for each bank ($4000-$7fff,$8000-$bfff,$c000-$ffff) and cannot be any larger due to the loader code.

    Alter small run code memory location (-b1,2,3)
    The final part of the snapshot loader code has the be placed within bank 5 ($4000-$7fff). This has to be somewhere that won't interfere with the running of the snapshot. I've got this code down to 17bytes and have found that putting this at the start of the CHANS memory area (23734) works in most cases, so made it default. If you find that doesn't work there are a few other options. The screen area ($4000-$5aff) is probably the safest but causes screen corruption which is why it isn't default. I've added two options for this which can help move the corruption around. The first is place the code at top left of the pixel area (1) and the second is to place it in the bottom right (2). Sometimes even that doesn't work so I added a third option (3) which pops the code in the printer buffer. For this I added a little scan routine which looks for a large enough space within the 256byte buffer. I will probably add a 4th option were you can specify the final place manually.

    Dump z80 banks (-m)
    Mostly used for debugging but I left it in just in case. Basically dumps the memory banks and final compression out to files.

    As mentioned v1.0 only works with 48k snapshots but will handle versions 1,2 or 3 of the z80 file format. 128k is on my to-do list but the focus here was always 16k & 48k games as it is these that are in shortest supply on disk. Currently my to-do list is:
    -128k snapshot support
    -create dsk files directly without needed tap
    -batch conversion of multiple snapshots straight to dsk
    -add 4th memory location option, user specified within $4000-$7fff
    -longer filename support for hard disks

    Let me know if you think anything else would be useful.

    For those interested here is a bit more information on how it works:

    The snapshot data file contains:
    -Registers, where to put the final run code and file lengths for the compressions
    -Compressed Loading Screen
    -Compressed Bank 0
    -Compressed Bank 2
    -Compressed Bank 5 (if loading screen is the snapshot screen this is only data from $5b00-$7fff)

    The strategy for loading the snapshot is:
    -Move the disk cache and RAM disk to bank 1 out of the way (set each to 2kB)
    -Open the Snapshot file via 3DOS
    -Load registers, where to put the final run code and file lengths for the compressions
    -Load Loading Screen and decompress to screen area
    -Patch the 48k Amstrad ROM to be a Sinclair 48k ROM and copy into Bank 4. This is done to improve compatibility with 16k & 48k snapshots and uses the +3s ability to use a custom ROM
    -Using bank 2 as a staging area (after the loader code)
    -Bank 0 is loaded & decompressed into bank 3
    -Bank 2 is loaded & decompressed into bank 6
    -Bank 5 is loaded & decompressed into bank 5
    -Close the Snapshot file and turn off the disk motor
    -Copy the 17byte run code to bank 5 (at address defined above)
    -Set most of the registers as per the Z80 snapshot
    -Jump to run code in bank 5
    -Switch into +3 special mode -> 4,5,6,3
    -Turn off further RAM paging
    -Set final few registers and execute JP PC

    The M/C loader is 703bytes long including the ROM patch code, all the 3DOS, bank switching, copy and decompression routines
    The Register etc... code at the beginning of the snapshot is 65bytes long
    The rest is the compressed RAM banks and screen

    TomD
  • One thing I found while writing this utility is that sometimes v1 Z80 snapshots won't work, even moving the base memory location doesn't help. However simply converting them to v3 (either by using an Emulator or the snapconv FUSE utility) fixes them and then they run fine. I'm not exactly sure why but it works.

    Also worth noting that this doesn't give you 100% compatibility with 16k & 48k games, some still just won't work no matter what you try and you will need to grab a fixed version. Try http://www.alessandrogrussu.it/plus2A-en.html for those

    TomD
  • Small update to v1.1 adding an additional option to adjust the position of the small run code to anywhere in lower memory, the ability to name the snapshot with any single alphanumeric character and a MAC OSX version. You can download the new version http://tomdalby.com/speccy/Z80onDSK_v1.1.zip.

    I've also pulled together a quick Q&A:
    (Q)Snapshot doesn't work
    (A)Try moving the small run code memory location. Default is 23734 so try within the screen area or printer buffer with options -b1,-b2,-b3 & -b4

    (Q)Still doesn't work
    (A)Some v1 snapshots don't work, not sure why. If it is a v1 snapshot try converting it to v3 using an emulator or the Fuse utility snapconv first

    (Q)Nope still doesn't work
    (A)It might be a bad snapshot. Try loading the tape version into an Emulator (48k machine selected) and saving a new snapshot

    (Q)Still not working should I give up
    (A)Some games just don't work on the Spectrum +3 so the answer is probably yes. However it might be worth trying different releases of the game (for example Hit Squad) which may have fixes. Also try Alessandro Grussu's website to see if there is a fixed version on there (http://www.alessandrogrussu.it/plus2A-en.html)

    (Q)The snapshot size for a 16k game is very large
    (A)Often 16k games where captured on a 48k machine which may have junk in the top 32k. If you can re-load via tape & re-capture the snapshot using an Emulator with 16k machine selected you should then get a nice small snapshot

    (Q)What is the easiest way to create a compilation disk
    (A)Until I get the batch processing working the easiest way is to create individual .tap files using the -t option (without basic part). Then combine them using DOS's "copy /b 1.tap+2.tap all.tap" command (or similar unix/mac) and then use John Elliott's utility tap2dsk to create the disk file (http://www.seasip.info/ZX/unix.html). I've included the loader code as a .tap file for this option so you'd put "copy /b loader.tap+1.tap+2.tap all.tap", then "tap2dsk -180 all.tap mydisk.dsk". As I've put a simple basic loader in the loader.tap it will autorun on a +3, catalogue the disk and then ask you to select a snapshot to load.
  • Batch mode is up and running, and also the ability to create a disk image so no more copying. Just a couple of things to add and I'll release v1.2 and the on to 128k snapshots!

    Ouput of it running below with the resultant imagine_001.dsk containing the loader code and all the snapshots.

    TomD
    PS R:\Converted> ./z80ondsk "Schizoids (1983)(Imagine)(16K).z80" -s "Schizoids.scr" "Ah Diddums (1983
    )(Imagine)(16K).z80" -s "AhDiddums.scr" "Alchemist (1983)(Imagine).z80" "Arcadia (1982)(Imagine)(16K)[a].z80" -s "Arcadi
    a.scr" -o arcadia "Jumping Jack (1983)(Imagine)(16K)[a][aka Leggit].z80" "Molar Maul (1983)(Imagine)(16K).z80" -s "Molar
    Maul.scr" "Stonkers (1983)(Imagine).z80" -s "Stonkers.scr" "Zip-Zap (1983)(Imagine).z80" -s "Zip-Zap.scr" -o zipzap "Zzo
    om (1983)(Imagine).z80" -s "Zzoom.scr" -o zzoom imagine_001
    
    -------------------------------------------------------------------------------
    Z80onDSK v1.2 (c) 2019 Tom Dalby
    +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
    Batch Mode Activated with 9 Snapshots Identified:
    1) Schizoids (1983)(Imagine)(16K).z80   [SCHIZOID]      [base=23734]    [altscreen "Schizoids.scr"]
    2) Ah Diddums (1983)(Imagine)(16K).z80  [AHDIDDUM]      [base=23734]    [altscreen "AhDiddums.scr"]
    3) Alchemist (1983)(Imagine).z80        [ALCHEMIS]      [base=23734]
    4) Arcadia (1982)(Imagine)(16K)[a].z80  [ARCADIA ]      [base=23734]    [altscreen "Arcadia.scr"]
    5) Jumping Jack (1983)(Imagine)(16K)[a][aka Leggit].z80 [JUMPINGJ]      [base=23734]
    6) Molar Maul (1983)(Imagine)(16K).z80  [MOLARMAU]      [base=23734]    [altscreen "MolarMaul.scr"]
    7) Stonkers (1983)(Imagine).z80 [STONKERS]      [base=23734]    [altscreen "Stonkers.scr"]
    8) Zip-Zap (1983)(Imagine).z80  [ZIPZAP  ]      [base=23734]    [altscreen "Zip-Zap.scr"]
    9) Zzoom (1983)(Imagine).z80    [ZZOOM   ]      [base=23734]    [altscreen "Zzoom.scr"]
    -> imagine_001.dsk
    +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
    1) Schizoids (1983)(Imagine)(16K).z80 -> Created code block ["SCHIZOID" CODE 16384,8866]
    2) Ah Diddums (1983)(Imagine)(16K).z80 -> Created code block ["AHDIDDUM" CODE 16384,18153]
    3) Alchemist (1983)(Imagine).z80 -> Created code block ["ALCHEMIS" CODE 16384,25018]
    4) Arcadia (1982)(Imagine)(16K)[a].z80 -> Created code block ["ARCADIA " CODE 16384,10222]
    5) Jumping Jack (1983)(Imagine)(16K)[a][aka Leggit].z80 -> Created code block ["JUMPINGJ" CODE 16384,7019]
    6) Molar Maul (1983)(Imagine)(16K).z80 -> Created code block ["MOLARMAU" CODE 16384,10740]
    7) Stonkers (1983)(Imagine).z80 -> Created code block ["STONKERS" CODE 16384,24141]
    8) Zip-Zap (1983)(Imagine).z80 -> Created code block ["ZIPZAP  " CODE 16384,17093]
    9) Zzoom (1983)(Imagine).z80 -> Created code block ["ZZOOM   " CODE 16384,18809]
    +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
    imagine_001.dsk file saved
    -------------------------------------------------------------------------------
    
    PS R:\Converted>
    
  • edited May 2019
    Ok v1.2 is up on my website http://tomdalby.com/speccy/Z80onDSK_v1.2.zip, both MAC OSX and Windows versions.

    As mentioned in my previous post this version has batch processing and the ability to create disks so no need for copying from tape anymore. It also has some bugs fixed most notably one with the Z80 decompressor which caused some issues with v1 snapshots (I said above I was having some problems with v1 snapshots, well it turns out it was my code!).

    Have also improved its functionality a little, such as being able to use full filenames now which is useful if you have a lot of snapshots on disk. Anyway more details below and if you have any questions or feedback please just shout.

    Now onto 128k...

    TomD
    -------------------------------------------------------------------------------
    Z80onDSK v1.2 for Windows (c) 2019 Tom Dalby
    -------------------------------------------------------------------------------
    Usage: Z80onDSK [global options] <snapshot>.z80 [snapshot settings] <name>
    
      <name>: output filename, if nothing specified z80 snapshot filename used
    
      [global options]
        -t: output to tape as well as disk
        -q: quiet mode, turn off all text output (other than error messages)
        -m: dump memory banks and full compression to binary files. These will
            named after the SPECTRUM filename
        -b: do not add autorun basic routine to disk, useful if you want to add
            your own loader routine later
        -h: make the loader code & autorun basic routine hidden on the disk,
            just makes things neater when cataloging the disk
    
      [snapshot settings]
        -o <name>: define SPECTRUM filename, if nothing is specified snapshot
                   filename used. Truncated to 8 chars with non-alphanumeric
                    & spaces removed to ensure PLUS3DOS compatibility
        -s <name>.scr: use an alternate loading screen. Must be a .scr 6912bytes
        -bN: use an alt mem location for 17byte run code, default 23734 (CHANS)
          1: @16384 (top left of screen pixel area)
          2: @22511 (bottom right of screen pixel area)
          3: @23296-23552 program will scan for continuous block of zeros
               in printer buffer, if no space exists program will error
          4 <mem>: @16384-32751 user specified memory location
    
      Batch Mode is activated if more than one z80 snapshot specified, example:
    
          Z80onDSK snapshot1.z80 snapshot2.z80 compilation1
            where "compilation1" is the filename of the resultant disk/tape file
            (if nothing specified the first snapshot name is used as above)
    
        each snapshot can have its own settings but options are global, example:
    
          Z80onDSK -q snapshot1.z80 -s screen1.scr snapshot2.z80 -b1 compilation1
              which runs in quiet mode, snapshot 1 has an alternate loading screen
              snapshot 2 has the run code located top left of screen pixel area
              all outputed to "compliation1.dsk"
    
        max 16 snapshots per disk/tape
    -------------------------------------------------------------------------------
    
    Post edited by TomD on
  • edited May 2019
    Am please to announce that I've got 128k working fine although it took a little longer than 48k to implement mainly due to the additional memory pages/banks which meant I had to come up with a new way to load in the compressed snapshot. For 48k the strategy was as follows:

    1) Patch 48k ROM and copy into page/bank 4
    2) Load compressed loading screen into page/bank and decompress to page/bank 5
    3) Load compressed page 0 into page/bank 2 and decompress to page/bank 3
    4) Load compressed page 2 into page/bank 2 and decompress to page/bank 6
    5) Load compressed page 5 into page/bank 2 and decompress to page/bank 5
    6) Switch to special mode which has page/bank 4 as the ROM then 5,6,3

    Page/bank 2 is used as a buffer and this worked fine, is very fast and other than 48k only it had a small limitation that each page/bank compression could only be max 15360bytes to allow enough room for the loader code in page/bank 2.

    Unfortunately this wouldn't work for 128k, unless it had limited use of the pages/banks, as there may be data in all the pages/banks so no room for a buffer. To get around this I re-wrote the decompression code so it decompressed on the fly from the data on disk. This meant I could decompress to each memory bank/page without the need for a buffer, it also removed the size limitation. The biggest downside of this change was speed as it is much slower than using a buffer. The new 48k strategy became:

    1) Patch 48k ROM and copy into page/bank 4
    2) Directly decompress loading screen to page/bank 5
    2) Directly decompress page/bank 0 to page/bank 3
    3) Directly decompress page/bank 2 to page/bank 6
    4) Directly decompress rest of page/bank 5 to page/bank 5
    5) Switch to special mode which has page/bank 4 as the ROM then 5,6,3

    and for 128k:

    1) Directly decompress loading screen to page/bank 5
    2) Directly decompress page/bank 0 to page/bank 0
    3) Directly decompress page/bank 1 to page/bank 1
    4) Directly decompress page/bank 2 to page/bank 2
    5) Directly decompress page/bank 3 to page/bank 3
    6) Directly decompress page/bank 4 to page/bank 4
    7) Directly decompress rest of page/bank 5 to page/bank 5
    8) Directly decompress page/bank 6 to page/bank 6
    9) Directly decompress page/bank 7 to page/bank 7

    The next question is where do you put the loader code plus a small area in page/bank 5 and page/bank 7 for system variables, the Stack & 3DOS. After a bit of experimentation I came up with the following strategy for 128k (48k is similar minus the extra banks and includes the patched ROM routine):

    1) Loader code placed at 24576 (0x6000) max size 1024bytes (this is the loader code and a small decompression buffer)
    2) Disable disk cache and RAM drive
    3) Directly decompress loading screen to page/bank 5 (0x4000 to 0x5aff)
    4) Directly decompress page/bank 0 to page/bank 0
    5) Directly decompress page/bank 1 to page/bank 1
    6) Directly decompress page/bank 2 to page/bank 2
    7) Directly decompress page/bank 3 to page/bank 3
    8) Directly decompress page/bank 4 to page/bank 4
    9) Directly decompress page/bank 6 to page/bank 6
    10) Directly decompress page/bank 7 (0xc000 to 0xdb00) to page/bank 7 (shadow screen only)
    11) Directly decompress page/bank 5 (0x6400 to 0x7fff) to page/bank 5
    12) Direct decompress page/bank 5 (0x5b00 to 0x5fff) to page/bank 7 (0xf700) 1280bytes
    13) Direct decompress page/bank 5 (0x6000 to 0x63ff) to page/bank 7 (0xe800) 1024bytes
    14) If required decompress original screen to page/bank 5 (0x4000 to 0x5aff)
    15) Turn off 3DOS (close file, turn off motor & disable interrupts)
    16) Move some last part of the loader code to very top of page/bank 7 and jump to there
    17) Copy page/bank 7 0xf700 1280bytes & 0xe800 1024bytes to page/bank 5

    As you can see this will not recover 100% of the Spectrum +3s memory but I can't see anyway around this on real hardware. So the compromise is every page/bank recovered minus the top of page/bank 7 which is used extensively for 3DOS anyway. This will unfortunately mean some snapshots won't work.

    My test 128k Z80 snapshots were Daley Thompson's Supertest 128k and Three Weeks in Paradise 128k. My initial design was to have one big file on the disk as 3DOS can stop and start as required. This worked fine for Three Weeks and it loaded fine. For Daley the resultant compressed file was over 64kB which although doable caused some strange results so I decided to split 128k snapshots into 2 files so they can never go over 64kB. Once I did this Daley loaded fine as well.

    I've tested a few other snapshots and it has a good success rate. If using the TOSEC or similar collection it may require that you re-do the snapshot (as I've also found for 48k) and I've also found that creating the snapshot after the loading screen works best as it avoids some of the start up checks or memory processing which may make it fail on a plus 3 even if you load from tape. I also added a check to see if no extra memory banks are used even if it is a 128k snapshot, maybe to get AY music, and it will attempt to create a 48k version but keep the AY music which saves a bit of space.

    Anyway I'm just packaging up the executables and will release it ASAP.

    Tom
    -------------------------------------------------------------------------------
    Z80onDSK v2 for OSX/WINDOWS (c) 2019 Tom Dalby
    -------------------------------------------------------------------------------
    Usage: Z80onDSK [global options] <snapshot>.z80 [snapshot settings] <name>
    
      <name>: output filename, if nothing specified z80 snapshot filename used
    
      [global options]
        -t: output to tape as well as disk
        -q: quiet mode, turn off all text output (other than error messages)
        -m: dump memory banks and full compression to binary files. These will
            named after the SPECTRUM filename
        -b: do not add autorun basic routine to disk, useful if you want to add
            your own loader routine later
        -h: make the loader code, autorun basic & 128k 2nd file visible on disk
            default is hidden to make things neater when cataloging the disk
    
      [snapshot settings]
        -o <name>: define SPECTRUM filename, if nothing is specified snapshot
                   filename used. Truncated to 8 chars with non-alphanumeric
                    & spaces removed to ensure PLUS3DOS compatibility
        -s <name>.scr: use an alternate loading screen. Must be a .scr 6912bytes
        -bN: use an alt mem location for 17byte run code, default 23734 (CHANS)
          1: @16384 (top left of screen pixel area)
          2: @22511 (bottom right of screen pixel area)
          3: @23296-23552 program will scan for continuous block of zeros
               in printer buffer, if no space exists program will error
          4 <mem>: @16384-32751 user specified memory location
        -fN: force machine type
          1: force 16k. If known 16k game then force clear top 2 memory banks.
             Checks stack and program counter and if in upper mem errors
          2: force 48k. Only banks 5,0 & 2 stored, retain AY chip & paging off.
             Useful for 128k snapshots with erroneous data in the extra banks
             which cause it to fail the automatic conversion
          3: force 128k. Overide automatic 128k-48k conversion if extra banks
             are blank. Will keep paging on with original Amstrad ROM.
    
      Batch Mode is activated if more than one z80 snapshot specified, example:
    
          Z80onDSK snapshot1.z80 snapshot2.z80 compilation1
            where "compilation1" is the filename of the resultant disk/tape file
            (if nothing specified the first snapshot name is used as above)
    
        each snapshot can have its own settings but options are global, example:
    
          Z80onDSK -q snapshot1.z80 -s screen1.scr snapshot2.z80 -b1 compilation1
              which runs in quiet mode, snapshot 1 has an alternate loading screen
              snapshot 2 has the run code located top left of screen pixel area
              all outputed to "compliation1.dsk"
    
        max 16 snapshots per disk/tape
    -------------------------------------------------------------------------------
    
    Post edited by TomD on
  • v2.0 now released, grab it here here

    TomD
  • TomD wrote: »
    As you can see this will not recover 100% of the Spectrum +3s memory but I can't see anyway around this on real hardware. So the compromise is every page/bank recovered minus the top of page/bank 7 which is used extensively for 3DOS anyway. This will unfortunately mean some snapshots won't work.

    I haven't tried, but I guess that you can load (almost) every byte of RAM accessing directly to floppy controller. The trick is that you must place every chunk of memory at known (fixed) places on disk.

    The downsides are:
    - Only one snapshot per disk.
    - You can not store snapshots in +2e/+3e hard disks/flash cards.
    - You can only copy your disks using disk copy (i.e.: COPY "A:" TO "B:" or du54 utilities), instead of copying only files.
    - It's more complex than accessing plain +3DOS.
    I was there, too
    An' you know what they said?
    Well, some of it was true!
  • edited May 2019
    Zup wrote: »

    I haven't tried, but I guess that you can load (almost) every byte of RAM accessing directly to floppy controller. The trick is that you must place every chunk of memory at known (fixed) places on disk.

    The downsides are:
    - Only one snapshot per disk.
    - You can not store snapshots in +2e/+3e hard disks/flash cards.
    - You can only copy your disks using disk copy (i.e.: COPY "A:" TO "B:" or du54 utilities), instead of copying only files.
    - It's more complex than accessing plain +3DOS.

    You would have to completely disable +3DOS and use custom disk access routines to do this, plus where would you run the code to do it and put the stack (if required)? I guess it is doable, maybe using the screen to run the code, but a ton of work plus I'm not even sure how many games use the top of bank 7. I think when writing this I only found Adams Family 128k which still worked but had some corruption in the title screen graphics.

    The big advantage of using +3DOS is, as you say, moving the snapshots onto hard disks or drive B: and having more than one per disk.

    TomD
    Post edited by TomD on
  • Yep, don’t talk to the FDC directly! People won’t thank you for it. There’s a reason Amstrad originally specced an API and subsequent endeavours have stuck to the API.
    Robin Verhagen-Guest
    SevenFFF / Threetwosevensixseven / colonel32
    NXtel NXTP ESP Update ESP Reset CSpect Plugins
  • v2.1 released with some bug fixes and a change regarding the forcing of machine type to improve compatibility. I found while making some compilation disks that games that seem to be 48k only but from circa 1985 and onwards sometimes seem to have code which checks for machine type and adjusts some timings etc.. This caused some games to not work when converted using my utility (Heatland) or to have terrible sound (Hypaball). I've therefore changed the -f3 and -f2 options to do the following:

    -f2 - force 128k to 48k. This forces a 128k snapshot to run as 48k but retains paging and the Amstrad 48k ROM. Before it was turning off paging and patching in the Sinclair 48k ROM.
    -f3 - force 48k to 128k. This forces a 48k snapshot to run as 128k. Before I had this as an option to stop the auto conversion of 128k to 48k but that made no sense so I've switched it. Heatland by Odin just didn't work until I added this option, it also fixes a lot of other games from 1985 and onwards. It still retains the 48k memory map of 5,2 & 0 but keeps paging on and the Amstrad 48k ROM.

    Anyway you can download the new version here https://tomdalby.com/speccy/Z80onDSK_v2.1.zip

    TomD
  • After reading about the +3s memory banks I've redesigned the 48k snapshot routine a little. My initial design patched in the SInclair ROM for 48k snapshots as default but while converting some games I've found the music was off. I didn't realise but it seems that using the special mode makes the upper memory contended (banks 3 & 6) which screws all the timings up. I've therefore flipped the default mode to be standard pages (2 & 0) but with bank switching off which improves compatibility a lot. I've kept the Sinclair ROM as an option but this really only helps with very old or 16k games which don't care about the upper memory being contended.

    I addition I've added a 2nd basic loader for disks with only a single snapshot on them so it autoloads it without having to type the name in. You can grab v2.2 here https://tomdalby.com/speccy/Z80onDSK_v2.2.zip
    ╔═══════════════════════════════════════════════════════════════════════════════
    ║ Z80onDSK v2.2 for WINDOWS (c) 2019 Tom Dalby
    ╠═══════════════════════════════════════════════════════════════════════════════
    ║ Usage: Z80onDSK [global options] <snapshot>.z80 [snapshot settings] <name>
    ║
    ║  <name>: output filename, if nothing specified z80 snapshot filename used
    ║
    ║  [global options]
    ║   -t: output to tape as well as disk
    ║   -q: quiet mode, turn off all text output (other than error messages)
    ║   -m: dump memory banks and full compression to binary files. These will
    ║       named after the SPECTRUM filename
    ║   -b: do not add autorun basic routine to disk, useful if you want to add
    ║       your own loader routine later
    ║   -h: make the loader code, autorun basic & 128k 2nd file visible on disk
    ║       default is hidden to make things neater when cataloging the disk
    ║
    ║ [snapshot settings]
    ║   -o <name>: define SPECTRUM filename, if nothing is specified snapshot
    ║              filename used. Truncated to 8 chars with non-alphanumeric
    ║               & spaces removed to ensure PLUS3DOS compatibility
    ║   -s <name>.scr: use an alternate loading screen. Must be a .scr 6912bytes
    ║   -bN: use an alt mem location for 17byte run code, default 23734 (CHANS)
    ║     1: @16384 (top left of screen pixel area)
    ║     2: @22511 (bottom right of screen pixel area)
    ║     3: @23296-23552 program will scan for continuous block of zeros
    ║          in printer buffer, if no space exists program will error
    ║     4 <mem>: @16384-32751 user specified memory location
    ║   -fN: force machine type
    ║     1: force 16k. Clears top 2 memory banks to remove erroneous data in upper
    ║        memory for 16k games. Helps reduce snapshot compressed size. If stack
    ║        or PC are in upper mem (>0x7fff) utility will exit with error.
    ║     2: force 48k + paging. Works on 128k & 48k snapshots. Only banks 5,0 & 2
    ║        are stored, retains paging & Amstrad ROM.
    ║     3: force 48k no paging. For 128k snapshots as this is default for 48k.
    ║        Only banks 5,0 & 2 are stored, paging off & Amstrad ROM in place.
    ║     4: force 48k old skool. Only banks 5,0 & 2 stored, paging off &
    ║        original Sincliar ROM patched in. Note this causes upper mem to be
    ║        contended which may cause issues with some games.
    ║
    ║ Batch Mode is activated if more than one z80 snapshot specified, example:
    ║
    ║     Z80onDSK snapshot1.z80 snapshot2.z80 compilation1
    ║       where "compilation1" is the filename of the resultant disk/tape file
    ║       (if nothing specified the first snapshot name is used as above)
    ║
    ║   each snapshot can have its own settings but options are global, example:
    ║
    ║     Z80onDSK -q snapshot1.z80 -s screen1.scr snapshot2.z80 -b1 compilation1
    ║         which runs in quiet mode, snapshot 1 has an alternate loading screen
    ║         snapshot 2 has the run code located top left of screen pixel area
    ║         all outputed to "compliation1.dsk"
    ║
    ║   max 16 snapshots per disk/tape
    ╚═══════════════════════════════════════════════════════════════════════════════
    
  • Utterly amazing... This is the sort of tool that makes me wish that I had kept my original +3 back in the day.. !!!
  • Zup wrote: »

    I haven't tried, but I guess that you can load (almost) every byte of RAM accessing directly to floppy controller. The trick is that you must place every chunk of memory at known (fixed) places on disk.

    The downsides are:
    - Only one snapshot per disk.
    - You can not store snapshots in +2e/+3e hard disks/flash cards.
    - You can only copy your disks using disk copy (i.e.: COPY "A:" TO "B:" or du54 utilities), instead of copying only files.
    - It's more complex than accessing plain +3DOS.

    I've managed to pretty much restore the entire memory without having to use a customer loader, it just corrupts part of the screen. Basically compress part of page 7 into screen memory and decompress once done loading. This does help get games like Rodland and Addams Family working.

    TomD

  • Update to v3.1. Utility now able to restore all the snapshot to memory (well other than the screen) giving much better compatibility especially for games like Adams Family 128k and Rodland 128k which use nearly all the available memory. You can download latest version https://tomdalby.com/other/z80ondsk.html

    TomD
  • edited October 2019
    I've had a few questions around how to transfer the created disks to a real 3" floppy disk (i.e. no Gotek). Easiest way is using an Amstrad FD-1 connected to a PC with SAMDISK but that is not an option for most so Z80onDSK does have the ability to create a TAPE file which can be transferred to a real disk using a Spectrum +3 and the following steps:

    - Create the tape version of the z80 snapshot using the -t option, for example "z80ondsk -t jsw.z80"
    - Pop a blank floppy into your Spectrum +3 disk drive and format it with FORMAT "A:"
    - Load the DISC & TAPE CONVERT utility https://www.worldofspectrum.org/infoseekid.cgi?id=0024047 from tape (use an APP or PC to do this)
    - Select option 2 & press 0 to start
    - Select Drive A and then press ENTER, then any key on the next prompt and it will then ask you to start the tape
    - Now load in each part of the snapshot tape (again using an APP or PC) and it will copy it all to the blank disk. 48k will have two files "loader" and "jsw", 128k three files "loader" and two "jsw" files.
    - Once complete reboot
    - Now we need to rename the file(s) on the disk. You should see a file called "jsw" or whatever you called the snapshot. This needs to be "jsw.0", it needs the dot and zero otherwise it won't load. Unfortunately it won't transfer the filename properly from tape so it has to be changed manually. The command to do this is MOVE "jsw" TO "jsw.0". If it is a 128k snapshot there will also be a "jsw.0" which needs to become "jsw.1" (do this first with MOVE "jsw.0" TO "jsw.1")

    Once this is done it should work, just needs a basic loader which is:
    10 CLEAR 24387
    20 LOAD "loader"CODE
    30 RANDOMIZE USR 25012
    

    Save this basic loader to disk using SAVE "DISK" LINE 10 and it will autorun from the main menu.

    If you've created a compilation then there will be multiple files on the tape, just copy them all across and do the renaming as above. The loader will automatically check if there is more than one snapshot to load and use the menu if needed.

    TomD
    Post edited by TomD on
  • Seems there is an even easier way using a utility called dsk2tap http://www.seasip.info/ZX/unix.html. Works much better as no renaming etc... Thanks to Mark Edwards for pointing this out

    TomD
  • Small update fixing a crash bug, grab the new version here http://tomdalby.com/other/z80ondsk.html
  • v3.4 uploaded which fixes a filesize >64k crash bug. Windows only for now till I boot up my Mac. http://tomdalby.com/other/files/Z80onDSK_v3.4.zip

    TomD
  • Loved your 3.3a version, which worked wonderful for my old Windows XP 32bit setup... Any chance of distributing the source code for your 3.4 version or recompiling a version that works on older machines like mine?...:)
  • kgmcneil wrote: »
    Loved your 3.3a version, which worked wonderful for my old Windows XP 32bit setup... Any chance of distributing the source code for your 3.4 version or recompiling a version that works on older machines like mine?...:)

    I've compiled it for XP and added to the archive, can you please try it out and let me know if it works ok
    http://tomdalby.com/other/files/Z80onDSK_v3.4.zip

  • Downloaded and tested!... Thank you so much for thinking of us XP techno-peasants!... Your gesture is much appreciated!... Its a wonderful tool and works really well on the samples I used if for - thanks for continuing to update it!... :)
  • v3.4b uploaded which fixes a bug where v2 48k Z80 snapshots didn't work due to out of order page layout.

    http://tomdalby.com/other/files/Z80onDSK_v3.4b.zip

    TomD
Sign In or Register to comment.