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.

I have updated the web-based simulator (https://gfoot.github.io/gf-rv16/) with some more features:

• New "Machine Code" window shows the source code that was assembled along with the machine code bytes for each instruction, and highlights the currently-executing instruction
• Breakpoints - click to the left of an instruction in the Machine Code window to set or clear a breakpoint, then "Run" mode will stop when it gets there
• Step through by source instruction (skipping to the next pseudoinstruction), machine code instruction (what you'd normally expect) or hardware cycle
• Speed control for Run mode - you can adjust the simulation speed, making it run quickly so that you can see the results sooner, or slowly so you can see what it is doing as it executes the program

Very much liking the web emulator!

I'm with you that serial I/O is a good starting point, sufficient for lots of fun, and of course one can even implement a filesystem running over serial.

Just for interest, we did wonder, discussing this, whether it would be fun to hand-write a Tube ROM and make an Acorn-style second processor with this CPU - could be in C on PiTubeDirect or in Verilog on FPGA. It's been done before, for F100 and OPC at least. (But perhaps not for 65Org16 - yet!)

(When I say 'we' it's some combination of me, hoglet, revaldinho, dominicbeesley)

The point, of course, is to embed the new core in an existing platform, namely the Beeb's second processor, and Acorn's OS and filesystems. Gives you an APi to keyboard, screen, storage, serial connectivity. Perhaps mainly of interest to people already living in the land of Acorn, or nearby. But it does give ready portability into implementations for emulation, webulation, TTL, FPGA, and PiTubeDirect.

A Tube ROM is usually about 2k of binary. You don't need all of it to show proof of life, of course.

I've a vague idea one can write some (most?) of a Tube ROM in C, which is of course easier, but not sure where to look for that. And you do need a working C compiler.

I had thought about doing something like that but using Dominic's Blitter board that he leant me... too many years ago. I feel bad because I've had it all this time and not really done anything useful with it. It would require writing more OS code than a Tube ROM would, but I still think it wouldn't take very much code to at least initialise the system and get the basics up and running.

I don't have any experience with FPGAs and Verilog so it's not a trivial step, but it could be a good time to learn that. I am also conscious that this design wasn't really meant for that environment, and the compromises I've made were in order to make it practical to implement with less scalable technology, i.e. CPLDs or 74HC logic, so an FPGA implementation might feel unnecessarily restricted - the FPGA might be able to easily support a wider ALU, and a dual-port register file, and then be able to execute most operations in a singe clock cycle. But even if it feels like not the right design for an FPGA, using the FPGA could still be a great way to prove it out more.

Ah, yes, good point - FPGA will usually start off larger than your design or project, and it's a bit of a trap that one might to make use of more of it and undertake a bigger project. Self control might be the only answer - or perhaps buy the smallest FPGA you can find!

If you're not already up with verilog and FPGA then this might be an entirely unwelcome sidequest. (But I note in passing that myHDL and amaranth both offer, apparently, ways to work directly from Python.)

On the other hand, FPGAs are a most wonderful way to create fast hardware with very low technical turnaround time - no fabrication step, no wires falling out of breadboards - so as and when you do want to venture in that direction, the rewards are there.

Just watch out for that scope creep...

(On the topic of a Tube ROM, I think implementing just character read and character write would get you quite a long way. Not a great deal more work than a serial interface.)

On the general trajectory of bringing up a new implementation of a new architecture, I'm a proponent of starting with an emulator, and then an assembler. You are of course already well past that point. And most of my preference is based on pitifully little experience, so it's not worth much.

One option is to design a generic interface card, with a FPGA module. This way you could swap out for a bigger FPGA if you need one.

A fully pipelined single cycle RV32 processor will use 1-2k LUTS and run at 50-100Mhz. That's possible on a low end FPGA and probably a few hundred lines of Verilog.

Depending on your goals that level of performance may, or may not, be a good thing. However I do think FPGAs are great choice as a peripheral controller for a TTL computer. Especially video.

I'm reminded of Arlet's rather splendid quad-CPLD 6502, where it turned out the decomposition into four parts, with limited wires between, worked out rather well. Just possibly a RISCy processor could do similarly, perhaps with more CPLDs. (We should note that availability especially in 5V flavours is quite limited these days, but there are options - AFAICT at least Lattice ispMACH 4000V/B/C and Microchip/Atmel ATF15xx and maybe Intel/Altera Max V.)