From: si@si.si   
      
   On Thu, 31 Jan 2008 22:41:39 +0100, Knut Roll-Lund   
    wrote:   
      
   >Bu wrote:   
   >> On Tue, 29 Jan 2008 23:10:26 -0800 (PST), Progress City   
   >> wrote:   
   >>   
   >>   
   >>>I have a VERY OLD basic program (TRS-80 Model 1, Level 2) that is   
   >>>saved in standard tokenized form. I'd like to convert it to plain   
   >>>text. Is there a utility for Windows XP that will do this?   
   >>   
   >>   
   >> On what medium do you have the 'source'; paper, cassette file,   
   >> diskfile or maybe a wav file?   
   >> Keep in mind that for instance in a cassette file every line statrts   
   >> with an memory address ( 2 bytes) followed by a linenumber (2 bytes)   
   >> and than the code.   
   >>   
   >> In the code part you can replace every token (byte or character value   
   >> above 127) with the actual basic word.   
   >> Below you find all the tokens.   
   >>   
   >> Bu   
   >>   
   >> Tokens(128) = "END": Tokens(129) = "FOR": Tokens(130) = "RESET":   
   >...   
   >   
   >In WAV2CAS I use the addresses you mention for checking correctness by   
   >keeping track of it when I encounter the next line. And because of it I   
   >can identify which basic that created the file, what model and what   
   >version of disk basic. BASIC ignores these addresses completely,   
   >regenerating them while loading so they match the current configuration.   
   I was also playing a littlebit around with 'decodong' wav files and   
   wanted to use the addresses for consistency checking of the   
   basic-file. I found soon that there is no strict relation between   
   addresses of the one statement line and the next. I guess if you saved   
   a basic program after some heavy editing (deleting lines) the address   
   pointers do not mean anything in a listing (and can not be used for   
   consistency checking of a saved basic file).   
   You mention you can identify what basic based of the addresses. Can   
   you explain this a little bit more as i am interested in this.   
      
   >   
   >The addresses are a linked list used and when you GOTO or GOSUB. Basic   
   >search from the beginning of the program using the addresses to search   
   >for the specified line number. Which means that a GOTO to a line earlier   
   >in the program is excuted faster than a GOTO to a line further into the   
   >program... Compiler basic converts GOTO and GOSUB's int real jumps and   
   >calls to avoid this overhead.   
   I once wrote a level2 basic program that needed all the speed it could   
   get so i placed a.o. all often called procedures in the low line   
   numbers beside using no numbers but only variables etc.   
      
   >   
   >I would use an emulator and LLIST it to a PC file or SAVE"FUN/BAS",A for   
   >an ascii save etc.   
   But then you need first to get it into the emulator (:-). And this   
   depends on which media you have the data. And you can't type the   
   tokens into the basic of the emulator.   
   Maybe the easiest way is to write a small program (for instance in VB)   
   to convert the data/tokens. For input you can use either a file or   
   just type it in.   
      
   >   
   >BTW I intend WAV2CAS to be able to save ascii format and read BAS, CMD   
   >and CAS files as well as WAV. I have actually found out the problem I   
   >had. It was a mistake, a bug, in the decoding of highspeed system tapes   
   >(doesn't affect basic), model III stuff. A few bits at the en were lost   
   >due to the fact that highspeed saves 9 bit per byte (a startbit is used)   
   >so significant bits at the end (highbyte of the transfer address) might   
   >be afffected. I'll release the new versions very soon.   
   The program i wrote (if you want to have a look at it see   
   www.geocities.com/butchijo/TRS.html ) 'decodes' wav files and produces   
   readable listings of basic files (*.cas)   
      
   Thanks for sharing your thougts on this   
   Bu   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)   
|