bwinkel67 wrote: ↑Mon Mar 14, 2022 2:20 am
So the poke 16389,255 followed by NEW doesn't work in EightyOne since when you load in the program (not from a menu but in the emulator, which doesn't do an implied NEW) the 16389 location gets reset to 111 (i.e. PRINT PEEK 16389). I did try that trick and compiled my 8K program and MCODER2 just kept crashing. Note that I saw someone else post that POKE 16389,192 followed by NEW would work, and it didn't for me. As I posted earlier today, I've been teasing my program apart to get it to compile.
I've reproduced the issue you were seeing and so understand where the confusion is coming from.
When you load MCODER2, it sets system variable 16389 to $6F (111) and loads its Merge routine above RAMTOP. The idea is you can now load in a BASIC program and type RAND USR 32462 and MCODER2 is merged into your program at lines 0 to 3. A copy of MCODER2 is initially held in memory at ($6F00) 28416 so the largest BASIC program you can load is about 11K or so if you wish to use the merge facility. After merging, RAMTOP gets set at ($6F00) 28416. Saving out the program to tape, resetting the ZX81 and loading the saved program back in means RAMTOP will be restored to ($8000) 32768 and so extra RAM will be available to the compiler but at the expense of losing the merging ability (but then you no longer need this as your BASIC program is now merged). But since you are using EightyOne, you can completely ignore MCODER2's merge facility and do things in a much simpler way.
To get MCODER2 working with more than 16K RAM, do the following:
- In EightyOne set the RAM to 48K RAM
- LOAD MCODER2
- Using EightyOne's BASIC Listing window, save out as MCODER2.B81
- Reset the ZX81
- LOAD in your BASIC program
- Using EightyOne's BASIC Listing window, save out your program, e.g. YOURPROGRAM.B81
- Using a text editor on your PC, copy the contents MCODER2.B81 and paste it at the start of YOURPROGRAM.B81
- Save the updated YOURPROGRAM.B81 file
- Reset the ZX81
- Type POKE 16389,255
- Type POKE 16388,255
- Type NEW
- Load in YOURPROGRAM.B81 file, e.g. drag/drop into EightyOne or the Tape Manager, etc
- You now have a ZX81 with 48K and your BASIC program with MCODER2 loaded in
- Type RAND USR 17300 to compile
A BASIC program can utilise all the 48K RAM but the key thing is for the display file to never straddle across the 32K boundary; it must either be fully below it or fully above it. The instructions for the Memotech 32K RAM pack describe how you can push the display file above the boundary:
I'm not sure if MCODER2 automatically guarantees that the display file will never straddle the 32K boundary so you might need to use the Memotech technique to ensure it never does.
As a test of compiling a large BASIC program, I grabbed the original BASIC version of your game and ran MCODER2 on it, replacing each line it complained with any other one it was happy about to keep the program size large and kept doing this until MCODER2 was happy with all the syntax. It then successfully compiled the whole program. I couldn't properly run the compiled game as all the line replacements I had made meant it was performing gibberish logic but it ran enough to prove that this approach works for compiling a larger BASIC program.
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.
If only I had more than 16K back then... Still, I did managed to create a few games using just 16K. I still have the compiled forms but sadly no longer have the original BASIC listings for them. One day I'll have to see how feasible it is to reverse engineering a compiled program back into a BASIC listing...