Page 1 of 1

bas2tap/tap2dsk bugs

Posted: Fri May 18, 2018 7:03 am
by ibisum

I've been working on getting the OSDK toolchain building cleanly on MacOS, and going through the tools one by one to start using them for my own Oric hacking purposes... one thing I've noticed is some odd behaviour with bas2tap that I'd like to verify/confirm is expected behaviour:

1. Short BASIC listings that are piped through bas2tap to produce a loadable .TAP file, seems to produce TAP files that take very, very long to load - i.e. unusually long, given that its just a 20-line BASIC program (assembly loader). Is this expected/current behaviour - that TAP files produced this way just take a long time to load?

2. If I leave a BASIC listing with an empty line-number at the end, i.e. just a line-number with no subsequent code on the same line, it seems to corrupt the BASIC listing entirely and results in spurious/unknown code being run once the Oric gets to those line numbers. In one case I had a 20 line BASIC listing with a very last "600 " at the end of the file, and when I loaded it and LIST'ed with the Oric, got random junk and garbage at line "62302", or whatever. I'd just like to confirm this is 'known and/or expected behaviour', before I get too worried about whether its a platform-specific (MacOS) bug in my local build of the tool.

3. tap2dsk, when I give it a command like this: "tap2dsk retro.tap retro1.tap retromaster.dsk", producers "retromaster.dsk", it seems, just fine. But when I load the .dsk in Oriculator (haven't tried Cumulus yet), I get a corrupted .DSK file. I'm okay with this result - after all, I'm still testing the builds on MacOS - but I was just wondering if anyone knows if the OSDK tools contain a valid method of validating the artefacts of things like tap2dsk/bas2tap? If there were some way to validate the results properly - i.e. reproducible DSK builds - I'd be happier. As it stands I'm not sure if my tap2dsk bin is valid or not - I suppose I'd need to get a Windows machine in my environment, build the OSDK with it and compare the production of artefacts between the two ports - but maybe there is a simpler way?

Anyway, I'm currently working on getting the OSDK working as a 'first class' toolchain on MacOS, so if anyone has other ideas/input/questions, I'm all ears. I hope to get the tools working that I need in order to continue my Oric hacking ..

Re: bas2tap/tap2dsk bugs

Posted: Fri May 18, 2018 8:52 am
by Dbug
I guess we could just extend the TestSuite with a few programs to test these cases. ... TestSuite/

The idea is the following:

:: The idea is to run each of the OSDK tools to generate a particular set of data,
:: and then check if the result matches a precomputed MD5.
:: If the result is the same, it means the version is correct (as far as the test suite is concerned).
:: If the results are different, it may mean:
:: - One of the tools is broken
:: - One of the tools generated data in an inconsistent way (it may not clean data correctly)
:: - One of the tools is inserting things that are run dependent (like a version number of time stamp)
:: - One of the tools may be generating more efficient things (like a more optimized compiler, or a better conversion algorithm for pictconv)
:: Whatever the result, it should be investigated before deploying a new version
:: In order to run this script, you have to make sure that the OSDK variable points to the set of tools you want to check

So basically in one mode we generate a set of MD5 for various operations that we know are correct, then when doing some code changes we can run in check mode to see if the MD5 has changed.

And yes, it's a batch file, so it only runs on Windows, but since this thing would only be ran by developers, I guess it could be rewritten to use something like a Python 2 compatible script so it can run on all versions

Right now only PictConv is checked, but it would be easy to add tests for BAS -> TAP, TAP+TAP+TAP - DSK, S -> BIN, etc... checking the various parts independently with a set of known programs.

The one important thing to remember is that the source HASH can change over time: A changed MD5 does not mean something is wrong, it means something has changed: For example the C compiler was optimized, or some initial value was modified.

Re: bas2tap/tap2dsk bugs

Posted: Fri May 18, 2018 9:03 am
by ibisum
Yeah, thats what I was headed for .. I guess the most productive thing for me to do would be to take the outputs of $OSDK/samples/*/BUILD/ as a first set of test data, and if artefacts from the MacOS build of the tools are produced with the same hash as those on the Windows side, we can settle the issue (or not).

At the moment I'm running everything in WINE in order to produce 'known good inputs', but I even am not so sure about that any more. Anyway, I'll consider adding artefact checks to the samples/ tree as another PR on the horizon ..