Yes, I know. The problem is that the first two bytes must point to the right memory location, and my DTV doesn't like loading files like that. Somehow it just crashes when I continue coding, so it's kind of problematic to test a program under development...
Post by Robin Harbron on Oct 21, 2006 20:22:58 GMT -5
Yes, I know.
Why didn't you say so then?
The problem is that the first two bytes must point to the right memory location, and my DTV doesn't like loading files like that. Somehow it just crashes when I continue coding, so it's kind of problematic to test a program under development...
Hmm, are you loading from device 8? Sounds like something that would happen with device 1.
I remember reading in some issue of Loadstar how to use a KERNAL SYS to load a file - that might have the same problem anyway. And I'd probably have to look through 50 issues to find the right one
Loc 780 is 0 for load, 1 for verify. With this, you can bload data anywhere in memory, not just to the address from which it was saved. (For ML, you have to bload to the assembled address.)
Also, this rather long line does not return the program to the top. It is almost a real BLOAD command.
Now to get the data --
A is now the pointer to the string data, and can be pointed anywhere in open memory.
POKEA,len POKEA+1,ADDRLO POKEA+2,ADDRHI
Magically, A$ will now hold len bytes of whatever is at ADDR.
How you make this work is up to you. Static length Fields is one way. Long ago, I created a database using the $C0000 4K area (49152-53247) for data, and the above moveable string to get information into BASIC. Had to POKE data byte-by-byte into the memory area, though.