Re: [M100] Writing binary files from BASIC
On Mon, Aug 15, 2022 at 1:47 PM B 9 wrote: > > Is there a manual where the .CO file format is defined? I presume there's > a header I'll have to skip to get to my data, but what is its format? Also, > how can I render a .CO file harmless if a user accidentally tries to load > it. For example, can I set the reserved load location to be so it'll > write to ROM? > > https://bitchin100.com/wiki/index.php?title=Low_Level_Filesystem_Access#CO_File_Format As to making the CO file safe... I don't know you'd have to experiment. I think you'd have to find a RET instruction in memory for your platform and set the EXEC address there. In fact if you don't CLEAR before load or launch the CO it will fail no matter what, error BEEP and show the Load, Length and EXE address. > If you want to create a binary file, you need to create a CO file by >> saving a range of memory to a CO file. To create the initial contents you >> would POKE your bytes into a reserved region of memory. >> > > That would be the simplest way, but I'm trying to avoid duplicating the > file in memory. Has anybody ever tried first creating a .DO file of the > correct size in BASIC and then twiddling the RAM Directory's attribute byte > so that it is a binary file? > You cannot do that. The BA, DO and CO regions are separate contiguous blocks. You'd have to move the file bytes if you changed its type. Which is a whole thing. Take a look at the link above for the general file system structure. > Once I have the file's address, I could just poke directly into it and > save the copy. Right? Or am I missing something? (For example, after > creating a file, does the Ram Directory get updated? I already noticed that > I need to use CLEAR at the start of my program since the file pointers are > stale after doing an EDIT in BASIC.) > > To create a CO file: First, CLEAR space at some location. Of it it's small you could poke your contents into some known safe region like the ALTLCD buffer. This is a small buffer that maintain a copy of the screen contents while TELCOM is in operation. After you have a safe area, you can poke your data to it. Then you can SAVE it as a file. This command is different on different BASICs. As to having one program run on M100, T200 and NEC... be advised that is tricky if it's even possible. Their BASICs are different, and there ROMs are different and their RAM offsets are different. In particular the SAVE/LOAD commands are different between NEC and Tandy. -- John.
Re: [M100] Writing binary files from BASIC
On Mon, Aug 15, 2022 at 4:52 AM Stephen Adolph wrote: > I encode the data to avoid these values If the byte matches the above > criteria, I use "/" to denote "encoded" and then I follow with the value of > the byte +128. > Good idea, but I can't as I am going to be indexing into the file given a fixed record size. On Mon, Aug 15, 2022 at 12:09 PM John R. Hogerhuis wrote: > There is no limitation on the characters a binary file contains. But, > binary files are harder to use, since you cannot open them directly, you > can only load them back into RAM at their reserved load location... which > itself creates a second copy of the data doubling RAM requirements. > Alternatively if you have a CO in the RAM file system you could access the > directory entry and peek the contents directly. This skips a decode > operation. > I was planning on accessing the file directly without loading it. I need less than 1% of the file, but which 1% changes every day. I already have the code for that working, albeit for .DO files. Is there a manual where the .CO file format is defined? I presume there's a header I'll have to skip to get to my data, but what is its format? Also, how can I render a .CO file harmless if a user accidentally tries to load it. For example, can I set the reserved load location to be so it'll write to ROM? > If you want to create a binary file, you need to create a CO file by > saving a range of memory to a CO file. To create the initial contents you > would POKE your bytes into a reserved region of memory. > That would be the simplest way, but I'm trying to avoid duplicating the file in memory. Has anybody ever tried first creating a .DO file of the correct size in BASIC and then twiddling the RAM Directory's attribute byte so that it is a binary file? Once I have the file's address, I could just poke directly into it and save the copy. Right? Or am I missing something? (For example, after creating a file, does the Ram Directory get updated? I already noticed that I need to use CLEAR at the start of my program since the file pointers are stale after doing an EDIT in BASIC.) > Another topic is embedding binary data into a tokenized BASIC program, for > example in strings, in REM statement and in high-numbered unlistable lines > of tokenized BASIC. That's also tricky but can result in machine code that > can be run directly. You actually have to specially craft your ML code to > do this. > > -- John. > You always amaze me with ideas that are so far over my head that I can only aspire to someday make use of them. Having the data embedded in the BASIC program would be fun, but a requirement of this program is that it will run on Model 100/102, Tandy 200, and NEC PC-8201/A/8300. (I might add Olivetti M10 and Kyotronic KC-85, but I can't find the technical reference manuals that have the address for the RAM Directory.) —b9
Re: [M100] Writing binary files from BASIC
.DO files are not binary files and are slightly limited in the characters they can contain. If you want to represent binary data in a DO file you need to encode it in some way, like HEX or custom. Custom formats can be more compact than HEX. There is no limitation on the characters a binary file contains. But, binary files are harder to use, since you cannot open them directly, you can only load them back into RAM at their reserved load location... which itself creates a second copy of the data doubling RAM requirements. Alternatively if you have a CO in the RAM file system you could access the directory entry and peek the contents directly. This skips a decode operation. If you want to create a binary file, you need to create a CO file by saving a range of memory to a CO file. To create the initial contents you would POKE your bytes into a reserved region of memory. Another topic is embedding binary data into a tokenized BASIC program, for example in strings, in REM statement and in high-numbered unlistable lines of tokenized BASIC. That's also tricky but can result in machine code that can be run directly. You actually have to specially craft your ML code to do this. -- John. On Mon, Aug 15, 2022 at 1:49 AM B 9 wrote: > I was attempting to write a binary data file using BASIC's OPEN and PRINT > # commands and found that there are three bytes that are not allowed: 0, > 26, and 127. I had expected CHR$(26) might be a problem as that is the > End Of File character, but the other two were a surprise. Is this > limitation documented somewhere? It's not in the BASIC manual from Radio > Shack. > > Here's an example of what doesn't work: > > 10 open "foo.do" for output as #1 > 20 for t=0 to 255 > 30 print #1, chr$(t); > 40 next t > 50 close #1 > 80 open "foo.do" for input as #1 > 90 x=0 > 100 if eof(1) then 200 > 110 c = asc(input$(1,1)) > 120 if c<>x then print x > 130 x=c+1 > 140 goto 100 h > 200 close #1 > 210 end > > I can think of various workarounds, but they are ugly. What is the best > way to write binary files with arbitrary data from BASIC on a Model T? > > Thanks for any guidance. > > —b9 >
Re: [M100] Writing binary files from BASIC
There must be a reason every single do2co/loader/hexfer util does this by poking into memory. They determine or are hardcoded with a starting address, poke the bytes, and then savem the start & length. You probably just found that reason. On Mon, Aug 15, 2022, 4:49 AM B 9 wrote: > I was attempting to write a binary data file using BASIC's OPEN and PRINT > # commands and found that there are three bytes that are not allowed: 0, > 26, and 127. I had expected CHR$(26) might be a problem as that is the > End Of File character, but the other two were a surprise. Is this > limitation documented somewhere? It's not in the BASIC manual from Radio > Shack. > > Here's an example of what doesn't work: > > 10 open "foo.do" for output as #1 > 20 for t=0 to 255 > 30 print #1, chr$(t); > 40 next t > 50 close #1 > 80 open "foo.do" for input as #1 > 90 x=0 > 100 if eof(1) then 200 > 110 c = asc(input$(1,1)) > 120 if c<>x then print x > 130 x=c+1 > 140 goto 100 h > 200 close #1 > 210 end > > I can think of various workarounds, but they are ugly. What is the best > way to write binary files with arbitrary data from BASIC on a Model T? > > Thanks for any guidance. > > —b9 >
Re: [M100] Writing binary files from BASIC
If you consider saving the .DO file over serial, or loading it over serial, it is even more tricky. here are the cases I trap: = 34 or =127 or <= 32 I encode the data to avoid these values If the byte matches the above criteria, I use "/" to denote "encoded" and then I follow with the value of the byte +128. Ex. Sending 26d --> replace with 47d, 154d of course this forces me to trap for =47 as well, sending 47d --> replace with 47d, 175d I also use "/E" aka 47d, 69d to denote end of data I have a utility based on this encoding that converts intel HEX output from a compiler, into a self loading .DO file. The utility can be compiled with Freebasic into an executable. Happy to share the code. The encoding part of it is similar to what you are looking for. Steve On Mon, Aug 15, 2022 at 4:49 AM B 9 wrote: > I was attempting to write a binary data file using BASIC's OPEN and PRINT > # commands and found that there are three bytes that are not allowed: 0, > 26, and 127. I had expected CHR$(26) might be a problem as that is the > End Of File character, but the other two were a surprise. Is this > limitation documented somewhere? It's not in the BASIC manual from Radio > Shack. > > Here's an example of what doesn't work: > > 10 open "foo.do" for output as #1 > 20 for t=0 to 255 > 30 print #1, chr$(t); > 40 next t > 50 close #1 > 80 open "foo.do" for input as #1 > 90 x=0 > 100 if eof(1) then 200 > 110 c = asc(input$(1,1)) > 120 if c<>x then print x > 130 x=c+1 > 140 goto 100 h > 200 close #1 > 210 end > > I can think of various workarounds, but they are ugly. What is the best > way to write binary files with arbitrary data from BASIC on a Model T? > > Thanks for any guidance. > > —b9 >
[M100] Writing binary files from BASIC
I was attempting to write a binary data file using BASIC's OPEN and PRINT # commands and found that there are three bytes that are not allowed: 0, 26, and 127. I had expected CHR$(26) might be a problem as that is the End Of File character, but the other two were a surprise. Is this limitation documented somewhere? It's not in the BASIC manual from Radio Shack. Here's an example of what doesn't work: 10 open "foo.do" for output as #1 20 for t=0 to 255 30 print #1, chr$(t); 40 next t 50 close #1 80 open "foo.do" for input as #1 90 x=0 100 if eof(1) then 200 110 c = asc(input$(1,1)) 120 if c<>x then print x 130 x=c+1 140 goto 100 h 200 close #1 210 end I can think of various workarounds, but they are ugly. What is the best way to write binary files with arbitrary data from BASIC on a Model T? Thanks for any guidance. —b9
Re: [M100] Rechargeable batteries
A while ago I saw a howto on hacking a Tandy 200 to fit a fifth rechargeable battery but I can't for the life of me find it again. I'd rather not reinvent the wheel, so if anyone has any clues, I'd appreciate it. —b9 On Mon, Jun 20, 2022 at 11:31 AM you got me wrote: > One option might be to install 5 ni-mh cells. 4 in the regular place and a > 5th inside of the m100. Then have a ni-mh charging circuit (widely > available) in line with the 6v adapter socket of the m100. So, while the > m100 is plugged in, it charges the batteries. > > Also, I believe there were previous discussions about replacing the memory > ni-cad with a super capacitor. > -- > *From:* M100 on behalf of Allan > Zieser > *Sent:* Monday, June 20, 2022 12:55 PM > *To:* m...@bitchin100.com > *Subject:* [M100] Rechargeable batteries > > > I have noticed that with rechargeable batteries the active life for the > Model 100 is shorter. This is because most rechargeable batteries follow a > curved path for power drain. They only maintain the 1.5 volts for s short > time then tend to drop lower for the remainder of their power drain. When > the power drops low enough the Model 100 activates the low power light and > then goes down. > > > > There are some exceptions to this discharge path. The EBL rechargeable > batteries hold the 1.5 voltage across their drain, however then they drop > off sharply causing a shutdown when they are at the end of the discharge > cycle. Not really an issue for me as I use the Rex and Jeff’s backpack so I > can save often on projects. Just some of the tradeoffs I have noticed when > using rechargeable batteries. > > > > In regards to the backup battery, the advantages do outweigh the > disadvantages. If you are only running on installed batteries then the > backup battery will recharge from them continuously, reducing the battery > life. However if you use a wall outlet or usb power cable then it will > extend the life of the batteries by charging the backup off of the power > cable instead of the installed batteries. > > > > I have considered installing NiCad’s, however this requires a little > soldering, so I am not sure if it is worth it. For now I just use a > combination of the EBL batteries and a USB power cable I found on Ebay that > works really well. > > > > Just my observations on this. Please correct me if I am wrong in any of > this. Have a great week! > > > > -Allan Zieser > > >
