Devtalk: Musings on the DSP (and 1.0.6)

[Shamus]

Things have been quiet on the development front lately, so I though I'd share some thoughts on what I've been up to...

So there I was, minding my own business, when Wolfenstein 3D presented me the following DSP code:

F1B248: MOVEI  #$00F1A100, R01
F1B24E: STORE  R00, (R01)
F1B250: JUMP   T, (R03)
F1B252: NOP

What this little bit of innocuous code does is end the interrupt that it was servicing (in this case, the SSI interrupt). However, unlike what the JTRM recommends, they alter the DSP_FLAGS register before they jump back. What is the problem with this? The main problem is that REGPAGE gets written to on the STORE instruction and so R03 has the wrong address to jump back to when its chance to execute comes up. Egad! Code that depends on pipeline effects!

I tried to think of a simple way to fix this without wrecking other DSP code, and there doesn't seem to be one. If anyone comes up with a simple way to fix this without using a pipelined core, feel free to send a patch.

So anyway, to make a long story short, I tried pipelines with various numbers of stages (4, 3, then 2) and found the optimal number of pipeline stages to be 3. So now I've been going through the DSP code and fixing problems wherever they manifest themselves, but it's been slow going. Pipelines are tricky things to emulate!

So what does this have to do with 1.0.6? Well, it seems that it might be a while before all the kinks are ironed out of the pipelined DSP core, but the changes that have been made up to this point elsewhere (OpenGL, config file, etc.) are important enough to warrant a release. The old DSP core is still there, and it still works the same old (wrong) way that it did before, so it wouldn't be all that difficult to put it out there...

[Shamus]

Quick progress report: Wolfenstein is working properly now, although Rayman and Doom aren't...

Time to do some more digging...

[Shamus]

More progress... Now Wolf3D, Rayman, and the BIOS are working with the new DSP!

Doom is still not working though...

A few other things to mention--the config file will support paths and all the command line switch options, so it's getting to the point where you can just run it and it will do something useful... Should be helpful, especially for the newbies.

[nwagenaar]

This looks very promising. Sorry for the communication-silence but I was sick again

But back to ontopic. This looks *very* promising! While I reccon that a pipelined core is somewhat slower it also means more compatiblity at the end (I hope ) and that's one thing we should focus on!

BTW, concerning your sdlemu related contributions. OpenGL rendering needs no resizing. It does that automaticly when you render the backend into the framebuffer If you just make you framebuffer (ie : the window) larger in size it will automaticly resize the original backbuffer to the size of the window. You just gotta love OpenGL

Oh, did you get the e-mail I send you how to upload the images on the sdlemu FTP? You askes for this before I was sick and I think I replyed it... I think.... Yep, according to my sent items I did

[Shamus]

Sorry to hear that you were sick again. And yep, I got your email. I think there will be announcement on SDLEmu soon, now that Doom is working again (as well as the rest)...

The pipelined core is a lot slower than the old core, but I expect that optimizations should take care of that. Yes, you're right--compatibility is the name of the game. We can always add speed later.

As far as the OpenGL goes, I think it does need the resizing code (unless I'm totally missing something, which could be the case!). If you look at the pix on the VJ homepage, you'll see that all the screens are 320 x 240. The thing is that the pixel widths on various games are not uniform, but they all have to fit into that 320 pixel scanline width.

Clear as mud? Yeah, let me explain.

On a real Jaguar, it renders its line buffer into a TV scanline of a fixed width. What the pixel width does is tell the video hardware how quickly (or slowly) to tell the CRT's electron beam to change to the next pixel. Because the size of the TV scanline is fixed, this causes the pixels displayed to range in size (in technical terms) from skinny to fat. So when the pixel width is 1, the video hardware changes to the next pixel on each tick of the horizontal counter (skinny pixels) while when the pixel width is 8, the video hardware doesn't change to the next pixel until the horizontal counter goes through 8 ticks (fat pixels). The interesting thing about a pixel width of 4 is that they generate pixels that are "nearly square" (according to the JTRM, that is). What this means is that any pixel width smaller than 4 will look horizontally compressed and any greater than 4 will look horizontally expanded.

What VJ does now is simulate the fixed strip of screen real estate that the real Jaguar has to render its line buffer to. I've arbitrarily chosen a 320 pixel width to represent this visible TV screen scanline (I could have chosen any number, but it works well with the common pixel width of 4). It uses OpenGL to horizontally squeeze/expand the line buffers to fit into that fixed size scanline (otherwise, we'd have to do it using software interpolation).

So, resizing the OpenGL texture is necessary, since the size of our horizontal window is fixed. We can, of course, resize this window (which is what VJ does now with the OpenGL support) to any size we want in order to shrink/expand the entire simulated TV screen. I think we can even use fractional sizes as well (1.5 x 1.5 scaling, anyone?)...

At any rate, I've just updated CVS and if it works for you, I'll tag it as VJ_1_0_6 and roll some tarballs...