RGB mod for TMS99xx based computers

[gunrock]

I'm guessing that people have seen:

tms-rgb-board.png (224.44 KiB) Viewed 15212 times

It's a RGB modification for TMS99xx machines. It actually mentions the Memotech MTX on it's landing-page at:

https://tms-rgb.com/

It's quite pricey if you buy it ready to install, about 32 EUR from Ireland (plus postage). Has anybody seen it or tried it? Or does everybody only run CP/M?

You could build it yourself, but the SMD soldering on this looks waaaaay beyond my abilities.

[Bill B]

Not seen it, thanks. I must take the time to read the details.

Various other options for achieving the same effect:

• http://www.primrosebank.net/computers/m ... kvideo.htm
• http://www.nyangau.org/video/video.htm
• CFX-II. The Propeller could do better if it was generating 50Hz TV output rather than 60Hz VGA output.
• Could almost certainly do something with a Raspberry Pi Pico

[Dave]

Hi Bill,

I know that we are working (very slowly - sorry Martin!) on a modified CFX with better VGA, but perhaps a slightly redesigned CFX-II would be a good idea too. I had always targeted VGA, particularly for the 80 column screen needed for CP/M, but as a games platform, perhaps PAL/NTSC RGB is good enough? (I know that you don't use games, but for other . . . . . )

If the Propeller could achieve that more easily than VGA, maybe it is worth thinking about?

regards
Dave

[Bill B]

The issue is the difference between 50Hz and 60Hz.

Games use the VDP interrupt to update the VDP only when it is not refreshing the screen. Since the Propeller is running at a different refresh rate, it frequently draws the screen partly through an update, resulting in display artifacts such as spurious sprites.

To do better, the Propeller would need to either synchronise with the VDP interrupt (tricky), or completely replace the VDP, in which case it would need to do sprite collision detection and generate the frame interrupt.

Some TV/Monitors (mine for example) will accept 640x480 VGA at 50Hz rather than 60Hz.

[gunrock]

More interestingly and thus more expensive and currently rarer than hens teeth is this complete replacement for the TMS99xx:

https://dnotq.io/f18a/f18a.html

Unfortunately, the MK2 batch is not ready because the creator has some personal stuff going in the pandemic that means progress is temporarily halted and the MK1 batch sold out (and it's not open source - which is fair enough given how sophisticated it is).

It effectively replaces the VDP completely and adds VGA out (HDMI out on the MK2 when it arrives). The great thing is, that it uses it's own onboard RAM, thus their might be a lot of systems across that used the TMS99xx range that have bad ram and non-technical users might be able to return them to use.

It also has a lot of enhancements:

Code: Select all

80-column (T80) mode.
Position-based attributes for T80 mode, so each tile can have its own foreground and background color.
64 programmable 12-bit (4096) color palette registers.
High-speed “data port mode” for fast palette register updating.
Three enhanced color modes (ECM) that provide 1, 2, or 3 bits-per-pixel allowing 2, 4, or 8 colors per-pixel for each tile and sprite.
32-sprites on a line at once (can eliminate sprite flicker if software did not implement sprite-rotation).
Each sprite can have its own size (8x8 or 16x16), and X/Y pattern flip.
30-column mode that provides 32x30 tiles (same as the NES).
Two independent tile-layers, each with their own name, color, and pattern table base addresses.
Per-tile attributes so each tile can have its own foreground and background color, priority over sprites, X/Y pattern flip, and transparency.
Independent horizontal and vertical pixel-scrolling for each tile layer.
Tile page sizes of 1x1, 2x1, 1x2, and 2x2 to support edge-to-edge pixel scrolling.
Bitmap layer with programmable size from 1x1 to 256x192 pixels, pixel locatable, 4-colors per pixel, 16-colors per pixel “fat pixel” mode, sprite priority, and palette select.
Programmable horizontal-line interrupt.
Programmable signed increment value for the VDP Address Register.
Ability to read all VDP Registers.
Programmable 46-bit decimal counter with 10ns (nanosecond) precision (can count 18.2044 hours with 10ns accuracy).
A 100MHz TMS9900-based “GPU” processor that can execute programs in VRAM, has full access to all VDP Registers, a high-speed DMA, and dedicated pixel-plotting and address instructions.
Virtual scan-lines for a retro CRT look.

Most of which I think cross into the territory of "is this still a Memotech/Coleco/MSX/SVI, etc." Personally, I've no problem with that; there are lots of similar enhancements for retro hardware like the Turbo Chameleon for the C64, 48mhz mode and MultiSID emulation (8 SID chips!) on the Ultimate 64, the Vampire for the Amiga and so on. I think demo makers could do some really cool effects with this chip and perhaps ports of MSX 2/NES games to all sorts of platforms could be pulled off, maybe enhanced scrolling for "deluxe" versions of existing games, etc.

The only downside I see is bifurcating the communities of smaller platforms like the MTX if the major software contributors switched to using the extra features (Bill and Claus, for example). Other larger-selling platforms like the MSX 1 have room for a subset of hardware. The thing that impresses me in this community is the level or collaboration and interoperation of add-ons. Part of that, IMHO, is the legacy left by Memotech with the FDX, SDX expansions and the rest is the genius of you guys.

[Martin A]

Interesting find, I have tried feeding the colour difference signals from the VDP to a compatible TV. The excess blue was very evident, tweaking the relative blue output level via the divider resistors didn't do a whole lot. Now I know the reason why,

The issue is the difference between 50Hz and 60Hz.
[snip]
To do better, the Propeller would need to either synchronise with the VDP interrupt (tricky), or completely replace the VDP, in which case it would need to do sprite collision detection and generate the frame interrupt.

Could the propeller be slowed down to output 50hz at TV frequencies for RGB SCART ? a VGA to SCART adapator cable would solve the "problem" of CFX-II not having a SCART socket.

[gunrock]

Actually Martin, it seems that Tatung may have solved the too-much-blue issue with the TC01:

https://atariage.com/forums/topic/30893 ... nt-4712449

Great detective work on their part. It's great that Memotech and Tatung published schematics for future arche(techn)ologists!

[Bill B]

Could the propeller be slowed down to output 50hz at TV frequencies for RGB SCART ? a VGA to SCART adapator cable would solve the "problem" of CFX-II not having a SCART socket.

Slightly more involved than just slowing from 60Hz to 50Hz to feed into a SCART socket. Would need to generate 625 line interlaced frames rather than 480 line non-interlaced. But yes, the Propeller could generate a TV standard signal.

However to be worth doing it would be necessary to either:

• Find some way of synchronise the Propeller screen refresh to the VDP screen refresh.
• Pull the VDP chip. In which case the Propeller would need to generate the end of frame interrupt and the sprite collision signal.

[Martin A]

Thinking out loud here, feel free to say this is complete rubbish....

In emulation mode, the propeller is already monitoring ports 1 and 2 in order to update the shadow copy of the screen. Can it also snoop on the VDP replying to status register reads, to monitor "F" the interrupt flag, and from that get an idea of the interrupt timing ?

I know of at least 1 game that used the changing state of "F" to decide when it was safe to write to the screen instead of using the VDP interrupt.

Since the propeller has acces to all the lower address bus, it could also monotor the setup of CTC channel 0 it would "know" whether the VDP interupt is in use or not, and pick the strategy accordingly?

[Bill B]

The MTX ROM does not enable the VDP interrupt. It reads the VDP status register in routine SPRCYC (0x3CF1) called from the timer interrupt routine VINT (0x3A55). So every 1/125s or 8ms. The frame interrupt is at 1/50s or 20ms. 20 ms is not divisible by 8ms, so would see the interrupt flag set at alternating 16ms and 24ms intervals. And the timer interrupt is not synchronised to the VDP frames anyway, so there would also be a random offset. So in ROM BASIC I don't think there is any way to synchronise frame updates.

To try and achieve synchronisation for games depends upon what the game does. Simplest if the game does enable the VDP interrupt, since the timing of that is known. The Propeller can, in principle, recognise an interrupt acknowledge (/IORQ with no /RD or /WR). It would be slightly easier if /M1 was connected. To be certain that the interrupt is a VDP one, the Propeller would have had to snoop on the programming of the CTC interrupt vector, and compare this with the vector in the interrupt acknowledge.

If trying to use snooping on the VDP status read, difficult to know when that is done. The program could:

• Be polling the status to detect end of frame.
• Called immediately after a VDP interrupt, before updating any of the display data,
• Called at the end of the interrupt routine, after updating all the display data, to clear the interrupt flag.

It might be simpler to just detect the first write to port 0x01 or 0x02 following a relatively long gap (enough for 256 lines of display).

And then synchronising the Propeller output to whatever signal is being used, without causing major glitches in the display in the event of a mistake in recognising the timing. Perhaps a small delay at the end of the frame which causes the Propeller output to run slightly slow, but have whatever timing event is being used cause this extra delay to be terminated.

Um ... Those last two ideas might just work. But I have got too much else on at the moment.