mos_8502 :verified: on Nostr: The way we are doing the Sentinel 65X kernel is roughly as follows: · Interrupts to ...
The way we are doing the Sentinel 65X kernel is roughly as follows:
· Interrupts to handle repetitive kernel tasks like refreshing the VRAM in text mode and advancing the system clock
· An internal API for kernel code to call which has no unified calling convention
· A public/user-facing kernel API that is gated through the COP software interrupt instruction which has a consistent calling convention
· Baked-in drivers for all the basic hardware, with defined API for interacting with them which, because it uses the COP interrupt, does not require remembering any particular jump address, which means the whole of the internal code layout of the kernel can change version to version without breaking ABI compatibility
· ANSI/VT colour terminal emulation in the kernel to make TUI applications easier to make
While the specifics of the operating system to run on the kernel are undecided, and the final decision is up to Becky (npub1dmy…5tze), the feel of what we are growing towards is in the general CP/M or MS-DOS mould, though definitely compatible with neither. My own preference would be something like MSX-DOS but with long filenames. Enough of an OS to support a C SDK, not so much that it burdens the system, and nothing that stops a determined coder from pushing the hardware to its limit.
The CPU in Sentinel 65X wildly outperforms that in any MSX system, so that level of OS seems appropriate to me. I am open to other ideas, though -- if someone wanted to do a port of V6 or V7 Unix or the like, I would support them in it however I could.
#Sentinel65X
· Interrupts to handle repetitive kernel tasks like refreshing the VRAM in text mode and advancing the system clock
· An internal API for kernel code to call which has no unified calling convention
· A public/user-facing kernel API that is gated through the COP software interrupt instruction which has a consistent calling convention
· Baked-in drivers for all the basic hardware, with defined API for interacting with them which, because it uses the COP interrupt, does not require remembering any particular jump address, which means the whole of the internal code layout of the kernel can change version to version without breaking ABI compatibility
· ANSI/VT colour terminal emulation in the kernel to make TUI applications easier to make
While the specifics of the operating system to run on the kernel are undecided, and the final decision is up to Becky (npub1dmy…5tze), the feel of what we are growing towards is in the general CP/M or MS-DOS mould, though definitely compatible with neither. My own preference would be something like MSX-DOS but with long filenames. Enough of an OS to support a C SDK, not so much that it burdens the system, and nothing that stops a determined coder from pushing the hardware to its limit.
The CPU in Sentinel 65X wildly outperforms that in any MSX system, so that level of OS seems appropriate to me. I am open to other ideas, though -- if someone wanted to do a port of V6 or V7 Unix or the like, I would support them in it however I could.
#Sentinel65X