Jump to content
IGNORED

Error 137 help please..


Mclaneinc

Recommended Posts

 

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..

Link to comment
Share on other sites

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 by _The Doctor__
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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 by Mclaneinc
Link to comment
Share on other sites

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!!!

 

  • Like 2
Link to comment
Share on other sites

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 by Guest
Link to comment
Share on other sites

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 by _The Doctor__
Link to comment
Share on other sites

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 by _The Doctor__
Link to comment
Share on other sites

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 by _The Doctor__
Link to comment
Share on other sites

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.

Link to comment
Share on other sites


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?
  • Like 3
Link to comment
Share on other sites

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 by _The Doctor__
Link to comment
Share on other sites

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 by Mr Robot
I didn't know for sure who did that so I removed the accusation it was someone specific.
Link to comment
Share on other sites

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.

 

  • Haha 1
Link to comment
Share on other sites

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.

 

Link to comment
Share on other sites

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...