Estimated lift to hook an external bus to the SOC?

[m00dawg]

I watched Shawn H's excellent 2 part series on the FemtoRV where he goes into good detail on how the MMIO I/O addresses work. I was curious what the lift might be to expand that to a larger more standard memory area as well as exposing a chunk of memory out to an external address bus?

This is sort of an eventual goal but was trying to find hardware that might fit both the short and longer term plans. Specifically, I was thinking about how I might add a RISCV co-processor to the Comamnder X16 retro computer. I was thinking of making an expansion card housing say a ULX3S and connecting the system bus (along with IRQ and some other signals) to the FPGA. That would allow it to be used for lots of things, but in my case, playing around with how I might write hybrid programs (letting the 65C02 handle kernal calls and things, but using RISCV, along with its local expanded address space (TBD how I'd implement that, SRAM via LUTs, BRAM, SDRAM, external SRAM, etc.) combined with the X16's which might side within an expanded 32-bit region (so say 0x900000-0x90FFFF).

Raw speed isn't the goal and I had thought of simply using the X16 system clock (8 MHz). The X16 already has a Lattice FPGA for video (the VERA module) and it runs internally at a higher frequency than the bus so seems like running at different speeds is perhaps also possible.

All told though the Femto SOC isn't setup to do this, on purpose to save LUTs. I was looking at the picorv32 and others but the Femto documentation is soooo good I was trying to sort out how much of a change might be required to update the memory handling to achieve something like the above. I haven't touched an HDL since college (some time ago) but reading the Verilog makes me think it wouldn't be an extreme lift but thought I'd ask.

I realize it's a newb sort of question and probably wouldn't be asking this if the above didn't hinge on which FPGA solution to consider purchasing for when I might be ready to tackle something like this. Apologies if this is not the place to ask such things.

Thanks!

[BrunoLevy]

Hi !
It is an excellent idea, I love it !
There are different things to do:

• from the SOC side, it is reasonably easy, what needs to be done is mostly creating an additional bit in the address bus, and say that if this bit is 0, it is normal operation, else it is an address for the external bus. Unlike the SOC that has an input data bus and an output data bus, the external bus will be bidirectional, with three-state IO-pins, so it needs to be configured as input for a read operation, output for a write operation and high impedance if the additional address bit is set to 0. This part is simple (it is a matter of a couple of lines of Verilog)
• but we need also to understand what happens from the XC16 side (and it is a complete mystery for me). A good starting point may be to take a look at how the VERA graphic board works, then we can learn more on what the XC16 expects from an expansion board.
• finally, we will probably need some interrupt support, our board may be both a source of interrupts and receive some other interrupts from the XC16. For this, you may need to use @Mecrisp's versions of femtorv (intermissum, gracilis) that have support for an external interrupt source.

[m00dawg]

Thank you Bruno! Awesome it sounds like I wasn't too far off base! Though I hadn't thought about tree-state and high-Z things. Super good point, thanks for that!

On the X16 side, the card edge connector exposes nearly the whole smash (if interested, you can see the full pinout here: https://github.com/X16Community/x16-docs/blob/master/X16%20Reference%20-%2014%20-%20Hardware.md#expansion-cards--cartridges) and yep this does include both IRQ and NMI for interrupt handling. Notably it also includes RDY which can pause the 65C02 or 65816 allowing the RISCV to take over execution. There has been talk of an 816 upgrade path (this is in part because the smaller X16's will not be nearly as easy to upgrade and it would be more economical to ship with an 816 as a result) which also means the COP instruction could be used though I think using the MMIO range along with interrupts and RDY may end up being the better option.

For VERA, yes it will be a great thing to compare to though I don't think it can see the entire bus. MMIO on the X16 is divided into 16-byte chunks which includes the VERA. The expansion card connector has IO# lines to activate address ranges to simplify decoding as well. I believe VERA may be doing something similar. But I suspect the timing will be similar, noting pretty sure the VERA also uses bus transceivers since the X16 bus is 5V. So that'll add some latency.

One idea I had to try and walk-before-run was to consider making a simple accelerator card. So instead of having the RISCV CPU take over and run arbitrary code, I can start by having it handle some operations the 6502 can't do as fast, such as multi/div or even floating point if using a big enough FPGA.

I was thinking there the MMIO would be something like:

$xxx0: Command
$xxx1: Control
$xxx2: Status
$xxx3: Width
$xxx4-7: Value1
$xxx8-B: Value2
$xxxC-F: Result

Command being a simple value corresponding to a function (so 0 = do nothing, 1 = multiply, 2 = divide, etc.) - a simple opcode more or less. Status would then have flags such as interrupt set, result available. Control would be to tell it to execute, clear IRQ, etc. Once it's instructed to do so, it can go do the function and latch the result and optionally assert IRQB (if the operation was going to take several clock cycles so the system can do something else during).

My thought was to have these values latched so similar to external registers/memory. That way if using interrupts on a multi-cycle command, system can go do something else for a while. And/or can set a value and look at it after a guaranteed time has passed.

RISCV isn't necessarily needed for this where a bespoke solution is possible. That might be a good exercise on its own but using RISCV also means I can get some hands on experience with writing RISCV assembly (a big goal) to read those registers and do stuff, which itself could be things more than just instructions natively available with RISCV. The VERA has an "FX" mode to help with some math accelerations common for line and polygon drawing for instance, but it's basically out of available LUTs to add many more features where an add-on card might be able to add more for folks that want it.

The ultimate goal is still to plonk the whole thing on the bus so a RISCV CPU can take over program execution (with an extended RAM space as well) and passing control back and forth to the 6502. Definitely a "because I can" though. I actually quite like the X16 as is but since it has a fully exposed bus and expansion cards, it really makes for a fun place to do these sorts of oddball things.

[Mecrisp]

Maybe you could add a funny hardware feature to your X16, I am thinking on having two fast digital-analog converters for vector graphics, as I wrote a RISC-V vector demo for the Lovebyte party last weekend, or include one of these HUB75 protocol 64x64 RGB LED matrix display panels. When trying to run the FemtoRV core as coprocessor from main memory of the X16, using the 8-bit-data and 16-bit-address bus, you need additional logic for handling 32 bit instruction fetch, memory read and memory write over 8 bit data lines. Split it into four separate bus cycles. Well possible, we execute code directly from SPI flash and SDRAM memory, all official FemtoRV cores offer busy signaling. Vice versa, stopping the 65C02 and using the complete X16 as peripheral(s) to the RISC-V, running from internal block RAMs, might be easier. Another idea is to have a shared dual port memory area in the FPGA, which is mapped to the 65C02 bus and can be accessed 8 bit wide from the outside, and executed 32 bit wide from the inside. You have many possibilities as soon as you connected the FPGA to all the bus lines. Just keep in mind that 65C02 runs on 5V, whereas most FPGA boards are designed for 3.3V signals. You need high-Z capable tristate level shifters!

[m00dawg]

Ooh the dual port concept is a good idea! Indeed using the 8-bit bus in RISCV mode would be a bit weird. In many ways simpler though. The 6502 has multi-width instructions and cycles. I did some basic exercises converting some routines I use (in DreamTracker, my X16 based music tracker) to RISCV. The end result required both more memory and instructions than the 6502 version, though these were small routines. I suspect RISCV programs will end up larger than a 6502 equivalent so one thought there is to leverage the 8k banking to store RISCV program code, to use the 16k cartridge ROM or RAM space optionally or, perhaps most likely, to load RISCV program code into its own address space using some sort of loader program (copying data to RISCV maybe 8k at a time through the banked RAM).

That means most of the RISCV specific app code can be in the RISCV's own native memory space and the X16's address space can be used for hardware MMIO and for data that needs to be shared between the 6502 and other devices. That helps with instruction fetch but still some hoops to jump through I think beyond just lb and sb I suspect.

Coordinating program execution between the 6502 and RV is where I feel things will tend to be the most complicated. Noting writing to expand x16emu to include support for a RISCV card is not a small task so debugging may have to be done on the real hardware. To avoid having to write basically a copy of the KERNAL, I was thinking 6502 would continue to be involved when needing to make most KERNAL calls (including file handling). Some specific routines may need to be implemented for RISCV to avoid constantly switching back and forth (though maybe that's ok, I'm not sure), such as reading the keyboard buffer.

[Mecrisp]

Coordinating execution can be done with an additional run/stop/reset register, this isn't a problem. Or you can handle it in a way that a 6502 jump into the shared address will trigger logic watching all the bus wires, putting the 6502 to halt, and cause the RISC-V to execute said address. If the RISC-V returns, a ret opcode is put on the bus, and the 6502 continues. This way you can "call-v" :-) I think having sb/lb/lbu only when accessing the X16 memory space from within the FPGA is fine if you do not try to directly execute it.

True, RISC-V code tends to be larger than 6502, especially if you directly translate the idea of the original code one-by-one. But hey, you can do a lot in 8 kb RISC-V assembly already!

[Mecrisp]

If you follow your ideas, remember that the FPGA is much more capable than the whole X16 (except its VERA), so you can attemp to do totally crazy things :-)

[m00dawg]

Yep that's similar to what I was thinking. The coordination on the X16 side is still slightly nebulous though the reason for RDY being on the expansion card pinout was for this very purpose though no one has made use of it yet and if there ends up being an 816 upgrade path, the COP instruction might come into play.

The 816 upgrade discussion included a similar idea as mine except having an 816 on a card plus additional SRAM for an expanded address space and being able to use the 816's hardware paging. We might still see this as a power user option though I think the normal 816 upgrade path will just be a CPU swap on the X16 (which still provides a lot of 816 features that way).

I hadn't thought but I guess I might need some glue logic if using RDY to make sure that gets asserted within a timely manner. Writing say a 1 to a control address in the IO space for the card would cause RDY to get immediately asserted (or rather assert right when it needs to be) if it takes a few cycles for the RISCV to start doing it's thing.

A lot to think about. I'm a ways away still but I'll likely be setting up a git repo to start writing down notes and things in prep for all these things. Does seem like a neat project even if it's a niche on top of a niche.

Agreed on RISCV code size. As much as I really enjoy 6502 asm, being in that world for a few years know took some time to sort out haha. Like the branch instructions. I'm so used to 6502's simplistic status flag branching I had to stare at the RISCV branch instructions for a bit to realize the compare and branch is all done in one instruction ;) Also had to learn how to use pointers and indexing memory :P 6502 tends to force some design decisions, as does the X16 with the banking. I quite like the banking (one of my fav features of it oddly) but the way I have my data structures setup if very 6502-like, making heavy use of the indexed addressing modes. Took some time starting at my 6502 to figure out how to do the same thing in RISCV. Not hard and actually arguably easier than on the 6502 but it was a bit of a paradigm shift. It's why the idea of a computer that has this hybrid of the old and new at the same time is hilariously compelling.

[Mecrisp]

...for playing with RISC-V assembler, a RV32IM emulator written in and running on the 65C02 itself might be a slow and horrible, but easy solution, offering single-step debugging and advanced insight...

[m00dawg]

Yeah the Eurorack and X16 are two very different use cases there. The former I think will be a much easier lift and yep I was looking at Icebreaker. I ended up ordering an Upduino to start with but on the Eurorack side, if I find something I like, I might explore the SMD pick and place services some fab shops are doing to get all the SMD bits presoldered. Or see if I can find a small FPGA package similar to the ItsyBitsy M4 (that's what I'm using now for the current version).

For the X16, I'm far too invested in DreamTracker to fully switch platforms :) X16 is kind of a different solve though. The whole thing can fit inside and FPGA (and the smaller versions of it will be just that) and run at a bazillion MHz though the creator (8-Bit Guy) wanted something that felt like a vintage retro machine, down to the simple (PET inspired) architecture and low clockspeed by modern standards, but with new parts that were less likely to fail. He wanted to use as few CPLDs, FPGAs, etc. and as much off the shelf hardware as he could. Practicality meant that it mostly met the goal, but not fully (noting the VERA). The early idea was very much "this is your toybox, these are your toys, go make something" meaning it hard plants the goal posts. From a demoscene perspective, that's kinda nice with the combined heritage of being 6502-based. Early conversations while it was being designed often revolved around adding features (RISCV included) but most of the time the conversations ended with "why not just use a modern computer" ;) Whether or not it catches on enough for the current demoscene or folks at large is another story, though it's selling pretty well. Definitely not everyone's paradigm though.

[Mecrisp]

We love crazy creations here, and you get our assistance in any direction you might choose to go! :-)

[m00dawg]

Indeed! The docs is what got me here ultimately and it's been really great to see some of the discussions taking place here. Huge thanks to yourself and Brunco for both the fun conversation, help, and great ideas! Really quite looking forward to getting my hands dirty with this as it were.

[Mecrisp]

You are welcome! For custom oldschool phantasy consoles, there are so many options and tastes, diversity rules :-) I like the idea of the X16 a lot. Personally, I am currently into into vector graphics intros using the GD32VF103 microcontroller.

I have three more pointers for you - sizecoding intros for RISC-V, and my own takes of a phantasy RISC-V based "retro style" machine:

https://www.pouet.net/user.php?who=105292
https://codeberg.org/Mecrisp/Nandland-RISC-V
https://github.com/badgeteam/mch2022-firmware-ice40/tree/master/projects/RISCV-Playground

Note: I cannot recommend a HX1K based board, the FPGA simply is too small, everything is the logic equivalent of a sizecoding challenge on that, but you might like the ideas!

[m00dawg]

Oh yeah I got distracted by external stimuli (work :P) but forgot to mention, the vector thing sounds awesome! I have an old Space Duel cab I inherited from my aunt. Long story that thing but I've somewhat restored it. Nothing quite like vector graphics and it's something that's been missing from the gaming landscape for a while I think! Some folks on the X16 side have talked about vector graphics before so if you ever decide to do that, I think you'd make some folks happy!

I'll def check out the links after the day hustle. I took a quick peak and yep looks like some really good and interesting stuff!

[Mecrisp]

Bruno has done an excellent course supporting the Icebreaker, but if you feel lost in all the configurable options, maybe have a look at a my design for the Icebreaker board, with a different IO layout:

https://sourceforge.net/projects/mecrisp/files/mecrisp-quintus-1.0.5.tar.gz/download
--> mecrisp-quintus-1.0.5/icebreaker/icebreaker-verilog/icebreaker.v