Sonnet 7200 PCI programming

[Hedeon]

AmigaAMP in combination with mpega uses Amiga FAST RAM as decoding buffer. I'll try to fix that.

[BULI]

Originally Posted by Hedeon

AmigaAMP in combination with mpega uses Amiga FAST RAM as decoding buffer. I'll try to fix that.

Now, I understand why mpega.library don't play smooth on Ragnarok (the same situation is on Amplifier, who use mpega.library).

[Hedeon]

Originally Posted by Hall80

FYI: In my A1200 the Killer K1 was initialized and found every time at any PCI slot (with Voodoo3) but Ragnarok NOT! Sometimes Yes , sometimes no.
Ragnarok need Voodoo RAM at start up/init, K1 not. May be that this is the problem =o/.

Only MPC107 based cards need VGA RAM at the start. The others do not.

[k0x]

Killer K1/M1 sports 64MB of RAM.

The 64mb of onboard memory is handled by a pair of Micron Technology memory IC’s with the FBGA number of D9DWJ, which can be decoded to find their true part number of which is MT46V16M16BG-6:F. After looking up the part number it was easily found out that these are 256Mb DDR1 SDRAM parts that are rated to run at 333MHz with at CAS Latency of 2.5 when operated at 2.5V.

The memory chip datasheet is here

https://media.digikey.com/pdf/Data%20Sheets/Micron%20Technology%20Inc%20PDFs/MT46V64M4,%2032M8,%2016M16.pdf

How about replacing those two chips with higher capacity?
What chip shall I look for?

[grelbfarlk]

Originally Posted by k0x

Killer K1/M1 sports 64MB of RAM.

The memory chip datasheet is here

https://media.digikey.com/pdf/Data%20Sheets/Micron%20Technology%20Inc%20PDFs/MT46V64M4,%2032M8,%2016M16.pdf

How about replacing those two chips with higher capacity?
What chip shall I look for?

I tried with Micron MT46V64M8CV-5B without success.



The other problem is that the "BIOS" or Flash-ROM on the board may not be set up to properly detect and enable extra memory. This is not an insurmountable problem but to my knowledge nobody has really put in a whole lot of effort to fix this problem.

[k0x]

Originally Posted by grelbfarlk

I tried with Micron MT46V64M8CV-5B without success.



The other problem is that the "BIOS" or Flash-ROM on the board may not be set up to properly detect and enable extra memory. This is not an insurmountable problem but to my knowledge nobody has really put in a whole lot of effort to fix this problem.

Ah, you are always 2 steps ahed


When chips were replaced, was the card working with same amount memory or it was dead?



Thanks for info.

[grelbfarlk]

Originally Posted by k0x

Ah, you are always 2 steps ahed


When chips were replaced, was the card working with same amount memory or it was dead?



Thanks for info.

As I recall, it's been a while now, that it actually seemed to allocate the 64MB Memspace and I could sort of write to it (though it was corrupted), and the PPC was probably crashed. The card was otherwise detected and the Sonnetlib was still detecting the card and trying to initialize it. It actually acted somewhat like the "builtin-default-clocking-modes" modification that we never really got working.

Anyway, too many unknowns, it's just as likely that I failed to solder the BGA chips properly-that's actually the most likely problem-but even were that not an issue the other problems would have to be fixed by $somebody.

And I'm not too sure, but alternate memory configurations generally require a library update, see Buli's recent posts about the Apocalypse with only 128MB.

[Hedeon]

Originally Posted by Hedeon

AmigaAMP in combination with mpega uses Amiga FAST RAM as decoding buffer. I'll try to fix that.

It's a bit weird. AmigaAMP v2 allocates 4 buffers (I am guessing for each AHI unit) so I fixed that. AmigaAMP v3 does the same, but then uses a whole different kind of play buffer and not the 4 allocated ones.

So V2 is working, V3 is not. That being said, I have an old V3 (from 2017) so I'll have a look at the latest. But I rather not turn on the Amiga with this heat, so I'll look at it this weekend or next week.

[grelbfarlk]

Originally Posted by grelbfarlk

As I recall, it's been a while now, that it actually seemed to allocate the 64MB Memspace and I could sort of write to it (though it was corrupted), and the PPC was probably crashed. The card was otherwise detected and the Sonnetlib was still detecting the card and trying to initialize it. It actually acted somewhat like the "builtin-default-clocking-modes" modification that we never really got working.

Anyway, too many unknowns, it's just as likely that I failed to solder the BGA chips properly-that's actually the most likely problem-but even were that not an issue the other problems would have to be fixed by $somebody.

And I'm not too sure, but alternate memory configurations generally require a library update, see Buli's recent posts about the Apocalypse with only 128MB.

I found this card and for a laugh tried to start it up. The 64MB memspace in pciinfo is there, but reading the memory it's all just garbage, writing anything just produces more garbage.



I tried pinning around the board a bit and the extra I/O (compared to the smaller chips) for the larger memory chips appear connected to the CPU in the correct(?) places, so that's good. Anyway I found three of the extra required address lines connected, maybe the rest are, don't know.


If some brave or bored soul wants to check if all these are connected from:
On the DDR chips:



To these pins on the CPU:

[Hedeon]

Originally Posted by Hedeon

It's a bit weird. AmigaAMP v2 allocates 4 buffers (I am guessing for each AHI unit) so I fixed that. AmigaAMP v3 does the same, but then uses a whole different kind of play buffer and not the 4 allocated ones.

So V2 is working, V3 is not. That being said, I have an old V3 (from 2017) so I'll have a look at the latest. But I rather not turn on the Amiga with this heat, so I'll look at it this weekend or next week.

Here's a test lib. The autobuild function on git is not working atm.

AmigaAMP v3 uses a BSS hunk as a data buffer. Now this BSS hunk goes to PPC memory. AmigaAMP V3 starts much quicker than V2, but loading an MP3 takes ages when load whole file is ticked (it loads an MP3 of several MBs by 1024 bytes a piece......) I recommend ticking 64k or something like that as a buffer. It still fills that buffer with 1024 byte loads.

Both mpega.library and external decoder should work now. I recommend mpega.library.

You need to reinstall AmigaAMP v3 or find a way to reset the unused protection bits of the program (upper 8 bits). The command protect or DOPUS 4 does NOT do this.

Haven't looked at Amplifier yet.

[Hedeon]

Latest update with the fix for AmigaAMP is now on git. Removed above archive as it contained debug code that does not run on every system.

[indigolemon]

Confirmed working for me, using the WarpUP mpega.library without issues now! Great stuff, currently playing a 320kbps@44khz MP3 and the 060 is sitting at around 40% use (which will all be disk IO I think, HDD on the 1200 IDE port).

[trixster]

Can you give a quick update on what works and does not work on your 1200?

[indigolemon]

Well, I've not been as good as testing as I should be as I have yet to get the Voodoo back in play - everything is working really well atm with the Radeon and I must admit I'm a little scared to rock the boat too much!

So - background before the list below, I start the PPC card using a script as and when I want it, as starting it during normal startup eventually makes the machine unstable.

Game wise, the only success so far is QuakeWOS - and even then it needs to be from a cold boot - if I use the machine for while, then enable the PPC and fire it up, I'll get a hang of some description (it usually locks trying to bring up the Quake Options GUI).

Software wise, I can run the bogomips command no bother, SysSpeed happily runs benchmarks, and I can now use the mpega.library to play music via AmigaAMP (and have previously been using WarpAMP without problems).

Any software that wants to use Paula is a no-go, and as mentioned, the longer I run the PPC the less stable the system becomes - although that situation has greatly improved over the last few builds!

Once the system has crashed with a PPC fault, I can't really do anything unless I power off completely and leave it 30 seconds or so. A reboot doesn't help, it's like the memory needs to be cleared for it to work again?

And finally, I'm still very much aware the 1200 isn't officially supported, and once more appreciate all the efforts made to try and get it working as well as it does for the big box miggies

[Hedeon]

Originally Posted by BULI

Anybody use mpeg.library for WOS from Aminet

http://aminet.net/package.php?packag...ega-WarpUP.lha

with AmigaAMP, or AMPLIFTER?
Could anybody check it?

I checked Amplifier (v2.35 from BB3/4 not the 2.10 from Aminet) and it seems fine with the latest library. Can anyone confirm this?

On a side note (bug): Amplifier does not produce any sound when at 100% volume, but does at 99%, in case ppl think it is broken.

[Hedeon]

Originally Posted by indigolemon

the 060 is sitting at around 40% use

How did you measure this? If I look at DOpus4 it says 60%, but if I look at Scout it says around 25% for the 68k part of the mpeg decoding.

Amplifier: DOpuS says again 60%, Scout says 20% for visualization and 20% for 060 part of mpeg decoding.

Not sure if DOpusS is correct.

[Hedeon]

Had a look at Hollywood. Script decoding is very fast compared to the 060 but running the result not. It seems that Hollywood is a 68k program calling PPC subroutines. The player at least. So scripts compile like 10-20x as fast, the playing is maybe 2-3 faster. With the 060 sitting at a hefty 70-80% and the PPC at around 5%.

Does anyone have compiled (using the interpreter) files I could test? Preferably Asyncfx from the samples directory from the player found on Aminet.

[indigolemon]

Originally Posted by Hedeon

How did you measure this? If I look at DOpus4 it says 60%, but if I look at Scout it says around 25% for the 68k part of the mpeg decoding.

Amplifier: DOpuS says again 60%, Scout says 20% for visualization and 20% for 060 part of mpeg decoding.

Not sure if DOpusS is correct.

I think it's hard to get a good measurement really, but I just always use the same app - Idle: http://aminet.net/package/util/moni/idle2_2

[Stedy]

Originally Posted by grelbfarlk

I tried with Micron MT46V64M8CV-5B without success.


The other problem is that the "BIOS" or Flash-ROM on the board may not be set up to properly detect and enable extra memory. This is not an insurmountable problem but to my knowledge nobody has really put in a whole lot of effort to fix this problem.

You used the wrong RAM width! The original part, the MT46V16M16BG is 16Mbit x 16 bit wide = 256Mbit or 32 Mbyte.
The MT46V64M8CV is a 64 Mbit x 8 bit wide = 512Mbit but it is only 8 bits wide, your original was 16 bits wide. A MT46V32M16 should work and double the RAM. It looks like 1Gbit DDR has been discontinued factory fresh.

It's not too difficult to program the DDR controller in the MPC834x devices, UBOOT has some example code. I don't remember how to set the PCI memory space usage, it's been a while.

[k0x]

128MB would be great on this card but I aim at 256 or 512MB