When I have a ton of peripherals in my system, I use bus bridges to split the peripherals up into smaller groups. It typically adds a cycle or two to the I/O access, but it keeps the clock rate high and there are fewer routing issues that crop up. There is a video bridge that connects most of the video controllers to the system, a slow speed I/O bridge for things like keyboard and mouse input and LED display outputs, a bridge for storage media, and another bridge for miscellaneous I/O.

So, like this?



And then build a tree of them?

~~~~

I did have the thought of making a super simple microcode state machine that runs as the screen is drawn. It could take simple instructions from a ROM like "wait for Y to equal ____", "wait for X to equal ___", "draw value from debug bus at index ___ if condition ___", "draw text ___", "jump to ___".

An advantage to this is I could build a debug bus, similar to what's described on the ZipCPU blog. This could gather all the debug info and reduce the number of outputs on the CPU itself, and there could be multiple consumer implementations, like a serial one as well as VGA.

I think they did a similar thing in The cheap video cookbook. Some computers that will remain nameless with z80 used that display idea.

You could connect all the signals together with a parallel to serial shift register. Then dump the bits as black or white dots on screen, or alternate the color every so many shifts to make it easier to correlate the the display pixels to debug signals. Load the shift register on hsync, then shift out as long as the display is enabled.
It would give a bunch of stripes down the VGA display. Really primitive, but may be useful for debugging.

Otherwise I think something along the lines of a text mode display controller would be needed. There are some text mode controllers already available at opencores.org. As it scans memory to look for characters to display, decode the address scan and send back data based on debugging signals.

So I already have text generation working:



I am just asking if there's a more efficient way to generate that text given it's pulling the text from a couple dozen memory mapped peripherals on a long bus, and it does so synchronously with the dot clock, so it's a tad slow. Each peripheral has its own multiplexer for the bus. So that's probably not the best way to do things.

Cool display. I like the font.

You can probably put registers in-between the muxes so there isn't a whole bunch of them cascaded, then read the value every N clock cycles where N depends on the number of registers. You could also feed the values into a dual-port memory so that they can be read at the dot clock rate. The values probably don't need to be sampled at the dot rate as nobody can see signals changing that fast.

I like the font too.How come they never made drivers for the n segment displays?
For any kind of display, you need a slow refresh rate. 30 hz or less. Having a good looking front panel
is a lot of work. Ben.

No video this week. I tried a few times to edit it down and just... well... haven't been in the mood I guess. Work is taking a lot out of me lately.

I have a video recorded on adding a logic unit to the ALU, so the ALU is now complete apart from shifts. I also recorded a video on adding relative jumps. I'd like to also record one on adding a link register for function calls, but haven't yet.

And for fun I recorded some footage of upgrading the GPU / VDU to have a palette ROM in preparation for adding tilemap support. I think it would be fun to build something similar to the SNES / gameboy / gameboy advance PPU, but with a focus on the frontpanel specifically (and maybe a text buffer for printing to the screen).

I'd like to maybe support 3 shades (+ transparent) of several colours so that the LEDs look a bit more like LEDs. And it would be nice to be able to draw a background image. Block RAM that I can use as a ROM is pretty limited on the up5k though, so I am going to do it retro style with tile maps.

Next video is up, a shorter one. I implement the overflow flag, negative flag, signed comparison, and a logic unit with and, or and xor. Not is left out because it's just xor rd, -1.

[034] Overflow and Logic Unit! https://youtu.be/HezdglugQzk

Next up is of course relative jumps and after that the palette rom.

I think I have a pretty good idea how to make the GPU / VDU better with tilemaps and whatnot. I got a 4 colour 16 segment font to fit into a very small amount of ROM, roughly the same amount as before but with 4 colours instead of 2. Probably those videos won't be coming out for a couple weeks but we'll see. If I get on a roll with editing maybe I can put them out sooner.

So, work is still taking a lot of energy out of me. Hopefully I will have energy to edit up the next video soon. I need to re-record the intro to it I think.

In the meantime I have been doing some design work on a background layer for the VGA frontpanel. That's fun. I am not very good at it so it's taking a while but it's a nice change of pace.

I also uploaded the code to github, which you can find here:

https://github.com/rj45/rj32

I have been updating the documentation to be a bit better formatted and comprehensive. Feel free to poke around, fork it, submit PRs, critique it, whatever. I would be very happy to collaborate if anyone is interested. Hopefully it's okay, though, if you do contribute, that I record videos showing what you did and explain it.

In other news, I bought a new FPGA. It's an icezero from Trendz. I bought it because it has a ice40 hx4k which is much faster than the up5k I was using, and it has 512 KB of 10 ns 16-bit SRAM on it. I have a BlackIce MX as well, but SDRAM is a bit beyond me, and the icezero is pretty much the only SRAM ice40 I could find. So I have also worked to update the verilog build to compile for the icezero in addition to the icesugar.

Oh, nice - fast wide SRAM and a lattice FPGA.

Yeah, I don't know why it's so difficult to find any FPGA boards with SRAM these days. I'd gladly pay more for it.

The only other one I found (that has open source tooling) was a Xilinx board, the CMod, but the SRAM is only 8-bit wide, and there's only a single pmod with no HDMI. That and Xilinx support in open source tools is still very young.

My dream board is an ECP5 (or Artix-7) with lots of wide fast SRAM, at least 3 pmods, two of which are dual-pmod compatible, USB HID host for a keyboard, HDMI out, QSPI flash, SD card and USB programming. And that is it, nothing else to bring the price up.

Probably because DDRII/III comes with IP blocks. Kind of "click here, and there" on the wizard function, and your block will be automatically instantiated and programmed.



Talking about Xilinx, both ISE and Vivado come with a "personal license", and are excellent tools. The only limitation is that they come as binary applications, that's a problem for me when I want to use an HPPA-RISC workstation to develop things.

ISE and Vivado being chunks of x86 binaries for Linux, I have to use Qemu/x86 or an hardware x86 accelerator board on the ISA bus in order to keep decent performance. Qemu/x86, even on POWER9, is ... slow.

I have an old PCI-accelerator-card with a GEODE AMD chip on it. It works as a sidecar on my HPPA-workstation it's x86 compatible, and it's able to run Linux like a SBC. It runs at 600Mhz and it has 256Mbyte of ram. Not bad, better and faster than Qemu/x86 executed on a PA8900 at 1Ghz but not exactly brilliant, so I am currently using ISE on a mac-mini/intelcore duo @ 1Ghz with 1Gbyte of ram for the build of legacy things (Xilinx spartan3,6), while on my HPPA I write and simulate the VHDL code.

My i7 laptop comes with more ram and CPU power and it's dedicated to modern stuff with Vivado.

Vivado is more scriptable than ISE and I really love it, especially the integration with Modelsim

Yeah I haven't seriously considered using the proprietary tools. But that would open a world of older FPGA parts that are a lot less expensive. And of course IP blocks for various kinds of memory.

One issue is that I have a linux box and I am not willing to use windows. So I would have to do some research to find what proprietary tools work the best on linux.

But anyway, I don't need to do that right now. The icezero is more than enough for my needs currently, and the open source tools work great for it.

I spent some time converting the design over to using a debug bus instead of having tons of inputs and outputs being passed between components just for passing debug information.

I did not record this, it's instead documented on github here:

https://github.com/rj45/rj32/blob/main/docs/debugbus.md

I might record a summary video in the future.

But this paves the way to rebuilding the VGA front panel with a microcode "copper" co-processor reading instructions from a ROM. In the future this co-processor could be programmable by the main processor. I will try to record that work.