hard1k wrote:

And guys. The possibility for a 4Mb ROM will make the whole project 500% more interesting. Please keep up the good work!

Frankly, I have never heard MIDI playback from a device with a 1 MiB instrument bank that I liked. The only one that was anywhere close was the Soundscape S2000 and DB. From what I've heard so far, the standard AMD/Eye & I ROM isn't terrible, but it's still quite a compromise. I find the percussion to be particularly lacking. They had to cut corners to get that many instruments to fit in 1 MiB.

Starting from the PPLT set, there is just about no way that I can think of to fit a complete sound bank in 1 MiB, much less with any semblance of quality. That is why place for the headers was so important.

In the current 44-pin SOP package, we can only source 1 MiB parts, with some possibility of a 2 MiB part if Digi-Key or Mouser get the 29F160 in stock. Even then, they are relatively expensive. I think it makes more sense to use a modern part, and add level translation and other hardware to a ROM daughterboard. That way, we can have any size ROM that is supported by the InterWave, and a quality sound set to match.

EDIT: Corrected spelling errors.

shock__ wrote:

Pulldowns for the SOJ-RAMs have not been implemented yet, I'll actually test those on one of the prototypes within the next few days first.

If we're referring to the same thing, don't you want to pull CAS# to VCC to ensure the SOJ DRAMs aren't becoming inadvertently activated when the SIMM is selected? Do you need to do the same for the SIMM, in case it is inserted, but the SOJ selected?

EDIT: Two more pertinent questions: what do you mean by "open" prototype, still limited to your list of prior donors, I presume? How soon do you plan to go ahead?

640K!enough wrote:

shock__ wrote:

Pulldowns for the SOJ-RAMs have not been implemented yet, I'll actually test those on one of the prototypes within the next few days first.

If we're referring to the same thing, don't you want to pull CAS# to VCC to ensure the SOJ DRAMs aren't becoming inadvertently activated when the SIMM is selected? Do you need to do the same for the SIMM, in case it is inserted, but the SOJ selected?

Yup ^^ Already a bit late here (4am), therefore not exactly thinking along right now 😉

I've also made templates for various provisions of supported header footprints for the ROM daughterboard, so if anyone wants to get going ... feel free:
https://i.imgur.com/fJaVrpt.jpg (recommended layouts would be the ones either with IC1 or IC2)

Is there any chance of a small pin header near the SOJ chips to expose BKSEL0#-BKSEL3#, WE#, RAS# and CAS#? I expect you can figure out what I might want to tinker with (still). If not, I can always borrow the signals from existing footprints, but it would be a little unsightly if that design were to end up on a production daughterboard.

Should be possible.
!CAS does not exist directly ... !BKSEL* gets 'translated' to that via the RAM select jumpers or would you need the explicit signals going to the SOJ/SIMM?

shock__ wrote:

Should be possible.
!CAS does not exist directly ... !BKSEL* gets 'translated' to that via the RAM select jumpers or would you need the explicit signals going to the SOJ/SIMM?

I forgot about that. There is no need for an explicit CAS#, then. I should be able to work with the other six.

Alright 😀
I should have that included within the next few days.

'Open Prototype' would mean that anyone who previously donated or got involved in the project (which includes you 640K!enough) can order one such board for the sake of testing or experiment with implementing additional features. Layout/features might potentially change in the future (read: Design is not final - afterall it's a test). Number of cards you can order in the full production run gets reduced by one then (unless one found a bug or implemented a feature - in that case you can still order 3 cards in the run [sounds unfair? Not really - I wouldn't want people to order prototypes just to get an early peek or have another, additional version of the card for their collection/ebay profits]).

I don't know about that, I think that if someone wants to get a board to test and actually perform tests (no matter if he reports a bug , even saying it works fine is a good test IMHO) then he should not be limited to 2 cards of the final version - unless the final version stays the same. You can limit prototypes to serious people that can report serious stuff though - I think that's better.

I don't plan on being too strict on that. Maybe that didn't come out properly.
Lemme rephrase: Anyone can get one additional prototype, under the promise of giving competent feedback/bug reports/implementations of new features.
I reserve the right to 'deny' low effort feedback which would then result in the prototype being accounted as one of the 3 cards for the actual production run.
Feedback might include summaries on the soldering/assembly/acquisition of parts, writing guides, finding bugs in the hardware or software that is compatible with the GUS PnP but makes trouble with the ARGUS alternatively you can implement/'hack' new features in hardware or anything that helps making the card better - be creative. People already mentioned in the "contributor"-section are excluded and can get their addtional prototype cards without these conditions. As of now those people are: 640K!enough, alien^pdx, bristlehog, CHiLL72, Enigma, FGB, hard1k, hyperborean, keropi, Marmes, wbc

I've seen projects tho where "beta-testers" didn't even get around to pluging in a ready built board into their machines (and then sold it off on eBay at 400% of the price before the regular run) or had to be asked 3x times for feedback which then literally was "works for me, cool". That's something I'd definitely not want to happen.

ah yes that's much better - it's really fair and makes sense 😀

Added header exposing various signals that might be required for a larger ROM: https://i.imgur.com/JCbtS9d.jpg

EDIT: Just added pullups (!BKSEL is active low) on one of the prototypes, works nicely, no more overheating SOJ-RAMs. Adding those to the schematic and layout now.
On the other hand I just noticed "memory gap" configurations (i.e. Bank0 - 256k, Bank1 - 256k, Bank2 - 4MB, Bank3 - 4MB) seem to majorly confuse IWINIT, causing the card not to be found or more or less random amounts of RAM getting detected (those configs are also mentioned as instable in one revision of the GUS PnP manual if I'm not mistaken ... and XTC player detects them as "unusual").
EDIT2: Adding pullups to the SIMM makes things run a lot more stable.
XTC-PLAY: https://i.imgur.com/2mRitOZ.jpg
No pullups, no problem! https://i.imgur.com/JbQuaGW.jpg
EDIT3: Pullups for the SOJ-RAMs are giving me a bit of a headache in the layout ... therefore no new preview tonight. I'll probably get around to them on Tuesday.
EDIT4: Next proposal for the prototype: https://i.imgur.com/DMJOTFR.jpg

Wow, it's nice to see the project activity again, good luck and keep it going! 😀

As far as I know from prevoius posts, Interwave IC does not support in-curuit ROM flashing, so it will require additional circuit and obviously will bump prices up, so I think external ROM header is more suitable.
Apart from it, as I proposed earlier, support for 1024K x 16 SOJ DRAMs (providing max. 4 MB RAM on board) would be a nice choice for those who doesn't want to fiddle with SIMMs; it requires only extending SOJ40 socket to SOJ42, (leaving pins 1-20 and 23-42 for SOJ40), two 3-pin jumpers and a bit of rewiring (example on photo, a bit messy though); at least I've modded my AWE64 CT4520 and it works fine with 2MB RAM.

about mono in/out - I assume MONO_IN can be muted in mixer, so it can be safely placed as external header and used as PC speaker input or been muted in order to supress noise from motherboard.

Anyway, I think prototype #2 is already features almost all stuff needed, so let it release now 😀

There are 2 problems with adding 1024K*16 DRAMs to the board:

I'm currently right on the edge of the 200mm width (199.52mm) for the board and the corresponding areas are already quite packed, along with the rest of the board allowing little to no optimization to free up the missing 1.27mm (one additional grid) + 0.325 (half the smd landing area) - sounds funny, but that ~1mm missing . If I drop the support for sockets for the SOJ-RAM and Wavetable-ROM I might be able to free up enough space, but personally I'd prefer to keep those.

Second reason which is more severe in my eyes: the adress lines on the right side of the SOJ-RAM (22-26 in case of 256K*16, 23-28 in case of 1024K*16) are offset by one pin as well. Meaning those would have to be re-routed as well. Connecting A0 and A9 to the outmost pins on the 1024K*16 (A3 and A4) won't work (random scrambling of data lines usually works, but not for adress lines - unless I'm totally mistaken). I don't think adding 7-10 3-position (solder)-jumpers is an option. Checking the layout for the CT4520 I have absolutely no idea what they're doing there.

EDIT: As it turns out, adress line swapping might be possible in DRAM as well, therefore I'll give adding 1024K*16 DRAMs a spin. Only drawback would be that those DRAMs have to be soldered in place, while the smaller 256K*16 ones can be optionally socketed.

EDIT2: Just found some 72 pin SIMM modules which carry 1024K*16 DRAMs ... gotta hack up the prototype again tomorrow to confirm that it's possible to swap the adress lines.

1024K*16 DRAMs work.
https://i.imgur.com/fa5HrvG.jpg

shock__ wrote:

EDIT4: Next proposal for the prototype: https://i.imgur.com/DMJOTFR.jpg

Does Eagle have a feature that would allow you to produce a full-scale image or PDF of the ROM area, so that we can get a better idea of the placemment of X3, relative to other components? I'll wait a little while before working on the ROM hardware; I'd rather do it once, when connector placement is relatively certain, rather than have the unpleasant surprise of having built something that doesn't fit.

New layout: https://i.imgur.com/jgLnqE7.jpg

Some of the infoboxes suck.
'JP6 & JP7 "SOJ footprints"' probably doesn't make much sense to non-tech folks. Recommendations that aren't longer in text welcome.
Also the description on X3 is confusing as to why !RAS and !MWE are included, recommendations welcome here as well.

640K!enough wrote:

shock__ wrote:

EDIT4: Next proposal for the prototype: https://i.imgur.com/DMJOTFR.jpg

Does Eagle have a feature that would allow you to produce a full-scale image or PDF of the ROM area, so that we can get a better idea of the placemment of X3, relative to other components? I'll wait a little while before working on the ROM hardware; I'd rather do it once, when connector placement is relatively certain, rather than have the unpleasant surprise of having built something that doesn't fit.

EDIT: Eugh ... just realized the uploaded version of the daughterboard in an earlier post doesn't include X3 ... lemme attach the correct one.
This should allow you to take measurements of how the parts are spaced. I intend not to change their correlations, unless I absolutely have to.

Measurements as .jpg (all units are mm): https://i.imgur.com/s5pMzpf.jpg

I think I'm done with the layout.

Anyone who would be interested in taking part of the open prototype run, feel free to give me a ring via PM. Price for a board + presoldered InterWave will be anywhere between 90€ (small run, full features like hardgold and chamfering/beveling for the connector, blue silkscreen) or 20€ (larger run, reduced features). Your PM will not be a final order, but an indication of your interest. I plan to have the boards produced before the end of the month.
General conditions of the prototype run here: ARGUS Project thread - Now with gerbers and documentation in initial post!
Bill of materials and placement map will follow within the next few days.

I've just re-read the whole thread (what a great reading actually!) and I've got several questions before the PCB is sent to production:
Any ideas on the crystals? (ARGUS Project thread - Now with gerbers and documentation in initial post!) Just leave them as they are?
Final decision on the MONO_IN?.. No way?
What's the reason for keeping the JP4 and the right part of the JP5 if they are always in the same position?

shock__ wrote:

Let me re-iterate, yellow silkscreen (not offered by the plant) and an additional MIDI interface (just get keropi's card) won't happen.

Our discussion about the MIDITXD and MIDIRXD: ARGUS Project thread - Now with gerbers and documentation in initial post!
In neither way did I mean any additional wavetable headers / MPU-401 / whatsoever. What I'm referring to is just an option to painlessly route the MIDITXD and MIDIRXD from any future ARGUS-style daughterboard that might get released later (we already have the ISA bus, we have the Line-In port, the only thing we lack are the MIDI I/O routing pins).
Maybe it is still possible to add vias or replace both SMD R84 & R85 with similar through-hole parts? I know you answered that before... But... Please?

And the PM with the interest confirmation is on the way (for the higher-end 90 euros version if possible) 😀

Crystals are running stable as they are and actually are closer to their corresponding pins than on the GUS PnP, so no worries there.
MONO_IN & MONO_OUT only if someone presents me a working implementation (great use for one's prototype)
JP4 is left in because I still don't fully understand why it works, same goes for the leftmost pad on JP5

MIDITXD and MIDIRXD via headers, while the joystick stuff can be left as is? Sure, why not.
EDIT: From the InterWave or DSUB?