VOGONS


Reply 1260 of 3172, by 640K!enough

User metadata
Rank Oldbie
Rank
Oldbie
Atomizer_Zero wrote:

That drum echoing sounds like a sustain effect has been applied but the drum sound can't be sustained so it causes it to echo. I noticed a slight lack of sustain in the first song too.

To get back to this, most of the percussion is defined as one-shot (no sustain, no response to key-off), and most of the instrument definitions share a volume envelope. This is true of the official 4 MiB FFF/DAT bank included on the CD. So unless these problems are also present when playing back the MIDI files with that bank (and presumably the 1 MiB ROM bank on every card known to have shipped), that shouldn't be the source of the problem.

In most cases, the percussion instruments are not part of an exclusion group, so that shouldn't be causing playback of the samples to be prematurely cut off, either. I guess I'll have to keep looking.

Reply 1261 of 3172, by 640K!enough

User metadata
Rank Oldbie
Rank
Oldbie

Another member here, who shall remain nameless for the moment, generously acquired a board and sent it along for nothing more than the cost of shipping. This should make ongoing testing much easier. For the moment, I have removed the ROM altogether, and have been experimenting exclusively with RAM banks, in the hope of answering some questions. I have some early results to report.

The most significant of those results is that the problems we have been experiencing with MIDI playback seem to have absolutely nothing to do with the ROMMaker software. Simply generating an FFF/DAT bank via GIPC, loading that and playing MIDI files produces the same output; that is to say, the stuttering drums and clicking. So, at least now I know where to direct my attention when trying to solve the problems; no amount of time spent staring at the ROMMaker source code would have led to a solution.

The problem isn't caused by GIPC alone, either. I was able to generate an FFF/DAT bank from the original 16-bit UltraSound patch set, and playback is about as good as it can get with those patches; no stuttering/echo or clicking.

Armed with that information, I decided to try another experiment: I manually hex-edited the FFF file for the 2MiB PPLT bank we have been using, indiscriminately disabling looping for almost all of the percussion. The result was no more echo or stuttering (though the clicking did remain), but playback that was still somewhat wrong.

This seems to indicate that it would be worth the time to go back to the original PPLT PAT files to carefully look at the loop points and flags, to make sure the problems aren't coming from there, and that the conversion process isn't introducing the problems.

EDIT: I forgot to mention that the echo and clicking are present during playback in native InterWave mode (as opposed to GUS compatibility mode) in pure DOS as well as under Windows. Playing one of the Doom files or GDVIB6.MID using PLAY.EXE will demonstrate this.

Last edited by 640K!enough on 2017-10-18, 16:47. Edited 1 time in total.

Reply 1264 of 3172, by 640K!enough

User metadata
Rank Oldbie
Rank
Oldbie

I had some time for a little more experimentation, and I am now confident enough to make a few conclusions:

  1. The ROMMaker, as it stands, is functional enough to do the job, and alignment of the wave data seems to be correct.
  2. GIPC, while somewhat buggy and sloppy, doesn't seem to be introducing any significant problems during the conversion from collections of PAT files to FFF/DAT banks.
  3. The problems we have had with MIDI playback are inherited from the PPLT PAT files themselves. It is unclear if the files I have are identical to those that were originally released, but every copy of the snare file (among others) that I have found has the same problem. That means that each of the files used in the percussion banks will have to be reviewed, and its loop points potentially adjusted.

To prove item 3 to myself, I edited the loop points on the snare, not putting any effort into precise alignment, generated a new bank and played the usual files from Doom II. The result was that it went from the usual stutter/echo to a dull buzz at the end of the drum sample. So, with a little more care put into editing the loop points, I suspect we will have that problem solved.

In the percussion banks alone, there are about 40 files that have samples with looping enabled. I am not planning on fixing all of them just yet. I will leave those with slightly sloppy loop points for later, and work on the worst offenders for now. I will try to post a few recordings when that's done.

Reply 1265 of 3172, by cyclone3d

User metadata
Rank l33t++
Rank
l33t++

What version of GIPC are you using?

Version 1.0 size is: 44,452 bytes
Version 1.11 size is: 49,548 bytes

(edited file size because I am apparently dyslexic)

Last edited by cyclone3d on 2017-10-21, 16:32. Edited 1 time in total.

Yamaha modified setupds and drivers
Yamaha XG repository
YMF7x4 Guide
Aopen AW744L II SB-LINK

Reply 1266 of 3172, by 640K!enough

User metadata
Rank Oldbie
Rank
Oldbie
cyclone3d wrote:

What version of GIPC are you using?

Version 1.0 size is: 44,452 bytes
Version 1.11 size is: 49,458 bytes

I have been using version 1.11 exclusively. Can you re-check the file sizes? Mine is 49548 bytes; if yours doesn't match, maybe I have a bad copy (seems unlikely, though, as I downloaded from two separate sites, and the files are identical).

Reply 1267 of 3172, by cyclone3d

User metadata
Rank l33t++
Rank
l33t++
640K!enough wrote:
cyclone3d wrote:

What version of GIPC are you using?

Version 1.0 size is: 44,452 bytes
Version 1.11 size is: 49,458 bytes

I have been using version 1.11 exclusively. Can you re-check the file sizes? Mine is 49548 bytes; if yours doesn't match, maybe I have a bad copy (seems unlikely, though, as I downloaded from two separate sites, and the files are identical).

You are correct on the file size. I switch numbers like that quite often. 😊

Yamaha modified setupds and drivers
Yamaha XG repository
YMF7x4 Guide
Aopen AW744L II SB-LINK

Reply 1268 of 3172, by shock__

User metadata
Rank Oldbie
Rank
Oldbie

I've started to adjust the layout to clean up a few tidbits I noticed on the first prototype.

Prototype_01 -> Prototype_02
! Moved UA0 and UA1 apart, which should allow easier soldering and optional installation of sockets
! Moved CA1 & CA2 to allow optional sockets for UA0 & UA1
! Renamed JP4-7 -> JP0-3 to better reflect their coresponding banks
! Replaced JP0-3's pinheaders to solderjumpers to allow an optional socket for U31
! Moved C32 to allow an optional socket for U31
! Replaced R12 with a solderjumper footprint for better uniformity
! Replaced R13 with a solderjumper footprint for better uniformity
! Split one pad on R13 to two to fix an oversight on the first prototype regarding ROM-type selection
! Changed 'Sample ROM options' section to reflect above changes
! Renamed JP3 -> JP4
! Lots of minor adjustments to ground plane and via stitching
! Made sure vias are hidden under soldermask
+ Added 640K!enough (as 640Kenough) to the contributor section
+ Added a field of exposed copper on the top layer for 'scratching' in serial numbers which is more tamper-proof
- Removed silkscreen field for serial numbers, since sharpies wash out over time and are quite tamper-friendly
- shortened section on X1 & X2

Case in point: I'd really like to start production soon-ish, since I'm almost a year overdue. What are the general feelings on that, since flash support might become a reality at one point in the future, but isn't at a point yet where I'd happily add it (circuit probably too complex to fit, adding redundancy on cards, cost factor probably being higher when installed on multiple cards). I'd like to hear some opinions on that - whether we should wait longer or are ready to go (feel free to reply here publically or via PM). As a compromise I could also produce a desired number of the current design and you could still use your remaining "credit" (meaning you can order any amount now and the rest later - but no more than 3 cards overall) for a future layout which might include additional features (keep in mind that might push prices a bit depending on the demand [boards should still be under 25€ in any case]). The later would also serve as a public betatest, in case there are any oversights.
Feel free to discuss this or tell me your opinion til the 31st of october, which is when I'll make a decision (do the full run or do a limited run and another one later for the people who contributed so far) based on your input.

I'll post a picture of the current layout in a few days at worst, since there are still a few minor loose ends I'd like to double check

Current Project: new GUS PnP compatible soundcard

[Z?]

Reply 1269 of 3172, by the Goat

User metadata
Rank Member
Rank
Member
shock__ wrote:

Case in point: I'd really like to start production soon-ish, since I'm almost a year overdue. What are the general feelings on that . . .

I admit I have not read through the entire thread, can people still get in on this order? If yes, how? Are you planing a regular production run later, or is this a one-and-done situation?

Reply 1271 of 3172, by keropi

User metadata
Rank l33t++
Rank
l33t++
shock__ wrote:

Case in point: I'd really like to start production soon-ish, since I'm almost a year overdue. What are the general feelings on that . . .

Fine by me, real life comes first and then nerdy stuff. Your card is really complex and this timeframe for a hobbyist is really good in my book. I'd day take your time and when it's done it's done. 😊

🎵 🎧 PCMIDI MPU , OrpheusII , Action Rewind , Megacard and 🎶GoldLib soundcard website

Reply 1272 of 3172, by 640K!enough

User metadata
Rank Oldbie
Rank
Oldbie

I finally got to recording a few samples. The first is really just enough to show the revised drum looping. I obviously don't have it quite right yet, but I think it is less irritating than it was before.

Filename
Breakout.mp3
File size
363.5 KiB
Downloads
53 downloads
File license
Fair use/fair dealing exception

The second shows off some of the other PPLT instruments.

Filename
Jump_Bk.mp3
File size
656.4 KiB
Downloads
54 downloads
File license
Fair use/fair dealing exception

And lastly, the usual Doom II standard, slightly better than before.

Filename
DoomII-Map01.mp3
File size
4.43 MiB
Downloads
67 downloads
File license
Fair use/fair dealing exception

Other than the snare still needing work, please let me know if you hear anything that doesn't sound right. I did have to compensate for recording volume by using the "Normalize" function, so they are not completely unedited, but it should be close enough. Any constructive feedback is welcome.

Reply 1273 of 3172, by shock__

User metadata
Rank Oldbie
Rank
Oldbie

Proposed new layout:
eyNuCR6.jpg

Sadly it turned out that I lost the library containing the ARGUS silkscreen logo (which I would have liked to upscale a little), therefore it seems a little small now.
Any suggestions what to do with the empty space between the ARGUS silkscreen logo and the ROM infobox (can only be on the top layer)?

Current Project: new GUS PnP compatible soundcard

[Z?]

Reply 1274 of 3172, by shock__

User metadata
Rank Oldbie
Rank
Oldbie

As a last attempt I'm trying to add back the 42pin socket for the ROM. That would conviently expose all relevant pins on the ROM which would allow an in-circuit flash programmer daughterboard to be made.
Getting there might take a few days tho.

Current Project: new GUS PnP compatible soundcard

[Z?]

Reply 1275 of 3172, by Batyra

User metadata
Rank Member
Rank
Member

For me logo size is OK - it's elegant somehow. Larger may me more "obvious"... I like how it is now.
As a collector personally I would like to buy one with current design and another one later to have both of tchem, compare etc 😀

Visit my website: http://www.collection.batyra.pl

Reply 1276 of 3172, by 640K!enough

User metadata
Rank Oldbie
Rank
Oldbie

If I'm not mistaken, is the RAS# line not connected to pins 33 and 45 on the SIMM socket? Given that the InterWave has only one RAS# signal, isn't that asking for trouble if someone happens to insert a dual-rank SIMM (apparently most common in 2, 8, 32 and 128 MiB SIMMs)? It seems like it would be safer to ignore the second rank and lose some capacity, rather than risk having multiple banks try to drive the data bus simultaneously.

Reply 1277 of 3172, by 640K!enough

User metadata
Rank Oldbie
Rank
Oldbie
shock__ wrote:

As a last attempt I'm trying to add back the 42pin socket for the ROM. That would conviently expose all relevant pins on the ROM which would allow an in-circuit flash programmer daughterboard to be made.
Getting there might take a few days tho.

Unless you are planning a revised design later, I think we can consider in-circuit flashing a lost cause. I mentioned previously that the simplest design I had in mind depended on particular behaviour from the InterWave. When I actually looked at the timing diagrams more carefully, it became clear that the InterWave does exactly the opposite of what was needed. In-circuit flashing could still be implemented, but not with just those signals; it would likely need a few other modifications in the vicinity of the latches, ROM and SIMM socket. I doubt you would even want to open that can of worms.

Instead of re-introducing the old 42-pin DIP socket, is there any chance you'd consider elongating the pads of the SOP footprint slightly, so that the standard flash chip could be replaced with a 1.27 mm pitch surface-mount pin header? That way, those building their cards would be able to use a ROM daughterboard with more modern chips, level-translation and higher capacities as an option, with less re-routing on your part. If the SIMM socket happens to be close enough, you could even have a header for the 4 BKSEL# signals, which would even allow capacities above 4 MiB.

The software adapted beautifully to the complete removal of the ROM, so I doubt having more ROM available would be a problem. I plan to test this next week or so, and will have a definite answer (with screenshots and recordings) soon enough.

Reply 1278 of 3172, by shock__

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

I doubt you would even want to open that can of worms.

Exactly that 😀
Elongating the pads sounds like a great option in my book, I didn't think of yet! That would certainly require less of an effort than the 42 pin socket (which would require a major re-routing for the SOJ-RAMs), while certainly cherishing the DIY-aspect of the project. You're speaking of SMD 1.27mm headers, right? If so I should probably have that ready by tomorrow (along with a few other minor fixes).
EDIT: You mean like this right? https://www.ismolex.com/wp-content/uploads/20 … -single-row.png
EDIT2: Actually the female headers seem a lot nicer to work with: https://www.ismolex.com/wp-content/uploads/20 … D-Connector.pdf

About !RAS that signal is indeed connected to all 4 !RAS* signals on the SIMM. Which seems to work without any catastrophic consequences (to card and SIMM sticks) and reliable operation, even when used with incorrect types (that was one of the things Elianda and I tested a while back). Might still be worth checking into as I noticed the SOJ-RAMs often get quite hot (which might be normal ... or not).

Current Project: new GUS PnP compatible soundcard

[Z?]

Reply 1279 of 3172, by shock__

User metadata
Rank Oldbie
Rank
Oldbie

Aaand done:
D2wJ3Lp.jpg

Prototype_01 -> Prototype_02
! Renamed UA0 -> U0 & UA1 -> U1
! Moved U0 and U1 apart, which should allow easier soldering and optional installation of sockets
! Moved CA1 & CA2 to allow optional sockets for UA0 & UA1
! Renamed JP4-7 -> JP0-3 to better reflect their coresponding banks
! Renamed R12 -> JP4 & R13 -> JP5
! Renamed JP3 -> JP6
! Replaced JP0-3's pinheaders to solderjumpers to allow an optional socket for U31
! Moved C32 to allow an optional socket for U31
! Replaced JP4 with a solderjumper footprint for better uniformity
! Replaced JP5 with a solderjumper footprint for better uniformity
! Split one pad on JP5 to two to fix an oversight on the first prototype regarding ROM-type selection
! Realigned lower edge of the PCB near Midi/Joystick port, so chamfering won't result in ugly flashing there
! Elongated pads for U31 to optionally allow female 1.27 SMD headers to be placed instead of the chip
+ Added small markings to silkscreen for U31 to allow easy orientation of SMD headers
! Moved nametags for ICs outside of their footprint, so they don't get obscured when the footprint gets populated
! Slight changes to the ARGUS PCB Art logo to allow the soldermask to stick better
! Pulled back the right-hand edge of the board outline near DSUB15 connector, so backplanes sit flush
+ Added 640K!enough (as 640Kenough) to the contributor section
+ Added a field of exposed copper on the top layer for 'scratching' in serial numbers which is more tamper-proof
- Removed silkscreen field for serial numbers, since sharpies wash out over time and are quite tamper-friendly
! Changed various 'Option'-infoboxes section to reflect above changes
! Moved 'Info'-boxes closer to their relevant jumpers/headers
! Moved ARGUS silkscreen logo
! Rearranged 'thanks'-section a bit
! Lots of minor adjustments to ground plane and via stitching
! Made sure vias are hidden under soldermask

Whoever can name the origin of the codename correctly first gets a free desoldered InterWave that was used in development (ideal for keychains or huge profits on eBay) 😜

Current Project: new GUS PnP compatible soundcard

[Z?]