ZOMBIES ATE OUR ROADIES!

[aerworuld]

The UEF file is a bit odd. It seems to include junk data at the end of each file block, so either my understanding of UEF files is incomplete or BeebEm is doing something strange. I can make a cleaned up version of the UEF if required.

It might just be the noisy sound file I converted it from. It seems to work ok despite the junk doesn't it?

[lurkio]

The UEF seems fine in BeebEm to me.

How can I tell if there's "junk data"?

[davidb]

I think the UEF probably works fine in emulators and on real systems. It's just that my tools tripped up on some of the data chunks. You need to dig around in the files themselves to see any issues.

I think BeebEm is adding two extra bytes to each data chunk after the CRC for the block of data itself. The emulators probably discard this, and perhaps the tools to play back UEFs as audio also do that, or maybe they generate audio but the computers ignore it. That's my interpretation of it, anyway.

Here's an example using the first data chunk from the LOADER program, encoded as a Python string where \x precedes non-printable characters, so \x00 is a null byte and so on:

Code: Select all

*LOADER\x00\x00\x0e\x00\x00#\x80\x00\x00\x00\x00\x00\x01\x00\x00\x00\x00\x00\x8c2\r\x00\x01% \xf4 ZAOR (TBIBMOTI) - INTRO SCREEN\r\x00\x02\x1d \xf4 A GAME BY STUART JOHNS\r\x00\x03! \xf4 www.AcornElectronToday.com\r\x00\x04' \xf4 ------- CASSETTE VERSION -------\r\x00\x05\n *TAPE\r\x00\n\x08 \xeb 4\r\x00\x14\x14 \xef 23,1,0;0;0;0;\r\x00\x1e\x12 \xef 19,1,0;0;  \r\x00(\x10 \xef 19,0,2;0;\r\x00-\x11 \xef 28,0,0,0,0\r\x002\x16 *LOAD ZAORCV 5800\r\x003\x0b*FX\xbeWWW

The last four bytes are &BE, &57, &57, &57 (\xbeWWW) but the CRC value is &57BE (little-endian) and the last two &57 bytes appear to be extra.

As I said above, it doesn't seem to cause problems with the emulators but I thought it was worth mentioning.

[aerworuld]

^^^ ghost in the shell! Most odd. If there's an awkward way to do something, I'll find it!