PRG to TAP: 1.5 release ready

I’ve checked the Turbo Tape utility that shows Stephan Senz Freiburg as author and I was able to confirm that there’s no silence written to tape between header and data blocks so I removed it in prg2tap 1.5.

Another thing I noticed is that the same utility resides at $C300 so it cannot load files past that address and it definitely does not do any bank switching for the BASIC ROM. Therefore it should be assumed that programs loaded by the utility should not go past the $a000 address. Regardless of that I decided to allow prg2tap users to encapsulate programs that extend past $a000 as a custom loader would be able to load data past that address anyway.

I should finally add that injecting data into the header part of a turbo file works absolutely fine on a C64 (the extra data is loaded into the cassette buffer). However, TAPClean does not expect that to happen.

Here’s the download link.

There’s still quite some work that I’d like to do on this tool, including producing a library, libtape (e for embedded), that would supersede libtapf and that I would be able to use verbatim in DC2N5 and PC apps 🙂

About Luigi Di Fraia

I am a Senior DevOps Engineer so I get to work with the latest technologies and open-source software. However, in my private time I enjoy retro-computing.
This entry was posted in Retrocomputing, Technical and tagged , , , , . Bookmark the permalink.

11 Responses to PRG to TAP: 1.5 release ready

  1. silverdrs says:

    Luigi – first the fact that the utility resides at $C300 and doesn’t do any “bank switching” doesn’t mean it can’t load beyond $A000. In C64 it’s the PLA that takes care of proper chip selection and there is no need to do any switching in order to do the write/load to RAM. Second – the most used variant of “Turbo Tape” is the “Turbo ROM”, which relocates itself under KERNAL address space and is therefore able to load up until $CFFF inclusive. The most sophisticated is probably the “Finaltape”, which also loads up to the same $CFFF. You shouldn’t base your utilities’ capabilities on limitations imposed by early implementations of Turbo Tape protocol. Other than that – keep up!

    • luigidifraia says:

      > doesn’t mean it can’t load beyond $A000

      The point I was trying to make is that the old implementation I mentioned does not save RAM under ROM beyond $a000 (even if it could be modified to do so) so you would not have programs previously saved by the same tool that load your own data past that address in RAM: Saving past $a000 would actually save ROM contents from $a000 onwards instead of your own data in RAM, without code modifications to the saver.

      > The most sophisticated is probably the “Finaltape”, which also loads up to the same $CFFF

      When I lifted the max address limitation in my tool for TT250 I was thinking that by having the loader (loader alone without the saver) partly at $0351 and partly at $02a7 or thereabout (a common arrangement in a number of fast loaders) it would be possible to load pretty much without worries (and autostart the turbo loader too).

      • silverdrs says:

        > the old implementation I mentioned does not save RAM under ROM

        I see. Now I understand. It’s just that we shouldn’t really look at it these days. Even in the mid-eighties nobody looked at it anymore, once the more effective variants popped up. If there is one variant to look at – it’s the Turbo ROM (preferably the variant with black-red striping during load).

        >I was thinking that by having the loader (loader alone without the saver) partly at $0351 and partly at $02a7 or thereabout

        Yes – loader can be placed in pages two/three when dealing with programs loading above it. Since majority loads at $0801 anyway – it works reasonably well. AFAIR (it’s been some time… 😉 “The Finaltape” does that when saving with autostart. Yet I still believe that clean “TurboROM” type of output with “250 blocks” limit i.e. the full RAM range up to $CFFF inclusive is what is going to be most useful and wanted.

        P. S. Are there any chances to get your utility compilable on non-Windows systems? Or does it heavily depend on Windows API?

  2. luigidifraia says:

    @silverdrs: What OS are you on? There hasn’t been anything Windows-only in my applications for a number of years now. I can build my commandline tools for Windows, Linux and MAC without any concern other than having to fire off a Virtual Machine for the last two 🙂

    > It’s just that we shouldn’t really look at it these days.

    That’s right. Mine is more of a tribute than a technical innovation 🙂

    • silverdrs says:

      I use both GNU/Linux and OSX on a daily basis. My primary OS is OSX although it’s becoming more annoying and less usable with each new version in the recent years.

      > Mine is more of a tribute than a technical innovation 🙂

      Well, I believe everything we do for those ancient machines is more of a tribute (and maybe some nostalgia) than anything else. Surely not much of a technical innovation 🙂 I do ROM adapters and floppy speeders for example. After some adaptations of the pre-exisitng ones, Now am developing a newer, faster one in my spare time. Won’t ever get any living out of it :-))

  3. Still doesnt get any turbo loader tap output when using -t. I even run your example command with the example.prg you provide in the binary.

    >prg2tap.exe -t -n “HELLO” example.prg example.tap

    PRG to TAP version 1 generator V1.5 – (C) 2016 Luigi Di Fraia
    Converts PRG to TAP using the CBM ROM loader or Turbo Tape 250

    PRG start: $0801
    PRG end+1: $081F
    PRG size: 30 bytes

    If I run it without -t I get the exact same output. I have also tried it on some of my own binaries with no difference in the output size or loader.

    • Ok I got it working now it seems although I see it doesnt figure out the SYS at the start of the prg I use. Ofc my prg isnt a binary on its own but has a basic bit at start that SYS into where the code is (just after the basic bits).

      • Lol obviously I dont get it, the tap file that the -t paramenter outputs clearly is shorter than the non turbo tape one – LOAD – RUN and nothing happens. Check Vice emulator memory around $0801 and there is nothing there. Checking with tapclean front end I see there is indeed two parts here, TurboTape250 header and TurboTape data block. Is there an issue with Vice 2.4 perhaps?

        TAPClean version: 0.32


        TAP Name : C:\Users\jcl\Dropbox\Private\prg2tap\main.tap
        TAP Size : 222752 bytes (217 kB)
        TAP Version : 1
        Recognized : 100%
        Data Files : 2
        Pauses : 1
        Gaps : 0
        Magic CRC32 : EAA673DF
        TAP Time : 0:50.11
        Bootable : NO
        Loader ID : n/a

        Overall Result : PASS

        Header test : PASS [Sig: OK] [Ver: OK] [Siz: OK]
        Recognition test : PASS [222732 of 222732 bytes accounted for] [100%]
        Checksum test : PASS [1 of 1 checksummed files OK]
        Read test : PASS [0 Errors]
        Optimization test : PASS [2 of 2 files OK]


        PAUSE (1)
        TURBOTAPE-250 HEADER (1)
        TURBOTAPE-250 DATA (1)


        File Type: PAUSE
        Location: $0014 -> $0000 -> $0000 -> $0017
        – Length: 328088 cycles (0.3330 secs)

        File Type: TURBOTAPE-250 HEADER
        Location: $0018 -> $2818 -> $2E18 -> $2E1F
        LA: $033C EA: $03FB SZ: 192
        File Name: TEST
        Pilot/Trailer Size: 10160/0
        Read Errors: 0
        Unoptimized Pulses: 0
        CRC32: 939B5637
        – Block type: HEADER (DATA is Binary) (ID=$02)
        – DATA FILE load address: $0801
        – DATA FILE end address: $6C00
        – Header size: 192 bytes

        File Type: TURBOTAPE-250 DATA
        Location: $2E20 -> $3E20 -> $35E20 -> $3661F
        LA: $0801 EA: $6C00 SZ: 25599
        Pilot/Trailer Size: 4016/2040
        Checkbyte Actual/Expected: $A3/$A3, PASS
        Read Errors: 0
        Unoptimized Pulses: 0

        CRC32: 570B1DA8
        – Block type: DATA (ID=$00)


        0x1A (198510)
        0x28 (24217)

  4. luigidifraia says:


    > LOAD – RUN and nothing happens

    There are not enough details here on the exact process you are following for me to advise, so let me show you my process in detail here.

    1) prg2tap.exe -t -n “HELLO” example.prg example.tap
    2) Load a Turbo Tape program in VICE 2.4 (nightly snapshot) – you can get the one I use from here:
    3) Get past the credits screen; type “<-L” and press RETURN
    4) VICE -> File -> Attach tape image… and select example.tap
    5) VICE -> File -> Datasette control -> Start
    6) After the load finished type RUN

    The concept to bring home here is that the file saved by prg2tap using TT250 is NOT standalone: it needs you to load a Turbo tape loader upfront (steps 2/3 above).
    That’s why in an earlier post I wrote that I am looking into getting together a process to use prg2tap to generate a CBM boot that autostarts and loads the Turbo tape section without the need to load a separate Turbo tape loader upfront. That’s also the reason why I added the option to append data to an existing TAP file, through multiple runs of the tool.
    Once I do that, the pipeline to produce standalone tap files that can be drag’n’dropped in VICE and just work will be complete.

    The process will look like this for a single file game:

    prg2tap -n “AWESOME GAME” -p turboloader1.prg turboloader2.prg awesomegame.tap
    prg2tap -n “GAME FILE” -a -t exomizedgame.prg awesomegame.tap

    The second run of the tool will simply append the turbo tape file to a bootable part that is loaded by the standard ROM loader.

    Why do I allow users to save a TT250 file without a bootable CBM part in front of them? Because the TT250 file might be a “level” file, i.e. something that is loaded by your own game/program upon completing a stage or choosing some option that needs to load code/data from tape.

    > I see it doesnt figure out the SYS at the start of the prg I use. Ofc my prg isnt a binary on its own but has a basic bit at start that SYS into where the code is (just after the basic bits).

    A BASIC boot is necessary for anything useful to happen at the end of the load when RUN is issued. If you follow the above mentioned process then at the end of the load you will be at the “READY.” prompt where you will be able to type RUN and be in business…

    I think you might be using my prg2tap tool with “tape masterer” expectations. Unfortunately unless you combine multiple runs of the tool and inject a custom turbo loader into the CBM ROM header and/or data block (which is an advanced user’s option) you don’t get anywhere near to a self-contained standalone TAP file.

    Once I will have put the pipeline in place with a custom turbo tape loader running in pages 2/3 then such expectations will be met and the last pass of your build process, after assembling, linking, exomizing, etc. could be a set of commands that built a standalone TAP file that simply works when drag’n’dropped in VICE. This is the real powerful feature of my PC version of the tool: allowing expert users to use their own tape loading system which might show bitmap graphics, playback music, read turbo tape files, and more. The possibilities are endless.
    Again, I will get one such loaders up and running myself for other people to use but it will be a simple one.

    • Ah ok I was under the impression this was packaged into a bootable tap. Sorry for the confusion.

      • luigidifraia says:

        Try this package:

        It includes a hacked Trilogic V3.2 loader that loads Turbo Tape 250 files without any practical limitation on the top of RAM it can load to. If you use the batch file provided within the archive then you end up with a bootable TAP file 🙂
        Just remember that the program you provide in place of example.prg must have a BASIC boot (e.g. it could be an exomized file) in order for this pipeline to work.

        Contents of the batch file:

        prg2tap -n “LOADER” -p turboloader1.prg turboloader2.prg mytape.tap
        prg2tap -n “PROGRAM” -t -a -s example.prg mytape.tap

        The first command creates a new TAP file, mytape.tap, and writes a standard CBM ROM file named LOADER that contains the hacked loader, mostly stored in the tape buffer, hence injected with the -p option. The loader is autostarted as well.
        The second command encodes example.prg into Turbo Tape 250 data, which is appended to the existing TAP file, using the -a option.

        Again, this is a proof of concept/hack, not a “production ready” turbo loader. I will certainly do some more work on it before releasing an official version.

        The TAP file generated by the batch file can be downloaded from:

        Have fun 🙂

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s