WildChild83 / BlastForth

BlastForth is a development kit for the Sega Genesis/Megadrive system, using the Forth programming language.
MIT License
3 stars 0 forks source link

Issue running on target hardware #2

Open kbanks-krobotics opened 1 year ago

kbanks-krobotics commented 1 year ago

Generated ROM image for your Hello World example runs in many emulators, but not on a real Genesis stackup (at least, not with code loaded via a MEGA EVERDRIVE PRO which is how I test). It also does not run in REGEN v0.97d if you set that emulator to flag illegal memory accesses (in regen.ini set EmulateLockups=1 ). I have debugged it far enough to tell that some code is reading from uninitialized memory (perhaps a variable or a value?) and then using that as a destination to write to. Code in system/finalize.fs preloads all of RAM with 0xdeadce11, so the bad write is to that address. Since I don't have time tonight to run this to ground, a hacky work-around is to change the sentinel value from 0xdeadce11 to 0xff8000, which is at least legal to write to and the code can proceed onward. Here is the relevant code snippet from finalize.fs for the work-around: \ clear System RAM and CPU registers \ WAS: \ rp clear, $deadce11 # d1 move, d2 64 kilobytes cell/ for d1 rpush, loop \ CHANGED TO rp clear, $ff8000 # d1 move, d2 64 kilobytes cell/ for d1 rpush, loop 1) Posting in case this helps someone else, plus since you are more familiar with the code you may come up with a fix quickly 2) I have been porting this to the Genesis, in case you are curious: https://github.com/RickCarlino/Cosmic-Conquest-1982 3) I'll also take this opportunity to say NICE WORK! Kevin Banks

kbanks-krobotics commented 1 year ago

Found the root cause: routine zero-controllers in file system/input.fs is wrong. The following shows one way to fix the issue, there is probably some way to get the RAM address of a value and fix it with a smaller change.

(code snippet from modified input.fs) \ The following is wrong, and results in an attempt to write to memory address deadce11 \ I assume controller1-4 were originally variables (in which case the code would work), \ but later they got changed to values instead of variables \ : zero-controllers ( -- ) controller1 [ 8 cells ] literal erase ; \ The following works, and as a bonus does not make assumptions about memory layout : zero-controllers ( -- ) 0 to controller1 0 to controller2 0 to controller3 0 to controller4 ;

With the above change, the generated ROM runs on real hardware (without the hack I posted for system/finalize.fs)