Category: Emulation

Got the basic SPTI routines running. Now Saturnin can select a drive, save it by its letter, and read data from the cd inserted. The structures are now shared between ASPI and SPTI, and the drive letter is saved (instead of the id)
However there’s a problem : this technique cannot be used for ASPI, as there’s no way to map correctly windows drive letter to the internal SCSI configuration.

How does it work :

SPTI :

• you get a handle to a drive by its letter (D: for example)
• you use this handle to get the SCSI address of the drive (bus/target/lun)- and then you use ioctl to get the data configuration from the drive, using the SCSI address

ASPI :

• you scan the SCSI chain, testing for each address if it’s a cdrom drive or not
• if that’s the case you save the SCSI address of the current drive
• you get the logical drive list from Windows and try to map it to the SCSI address

The problem with ASPI is that you don’t have a function to map the drive letter to the SCSI address … you can get a list of logical drives, but you can only guess it’s mapping. It won’t work for people changing the order of the drive letters in Windows.

Quick example :

Before modifying logical letters

Windows letter	SCSI address	Position
D: (cdrom)	0/0/0	0
E: (dvdrom)	0/1/0	1
F: (virtual drive)	0/2/0	2

After modifying logical letters

Windows letter	SCSI address	Position
B: (virtual drive)	0/2/0	0
D: (cdrom)	0/0/0	1
E: (dvdrom)	0/1/0	2

Using ASPI, as we only have the position in the SCSI chain, the letter mapping won’t be accurate …

I did look into FrogAspi, as it was supposed to be an ASPI replacement, and much to my regret it’s also based on ioctl, so it’s not usable on Windows 9X systems 🙁

Update : I’ve decided to get round this problem by saving the SCSI address in ASPI mode. The only drawback being that you won’t have a letter displayed in the drives list when you’re in ASPI mode …

When you’re trying to make new stuff work, you begin by setting everything up, coding test routines, solving problems, and when everything seems to work the way it’s supposed to, you try to put the code in a more formal way to be usable by the rest of the program. And that’s typically the moment when new and unexpected problems arise …

Actually, the problem I ran into was related to file header inclusion and external variables declaration. Some headers were included more than once, others were overlapping, etc … A real mess.
After looking around to see what’ll be the best way to solve this, I decided to put every needed header file in a single one which will be called by every cpp file. It went smoothly on the code generation, but then the linker went berserk : more than 1000 errors ! What the hell ?!??

I had to dig further into my code, and finally I found out what was the problem : some extern variables were explicitally declared as using C linkage, result of years of coding without knowing in depth some of the specificities of the language …
Now everything uses C++ linkage, Saturnin compiles like a charm, and that’s great news 🙂

Back to my SPTI routines now … :p

So I’ve decided to let down mvSCSI, for 2 main reasons :

• the creator hasn’t contacted me since the last time, I don’t know if he still has the problem I pointed out or if he doesn’t care (I don’t blame him)
• it needs the dll to be bundled with the emulator, which isn’t really good if I want one day to put the relative code in its own dll … meaning that 2 dlls are needed in order to make it work.

So I spent some more time trying to access sectors using SPTI directly, and I was successful using SCSI_PATH_THROUGH_WITH_BUFFER. SCSI_CDROM_RAW_READ still doesn’t work though, but that’s not that important as raw sector read isn’t needed for now (maybe it won’t be needed at all 😉 )

So what’s next to develop :

• functions to get the cdrom players list and to save them to the config file
• shared structures between ASPI & SPTI to have code as portable as possible between the 2
• put ASPI code in its own files
• functions to take care of what’s nedeed by the Saturn from the SPTI side (read TOC, read sector, etc. )
• code to switch between SPTI and ASPI

I had to do a bit of cleaning in my interface code, and I took the opportunity to get rid of a bunch of global variables … less they are, better it is 😉 Anyway I’m now going to change the way selected cd-rom is saved in the config file, to fix the problem that PsyMan talked about earlier. I’ll also have to lift the SPTI/ASPI code out of the cd-rom class, as it doesn’t really belong here … After that I think’ll try to go back to my texture cache problem, as I can’t test cd-rom access while it’s still happening …

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.

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 …