Skip to content

TG100 sample ROMS

Technical discussion which is not directly related to VGM files. Talk about Hardware and Software.

Moderator: Staff

Post by vampirefrog »

Can you characterize the idle time commands? I'd like to filter those out to save bandwidth.

Edit: in fact, is it possible to see a vgm2txt of the idle commands? And perhaps the test mode ones as well? Thanks

Post by vampirefrog »

It occurred to me that I can use a diode OR gate to mix /CS and /WR together and this way trigger less DMA requests.

Post by vampirefrog »

Here is another log, I think I got rid of the 0xffff waits. This time the format is:

0x61, 0xb5, 16 x (wait time, 16 bit, LSB first, address, data)

This format is meant to save some bandwidth, that's why it's not VGM commands this time.

Example:

Code: Select all

61b5
0000 0201
0000 007d
0100 0205
0000 0031
0f00 0114
0000 0202
0000 0021
0000 0203
0000 0003
0100 0205
0000 0030
0d00 0115
0000 0200
0000 0008
0100 0202
0000 0001
Attachments
song.cap.gz
(624.46 KiB) Downloaded 300 times

Post by vampirefrog »

Is the YM3413 emulated? Aparently the SY77 keyboard uses it, which I also own.

Also, the unused pins on IC21 tells me that it is used in other products as well.
  • ctr Offline
  • Posts: 492
  • Joined: 2013-07-17, 23:32:39

Post by ctr »

The led outputs on the gate array (IC21) are probably for the CBX-T3, which is a budget version of the TG100 without an LCD display.

The YM3413 ("LDSP") is not emulated. We need to reverse engineer it, somehow. I think it can probably only do a few fixed functions...

Post by vampirefrog »

Well, that DSP chip is in several cheap Yamaha products. Some info here http://www.dtech.lv/techarticles_yamaha_chips.html

I wonder what they mean 'programs are only 32 cycles long', perhaps the programs are stored in the CPU ROM and just sent over to the DSP chip?
  • ctr Offline
  • Posts: 492
  • Joined: 2013-07-17, 23:32:39

Post by ctr »

it seems like any commands to it go through the sound chip, so any hints on how the LDSP is programmed would be contained in your chip capture logs... There is also another test in the test mode dedicated to the LDSP chip and it seems like you can use MIDI sysex commands to mess with it as well.

Post by vampirefrog »

ctr wrote:it seems like any commands to it go through the sound chip, so any hints on how the LDSP is programmed would be contained in your chip capture logs... There is also another test in the test mode dedicated to the LDSP chip and it seems like you can use MIDI sysex commands to mess with it as well.
Ah I hadn't thought of that. I'll wait for ValleyBell to examine the latest log file to see if the VGM logger is accurate now.

Post by vampirefrog »

I'm leaving tomorrow for a week or so, here is the latest capture file.
Attachments
song.cap.gz
(1.33 MiB) Downloaded 287 times
  • User avatar
  • ValleyBell Offline
  • Posts: 4768
  • Joined: 2011-12-01, 20:20:07
  • Location: Germany

Post by ValleyBell »

here is a tool to convert the latest capture into VGM. It can even insert the (8-bit) sample ROM into the VGM.
The archive also contains the startup/testmode VGM. It's really just the VGM header and the raw capture data slapped together.

The new capture is bit a bit fast (but seems fine else) and there are about 3 major lags. (65535 sample delays)

EDIT: When I said "new", I meant the log from yesterday.
Also, the tool requires the "sync" word to start at an even offset. The log you just posted fails there.

Post by vampirefrog »

Thanks, my hands are all over your tool.

Post by vampirefrog »

Hello friends. I bring more contributions:

See attached demo.vgm for the complete but untrimmed demo song. I will post a better version later, this one is fairly close. It sounds pretty good even without the DSP, though you can tell the DSP is missing.

It is only playable with the libvgm vgmtest program. I have tried applying ValleyBell's patch to the MultiPCM core in vgmplay, but the instruments are messed up and it doesn't play correctly. Perhaps ValleyBell can do a quick backport?

In the log to vgm converter, I was able to detect the sync word at any offset, by simply reading byte by byte until I found what I was looking for. I also skip a few sync words at the beginning, seems to give better results. I was also able to get the timing correct by simply multiplying by two the waits. Perhaps I'm doing something wrong on the micro when counting samples.

I had trouble getting vgmplay to work with libao, due to uninstalling pulseaudio, and libao's config file /etc/libao.conf still trying to use pulse instead of alsa. If you ask me that's a bunch of caca dookie.

I haven't used git in a while, so just so I don't mess anything up, instead of committing here is a patch for vgmplay:

Code: Select all

diff --git a/VGMPlay/Stream.c b/VGMPlay/Stream.c
index a8cb05e..2319a1f 100644
--- a/VGMPlay/Stream.c
+++ b/VGMPlay/Stream.c
@@ -30,6 +30,7 @@
 #error "Sorry, but this doesn't work yet!"
 #endif
 #include <ao/ao.h>
+#include <errno.h>
 #endif
 
 #include "chips/mamedef.h"     // for UINT8 etc.
@@ -240,6 +241,17 @@ UINT8 SoundLogging(UINT8 Mode)
        return RetVal;
 }
 
+static const char *ao_strerror(int e) {
+       switch(e) {
+               case AO_ENODRIVER: return "No driver corresponds to driver_id.";
+               case AO_ENOTLIVE: return "This driver is not a live output device.";
+               case AO_EBADOPTION: return "A valid option key has an invalid value.";
+               case AO_EOPENDEVICE: return "Cannot open the device (for example, if /dev/dsp cannot be opened for writing).";
+               case AO_EFAIL: return "Any other cause of failure.";
+       }
+       return "Unknown";
+}
+
 UINT8 StartStream(UINT8 DeviceID)
 {
        UINT32 RetVal;
@@ -322,6 +334,7 @@ UINT8 StartStream(UINT8 DeviceID)
        if (dev_ao == NULL)
 #endif
        {
+               fprintf(stderr, "Error opening AO: %s (%d)\n", ao_strerror(errno), errno);
                CloseThread = true;
                return 0xC0;            // waveOutOpen failed
        }
It might need some more #ifdef'ing though.

And here is a patch for README.md:

Code: Select all

diff --git a/VGMPlay/README.md b/VGMPlay/README.md
index 8be3aa3..9923963 100644
--- a/VGMPlay/README.md
+++ b/VGMPlay/README.md
@@ -13,3 +13,10 @@ sudo apt-get install make gcc zlib1g-dev libao-dev
 make
 ```
 
+**troubleshooting**
+If you are using libao and you get an error similar to this one:
+```
+Error opening AO: Cannot open the device (for example, if /dev/dsp cannot be opened for writing). (5)
+Error openning Sound Device!
+```
+Try checking the contents of /etc/libao.conf or ~/.libao and select the correct driver. One example is if you uninstalled pulseaudio and the default_driver value remained pulse instead of alsa.
Here is my attempted MultiPCM patch, which fails because the instruments sound switched around:

Code: Select all

diff --git a/VGMPlay/chips/multipcm.c b/VGMPlay/chips/multipcm.c
index a108536..2c302ce 100644
--- a/VGMPlay/chips/multipcm.c
+++ b/VGMPlay/chips/multipcm.c
@@ -346,7 +346,7 @@ static void WriteSlot(MultiPCM *ptChip,struct _SLOT *slot,int reg,unsigned char
                        //according to YMF278 sample write causes some base params written to the regs (envelope+lfos)
                        //the game should never change the sample while playing.
                        {
-                               struct _Sample *Sample=ptChip->Samples+slot->Regs[1];
+                               struct _Sample *Sample=ptChip->Samples+(slot->Regs[1] | ((slot->Regs[2] & 1) << 8));
                                WriteSlot(ptChip,slot,6,Sample->LFOVIB);
                                WriteSlot(ptChip,slot,7,Sample->AM);
                        }
@@ -382,9 +382,9 @@ static void WriteSlot(MultiPCM *ptChip,struct _SLOT *slot,int reg,unsigned char
                                        if(slot->Base>=0x100000)
                                        {
                                                if(slot->Pan&8)
-                                                       slot->Base=(slot->Base&0xfffff)|(ptChip->BankL);
+                                                       slot->Base=(slot->Base&0x3fffff)|(ptChip->BankL);
                                                else
-                                                       slot->Base=(slot->Base&0xfffff)|(ptChip->BankR);
+                                                       slot->Base=(slot->Base&0x3fffff)|(ptChip->BankR);
                                        }
 
                                }
I guess now there a few things left to do:

- Add 12 bit sample support in the multipcm core.
- Log the DSP test program and get some clues on how the YMW258-F controls the DSP chip.
- Emulate the DSP chip.
- Trim the demo song and post as a pack or in homebrew. I think it would be the first hardware VGM log.
- I'll post the firmware to the github page as well, after a bit of cleanup.
- I still haven't figured out why I was getting the 65536 sample errors previously, it seems to behave well now. I'd like to figure out a more robust way to log hardware VGM. Perhaps by using a CPLD with its own timer inside, and making a reusable board with a bunch of I/O lines. I wonder if 16 is enough? EDIT: a 16 channel logic analyzer should suffice IMO.
- Perhaps filter out command spamming by keeping a register cache? Would that be possible?
- Dance.
Attachments
demo.vgz
(2.03 MiB) Downloaded 289 times

Post by Kaminari »

Rickrolled... again!

Post by vampirefrog »

Kaminari please stay on topic.

Anyway, here's a slightly more precise VGM log.
Attachments
demosong.vgz
(1.41 MiB) Downloaded 293 times

Post by Kaminari »

Is this forum becoming uptight or what? I was definitely on topic (I have listened to your song), but apparently one can't even post a light-hearted reaction without getting a dead serious warning.

I respect this dev discussion, thus I'll refrain from posting here anymore. Cheers.

vampi edit: removed racist comment about vampires
Post Reply