Is CD+G possible?

[zakk4223]

OK, finally got it working after doing my own Quartus build - I think I picked up an earlier prebuild before things were ironed out.

Is what appears to be random decoding and/or paint errors a known issue? No matter what disc I choose (or how many times I cold restart), a minimum of one (but often 2-4) vertical 'strips' anywhere from 2 to 8 'blocks' high on various parts of each screen are either flat-out corrupt or "leftovers" from a prior screen (but in the wrong place!). Not quite sure how to explain it, I can make a video if it'll help.

I see it sometimes, and it isn't consistent at all for me. So it's likely not something simple. This is one of the disadvantages of not having a SegaCD myself to compare/test with. It's like it misses an update for a block randomly; kinda makes me suspect this could be some sort of subtle timing issue related to when the subcode data interrupt is generated.

[dshadoff]

I see what you mean; I saw this very often on the cdrdao->CHD rips, but not so much on the CloneCD ones.
Are you using a FIFO to stream the subcode data, or is it possibly being overwritten by the next sector ?

Since the CDDA seems to have a pretty big 8000-sample output FIFO (plus whatever SCSI FIFO exists), if the subcode doesn't have something similar, there could be data loss (but then there should also be a flush whenever there is a repositioning...).

[zakk4223]

The existing MegaCD subcode stuff I resurrected+fixed didn't have a FIFO. It just updates/simulates the ring buffer the raw subcodes are stored in and asserts the interrupt. That ring buffer is only 15 words bigger than a full subcode set, although the interrupt is supposed to only fire when a full subcode set is 'valid' in the buffer. I guess there could be some timing differences with how that buffer is filled and the overflow flag managed since we aren't reading from a cd directly.

I'm also not very (as in, at all...) experienced with FPGA programming so there may be something I'm doing wrong. Maybe I should be using a signal instead of a variable etc. I also need to dig a bit deeper into how ARM->Core data transfer works so I can understand that bit of code better.

[dshadoff]

I think it's close enough for a pull request; if there is an improvement or bugfix needed, it can come afterward.

[rhester72]

If you can make it there, you can make it anywhere...

https://www.rendezvo.us/cdg_try2/Lou%20 ... D+G%5D.chd

[zakk4223]

This was in the latest update of Main+MegaCD core. One step closer to the ultimate FPGA Karaoke machine

[Stupid Dufus]

Just wanted to say I tried it out with Information Society. Blast from the past. First CD I ever asked for as a kid. Thanks for adding this in.

[WiteWulf]

Hi folks, I'm curious to see these running. I've grabbed some CD+G CHD files (linked from this thread) and loaded them up in the MegaCD core in MiSTer. I get music but no graphics, even after selecting the CD+G option in the CD player app. Am I missing something?

The MegaCD BIOS version appears to default to is a Japanese v2.00, so I'm guessing "[BIOS] Mega-CD 2 (Japan) (v2.00C).md"

[rhester72]

It should 'just work'. Are you sure your main and core are both up-to-date?

[WiteWulf]

Yeah, did an update_all before I tried it. Weird, I’ll try again later.

*edit* Yeah, update_all.sh wasn't running properly. I usually start it off and go do something more interesting while it runs Turns out that update.sh was abending as some ssl certs were out of date, so I had to run security.sh to fix those. Now everything's up to date and I have the current versions of main and megacd I've got the CD+G working, thanks

FYI, regarding different data channels: the Lou Reed disk has lyrics in (I think) Spanish and French on channels 2 and 3.