Durexforth compatibility.

[Whammo]

I've studied your code- very cool! I think it is simple to make this work well with Durexforth.

If we not copy BASIC to RAM, and restrain logging to between HERE and LATEST, and keep BASIC banked out, I think it will be both compatible and useful in this context also.

I am capable of this but I thought I would bring it to your attention while the code is fresh in your mind. Thank you for your efforts!

[davervw]

Unfortunately it appeared to me that it was required to bank BASIC out when banking the KERNAL out. I don't see a banking scheme where BASIC is ROM, and KERNAL is RAM. The alternative would be to change to hooking only the vectors in RAM instead -- a different algorithm for those entries which do have vectors. Not all the entry points use vectors though.

Compare A000 (BASIC) to E000 (KERNAL) in this chart I composed from testing. This monitor runs in bank 5, while normal operation of a C64 at power up is in bank 7.

; bank A000 D000 D800 E000 ; 0 RAM RAM RAM RAM ; 1 RAM CHARG CHARG RAM ; 2 RAM CHARG CHARG ROM ; 3 ROM CHARG CHARG ROM ; 4 RAM RAM RAM RAM ; 5 RAM I/O NYBLE RAM ; 6 RAM I/O NYBLE ROM ; 7 ROM I/O NYBLE ROM

[davervw]

I hadn't seen your pull request until after I commented. If that works for you, great! Seems the $125f, $1261 are specific to Durexforth, so probably not generally useful to the rest of folks. Now, adding some variables, and a configuration byte could make the code work better for both communities. Another test could be to check if BASIC is already swapped out, and skip copying it. But unfortunately probably not one size fits all, unless able to better detect the situation.

Hope this works out for you.

[Whammo]

Actually, I just got it working with Durexforth. It's default memory bank is 6. I was having a problem assembling it on windows 10 and I just patched it. Skipping the move basic- Hard coding the lda 55's and 56's to lda #a0 and #00, and moving 'log_end' from $a0 to $bf to suit memory use.

[Whammo]