VOGONS


Reply 1180 of 3179, by shock__

User metadata
Rank Oldbie
Rank
Oldbie

sines.fff/sines.dat is easily available on the Internet (while you are of course correct on the copyright aspect) ... I'd be perfectly fine with "just" distributing ROMMAKER.EXE and leave the generation/programming steps to the folks building their cards.
No problem with the reworks I've done 😀 That was partially my fault and in the future the ROM will be socketed once the sockets arrive, therefore further testing should be a lot easier/quicker.

Kinda agree with Elianda and Kodai.

Current Project: new GUS PnP compatible soundcard

[Z?]

Reply 1181 of 3179, by Kodai

User metadata
Rank Member
Rank
Member

If you want to really hear how bad it can be, play Tyrian (aka Tyrian 2000) in AdLib or SoundBlaster mode with any GUS. If your ears don't start bleeding, then you must already be deaf, 🤣.

Reply 1182 of 3179, by shock__

User metadata
Rank Oldbie
Rank
Oldbie

Wolf3D on the GUS was already enough for me to be perfectly honest.

Current Project: new GUS PnP compatible soundcard

[Z?]

Reply 1183 of 3179, by 640K!enough

User metadata
Rank Oldbie
Rank
Oldbie

Although it may not be useful to anyone else, I have spent my free time the last few days working on an FFF parser to see if it can offer a few hints about what is going on. The results turned out to be quite interesting, even though the software isn't complete yet. I should have a new test ROM that incorporates some of the findings ready over the next few days.

Does incorporating the sockets require modifications to the layout, or can they be fitted to the existing boards? Another related question: are the original ROM and flash directly interchangeable, or did you have to modify the pin-out to suit the flash chips?

Reply 1184 of 3179, by shock__

User metadata
Rank Oldbie
Rank
Oldbie

Great news 640K!enough ... you're really earning your name on the frontside of the PCB here 😀
Pretty excited for what you come up with.

Prototype 1 has now evoled to a real prototype 😀
http://i.imgur.com/X4qsj3S.jpg

Regarding adding the socket, I had to slightly modify the lower carrier because otherwise a decoupling capacitor would be in the way and the jumpers for the SIMM/SOJ RAM selection had to be removed (the plastic standoffs collided with the upper part of the socket). I'll try to incorporate support for sockets in the final version (for the ROM, as well as the SOJ DRAM), that has actually been on my to-do list for a while.

Regarding different pinouts of the IW78C21M1 and 29F800 ... it basically comes down to the highest pin of the ROM that has to be wired up differently depending on the chip used (!RESET on the 29F800 which is constantly held low on GUSPnP boards, which works for the IW87C21M1 but holds 29F800 chips in a permanent reset state). I actually messed that up in the prototype which is what the wire on the backside in above picture is for (which replaces the botch wire in previous photos). That wire will of course not be present in the final run and will be replaced by a jumper for configuring how the board is populated.

Current Project: new GUS PnP compatible soundcard

[Z?]

Reply 1185 of 3179, by 640K!enough

User metadata
Rank Oldbie
Rank
Oldbie
shock__ wrote:

Great news 640K!enough ... you're really earning your name on the frontside of the PCB here 😀
Pretty excited for what you come up with.

The first thing I looked at was the patch parameters in the official FFF files. I didn't really take a detailed look at the 4 MiB set beyond that, but it was interesting to look at the effects settings. I will gradually take a few hints from those settings for future ROM files. For the time being, I have resorted to hex-editing the parameters before generating the ROMs, which can get tedious as the number of instruments grows. I think the sound quality is gradually improving, with a few mysteries that remain to be solved. I think further work on the parser will help us get there.

shock__ wrote:

Prototype 1 has now evoled to a real prototype 😀
http://i.imgur.com/X4qsj3S.jpg

Regarding adding the socket, I had to slightly modify the lower carrier because otherwise a decoupling capacitor would be in the way and the jumpers for the SIMM/SOJ RAM selection had to be removed (the plastic standoffs collided with the upper part of the socket). I'll try to incorporate support for sockets in the final version (for the ROM, as well as the SOJ DRAM), that has actually been on my to-do list for a while.

I have to admit that it looks good with the socket in place. Now it really looks like a prototype meant for experimentation.

For the final board, wouldn't the sockets be an unnecessary expense? If they can solder the socket, isn't the chip about the same, in terms of difficulty? Once it's out of the prototype stage, are we really expecting to be swapping chips so often that the cost of sockets is justified? If it's still under consideration, and we can get in-circuit flashing working, that could easily cut at least $15 worth of sockets from the BOM. I have a theory that might get it working with minor hardware changes and some software trickery. Sadly, any attempt at writing that sort of software will have to wait until I can find a board that I wouldn't mind modifying at a sane price; the $400+ they want on eBay is out of the question!

shock__ wrote:

Regarding different pinouts of the IW78C21M1 and 29F800 ... it basically comes down to the highest pin of the ROM that has to be wired up differently depending on the chip used (!RESET on the 29F800 which is constantly held low on GUSPnP boards, which works for the IW87C21M1 but holds 29F800 chips in a permanent reset state). I actually messed that up in the prototype which is what the wire on the backside in above picture is for (which replaces the botch wire in previous photos). That wire will of course not be present in the final run and will be replaced by a jumper for configuring how the board is populated.

Do all of the other pins fall in exactly the same place? WE#, BYTE#, etc. are all sure to be correct? Are there any other free pins that we could borrow for other purposes?

Reply 1186 of 3179, by shock__

User metadata
Rank Oldbie
Rank
Oldbie
640K!enough wrote:

For the final board, wouldn't the sockets be an unnecessary expense? If they can solder the socket, isn't the chip about the same, in terms of difficulty? Once it's out of the prototype stage, are we really expecting to be swapping chips so often that the cost of sockets is justified? If it's still under consideration, and we can get in-circuit flashing working, that could easily cut at least $15 worth of sockets from the BOM. I have a theory that might get it working with minor hardware changes and some software trickery. Sadly, any attempt at writing that sort of software will have to wait until I can find a board that I wouldn't mind modifying at a sane price; the $400+ they want on eBay is out of the question!

Personally I'd encourage everyone to actually solder the chips in place, unless they want to experiment with their cards - but it won't harm to have support for sockets, which will of course be optional. I'll write you a PM regarding developing in circuit programming within the next few days.

640K!enough wrote:

Do all of the other pins fall in exactly the same place? WE#, BYTE#, etc. are all sure to be correct? Are there any other free pins that we could borrow for other purposes?

To my knowledge that is correct. Problem is that the IW78C21M1 datasheet is not public, therefore it's more of a certain guess that turned out to work than verified information. Pin1 is unused and Pin43 (!WE) can possibly be "freed" - but I'd have to investigate the later first.

Current Project: new GUS PnP compatible soundcard

[Z?]

Reply 1187 of 3179, by matze79

User metadata
Rank l33t
Rank
l33t
 I'll write you a PM regarding developing in circuit programming within the next few days.

That would be really cool ! 😁

https://www.retrokits.de - blog, retro projects, hdd clicker, diy soundcards etc
https://www.retroianer.de - german retro computer board

Reply 1188 of 3179, by shiozaki

User metadata
Rank Newbie
Rank
Newbie

So when will I be able to put in an order for one of these?

Reply 1189 of 3179, by Kodai

User metadata
Rank Member
Rank
Member

Shiozaki, please read the thread. At least read the las few pages.

Reply 1190 of 3179, by shiozaki

User metadata
Rank Newbie
Rank
Newbie
Kodai wrote:

Shiozaki, please read the thread. At least read the las few pages.

lots of bug fixes on the prototype, and some short of deadline i missed?

Reply 1191 of 3179, by Synoptic

User metadata
Rank Member
Rank
Member

Shio : You missed the opportunity to order one.

Reply 1192 of 3179, by shiozaki

User metadata
Rank Newbie
Rank
Newbie
Synoptic wrote:

Shio : You missed the opportunity to order one.

well thats a shame.

Reply 1193 of 3179, by 640K!enough

User metadata
Rank Oldbie
Rank
Oldbie

It took some debugging and a good bit of staring at both a hex editor and the output from the FFF parser, but I think I've finally found the source of the problem I was having with the ROMMAKER. I should have time within the next few hours to produce another new test ROM. If I can avoid including copyrighted patches, I will post the file publicly. I should have another update shortly.

Reply 1195 of 3179, by 640K!enough

User metadata
Rank Oldbie
Rank
Oldbie

I have generated what should be a workable ROM that will at least give us better sound than we were getting before. There are likely a few adjustments that still need to be made, but we won't know that until we hear the results. There is a ROM file, with no patches that weren't intended to be freely available, to my knowledge, and a few MIDI files. The file looks a little more sane, but our ears will tell us.

It may be helpful if someone with an unmodified Gravis card could post a recording of their card playing the MIDI files using only the default ROM set, as well as the output from an older GF1-based card, so that we can compare what we are getting.

EDIT: Removed the attachment, and will upload a revised version shortly.

Last edited by 640K!enough on 2017-06-26, 04:06. Edited 1 time in total.

Reply 1196 of 3179, by Snayperskaya

User metadata
Rank Member
Rank
Member

I've been off from the forums for a bit of time just to be surprised by the amount of stuff you guys done in the meantime. Great to see this is still kicking and almost ready for prime time! 😀

Reply 1197 of 3179, by shock__

User metadata
Rank Oldbie
Rank
Oldbie

FlashROMs from China have arrived ... 70ns apparently work fine as well.

Recording the MIDI testfiles with the current ROM build ... seems to work nicely so far (I'm halfway into the first song right now). I'll update this post with a recording soon-ish.
EDIT: Recording here - https://drive.google.com/open?id=0B9WAZV_Pqo7 … YzFpbXo2RUxsNms ... last 9 minutes or so are recordings from Duke3D/Doom2/ROTT with IWSBOS. MegaEM doesn't seem to work at all anymore.

Current Project: new GUS PnP compatible soundcard

[Z?]

Reply 1198 of 3179, by 640K!enough

User metadata
Rank Oldbie
Rank
Oldbie

Well, it's certainly better than it was, but it sounds like there is still some work to be done. Is it just my cheap earbuds, or did anyone else hear a bit of noise/distortion in a few places? How about the bass in STRIVING.MID, for example? For easy reference, start times for each of the files are listed below:

00:00	Clair de lune
03:45 The Last Days of Summer (DILAST1B.MID)
06:49 GDVIB6.MID (some instruments missing)
08:18 MELLOW55.MID
09:23 Space Quest V - Closing Theme
10:27 STRIVING.MID
14:47 IWSBOS testing

From the sound of it, IWSBOS is still using the RAM bank, which doesn't really allow us to evaluate sound quality yet. Since most of the instruments needed for those games are missing from the current ROM, we are likely better off leaving that testing for later.

If MegaEM ever worked with our ROMs, I don't see why it would stop now. Did it give any useful error messages? Is it known to depend on particular instruments?

Reply 1199 of 3179, by 640K!enough

User metadata
Rank Oldbie
Rank
Oldbie

I've generated a revised version of the same ROM, since I've finally found which patch file was corrupt. I found a new copy and fixed the instrument maps a little. To save a little upload time, we could probably hear what we need with just MELLOW55.MID and STRIVING.MID.

If we can get these to produce distortion-free sound, I can try figuring out which instruments Doom 2 needs, and we can move on to some more serious ROM-based IWSBOS testing.