Page 1 of 3
Wolf32X - finally in beta!
Posted: Tue Feb 17, 2009 4:16 am
by Chilly Willy
Okay, after a LOT of work, here's beta 1 of Wolf32X. I completely reworked the "file" handling so that everything is in ROM, with no memory allocated other than static arrays used for things that change. No more memory corruption! This also slimmed things down a bit - Wolf32X now has 19 M Power!! That's 2.5 MB for those of us that laugh at the Mbit unit.
The other major addition is working digital sound - this is fully tested on a real 32X. The sound is great and doesn't slow the game at all. I'll probably take a break before working on FM audio.
As usual, all the source is included. That includes the new unpacker I wrote to fully process the data files. It should work on the Wolf3D full files, as well as Spear of Doom shareware and full files. If there's a call for it, I'll compile a version of the SOD shareware.
EDIT: Went ahead and compiled SOD Shareware. The second link has BOTH Wolf3d and SOD Shareware.
EDIT 2009-02-21: Minor update - fixed six button controller support. Thanks to snake for the help!
EDIT 2009-03-09: Major update! Added FM sound effects and Load/Save!
EDIT 2009-03-11: Added auto-map. Read the new readme file for details.
EDIT 2009-06-07: Added mouse support.
Wolf32X-b1.zip
w3d-sod-sw-b1.zip
w3d-sod-sw-b2.zip
w3d-sod-sw-b3.zip
w3d-sod-sw-b4.zip
w3d-sod-sw-b5.zip
Oh, here's the "official" test platform.
Posted: Tue Feb 17, 2009 8:54 am
by devzone
Nice work chilly, ive just downloaded it and will try it out later today
Cheers
Posted: Tue Feb 17, 2009 11:12 am
by TmEE co.(TM)
Posted: Tue Feb 17, 2009 11:40 am
by Chilly Willy
Good to see separate confirmation it's working.
That's why mine is hidden in the cart.
Posted: Tue Feb 17, 2009 5:08 pm
by Huge
Not counting potential bugs, the only improvements I can imagine are FM sound, 6 button support, and potential speed optimizations. Extremely impressive job.
Posted: Tue Feb 17, 2009 9:40 pm
by Chilly Willy
It has 6 button support in it which works with Gens/GS. Not sure what is the deal with real hardware... gotta make a test app to print out what I'm getting back from my pad to see where it's going wrong.
Posted: Wed Feb 18, 2009 8:46 am
by Eke
this is really impressive job
about 6 button support, do you use the same routine as in official games ?
I think there need to be a delay between TH transitions, Gens (and most emulators) immediately swap the returned button values as soon as TH state is changed.
Also, in Gens, the TH cycle counter is reseted at the start of each line AND when a bus request is issued...
On real hardware, this would mean the pad logic resets its internal state if TH has not changed after a certain amount of time, you probably have to deal with timings here...
Posted: Wed Feb 18, 2009 9:36 am
by Chilly Willy
Eke wrote:this is really impressive job
about 6 button support, do you use the same routine as in official games ?
I think there need to be a delay between TH transitions, Gens (and most emulators) immediately swap the returned button values as soon as TH state is changed.
Also, in Gens, the TH cycle counter is reseted at the start of each line AND when a bus request is issued...
On real hardware, this would mean the pad logic resets its internal state if TH has not changed after a certain amount of time, you probably have to deal with timings here...
I didn't use the SEGA code. I used something simplified, but should work. Seriously, I never believed it was that strict as I had no trouble at all making 6 buttons sticks work on the Amiga. What's REALLY weird is that the six button code doesn't work on Kega Fusion - I'd REALLY like to know why that fails. timing shouldn't really be a consideration at all on emulators. It's not like two nops instead of three makes ANY difference to an emu.
Posted: Wed Feb 18, 2009 10:05 am
by Shiru
Always greet to see new software for old systems, though I'd like to see version of this game for SMD, not 32X (it has Doom already).
About the music:
Chilly Willy wrote:Well, I'm going to try the "standard" fmopl emulation code and see if the slave SH2 can handle it.
This game uses MIDI files. Isn't simple YM2612 MIDI player on SMD side will be much simpler to do than handle OPL emulation?
Posted: Wed Feb 18, 2009 10:14 am
by Huge
I'd think it is easier to "port" the adlib opl tunes to the ym2612, but emulating the OPL as a whole is probably MUCH less hassle.
Posted: Wed Feb 18, 2009 12:37 pm
by Chilly Willy
Shiru wrote:Always greet to see new software for old systems, though I'd like to see version of this game for SMD, not 32X (it has Doom already).
About the music:
Chilly Willy wrote:Well, I'm going to try the "standard" fmopl emulation code and see if the slave SH2 can handle it.
This game uses MIDI files. Isn't simple YM2612 MIDI player on SMD side will be much simpler to do than handle OPL emulation?
No, it doesn't use MIDI. It uses an array of OPL register writes as the music. Here's the main loop that plays the music:
Code: Select all
while (MusicCount <= 0) {
dat = *MusicData++;
MusicCount = *MusicData++;
MusicLength -= 4;
OPLWrite(OPL, dat & 0xFF, dat >> 8);
}
But the SH2 really isn't powerful enough to use the "regular" YM3812 emulation. It would have to be something written in assembly with shortcuts all over the place. I don't feel like doing that. I'm thinking of trying to use the 2612 to simulate the 3812.
Another approach would be to actually use tracker files and ignore the OPL music altogether.
By the way, the game uses about 180 KB of bss space. Even if you take out the graphics buffer, that's still more than twice the total ram in the MD. There's no way you can do Wolf3D on the MD without gutting the level data to toss out enough to get it into 64 KB of ram.
The stats on Wolf32X were:
~115 KB code (which is in the rom)
~14 KB of data (copied from rom to ram)
~180 KB of bss
The rest of the rom image is static data left in the rom and the uncompressed data from the files. The code and static data in the rom is not a problem with a MD version of W3D. The data copied to ram could probably be pruned a little, but the bss is the killer. 16 KB is used to store the level info. 64 KB is used to store the frame buffer drawn into (this could be worked around), and the bulk of the rest is storing object and actor info for the stuff that populates the level.
I might take a crack at it later, but right now I'm more interested to see if I can get it to run on the CD. The big problem with running it on the CD is storing all the texture data in ram. We just can't dump it all in the rom - there isn't one. Actually, now that I think about it. The IDEAL way to do Wolf3D and Doom would be a combination of cart and CD: have all the textures and junk like that in the cart, and load the level data from the files off the CD.
Posted: Wed Feb 18, 2009 8:46 pm
by Shiru
Chilly Willy wrote:No, it doesn't use MIDI.
What's
this then? It copyrighted by original author, does not look like remake.
Chilly Willy wrote:By the way, the game uses about 180 KB of bss space. Even if you take out the graphics buffer, that's still more than twice the total ram in the MD.
I'm sure, good direct port of original code to SMD isn't possible, it probably require completely new engine to achieve good results.
Posted: Wed Feb 18, 2009 9:29 pm
by Chilly Willy
Those are probably from something like the Apple version. They're certainly not part of the original file set.
The digital sound effects are in the vswap file. The synth sound effects and music are in the audiot file. There is no midi in either one. That's why most open source conversions of Wolf3D don't have any music. It's only recently that the FMOPL emulation was taken from MAME to use in new conversions to play the synth effects and music.
The source for the Apple version was never released, so it's rare that you find a conversion using the Apple version files. Those files would be better for a MD version since they're also especially designed for 16 color systems with low memory as well.
Posted: Thu Feb 19, 2009 12:50 am
by tomaitheous
Shiru wrote:
I'm sure, good direct port of original code to SMD isn't possible, it probably require completely new engine to achieve good results.
Like what they did on a stock SNES (the wolf3D port).
Posted: Thu Feb 19, 2009 1:41 am
by Chilly Willy
tomaitheous wrote:Shiru wrote:
I'm sure, good direct port of original code to SMD isn't possible, it probably require completely new engine to achieve good results.
Like what they did on a stock SNES (the wolf3D port).
Exactly. There are times when "ports" are really just entirely new games with (remotely) similar graphics and game play.
