(no title)
crc_ | 2 years ago
From a quick reading of the linked system:
- ilo is little endian (for block & rom format); if you wanted to keep external compatibility, this would need to be dealt with. It's not difficult to do this; e.g., the 68k Mac version does this: fossils.retroforth.org:8000/ilo/file?name=vm/ilo-68k-mac.c&ci=tip
- this system presents some memory limits that would necessitate changes to ilo. Two aspects stand out to me.
First, separate code & data sections, with a limit of 64K each. ilo's standard memory area is a flat 65,536 32-bit words, needing 256K. This can be reduced, but will then not work with a standard Konilo rom. (The memory layout in the Konilo rom can be edited by modifying the assembly, but the overall reduction in available space will be very limiting for a full Konilo system. It'd be fine for using just the basic wordset in the rom or for assembly programs).
Second, memory is divided into 2K banks, so a bit of work in ilo may be needed to deal with that. The previously linked Mac version can deal with this as well.
- performance will be slow.
ilo is internally a 32-bit system. I've built & run it on an old 8088 MS-DOS system, but it's very slow there. I suspect it'd also be quite slow here as this is another 16-bit system.
I don't have the timings for this, but starting up a minimal Konilo system on an emulated Mac Plus (mini vMac @ 1x, emulating an 8MHz 68k CPU) takes 1m8s. It took quite a bit longer to start up on the DOS system.
Though again, this is when running Konilo. It'll be much faster with smaller assembly programs or things that do less i/o.
No comments yet.