[模拟新闻]Makaron WIP 最新开发进展 01.24

XANADU

http://dknute.livejournal.com/15529.html]

• 18th-Jan-2008 - Today's experiment... success!
  
  Now the usuall stuff. I'm sure you've noticed how even the MT version gets choppy sometimes, SH4 speed indicator going all red for a split second with sound getting distorted, and so on. If you were paying attention you've noticed your HDD led blinked at the very same moment. Yup, it's not a coincidence. Untill now CD/GD image reads were blocking the main emulator thread - but no more.
  I've begun converting GD layer to threaded model and hit few walls (what a surprise, huh?). I mean it's very doable but I have a very specific implementation in mind:
  - ATA/ATAPI layer responds according to standards
  - INTRQ/DMARQ signals can change asynchronously
  - disc reads do not block emulator
  - data reads are speed-limited to 12x
  - DMA transfers are speed-limited to G1 max. of 10MB/s
  
  I'd also like to move CDDA support from image reader to GD module as a special case of raw sector read. This way I'd have only one place in which the buffers are being refilled from HDD - nice and tidy.
  So far I've completed about half of that, that is data reads are not blocking anymore - man, that does make a difference. You will like it . Still, the limiter on DMA is 10MB/s now and there's none on GD yet. Why would I even need those? Because I like it that way. Sure as hell would make my life easier to just remove them but this is a gauntlet thrown in my face and I will take up that challenge
  All this and no need for thread blocking other then BSY flag in status register - just like the hardware. But this might not last as I still need to figure out how to convert functions that "open" and "swap" discs - those can be called anytime from main thread (that is, menu that will be there someday). I need to gracefully handle cases like swap requests in the middle of buffer refill for example.
  
  The additional thread doesn't run all the time, it goes to sleep when GD is not being accessed. This means you don't need triple-core (and if you have you will not notice any speedup) beacuse it'll most likely get scheduled to the core doing rendering, once it finishes that of course. I'm sure you realize that on single-core system the read has to block at some point, so non-MT version will have this mechanism disabled and work as they always did.
  
  Oh, by the way, fighters/shooters use fog too: