I've currently got a 240 x 128 lcd like the one discussed here viewtopic.php?f=4&t=7643 which works very well for 40x16 text (onboard character generator)
and is ok for monochrome graphics tho with some motion blur. I have it wired directly to the data bus with data/ctrl write addresses mapped in my IO page.

You can see it running a choplifter demo loop extracted from an apple // disassembly. It's doing brute force 7-bit to 6-bit mapping but at 4Mhz it kind of works...

I could go down the route of generating an NTSC video signal and resurrecting an old TV or CRT monitor, but not sure I really want that trouble since I'm more enjoying software tinkering at the moment.

Wondering if there is some more modern display option along these lines:

- slightly higher resolution (320 x 240 ?)
- still has onboard character generator for text mode
- reasonably large physical size so low pixel density (many tft lcd at that resolution seem to be only an inch or two in size)
- won't be too difficult or too slow to interface so i can still emulate memory mapped graphics by copying some RAM region to the LCD at reasonable frame rate
- decent refresh rate(?) to avoid some of the ghosting seen in video above
- perhaps color (I don't need 24bit rgb, but could map from a 256 color palette or sth?)

there seem to be infinitely many varieties of LCDs and don't know enough about them to really narrow my search.

Thanks,
Patrick

I've gotten one of these guys working directly off the data bus on my 6502 with just the need of a 74HC245:
https://www.adafruit.com/product/1770

(Haven't tried it with my 65816 yet)

We discussed it a bit on this topic. The problem being that trying to fill the screen with the clock speed the 6502 operates at would be hard (impossible?).

Looks like most of the Arduino libraries out there get around this by using the Arduino's DMA system.


As for the NTSC signals, you can get a converter that generate an HDMI output. I've considered trying to get my hands on a Yamaha V9958 to play with.

We've also discussed using a RP2040 for generating video.

See also here on a TMS9918 emulated with one.

People have generated VGA signals from the RP2040, and I've seen some other stuff floating around online suggesting it should be possible to generate a DVI signal from them too. The RP2350 was recently released and has a version with some additional pins. (Along with some additional memory and faster internal processors)

What about VGA?

It is trivial to generate and there are tons of smaller monitors with VGA input going for free or next to nothing.
You will have no motion blur and can use a shiftreg for mono or a shiftreg and latch for color in a basic circuit.
For more fun, a simple frame buffer using a readily available 512K SRAM gives you 400x300 with as little as a 20MHz clock.

You can do it all in logic or with as little as a cheap 8 bit AVR.

Brad

Thanks for the ideas Yuri, lots of helpful threads there.

Generating VGA is an option too tho not sure it would be trivial for me - is there an implementation/thread you'd recommend?

I've found a bunch of threads about interfacing rpi pico directly to the 6502 addr/data bus. Is it naive to think that a pi zero(?) could just continuously sniff the bus for memory writes, and have the 6502 pretend it has a memory mapped display? e.g. 6502 writes data to $2000-$3fff and pi zero captures writes and decodes to whatever video layout the 6502 wants, drawing chunky pixels on its hdmi output? with a couple of special memory address 'registers' the 6502 could tell the pi what video mode it wanted, what memory range it wanted mapped etc.

but I haven't discovered a writeup of something like that so either my google skills have let me down or I'm missing some obvious problem

aside: i'm mentally down this track since I do something analogous for video using my simulator: ram/rom is backed by a mmap'd file, with a local web server serving memory-mapped display data to a bit of javascript in my browser which renders it using the canvas api. it's surprisingly fast/smooth frame rate, even when (say) decoding apple's crazy 7-bit reversed hgr data.

Yep, pico can snoop a 6502 bus and do the video hardware thing.
Combined VGA / Tube interface board for Atom

A pi is a more tricky proposition because although it has more peak compute power it's less deterministic and it's more difficult to manage the real-time deadlines. But PiTubeDirect does the job, interfacing to a 2MHz 6502 bus (with precoded address selection) and delivering HDMI video as a bonus feature (the main feature being to deliver a second processor)

If you want to go retro, the Hitachi 6845S CRT can just barely go fast enough to squeak out a VGA signal.

_________________
"The key is not to let the hardware sense any fear." - Radical Brad

After lots of reading, I love the idea of trying a modern version of Don Lancaster's cheap video with the Pico as an intelligent video decoder. The 'nop slide' thread was also good inpsiration viewtopic.php?f=4&t=6408

Maybe this doesn't make sense, or is overcomplicated, but here's what I was thinking:

The pico would maintain a frame buffer for your current graphics mode (s/w configurable). For example https://github.com/Panda381/PicoVGA uses one core, one PIO, and 9 gpio pins for R3G3B2 VGA out in many different modes. So the pico would be continuously generating a VGA signal, but we need a way to refresh the frame from the 6502.

Could the pico be interposed between RAM and CPU as a normally transparent read buffer (8 pins in/8 pins out)? To trigger a refresh, signal the pico (e.g. with a VIA pin) that we want to block copy from RAM, then immediately execute `jsr frame_buffer` and have the pico start recording the data bytes fetched from RAM while hiding the result from the CPU and instead returning $A0 (ldy #) to increment the CPU PC one byte per cycle, with a final $60 (rts) when we're done the block and will stop hiding RAM. (I guess 65c02 could use one of the $x3 single cycle nops instead of ldy # ?)

Running at 2MHz it seems like you could block copy an 8K graphics frame in 4ms, so a 25fps refresh rate would only use 10% of the cpu. Is that math right?

I don't know a lot about pico PIO programming, but the vga driver above does leave one free - is that enough to proxy the data bus?

And there still might still not be enough pins (8+8+9 leaves only one, and presumably need phi2 and a signal pin at least). Maybe 6-bit color would work?

Originally I was thinking about only snooping on graphics writes, but that seems to quickly run out of pins (14-16 for address + 8 data + various chip signals + vga output is more than 26?)

I'm taking a different approach with my pico, though the code is temporarily on hold while I finish the tiny basic. Instead, I'm hoping to use the pico in the same way as any other 6502 bus peripheral, using a handful of internal 'registers' controlled by two IO addresses: one is read to get status and written to select a register; the other is used to transfer data (e.g. keyboard data to the 65c02 and characters to the internal terminal).

That needs only eight bits of data, plus a chip select and register address - and because the pico is also providing the system clock and other signals to the 65c02 if necessary I can do clock stretching by just turning the clock off - though I hope not to.

Your idea looks as if it might work, but I'd hate to commit myself... using the pico between the processor and the memory puts a variable delay between both reads and writes and I think that meeting the timing could be, um, interesting.

Neil

it seems you can run a pico as an SPI peripheral (https://github.com/raspberrypi/pico-exa ... pi_slave.c) which i've found really easy to integrate. With a shift-register and a flip-flop for clock delay the VIA will transfer natively at one byte exchanged every 18 cycles, which is fast for one-off stuff like reading an SD card, but is about 75ms for 8Kb transfer at 2Mhz which only gives 13 hi-res frames per second with the cpu doing nothing else. Running 18x faster with a ldy or nop slide block transfer at 1 byte per cycle would be a big win for graphics performance.

if the pico isn't reliable as a cpu-ram buffer/tap maybe you could do that part with a couple of ICs and just have the pico orchestrate things. it seems you just need a way to switch the cpu from seeing ram on the databus to a fixed opcode during the slide, terminated by a rts/rti. in fact if you picked either the pair cpy # ($c0) + rti ($40) or the pair cpx # ($e0) + rts ($60) then you only need to turn off bit 7 off to finish the slide. [edit: could even arrange for VIA T1 to end the slide by toggling pb7?]

in that arrangement the pico would use 4 pins for spi (di/do/clk/cs), 9 pins for vga, 9 pins to watch the bus + clock, a pin to enable/disable the tap, and a pin to continue or finish the slide, leaving a couple spare for whatever I've forgotten... SPI would also be a nice way for the CPU to tell the pico what video mode it wanted, where the current frame buffer was in memory, and when to start a frame grab, alongside a super-fast channel for parallel data transfer.