oldben wrote:
What are your thoughts on memory expansion over 64Kb?
What about a operating system?
Many 16 bit computers of the 70's,had a 8" floppy for IO, thus you had a rather primitive OS,
like CP/M or OS/8 (PDP-8) just because you had no room a better OS or buffers for data.
FAT (12) worked for DOS only because reading word could be at a odd address.
Ben.
I haven't thought much about expansion beyond 64K - I think it's a bit out of scope. For that it would be better to build a full RV32I-based CPU, I think - and there are variants of that which have fewer registers (16) and 16-bit encodings for the most common instructions. But it would need to have wider internal buses to be any use, I think, as loading 32-bit registers through an 8-bit bus would be quite slow.
Another option would be something like x86 segmented addressing, or some other form of using two registers together to access a wider span of memory. At the moment I'm taking the lazy option though, which is that the CPU doesn't support it directly and you have to use external banking schemes somehow if you want to attach more memory.
For an operating system, so far I have written something basic that just does interrupt handling for asynchronous buffered I/O (well, input at least). I think it will grow organically, so at some point I might make the simulator support some form of file-loading. For actual hardware, if I ever build this, I'll probably use a 6551 for serial I/O (and rewrite the I/O routines to support that), and also probably hook it up to a 6522 for general purpose I/O, which could drive SD cards for example. In my 6502 projects I also often do file I/O through a serial connection to a host PC, and that could work too - the way I see it, all these things that I usually do on 6502-based projects are options that can be used equally well here, and I haven't really decided what shape an actual system would be yet.
Unaligned words are an interesting one - initially I accidentally made the simulator support them, so then I had to deliberately break it because it wasn't planned to be supported by the hardware! The issue is fairly minor though - it's just that when reading the high byte of the pair it would be necessary to add (with carry) 1 to the address in the MAR, whereas if I only support aligned reads then I just have to force the bottom bit to be set when reading the high byte, which is just a one-bit OR without requiring a full add. At the end of the day though it would only require a few adder ICs to perform the add, so perhaps I might as well just support this, to make some kinds of code easier to work with. And another way to implement it is to make the MAR actually be a counter rather than a normal register, and increment it directly when performing this sort of operation.
