Last visit was: Sun Aug 01, 2021 3:18 am
It is currently Sun Aug 01, 2021 3:18 am



 [ 236 posts ]  Go to page Previous  1 ... 10, 11, 12, 13, 14, 15, 16  Next
 rj16 - a homebrew 16-bit cpu 
Author Message

Joined: Mon Oct 07, 2019 2:41 am
Posts: 255
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


Sun May 02, 2021 6:55 pm

Joined: Sun Dec 20, 2020 1:54 pm
Posts: 73
rj45 wrote:
I basically just take the 7 bit ASCII and just take bits 0-4 and 6 to make a 6 bit number. The digits repeat twice and the letters also repeat twice. Zero ends up being the space, which is perfect.


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

Code:
000: [`]
001: [a]
002: [b]
003: [c]
004: [d]
005: [e]
006: [f]
007: [g]
008: [h]
009: [i]
010: [j]
011: [k]
012: [l]
013: [m]
014: [n]
015: [o]
016: [p]
017: [q]
018: [r]
019: [s]
020: [t]
021: [u]
022: [v]
023: [w]
024: [x]
025: [y]
026: [z]
027: [{]
028: [|]
029: [}]
030: [ ]
031: [ ]
032: [@]
033: [A]
034: [B]
035: [C]
036: [D]
037: [E]
038: [F]
039: [G]
040: [H]
041: [I]
042: [J]
043: [K]
044: [L]
045: [M]
046: [N]
047: [O]
048: [P]
049: [Q]
050: [R]
051: [S]
052: [T]
053: [U]
054: [V]
055: [W]
056: [X]
057: [Y]
058: [Z]
059: [[]
060: [\]
061: []]
062: [^]
063: [_]
064: [ ]
065: [!]
066: ["]
067: [#]
068: [$]
069: [%]
070: [&]
071: [']
072: [(]
073: [)]
074: [*]
075: [+]
076: [,]
077: [-]
078: [.]
079: [/]
080: [0]
081: [1]
082: [2]
083: [3]
084: [4]
085: [5]
086: [6]
087: [7]
088: [8]
089: [9]
090: [:]
091: [;]
092: [<]
093: [=]
094: [>]
095: [?]
096: [ ]


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
Code:
        /*
         * 128 / 32 = 4
         *
         * 7 6 5 4   3 2 1 0    block -> block
         * --------------------------------------
         * 0 a b x | x x x x    0 / 3    /a /b
         * --------------------------------------
         * 0 0 0                0        3
         * 0 0 1                1        2
         * 0 1 0                2        1
         * 0 1 1                3        0
         *


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 }


Sun May 02, 2021 11:27 pm

Joined: Sun Dec 20, 2020 1:54 pm
Posts: 73
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

Code:
         * 0 a b x | x x x x
         *
         *            wanted
         * a b  ----> a b
         * 0 0  ----> 1 1
         * 0 1  ----> 0 0
         * 1 0  ----> 0 1
         * 1 1  ----> 1 0


Sun May 02, 2021 11:35 pm

Joined: Sat Feb 02, 2013 9:40 am
Posts: 1442
Location: Canada
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.

_________________
Robert Finch http://www.finitron.ca


Mon May 03, 2021 1:32 am WWW

Joined: Sat Nov 28, 2020 4:18 pm
Posts: 122
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.


Mon May 03, 2021 2:07 am

Joined: Sun Dec 20, 2020 1:54 pm
Posts: 73
You draw things like a schematic, does it automatically produce Verilog or Vhdl?


Mon May 03, 2021 9:06 am

Joined: Sat Nov 28, 2020 4:18 pm
Posts: 122
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.


Mon May 03, 2021 11:36 am

Joined: Sun Dec 20, 2020 1:54 pm
Posts: 73
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 :D


Mon May 03, 2021 12:17 pm

Joined: Sat Nov 28, 2020 4:18 pm
Posts: 122
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 :-)


Thu May 06, 2021 8:03 pm

Joined: Mon Oct 07, 2019 2:41 am
Posts: 255
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.


Fri May 07, 2021 3:52 am

Joined: Sun Dec 20, 2020 1:54 pm
Posts: 73
Code:
 RTL-HDL        assembly
---------  =  -----------
  FPGAs           CPUs


Chisel/Scala       C/pascal/Ada
-------------  =  --------------
   FPGAs               CPUs



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


Fri May 07, 2021 8:37 am

Joined: Sat Nov 28, 2020 4:18 pm
Posts: 122
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?


Sun May 09, 2021 3:37 pm

Joined: Wed Jan 09, 2013 6:54 pm
Posts: 1627
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.


Sun May 09, 2021 4:31 pm

Joined: Mon Oct 07, 2019 2:41 am
Posts: 255
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.


Sun May 09, 2021 7:37 pm

Joined: Sat Nov 28, 2020 4:18 pm
Posts: 122
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:
Attachment:
long_bus2.png


And here are the multiplexers in each peripheral on that bus:
Attachment:
bus_multiplexer.png


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?


You do not have the required permissions to view the files attached to this post.


Sat May 15, 2021 5:29 pm
 [ 236 posts ]  Go to page Previous  1 ... 10, 11, 12, 13, 14, 15, 16  Next

Who is online

Users browsing this forum: CCBot, YandexBot and 0 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Jump to:  
Powered by phpBB® Forum Software © phpBB Group
Designed by ST Software