Last visit was: Fri May 20, 2022 4:56 pm
It is currently Fri May 20, 2022 4:56 pm

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

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

Sat Jun 12, 2021 9:17 pm

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

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

Sun Jun 13, 2021 1:43 am

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

Sun Jun 13, 2021 7:26 am

Joined: Sun Dec 20, 2020 1:54 pm
Posts: 74
rj45 wrote:
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.

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!

Sun Jun 13, 2021 11:48 am

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

Sun Jun 13, 2021 4:26 pm

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

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.

Fri Jun 18, 2021 8:22 pm

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

Sat Jun 19, 2021 9:04 am

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

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.

Thu Jul 01, 2021 12:41 pm

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

Thu Jul 01, 2021 12:59 pm

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

Thu Jul 01, 2021 4:10 pm

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

Fri Jul 02, 2021 9:38 am

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

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?

Sat Jul 03, 2021 12:04 am

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

Sat Jul 03, 2021 3:50 am

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

Sat Jul 03, 2021 7:33 am

Joined: Sun Dec 20, 2020 1:54 pm
Posts: 74
I would spend time learning Verilog instead.

Sat Jul 03, 2021 2:44 pm
 [ 237 posts ]  Go to page Previous  1 ... 12, 13, 14, 15, 16  Next

Who is online

Users browsing this forum: Bing [Bot], CCBot 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