erichenneke Posted April 3, 2017 Share Posted April 3, 2017 Posting from my phone on vacation, so I will add more details and attach examples later... However, this is really bugging me and I wanted to get your thoughts... While going through all my old disks I decided i'd like to finish some uncompleted games that I had started back when I was a kid in the early 80's. but I ran into a problem with several of the files. These are all in standard atari basic by the way. When I try to load the problematic files it results in: READY READY (two "ready" messages) and then when I say LIST there is no code to view, and RUN does nothing, like there is nothing in memory. The files show up in DOS directory and seem normal size, etc. I have found I can load them into memopad as an imported basic tokenized file, but not sure what good that really does for me...at least it seems to indicate that the data is there and can be read. I am thinking something in the basic tokenized file got corrupted. I remember "back in the day" running into this READY READY thing with nothing to LIST even on some commercial software ( like Avalon Hill games or something like that which were in basic) and I assumed they were doing something intentionally to protect the code. Anyway, I'd appreciate any help or advice. It would be cool to finish some of these games I started on so long ago but I am stuck for now. I will attach some example files later after I get back to a PC. Thanks!! Eric 1 Quote Link to comment Share on other sites More sharing options...
+Stephen Posted April 3, 2017 Share Posted April 3, 2017 Gah - I have seen this in the past, but never knew what the cause why. I am not familiar with Memopad. However, you say it can import the file as tokenized BASIC. Is it possible to then "LIST" it out as plain text, and then "ENTER" it back on the machine? If so, you can then re-save it as tokenized BASIC. 1 Quote Link to comment Share on other sites More sharing options...
Roydea6 Posted April 3, 2017 Share Posted April 3, 2017 (edited) Stephen You got to know about memopad Joyfulcoder product. previous version only did Basic and Turbobasic but now at version 18 it is almost a text editor for basic.. Drag and drop or open from the file menu.. http://joyfulcoder.com/memopad/MemoPad-R18.zip Edited April 3, 2017 by rdea6 4 Quote Link to comment Share on other sites More sharing options...
+Stephen Posted April 3, 2017 Share Posted April 3, 2017 Stephen You got to know about memopad Joyfulcoder product. previous version only did Basic and Turbobasic but now at version 18 it is almost a text editor for basic.. Drag and drop or open from the file menu.. Oh - yes, pretty bad when I'm in threads mentioning it. So, what you'll want to do, is import the BAS program. Go to View->EOL and make sure that ATARI $9B is selected. Then, export the file somewhere on your PC. Assuming you have some type of SIO2PC device, load the file on the ATARI in BASIC via the "ENTER" command. The syntax will be parsed line by line as the code is entered. Failing this, you can use Altirra. Copy all of the text from MemoPad, and simply paste it into Altirra, then you can also do a BASIC save. 1 Quote Link to comment Share on other sites More sharing options...
thorfdbg Posted April 4, 2017 Share Posted April 4, 2017 When I try to load the problematic files it results in: READY READY (two "ready" messages) and then when I say LIST there is no code to view, and RUN does nothing, like there is nothing in memory. This is typically an indication that the files in question have been "list-protected". They cannot be "LOAD"ed. You should be able, though, to start them with RUN "D:xxxx". There are probably a couple of utilites out that can de-tokenize the basic file and bring them back in a form where you can ENTER them, and then list them. I should have such a utility available if you need it. 2 Quote Link to comment Share on other sites More sharing options...
Mclaneinc Posted April 4, 2017 Share Posted April 4, 2017 List protection was commonly used especially in the commercial BASIC programs, it was a very simple measure to protect from the school boy copying, often it was used in conjunction with more complex protection. 1 Quote Link to comment Share on other sites More sharing options...
russg Posted April 4, 2017 Share Posted April 4, 2017 (edited) This is typically an indication that the files in question have been "list-protected". They cannot be "LOAD"ed. You should be able, though, to start them with RUN "D:xxxx". There are probably a couple of utilites out that can de-tokenize the basic file and bring them back in a form where you can ENTER them, and then list them. I should have such a utility available if you need it. Here's a A8 program to salvage unloadable BAS files to a LISTed file. After the LIST file is complete, ENTER the file you created, which can be reSAVED then. Comment: I tried my salvage program in Altirra 2.70 and it gives ERROR # 163 at line 53. It is strange. I tried it in Atari800winplus 4 and it doesn't get that error. I think the OP is using a real Atari with a real disk drive, so it should work. Maybe some expert on Altirra can help me. SALVAGEX.ATR Edited April 4, 2017 by russg 2 Quote Link to comment Share on other sites More sharing options...
Rybags Posted April 4, 2017 Share Posted April 4, 2017 Fairly sure double-Ready could also be gotten via - failed load due to corrupt data or truncated file. Attempt to Enter a file that wasn't created by List. 1 Quote Link to comment Share on other sites More sharing options...
phaeron Posted April 6, 2017 Share Posted April 6, 2017 (edited) Double READY definitely sounds more like a damaged file than LIST protection. Most techniques that I know of for the latter only take effect once you try to run another command, not immediately after the LOAD. If we can get a sample .BAS file it shouldn't be hard to tell what's going on and fix it, as long as the essential code's still there. I've recovered BASIC programs corrupted by an ASCII transfer before. Comment: I tried my salvage program in Altirra 2.70 and it gives ERROR # 163 at line 53.It is strange. I tried it in Atari800winplus 4 and it doesn't get that error.I think the OP is using a real Atari with a real disk drive, so it should work.Maybe some expert on Altirra can help me. This is just MyDOS's weird way of telling you your disk is write protected. Edited April 6, 2017 by phaeron 2 Quote Link to comment Share on other sites More sharing options...
russg Posted April 6, 2017 Share Posted April 6, 2017 (edited) Double READY definitely sounds more like a damaged file than LIST protection. Most techniques that I know of for the latter only take effect once you try to run another command, not immediately after the LOAD. If we can get a sample .BAS file it shouldn't be hard to tell what's going on and fix it, as long as the essential code's still there. I've recovered BASIC programs corrupted by an ASCII transfer before. This is just MyDOS's weird way of telling you your disk is write protected. Yes, thanks. My salvage program will work on .BAS files that have been made unloadable. I remember a little. The main reason I wrote salvage was to recover .BAS files that got unloadable because of the 'add 16 bytes to the end' with every SAVE, eventually making the file unloadable. I think there were 'protection' schemes that mashed the variable name table. Salvage will work on those too. Also, you have to have two disk drives, one to read and one to write you specify with the 'filespec' inputs at start. Has to have 'D:READ.BAS' and D2:WRITE.LST for example. Edited April 6, 2017 by russg 2 Quote Link to comment Share on other sites More sharing options...
Nukey Shay Posted April 6, 2017 Share Posted April 6, 2017 ...but it won't restore the original variable names (obviously). I'm thinking it was some other corruption than intentionally wiping the table...because why would somebody do that to their own programs? 1 Quote Link to comment Share on other sites More sharing options...
russg Posted April 7, 2017 Share Posted April 7, 2017 ...but it won't restore the original variable names (obviously). I'm thinking it was some other corruption than intentionally wiping the table...because why would somebody do that to their own programs? Yes, I don't remember if SALVAGE assigns variable names for all files, or just those with a mashed vnt. I think it restores names if the vnt is right. 1 Quote Link to comment Share on other sites More sharing options...
erichenneke Posted April 7, 2017 Author Share Posted April 7, 2017 Gah - I have seen this in the past, but never knew what the cause why. I am not familiar with Memopad. However, you say it can import the file as tokenized BASIC. Is it possible to then "LIST" it out as plain text, and then "ENTER" it back on the machine? If so, you can then re-save it as tokenized BASIC. unfortunately, with the examples i have listing it as text from memopad and then trying the ENTER it doesn't work either. Quote Link to comment Share on other sites More sharing options...
erichenneke Posted April 7, 2017 Author Share Posted April 7, 2017 Oh - yes, pretty bad when I'm in threads mentioning it. So, what you'll want to do, is import the BAS program. Go to View->EOL and make sure that ATARI $9B is selected. Then, export the file somewhere on your PC. Assuming you have some type of SIO2PC device, load the file on the ATARI in BASIC via the "ENTER" command. The syntax will be parsed line by line as the code is entered. Failing this, you can use Altirra. Copy all of the text from MemoPad, and simply paste it into Altirra, then you can also do a BASIC save. Thanks for the suggestion Stephen, I tried what you said but that didn't work either. I learned something new though based on what you suggested... I didn't realize you could paste into Altirra and it would behave like it is entering the text directly. That's pretty cool. Good to know. Still stuck with my "corrupted?" basic programs though. Just getting back from vacation and back on a PC for the first time in over a week, so seems I have a lot of great suggestions and tools to try out from this thread though! -Eric Quote Link to comment Share on other sites More sharing options...
erichenneke Posted April 7, 2017 Author Share Posted April 7, 2017 This is typically an indication that the files in question have been "list-protected". They cannot be "LOAD"ed. You should be able, though, to start them with RUN "D:xxxx". There are probably a couple of utilites out that can de-tokenize the basic file and bring them back in a form where you can ENTER them, and then list them. I should have such a utility available if you need it. Unfortunately on the examples I am having problems with RUN "D:XXXX" also results in READY READY ( and no code ), which is the same behaving of LOAD. Quote Link to comment Share on other sites More sharing options...
erichenneke Posted April 7, 2017 Author Share Posted April 7, 2017 Fairly sure double-Ready could also be gotten via - failed load due to corrupt data or truncated file. Attempt to Enter a file that wasn't created by List. i think this is what's happening. I tried loading it into Turbo Basic XL just for the heck of it ( even though these are standard atari BASIC files) and it gave a TRUNC error. Quote Link to comment Share on other sites More sharing options...
erichenneke Posted April 7, 2017 Author Share Posted April 7, 2017 Double READY definitely sounds more like a damaged file than LIST protection. Most techniques that I know of for the latter only take effect once you try to run another command, not immediately after the LOAD. If we can get a sample .BAS file it shouldn't be hard to tell what's going on and fix it, as long as the essential code's still there. I've recovered BASIC programs corrupted by an ASCII transfer before. This is just MyDOS's weird way of telling you your disk is write protected. Ok, here's a good example. This is just an old simple BASIC program from back in the early 80's. The particular file called "EGYPT" is part of a bigger game that used multiple BASIC programs that would load as gameplay progressed. Anyway, this one is being problematic with the READY READY behavior we are discussing here. (sorry for delay on providing an example, i was traveling and didn't have my PC...or my Atari either of course!). I am providing two separate ATR files as examples. In theory, they SHOULD be the same but clearly they both have issues, and seem to be different issues! Even the sector count for the EGYPT file is different from one ATR to the other. I dumped these from floppies to ATR files using SIO2PC a long time ago (many years). If I remember correctly, they each came from separate physical disks which were intended to be backups of each other from back in the day. One of the ATR's results in READY READY when you try to load "D:EGYPT The other ATR doesn't even get that far, it just results in an error 164 (attempting LOAD) and 137 (attempting ENTER). If I could recover EITHER of the EGYPT files off of one or both of these ATR's, or even partial recovery, it would help a lot! Thanks, Eric Bount2_1.ATRBount2_2.atr Quote Link to comment Share on other sites More sharing options...
erichenneke Posted April 7, 2017 Author Share Posted April 7, 2017 Here's a A8 program to salvage unloadable BAS files to a LISTed file. After the LIST file is complete, ENTER the file you created, which can be reSAVED then. Comment: I tried my salvage program in Altirra 2.70 and it gives ERROR # 163 at line 53. It is strange. I tried it in Atari800winplus 4 and it doesn't get that error. I think the OP is using a real Atari with a real disk drive, so it should work. Maybe some expert on Altirra can help me. Wow, thanks russg ! This seems to have worked on the EGYPT basic program i was getting READY READY on ! Sweet. I will try it on some of the others as well. Thank you! -Eric 1 Quote Link to comment Share on other sites More sharing options...
erichenneke Posted April 7, 2017 Author Share Posted April 7, 2017 Wow, thanks russg ! This seems to have worked on the EGYPT basic program i was getting READY READY on ! Sweet. I will try it on some of the others as well. Thank you! -Eric ok, maybe i spoke a little too soon. SALVAGEX did work on one version of the EGYPT file and made it LOAD-able again, but it seems to only be a portion of the program. On the other version of the EGYPT file the SALVAGEX tool runs much longer and recovers more of the program, but then it gets an ERROR 164 and doesn't complete successfully. Even so, it recovers quite a bit more of the code as LOAD-able. In both cases, this is still much better than what I had before. At least I get more to work with. However, if you there is a way to get this to recovery the ENTIRE file, that would of course be better. This is the error screen I get. Both versions of the "EGYPT" file I am attempting to recover are in the examples message above attached as ATR files. Any suggestions? Thanks! I will keep playing with it. -Eric Quote Link to comment Share on other sites More sharing options...
AtariGeezer Posted April 7, 2017 Share Posted April 7, 2017 Ok, here's a good example. This is just an old simple BASIC program from back in the early 80's. The particular file called "EGYPT" is part of a bigger game that used multiple BASIC programs that would load as gameplay progressed. Anyway, this one is being problematic with the READY READY behavior we are discussing here. (sorry for delay on providing an example, i was traveling and didn't have my PC...or my Atari either of course!). I am providing two separate ATR files as examples. In theory, they SHOULD be the same but clearly they both have issues, and seem to be different issues! Even the sector count for the EGYPT file is different from one ATR to the other. I dumped these from floppies to ATR files using SIO2PC a long time ago (many years). If I remember correctly, they each came from separate physical disks which were intended to be backups of each other from back in the day. One of the ATR's results in READY READY when you try to load "D:EGYPT The other ATR doesn't even get that far, it just results in an error 164 (attempting LOAD) and 137 (attempting ENTER). If I could recover EITHER of the EGYPT files off of one or both of these ATR's, or even partial recovery, it would help a lot! Thanks, Eric Bount2_1.ATRBount2_2.atr Just downloaded these and checked them with ATR Tools, Bount2_1.ATR can display all what's there, but seems to be missing a sector or two as it doesn't show any lines past 19008 and up to the indirect line 32767 which should be something like "SAVE D1:EGYPT". The VTOC check shows corrupted sectors on both ATR's, this is part of the double "READY" problem (incomplete loading). I'll scan the sectors for valid data and see what I can do to repair these... Jay 2 Quote Link to comment Share on other sites More sharing options...
AtariGeezer Posted April 8, 2017 Share Posted April 8, 2017 Here's the fixed disk... Bount2_1.ATR The contents of Disk 2 looks almost identical, so this should get you going 2 Quote Link to comment Share on other sites More sharing options...
erichenneke Posted April 8, 2017 Author Share Posted April 8, 2017 Here's the fixed disk... Bount2_1.ATR The contents of Disk 2 looks almost identical, so this should get you going Very cool! Looks to be all there. Thanks a ton ! Really. This all got me playing around with ATR Tools. Very nice program. What's the latest version of ATR Tools available ? I was able to find build 025A. Is that the most current? -Eric Quote Link to comment Share on other sites More sharing options...
AtariGeezer Posted April 8, 2017 Share Posted April 8, 2017 Very cool! Looks to be all there. Thanks a ton ! Really. This all got me playing around with ATR Tools. Very nice program. What's the latest version of ATR Tools available ? I was able to find build 025A. Is that the most current? -Eric Glad to help out Yep, 25A is the last posted version. 26C should be ready in the next week I think, just finishing up the ATX write image routines, plus it has a Mac/65 code viewer too... 3 Quote Link to comment Share on other sites More sharing options...
russg Posted April 8, 2017 Share Posted April 8, 2017 (edited) ok, maybe i spoke a little too soon. SALVAGEX did work on one version of the EGYPT file and made it LOAD-able again, but it seems to only be a portion of the program. On the other version of the EGYPT file the SALVAGEX tool runs much longer and recovers more of the program, but then it gets an ERROR 164 and doesn't complete successfully. Even so, it recovers quite a bit more of the code as LOAD-able. In both cases, this is still much better than what I had before. At least I get more to work with. However, if you there is a way to get this to recovery the ENTIRE file, that would of course be better. This is the error screen I get. error running salvage.JPG Both versions of the "EGYPT" file I am attempting to recover are in the examples message above attached as ATR files. Any suggestions? Thanks! I will keep playing with it. -Eric I think error 164 means you didn't set the .atr image in your emulator to be writeable. Anyway. I did EGYPT.BAS and got a complete LIST and then a SAVEd BASIC. Here's a .ATR with the two on it. I didn't play the game, but it seems to be working. edit: As usual, when I don't test something before posting it, it doesn't work right. don't try to boot that .ATR. The LIST and BAS files on the .ATR are good, but load them after booting from a good boot image. ie. boot a good .ATR, then LOAD or ENTER from my .ATR MYEGYPT.ATR Edited April 8, 2017 by russg 2 Quote Link to comment Share on other sites More sharing options...
AtariGeezer Posted April 8, 2017 Share Posted April 8, 2017 I think error 164 means you didn't set the .atr image in your emulator to be writeable. Anyway. I did EGYPT.BAS and got a complete LIST and then a SAVEd BASIC. Here's a .ATR with the two on it. I didn't play the game, but it seems to be working. It's missing lines 20000 to 32011, there are 4-5 more sectors that weren't linked. 3 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.