EasyFlash, EasySDK, and EasyAPI

In the last couple of days I’ve been tinkering with Thomas ’skoe’ Giesel’s EasySDK code that he published here a while back.

I wasn’t able to find an example that would show how to embed the EasyAPI (EAPI) binary in a cartridge image, so I built one myself using Thomas’ existing examples. I also updated his EAPI test program to work with the latest version of EAPI, version 1.4.

My examples, along with a minimal SDK structure to build them, is now available on GitHub here.

Enjoy!

IFFL System for CMD FD2000

I’ve finally finished most of the work I was planning to do on the IFFL System: support for CMD FD2000 floppy disk drives is now available within the master branch of my GitHub repository.

Although I haven’t been doing heavy testing with CMD FD2000 drives, due to the fact I have to manually inject files into .d2m disk images, Commodore 1541 and 1581 drives were tested extensively so I would say my code provides a good starting point for those who want to use a production-friendly IFFL System 🙂

Have fun!

TAPClean updated

Those of you who closely follow the development of TAPClean might have noticed that I’ve been doing some improvement work on the code in order to address an excellent finding submitted to me by Ziggy72: The loader previously referred to as “Fast Evil” is, in fact, called “Jiffy Load” 🙂

Not only that, but Paul submitted titles that use two Tx variants of this loader, so TAPClean now supports “Jiffy Load T1” and “Jiffy Load T2”.

I am getting closer and closer to publishing an official release of TAPClean, but for those who want to compile and use the latest development version in conjunction with TAPClean Front End, you might want to change this line in scanners.txt:

0:fastevil:Fast Evil

into:

0:jiffy:Jiffy Load

Happy days!

IFFL System for Commodore 1581 drives

Today, with Lasse Öörni’s help and advice I finished all customizations required for my IFFL System to work with 1581 drives 🙂

At the moment the development for 1581 drives is in a separate branch of my GitHub repository. However, as is usual these days with this sort of tools, I will eventually combine the new branch and the master branch into a version that dynamically adapts itself to the disk drive in use, as long as it is supported.

For testing purposes I produced a version of my Barbarian II disk image as D81 file: it works absolutely fine 🙂

Although this is nothing new, I am sharing the source code of the IFFL System with those who are interested. I also plan to expand the documentation to make is simpler to use.

Stay tuned!

Further IFFL System updates

This afternoon I’ve updated my IFFL System repo on GitHub with a further example of usage that covers a different use-case compared to existing examples: using sprites while file loading is in progress.

Furthermore, I updated my IFFL version of “Barbarian II” to version 1.2, which should be the final one, hopefully. You might download it from here.
Again, if there is any interest from readers in seeing how this version is put together, I might publish all source code, data, and Makefile to build the disk image 🙂

The strange case of “Action Pack 2”

Recently Paul (Ziggy72) provided me with his tape dumps of “Action Pack 2”, which have been baffling me a good deal. They turn out to be excellent research material for a number of reasons, so here’s some insight on this case.

First of all, most titles on this tape use what appears to be an early, and very slow, variant of “Mega-Save”, which is now supported in TAPClean (since commit tag v0_37_pre_22) as “Mega-Save T4”.

The second thing worth mentioning is that there was a mastering error for “Z” on Side B. Long story short, when mastering the last turbo file to tape for this title, it looks like a typo was made at the execution address input.
Here’s a screenshot from the Mage-Save masterer itself, masterer that was submitted to me by Paul himself a while back when he found out that it is this tape masterer that recorded what were referred to as “CHR Loader” tapes:

Mega-Save masterer: execution address selection

Rather than 2304, i.e. $0900, I think the value 2404 was used, i.e. $0964, resulting in a JMP to the wrong execution address at the end of the load.
Realistically, this seems a case of typo as the chance that the byte $00 would be altered to $64, i.e. %01100100, at some time in between the mastering and the dumping process, are very slim.

BTW, the typo might have been significantly harder to make if the execution address input were to accept hexadecimal values instead of decimal ones 🙂

The issue had baffled me because the overall CRC-32 value computed by TAPClean on all files for this title from Side A and Side B was the very same. In fact, TAPClean does not compute CRC-32 values on the whole contents of a file (sync+header+payload+check byte+post data+…), but simply on the payload itself. As the execution address for this format is stored in the header section of turbo files, TAPClean is not useful to detect these differences using CRC-32 values. It was only when I decided to compare the report it generated for both sides that I spotted the issue:

Z: comparison of TAPClean’s report between Side A and B

I’ve now added an item to TAPClean’s TODO list to optionally extend the CRC-32 calculation to all bits of information in a file, albeit cases as the one above seem to be extremely rare for it to be an urgent change 🙂

IFFL System update

I’ve spent some time in the last couple of days reshaping my IFFL code so that it would be more flexible and allow easier use. In order to try the benefits of my changes, I thought to adapt my IFFL version of “Barbarian II” to use the latest code. At this point I discovered two issues:

1. The original tape loader loads a file at level 2 only partially: I was loading it fully, which caused the corruption of a few sprites when the female character is selected;
2. When I fixed point 1 above and rebuilt “Barbarian II”, I discovered that Cadaver’s addiffl tool overwrites entries in the “length table” whose length’s LSB is 0.

I now fixed the second issue too and published the fix on the relevant GitHub repository.

I will publish an update of my IFFL version of “Barbarian II” as well at some point. I think I might even publish the source code I use to build it if people were interested in this. It would be a great example application of the IFFL itself and of quite some help for somebody interested in converting games to disk for which the tape loader proves to be temperamental.

Stay tuned!