After you have the VGA text working well as display, you might try bit mapped graphics as a overlay done as a analog vector display. Here is PDP 1 sample video display.
https://www.masswerk.at/spacewar/640/?v ... ss=5:1,6:1

This doesn't make sense for me because this way there are collisions with chars.



This is probably what I would like to achieve, but I don't see the point in removing the first 31 unprintable entry which could be used for "special" chars.

Anyway, considering 128/32 = 4, this is what I would implement


This save one block of 32 entry, it cannot be implemented to save BRAM.

Basically, rom_font_addr <= in_addr{ not(bit6), not(bit5), bit4-0 }

This is what "addr - 32" does (basically it shifts blocks by 1), but I don't find an easy way to synthesize the "wanted" logic mapping functions without using LUTs

Are you going to support any other attributes for characters besides color? For example flashing to indicate cursor position.

How large are the ram blocks in the ICE device? Depending on the device there may be extra space available so why not just use a direct map then? An alternative is to use main memory to store the bitmap images, then there’s probably lots of rom for fonts.


An issue crops up with keyboard input using ascii as well. It is handy to define some of the character codes as cursor operations. Typically several maps are needed for control and shift characters.

The BRAMs are 256 x 16-bit I believe. I could use a bunch of them for character ROM but I kind of want to keep some for the main processor. Hence my desire to minimize their usage.

I don't currently plan to have other attributes / a cursor. Though that's something to keep in mind in the future. For now I am kind of just doing the minimum to have a debugging display with the CPU's internal state. But it did occur to me it would be nice to have a way to print some text to the screen. And it also occurred to me if I had a more capable VDU / GPU it might be a good motivator to finish enough of the CPU to be able to use it. So we'll see.

BTW, I just tried to synthesize the same circuit on the ice40 hx8k, and it runs at 115 MHz. So I guess if I want to do higher resolutions I need to switch to the hx8k (I do have both). I like the up5k though because it has a bunch of SPRAM (128KB?) in addition to the BRAM. If I go with the hx8k I need to figure out how to use the external SDRAM which... well... I would like to avoid for now.

I can do a 720x400 or 720x480 on the up5k easily, and 800x600 with a bit of care. I think that will be fine.

You draw things like a schematic, does it automatically produce Verilog or Vhdl?

Digital? Yeah, it has verilog and VHDL exports. Exporting is manual in that I don’t think you can trigger it from the command line. But otherwise the export is automatic in that you get verilog or VHDL for the whole circuit from clicking export.

Not all components can be converted though. So what I do is have separate top level circuits. In one I have the top level for digital, and then one I have a top level in verilog. In the verilog one I wire up things like block ram, PLLs, and other things that Digital doesn't have components for. In the Digital one I can put buttons, LEDs, vga monitor simulation, etc that I can’t export to verilog but are useful in simulation. I then have a shared embedded circuit with everything in common between the two top levels, and it’s that embedded circuit that I export to verilog and reference from my verilog top file. This allows me to run the same circuit in Digital and on an FPGA.

I don’t know verilog very well, so drawing circuit diagrams is a lot easier for me. And hopefully it’s also more interesting to watch. And if I do a discrete logic / TTL version it will be easier, since digital has a good library of 7400 series chips.

There are a couple gotchas though: pins and tunnels can’t share names. And memories that digital exports to verilog don’t seem to infer properly in yosys. Maybe other synthesis tools would infer better. So I move all my memories to the top level and implement them differently in Digital and verilog, so they are properly converted to block ram instead of LUTs or registers in the FPGA.

Bah, I don't like this approach mostly because it's not my habit, but it's also a new "hype" (promoted by the RISC-V team) to use an abstract language like Chisel/Scala instead of an RTL-HDL language (vhdl, verilog, etc...), and in discussions like this is like comparing the assembly language of a CPU with high level language like C/Pascal/Ada ...

A = RTL-HDL : FPGAs = assembly : CPUs
B = Chisel/Scala : FPGAs = C/pascal/Ada : CPUs

Someone in the RISC-V team says B has an higher gain than A in terms of productivity. Personally I don't know.

B ?> A ......... who knows? For CPUs definitively "yes", but what about FPGAs?

I still have to learn Chisel/Scala and I haven't yet used any graphical tool (like Digital), so in my case, I prefer a low level language to directly manage the RTL level. So it's not a criticism, it's simply "I wouldn't do it that way" and I am watching it with more interest and curiosity

I dunno... in some ways verilog is higher level than Digital. It would take me a lot less time to just write it in verilog -- if I knew verilog super well. With Digital I have to draw all the wires and figure out routing and how to make it pretty and that all eats time. Verilog I just tell it in textual form where all the wires connect without having to draw them.

Digital does have an advantage with simulation / debugging though. I can see what all the wires are doing and what values they have. So I do save time there. And it is more visual so it's easier to understand what's happening in my opinion, though you can generate schematics from verilog.

But yeah, there's lots of new HDL languages out there and I am not sure what I think of them either. Many of them don't seem simpler / better than verilog to me. But well... I am sure they are better to some people.

~~~~~

Anyway, the next video is up. I show what I was talking about in a prior post about making it work both in digital and the fpga. I also build a module to display arbitrary text and one for showing hex numbers.

[031] VGA Blinkenlight Displays! (Part 3)

I haven't recorded the next video yet, but I think I am going to show the optimizations I did and then integrate this with the CPU to display some internal state of the CPU. But I am open to other suggestions.

I am considering also implementing a tilemap and maybe some sprites. But I am still unsure about that. If I do memory mapped I/O then the CPU might be currently powerful enough to do a few things, but I don't have functions / subroutines yet, so it will be a bit limited. But that might be good motivation to add the features needed to use the VDU more

Forget vga, go directly to a built in card punch and card reader. Joking aide a useable computer may need to be self hosting
and that requires likely 64k words of memory, serial port, keyboard and dual sd cards. At some point you need to look at the design and ask does this design meet my needs for today.

as well as C/pascal/Ada directly output assembly-source so does Chisel/Scala that directly outputs RTL-HDL-source (Verilog/Vhdl)

So the next video is up. I go over the optimizations in the previous few posts and outline the changes I made. I then fix the corruption issue by adding a busy signal to keep the value from changing while the monitor is drawing the rows for the value in question.

I then move on to building the VGA version of the front panel. I just wire up the first two registers, I think I will do the rest off camera since it's just more of the same.

[032] VGA Front Panel! (Part 4) https://youtu.be/znp12xHvzQw

So I have a video I recorded a few episodes back where I revamp the ALU to be more proper, there's another video I can record on that topic to finish setting up the flags properly.

The creator of Digital is building a telnet module that can interface with a CPU as an emulated serial link, so I am waiting for that before I will start on a serial connection. With that I can do serial over USB on the FPGA, and telnet to the simulation when running on Digital. That will be nice.

Then I will probably focus on building what's necessary to write a boot loader. So I will need function calls probably, and a way to write program memory. Not sure what else I will need to do that?

Oh yes, being able to communicate with a simulated serial port will be nice!

For bootstrap code, you'd like to have a ROM model which is initialised with binary content from a file.

Front panels are another way to boot strap. I use that on real hardware (FPGA) all the time. I can load the PC, and display important registers from the halted state, I know the latest design built correct. Then I check my rom works. that prints a "hello world" message starts the abs bootstrap loader. It is very important to have a REAL serail port
at this point, the latest windows refuses to user my 20 year old USB to serial port adaptor.Then you move on to other testing. Every so often I check that my HALT instruction works. From then on to other software.

Next video is up!

This video is mainly just implementing subtract and then moving the unsigned comparisons to using the carry flag. I also update the microcode to do a compare and add the subtract instruction.

[033] Subtract! https://youtu.be/0eWKxe3rj_M

I also show off a bit of the VGA front panel stuff I have done off camera. There is one point in the video where I show a very long bus with a ton of peripherals on it (around 3:15). I really don't like that solution and I am curious if there's any ideas on a better way to do it?

Here is the crazy bus:


And here are the multiplexers in each peripheral on that bus:


Really all I need to do is be able to take a bunch of registers and control signals as input and produce text at specific locations on screen. Ideas?