TRH9000 - The Yamaha V9990 based open-source video card for the MSX

Page 7/8
1 | 2 | 3 | 4 | 5 | 6 | | 8

By ducasp

Paladin (669)

ducasp's picture

29-11-2022, 03:04

Swami wrote:
ducasp wrote:
crisag wrote:

Please note that the artifacts you see on the screen in some parts of the gameplay are due to the use of the board in a FPGA based MSX (I use one of those for development to avoid any damage to real vintage hardware).

If you are using ROM to test, you MUST use MGLOCM from KdL 3.6.1 delivery, newer versions of MGLOCM causes artifacts on V9990. Kim / ToughKidCst is the one responsible for that software but never had time to talk to him to debug this, perhaps you have, in the meantime, use older MGLOCM from 3.6.1 release of OCM-PLD, even if using with newer firmwares (3.7/3.8/3.9) it works fine

My SX-1 is from Oct 2018, so, it was produced about the same time as KdL 3.6.2. Hard to say what 8bits4ever installed for MGLOCM firmware. The Zemmix FPGA and SX-2 will almost certainly have the artifact unless I change the MGLOCM firmware.

MGLOCM isn't a firmware but a rom loader. You can use the one that was sent along KdL OCM 3.6.1 distribution with any firmware (i.e. 3.9.1) and then v9990 rom games work without artifacts Wink

By Swami

Expert (90)

Swami's picture

29-11-2022, 03:40

ducasp wrote:
Swami wrote:

My SX-1 is from Oct 2018, so, it was produced about the same time as KdL 3.6.2. Hard to say what 8bits4ever installed for MGLOCM firmware. The Zemmix FPGA and SX-2 will almost certainly have the artifact unless I change the MGLOCM firmware.

MGLOCM isn't a firmware but a rom loader. You can use the one that was sent along KdL OCM 3.6.1 distribution with any firmware (i.e. 3.9.1) and then v9990 rom games work without artifacts Wink

Cool. Here's hoping these carts go up for sale soon.

By doomn00b

Supporter (9)

doomn00b's picture

30-11-2022, 13:18

I noticed that in my previous post, my image-code did not work?? As such, I'm posting it as just straight links, again.

https://imgur.com/eT8ZcyI

https://imgur.com/JqSisQI

https://imgur.com/gM5iYVY

https://imgur.com/OaxMF32

crisag wrote:

MAN! loved the way you are separating the "more analogic" to "more digital"! lol... and what is the cool PCB art across it? super cool. My tests with the LMH1980 give a pretty good image quality. Still struggling with the superimpose, and I'm testing with the LT1675 RGB mux.

Ey, cheers mate! ^^

The pattern that goes across the board isn't actually a graphic, but "via fencing" - a technique where you make assymetric holes in the PCB, to separate different signal regions, to diminish Electromagnetic Interference - you then keep copper and components away from this border, as much as possible, only allowing crossover communication where you chose.

I had to remove the neat half-moon shapes tho, and use regular round holes... because otherwise it would cost extra to manufacture. ;(

(The half-moon shape is considered to give better EMI-protection)

Btw, I gotta' mention, CUDOS to you for managing to finish the layout twice! :O Talk is cheap, and I will admit that I was too cocky when I first claimed that we could fit it all in this space.

I'm almost there, but there has been more and more concessions in the design since my first bragging. @_x I'm not pleased with how many digital lines I have had to put on the "More Analog" layer. Still... only about 26 more lines to go! :)

By doomn00b

Supporter (9)

doomn00b's picture

30-11-2022, 22:18

crisag wrote:

I have the pleasure to say that the superimpose feature is now working on my prototype. However due to the challenges I had to make it work, and the differences in how RGB signals are exposed in the variety of MSX computers, I decided to release two versions of the board on GitHub: TRH9000 and TRH9000S

Great! I have noticed how requested this function is, so it's really good that you have managed to implement it. Smile

Also, good idea btw, I shall rename my variation to TRH9000D - for doomnoob.

Quote:

The biggest challenge I had was due to some MSX computers not exposing the YS sync signal that is required to control the superimpose feature on the V9990. There are ways to derive the required signal for the computers that don't explicitly offer it on the connector, but as some computers do that and some not, the complexity to research and find out if your computer offers the signal, change/make cables, etc is not just for the normal MSX user.

You can understand more just looking for the YS signal on multiple MSX computers exposing RGB on the wiki article

https://www.msx.org/wiki/RGB_(8-pin_DIN_45326)]RGB 8-pin DIN 45326 - MSX Wiki

You will see that some offer it, some not, some offer in different pins, together with other signals, etc

Ah... yes, I noticed this early on while researching the fabled Passthrough as well - so I just simply opted to only go with adopting the official RGB din-8 connector, from the MSX2+ standard, and ignore the rest. You make me think about how to circumvent the issue though! ^^ By creating daughtercards for the daughtercard, haha! LOL! With the right design, we can decouple the Din-8 connector from the graphics-card, onto a socketable mini-board that contains the plug and some support-components, which will then have to be altered for a couple of different variations of the RGB-input.

That's a ton more work of course... but it would offload the worst thinking for the end-users - they would just have to keep check of which MSX-model they have, and get the corresponding daughter-daughter-card for their machine.

An added bonus, is that it would improve the durability of the Din-8, since that part can be unsocketed while inserting the cable - the smaller pcb in the user's hand will make it easier to control the insertion-force.

Quote:

Then, the TRH9000 will have just one DB15 VGA/RGB 15Khz connector and will provide basically the same features of the traditional GFX9000. Important to mention that the new board is not using the Sony CXA2075 RGB encoder but a more modern Texas Instruments LMH1980 sync separator to form the RGB signal from the V9990 VDP. That change makes the board simpler and offers better video quality.

Hmm... that would not have been my preference - I feel that it's importsnt to offer something more, however small, when compared to the GFX9000 - otherwise, why choose the TRH over that?

That's why I put both a DB-15 and a SCART-output on the TRH9000D.
(Side-note: perhaps it's less confusing for the users if instead of letter-revisions at the end of the name, that we use number-increases? So, TRH9000, 9001, 9002, etc.)

The TRH9000S will feature two connectors. A DIN8 connector to receive RGB from the MSX computer connected and a DB15 VGA/RGB connector to output the resultant superimposed signal. Of course, there will be a way to allow MSX RGB passthrough or disable the MSX RGB input thus making the board behave like the conventional TRH9000.

So, there will be two versions on the GitHub moving forward.

A good idea. :)

Question - where you inspired by my implementation, with the Din-8 as a secondary/third connector, or was it just one of those no-brainers that people come up with when working on the same thing?

Quote:

TRH9000 Status

I just updated the repository with the v1.0 revision (first release). I’ve been using the board for the past several weeks and the video quality improved a lot from the initial prototypes, but of course it can be improved. I tried to isolate digital from analogic, separate the oscillators from the rest of the components, use shorter video traces on the board, etc but there is still room for improvement.

If you are curious to see the v0.3 prototype in action, please check this video of a bad player (me) playing Life on Earth TRH9000 - The Yamaha V9990 based open-source video card for the MSX - YouTube

In parallel to the effort to improve video quality, I’m also working to fit the board into a conventional MSX cartridge case. We have access down here in Brazil to factory quality ABS cases and I’ve been using a laser to create cardboard simulations before making improvements on the real board and order real PCBs.

Some pictures below



TRH9000S Status

My initial effort to implement the superimpose feature was using a LT1675 specialized RGB mux from Linear Technology. That chip is great, but requires +/- 5V, something we haven’t planned initially on the board (we have just +5V). That forced me to use ICL7660 to generate the right voltages, plus another LMH1980 to separate the sync signals from the RGB coming from the MSX… you can imagine the board would never fit a standard cartridge with so many ICs…

Then Doomn00b had the idea to use a SN74CBT3257 mux from TI. Well… results were the same with both, but the board is just a lot simpler with just that chip that with the collection of ICs I was using.

For the TRH9000S I have ordered the second batch of prototype PCBs to play with the signals. The video quality is also dependent on the developments made with the simpler version. I tested my prototype in an Omega MSX2 with success, but still need to see it working on my FPGA MSX (even changing the output to 15Khz I couldn’t see the superimposed image).

To fit that version into a conventional cartridge I think I’m already touching the limits of what is possible with routing in such a small work surface. ????

Well, that is it for today… I’ll keep you posted.

Eyyy, glad to hear I had a positive impact! ^^

I've been thinking about the size... although I agree with keeping it as compact as possible (it's just so darn cool!) - I think we should accept that we're already breaking the standard by even doing openings in the casing for the connectors, to begin with.

If what it takes to make a good product is a bigger board, then we should do that - remember, engineering is the art of using compromises to solve a given problem.

By crisag

Resident (55)

crisag's picture

07-12-2022, 18:17

Do you happen to have the MGLOCM from KdL 3.6.1? I can't find that package anymore and the tool from the latest package I believe has the bug.

By crisag

Resident (55)

crisag's picture

25-12-2022, 23:20

Hi friends, boards arrived from JLCPCB and during tests I noticed a weird behavior when superimposing the image. As you can see on the picture below, I'm getting a weird noise on the image generated when superimpose is activated. The board is working ok, but the image just don't have the quality expected. I've changed the capacitor values hoping it is something with them, but that doesn't seem to affect the horizontal noise bars on the image.

Strange is that in some games that is almost not noticed, but with Battle Bomb for example it is very evident. Also it is located towards the bottom part of the image. The TRH9000 (without superimpose feature) also has that, but it is very subtle and changing the resistance we have for each color we can alleviate that easily.

Anybody with experience in video to shed some light?

By sd_snatcher

Prophet (3608)

sd_snatcher's picture

26-12-2022, 04:49

crisag wrote:

The biggest challenge I had was due to some MSX computers not exposing the YS sync signal that is required to control the superimpose feature on the V9990. There are ways to derive the required signal for the computers that don't explicitly offer it on the connector, but as some computers do that and some not, the complexity to research and find out if your computer offers the signal, change/make cables, etc is not just for the normal MSX user.

Wait, wait! The MSX internal Ys signal is not necessary at all to have a working superimposer on the V9990 cartridge.

The idea is to superimpose the V9990 over the MSX video and not the opposite. IOW, the V9958 will appear as an extra (and very colorful) background layer for the V9990 games.

The Ys signal used for this type of superimposition is generated by the V9990 chip itself (pin-91).

By sd_snatcher

Prophet (3608)

sd_snatcher's picture

26-12-2022, 05:33

crisag wrote:

Anybody with experience in video to shed some light?

I took a look at the schematics of the TRH9000 and I'm sorry to tell you that that the analog part is dangerously wrong.

The CXA2075 or an equivalent chip cannot be eliminated. It's not only the TV-Encoder, but it also does the RGB buffer. The MSX VDPs cannot drive their signals directly to a cable, at risk of frying the chip's outputs.

If you don't want a TV-Encoder chip, at least a THS7316 chip should be present to drive the RGB lines. But I strongly encourage to have a CXA2075, since sometimes the user simply won't have a monitor with RGB inputs to use. So CVBS and S-Video outputs are always welcome.

IMHO, there's also no need to have the separate sync on the VGA connector. This will be a hindrance since most people will just use it to connect to a SCART input that requires CSYNC. Just connect CSYNC output to the pin-13 of this connector since this is accepted by the majority of the VGA monitors/projectors that accept 15kHz RGB.

Also, the LMH1980 clearly states that "The logic outputs do not have high output drive capability.". This means that they also cannot be connected directly to the VGA connector and would require a buffer chip for that. So, just get rid of the U6A, and use a NC7S08M5X (or 74AHCT1G08DBV) to buffer the CSYNC signal for the VGA connector.

Lastly, I'm not sure if your superimposer will be able to impose the V9990 over the V9958. The way you have designed is described in the V9990 datasheet as being able to sync a dual V9990 setup and, if the timings are different because a different video source is used, the V9990 might malfunction. Since the V9958 might have different timings, I would strongly recommend to do extensive testing before approving this design as definitive.

Last, the pin9 of the VGA connector should provide +5V, otherwise it will be a nuisance to connect this cartridge to SCART inputs. You need to supply that +5V via a polyfuse, to protect the MSX power supply against short circuits.

By sdsnatcher73

Prophet (3810)

sdsnatcher73's picture

26-12-2022, 06:52

The deteriorating signal towards the bottom of the screen may well disappear with the addition of the TV encoder/RGB buffer as mentioned by sd_snatcher.

By ducasp

Paladin (669)

ducasp's picture

26-12-2022, 12:48

crisag wrote:

Do you happen to have the MGLOCM from KdL 3.6.1? I can't find that package anymore and the tool from the latest package I believe has the bug.

I thought to have replied this on your YouTube video but couldn't find my comment there anymore, not sure what happened... This one should work fine, at least it did for me in the past, it has been quite some time since I've used my 9990

https://drive.google.com/file/d/10oVFqN1Lhv9jB_neeh3kYRWzzOY...

Page 7/8
1 | 2 | 3 | 4 | 5 | 6 | | 8