Another neolithic system: proposals for noodling

[barnacle]

Hey, you know I can't just keep one idea in my head at once, so bearing in mind that I'm getting some success with the Pico VGA design, here's an idea of what I'm planning on attaching it to. Here because this will become the hardware design, eventually.

The Pico has four or five main functions, depending how you count them, but in a couple of separate blocks.

• Initial program loader (because I want to use the acronym 'IPL' )
• VGA text and video output generator, either 1-bit RGB or 3-bit grayscale
• PS/2 keyboard receiver and decoder
• 'Serial' bidirectional comms to a host USB device (appearing on my linux box as dev\ttyACM0) [1]
• Virtual simple terminal with minimal controls, just throw ascii at it and it gets printed, 80 x 30
• Graphics co-processor, converting start/end coordinates and basic functions (plot pixel, line, rectangle, circle, set colours etc)
• Appears as memory mapped peripheral in 6502 space.

The 6502 is straight forward: a single 64k block of ram, no rom, with a chunk carved out for I/O space at 0xff00-0xffe0. Currently, only two IO devices each of which will occupy a 16-byte chunk - a compact flash card of a couple of gig (more than I'm ever likely to need but I have some lying around), and the fore-mentioned Pico.

The Pico has just enough pins exposed to do what I want (though I don't know yet if they can all do what I need - that's why this hobby is fun):

• 8 data lines
• 4 address lines
• ~chip select
• ~reset (to the processor)
• r~w
• ~irq (to the processor)
• ph0 (to the processor)
• data bus override control
• PS/2 clock and data
• RGB and syncs (5 total)

The plan - at the moment - is that on power up, the Pico resets the 6502 and disables reading from the ram. As the 6502 boots, it is fed its IPL from the pico (it's got lots of external memory for that) probably as a sequence of lda #/sta xxxx instructions. That loads something that can access fat-16 data on the CF card, hits reset again, and gets out of the way, only then appearing as the memory-mapped peripheral.

This should end up with a minimal chip count design, minimum need for fancy decoding, but a computer with significant capabilities. I'm thinking of at least an assembler/disassembler, compiler of some sort (perhaps some sort of mini-c), and text editors. With of course the ability to access files from the laptop via the CF card.

Neil

[1] It looks as if it's possible to use the usb port as a host for keyboard/mice, though I'm not yet certain. But that's another option.

[BigDumbDinosaur]

Neolithic, eh?  Does that mean your design is already cast in stone?    (Sorry!  Couldn’t resist the urge.)

With the I/O crammed right up against the MPU vector addresses, how are you going to handle the required granular decoding without use of “fancy decoding?”

[barnacle]

Neolithic? All my designs are stone age designs... re decoding, haven't thought it through yet, but a '688 will isolate a page with no other parts; a '138 after that will select (say) sixteen byte chunks within the bottom of that block - just the right size for the Pico, the Compact Flash, and a handful of 6522 if I go that way (which I might not).

Neil

[BigDumbDinosaur]

barnacle wrote:

Neolithic? All my designs are stone age designs...

Some of my designs are Jurassic. 

Quote:

re decoding, haven't thought it through yet, but a '688 will isolate a page with no other parts; a '138 after that will select (say) sixteen byte chunks within the bottom of that block - just the right size for the Pico, the Compact Flash, and a handful of 6522 if I go that way (which I might not).

You probably could fashion a single-chip decoder out of one of these critters.  With a 45 ns address-to-output rating, it should be fast enough to support an 8 MHz 65C02 system, and its 16 address inputs should result in some pretty granular decoding, I’d think.  Only other logic you would need would be something to qualify write operations with Ø2.

[barnacle]

Seems a bit ironic to design a rom-free system using a rom to decode the addresses

There's a 74act521 with a 7ns response, though; the hc688 takes around 50ns at 3v3. Or the 'lvc138 has a typical decode time of 3ns; I can be much speedier than I need to be... I think 8MHz is a reasonable target speed but as it's driven from a Pico timer output, that can be tweaked to suit...

Neil

[Yuri]

The biggest issue I've run into is the lack of GPIO pins on the Pico. The one I got (Pico-W) only has 26 GPIO pins available for use.

I was trying to consider how best to handle more colors with the Pico (my goal is 15-bit color). My initial thought was to have it multiplex the RGB channels out of 5 of the pins, but realized that I'd have to run at something like 100.7Mhz, which leaves me with ~10ns for getting the data out and latched into some place. (Much too fast for the HC parts I generally use)

Also considering using 8 pins for data, and then latching 16-bits on the rise/fall of the VGA signal. Seeing that I would like to do 320x240, that means I should be able to keep things in the ~40ns needed for a VGA signal and still latch the data.

Failing all of this though, I'll go back to doing the VGA with an FPGA like I had initially planned. It seems I should be able to use the Pico for adding Bluetooth, and likely other peripherals (USB, PS/2, etc).

[GARTHWILSON]

barnacle wrote:

There's a 74act521 with a 7ns response, though

If you need it faster, there's the 74FCT521CT at 4.5ns max.

[Yuri]

GARTHWILSON wrote:

barnacle wrote:

There's a 74act521 with a 7ns response, though

If you need it faster, there's the 74FCT521CT at 4.5ns max.

If you're going to go the SMD route, might as well develop a board with the RP2040 right on it. IIRC that would give 30 GPIO pins. The 2040 is a 3.3V part though, so maybe the ALCV parts will work?

[barnacle]

I've considering that, but if I can get enough pins from the Pico it's handy to have a 'chip' big enough to see and hang scope probes on. The extra three bucks would probably be worth it just to save sorting out the external flash chip, regulator, and USB parts. Also, the rp2040 package is not one I'm comfortable soldering; I can do it, but I suspect I'd kill some before I got one running.

I note that there's a cloneish part referred to as the purple pico which has - I think - an extra io pin or two.

There's always the possibility of using two picos - one for high-colour video and one for general IO, or one for each colour channel. The snag is that the rp2040 has only enough memory for four bits at 640 x 480, and that resolution is a minimum for me. You could get eight bits at 640 x 350 or (just) 640 x 400... I haven't investigated, but it's possible that three or four bits at 800 x 600 is also possible; I've seen higher resolutions but they mostly seem to be beam chasing designs.

It's always the old question of how much ram do I need to get the resolution I want, and how can I include efficiently in the 6502 memory space? With a full-colour 24-bit VGA, you're looking at a meg on a screen; an 8MHz 6502 is going to take a couple of seconds just to move that much data, irrespective of any processing...

So the sweet spot for me is that 'high' resolution of 640 x 480 x 3/4 bits, using the Pico as a video co-processor. I don't think that's against the 'retro' aspect vibe that seems popular; it provides a simple video output (I _know_ I can generate video with any number of alternative options... but they all put the video ram in main memory space), and I think it has the capability to provide the other IO I'm looking for.

One thing I have not seen many examples of is a bus interface to the 6502/6800 bus (or even 8080). Most of the examples say 'look, pretty colours' but they're mostly internally generated.

Neil

[Yuri]

barnacle wrote:

I've considering that, but if I can get enough pins from the Pico it's handy to have a 'chip' big enough to see and hang scope probes on. The extra three bucks would probably be worth it just to save sorting out the external flash chip, regulator, and USB parts. Also, the rp2040 package is not one I'm comfortable soldering; I can do it, but I suspect I'd kill some before I got one running.

I note that there's a cloneish part referred to as the purple pico which has - I think - an extra io pin or two.

I'll see if I can track that one down.

Quote:

There's always the possibility of using two picos - one for high-colour video and one for general IO, or one for each colour channel.

Erph, maybe, coordinating between two Picos might get tricky though.

Quote:

The snag is that the rp2040 has only enough memory for four bits at 640 x 480, and that resolution is a minimum for me. You could get eight bits at 640 x 350 or (just) 640 x 400... I haven't investigated, but it's possible that three or four bits at 800 x 600 is also possible; I've seen higher resolutions but they mostly seem to be beam chasing designs.

It's always the old question of how much ram do I need to get the resolution I want, and how can I include efficiently in the 6502 memory space? With a full-colour 24-bit VGA, you're looking at a meg on a screen; an 8MHz 6502 is going to take a couple of seconds just to move that much data, irrespective of any processing...

4-bpp @ 640x480 is what the original VGA supported; that takes up about 150KB of space. As I recall it was plane mapped in that mode.

VGA also supported a 320x200 8-bpp mode, that was a flat memory map of one byte per pixel.

Then there was the undocumented mystical "Mode-X" which was a plane mapped 320x240 8-bpp mode if my memory serves me correctly.

Looking at some of the details of the old Michael Abrash black book; VGA divided it's memory into 4 planes, which was used to do some quick copying (4 bytes at a time) from one place to another in memory.

The other handy thing about it was that if you knew you're doing a fill for example, you could set it up where you could write to all 4 planes at one time. Thus effectively setting 4 pixels for the price of one write.

Obviously though, there are other ways around all of this. The TMS9918A, and other video chips did not always have nearly enough RAM to pull off a completely flat bit mapped display.

Quote:

One thing I have not seen many examples of is a bus interface to the 6502/6800 bus (or even 8080). Most of the examples say 'look, pretty colours' but they're mostly internally generated.

Yea, I'm still poking about for that part of the puzzle. The datasheet says it's possible to interface to a 6800 or 8080 bus, but doesn't go into any detail on how. The thing that I'm trying to wrap my head around is that I would presumably need at the very minimum 10 of the 26 pins available to do it in parallel.

8 Data pins
1 R~W pin
1 ~CS/strobe

or

8 data
1 read strobe
1 write strobe

I have considered maybe using a '299, at which point I could dedicate one of the IO state machines to pushing bits in and out; but I think that would require me to run a pretty beefy clock rate if I wanted to keep with 8 to 16 MHz

I'm sure there are other clever ways the data could be split up and delivered into the RP2040. (Maybe split 4 bits at a time?)

[barnacle]

I may be reading the datasheet wrongly, but I believe it is possible to ingest all 8 bits in one read (or thirteen, given four data and one direction pin).

So the theory would be:
- all pins idle as inputs
- spin until ~cs goes low
- grab the data, address, and direction bit
- if direction is in, dump the data to buffer[address] and kick an interrupt to say something's happened
- if direction is out, change data pins to idle, copy buffer[address] to outputs, and kick an interrupt
- spin until ~cs goes high
- all pins back to inputs

At the moment, my pin usage looks like this...

Code: Select all

    - GPIO 00 ---> D0
    - GPIO 01 ---> D1
    - GPIO 02 ---> D2
    - GPIO 03 ---> D3
    - GPIO 04 ---> D4
    - GPIO 05 ---> D5
    - GPIO 06 ---> D6
    - GPIO 07 ---> D7
    - GPIO 08 ---> A0
    - GPIO 09 ---> A1
    - GPIO 10 ---> A2
    - GPIO 11 ---> A3
    - GPIO 12 ---> ~CS
    - GPIO 13 ---> R/~W
    - GPIO 14 ---> ~IRQ
    - GPIO 15 ---> ~RESET
    - GPIO 16 ---> VGA Hsync
    - GPIO 17 ---> VGA Vsync
    - GPIO 18 ---> 330 ohm resistor ---> VGA Red
    - GPIO 19 ---> 330 ohm resistor ---> VGA Green
    - GPIO 20 ---> 330 ohm resistor ---> VGA Blue
    - GPIO 21 ---> databus override
    - GPIO 26 ---> PH0 (?)
    - GPIO 27 ---> PS_2_DATA
    - GPIO 28 ---> PS_2_CLK
    - RP2040 GND ---> VGA GND

That uses every pin on the pico.

Neil

[rwiker]

Do you actually need 4 address bits? It might be possible to free up 3 address pins by having just two addresses, where one address would be used to specify the "register" number... that would require slightly more complex software to drive, and probably also be slightly less efficient, but might also unlock some additional functionality (e.g, auto-incrementing pointers).

[barnacle]

It's a thought...

[Yuri]

Apparently it is also possible to generate a DVI signal from a RP2040. In which case you could have a set up like so:

Code: Select all

- GPIO 00 ---> D0
    - GPIO 01 ---> D1
    - GPIO 02 ---> D2
    - GPIO 03 ---> D3
    - GPIO 04 ---> D4
    - GPIO 05 ---> D5
    - GPIO 06 ---> D6
    - GPIO 07 ---> D7
    - GPIO 08 ---> A0
    - GPIO 09 ---> A1
    - GPIO 10 ---> ~CS
    - GPIO 11 ---> R/~W
    - GPIO 12 ---> ~IRQ
    - GPIO 13 ---> DVI_DATA_1 +
    - GPIO 14 ---> DVI_DATA_1 -
    - GPIO 15 ---> DVI_DATA_2 +
    - GPIO 16 ---> DVI_DATA_2 -
    - GPIO 17 ---> DVI_DATA_3 +
    - GPIO 18 ---> DVI_DATA_3 -
    - GPIO 19 ---> DVI_CLOCK +
    - GPIO 20 ---> DVI_CLOCK -
    - GPIO 21 ---> databus override
    - GPIO 26 ---> PH0 (?)
    - GPIO 27 ---> PS_2_DATA
    - GPIO 28 ---> PS_2_CLK
    - PIN 30 ---> ~RESET (RUN)
    - RP2040 GND ---> VGA GND

This would give you the ability to use a full 24bpp color depth, or simulate anything between 1 and 24bpp that would fit in the RP2040's memory.

[J64C]

barnacle wrote:

I may be reading the datasheet wrongly, but I believe it is possible to ingest all 8 bits in one read (or thirteen, given four data and one direction pin).

You can read all 32 pins in one read, if you really wanted to.