Thank you for the detailed description, I cannot wait to give that a go as it will make the game a bit better. I used the feature to save .b81 code constantly in my technique, plus cutting and pasting REM statements, so I'm very familiar with how to do that...I had to discover that feature in EightyOne since zxtext2p.exe couldn't handle the long REM's that p2text.exe gave -- I am used to using those tools with the ZXSimulator and in fact, it won't be able to read .b81 output with it's \?? format since I didn't implement it.
I do have an Elite.bas version that has fixed MCODER2's idiosyncrasies. The Elite.p that is included in the zip is the original version that I developed as a demo BASIC for the ZXSimulator (to make sure it behaved like a ZX81) and it uses OR's, STOP, and inequalities in assignments, etc... all things that won't work in MCODER2.
First off, my experience with MCODER2 really left me impressed, esp with it only being about 5K in size. I recently played around with SuperCharge on the QL and that also worked pretty well, but is much larger in size. Both have a similar approach with SuperCharge using the QL's screen memory to stick the compiled code and MCODER2 using REM statements. Back in the 80's I wrote an assembler (still need to get it successfully off a tape) that had to generate a REM statement and size it to put the assembled code into, so I kind of know how MCODER2 is generating those new "2 REM" statements after the first pass to store its compiled code into.Fruitcake wrote: ↑Tue Mar 15, 2022 2:23 pm When I used MCODER2 back in the 80s I only had 16K RAM and so also struggled to get a good sized BASIC program to compile in one hit. Trying to split it into chunks was painful and so I never really pursued this, so it's interesting to read you've been having success using that approach. Good work! It's nice to see these original utilities still being used.
The way I ended up constructing my compiled version of Elite was definitely an interesting approach that forced me to think about how my game was developed. I can imagine if I were to write it from scratch in machine code, I may actually divide it up that way but with BASIC, you can just be a bit lazy where you place things and when you call things.
However, the steps you laid out to get it to work in 32K+ memory are also pretty neat. I love discovering those approaches to get around system limitations. I had planned to do a video on my process and now I'll fold in both processes since it might be useful to see both ways -- well, my way really only for those that want to see how it would have been done back in the days if you only had 16K. I'm imagining lots of pen to paper, and having to save each iteration, load it back in, and type in new code... I'll be sure to reference your help for the second approach...much appreciated.
)