bas2tap/tap2dsk bugs
Posted: Fri May 18, 2018 7:03 am
Hi,
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 ..
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 ..