xbas99 -d of INT/VAR 254 XB program fails to decode

[jedimatt42]

When I attempt to decode a long-format XB program it simply fails to decode or list. The docs for xbas99 say the long format is automatically detected.

python2 ./xbas99.py -d FILESYSTEM.bin
Warning: Cannot read program file

--long option only applies to create when reading the docs. Doesn't seem to do anything while decoding either. - had to try

xbas99-error.zip

Zip contains

• FILESYSTEM.bin which as the 128 byte TIFILES header removed.
• FILESYSTEM the original TIFILES format FIAD

[endlos99]

Thanks for your bug report!

I've had a look at the program file you supplied, and found something unusual about it:

$ hd FILESYSTEM.bin | head -n5
00000000 0a ab cd d0 97 d5 a6 05 31 ff e7 ff 00 00 00 00 |........1.......|
00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00000100 fe 01 44 e6 e5 01 43 e8 0c 01 42 e8 0f 01 41 e8 |..D...C...B...A.|
00000110 31 01 40 e8 47 01 3f e8 8a 01 3e e8 cd 01 3d e9 |1.@.G.?...>...=.|

There are more than >80 zero bytes at the beginning of the line number table, which throws off the decoding logic. How did you create this file?

[jedimatt42]

It came from Omega on Atariage. I don't know the file history. But remember, it is an INT/VAR 254 file, so...

0a : record length of 10
ab cd d0 97 d5 a6 05 31 ff e7 : data
ff : second record length - but ff indicates skip to next sector.

So those zeros are not a part of the data a disk controller read record would return.

The second sectors records look more typical...
fe : record length 254
....
ff : next record length indicating skip to next sector.

-M@

[jedimatt42]

So, if I extract the actual data from the record structure, join it all together and provide that data to xbas99 -d to skip your internal long conversion, would that be a worthwhile experiment?

[endlos99]

Oh, I see. What you should do then is this:

xdm99.py -F FILESYSTEM -o FILESYSTEM.dat
xbas99.py -d FILESYSTEM.dat

xdm99 should be able to do what you wanted to do; in fact, I somehow assumed this step already happened.

[jedimatt42]

Ah... ok,

1. that worked.
2. I didn't realize the 'plain' format when extracted still had record-len data, but doesn't have end of sector terminators...

I had only stripped the first 128 bytes off and mis-believed that was the same as your 'plain' file format for variable length record data.

This is probably the same problem Chris K. had as his change was trying to get around the 0xff's at the end of a sector.

Thanks, I will close this issue now - you should probably close Chris K. PR too.. his fork is gone, his fix shows hints at the same confusion as this, and his changes are more intrusive, changing the metaphor of your tools. ( My opinion )

Thanks!

[endlos99]

The plain format actually depends on the file type. For INT/VAR you get length bytes, for FIX you get padding, and for DIS/VAR you get newlines. :-)