I've just hit this one too. My Uno is loaded with 5.04T (UK), and doesn't even get past the first DOS command in the basic loader. I think this might be the version where the entry points have changed. I need to write a good detection routine.keith56 wrote: ↑Sat Dec 09, 2017 12:32 amit seems my problem was not the code, or trdtool, but something with my emulator, I was using TR-DOS 5.04 (UK) and it was somehow failing to even save a bas file to a newly formatted disk from it's own interface (It was renaming the disk??!!)
Well, I've moved to 6.04 (Russian) and the example works perfectly, so I don't know if I had a corrupt rom, or something messed up on my emulator, but all is good now! - out of interest, what is the best rom to use for testing (compatibility wise?)
Somewhere I saw a handy list of differences between several TR-DOS versions, but I can't find it now.
Thanks! Your suggestion works nicely (on 5.03)!Hikaru wrote: ↑Sun Dec 17, 2017 8:06 amThe whole 'leaving gaps' issue is normal in a sense, and is expected of programs that operate on the file level. Notice that, as long as the file you're working with is the last file on the disk, no gap would be left if it is deleted and subsequently saved back.
On the other hand, doing a MOVE within a game program is certainly an overkill and not what most people would expect. It's a bit like if a PC game tried to defragment the HDD on its own!
Random access and other unusual formats are best avoided. I doubt most people have any idea what those are (myself included), and I don't remember a single program that used those on a regular basis for its functionality.
(Why not just keep a single 961 byte file? Loading 4 sectors and 1 sector takes virtually the same time, and this is more efficient in terms of using the disk space.)
This is great, thanks. I haven't got this working yet (lack of time). But I will try to do soHikaru wrote: ↑Sun Dec 17, 2017 8:06 amAnother option is to do the #0A/#08 thing once in the beginning, store the file locations/lengths in memory, and then just use #05/#06 as needed. This would help to reduce unnecessary drive head movements to track 0 and back (is faster). Also, #05/#06 have the advantage of not requiring the extra buffer in order to work.
Ah, brilliant, thanks! I tried to do this before but couldn't figure it out. Much better way of handling it. I want the language selection to always write back to the disk when you start, but silently fail if it is write protected or something else happens. Resetting the high score table should only happen when you pick that option, and should fail verbosely. That why I originally had them as separate files. I can still do it the way I want having them share a file, it's just a little more complicated.