GARTHWILSON wrote:
That should work well, BDD. Is the M/L monitor in ROM? If so, it might be good to just make them separate ROMs and use them one at a time. The Forth kernel has all the same functionality plus a load more, except that if I add a file system for something like SD card, I would need help for that. That's an area I have not touched except for doing a FAT-less file chain in battery-backed RAM for a product in the late 1980's.
The monitor is in the same ROM that has the BIOS but is logically separate, meaning the monitor calls BIOS services for I/O and such, but the BIOS has no awareness of the monitor.
If control is given to a RAM-resident program (e.g., a Forth kernel), the monitor is out of the picture except for it being the default target of a BRK or COP, should one be encountered in the running program. The BIOS provides TIA-232 and SCSI I/O (all I/O being interrupt-driven), maintains an uptime counter, and provides a number of services that must be explicitly requested via JSRs. The front ends of all interrupt handlers are vectored through low RAM so they can be pointed elsewhere—the BRK and COP handlers are pointed to the monitor following reset.
So what I am saying is the Forth kernel can be run in RAM at any convenient address, subject to staying out of the way of the BIOS data structures, with about 51K of free RAM for code and data. If the goal is to ROMify Forth and eliminate the monitor (ROM is 8KB, so it's not possible to have Forth, monitor and BIOS all sharing the same ROM), then the ROM has to include enough of the BIOS to provide essential I/O services.
As V1.1 supports SCSI I/O, the Forth kernel could include extensions to provide mass storage to user programs. SCSI disks are readily available from many sources, so there's no reason to scrap that and replace it with some other type of storage. I'm not a Forth user, so I don't know enough about it to know if the core has words to read and write external storage.