I'm guessing that people have seen:
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.
RGB mod for TMS99xx based computers
RGB mod for TMS99xx based computers
Steve G
Danish Memotech MTX 512, MFX and loving it
Danish Memotech MTX 512, MFX and loving it
Re: RGB mod for TMS99xx based computers
Not seen it, thanks. I must take the time to read the details.
Various other options for achieving the same effect:
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
Re: RGB mod for TMS99xx based computers
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
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
Re: RGB mod for TMS99xx based computers
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.
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.
Re: RGB mod for TMS99xx based computers
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:
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.
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.
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.
Steve G
Danish Memotech MTX 512, MFX and loving it
Danish Memotech MTX 512, MFX and loving it
Re: RGB mod for TMS99xx based computers
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,
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.Bill B wrote: ↑12 Feb 2021 16:04 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.
Re: RGB mod for TMS99xx based computers
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!
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!
Steve G
Danish Memotech MTX 512, MFX and loving it
Danish Memotech MTX 512, MFX and loving it
Re: RGB mod for TMS99xx based computers
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.
Re: RGB mod for TMS99xx based computers
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?
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?
Re: RGB mod for TMS99xx based computers
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:
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.
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.
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.