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

[visrealm]

16 hours ago, Asmusr said:

But still, the F18A has an additional tile layer, a bitmap layer, hardware scrolling, more sprites, and more colors. I guess it would be tight? And do you think the other core would be fast enough to emulate a 100MHz TMS9900 (the F18A GPU)?

Agree, it's tight. Would certainly need some optimising to squeeze that all in. Also, we are limited by VRAM, right? So, although the F18A supports all of those features, it's difficult to use them all at once.

 

9900 CPU would certainly be doable on the idle core, but no chance we're getting anywhere near 100MHz.The Pico is running at 252MHz. My PICO-56 emulates a 65C02 (and the rest of its hardware) and I get around 4MHz. I'd say that's the achievable ballpark speed. Obviously, access to the VRAM, VREG, etc is much faster for the GPU than it is for the external CPU, so a 4MHz (for example) TMS9900 GPU with direct access would still be quite useful.

 

Edit:

 

@Asmusr I'm curious - do you have a rough idea of the GPU clock frequency you're getting in JS99er? Or classic99?

Edited June 14 by visrealm

[visrealm]

16 hours ago, Artoj said:

Wonderful Work Troy!!, I appreciate the gift of technical prowess it takes to accomplish feats such as you have shown! I am in awe, knowing you are also an Aussie, you might even live in striking distance of me, LOL.

Thanks! I'm in the Adelaide hills...

[sometimes99er]

The Yamaha V9938 (1985) is largely accepted as the successor of the Texas Instruments TMS9918. The V9938 is used in the MSX2 (1985) and the Geneve 9640 (1987) (enhanced TI-99/4A). Maybe the V9938 is a more suitable target for your project. Other derivatives of the TMS9918 include Famicom/NES (1983), Mark III/SMS (1985), Mega Drive/Genesis (1988), SMS II (1990) and Game Gear (1990).

[Gary from OPA]

8 hours ago, sometimes99er said:

The Yamaha V9938 (1985) is largely accepted as the successor of the Texas Instruments TMS9918. The V9938 is used in the MSX2 (1985) and the Geneve 9640 (1987) (enhanced TI-99/4A). Maybe the V9938 is a more suitable target for your project. Other derivatives of the TMS9918 include Famicom/NES (1983), Mark III/SMS (1985), Mega Drive/Genesis (1988), SMS II (1990) and Game Gear (1990).

i would agree, i rather see a replacement for v9938 with vga, since you have the ram, and already doing 640x480, so you should be able to handle the 512x424 mode, and its just a matter of adding the extra few modes, you already got 80col.

 

that way, there is two options for people, the f18a or this, each with its own nice features. We really don't need another device doing the same as f18a, and you wouldn't have to worry about speed wise for cores, as v9938 is not much more handling wise compared to the 9918.

 

And then your device would also have a larger market for all those wanting to upgrade their older MSX1 machines, there a few options out there already but that add stuff not needed.

[visrealm]

I'd like to look at doing the V9938 in the future, however I don't have anything to test it on. It's not pin-compatible with the TMS9918A (being a DIP64) and would require some way of manipulating the additional MODE pin at a minimum if I made a DIP40 version that was mostly pin compatible with the TMS9918. And to make a drop-in replacement for a V9938 would be a lot more complicated. There are a lot more signals (which I'm not sure are used in reality or not). So, I can't see that being much use to anyone (can't drop it in a TMS9918A socket and get the extra features without the MODE1 pin and can't drop it in a V9938 socket and expect everything to work).

 

Baby steps...

 

Initially, I'll just be focusing on the TMS9918A drop-in replacement which is pretty much done now except for integrating the RP2040 in a future hardware revision.

 

I'd still like to look at adding some form of F18A support later, though I do understand this can complicate things for developers (I'm a software guy too, not a hardware guy). The main issues I see with the F18A are it's hard to get (I don't have one btw), it's hard/expensive to build, and it's hard to tinker with (without FPGA/VHDL knowledge).

 

I'm not aiming to replace the F18A. It's the well-established standard and the lowly RP2040 could never compete with it. But, I could provide a much cheaper alternative you can actually buy/build easily and modify yourself. Something to hack with.

[Gary from OPA]

3 hours ago, visrealm said:

I'd like to look at doing the V9938 in the future, however I don't have anything to test it on. It's not pin-compatible with the TMS9918A (being a DIP64) and would require some way of manipulating the additional MODE pin at a minimum if I made a DIP40 version that was mostly pin compatible with the TMS9918. And to make a drop-in replacement for a V9938 would be a lot more complicated. There are a lot more signals (which I'm not sure are used in reality or not). So, I can't see that being much use to anyone (can't drop it in a TMS9918A socket and get the extra features without the MODE1 pin and can't drop it in a V9938 socket and expect everything to work.)

 

Well, I wouldn't look at making it fit into a dip64, if they already have a working v9938 then there would be no need.

 

Only thing needed is the one extra address line the mode1 pin. For my Tiny-TIM which was a PCboard with the v9958 on it and 192k of ram I made to as drop-in replacement for the 9918, you only needed to run and solder 1 extra wire outside of the dip40 socket to get the extra address line for the other port access.

 

If you have one free signal line on the pico9918 it would be worth it to add the rest in via software at some point.

 

Anyway still great job. I just got myself a f18a so going to play with that soon, but looking forward to getting one of your devices as well for my other ti99 system so I have at least 80col mode and VGA output I see your device as affordable way to add both of those features to any ti99 console.

 

 

[visrealm]

29 minutes ago, Gary from OPA said:

 

If you have one free signal line on the pico9918 it would be worth it to add the rest in via software at some point.

I will definitely do this.

[Artoj]

8 hours ago, Gary from OPA said:

Only thing needed is the one extra address line the mode1 pin.

Here is a low res collage of some of my work, regarding spare pins on the TI motherboard. Regards Arto.

[Gary from OPA]

1 hour ago, Artoj said:

Here is a low res collage of some of my work, regarding spare pins on the TI motherboard. Regards Arto.

 Thanks, I forgot there was some unused 9901 pins. Useful for those wishing to control their special internal motherboard add-ons or mods.

Edited June 15 by Gary from OPA

[sometimes99er]

On 6/15/2024 at 2:18 AM, visrealm said:

And to make a drop-in replacement for a V9938 would be a lot more complicated.

AFAIK, something like that was made for the MSX (to upgrade it to MSX2 specs).
 

[Tursi]

On 6/13/2024 at 1:59 PM, visrealm said:

@Asmusr I'm curious - do you have a rough idea of the GPU clock frequency you're getting in JS99er? Or classic99?

In interleave mode Classic99 runs 20 GPU instructions per host CPU instruction. It's a pretty rough estimate but works well enough so far.

 

[+Yurkie]

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

The Pi Pico has 264KB of RAM, so I think 192K could be do-able... Just. Depends how much code we need in RAM.

 

Assembly might help, but GCC is pretty darn good at generating ARM assembly for the RP2040. Performance could certainly be improved by making my TMS9918 library more Pi Pico friendly. Currently, it's quite generic and was originally written for my Desktop homebrew computer emulator. Later ported to Web (WASM), then the Pico with very few actual code changes, so wasn't designed with embedded systems in mind.

 

My Pi Pico VGA implementation (written from scratch as well) has been tested up to 1024x768. I find for the TMS9918A, 640x480 works well with doubled pixels - 800x600 also works really well with tripled pixels, resulting in a slightly smaller border. I haven't looked into the DVI/HDMI output options yet.

 

80 column text would certainly be doable. Other F18A features could also be added relatively easily. Not sure about the virtual 9900 "GPU" - I haven't looked into the 9900 that much yet and have so far written all of my emulation libraries myself to gain a deeper understanding of whatever it is I'm emulating.

 

I haven't added support for the undocumented display modes.

I need a couple of these to show off your great product on my Zenith 32" CRT with VGA input It's a commercial tv/monitor from a school AV Cart.

[visrealm]

7 hours ago, Tursi said:

In interleave mode Classic99 runs 20 GPU instructions per host CPU instruction. It's a pretty rough estimate but works well enough so far.

 

Thanks, @Tursi I later looked at the Classic99 code and saw the 20:1 there. JS99er looks to run at 25:1.

 

2 hours ago, Yurkie said:

I need a couple of these to show off your great product on my Zenith 32" CRT with VGA input It's a commercial tv/monitor from a school AV Cart.

BIG pixels

[retrodroid]

20 hours ago, visrealm said:

Thanks, @Tursi I later looked at the Classic99 code and saw the 20:1 there. JS99er looks to run at 25:1.

FIGHT!!!

 

😛

 

 

What is meant by "GPU instructions? Not bytes written to VDP RAM?

[Tursi]

20 hours ago, visrealm said:

Thanks, @Tursi I later looked at the Classic99 code and saw the 20:1 there. JS99er looks to run at 25:1.

And it's important to note that F18A instructions do not have the same cycle count as the matching instructions on the host CPU, so there's no scientific meaning to the ratio. We don't officially have a table of F18A cycle counts so a rough estimate that "seems to work" is good enough for now.

 

Going too fast is not likely to be a problem since F18A software right now is unlikely to be cycle counted. But too slow may cause some software to fail - for instance my scanline palette code needs enough performance to be able to unpack a new palette for every scanline. Also my GPU-test for presence assumes the F18A can start execution and modify VDP RAM faster than the host CPU can execute a NOP and read VDP... though that's likely to be true even if they ran 1:1.

 

[Tursi]

20 minutes ago, retrodroid said:

What is meant by "GPU instructions? Not bytes written to VDP RAM?

Basically, the F18A can execute 9900 instructions out of VDP memory, and this second processor is referred to as the GPU (since it's on the video chip). This GPU is an extremely fast 9900 - clocked at 100MHz and with instruction timing much faster than the host CPU.

 

So basically, you can upload code to VDP RAM and ask the F18A to run it. I made a mandlebrot generator demo to show off the performance difference - you can run the same code on both the CPU and then the GPU and see the difference.

 

https://harmlesslion.com/software/mandlebrot/

 

I don't have the video anymore, I searched. But the TI took 30 seconds to draw the screen, and the GPU ran the same code in about 3. JS99er has the GPU version in the F18A section (but not the stock version for comparison )

 

[retrodroid]

On 6/17/2024 at 4:34 PM, Tursi said:

Basically, the F18A can execute 9900 instructions out of VDP memory, and this second processor is referred to as the GPU (since it's on the video chip). This GPU is an extremely fast 9900 - clocked at 100MHz and with instruction timing much faster than the host CPU.

 

So basically, you can upload code to VDP RAM and ask the F18A to run it. I made a mandlebrot generator demo to show off the performance difference - you can run the same code on both the CPU and then the GPU and see the difference.

 

https://harmlesslion.com/software/mandlebrot/

 

I don't have the video anymore, I searched. But the TI took 30 seconds to draw the screen, and the GPU ran the same code in about 3. JS99er has the GPU version in the F18A section (but not the stock version for comparison )

 

Wow, that's amazing!  I had no idea the F18A had a super-fast 9900 CPU capability.

[Asmusr]

1 hour ago, retrodroid said:

Wow, that's amazing!  I had no idea the F18A had a super-fast 9900 CPU capability.

My F18A Karts demo would be impossible without the GPU.

[visrealm]

I have just released the Gerbers for the PICO9918 PCB v0.3. I've been running tests continuously for a week or so on this revision and it is working great. 

 

I've been thinking about how to go about getting this tested on more machines as I've only tested on two TI-99/4A's (PAL and NTSC) and my HBC-56. I might produce a few of these to send out to those who are willing and able to try it on a wider range of machines. Let me know if you're interested in this.

 

Note: This PCB revision is not representative of the final release which will be a single board without the need to the piggy-backed Pi Pico board. However, v0.3 is fully functional. If you're a tinkerer or early-adopter type, go ahead and give it a go. If not, I suggest waiting.

 

https://github.com/visrealm/pico9918

Edited June 25 by visrealm

[aotta]

@visrealm:  I just ordered the pcb and trying to build the firmware for pico, but can't compile it with vscode in Windows... i have to include in some way the submodules into? could you give some tips on how to build the .u2f files for windows user?

And, other question: i'm interested in use it on some PAL consoles (colecovision and sega sc-3000), they use the 9929 instead of 9918 one, i need to change something to emulate the 9929? 

Thank you in advance and my compliments for your great work!

[visrealm]

6 hours ago, aotta said:

@visrealm:  I just ordered the pcb and trying to build the firmware for pico, but can't compile it with vscode in Windows... i have to include in some way the submodules into? could you give some tips on how to build the .u2f files for windows user?

Nice one.

 

To clone including the submodules:

 

git clone --recurse-submodules https://github.com/visrealm/pico9918.git

 

I just added a section on setting up the dev environment for Windows: https://github.com/visrealm/pico9918?tab=readme-ov-file#development-environment

 

Also, note: I do have the .uf2 file published under the releases section: https://github.com/visrealm/pico9918/releases You'll find the .uf2 file there under Assets.

 

6 hours ago, aotta said:

And, other question: i'm interested in use it on some PAL consoles (colecovision and sega sc-3000), they use the 9929 instead of 9918 one, i need to change something to emulate the 9929? 

It works to replace either a 9929 or a 9918 since the output is VGA. However, when replacing a 9929, it will behave as a 9918 in that the framerate (and interrupt frequency) will now be 60FPS. I've tested this on a PAL (9929A) and NTSC (9918A) TI-99/4A with no issues.

6 hours ago, aotta said:

Thank you in advance and my compliments for your great work!

No worries. If you have any issues, don't hesitate to ask. 

 

I will likely do up either a short build video or some build instructions soon.

[aotta]

Thank you @visrealm for the info, sorry but i completely missed the "release" section! 😁

Anyway i got compiler finish with return code 0 after copying the submodule from github into the subfolder and setting up the python environment (i simply added the python path and gitted the "PIL" as in the remarks in your code.

Just for confirming, the pico clone you used are the "black" ones, right? I used the "purple" ones in other projects but i think they have different pinouts.

Can't wait for the pcbs to start testing your fantastic PICO9918!

[visrealm]

Awesome.  This is the pinout. Note GPIO23 and GPIO29.

 

Edited June 26 by visrealm

[visrealm]

Started working on the next revision of the board (v0.4). The all-in-one. 

 

Looking pretty good. Managed to have it mostly single-sided (good for cheaper PCBA). Most of the components will be on the underside. 4 layers with the middle layers being a solid ground pour and a (mostly) power layer. Signals mostly on the IC layer (bottom) with some on the back (top).

 

On the top side are a couple of optional LEDs for read and write (for those who like the blinkenlights). The Boot button and USB-C connector required for reprogramming to little RP2040.

 

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.

[aotta]

Very nice! just wondering, is planned also a composite output (for an easy connection to rgb monitor or SCART TV) instead of separate VGA H & V Sync, in future versions?

Edited June 26 by aotta