If you ask the community to not include your code in thire products (which you have), they won't, those that do anyway will be banned from mention and fade away. I'm afraid it's infinitely worse than that. If the concern is around cheap Chinese devices being made and sold commercially (and that's …

I'm not fond of idea of running Nuked SC-55 on Pi either. Mostly because it will open pandora box and might cause unscrupulous people starting selling Pi-based hardware with emulated SC-55 using my code, despite it being prohibited by non-comercial license. With respect, bad people are going to do …

how about making another thread and stop spamming here with totally unrelated Low-Performance Pi discussion. I for one have stopped to read and post here, because I am completely tired of those Pi-related posts, that from my point of view, has absolutely nothing to do with the project and its goals …

Right, that's what I mean...for doing the remaining four, if I do the capture and pull out the sysex (and fix the display stuff for each song), I should be able to reuse your sysex for all the MIDs, correct?

From what I've been able to tell, the instrument patch sysex is identical across all the demos, is that correct?

OK, that sounds like it explains the oddness I'm seeing on old-gen...but I'm afraid splitting the SysEx messages is likely beyond my capabilities.

The attached is 1:1 recording of the first demo song, direct from MUNT into straight MIDI, with the SysEx patch for Hi Tom 1 corrected (FF->00 and checksum fixed). It sounds awful. I don't understand why.

FIgured out the checksum error...it really is an invalid patch SysEx that is padded with FF instead of 00. Got that fixed...now some songs play more or less OK and some sound awful due to bad patches, but I can't work out why the patches are bad...they are EXACTLY as recorded. Ugh.

Further update - got a bit further, but my captures are still bad. Now I'm getting the patches in the SysEx stream, and they are played back on my MT-32...but I get "Exc. Checksum error" on playback just before the notes begin to play and they sound wrong (because the patch is failing to upload …

@sergm Gave this a try - it does seem you can record demos, sort of. Problems I'm having: - There's obviously some sort of patch being applied that isn't captured, which is very necessary for proper playback - If you allow a demo song to play through to the end, you aren't prompted to save the …

I also thought it wouldn't! Will look into this, thanks very much!

Has anyone ever looked into this? It would be very nice to be able to play the 5 "new" (read: ROM 2.x) demo songs (Adjarre, Boiler Buster, Short Demo, Sinfonia 1, and Good Morning) on older units (or even MUNT). Extracting the data for them (in the second 64K bank) is very easy...working out the …

It looks like the root cause of the issue is that the original Infocom booters deliberately malign the first 8 sectors into 4 1024-byte sectors, and use the bootloader to reprogram the FDC to deal with this at load time. I doubt ZorkTools will ever work properly outside of actual hardware. Thanks to …

DOSBox wants a recognizable filesystem on IMGMOUNTed floppy images when they're mounted. Perhaps if you boot real DOS it won't complain about no filesystem until you try to read the disk with some command. I think you're on to something! Using this method (with FreeDOS), I get: Using partition 0 on …

I think I'm starting to better understand the nature of the problem. The Infocom booters do not have a filesystem _at all_...it isn't FAT or anything else, it's entirely custom. I've mounted a raw 160KB Infocom disk image under ImDisk, which Windows of course immediately wants to format (and I …

Both "offical" DOSBox and various patched versions exhibit similar behavior. I have a number of floppy images (type IMA, extension IMG, not compressed) - some 160KB 5,25" SSSD, others 360KB 3.5" SSDD (specifically, Infocom "booter" images). Interestingly, if I try to boot them with DOSBox, they boot …