Project ARGUS (Gravis UltraSound Re-issue) is looking for a coder
category: general [glöplog]
Hey there folks,
my project on re-issueing the Gravis UltraSound PnP is closing in onto getting an actual working prototype (I got my hands onto 190 InterWave chips and designed a custom PCB using the "InterWave OEM design" as a base to build upon). While I'm fairly happy with the result that's to be expected there's one loose end I'd really like to tie up before the final run, which might possibly be realized in hardware already but needs a custom program to actually work (if any hardware changes are required I'd love to implement them).
The deal is the following: On the original GUS PnP you had a ROM chip camouflaged as "IW78C21M1" which turned out to be just a 1MB ROM holding the wavetable data. As of now it has already been replaced with a 1MB FlashROM and has been confirmed to work on various InterWave cards, which is why it has been implemented into the current ARGUS design. Being a FlashROM, the current process would still look like this ... get an external programmer, get a TSOP44 adapter, burn the ROM image, solder the chip on the ARGUS board - while sufficient kinda sucks doesn't it? What I'd love to do would be being able to solder the chip onto the ARGUS board and flash it directly from there. This would of course need a custom application/program to do that (typically under DOS). All the relevant lines of the FlashROM are already wired up to the InterWave chip and an extensive "InterWave Programming Guide" (400 Page .pdf) is available, which I can send you. Sadly I suck at coding and don't enjoy it at all. The intended FlashROM chip is an 29F800 which is also supported by Uniflash for DOS, which has it's source-code publically available, so it would be "just" the InterWave part you'd have to worry about (and potentially porting the Python [or Pascal?] code of uniflash to your language of choice).
Would anyone of you be up for the task of creating such a flash program for the wavetable ROM? In return you'd get your name on the PCB and be one of the first folks to enjoy the new card, as you'd recieve one of the 3 prototypes to evaluate/test/debug your program. Once the final run starts you'd of course get a final board fully assembled for free in return for your efforts. I've made good experiences on here before so I thought this is certainly worth a shot (I briefly mentioned the project in another thread and got alien^pdx to design the awesome logo on the back of the card).
Blog post with my contact information is available here:
http://guspnp.livejournal.com/6463.html (if anyone feels like hopping in on the second point you're more than welcome as well).
my project on re-issueing the Gravis UltraSound PnP is closing in onto getting an actual working prototype (I got my hands onto 190 InterWave chips and designed a custom PCB using the "InterWave OEM design" as a base to build upon). While I'm fairly happy with the result that's to be expected there's one loose end I'd really like to tie up before the final run, which might possibly be realized in hardware already but needs a custom program to actually work (if any hardware changes are required I'd love to implement them).
The deal is the following: On the original GUS PnP you had a ROM chip camouflaged as "IW78C21M1" which turned out to be just a 1MB ROM holding the wavetable data. As of now it has already been replaced with a 1MB FlashROM and has been confirmed to work on various InterWave cards, which is why it has been implemented into the current ARGUS design. Being a FlashROM, the current process would still look like this ... get an external programmer, get a TSOP44 adapter, burn the ROM image, solder the chip on the ARGUS board - while sufficient kinda sucks doesn't it? What I'd love to do would be being able to solder the chip onto the ARGUS board and flash it directly from there. This would of course need a custom application/program to do that (typically under DOS). All the relevant lines of the FlashROM are already wired up to the InterWave chip and an extensive "InterWave Programming Guide" (400 Page .pdf) is available, which I can send you. Sadly I suck at coding and don't enjoy it at all. The intended FlashROM chip is an 29F800 which is also supported by Uniflash for DOS, which has it's source-code publically available, so it would be "just" the InterWave part you'd have to worry about (and potentially porting the Python [or Pascal?] code of uniflash to your language of choice).
Would anyone of you be up for the task of creating such a flash program for the wavetable ROM? In return you'd get your name on the PCB and be one of the first folks to enjoy the new card, as you'd recieve one of the 3 prototypes to evaluate/test/debug your program. Once the final run starts you'd of course get a final board fully assembled for free in return for your efforts. I've made good experiences on here before so I thought this is certainly worth a shot (I briefly mentioned the project in another thread and got alien^pdx to design the awesome logo on the back of the card).
Blog post with my contact information is available here:
http://guspnp.livejournal.com/6463.html (if anyone feels like hopping in on the second point you're more than welcome as well).
can't help you much there, but cool project, hope you find your coder.
Hi,
Sounds like something I can do, but I'd have to check the programming manual to make sure it's possible :) (is the interwave chip actually able to write to the ROM space?)
Sounds like something I can do, but I'd have to check the programming manual to make sure it's possible :) (is the interwave chip actually able to write to the ROM space?)
Sounds like something that's either relatively simple or impossible, especially if there's something that "almost works" available with source code..
just looked at interwave programming guide and IWSBOS sources...yes, reading from ROM is really piece of cake but i'm not sure does Interwave chip able to write to ROM.
SDK + Programming guide (+ often incorrect datasheet) available here: http://dk.toastednet.org/GUS/SOURCE%20CODE/IWSDK20.ZIP
Relevant stepping stones would be RA20 & RA21 pins which are wired to the FlashROMs !RESET and !WE required for programming. Sadly those pins are described as "The high ROM Address lines during ROM accesses. At the trailing edge of RESET, these signals become inputs that are used to determine the operation mode of certain multiplexed function pins." with no further explaination in neither the datasheet, nor the programming guide. Maybe digging through the SDK would reveal something. Dumping the ROM to a file "in-circuit" seems to be no problem.
Relevant stepping stones would be RA20 & RA21 pins which are wired to the FlashROMs !RESET and !WE required for programming. Sadly those pins are described as "The high ROM Address lines during ROM accesses. At the trailing edge of RESET, these signals become inputs that are used to determine the operation mode of certain multiplexed function pins." with no further explaination in neither the datasheet, nor the programming guide. Maybe digging through the SDK would reveal something. Dumping the ROM to a file "in-circuit" seems to be no problem.
Dumper works:
(above was read out by unsoldering the chip popping it in an EPROM programmer - lower file was read out "in circuit" using a dumping program under DOS)
(above was read out by unsoldering the chip popping it in an EPROM programmer - lower file was read out "in circuit" using a dumping program under DOS)
If the InterWave chip is not able to write the (Flash)ROM (which might make sense, because it was originally meant to be a ROM) you're probably best off to break out some pins to vias and construct a programmer using some pogo-pins to program the flash chip with a regular programmer...
If in doubt, place some 0 Ohm resistor bridges you'll hand solder afterwards or some jumpers you can open to program the FlashROM.
If in doubt, place some 0 Ohm resistor bridges you'll hand solder afterwards or some jumpers you can open to program the FlashROM.
From the programming manual, the external memory interface can drive both the ROM and the DRAM. Unfortunately apparently there is no static RAM mode, which would be what is needed here. Unless they accidentally left the write pin work as expected in ROM mode, but that would be surprising. Only way to know is testing how that pins behave, I guess.
I've pretty much come to a similar conclusion and decided not to implement FlashROM burning directly on board (would involve adding various ICs) since it's a one time thing cuasing quite a bit of effort. Instead I'll add an additional through hole footprint for the ROM, so people can use ordinary EPROM programers without having the need for a special adapter that might be expensive (250€ for the GALEP high quality programmer).
On the other side: In the SDK is a program called ROMMAKER (IWSDK20.ZIP\960214.SRC\TOOLS\ROMMAKER) apparently used to create ROM images from .FFF banks. If anyone wants to throw a compiler at it (it's either Borland C 3.1 or 4.0 or Watcom 9.5/OpenWatcom) and figure out how exactly it works - that's something I'd love to see running. Someone from VOGONS managed to compile it already by commenting out a few lines.
On the other side: In the SDK is a program called ROMMAKER (IWSDK20.ZIP\960214.SRC\TOOLS\ROMMAKER) apparently used to create ROM images from .FFF banks. If anyone wants to throw a compiler at it (it's either Borland C 3.1 or 4.0 or Watcom 9.5/OpenWatcom) and figure out how exactly it works - that's something I'd love to see running. Someone from VOGONS managed to compile it already by commenting out a few lines.
I'm not a coder but I'll probably buy your stuff;]
Any reason why you wouldn't socket the rom chips? (apart from the cost)
sol_hsa: Currently because I didn't see a reason for that yet ... with the challenge of obtaining a valid license to re-distribute those files, the Wavetable ROM will very likely get a DIP socket again so people don't need special adapters for their programmers. As for the PNPROM, that's just 8 pins and socketing the chip might interfere with the RAM-sticks (that one chip can also be reprogrammed by the InterWave).
Got ROMMAKER.EXE compiled ... binary and makefile output here: http://www.vogons.org/viewtopic.php?f=46&t=42431&start=874 Would be great if a coder could have a look over it, that nothing catastrophic happened there (got 0 errors, but a few warnings). Binary seems to be working and produces something resembling the intended output ... testing of course isn't possible for now.
Got ROMMAKER.EXE compiled ... binary and makefile output here: http://www.vogons.org/viewtopic.php?f=46&t=42431&start=874 Would be great if a coder could have a look over it, that nothing catastrophic happened there (got 0 errors, but a few warnings). Binary seems to be working and produces something resembling the intended output ... testing of course isn't possible for now.
Hm... is there any chance of a PCI version?
Most music players ignore the DMA channel at all, thus it would likely provide better hardware-level compatibility than Soundblaster-like cards.
Most music players ignore the DMA channel at all, thus it would likely provide better hardware-level compatibility than Soundblaster-like cards.
If your system has PCI slots, you're probably better off using DOSBox ;)
Meaning: nopes, too far into the project to implement massive changes, also since the project virtually has no coder I see no way to test a possible PCI variant, as adapting the drivers massively extends my knowledge of C/C++/ASM
Meaning: nopes, too far into the project to implement massive changes, also since the project virtually has no coder I see no way to test a possible PCI variant, as adapting the drivers massively extends my knowledge of C/C++/ASM
Quote:
If your system has PCI slots, you're probably better off usingDOSBox :)GUSEmu32
fixed ;)