CD32-tools

[patrik]

In the repo

[SyX]

Originally Posted by jotd

BTW maybe you could host the CD32.TM/CDTV.TM python script from SysX in your github. I'm sure he'll be OK with that.

Of course, feel free of using/abusing any code that i have published.

[patrik]

Originally Posted by SyX

Of course, feel free of using/abusing any code that i have published.

Cheers!

[patrik]

@SyX:

Your script is now added to the cd32tools repo with the changes already discussed in the thread to get it working. Also made it use external trademark file so nobody complains.

[SyX]

Thanks patrick!

[patrik]

Originally Posted by jotd

Tell me when it's in the git repo and I'll adapt it. Now we have a full windows native toochain, not up to your standards in terms of boot speed, but still very convenient.

Actually, now with the fully working mkisofs-isos I retried the boot time. When I did the previous timing I was under the impression it created correct isos for me as it did boot and appeared to work fine.

However, it did not and this affected the boot time. We use ahx music in our menu and it looks in S:ahxWaves.location for the path to the precalc data and we have that data in S:ahx.waves. Our Startup-Sequence had uppercased first character in the name, with the result that the CD32 couldn't lock either of the ahx files leading to it precalculating it with the cpu, which normally should be slower than loading it from disc. However, with the mkisofs generated iso it apparently is slower reading from file :P.

We have also made one change to the CD, we now run "C:SetPatch QUIET" first in the Startup-Sequence. This makes the measurements a bit non-consistent with the previous. One insteresting thing with it is that it actually made the ISOCD-generated disc boot even faster than before. SetPatch says it patches a "cd CD_SEEK" function, maybe that is beneficial?

Also for fun tried a depth first sorting with the per-directory file sorting on upper case names manually removed and without prioritization list using generateLayout.py. Just guessing that that is something similar to the order of makeisofs.

Nevertheless, these are the current results.
Mkisofs: 17.88s
ISOCD with depth first, no per-dir filename uppercase-sorting: 17.34s
ISOCD with regular breadth first with our prioritization list: 11.64s

[jotd]

Ok, we can keep both solutions. The slow one will be for day to day builds to test on emulators, and the ISOCD one will be for releases.

[patrik]

Indeed, just wanted to update the numbers and was also a bit intrigued by the positive results by running setpatch. If anything, I expected it to get slower as it is one more command to execute. Did not expect it to go the other way.

[alpine9000]

Reviving an old thread, I tried this and it worked great!

Only issue I have is if I use CDTV.TM then I get an error when running pathTableUtil.py uppercase

(Works fine with CD32.TM)

PathTable size: 200
Traceback (most recent call last):
  File "../tools/cd32tools/pathTableUtil.py", line 230, in <module>
    pathTableLSB = PathTable(isoFile.read(descriptor.pathTableSize), True)
  File "../tools/cd32tools/pathTableUtil.py", line 175, in __init__
    entry.parent = self.entries[entry.parentNum - 1]
IndexError: list index out of range

[jotd]

ouch. It means that self.entries is empty. So long for the parent.... probably not trivial to fix.

Yes those tools are great to batch ISO production with mkisocdfs. Now StatMat ISOCDWin does a great job replicating ISOCD on Windows. Only the batch mode is missing.

[alpine9000]

I am guessing the problem is that the CDTV.TM is ~22kb whereas CD32.TM is exactly the block size (2048), which probably means that when make_cd32_iso.py patches it in it’s not quite right.

[girv]

Thread: Reanimate!

I had a dig at creating a CD32 ISO purely in Python 3, on macOS, with pycdlib and bits of make_cd32_iso.py from this thread.

I had to monkey patch pycdlib to skip ISO9660 filename validation so I could get "S/startup-sequence" on the image. Maybe this could be made into an option at some later stage.

The image seems to create OK and even boots the executable

The game can't read it's data files though. I can mount the image in macOS and copy the files off OK and the MD5's match up. In the code, I traced that Lock/Examine/OpenFromLock/Seek all work but the actual Read returns -1

I don't have a real machine with a CD-ROM so I can't really judge if the ISO is fast or slow to load, I think.

[jotd]

The absolute goal for me was to create a 100% compliant ISO file, no joliet, no fancy shit, so RN loader can read it and so CD32load works.

MasterISO, MakeCD,... all fail at this, ISOCD works (but is old & amiga-native), ISOCDWin does the job but has a, forced GUI, and ISO python tools using mkisofs that I got from Patrik & friends, used & improved (around 2016) create OK ISOs but if there are too many games, the lookup table is not well organized enough and the crawls on the real machine.

[girv]

The only part of mine that is not base ISO9660 is the startup-sequence filename, and I don’t see how you could avoid that?

I only have three game files, all loaded at the start, so I guess speed won’t be an issue if it’s just how the file system is organised that is the problem.

[jotd]

yes, in that case mkisofs stuff + python patches to insert TM file works perfect. I mastered Jim Power CD32 (commercial) with that and there are no issues. I would avoid it for big compilations.

[girv]

Were the differences between an ISOCD/ISOCDWin disc and the others ever explored? There can't be that much room for differences surely? Basic ISO9660 is quite straightforward.

[jotd]

A limitation in name lengths? case? Other ISO builders tend to add default extension options that conflicts with the implementation of at least RobNorthen CD loader (the only hardware banging CD32 loader I know of). So, cornercase, but this hardware banging CD32 loader (modified in CD32load to fix the "grinding" bug) is super-convenient to run games that you could not run on the (unexpanded) machine otherwise.

An example: Body Blows Galactic AGA that runs with CD32load, while at start it's a NDOS AGA game that uses most of the 2MB chipmem and uses RN floppy track loader. Jurassic park AGA is another. And Street Racer too.