MvSCSI trouble

I contacted the guy behind mvSCSI as there is a strange problem when I’m using it : internal exceptions are triggered. It isn’t preventing the dll to do what it’s supposed to do, but it’s a bit ugly. According to him it’s a problem on his side, he’s working on it.

Back to my code … I’ve started rearranging the cdrom code to have separate files for ASPI and SPTI. Until today ASPI code was included into the cdrom class, which isn’t possible now with 2 different access type. This way it’ll be easier if one day I’m interested in putting the code in separate dlls (why not to be compatible with other Saturn emus ? :p ) I won’t go a lot further in that aspect as I can’t test it while my VDP2 cache isn’t working.

Opening

I thought it might be a good idea to share about what I’m currently working on … Originally this was posted on Saturnin’s private board, but I thought that it might be interesting to share it with more people.

  • CDRom access

So I had for a long time in mind to change the way that cd data is accessed. Currently ASPI is used, but it leads to a lot of incompatibility problems depending on what version is used. My first choice was to use ioctl, which only drawback is to be incompatible with pre Windows 2000 versions. But as Windows 95 and 98 are getting less and less used, I wanted to give it a shot. I intend on keeping the ASPI layer for those anyway 😉 After messing around a while, I wasn’t able to read raw data from a cdrom using ioctl. Audio data reading was fine, but raw data wasn’t.

Someone pointed me out mvScsi, which is a “simple C API for programming SCSI devices under Windows NT/2K/XP”, a SPTI wrapper. And it works great. So far I was able to read the system ID from a Saturn game disc (this functionnality is back, hurray !), I have now to clean up the code, to add code to choose between ASPI and SPTI, and to code STPI data access functions …

  • VDP2 texture cache

This is a huge one. After releasing version 0.40, it was obvious that speed was a problem. Debugging something ingame was taking forever to get to the good spot. So I decided to apply the same technique I used for the VDP1 cache to the VDP2. Now every cell (8*8 pixels) is considered as a texture which is cached in a huge list. The core of the cache is done (mainly using STL), but I still have crashes at some point during the BIOS … When this bug will be ironed out, I will have to code every display case to use the cache. But the good news is that it’ll simplify the code, as geometric transformations will be done natively via OpenGL instead of manually. Plus, Fabien told me he found a technique to display quad textures without the triangle deformations …