On Tue, Aug 16, 2022 at 10:50 PM Eric LK <[email protected]> wrote: > I wrote a "very simplified" DB system where I used CO files for my data. > > Basically, I just peek and poke directly when into the files without > loading them into BASIC. It works well, allows you to use most of the > available ram for your > data, and is very fast to seek a record from its number [...] >
Sorry for not replying to this before, Eric. Gmail got confused and had filed it as spam. I ended up reinventing the wheel, but then this particular wheel has probably been invented many times over and just never clearly documented. I wonder if anyone has tried to update Anderson's Programming Peeks, Pokes and Tips <https://archive.org/details/ProgrammingTipsPeeksAndPokesForTheTandyPortableComputers> since 1989. This technique definitely belongs in there. > Of course, you have to be careful because any misplaced poke may screw > your whole filesystem, but if you have a REX for baking everything up > before trying your code it's doable. > Thanks for the advice. I already bake everything up. My worry is that I could release a program that seems to work perfectly on my machine, but blows up someone else's. It feels risky and dangerous to not have bounds checking on POKEs. I guess, that's the thrill of running close to the metal on these archaic beasts... As for a REX, I had been trying to see how much I could do with "stock" equipment, so I've been using Brian White's awesome dlplus <https://github.com/bkw777/dlplus> for backups. Still, I bought a REX recently and hope to learn to use it. Honestly, it seems so popular, I wonder if REX can just be considered the "default" Model T equipment at this point. Or, are my numbers skewed because the people who are most likely to own a REX are also the ones who are most likely to be using their Model T's actively and posting on this forum? Also you shouldn't write any other file (using regular BASIC files > functions) after you fetch the base addresses of your CO files because > it may change the file position in RAM No kidding! It's amazing how much shuffling the Model T is doing behind the scenes. How did Bill G. do it so efficiently? > (it will probably work if you refetch this base address, but I didn't try > it). > It turns out, it doesn't work. I think I mentioned this before, but I found that even just using EDIT moves the files and does NOT update the addresses in the directory. So far, the only way in BASIC that I know to update the directory is to call CLEAR. > The only thing I didn't do was allow creation of new records (I have a > fixed size DB of records I consult and/or edit). > Likewise! I believe the routine for resizing a .CO file is in all the Model T ROMs, but it'll be at a different location for each one. It'd be nice if somebody extended BASIC to expose that routine as a command, the same as SAVEM calls the ML routine to create a .CO file. I may try finding some of my code if you want something to start from. > I've finished, but I'd love to see your implementation. Perhaps I can generalize something that will be useful to other people as a library of sorts. —b9 On Tue, Aug 16, 2022 at 10:50 PM Eric LK <[email protected]> wrote: > B 9 <[email protected]> wrote: > > Good idea, but I can't as I am going to be indexing into the file given a > > fixed record size. > > I wrote a "very simplified" DB system where I used CO files for my data. > > Basically, I just peek and poke directly when into the files without > loading them into BASIC. > It works well, allows you to use most of the available ram for your > data, and is very fast to seek a record from its number (or its name > if you go the extra mile to have an index file). > > Of course, you have to be careful because any misplaced poke may screw > your whole filesystem, but if you have a REX for baking everything up > before trying your code it's doable. > > Also you shouldn't write any other file (using regular BASIC files > functions) after you fetch the base addresses of your CO files because > it may change the file position in RAM (it will probably work if you > refetch this base address, but I didn't try it). > > The only thing I didn't do was allow creation of new records (I have a > fixed size DB of records I consult and/or edit). > > >> 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.) > > I did this with a CO, not a DO. To be clear, you don't have to "load" > it before PEEK/POKE into it because it's already in RAM. > > So basically: > - you create a CO file of the size you want (you only do this once) > - you wrote a BASIC subroutine that finds its position in RAM by > parsing the files directory in RAM (note that it may change every time > you run your program so you have to do it at runtime) > - Then your BASIC program can POKE directly into this file > > I may try finding some of my code if you want something to start from. > (also I did that a few years ago, so I may be forgetting some details > about how it works) > > Cheers, > Eric >
