This is no less than the fourth revision of the PCB. 

It still uses Dr.VIP which is a standalone project and could be useful for many other projects that need a Pico with as many GPIO as possible and an HDMI socket on the board, although that idea has now been overshadowed a little by the PicoVision project.

I have wondered whether I'd need dual RP2040s for this project but It turns out not.

This version of the card looks identical to the previous one, but the logic is simplified. 

Finally the VRAM reading is working. This was a tough nut to crack. Earlier versions of the card didn't have this feature at all. In the last project log (with the last version of the module) I claimed that this feature was 'working like a charm'. Although it appeared to be initially, it wasn't working very well at all. 

Why is this a big deal? The earlier cards are usable for most of the demos and games available at the moment, but certain operations, such as hi-res drawing are easier if you can read the existing VRAM data. 

To cut a very long story short, It really is now working. The new board (predictably) needed a bodge wire, but I've corrected that in the design and because of Dr.VIP (and therefore no surface-mount components on the module itself) minor revisions of the board will only cost me a few quid.

Sacrifices

The port select is still working (you can select $98/99 or 08/09 with a single jumper) but I've had to lose the serial communication, meaning that this version of the card won't have one of the features I set out to include, which is the terminal functionality at startup. It won't be truly standalone and like the "real TMS" module requires you to communicate with the computer via a terminal at least until you've started the program you want to run.

(I am aware that ROMWBW has some functionality to use a TMS card for terminal display but I haven't explored this yet.)

The other small sacrifice is that reading the status register gives you the vblank bit only. I had hoped to provide that whole byte which includes sprite collision and 'fifth sprite' information.

Both of these features are missing because of a shortage of GPIO pins, or in the case of the serial, the ones I have left can't be used with the hardware UART. I may be able to claw that feature back.

I'm not sure how important the sprite collision information is. This is pretty easy to work out in your own software if you know where your sprites are. The fifth sprite information probably isn't important at all because this project doesn't have a limit of four sprites per scanline. 

VRAM-reading now really working like a charm

As mentioned, plotting a point (and therefore drawing lines etc) is easier if you can read the existing video memory. Otherwise you have to keep your own copy of the pattern table (which may be faster than reading the VRAM, but will cost you about 6k of your ram.)

This is now working, and functions such as TmsPlotPixel in Mr Langston's excellent tms.asm library work perfectly. The drawing above is written in C and takes about 2.5 minutes to draw.

Here are some more screenshots (more accurately, poor photographs of my screen) of programs that use other modes: