Mclaneinc Posted August 29, 2019 Share Posted August 29, 2019 Hi there folks, I was just playing with some .bas files on Altirra (the ability to boot bas files directly is brill) but loads of them were giving me error 137, now I'm 100% sure its nothing to do with Altirra or its settings, so I'm trying to find out if these files can be fixed or if I'm doing something wrong here. The old brain cells don't recall this error and looking it up got a truncated record explanation but no clue as if the files are nak'ed. Cheers.. Quote Link to comment Share on other sites More sharing options...
_The Doctor__ Posted August 29, 2019 Share Posted August 29, 2019 (edited) make sure the BASIC listings have not had the ATARI EOL character stripped like some OCR and WINTEL editors do... post the files, only way we can know what is happening... copy the files to a DOS 2.5 disk and load them that way... sounds like it's truncated, that can be a program that is sent from a source file that was stripped of the Atari end of line character or is looking to use DOS in some way.... The Atari O.S. supports two main types of I/O procedure: byte oriented and record oriented. With byte oriented transfer, you specify the memory location where the data to be transferred is located (output) or where it is to be stored (input), and the number of bytes to be transferred. The operation continues until the specified number of bytes is moved or the end of the file is reached. If you are inputting data and you have not reserved a large enough area (buffer) of RAM for the incoming data, then data input is not halted - it just overwrites whatever follows the buffer (program lines, screen memory etc.). In record oriented transfer, input or output only continues until an ATASCII end-of-line (EOL) character is reached. If on input your allocated buffer size is exceeded before an-EOL is reached only part of the data is input and this error is returned, indicating that the record is truncated. The BASIC command for record oriented input is INPUT . When using this command, BASIC allocates a maximum buffer of 119 bytes (DOS 3 reference). If you use INPUT to read a file created using byte oriented transfer (PUT in BASIC) you may run into this error as well. Edited August 29, 2019 by _The Doctor__ Quote Link to comment Share on other sites More sharing options...
Mr Robot Posted August 29, 2019 Share Posted August 29, 2019 I've found a lot of the bas files you see in collections are corrupt. I wrote a bit of python to convert .bas to .html and it chokes on invalid files. In every case if I found a working .atr of the same software and extracted the .bas out of it and compared to the .bas I already had in a hex editor you can see the corruption clearly. post a few of the bad ones. Quote Link to comment Share on other sites More sharing options...
Mclaneinc Posted August 29, 2019 Author Share Posted August 29, 2019 Here's a few, Altirra basic shows them as error 137, I've tried making a disk and running then the old fashioned way, no joy... Kubert (b).bas Kung-Fu Master (b).bas Smash (b).bas Space Way (b).bas Quote Link to comment Share on other sites More sharing options...
vitoco Posted August 29, 2019 Share Posted August 29, 2019 They are neither Atari BASIC nor TurboBasic XL tokenized files. If they are old enough, I don't think Altirra Basic could open them. I haven't tried other BASIC flavours, BTW... Quote Link to comment Share on other sites More sharing options...
_The Doctor__ Posted August 29, 2019 Share Posted August 29, 2019 (edited) kubert... get the file version from homesoft... it is an xex might be these are a part of kemals broader games package.... it's unlikely that these would be patch makers for those games. Edited August 29, 2019 by _The Doctor__ Quote Link to comment Share on other sites More sharing options...
Mclaneinc Posted August 29, 2019 Author Share Posted August 29, 2019 (edited) Initially I thought that they were miss named files but that didn't work out hence the question on here...Making me wonder if another system also uses the same extender and they have been collected together by mistake... Thanks for looking guys... Update.....Can't find any systems that use .bas files and after looking through some files with HxD I noticed there were obvious Atari references like like D1:Pharoah as the last few bytes at the end of the file. I also found one file as a .bas on Atarimania called Adventure of the Dancing Dragon (The) but theirs ran perfectly. I've also noticed that all the files which a playing up have a mixed upper and lower case name ie not the 8.3 names they would have had so I wonder if they were just renamed by hand or had something else done as well. Blooming weird is all I can say... Edited August 29, 2019 by Mclaneinc Quote Link to comment Share on other sites More sharing options...
vitoco Posted August 29, 2019 Share Posted August 29, 2019 Well, I've found what is happening... They ARE Atari BASIC tokenized files, but downloaded to the PC using ASCII mode (with CR/LF convertion) instead of BIN mode, so every 0x0D byte was removed, and the final BAS file has less bytes than the original. That's why you are getting the error number 137: truncated file!!! 2 Quote Link to comment Share on other sites More sharing options...
Guest Posted August 29, 2019 Share Posted August 29, 2019 (edited) i was just going to say similar ^ they're definitely atari compatible (in some way) because - when saving them to ATR and writing to real disk, and then from run "d:******.bas" command on a real 800XL they all load and return to a READY prompt. from load "d:******.bas" command on a real 800XL they all load and return to a READY prompt and typing RUN results in another READY. Edited August 29, 2019 by Guest Quote Link to comment Share on other sites More sharing options...
Mclaneinc Posted August 29, 2019 Author Share Posted August 29, 2019 Aha...Thank you Vitoco for doing the research, I'd never have figured that much out... Sigh....I'll round them up and go looking for workings non screwed versions... Again, thank you and all who helped.. Quote Link to comment Share on other sites More sharing options...
Sikor Posted August 29, 2019 Share Posted August 29, 2019 Kemal Ezcan (aka Yoda Zank) programs - copy it to screen. All is available in xexs. Oryginally was written (probably) in Turbo Basic XL and protected to list it. Quote Link to comment Share on other sites More sharing options...
_The Doctor__ Posted August 29, 2019 Share Posted August 29, 2019 (edited) try the old right click save file as method of download if in a form not using compression like zip etc..... from your browser.... if it still is stripped (as mentioned in my first post in this thread)... advise whatever archive of the issue... since a zip file is how most deliver the files, it may be the problem exists before the zip... Edited August 29, 2019 by _The Doctor__ Quote Link to comment Share on other sites More sharing options...
Mr Robot Posted August 29, 2019 Share Posted August 29, 2019 @vitoco got it right, they are BASIC files but all the 0D bytes have been removed. I only checked a couple but I've found this in my own files as well I suppose these corrupt files are in TOSEC or something. Quote Link to comment Share on other sites More sharing options...
_The Doctor__ Posted August 29, 2019 Share Posted August 29, 2019 (edited) Atari Disk Explorer will de tokenize the file... Atari Disk Explorer Setup.zip atascii view... should allow you to load as ascii and resave as atascii and vice versa there are a few other that handle the return linefeed end of line issues as well... if I am not mistaken at last count there are 4 such programs that claim to do so... have at it... Edited August 29, 2019 by _The Doctor__ Quote Link to comment Share on other sites More sharing options...
Mr Robot Posted August 29, 2019 Share Posted August 29, 2019 (edited) BAS files are tokenised. They aren't straight ATASCII. Edited August 29, 2019 by Mr Robot Nice edit to correct there, doc! Quote Link to comment Share on other sites More sharing options...
_The Doctor__ Posted August 29, 2019 Share Posted August 29, 2019 (edited) might want to wait a couple minutes for a person to add the needed software to the post. not that it will work, as I didn't specifically have time to test it all. Heck I barely have time to find it and make/edit posts before folks are all over it. Be nice if they just posted the tools themselves though... I suspect they have it all and are way quicker than I will be these days. or just download from homesoft etc as mentioned. all the assessments were pretty much more or less the same thing... but... what if the programs weren't easily found, or not in anyones' archive apart from the messed up versions? Then you can attempt to detokenize and run it through the different converters. Or maybe just have your favorite tool add the stripped back followed by a manual debug. In any event many avenues to take. More than one way to de tokenize and more than one way to convert cr lf eol. so again, I say have at it. be interested to see how attempts to fix programs mangled this way fair, and possible examples of what the results were sort of posts. will it all end badly? Probably... but I bet there is a method to do so more or less by direct intervention and then processing or some other order of process... Edited August 29, 2019 by _The Doctor__ Quote Link to comment Share on other sites More sharing options...
Mr Robot Posted August 29, 2019 Share Posted August 29, 2019 I haven't come across any so far that only exist as a mangled BAS. So far here has always been an ATR with the BAS on it as well. Quote Link to comment Share on other sites More sharing options...
Mr Robot Posted August 29, 2019 Share Posted August 29, 2019 12 minutes ago, _The Doctor__ said: Be nice if they just posted the tools themselves though... I suspect they have it all and are way quicker than I will be these days. I am a mac user, almost all the tools I use are written by me in python because no one likes macs here. I don't have any tools to post. Quote Link to comment Share on other sites More sharing options...
_The Doctor__ Posted August 29, 2019 Share Posted August 29, 2019 (edited) But I always get corrected that it runs under wine.... or bottler or some such thing (My MAC days ended early) I really liked the A2GS etc. though Edited August 29, 2019 by _The Doctor__ Quote Link to comment Share on other sites More sharing options...
Urchlay Posted August 29, 2019 Share Posted August 29, 2019 There's 2 types of CR/LF mangling that can occur. The "error 137" files have all the $0D bytes removed, and I've found a few in the Holmes archive that have an extra $0D after every $0A in the file. Recovering the second type might be possible, since tokenised BASIC has a well-documented format with some internal redundancy: line length bytes, plus statement length, plus the fact that the line numbers will always be in ascending order, etc. All the information is there in the file, a recovery tool would just have to figure out which $0D bytes are extras. Recovering the first type might be possible, with a brute force algorithm. Just find the spots where the token structure breaks, and start inserting/removing $0D bytes at every position until you get something that makes sense... How do these broken files end up preserved in archives like Holmes or TOSEC anyway? Nobody bothers to check & see if they even run, before adding them to the archive to be preserved for all time? 3 Quote Link to comment Share on other sites More sharing options...
_The Doctor__ Posted August 29, 2019 Share Posted August 29, 2019 (edited) I'd think that's the case... I know even when archivists check before uploads to their sites they don't always download and check right away to make sure something obscure doesn't happen to muck up the works... I think such a thing happened to savetz... I'm sure it was eventually tracked down... but I think some hair pulling happened before the mystery unfolded... Edited August 29, 2019 by _The Doctor__ Quote Link to comment Share on other sites More sharing options...
Mr Robot Posted August 29, 2019 Share Posted August 29, 2019 (edited) 9 minutes ago, Urchlay said: Nobody bothers to check & see if they even run, before adding them to the archive to be preserved for all time? Exactly that And once in one archive (say an old one like Holmes) they get taken and added to newer archives, (like say TOSEC) and still no one checks to see if they work. People who aren't experienced Atari users do the collating as well so you get stuff like (for example) people who didn't know the difference between .CAR and .BIN files assumed they were the same and now there are lots of .CARs renamed to .BIN. There are also lots of .LST files with .BAS extensions for the same reasons. Edited August 29, 2019 by Mr Robot I didn't know for sure who did that so I removed the accusation it was someone specific. Quote Link to comment Share on other sites More sharing options...
Mr Robot Posted August 29, 2019 Share Posted August 29, 2019 The guy who compiled the MAME software list for Atari 8-Bit ATR's thought he'd be helpful and zeroed out all the empty space on all the ATR's assuming it was unneeded. Now there is another set of ATR files on the internet forever that don't match the SHA of a genuine disk dump. He realised the error he'd made and has since corrected it but those files now exist and people who collect and catalog can't get rid of them or their collections won't be complete, they just exist as (b) files for bad dump, data hoarders just won't delete them so cataloguing software will forever have to be able to identify them or the collectors will keep re-adding them to the dat files. 1 Quote Link to comment Share on other sites More sharing options...
_The Doctor__ Posted August 29, 2019 Share Posted August 29, 2019 lol, omg let's keep someones archiving mistakes as if they are source.... lol 1 Quote Link to comment Share on other sites More sharing options...
Mr Robot Posted August 29, 2019 Share Posted August 29, 2019 It doesn't help that a lot of context gets lost in the naming conventions, in the rush to add everything people rarely take the time to document stuff properly. The TOSEC naming convention allows for more descriptive naming than people use; a bad file can have (b empty space zeroed out) or something but the collectors just say (b), they would have to read every forum thread for every file to know why something is bad. Good files get added as (b) as well if the collector can't work out how to get it to run (for example a LST file named as a BAS) so no one who collects dares to delete anything just in case. We as a community are not helping clean this up. Teams like TOSEC are not helping us to help them. There is no easy way for a person to just correct a badly named file or add more info. there are many hoops to jump through and most people cant be bothered or just do their own. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.