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.