Small update to Wolf32X

Announce (tech) demos or games releases

Moderator: Mask of Destiny

Post Reply
Chilly Willy
Very interested
Posts: 2791
Joined: Fri Aug 17, 2007 9:33 pm

Small update to Wolf32X

Post by Chilly Willy » Thu Jun 26, 2014 9:56 pm

Okay, I just updated my 32X toolchain and took the opportunity to bump the sample rate from 14kHz (two times the Wolf3D digital sample rate) to 21kHz (three times the rate). This should cure any squealing a few folks reported. That is the only change for this version... except for one other thing. If you look in the archive, you'll find files with the .32X extension, and ones with the .bin extension. The .32X files are regular old Wolf3D/SOD with the changes sample rate. The .bin file have a new experimental DMA transfer for the display.

The way Wolf3D works is it does the game logic, renders the screen, and loops. Part of rendering the screen is transferring it from the off-screen buffer to the frame buffer. That was done by copying the data with the processor. In the .bin files, I now start an asynchronous DMA operation to copy the memory to the frame buffer, and return back to the loop. What this means is the game can get busy on the next tick worth of game logic while the DMA actually copies the display to the frame buffer. When the DMA is done, an interrupt sets a flag so that if the game logic finishes before the DMA is done, it will wait before drawing the next frame. The game feels smoother to me, especially SOD.

I call it experimental because I've only tried it on my system. Please try this on yours and report how it works (or doesn't as the case may be). As always, the full source is included. It's a good resource for seeing how to do mem-to-mem DMA with the SH2.

Wolf32X-20140626

Chilly Willy
Very interested
Posts: 2791
Joined: Fri Aug 17, 2007 9:33 pm

Post by Chilly Willy » Thu Jul 10, 2014 8:22 am

Okay, this is perhaps the last update to the old base code. My TV broke yesterday, so I have a little more free time and decided to work on Wolf32X. Gasega68k sent me his TFC format FM music for Wolf3D, so I added TFC playback (via the 68000). If you put an audio CD in the SCD, it'll try to play the tracks from it, but if you don't have a disc in it, or don't have a SCD at all, it now plays FM music. Everybody be sure to thank gasega68k for sharing the files. These are Wolf3D music files, so Spear of Destiny will also be playing Wolf3D music. Don't know if gasega68k plans to work on SoD or not. Maybe after he finishes Wolf3D.

I made a few improvements to the Mode 1 CD support so that it now plays the intro tune if you have the CD in to start with. I also changed where it checks for the CD as that was interfering with the FM playback. You can still put a CD in at any time, but it should be better behaved.

While fixing an issue with save ram writing/reading while using the DMA video updates, I also took the time to add compression to the saves. I found a nice simple BSD licensed C implementation of lz77. It takes just under a minute to compress the secret level on the highest difficulty setting - while it's saving, just let it sit at the "Saving.." notice until it finishes. If I want a ticker, I'm going to have to add it to the 68K side as the 32X is busy compressing during that time. Decompression during load is almost instant, so no problems there. Since the save is now compressed, I also save the auto-map, so if you reload in the middle of a level, your map is now restored as well. I need to check how big the compressed saves are - I might be able to support multiple saves now... not sure yet. For now, you get one save. This was mainly for MegaEverdrive/EverdriveMD owners as you get a max of 32KB of save ram on them, which isn't enough for the two higher difficulty settings without compressing the save.

Technical note - I use the 68000 to play the FM music for two reasons: first, the 68000 isn't doing much... checking the pads/mouse every vblank, reading/writing the save ram (if asked to by the 32X), asking the CD to play a CDDA track... that sort of thing. Second, you really can't use the z80 - the z80 cannot read the MD work ram, and can cause problems if you aren't careful about reading the cart. It's a pain, so using the 68000 is much easier.

http://www.mediafire.com/download/dq362 ... 0140710.7z

Chilly Willy
Very interested
Posts: 2791
Joined: Fri Aug 17, 2007 9:33 pm

Post by Chilly Willy » Fri Jul 11, 2014 10:57 pm

Okay, one more update - I've lowered the quality of the compression to make it reasonable in terms of time spent compressing. It's now about 15 seconds to compress instead of a minute. After checking the size of a few compressed saves, I've added support for two save slots. I could have made it three, but I wanted to error on the side of caution as far as space for compressed saves go.

http://www.mediafire.com/download/fmzh9 ... 0140711.7z

Chilly Willy
Very interested
Posts: 2791
Joined: Fri Aug 17, 2007 9:33 pm

Post by Chilly Willy » Sat Jul 12, 2014 11:44 pm

You can tell I haven't gotten my TV yet - here's another update. This is a really minor update, but should help make the speed more consistent. If you remember, I started updating the frame buffer via DMA. Well, I noticed I was just using LONG size DMA transfers. So what? So the SDRAM is HARDWIRED for burst reads. That means that any time you ask for ANY amount of data, it reads 8 words in 12 cycles. Ask for a byte, it reads 8 words. Ask for a word, it reads 8 words. Ask for a long, it reads 8 words. You get the idea. Anywho, that's fine with the CPU as 8 words is a cache line, and that is indeed what burst reading is doing - it's giving you the entire cache line that would cover the data you asked for.

The problem is when you read uncached memory, or use the DMA. In those cases, the cache is not involved. However, you STILL have to put up with the SDRAM reading 8 words. It's HARDWIRED to ALWAYS do burst reads. So if you read a byte/word/long from uncached ram, or DMA a byte/word/long from the ram, the ram still fetches 8 words, tossing the others in the trash, as it were. So using the DMA with byte, word, or long size units causes extra bus activity. It's no big deal for audio as you're asking for one long each sample. The other six words fetched are wasted, but at audio sample rates, that's no big deal. It IS a big deal when you're DMAing 16000 longs every frame!

There's one last transfer size the DMA can use... can you guess what it is? How about 16 byte units? If you DMA data on 16 byte alignments in 16 byte units, the DMA unit can use burst reads to fetch all 16 bytes at once. So I just make sure the screen buffer is 16 byte aligned, set the DMA to 16 byte size, and PRESTO! One fourth as much bus activity. That leaves more time for the CPU to read/write data from/to sdram, or read instructions from sdram.

So here's the new archive (bins and code as usual):
http://www.mediafire.com/download/5rpab ... 0140712.7z

Rob55Levo
Newbie
Posts: 9
Joined: Sun Apr 06, 2014 10:06 pm

Post by Rob55Levo » Sat Aug 09, 2014 9:57 am

Just thought I would show you these chilly for the hell of it, little bit of photoshop...(I didn't realise the game was just the shareware versions at the time) Any plans to do the other levels?

http://i61.tinypic.com/21ccxu0.jpg

http://i57.tinypic.com/2ptukjq.jpg

Chilly Willy
Very interested
Posts: 2791
Joined: Fri Aug 17, 2007 9:33 pm

Post by Chilly Willy » Sat Aug 09, 2014 10:02 pm

Later this month, I should have it updated to the Wolf4SDL 1.8 core. That should allow users to bundle the commercial files with the executable for the whole thing.

Rob55Levo
Newbie
Posts: 9
Joined: Sun Apr 06, 2014 10:06 pm

Post by Rob55Levo » Sun Sep 14, 2014 5:40 pm

Sweet, Look forward to it...

Chilly Willy
Very interested
Posts: 2791
Joined: Fri Aug 17, 2007 9:33 pm

Post by Chilly Willy » Mon Sep 15, 2014 12:05 am

I'm running behind on that update - my dad had back surgery (much sooner than we thought), so helping out while he recovers is taking more of my free time.

Post Reply