Why imperfect? You can make it perfect and work in all the cases, if you want. I said it might not be worth to bother with the complicated cases, and just generate BERR internally for RAM and ROM accesses. But you can emulate BERR in every I/O if you want, as emulators already do. There is a (minor) problem that the exact behavior depends on the chipset version. You can try to detect the current chipset, if you insist. Or just use the most common chipset behavior. Nothing too bad would happen if your BERR emulation doesn't match the actual hardware exactly. You are not cycle accurate anyway.Badwolf wrote: 13 Jan 2026 10:25 That's an excellent point and one I hadn't thought about: generate the BERR in the emulator. Imperfect, but probably good enough for 99% of use cases.
Yes. I would need to think about this better, but I think it is harmless as long as the emulator is aware about this. TAS was designed to be atomic even in multi processor systems. But in our case, the only thing that can interrupt a read modify instruction is DMA. So, it should probably be ok as long as the emulator makes sure not to grant the bus in the middle of the RMC bus cycle.Is that the command that produces the RMW cycle? I don't think my inital port handled it originally, no.
I'm not sure I understand why Bus Error handling should significantly affect performance. A bus cycle takes half a microsecond in the best case. This should be the dominant timing for bus cycles, by far. But may be I am missing something?Compiling in the bus error handling into the emulator does have quite an impact on performance ...
Wait a minute. You are saying that the above performance numbers are only for memory access. But that, in general, processing is way much faster?(we're just talking about memory speeds here, remember)
Ah, nice. May be the key is to implement a smart "write back" cache, not write through. It is probably complicated, might need to be running in a separate thread to be really efficient. But if you are using local storage (which means no real DMA), and video emulation, you might never need to read or write to RAM at all. Even if not using video emulation, as long as you are not running a game that changes the video address frequently, a smart write back cache might reduce writes to the minimum.The 'write through cache' was actually implemented quite early in development ... And yes, it improved things *considerably*.
I was thinking that if you optimize memory access, you might reach a point that the dominant time might be the I/O access to process the VBI and the timer C (200 Hz) interrupts. At that point it might pay to implement a custom driver to generate the interrupts locally. Of course, you might say that this kind of "optimizations" makes the PiStorm more an emulator than an accelerator. Guess the PiStorm fans wouldn't care, and the purists won't use a PiStorm anyway :)
May be this need to be investigated thoroughly, and fixed if necessary.... but that really demonstrated how broken the interrupt logic was on both ends of the interface. I'm fairly confident that brokenness was inherited rather than introduced by the Atari chaps.
That's not a bad idea at all. But I'm not sure it is worth the complication. It is probably simpler and more efficient just to emulate the complete BERR behavior internally. If you know that the bus cycle is going to generate BERR, don't bother performing the bus cycle at all. If you know it will not, then you don't need to check.SteveBagley wrote: 13 Jan 2026 13:18 Given, IIRC, GLUE in the ST generates BERR if it hasn't seen DTACK for a certain time period (500ns?), is there any reason you couldn't just implement the same logic in software on the PI to generate BERR synthetically? (i.e. effectively if you timeout on waiting for DTACK, then it must be a bus error).
