Update to v101r07 release.

byuu says:

Added VDP sprite rendering. Can't get any games far enough in to see if
it actually works. So in other words, it doesn't work at all and is 100%
completely broken.

Also added 68K exceptions and interrupts. So far only the VDP interrupt
is present. It definitely seems to be firing in commercial games, so
that's promising. But the implementation is almost certainly completely
wrong. There is fuck all of nothing for documentation on how interrupts
actually work. I had to find out the interrupt vector numbers from
reading the comments from the Sonic the Hedgehog disassembly. I have
literally no fucking clue what I0-I2 (3-bit integer priority value in
the status register) is supposed to do. I know that Vblank=6, Hblank=4,
Ext(gamepad)=2. I know that at reset, SR.I=7. I don't know if I'm
supposed to block interrupts when I is >, >=, <, <= to the interrupt
level. I don't know what level CPU exceptions are supposed to be.

Also implemented VDP regular DMA. No idea if it works correctly since
none of the commercial games run far enough to use it. So again, it's
horribly broken for usre.

Also improved VDP fill mode. But I don't understand how it takes
byte-lengths when the bus is 16-bit. The transfer times indicate it's
actually transferring at the same speed as the 68K->VDP copy, strongly
suggesting it's actually doing 16-bit transfers at a time. In which case,
what happens when you set an odd transfer length?

Also, both DMA modes can now target VRAM, VSRAM, CRAM. Supposedly there's
all kinds of weird shit going on when you target VSRAM, CRAM with VDP
fill/copy modes, but whatever. Get to that later.

Also implemented a very lazy preliminary wait mechanism to to stall out
a processor while another processor exerts control over the bus. This
one's going to be a major work in progress. For one, it totally breaks
the model I use to do save states with libco. For another, I don't
know if a 68K->VDP DMA instantly locks the CPU, or if it the CPU could
actually keep running if it was executing out of RAM when it started
the DMA transfer from ROM (eg it's a bus busy stall, not a hard chip
stall.) That'll greatly change how I handle the waiting.

Also, the OSS driver now supports Audio::Latency. Sound should be
even lower latency now. On FreeBSD when set to 0ms, it's absolutely
incredible. Cannot detect latency whatsoever. The Mario jump sound seems
to happen at the very instant I hear my cherry blue keyswitch activate.

ruby/audio/oss.cpp

@@ -3,12 +3,7 @@
 #include <sys/ioctl.h>
 #include <sys/soundcard.h>
 
-//OSS4 soundcard.h includes below SNDCTL defines, but OSS3 does not
-//However, OSS4 soundcard.h does not reside in <sys/>
-//Therefore, attempt to manually define SNDCTL values if using OSS3 header
-//Note that if the defines below fail to work on any specific platform, one can point soundcard.h
-//above to the correct location for OSS4 (usually /usr/lib/oss/include/sys/soundcard.h)
-//Failing that, one can disable OSS4 ioctl calls inside init() and remove the below defines
+//OSSv4 features: define fallbacks for OSSv3 (where these ioctls are ignored)
 
 #ifndef SNDCTL_DSP_COOKEDMODE
   #define SNDCTL_DSP_COOKEDMODE _IOW('P', 30, int)
@@ -31,12 +26,14 @@ struct AudioOSS : Audio {
     string device = "/dev/dsp";
     bool synchronize = true;
     uint frequency = 48000;
+    uint latency = 60;
   } settings;
 
   auto cap(const string& name) -> bool {
     if(name == Audio::Device) return true;
     if(name == Audio::Synchronize) return true;
     if(name == Audio::Frequency) return true;
+    if(name == Audio::Latency) return true;
     return false;
   }
 
@@ -44,6 +41,7 @@ struct AudioOSS : Audio {
     if(name == Audio::Device) return settings.device;
     if(name == Audio::Synchronize) return settings.synchronize;
     if(name == Audio::Frequency) return settings.frequency;
+    if(name == Audio::Latency) return settings.latency;
     return {};
   }
 
@@ -66,6 +64,12 @@ struct AudioOSS : Audio {
       return true;
     }
 
+    if(name == Audio::Latency && value.is<uint>()) {
+      settings.latency = value.get<uint>();
+      if(device.fd >= 0) init();
+      return true;
+    }
+
     return false;
   }
 
@@ -81,13 +85,11 @@ struct AudioOSS : Audio {
     device.fd = open(settings.device, O_WRONLY, O_NONBLOCK);
     if(device.fd < 0) return false;
 
-    #if 1 //SOUND_VERSION >= 0x040000
-    //attempt to enable OSS4-specific features regardless of version
-    //OSS3 ioctl calls will silently fail, but sound will still work
-    int cooked = 1, policy = 4; //policy should be 0 - 10, lower = less latency, more CPU usage
+    int cooked = 1;
     ioctl(device.fd, SNDCTL_DSP_COOKEDMODE, &cooked);
+    //policy: 0 = minimum latency (higher CPU usage); 10 = maximum latency (lower CPU usage)
+    int policy = min(10, settings.latency / 20);  //note: latency measurement isn't exact
     ioctl(device.fd, SNDCTL_DSP_POLICY, &policy);
-    #endif
     int frequency = settings.frequency;
     ioctl(device.fd, SNDCTL_DSP_CHANNELS, &device.channels);
     ioctl(device.fd, SNDCTL_DSP_SETFMT, &device.format);