dr_st wrote:

appiah4 wrote:

dr_st wrote:

1MB ROM in both versions I believe; 512KB RAM in Value, 4MB RAM in Gold.

The soundfont dump of the rom is 512KB by the way, so I am certain that it is only 512KB.

This is interesting, because every place I could find references the CT1972 to be a 1MB ROM. Perhaps it is used for more than just the soundfont?

That is possible.. Someone who knows better than me will probably chime in soon and tell me I'm wrong anyway 😎

That ROM is definitely 1MB, on both AWE32 and 64s. If you saw mirroring you had bad pin contact or wrong pinout during dumping...

yeah the ROM never changed from the the first AWE32 to the last AWE64. same rom.

1mb;
all AWE32, AWE64, CT1920 had 1mb.

2mb;
Only the 1910 (WaveBlasterII) had a 2mb one,

4mb;
the original 8801 + 8805 and CT1900 WaveBlaster 1, had the original 4mb one. (same one as in emu soundengine because it has some of the proteus sample in it besides GM)

question about the 2nd mpu. is this a real mpu like sb16? so in pure dos we just inisialize the card with ctcu and mpu will play without aweutil? that will be great since in pure dos midi games give problems with vanila awe64. example try run blood in dos if you select awe as music card the game and sound will play, if you use general midi the pc will lock up and will need hard reset. only if you are inside windows 98 general midi as sound will play

It is much better. It is a true hardware driverless MPU that is also intelligent mode capable. So it can drive your MT-32 directly in those old Sierra quests, no need for genuine Roland MPU-401, no clones, no drivers, no SoftMPU.

But please bear in mind that it will not drive the card's own EMU8000 synth. So if you want the EMU8K in the GM mode (MPU-401 emulation), you're limited to the Creative ill-designed AWEUTIL solution unfortunately. But any external MIDI device will work like a charm - LA, GM, GS, XG, etc; internal daughterboards, external modules, whatever.

thats undreastandable if i want awesynth (some games sound better with it some others like blood not at all beter compared to old good general midi) i will use aweutil. if i want general midi or like the sound of it beter that awesynth, then the mpu chip on this new awe card will be a beter solution. also this along with real opl chip makes the card act as full sb16 when needed. the vanila awe64 dont have opl3 and as i said before general midi as sound can lead to problems.i cant see this card cheaper that 150 euros at best but will worth it.

truemaster wrote on 2020-01-02, 20:15:

thats undreastandable if i want awesynth (some games sound better with it some others like blood not at all beter compared to old good general midi) i will use aweutil. if i want general midi or like the sound of it beter that awesynth, then the mpu chip on this new awe card will be a beter solution. also this along with real opl chip makes the card act as full sb16 when needed. the vanila awe64 dont have opl3 and as i said before general midi as sound can lead to problems.i cant see this card cheaper that 150 euros at best but will worth it.

Aweutil is what enables general midi on AWE. If you just want awesynth, just select AWE music in game, aweutil is just needed to initialize card in that case.

my isa motherboard inst working right now to test. hopefully i will repair it. but if i remember corect for just midi or awesynth you need aweutil in dos. but cant confirm right now, i have the impresion you need aweutil for both to work

truemaster wrote on 2020-01-03, 09:48:

my isa motherboard inst working right now to test. hopefully i will repair it. but if i remember corect for just midi or awesynth you need aweutil in dos. but cant confirm right now, i have the impresion you need aweutil for both to work

Aweutil is always needed to initialize the card. However, you only need it to stay resident for GM emulation via awesynth. If using mpu401 to drive external synth, you don't want to leave aweutil resident, nor for when selecting AWE music in game. I use both awe32/64 under dos and win98 regularly.

AWEUTIL is only necessary as a TSR if you are doing GM or MT-32 emulation. For AWE Synth or MPU-401 you only need to initialize the card with AWEUTIL.COM /S and it will run and terminate.

From what i could understand reading the PCB, it is possible to select which MPU (HardMPU or SB16 MPU) control either the DB-15 or waveblaster header. Is this the case or am i understanding it wrong?

Great feature if that's the case.

Exactly. It was offered as an option in the questionnaire, and the people voted for it - so here it is. It's already confirmed as fully working as intended by the way.

it will be an awe64 with all good parts back compared to vanila awe64. and exept main ics, the card has new components like the caps and is redesigned. lower noice at least when compared to value models. and propably would last more compare to old good vanila awe64. yes that part i confuse aweutil.com /s for cqm (opl3) and awesynth. and aweutil.com (resident in memory as trs) for general midi mt-32.

Still just super excited about this - it's still happening, right? (no rush, just wanna make double sure I don't miss out)

Yes, sorry for this little delay, we were trying to make it by Dec 31, but discovered some minor issues, and as the quality is a top priority for us, we've decided to sacrifice the time to market for the better product. In fact, that is what differs the AWE64 Legacy from the original card by Creative 😁

well if you guys werent around such thing wouldnt exist. so yeah take time as much as you think it need

Dec 31st?

Typo?

Nope. It was our internal deadline, but well, it's gone 😀

@hard1k, do you guys have something like a git repository and project or anything similar to maintain version history, documentation, progress, collaborated development, files and other important stuff to eventually let collaborators help squashing bugs and eventually to help adding other really nice features? For instance, in your first post you've mentioned that you need help with the CMOS and a few features have not been implemented due to higher complexity, which could possibly be solved/implemented by willing members of the Vogons forum (and others).

Might I also add that I think this is a really an AWEsome initiative! Thanks for at least sharing your results and eventually producing some cards! 😁