PistormX
PistormX copied to clipboard
f1ac0
PistormxDMA Amiga 2000 eatx troubles.
Hello! I’ll describe it in order: pistormx of the first revisions (without expansion cards in Zorro) - problems with the mouse cursor which trembles convulsively on the screen and is practically uncontrollable. Changing the firmware and modifying the pistormx itself to support dma solves the problem with the mouse. everything works well. When you insert a sound card into a Zorro slot (any), instead of sound from the card, a high-frequency loud noise is emitted and music plays very quietly... prlcheck (prelude utility) displays an error that changes when the utility itself is launched again.
Hi. I am happy to have feedback from a PiStormX user. Thank you for sharing your experience with the A2000, which seems to prove that the PiStormX-DMA logic is working. On my side, I couldn't find an A2000 at a decent price to test it, and to create a CPU board supporting both the 68k and the bus arbitration/DMA at the same time.
About the Prelude, and PrlCheck : according to your screenshot, it does something with address 0xE90000 which is "Secondary [auto-config space] (usually 64K I/O boards)" according to the Amiga memory map. I believe you are using Emu68 ; according to the last source files it does not seem to have a special behavior when accessing this address range (https://github.com/michalsc/Emu68/blob/0eaf3ab2c0641bb168b6b0c8c862182f3b8353cf/src/aarch64/vectors.c#L401) and I believe it also does not use cache (https://github.com/michalsc/Emu68/blob/0eaf3ab2c0641bb168b6b0c8c862182f3b8353cf/src/cache.c#L212). If you are using this same version, I do not see an obvious problem here.
On the hardware side, looking at the A2000 schematic, I believe that it is not a problem with logic voltage levels since address and data buses are buffered by U600-U604. Otherwise some CMOS chip on the expansion board might have not registered correctly the 3.3V outputs form the CPLD on the PiStorm'X board. (or it uses E, VPA and VMA that are not buffered).
The last thing I can think of is timing problem, especially if the offset of the error changes when you run prlcheck several times. For this it could be useful to confirm the address it uses and probe the bus to see what is happening.
After much torment with the a2k and the card, I decided to plug everything back into the a500... I connected the pi storm there and heard the same grinding and whistling noise as on the a2000! Well, I immediately thought maybe something had happened to my card... I returned the firmware and turned everything on again on the a500, the sound became normal... I put the pi storm with sound back in a2k, there is no sound at all, the card is checked with the same errors... I flashed back the pi storm with DMA support... the same thing, but there was a grinding and whistling noise... checking the prelude with the utility again produced chaotic errors and the guru machine when accessing the card... recorded some guru errors - 8000 0004 - 08184800, 08183260, 081е43f0, 08003020 etc The utility's check of the card sometimes goes through completely, but the test sound it makes is still the same bad noise... the following parameter z2_ram_size=4 was also added to the cmd txt line for emu68, the result is the same...
I recommend installing only boards+firmware that are aware of bus arbitration/DMA/bus master inside systems or with expansion boards that use it. Otherwise both the CPU board and expansion boards will talk at the same time on the buses, making unpredictable behavior, and maybe breaking something.
On the A500 where BR and BGACK are pulled up and not connected anywhere else, the PiStormXDMA logic will behave the same as the "pistormx - 4 states cycle write buffer" one. If this is the one you "returned to", I honestly don't understand what happened on the A500 at least. Do you unplug the board each time you flash it, and maybe there could be a bad contact somewhere/sometimes (even though all signals on the 68k socket are digital and a bad contact will prevent it to work at all - but maybe on the interrupt lines, audio channels from paula being interrupt 4 ?)
Before your last message, I was wondering if the JIT settings in emucontrol could change something with the prelude card like it does for some games?
Today I’ll try to play around with the emu68 control in symbiosis with the Prelude checking utility. I'm flashing it through a homemade cable (with a buffer) for the parallel port of an old PC +ise. I used this firmware for the a500 - pistormx - 6 states cycle write buffer.jed
hi! In principle, I did not achieve any big changes. pistorm equipped with jumpers so that they can be removed or installed at any time.
I noticed that with them (jumpers) and without them on the a2000 everything is determined and works the same... I achieved the following results with it, but they are also not constant...
I found on one of the forums that the prelude works on a2k with the original pi storm -
Ich hab ja mit Spannung auf den Treiber gewartet. Denn die Prelude (bzw. das Replikat) war in meinem A2000 mit Emu68 / Pistorm und dem Emu68 RTG Treiber mit den alten Treibern als Soundkarte per AHI oder Prelude direkt kaum sinnvoll nutzbar. Es kam ständig zu Abbrüchen.
Und in der Tat funktioniert genau das jetzt erfreulich gut. Wo es vorher zu Abbrüchen kam, stottert es jetzt leicht und insgesamt ist das Playback insgesamt viel stabiler. Gestern abend hat das System mit AmigaAMP 3.33 und MP3 Playback via AHI fast drei Stunden lang problemlos durchgehalten. Auch Hippoplayer dudelt jetzt schon eine Weile problemlos vor sich her.
Einzig Play16 per direktem Prelude Output spielt erst problemlos und hängt dann nach ein, zwei Minuten einfach ohne Möglichkeit zum Abbruch. Beim Playblack via AHI passiert das nicht. Wobei das natürlich auch Zufall sein kann, mein Setup ist ja in dieser Form eher experimentell.
A2000 Rev.6, Pistorm 2k / Emu68, AmigaOS 3.2.1, Freeway Pro, X-Surf 100, AT-Bus Clone, Prelude + MPEGit Replikat
https://www.a1k.org/forum/index.php?threads/85465/page-8
Why does pi storm x behave like this? Today I'll try all the firmwares.
I conducted the same experiment again with the DMA firmware and the removed jumpers that I installed on the pistormx - on the a500... it loads normally, the prelude is detected perfectly, but when I launched the digibooster I noticed how slowly the windows were drawn on the screen... choosing the prelude as the sound device and After loading the module, I heard the same creaking and noise... I changed the firmware to 6 state, everything worked fine on the a500...
I found on one of the forums that the prelude works on a2k with the original pi storm
What I see in original PiStorm logic is that bus arbitration signals M68K_BR_n, M68K_BGACK_n are not connected anywhere and M68K_BR_n is tied up. If the prelude works with that, then it does not use DMA.
I read here https://www.amigaimpact.org/forums/topic/tableau-perf-winuae/page/6/#post-375851 that it is recommended to use a "long hold" firmware to use the original PiStorm inside an A2000. I can see some binary files by this name here https://github.com/LemaruX/PiStorm-Firmware/tree/main however I cant find a source for it.
with the DMA firmware and the removed jumpers
Without the jumper wires I can see on your photo, then the BR input of the DMA firmware is floating and receiving noise from ambient, so the CPLD logic might be requesting the bus and releasing it randomly. This can explain your following sentence since according to pure randomness the bus throughput could be halved :
when I launched the digibooster I noticed how slowly the windows were drawn on the screen
You should leave your jumper wires always connected. When using non-DMA logic unused pins are just connected to a weak pull (keeper) inside the CPLD.
on the a500... it loads normally, the prelude is detected perfectly
your prelude is connected to the A500 ? Isn't it a board for A2000 ? https://amiga.resource.cx/exp/prelude
I changed the firmware to 6 state, everything worked fine on the a500...
I just added the bus arbitration/dma logic to the "6 states cycle write buffer" however I'm quite lost in what works and what doesn't.
The situation is the same... on the A500 the card plays okay and the utility test passes, but the mouse cursor twitches... at first I thought it was because of the RTG, but in the boot menu it also twitches... I removed the card and the cursor stopped twitching. I recorded a video of how it all works on the a500, but the volume doesn’t fit here... on the a2000 the situation with the card is the same... with the cursor everything is ok, the card is mistakenly checked by the utility and when playing only noise and I also noticed the music that plays in the background of noise You can hear that the samples are played at a faster speed! that is, the sampling frequency has been increased! how can this be...? prelude schematics - https://github.com/wiretap-retro/Prelude-ZII-Sound-Card/tree/main/PreludeZII/Schematics video amiga500+prelude & bootmenu convulsion cursor mouse - https://dropmefiles.com/bg6r7 - 2 files
I understand your setup a bit more.
A difference I can see between the A2000 and the A500 with this ZorroIIedge adapter is that the adapter does not have TTL logic ICs to buffer the address and data buses. However according to your Prelude schematic the signals are fed to 74F chips and to ATF20V8B chips that have TTL input levels, so the 3.3V from the CPLD might not be an issue there.
Also according to the Prelude schematic, BR, BG and BGACK are not connected. So it does not use DMA/bus master and the PiStorm'X-DMA logic with bus arbitration is useless here !
The dropmefiles link says the videos are being converted and the download button just refreshes the page when I click it.
I believe this leaves us with :
- on the hardware side, timings : have you tried the 8 states cycle logic ? (I guess that you did according to a previous comment but it is best to confirm)
- still on the hardware side, interrupt problem : have you checked all three IPL pins have good contact from the CPLD to the motherboard ?
- something on the software side (68K application/driver, emu68 or its config)
Cursor movement means that read operations of Denise JOY0DAT and JOY1DAT registers is returning wrong values ; in case of hardware problems I find strange that these would be the only fault.
Cpld was checked several times... all contacts were soldered ok. I flashed the firmware with 8 states (I also flashed it before) well, the same thing... on the a500 everything is ok, on the a2k the cursor twitches and is practically uncontrollable... I noticed that the cursor comes back to normal when the firmware is uploaded with DMA support... then the cursor is not twitches and the mouse works well, this concerns a2k. I have two SD cards with EMU68, one with the Coffin system, the other 3.2.1 with RTG... both have the correct drivers installed for the prelude, everything has been tested several dozen times... on the a500... and even on the a2000 only with negative result so far... that is, I can’t even think about the software part that there’s something wrong there... today I run the diagrom on a2k, all tests passed without errors. :( what could be the problem???
Hi! Сlaude pointed to the source with a long hold - https://github.com/captain-amygdala/pistorm/blob/c1e90713befeac724a83f36781bf2507d073b3ad/rtl/pistorm.v#L266 this was discussed here - https://discord.com/channels/784428461330530305/851194038841245766/1166755302021013664 I'm waiting for the firmware with long hold for Pi Storm X :)
I found the reason for the bad behavior of the mouse... it turned out to be a denise chip :( replaced it and everything is fine! but the sound card doesn't work...
Hello! I found the reason... it was the wrong resistor assemblies (rn902, rn102) that I installed :( on the a2000 motherboard. At the moment, the pistormx has the pistormxdma firmware - 6 states cycle write buffer, everything works well. A little later I will test all the other firmwares .
I express my gratitude to everyone who took part in this! Thank you!
ps pistormx - still works on a2000 without long hold :)
pps to Flac0, if you need to test something, I’m always happy to help! Thanks again!