Tursi

I didn't determine whether Gazoo changed the original code or not, but the Gazoo version runs on the UberGROM, which means it's the standard write-to-ROM banking scheme. I couldn't find enough information on the popcart to run the original ROMs, which would have been pretty cool.

Not anytime soon. They use different CPUs and even if you load Windows, the CPU will still be an issue. Am considering options for future cross platform but making zero promises, because I do this for fun and I'm not going to bang my head against a dozen open source libraries if I don't have to. If you want to be serious about programming you should learn to love the command line. I don't know if anyone has wrapped a GUI around it but the XDT toolchain is the most mature and updated toolset for the TI right now. I'm not involved in this project and can't give you any deeper information, except I used it for Dragon's Lair. There's always MAME. Supposed to be really good.

You don't need to clear it with me, the history of that file is so filled with history I think the only part that's debatable is XB3 itself. I literally changed only 1 byte.

hmm.. that makes sense, yeah. The step over function doesn't use a traditional breakpoint, it's special case code. It seems to break in all the "just right" cases. I'll add it to the list.

Now that I've said that, tonight I pushed up voice2psg, which will take in a voice sample in Wave format and output a PSG file that attempts to reproduce it. It's really limited, and doesn't tend to be very clear, but for some samples, it does work, and hey, it's 60hz sample playback. It's based on Artrag's Matlab concept, but several attempts at porting the code to C++ just had me walk away - every function I looked at linked to two more massive ones, and keeping the arrays straight was driving me crazy. I did get about halfway through it all if anyone wants that code, but likely I'm going to discard that work in favor of tuning this newer tool. I don't have a good example ready, but you want a very clear voice sample, with no background sounds, loud and crisp. With all that, the result should be barely recognizable in the output. TI1.wav Ultimately, this tool won't often be useful, but for screams and hoots it actually does pretty decently, so you can get some sounds in there if you need them.

Those keyboard wedge scanners work quite well, too, I had to write some software to support them back in the day

Sure, let me know if you have any questions. If it's useful to anyone, that's the point. I was thinking it might be more efficient with a change of the data structure from an array of structs to independent arrays, just from looking at the generated code, but that pass will have to come later.

No. This is a 60hz playback system, so samples aren't going to work regardless of the source.

Loading files from disk is the same in Classic99 as on the real machine. There are examples in the manual for various types of files. Loading the DSK image itself - Select Disk, then the disk device you want to load (ie: DSK1), then the first line of the popup there will take you to a dialog, section 6.5 in the manual covers it. Without more specifics it's hard to give a more detailed answer.

Without the envelope generator, the SID has only a single master volume (for all channels). So you have to include the envelope in any volume calculation. It doesn't have per-channel control like the SN does, just per-channel envelope. The converter runs a full SID emulation (indeed, there's also a 6510 running CPU code!) then samples the emulation state (tone comes from the period registers, but volume comes from the emulation's output) every frame. VGMComp2's convert tools convert all music to split channels with 12-bit tone and 8-bit volume for the sake of later tools - having more resolution to work with reduces the loss when you manipulate, and means we don't cut out features that other chips might be able to use. When you use the "prepare" tool, then the limitations of the target chip (which may be SID, AY-3-8910 or SN76489) are taken into account. So the test play does necessarily sound a little better than the final product, but the goal is to show you got a clean conversion. In the case of these SID tunes, the noise channels (if more than one) are combined and the volumes mapped from 8-bit linear to 4-bit logarithmic (and if there is any extremely low notes, those need to be trimmed, clipped, or scaled). There's some loss, but the Galaxy2 demo shows that it still sounds decent, it really abuses the slow volume ramps. You can also run the prepare4sn tool and then use testplayer to see what it sounds like after limitations are enforced on the SN. I decided to walk the rest of the way through the process. The noise channels merged nicely and even use custom frequencies where needed for the varying sounds. The only issue was the first channel having bass notes that were too low... after trying a few things I eventually went with a single octave higher, allowing a little bit of clipping, and play out the result. It almost makes me happy - I wanted to change the volume of the re-tuned channel, and I haven't written that tool yet. But you can hear that the sequences you called out still work fine with the reduced volume resolution. https://open.lbry.com/@tursilion:1/2020-07-30-15-07-40:1?r=J8w7SGxXLD3UUrHVxe5d5g1o5rwKT1Wh (Skip ahead to 22:05 to bypass most of my rambling and experimenting )

You can't permanently replace GROM0 without recompiling Classic99 (or hex-editting it), so you would have to create cartridge images in Classic99.ini for every combination of GROM0 + cartridge you wanted to run. I suppose that's something for the future - configurable base system - but it's a ways out. XB3, if it doesn't work by just drag and drop onto the window, you would need to know the memory layout and create a Classic99.ini entry for it. I'm assuming it doesn't have any new hardware - I haven't seen it myself so I can't provide you that magic.

Pushed up the SID converter today - this converts SID files (the ones based on emulating a C64!) into PSG. I used a package called csid and to my surprise the results are quite good - they had some talented musicians over there. Even losing the waveforms most of the music I converted still sounded really good. (Not all. But most!) Anyway, that's in the usual place, and once it's done uploading a demo video is here: https://open.lbry.com/@tursilion:1/2020-07-29-04-25-13:6

Biggest thrill for me back in the day was the RAMdisk, that opened up so much for me. Biggest waste of pennies was Super Marios Bros, the XB almost-game that "pushed the TI to its limits". I guess it inspired me to do better, anyway.

I did an optimization to the Coleco libraries and they are roughly 20% faster... I'd like to get more but the C code is probably pretty good now. I also finished and pushed up the "QuickPlayer" tool for this generation, it'll take your compressed file and spit out either an EA#5 (TIFILES) program for the TI or a 32k cartridge ROM for the ColecoVision. It can handle all the combinations that I've presented demos for with a simple Windows GUI (a command line version is also available). It's in the dist folder with the rest of the EXEs. A couple of challenging tools left then most of the rest should go pretty quick.

Maybe hand-optimizing is out, but I can /read/ Z80 code, and spent a few hours (more than I should have) tonight on optimizing the C code to get better output. The results are about 20% better, and I've pushed that up. There's still performance to be found, but this should be optimal enough to start using it.

I always disliked the semicolon, I used forward slash. But since that doesn't work on the PC file system, when I started Classic99 I switched to underscore.

Not much for this side, but tonight I pushed the first version of all the ColecoVision versions of the players. This took a bit of tweaking to get everything building clean on both sides. Performance of the C code is surprisingly close to what the 9900 GCC version side - code size too. Despite the clock differences the performance of the Z80 in the ColecoVision is remarkably close to the TI... that said, a hand-optimization pass of the Z80 code sure wouldn't hurt.

Hey! Resurrecting this old post to note that the work I've been doing on version 2 of this tool is finally running on ColecoVision (well, hopefully, my hardware is packed so I can't test there at the moment!) The goals of v2 were better CPU usage, less RAM usage, and better packing. CPU didn't go down much, unfortunately, but it did save a bit of RAM and pack a bit better on pretty much all songs. But there was a second goal - and that was a more complete toolchain for conversion. I've got a whole thread over in the TI side and I'm going to continue to use that for updates, but as of tonight I've got the ColecoVision SN player, the AY player for SGM and Phoenix, and the Sound Effects player working. New posts start here: https://atariage.com/forums/topic/225463-vgm-compression-tool/?do=findComment&comment=4493240 Unfortunately, I don't know Z80 well enough to do a deep hand-optimization of these like I did for the TI... but I may have to take a stab at it eventually anyway. I think if I do a first pass there should arise people to tell me how wrongly I did it. I have some samples you can drop in a folder and play with: - playerSN is a sample playing on the stock ColecoVision SN sound chip. It plays a conversion of the Journey to Silius title from NES (some of it anyway ) - playerAY is a sample playing on the SGM or Phoenix AY sound chip. It plays a conversion of the Master System Afterburner (yes, an SN chiptune. Ironic ) - playerSNAY plays a sample from Wonderboy in Monster Land arcade - originally a dual SN arrangement. It plays here on the AY and SN chips. - playerSNSFX is just a port of the old demo app from my first version of this tool to show sound effects working And if you just want something to watch, Piano is a quick port of the same demo I released on the TI last week, a conversion of the Protracker MOD GalaxyII using the new MOD conversion toolchain. I love it when a port just works. The code is all Windows, cause that's what I use, but it's all command line and should compile with minimal pain on Linux, although I didn't go out of my way to create makefiles (most tools are single source file and only the players use any Windows specific code). Source repo is up but it's not done yet - you can just grab the raw tools or docs in the "dist" subfolder. https://github.com/tursilion/vgmcomp2 Anyway, just wanted to let you know that the Coleco side is functional at last... though it could use some optimization! playerSN.zip playerAY.zip playerSNAY.zip playerSNSFX.zip Piano.zip

Note that "S"ave to disk is only for making a backup -- the UGROM itself is updated as soon as you see the result on the screen.

To re-test the toolchain, I reconverted Galaxy2.mod and saved off the steps. The result is attached. It's slightly better than the previous because I did the smoothing before merging channels - so when noises and tones were interleaved they preserve what they were doing instead of blending with the alternating note. Not too noticeable, but it was bugging me so I'm glad to have done it. The steps were as follows. Again, determining what I wanted to do was at least some verification with testplayer between steps. D:\work\TI\vgmcomp2\galaxy>..\release\mod2psg -d GALAXYII.MOD D:\work\TI\vgmcomp2\galaxy>..\release\smoothvolume.exe GALAXYII.MOD_ton00.60hz D:\work\TI\vgmcomp2\galaxy>..\release\smoothvolume.exe GALAXYII.MOD_ton01.60hz D:\work\TI\vgmcomp2\galaxy>..\release\smoothvolume.exe GALAXYII.MOD_ton02.60hz D:\work\TI\vgmcomp2\galaxy>..\release\smoothvolume.exe GALAXYII.MOD_ton03.60hz D:\work\TI\vgmcomp2\galaxy>..\release\smoothvolume.exe GALAXYII.MOD_noi04.60hz D:\work\TI\vgmcomp2\galaxy>..\release\smoothvolume.exe GALAXYII.MOD_noi05.60hz D:\work\TI\vgmcomp2\galaxy>..\release\smoothvolume.exe GALAXYII.MOD_noi06.60hz D:\work\TI\vgmcomp2\galaxy>..\release\smoothvolume.exe GALAXYII.MOD_noi07.60hz D:\work\TI\vgmcomp2\galaxy>..\release\arptones.exe GALAXYII.MOD_ton00.60hz GALAXYII.MOD_ton03.60hz D:\work\TI\vgmcomp2\galaxy>..\release\mergenoise.exe GALAXYII.MOD_noi04.60hz GALAXYII.MOD_noi05.60hz D:\work\TI\vgmcomp2\galaxy>..\release\mergenoise.exe GALAXYII.MOD_noi04.60hz GALAXYII.MOD_noi06.60hz D:\work\TI\vgmcomp2\galaxy>..\release\mergenoise.exe GALAXYII.MOD_noi04.60hz GALAXYII.MOD_noi07.60hz D:\work\TI\vgmcomp2\galaxy>del *.old D:\work\TI\vgmcomp2\galaxy>..\release\prepare4SN.exe GALAXYII.MOD_ton00.60hz GALAXYII.MOD_ton01.60hz GALAXYII.MOD_ton02.60hz GALAXYII.MOD_noi04.60hz galaxy2.snpsg D:\work\TI\vgmcomp2\galaxy>rem (manually patched a couple of lines in the snpsg) D:\work\TI\vgmcomp2\galaxy>..\release\vgmcomp2.exe -sn -v galaxy2.snpsg galaxy2.snsbf There were actually 4 noise channels output rather than 2. I had to move the intermediate merge.old files between them, though I did that in Explorer. There were a few rows right in the first tone that were dropping to zero, making a little static, so I manually patched those (about 6 lines - this is why the intermediate formats are in text!) Resulting program is here. Again, improvement is minor, but the arpeggio at the beginning and some of the thunderclaps are more crisp. I'll stop spamming now for a bit. piano.zip

.. just looking at that sequence there, I think I'll do away with the filename confusion and just have the tools rename the original files automatically. That was a pain to keep straight the first time around doing it every time looks tedious and error-prone.

Right now you need programming to get them over to the TI (though I'll get a quickplayer like the old tool had before it's done). But you can test the converter on the PC side. The tools are all over at https://github.com/tursilion/vgmcomp2 - you can download as a zip file. Binaries for Windows are in the "dist" folder. You would start with "mod2psg", and I recommend the "-d" flag to see what it autodetects the samples as, cause there's probably only a 50% chance it'll guess right. (so: mod2psg -d mymod.mod). That'll output a separate file for every final track with tones and noise separated. A 4 channel Protracker can output up to 8 files for that reason. You can test it immediately with "testplayer" and the filename prefix (in this case: testplayer mymod.mod). Then you can go back to mod2psg and adjust anything it got really wrong (use mod2psg.exe with no inputs to see the options). To just play around and see what they might sound like, this is as far as you need to go. To get it ready for the TI you need to get down to three tone channels and 1 noise channel. "arptones" will combine two tone channels into one by alternating the tones, and "mergenoise" will combine two noise channels into one by keeping the loudest one. For other needs I'm just starting on those tools, "smoothvolume" is the newest one which cleans up some of the noise on the volume channels. The trickiest part of this phase is keeping the filenames straightforward. After that, "prepare4sn" will do the final conversion, and you pass it your four channels. And then "vgmcomp2" compresses the output of that. It's a lot of little steps, but the intent is that the old process, while very simple, had very little flexibility. Every time I wanted to add the ability to tweak the result, I needed to insert it into the middle of a big bloated program. This lets you chain together the steps that are appropriate to a particular song - this should make better results possible. In theory once you decide what you need you can batch file them. GalaxyII would have been something like this (not exactly what I actually did, because I did it over several days): rem (I can't remember if I had to manually set any noise channels, and I didn't write it down!) mod2psg -d galaxyII.mod rem this generated 6 channels - 4 tone and 2 noise smoothvolume galaxyII.mod_ton00.60hz galaxyII.modA_ton00.60hz smoothvolume galaxyII.mod_ton01.60hz galaxyII.modA_ton01.60hz smoothvolume galaxyII.mod_ton02.60hz galaxyII.modA_ton02.60hz smoothvolume galaxyII.mod_ton03.60hz galaxyII.modA_ton03.60hz smoothvolume galaxyII.mod_noi04.60hz galaxyII.modA_noi04.60hz smoothvolume galaxyII.mod_noi05.60hz galaxyII.modA_noi05.60hz rem merge channel 3 into 0 (determined by playing and watching) rename galaxyII.modA_ton00.60hz galaxyII.modA_ton00.old rename galaxyII.modA_ton03.60hz galaxyII.modA_ton03.old arpnotes galaxyII.modA_ton00.old galaxyII.modA_ton03.old galaxyII.modA_ton00.60hz rem merge channel 5 into channel 4 (all noises) rename galaxyII.modA_noi04.60hz galaxyII.modA_noi04.old rename galaxyII.modA_noi05.60hz galaxyII.modA_noi05.old mergenoise galaxyII.modA_noi04.old galaxyII.modA_noi05.old galaxyII.modA_noi04.60hz rem prepare and pack prepare4sn galaxyII.mod_ton00.60hz galaxyII.mod_ton01.60hz galaxyII.mod_ton02.60hz galaxyII.mod_noi04.60hz galaxy2.snpsg vgmcomp2 -v galaxy2.snpsg galaxy2.snsbf So, a lot of steps, but hopefully they follow logically. Some of it could be automated but most of the time you want the human influence at each one to determine what is required. I feel like I rambled offtrack a bit... for testing your old songs you can start by just playing with mod2psg and testplayer.

Added the volume smoothing tool - overuse definitely causes notes to blend together, so I guess it's working, but a single pass improved GalaxyII quite a bit, and saved 4k on the resulting file to boot! I plugged it into the old keyboard viz to make another demo, or you can watch the video here: https://open.lbry.com/@tursilion:1/2020-07-21-02-06-47:e?r=J8w7SGxXLD3UUrHVxe5d5g1o5rwKT1Wh piano.zip

Yeah, I first heard it on an Atari XL conversion. This version is converted from a Protracker MOD which was in turn inspired by that Atari 8-bit version.