wraggster
July 3rd, 2008, 20:22
DKNute has posted more news of his impressive Dreamcast Emulator for Windows:
F355 Challenge works again. Turns out it was indeed SH4 recompiler bug - one that crept in with the introduction of MMU support. In short: right now all SH4 modules use common framework for interrupts and exceptions, and while converting TRAPA instruction to use that framework I've made a small mistake. Fixed.
The Skies of Arcadia bug is still there, unfortunately. Sometimes I can go in and out the game menu dozens of times (in rapid succession too) and it works. Then I restart the game, and it hangs on the very first try... You know, this might actually be a game bug, it just never manifests itself on Dreamcast due to much tighter corelation in timings on real hardware. Current PCs are faster but all operations exhibit a certain amount of lag (or should I rather call it "processing overhead") - well, only sometimes, but it happens every now and then and there's no control over it. It might take just a milisecond somewhere, when OS decides to switch threads at different time to balance CPU usage better for example, and there it goes. So... still looking into it.
I've came to belive that the same timing problem plagues GD code. It works for me (most of the time) but breaks horribly for other people. I've spent some time trying to determine the cause and I found out that SoA usually works, but will almost always crash at boot if I lower SH4 speed to some 150 MIPS. Curious, isn't it, especially if you consider GD-DMA speed is now tied to SH4 speed - so why does it even matter how fast it goes?
After a while I've noticed that in MT mode GD buffer becomes empty every now and then and this causes problems. Now, this is very unscientific explanation but my guess is BIOS booting procedure is kinda broken. Oversimplified. Maybe because it had to be short to fit all the code in cheaper and smaller ROM?
Anyway - a real GD drive isn't all that fast but once it starts reading, the data is being constantly streamed from disc to it's internal memory. And from there to Dreamcast main RAM via DMA. Think "hourglass" - constant stream of sand goes through. Now, on a PC it's more like a guy with shovel loading a truck. He can do way better in terms of quantity of sand moved but it's no longer a constant stream. If the truck is full it can supply us with all the sand we want but once it's empty it has to go back to the guy with shovel. If at this point we need more sand we either wait (that's blocking emulator for the read to complete) or go empty handed (DMA will finish later then usual and this might cause crash).
If you're smart you already see two ways to fix that. Either wait, as explained above, or... make the truck so big it will never become empty at the wrong time. In other words, make the GD data buffer at least the size of Dreamcast RAM, which is 16MB. And that's what I did yesterday and that really helped :)
This method isn't 100% fool-proof, as a real GD starts streaming data the moment the first read sector lands in its buffer. In our case loading some few MB might take longer and still fail because of that. This however wasn't a problem so far (or else the whole "offloading to thread" thing would not be possible) and let's hope it stays that way.
Marionette Company boots now, though there seem to be some geometry missing because I don't get text in dialog boxes at all... It's a WinCE game so maybe it's the Sort-DMA thing again?
And c'mon people, new version of Makaron isn't always going to be better than the last one. This is why I call my releases "Test", you know. So that you could TEST things, like new code and such. And report your findings back, maybe? Some people do - and I thank them for that.
Just because I'm not all over your problems when you report doesn't mean I disregard them. Still, I've no intention of answering each and every comment that shows up - this is a place in which I brag about how great I am, not a help desk.
http://dknute.livejournal.com/
F355 Challenge works again. Turns out it was indeed SH4 recompiler bug - one that crept in with the introduction of MMU support. In short: right now all SH4 modules use common framework for interrupts and exceptions, and while converting TRAPA instruction to use that framework I've made a small mistake. Fixed.
The Skies of Arcadia bug is still there, unfortunately. Sometimes I can go in and out the game menu dozens of times (in rapid succession too) and it works. Then I restart the game, and it hangs on the very first try... You know, this might actually be a game bug, it just never manifests itself on Dreamcast due to much tighter corelation in timings on real hardware. Current PCs are faster but all operations exhibit a certain amount of lag (or should I rather call it "processing overhead") - well, only sometimes, but it happens every now and then and there's no control over it. It might take just a milisecond somewhere, when OS decides to switch threads at different time to balance CPU usage better for example, and there it goes. So... still looking into it.
I've came to belive that the same timing problem plagues GD code. It works for me (most of the time) but breaks horribly for other people. I've spent some time trying to determine the cause and I found out that SoA usually works, but will almost always crash at boot if I lower SH4 speed to some 150 MIPS. Curious, isn't it, especially if you consider GD-DMA speed is now tied to SH4 speed - so why does it even matter how fast it goes?
After a while I've noticed that in MT mode GD buffer becomes empty every now and then and this causes problems. Now, this is very unscientific explanation but my guess is BIOS booting procedure is kinda broken. Oversimplified. Maybe because it had to be short to fit all the code in cheaper and smaller ROM?
Anyway - a real GD drive isn't all that fast but once it starts reading, the data is being constantly streamed from disc to it's internal memory. And from there to Dreamcast main RAM via DMA. Think "hourglass" - constant stream of sand goes through. Now, on a PC it's more like a guy with shovel loading a truck. He can do way better in terms of quantity of sand moved but it's no longer a constant stream. If the truck is full it can supply us with all the sand we want but once it's empty it has to go back to the guy with shovel. If at this point we need more sand we either wait (that's blocking emulator for the read to complete) or go empty handed (DMA will finish later then usual and this might cause crash).
If you're smart you already see two ways to fix that. Either wait, as explained above, or... make the truck so big it will never become empty at the wrong time. In other words, make the GD data buffer at least the size of Dreamcast RAM, which is 16MB. And that's what I did yesterday and that really helped :)
This method isn't 100% fool-proof, as a real GD starts streaming data the moment the first read sector lands in its buffer. In our case loading some few MB might take longer and still fail because of that. This however wasn't a problem so far (or else the whole "offloading to thread" thing would not be possible) and let's hope it stays that way.
Marionette Company boots now, though there seem to be some geometry missing because I don't get text in dialog boxes at all... It's a WinCE game so maybe it's the Sort-DMA thing again?
And c'mon people, new version of Makaron isn't always going to be better than the last one. This is why I call my releases "Test", you know. So that you could TEST things, like new code and such. And report your findings back, maybe? Some people do - and I thank them for that.
Just because I'm not all over your problems when you report doesn't mean I disregard them. Still, I've no intention of answering each and every comment that shows up - this is a place in which I brag about how great I am, not a help desk.
http://dknute.livejournal.com/