I got stuck on these with CIAgent as it was missing some PPC codes which I fixed. It was showing up on timer registers which meant that timer emulation was broken because the timer value wasn't being set.
The decoder in NallePUH is quite extensive so surprised it got stuck. Still I checked the codes when I got stuck on it. I wonder if it's the codes Petunia is using that were uncommon back when PUH was ported?
Also PUH has a few obvious faults in the emulation. As soon as it catches a register change it sends it to AHI. It doesn't check what it is or if it had changed. A lot of software and especially module players writes redundant data in audio registers like the same value over and over. As well as invalid values like $FF00 as period which is then fixed a few interrupts later. I imagine all this combined is why it used to crash on me. For one thing sending the same value to an audio driver is expensive and redundant.
Yes, I think something changed in Petunia, or maybe it stopped working when Petunia was included, I remember first versions of AmigaOS4.0 did not have JIT.
I wonder, can you tell me what, it is, if dump all the register values?
Yes, remember it kind worked once, so getting back to that is a start, all other problem and issues, has to be analyzed.
Anyhow, it has a half word (16bit) access, any word (32bit) wont make sense, not any byte read or write, real Amiga hardware registers don’t support that.
(NutsAboutAmiga)
Basilisk II for AmigaOS4 AmigaInputAnywhere Excalibur and other tools and apps.
Petunia can be disabled but not easily. Perhaps a patch could be written that disables any JIT flag in EmulationTags()? IF all emulation goes through it that is.
Can always blacklist it if it's from one program.
I could tell what it is if it listed the instruction. But in general JIT needs to be disabled or it messes up the crash log. Most Petunia crash logs are useless as it flags the BLR (return) instruction after the code.
So it's hitting on $DFF006. Looked it up and that's VHPOSR. It's reading the horizontal beam position. It's likely using this as a timer as module players used it in an interrupt as a micro delay to wait until sound DMA started to set loops.
An issue here is that it will get the same value back. Usually a zero. If it is polling it as in the usual case then it tends to freeze system if inside interrupt. Otherwise it should have just caused CPU to go 100%. Surprised it is crashing. Whatever is crashing.
If it's polling it you will likely need CIAgent (or anything else like NallePUH) as it simulates beam position with a counter. Without it CIA player interrupts take down the system. This is also the result of OS4 emulating a 68K interrupt inside a real PPC interrupt.
BTW, 68K programs could read and write 32 bits to Amiga hardware registers. Such as writing a bitplane pointer. Or reading both VPOSR and VHPOSR at once into a CPU register. Can be 16 or 32 bits in this case, but only for a read.
nope, its just stuck i think.. my keyboard is lucked up, but that can easily to be a bad thing.
1000 of expectations with long text message on the AUX port has tendency to be a bad thing.
I only dumped the registers array, to make it easier to guess.
Quote:
So it's hitting on $DFF006. Looked it up and that's VHPOSR. It's reading the horizontal beam position. It's likely using this as a timer as module players used it in an interrupt as a micro delay to wait until sound DMA started to set loops.
Yep thats what I'm thinking too.
(NutsAboutAmiga)
Basilisk II for AmigaOS4 AmigaInputAnywhere Excalibur and other tools and apps.
There is intuition lockup problem… Wonder, if it’s possible to find out why intuition is locked up, what task has locked the screen, or something else, at what program counter value.
(NutsAboutAmiga)
Basilisk II for AmigaOS4 AmigaInputAnywhere Excalibur and other tools and apps.
Yes, same as in the NXP PDF. That lbxz. It's a doozie.
I suspect it's in a vertical blank interrupt where the polling of $DFF006 is.
That could easily be added also since it catches other hardware hits. NallePUH was really left in incomplete state. For some reason it's like a lot of OS4 ports that were somewhat inferior to the 68K counterpart as they lack a GUI. I don't know why OS4, which should be superior to OS3, has ports that a lack a GUI.
Looks like we have a infinity loop of exceptions here, this way it get stuck..
it does not support $DFF006.
Originally this was made for Amiga1200/4000, so there was chipset, so if you had a unhandled expectation, it made sense to by default poke the hardware, if you had unhandled expectation, I guess.
this is what I guess is causing the loop.
Edited by LiveForIt on 2022/11/6 1:26:52
(NutsAboutAmiga)
Basilisk II for AmigaOS4 AmigaInputAnywhere Excalibur and other tools and apps.
Yes real hardware had $DFF006 so didn't need to catch it. Then again real hardware has real Paula so the idea didn't really make sense on real thing. Useful for Amithlon.
Should be easy enough to fix. Just add $DFF006 as VHPOSR and $DFF004 as VPOSR could be good idea as well. Just keep a running counter and increase on every read. Really is simple when you know how. I knew about it. Better is knowing what values are masked out so a jumping counter based on masking would reduce hits. It could read it 40 or 80 times in a row.
News feed
OS4 Feedback forum
OS4Depot Feedback forum
Amigabounty forum
OpenAmiga forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
Donate
