Why program a full custom design? Just pick two modes, say text and graphics, or text and game sprites.
Back in the early 80's you had just a small amount of video ram, and that limited what the video controler
chips could do. With more memory (bank selected) you could have several game overlays each with its
own custom sprites.

Well, Amiga for example had "copper" which is basically what I just described, and you could use it in games to do a lot of raster effects, since you could change the VDP registers at precise locations as the screen is drawn. It seems useful, and I am guessing this is the precursor to fully programmable graphics pipelines we see in modern GPUs.

In my case I just want to draw the frontpanel with it. But maybe there's easier ways.

Anyway, next video is up. I implement relative jumps. I also added chapters to the timeline so boring parts can be more easily skipped. And of course I did a bit of work between episodes that I show at the start of the video.

[035] Relative Jumps! https://youtu.be/51L-nHAbY7M

I have a couple more episodes recorded... not sure when I will get them edited and put up.

The copper was an interesting thing: relatively simple, pretty useful. But note that one or two mode changes or palette changes are often done on Acorn's BBC Micro, just using a timer-based interrupt. The key to that, probably, is that the 6502 has fast and moderately predictable interrupt response, which the 68k doesn't.

This is something I don't really understand. When I design something, I work in VHDL on a text-browser and I pass the project to Modelsim which generates a waveform where I can select/deselect signals, and that's all the debug information I need!

For whatever reason I like blinkenlights. So a fairly important design goal is to have a front panel with lots of LEDs that blink. I am perhaps a bit obsessed with that and should just get the major features of the CPU working and stop spending so much time on the front panel. But well... I am enjoying it

I dunno, I am a very visual and creative person. I like to build things that are aesthetically pleasing. And it's one of very few ways I can get help from my wife on this project

So, next video is up. I go into function calls, and I am doing the usual RISC trick of just putting the return address in a register. I also expanded the register file to 16 registers, as well as did a bit of a video tour of the debug bus I built.

[036] Function Calls! https://youtu.be/Gk25kKVGM58

I have skipped over the two videos I pre-recorded for now, as they are on the GPU / VDP, so I think I will have another mini-series on that later. In the meantime I am trying to get the major features of the processor in a good state to start writing some serious software.

Oldben, I thought about what you said, and I think I will just do a frame buffer instead. So I am going to have the debug info rendered to ASCII, then written into the frame buffer at the correct offsets, and then render the frame buffer each frame. I think that will be much simpler than building a copper co-processor to do it. It should also be trivial to add support for the CPU to also write to the frame buffer.

In my case, I wrote a "text VDU", Video Display Unit.
It's a simple engine with

• vertical scroll or page mode
• ring text-buffer, or two text-pages
• y=40 columns
• x=25 rows
• blinking cursor
• loadable font
• hardware cursor at (x,y)

It's enough and exactly what I need for writing a text editor in assembly for my Softcore.

I live on the west coast, and we had a crazy heat wave recently that's taken most of my time. But it's mostly passed now.

In the past couple weeks I have been tinkering a bit with rebuilding the VGA frontpanel to use a framebuffer. And then in order to draw on the framebuffer I ended up having to build a microcoded machine. I didn't record any of this because, well.... work has been crazy and so has home life. So yeah.... But it is up on github if you want to take a look.

Here is the display microcode:

https://github.com/rj45/rj32/blob/55f430e53bfbfe214fd60e7d2d5f7fddc9350121/microcode/microcode.asm

That's just compiled with customasm, so that's super easy.

Here's the circuit that runs the microcode from the ROM:



So yeah, that's my progress update. I have a few days of vacation now, so I am going to try to record some more videos.

I do have some difficulty on projects every 3 months. 3 months ago I was at the 3 month mark and I decided to switch from 32 bits back to 16 bits and implement a MISC processor. Well, it's been 3 months since that direction change. I am likely going to have to do another direction change in order to give myself another 3 months of energy on this project.

I have been super interested in retro computers lately. I have a mostly complete 16 bit CPU, and a mostly complete retro VDP with tile based graphics and text. For some reason I want to build a retro computer. Maybe that's the next step? Building a retro homebrew computer from the parts I have built thus far? What do you think?

I don't think I will have time to build the CPU in discrete TTL logic. So I may need to cheat by putting an FPGA on the board. But maybe version 1 uses an FGPA and some future version (maybe in 3 months?) could go down the road of trying to get rid of that FPGA.

Building a computer is a nice idea - it makes concrete some of the reasons for some of the tradeoffs.

And sure, use an FPGA. You can re-do later in CPLD or TTL if you like. As you say, momentum is key.

PAL's like 22V10's are a nice compromize. I use Wincpul and a TL866 II plus programmer on my new machine.
The FPGA software could not port over.

Personally, I am still working on my ISA. It's literally an odyssey story.

I am currently focused on enforcing stack protection hardware solutions without introducing too much complexity.

Easy to say, hard to achieve, but I like simulators, that's how I do operate.

I am scared about projects like OR (Open RISC). I see it implemented by Allwinner (a Chinese company) in a couple of their SoMs, but the Allwinner's OR is very very bugged and ugly core. It comes with too many features throw on the silicon quickly and poorly tested.

So, there's a funnel shifter design several pages back in this thread that I finally integrated into the processor. It only cost a couple MHz which I was surprised about.

For now I just have the traditional shift left, shift right and arithmetic shift right instructions implemented, but it seems like a shame to have the power of a 32-bit funnel shifter in the CPU and be unable to make full use of it from the instruction set. I am open to ideas for improvements.

[037] Funnel Shifter! https://youtu.be/3_ZEnyfkXH0

I have also been researching creating a PCB. I have created very few PCBs before, and the last one was years ago. I also don't have much by way of surface mount soldering equipment. So I am leaning towards an FPGA module of some sort.

I think I'd like HDMI, USB HID host, a fair bit of RAM and some expansion capability with a variety of existing peripherals.

But I am also thinking I might be in way over my head. In some ways the FPGA dev boards I have are plenty good enough, and I can expand them with PMODs. So... I dunno if I want to spend a huge amount of time making a better FPGA dev board. I guess I am only thinking about it because of a comment on one of my videos. So maybe I should let that go I dunno.... What do you think?

Spend some time on the bus and bus interfaces, and the clock speed used. (E)proms tend to slower and harder to find
than main memory. I need 120 ns parts and they are hard to come by, ball park planning wanted 150 ns parts
but detailed timing did not have any margin for clock skews and logic interconnect delays. Right now I am sourcing
memory and hard to find chips and Oscillators seem to be only a few frequencies.

PCBs are much more accessible these days. But I think I'd recommend first getting to grips with an FPGA design flow and toolchain, and then get to grips with an FPGA dev board, before embarking on your own FPGA PCB.

I would spend time learning Verilog instead.