Another neolithic system: proposals for noodling

[barnacle]

@Yuri: I could, but I know nothing about DVI video (I should look it up!) but given everything else that the rp2040 is going to be doing, I'd like to keep the load on it as low as possible. I don't really have a feel for how much processor time is available, and I haven't yet done any tests to see. Also, for my intended use, I prefer the idea of a frame buffer rather than a display list - it means I can very simply overlay text and graphics.

@J64C: Yes, of course. I found a video by Rumbledethumps (!) who appears to have done something very similar; he's interfacing the rp2040 as ram and rom for a CPU running at 8MHz (though he needs to overclock the rp to do that). I need to watch his video another couple of times...

Neil

[J64C]

barnacle wrote:

@J64C: Yes, of course. I found a video by Rumbledethumps (!) who appears to have done something very similar; he's interfacing the rp2040 as ram and rom for a CPU running at 8MHz (though he needs to overclock the rp to do that). I need to watch his video another couple of times...

Neil

Nice one.

I managed to do the same thing and get 4MHz out of it, with an over clock also. I used the PIO but didn’t use DMA, so that may well be the difference in the extra speed.

[barnacle]

I'm starting to lean towards just using two addresses, both read-write: address zero reads status, writes to select a target register; address one reads or writes the last-selected register.

So e.g. writing to the terminal or serial would
- write terminal register address to zero
- read the status (zero) to check for not-busy
- when clear write register (one)

On writing to the register, an interrupt would be triggered in the rp2040 which would then instigate further processing. So a write to a cursor position register updates the cursor position; a write to the terminal uses the new cursor position. Similarly, the point/line/circle/rectangle routines can use previously written x-y coordinate double-byte registers.

And I get a few pins back; an external reset would be handy without requiring a power cycle.

Neil

[Yuri]

I think I would have like to have two address lines. Specifically for making 16-bit writes from a 65816 cleaner, and the other for selecting between a register and data similar to how the TMS9918A does it.

I was looking at how Rumbledethumps handled it on their setup, and it would appear they have one Pico doing all the address decoding and handling of peripherals, and then it communicates with a second Pico with a custom 4-bit bus, and the second one does all the VGA work.

[barnacle]

To be honest I've not even considered a 65816. I know little about it but I though it used the same 8-bit wide data bus as the 6502... am I missing something? Other than that, I'm looking at register/data comms just using two addresses.

Though to be fair I haven't even started any code for handling that yet; I'm currently looking at hardware design so that I can butcher previous prototypes to get a proof of concept on a breadboard. In the absence of evidence otherwise, I don't feel that RdT's dual system is necessary - as long as I can get a fast enough read of data from the Pico. And I don't run out of state machines and memory...

Neil

[barnacle]

So here's a first cut at a PCB which might probably perhaps maybe work... if I can sort out the bus interface.

Basic specs:

• 65c02 and 65c22 running at (hopefully) 8MHz
• MCP795 real time clock, SPI from port A on the 65c22
• VGA video output, USB serial, and PS/2 keyboard input via Pi Pico. Either 3-bit RGB, or 3-bit (8-level) grey-scale, selected by jumper.
• 3.3v operation, from the Pi Pico (my PS/2 keyboard is quite happy at this reduced voltage)
• CF Card as long-term storage - probably with a FAT-16 file system if I can make it work
• Pico controls the 65c02 at reset to organise the initial program load; thereafter it is just an active part as above.
  The intent is that the Pico uploads the disc (CF) operating system and a monitor, like DOS used to do.

Obviously still a lot of software to play with and probably some hardware too. I'm not ordering this board until I've sat on it for a few days! (Four layers to simplify power distribution, and because there's some high speed signals flying around.

Neil

[BigDumbDinosaur]

barnacle wrote:

So here's a first cut at a PCB which might probably perhaps maybe work...

Instead of using two 32 KB SRAMs, why not use a single 128 KB SRAM and just ground (or pull up) A16?  One SOJ32 package instead of two SOIC28 packages and all that extra real estate.  You end up soldering 32 pins instead of 56.

[barnacle]

A very simple reason: I _have_ two 32k rams and I don't have a bigger one

A single chip would simplify the decoding a little, too.

And to be fair, that's hardly a PCB that's pushed for real estate! I could probably make it half the size if I tried hard...

Neil

[Yuri]

Saw this pop up on my news feed today:
https://www.adafruit.com/product/6006

Could be handy for over coming some of the memory issues with desired video modes.

Here's the link on the Raspberry Pi site:
https://www.raspberrypi.com/products/rp2350/

[barnacle]

Ooooh... enough memory for 8 bits depth at 640x480... must not get distracted at this point, but...

Neil

[Yuri]

Looking at the datasheet, it looks like they are going to have a package that will add an additional 18 GPIO pins as well.

[barnacle]

Ah, but if only they had a configurable 8-bit bidirectional interface...

[John West]

barnacle wrote:

Ah, but if only they had a configurable 8-bit bidirectional interface...

They do? If I'm reading it correctly (never used one, so maybe I am misunderstanding...), set the pins you want as SIO, and then the registers GPIO_OUT, GPIO_IN, and GPIO_OE control all of them at once.

Maybe the old one was more restricted.

[barnacle]

Now that is worth looking up... but I'll see if I can do it with the v1 first.

[barnacle]

After too many youtube videos, I finally found one in which not only is the pico used as a memory bus peripheral, but how to do it is explained in excruciating detail (which I need!).

https://www.youtube.com/watch?v=_zTlbCywZbY

In this case, he's interfacing it to an 80186, which has a more complex multiplexed address/data bus with four control signals to manage, but I think that the 65c02 should be much simpler. I'm trying to avoid any wait states but I won't know until I see how long it takes the pico to respond - I suspect I'll have one core running the vga, usb serial, and ps/2 keyboard, and the other dedicated to moving data to and from the 65c02 databus.

Just as a reminder: I'm planning to have one address to either read a status, or write a register address; the other address to read or write that 'register'.

Neil