PICO9918 - a TMS9918A drop-in replacement powered by a Pi Pico (RP2040)

[visrealm]

Unlikely. I think it might be possible (barely) but would need to overclock the RP2040 considerably more than I am already.

 

Colour composite is quite a thing. Greyscale it could do easily.

 

I might give it a go just for shits & giggles.

[aotta]

Ok thanks, but i meant a composite sync, not a composite video. I thought it was something like or-ing or nand-ing the h-sync and v-sync, but I'm not an expert

[visrealm]

Sorry. Missed that completely. 🤦‍♂️

 

That would be a relatively easy software (firmware) update.

[Geoff Oltmans]

So, how would I go about ordering up a PCB? I've sadly not ever done this from a open source hardware project and always bought a spare from someone who has.

[RickyDean]

Just now, Geoff Oltmans said:

So, how would I go about ordering up a PCB? I've sadly not ever done this from a open source hardware project and always bought a spare from someone who has.

You find a company that makes the PCB's and place an order using the Gerber zip file in the Github files. These pcb's are 4 layers, so you would specify that, as well as some other info such as length and width, color and so forth then pay for the order and wait. This is just a down and dirty rundown, others are free to join in and add to it.

[visrealm]

9 hours ago, Geoff Oltmans said:

So, how would I go about ordering up a PCB? I've sadly not ever done this from a open source hardware project and always bought a spare from someone who has.

RickyDean is correct. If you use JLCPCB, it correctly detects all of the details when you select the gerber file. Assembly on these is tricky though, with all SMD components, including a number of very small resistor packs.

 

I will make these available fully assembled too. I'd just like to finalize the next revision which doesn't require the Pi Pico module to be piggy-backed before I sell these. Probably in the next 3-4 weeks.

[JasonACT]

On 6/14/2024 at 1:32 AM, Asmusr said:

And do you think the other core would be fast enough to emulate a 100MHz TMS9900 (the F18A GPU)?

Question.. Has anyone timed a "JMP $" (>10FF) loop on the F18A GPU?  OK, that's really unfair without a logic analyser, you would need to have a counter to time something like that, but I'm interested in what number you would actually get if you calculated it by removing the counter time?  100MHz is a fairly round number, and without real meaning, so it would be nice to have an estimate of MIPS for a NOP loop on this device, since the TMS9900 doesn't really run 1-1 instructions for the MHz, and less so in 8 bit RAM.

 

That might give a ball-park figure for what the Pico needs to achieve.  In any case, I think I'm in the market for one of these devices.

[Geoff Oltmans]

11 hours ago, visrealm said:

RickyDean is correct. If you use JLCPCB, it correctly detects all of the details when you select the gerber file. Assembly on these is tricky though, with all SMD components, including a number of very small resistor packs.

 

I will make these available fully assembled too. I'd just like to finalize the next revision which doesn't require the Pi Pico module to be piggy-backed before I sell these. Probably in the next 3-4 weeks.

SMD doesn't bother me... I've done plenty of that. I've never ordered a PCB from a PCB house so I'm a little nervous it'll come back scaled wrong or something.

EDIT: And SMD shouldn't really scare anyone else. You can do some pretty fine pitch work with modest equipment.

Edited July 3 by Geoff Oltmans

[Duewester]

2 hours ago, Geoff Oltmans said:

EDIT: And SMD shouldn't really scare anyone else. You can do some pretty fine pitch work with modest equipment.

Flux is the key I believe.

To add to this conversation - I'm a fan of JLCPCB myself. You load the zip file from the git, pick a PCB color and they pretty much handle the rest. You get a nice preview of the Gerber's as well. The price for my last project (keyboard replacement) was better due to shipping. I can't attest to delivery time but I got mine in about ten days from the order day. China to SC took as long in the states as it did to get from manufacturing to the states.

[Geoff Oltmans]

1 hour ago, Duewester said:

Flux is the key I believe.

To add to this conversation - I'm a fan of JLCPCB myself. You load the zip file from the git, pick a PCB color and they pretty much handle the rest. You get a nice preview of the Gerber's as well. The price for my last project (keyboard replacement) was better due to shipping. I can't attest to delivery time but I got mine in about ten days from the order day. China to SC took as long in the states as it did to get from manufacturing to the states.

Yep, flux is definitely important in SMD. 

 

I'll give JLCPCB a shot. Thanks for the info. It's been a looooonng time since I did any board layout work... last time I did it myself I used one of  those transfer sheets you print on with a laser printer and iron on to a copper clad board and etch away yourself. ha

 

Edited July 3 by Geoff Oltmans

[JasonACT]

On 7/3/2024 at 9:04 PM, JasonACT said:

Question.. Has anyone timed a "JMP $" (>10FF) loop on the F18A GPU?  OK, that's really unfair without a logic analyser, you would need to have a counter to time something like that, but I'm interested in what number you would actually get if you calculated it by removing the counter time?  100MHz is a fairly round number, and without real meaning, so it would be nice to have an estimate of MIPS for a NOP loop on this device, since the TMS9900 doesn't really run 1-1 instructions for the MHz, and less so in 8 bit RAM.

 

That might give a ball-park figure for what the Pico needs to achieve.  In any case, I think I'm in the market for one of these devices.

The Pico @250MHz has the ability run TMS9900 instructions at 2MIPS average, peaking at 4MIPS for a JMP $ loop.  This is with GCC12.3 and -Os (-O2 was slower, GCC10.3 was much slower with either optimisation).

 

On 10/29/2014 at 5:00 AM, matthew180 said:

The F18A is implemented using an FPGA, but an FPGA nor the F18A are a "modified TMS9900". You can implement a TMS9900 on an FPGA as a "soft core", which the F18A does happen to do to some extent.

 

 

Yes, the F18A is internally clocked at 100MHz.

 

 

After finishing the 9918A functionality I had almost 40% of the FPGA still available. Not wanting to let almost half of the FPGA's circuits go to waste, I decided to implement a TMS9900 core and wire it behind the VDP's normal 8-bit host-interface. Since this was a "CPU" inside a video processor, I decided to call it the "GPU". The GPU is not a 100% TMS9900, I left a few instructions out on purpose because they did not make sense in this context, and I added a few instructions that seemed desirable (hardware stack support for example). The "GPU" has direct high-speed access to the 16K VRAM, all VDP registers, an extra 2K of private "GPU only" RAM, and runs at the F18A's internal 100MHz clock. A typical 9900 instruction will execute on average of around 150ns to 250ns (around 4 to 6 million instructions per second) depending on the source and destination addressing.

 

 

The V1.5 F18A has two 32-bit LFSRs as well as two 32-bit high-speed counters. The LFSRs are not a Mersenne Twister, just a 4-tap LFSR. However, in the upcoming V1.6 firmware I am removing all four components (the two LFSRs and the two counters) and replacing them with other features that are more desirable (second tile-layer and a blitter).

 

 

Probably. My fault really. The information in the forum is buried in long threads and you have to read the whole thread to know what is current (or read backwards). Documentation is a chicken-and-egg scenario though. Why write docs when there is a lack of interest in the F18A's enhanced features? However, you could also say there is a lack of interest because there is little official documentation. It is hard to justify the time, and I personally believe it is more of the former argument than the latter (and we *know* people are disinclined to read documentation at all, hence the existence of the venerable phrase "RTFM").

 

Right now the best course of action is to ask questions if you are interested (I try to be responsive), search the two main F18A threads, read the F18A register-use spreadsheet along with the 9918A datasheet, and check my website for possible posts with more details.

So, that answers my question (after reading a very long thread yesterday).  For many use-cases, I'd say this is in the ball-park.

 

@Asmusr would have to decide what other features would need to be implemented other than the GPU, most of the available F18A software is his ( @TheMole and a few others did produce some other examples though).  At least, that's the impression I got from reading the long thread.

[ti99user]

On 7/7/2024 at 1:09 AM, JasonACT said:

The Pico @250MHz has the ability run TMS9900 instructions at 2MIPS average, peaking at 4MIPS for a JMP $ loop.  This is with GCC12.3 and -Os (-O2 was slower, GCC10.3 was much slower with either optimisation).

 

So, that answers my question (after reading a very long thread yesterday).  For many use-cases, I'd say this is in the ball-park.

 

@Asmusr would have to decide what other features would need to be implemented other than the GPU, most of the available F18A software is his ( @TheMole and a few others did produce some other examples though).  At least, that's the impression I got from reading the long thread.

Can you also try -O3 and -Ox?

 

ti99user

[JasonACT]

On 7/10/2024 at 4:19 AM, ti99user said:

Can you also try -O3 and -Ox?

-O3 was slower when I tested last week, -Ox isn't an option in Arduino.  It's only 20-30K instructions per second slower with the worst optimiser selected.

[JasonACT]

On 6/26/2024 at 11:35 PM, visrealm said:

Not ordering these yet as I like to give it a few days to "simmer" in case I think of anything I've missed or could do better. Likely order the initial batch next week.

Is there any update with the latest v0.4 boards?

[visrealm]

1 hour ago, JasonACT said:

Is there any update with the latest v0.4 boards?

Apologies, it has been a while since my last update.

 

The v0.4 boards arrived yesterday . Just waiting on parts  (hopefully by the weekend) to build and test.

 

It's my first attempt at using an RP2040 directly, so I wouldn't be surprised if there are issues.

 

Here's a pic of the naked PCBs (and their predecessor):

 

 

In other news, I've been busy working to improve the read response time. My v0.3.0 firmware has a read request response time of ~200ns. This is out of spec for the TMS9918A's published 150ns max response time, but works perfectly fine on a TI-99 due to it using the very slow GROMCLK. I spent a long time trying to get this number down, but couldn't using the GPIO interrupt method I was using. So, decided to change the approach to use PIOs to handle the VDP <-> CPU interface instead. The results are seriously impressive. I've had to run the PIOs are quarter speed to get within spec of the real chip.

 

Here's some before-and-afters:

 

Key: CH1 (yellow) is !CSR and CH2 (magenta) is one of the data lines:

 

Using GPIO interrupts: Typically getting 200nS response time between CSR low and the data pin going high.

 

 

After the initial change to use PIOs:

Here's we're seeing ~80ns response time. This was while I was tuning the PIO speed. Initially, it was even faster.

 

Now, I've tuned it to 100ns matching the 'Typical' value on the TMS9918A datasheet. Switching to PIOs has definitely opening us up to run this on a much higher bus than the original TMS9918A. Additionally, it doesn't require the same (2us to 8us) waits between accesses like the original TMS9918A.

 

Also, in other news, I've sent a test unit to a guy in NZ who is willing and able to test it on: SVI 328/318, Coleco Adam & MSX 728. That arrived this week, so hoping to get some feedback from him in the next week or so.

 

Edited July 11 by visrealm

[Gary from OPA]

Would be nice to have it controllable as software switchable mode from original 100ns stable timing, to super turbo boost mode.

Edited July 11 by Gary from OPA

[visrealm]

Gary mode

[aotta]

Thanks for the update, i hope you'll keep the firmware update for the v0.3 boards, i personally prefers the "pico" solution, it's easier to build and pretty cheap.

Also, i spent my vote for an option for a composite sync instead of separate h & v syncs, i give a look at the code but it's not so easy for me to understand where to apply the "xor" between the two signals (i think in buildSyncData() but i'm still studing your code).

[visrealm]

Absolutely will keep the code compatible between both PCB versions. I completely understand the appeal of both.

 

I'll need to look into the composite sync.

[visrealm]

2 hours ago, aotta said:

i give a look at the code but it's not so easy for me to understand where to apply the "xor" between the two signals (i think in buildSyncData() but i'm still studing your code).

 

So, to get a composite sync signal, let's say using the HSYNC pin as the CSYNC signal, just need to replace these values:
 

  // sync data for a vsync scanline
  syncDataSync[SYNC_LINE_ACTIVE] = instNop | vSyncOn | hSyncOff | activeTicks;
  syncDataSync[SYNC_LINE_FPORCH] = instNop | vSyncOn | hSyncOff | fPorchTicks;
  syncDataSync[SYNC_LINE_HSYNC] = instNop | vSyncOn | hSyncOn | syncTicks;
  syncDataSync[SYNC_LINE_BPORCH] = instNop | vSyncOn | hSyncOff | bPorchTicks;

 

with this:

 

  // sync data for a vsync scanline
  syncDataSync[SYNC_LINE_ACTIVE] = instNop | vSyncOn | hSyncOn | activeTicks;
  syncDataSync[SYNC_LINE_FPORCH] = instNop | vSyncOn | hSyncOn | fPorchTicks;
  syncDataSync[SYNC_LINE_HSYNC] = instNop | vSyncOn | hSyncOff | syncTicks;
  syncDataSync[SYNC_LINE_BPORCH] = instNop | vSyncOn | hSyncOn | bPorchTicks;

 

Note, all hSync values inverted while vSync would be on. This would effectively be a XNOR combiner between the active low hsync and vsync signals.

 

I haven't tested it though as I don't have a display which accepts composite sync.

[aotta]

Thank you @visrealm for the update!

I'm interested in csync for using with scart output (and OSSC scaler in case): i'll test the changed firmware as soon as assembled v0.3 pcbs will arrive (they're on the way), but it's not clear to me if the changes you did in code should update h-sync output, v-sync one or both.... 

[visrealm]

Those changes only update the hsync output since that was the smallest change. That's where you'd connect your csync.

 

f you wanted to have both sync pins output the same value, You would change all 12 array values and change the vSync value (On or Off) to match the hSync value (On or Off).

[visrealm]

20 hours ago, visrealm said:

The v0.4 boards arrived yesterday . Just waiting on parts  (hopefully by the weekend) to build and test.

Looks like it will be Monday  

 

This, despite the package being scanned in my nearby (~35Km) capital city (Adelaide) yesterday morning. Gool ol' Australia Post.

 

I've also just published firmware v0.3.1

 

It includes the change from GPIO interrupts to PIOs for the VDP <-> CPU interface and many other small improvements, including getting the firmware binary down to 26KB in size (v0.3.0 was 70KB).

 

@aotta I've included #define VGA_COMBINE_SYNC 0 in vga.c. If you set this to 1, it will output a CSYNC signal on both Hsync and Vsync pins (untested).

 

I will eventually expose these options to CMake

Edited July 12 by visrealm

[aotta]

Looking at PCB schematic (i admit i ordered pcb 0.3 without checking it) i noticed that clock is not taken from crystal (pin 40) but only from cpuclk and gromclk (pins 37 & 38) that are not connected in Colecovision / Adam, so Pico9918 doesn't work on these machines, right? 

I planned to test it with my Colecovision.... 😔

[Gary from OPA]

3 minutes ago, aotta said:

Looking at PCB schematic (i admit i ordered pcb 0.3 without checking it) i noticed that clock is not taken from crystal (pin 40) but only from cpuclk and gromclk (pins 37 & 38) that are not connected in Colecovision / Adam, so Pico9918 doesn't work on these machines, right? 

I planned to test it with my Colecovision.... 😔

Cpuclk and gromclk are outputs on the 9918 so it shouldn't effect it's non-usage on the Colecovision.