Awesome, thanks. I will get there eventually. Somehow it's harder integrating new info in a foreign language until you reach a tipping point. I don't know how you multilingual guys do it, but you rock.Hikaru wrote: ↑Tue Dec 12, 2017 1:03 pm Meh. It fails since it's actually doing a 'verify' operation - because guess what, there are actually two variables responsible for this, the second one being #5D10. Neither Rodionov's book nor the disassembly mention that one (I don't even see it listed as a TR-DOS variable), although it's possible to trace where the check occurs in the disassembly.
You're right. This is code that's I copied and pasted between projects, and somehow I have strayed away from the original intention - which was to set up the environment in a deterministic state after external loaders (mostly DivMMC/exsDOS) have dumped you into the starting point. Clearly I'm not doing what I intended here!Hikaru wrote: ↑Tue Dec 12, 2017 1:03 pm 1. OUTputting a random value from #5B5C to (#7FFD) at the start of your main code and hoping for the best isn't exactly a good idea. There's no telling which ROM/screen/page that would activate, or indeed whether you won't be screwed the next time an IM1 interrupt comes. It's better to set both of them to a known value of your own if you have to.
Thanks! I have had help I'm afraid. Mikhail Sudakov (Castlevania Spectral Interlude) kindly offered to help with translations. He already warned me about context and word-ending changes. I woke up to the same message from him as I did from you!! Обнулить таблицу рекордов was too long - and I just now saw that he gave me Обнулить рекорды as an alternative right from the beginning
Another piece of the puzzle, cheersAst A. Moore wrote: ↑Tue Dec 12, 2017 1:46 pm Well, there’s this, which describes the variable at #5d10 as “MSB of TR-DOS error code, cleared on 15616 calling, should be cleared when you call 15635.”
I had been trying to get this one working too. This is the "official" API that passes tokenized basic commands to TR-Dos. I ran into issues with my tokenization - the stuff in my reference REM statements were being tokenised as "C", "O", "D", "E" etc and it was causing confusion with some other problems I was having at the same time. It clearly works in my basic loader though, so I could revisit this later. But I don't really need to.Ast A. Moore wrote: ↑Tue Dec 12, 2017 1:46 pm Then there’s the manual for BETA 128 interface itself, which isn’t particularly useful, but has a little assembly snippet nevertheless.
I now have an asm loader that loads everything except $6000-$7FFF (and updates my progress bar). Loading this block is breaking TR-Dos, so I need to debug to see what's going on. I don't really want to rearchitect the game because the codebase is shared with the non-Pentagon version (and space in unpageable RAM is TIGHT!!), so I will have to figure out a way to have code from $6000-> and stack from <-$5FFF, and still keep Dos working well enough to save my high scores every game end. Also I'm using the ZX Printer buffer as a general purpose buffer in a ton of places, so will need to figure out something different there.
Are there any special Pentagon-only horizontal MMU schemes that would help, by any chance? Mostly a rehetorical question - I have lots of reading to do...