shock__ wrote:

Bad news: Sounds quite broken ... this is canyon.mid played back under windows https://drive.google.com/open?id=0B9WAZV_Pqo7 … cnMzNFBUZzg0MjA ... General MIDI via SBOS/MegaEM sounds similarly wrong.

That's sounds so bad it's almost comical, except that we have to figure out how to fix it. I can barely discern any normal-sounding instruments in all of that. Can you try a simpler MIDI file, like SWNGCAFE.MID, TOCCATA.MID or DILAST1B.MID? Gravis usually used to ship them with the boards, so you should have them handy somewhere (usually in a MIDS sub-directory). Those are the only files I have found that have all of the instruments in the bank, though the drums may still be off.

Okay, prepare for quite a ride 😀
dilast1b.mid https://drive.google.com/open?id=0B9WAZV_Pqo7 … UzhOMTYwWklNU1E
(couldn't find any other of the midi files you named quickly)

That was trippy =) L0ve the progress.

Seems to come down to details on how ROMMAKER exactly works now ... I mean, all the features are working with the substitute (without MegaEM, IWSBOS, Duke3D and Windows would bomb out), just not very well yet.
I consider this quite a milestone as well.

That's bad! I knew before I suggested it that the "bow glass" is not in the ROM, but was hoping the piano might at least be sane. There also seems to be (too much) of some sort of echo (or bad reverb) effect.

If you load the 16-bit, 2 MiB FFF version of the bank into RAM, is MIDI at least half sane? There were a few different tools involved in getting that ROM, and we might get a hint by trying that.

RAM based sets work perfectly fine - including the 2MB ProPatches Lite variant.

If the FFF bank I uploaded a few days ago produces decent MIDI quality, then it may have something to do with the ROMMaker's down-sampling feature. What do you think of producing a ROM file with just enough instruments to play a few MIDI files, without converting to 8-bit, and giving that a try when you have time?

Sure ... if that helps pinpointing the issue I'm absolutely up for that.

It took quite a bit of fiddling with the instrument list just to get a few instruments and (most of) the standard drum kit to fit. I added a few MIDI files, too. With the exception of some of the drums, all of the instruments needed should be available.

Alrighty ... gonna give it a spin in a few hours.

Sounds a lot less broken already ... I think AWave Studio can also manage .FFF banks and convert them to 8bit ... maybe that's worth a try if this checks out okay-ish otherwise.

Order of recording:
canyon.mid
dilast1b.mid
gdvib6.mid
striving.mid

https://drive.google.com/open?id=0B9WAZV_Pqo7 … c0N2RDdaeGdYRUE

EDIT: Actually give me a minute ... Dump didn't check out properly.
EDIT2: 4C000-4C7FF & CC000-CC7FF are blank when dumped ... I'll get that sorted out tomorrow what went wrong there.

Seems like we have an undetected issue at hand (which on the other hand is good as that means it can be potentially fixed).
Turns out the memory area mentioned below always fails when not using an original IW78C21M1 chip. I've verified the ROM I set in place more than once, even reworked Prototype #2 (the one I used with FlashROMs) completely and just confirmed the issue with Prototype #1 (the one I previously only used with an IW78C21M1) ... looks like there's some potential fixing to be done.

Time for some investigation ... and reconfirming my theory with Prototype #2

EDIT: reconfirmed with Prototype #2 ... crap.
EDIT2: Alright ... Reveal InterWave card checks out properly with a FlashROM, gotta recheck my schematic ... or it might be an issue with using ST vs. AMD 29F800 ROMs.
EDIT3: Issue found ... it's either my FlashROMs being to slow or ST doing something different from AMD
EDIT4: ROM reliably checks out good ... I'll upload new recordings soon. While SBOS sounds a bit more complete now, Windows MIDIs sound pretty much the same to my judgement.

shock__ wrote:

EDIT4: ROM reliably checks out good ... I'll upload new recordings soon. While SBOS sounds a bit more complete now, Windows MIDIs sound pretty much the same to my judgement.

What did you find? I was suspicious of a timing problem somewhere in the memory sub-system, just because of the unpredictability of the results. Sometimes it would sound quite decent for a few notes, then back to the same old tonedeaf-musicians-on-acid sort of sound. Looking at the timing diagrams in the InterWave datasheet, it doesn't seem likely to be a problem, but are you sure the address latches meet the timing requirements? Can you find another flash ROM with better timing characteristics in the same capacity and package, if the problem reveals itself again?

I do highly suspect a timing problem, after changing the ST 29F800-90 to an AMD 29F800-55 things work reliably. I guess anything below 80ns might go, as that's the recommendation for RAMs on the GUSPnP I was told.
Latches are 74F373 so they should be good (I think HCT works as well).

While I now have a MIDITEST_1MiB ROM ready, I need to get more useable flash chips, reworking them to be used with an additional programmer is a major pain and maybe works 2-3 times. That might take a while I'm afraid (only distributors on eBay at a fair price I could find were from China)

shock__ wrote:

I do highly suspect a timing problem, after changing the ST 29F800-90 to an AMD 29F800-55 things work reliably. I guess anything below 80ns might go, as that's the recommendation for RAMs on the GUSPnP I was told.

I read the 80 ns requirement for the RAM too. It was mentioned in the Gravis PDF manual, if I'm not mistaken.

shock__ wrote:

While I now have a MIDITEST_1MiB ROM ready, I need to get more useable flash chips, reworking them to be used with an additional programmer is a major pain and maybe works 2-3 times. That might take a while I'm afraid (only distributors on eBay at a fair price I could find were from China)

Do you have enough place on the board to fit a socket, so that you could re-use the flash ICs with an adapter? I thought they could be programmed at least a few hundred times; is the re-work causing physical damage?

What is your target price for the ROMs? Most current 1 MiB chips can be had for around $2 (or less), with the problems being that they are often 3.3V and in 48-TSOP or similar packages. Is there a reason to prefer the AMD part, other than the fact that it fits in the same footprint? The only DIP parts I could find that were 5V were comparatively expensive ($2.79 for a 4M x 8, and we'd need two just to get to 1 MiB).

SOP44 sockets are usually quite expensive (actually just checked, seems like $15 seems to be a common rate, case in point that would require changing the layout and i'm not too sure if I could fit it in) and yup, DIP variants seem barely available.
I mean I don't mind reworking the SOP44 chips anymore since yesterday, but once you desoldered them cleaning up the pins to re-use them with my programmer is a major pain (it's a ZIF socket which needs the pins almost perfectly clean of solder - basically looks like this http://www.icunlock-mcucrack.com/socketadapter/sop44-1b.jpg)

If one of you could find me a source for this kind of socket, that would be amazing: http://www.mikroklub.hu/htm/jpg/will29fs.jpg
(I'll be searching on my own as well)

Target price for the ROM would be "anything below $5 per chip".

EDIT: Alright ... found a proper socket for PSOP44 ... 10€ per piece, but I think that's worth it for the time being.
EDIT2: Just ordered 2 sockets, those should arrive soon-ish. Now off to find more FlashROMs with 70ns or less.

Current TestROM (Windows Midis start around 4:00, same order as before, last one sounds like it has no major hickups): https://drive.google.com/open?id=0B9WAZV_Pqo7 … eHRUSHZMSFRGbUk

shock__ wrote:

I mean I don't mind reworking the SOP44 chips anymore since yesterday, but once you desoldered them cleaning up the pins to re-use them with my programmer is a major pain (it's a ZIF socket which needs the pins almost perfectly clean of solder - basically looks like this http://www.icunlock-mcucrack.com/socketadapter/sop44-1b.jpg)

Sorry about the hassle of all that re-work, I guess I will have to try and curb the number of ROMs I produce for testing. It's just that I can't stand having something that doesn't work, without even having a hint about why that is. There are still a few other things I am trying to figure out, but I guess testing will have to wait.

shock__ wrote:

Target price for the ROM would be "anything below $5 per chip".

I am having a little trouble finding 5V DIP or SOP-44 (same thing as some others call 44-SOIC, yes?) parts, especially for a reasonable price, and they are often not stocked. Some other TSOP parts look like they might have the right pitch and package size, but are not 44-pin.

Was the latest recording from MIDITST0.ROM? While there is some improvement, it still sounds off. The other problem is that even with 8-bit patches, we can still only fit just over 40 out of 128 GM instruments and part of the standard drum kit in a 1 MiB ROM, if we're basing the ROM on the Pro Patches Lite set. Furthermore, unless the archive I downloaded has problems, some instruments are not part of the set (MARIMBA.PAT, a number of the synth pads, etc.), and a few don't seem to be valid .PAT files (CYMCRSH2.PAT, for instance). It seems they relied on the official Eye & I GUS classic set for the missing instruments, which hinders our ability to freely distribute a complete patch set. I would love to be corrected if a GUS user has all of these files as part of the distribution. Might we try getting the missing pieces from another free set, or try a different set? Suggestions from regular GUS users would be appreciated.

Also, there is the matter of the sines bank, for which the copyright chunk reads "SBOS waves Patch Information Copyright (c) 1995, Immersion Computer Technologies". Not including the sines bank would likely cause trouble with FM emulation, if SBOS works at all. Has this been given much thought? Shall we try excluding the bank on our next test ROM to see what happens?

IMO FM emulation on the GUS should be of very low priority.

Some ideas for the instruments in the ROM:
There is a version of Megaem that builds a 1 MB bank file (usually 1024.bnk) from the PAT files for a GUS classic. This should also work with PP light and the definition used is ultramid.ini.

elianda wrote:

IMO FM emulation on the GUS should be of very low priority.

Having used SBOS in the past, I feel we should pass a law against the attempt of using FM emulation on any GUS. It's like hearing the human torture organ from the Baron Munchausen movie, except it's sad instead of funny.