(eventually)
NEW NEWS
OLD NEWS
TODO
1.12.07Happy New Year!
So it seems San Francisco's got itself a cold weekend ahead of it. Good thing I've got an Intel P4 to keep the house warm! Seriously though, the weather's kinda' miserable right now, so I'm gonna' take that as an excuse to sit around and spend some quality time with the world's bestestest emu. It's, of course, got some stiff competition with the Bears and Chargers games this weekend, but I figure I'll be able to pull my hands out of the vat of beer and brats long enough to write a few lines of code.
Recently I've been busy relative to my normal lackadaisical MAME behavior. Still getting little done, but that's nothing new. I've put Polygonet Commanders on the back burner since SMF may be carrying the driver ahead. I'm not sure though - he expressed interest awhile back and hasn't mentioned it since. Honestly, it gives me an excuse to take a break from that driver again, so I'm happy.
Awhile back gregf (of MAMEworld fame) pointed me to a King Pin PCB for sale on ebay. I bought it, drove to pick it up, popped out the ROMs, sent 'em to a dumper here in the US, and gathered the results from the guy. Now I'm attempting to emulate the thing. It's been fun seeing it go from its discovery to where it is now.
The hardware isn't particularly complex. Two Z80's, a TMS9928 for video, and an AY-3-8912 for audio. All stuff that's well emulated in MAME. The trick is figuring out the oddball early-80's junk that glues it all together. So I've stripped a KingPin PCB, scanned it, and am now tracing it in an image editor. Luckily the leads are only on the surfaces of this board, so it's relatively simple. I'm halfway done, but then I need to figure what it all means :P.
To that end, I've been trying to teach myself how to read schematics. Things are making sense, but there are still a few vital points I'm missing. I'll get it eventually, but if anyone knows of a good tutorial online about the things, please feel free to share (e-mail is on the left, or I'm "drewcifer" on MAMEworld's boards).
And yeah, that last link was the other thing I'm messing around with. As per Aaron's call-to-arms about laserdisc games in MAME, I've taken it upon myself to try to get the Astron Belt hardware working. Aaron and a bunch of others are doing great things towards emulating those games in MAME, so stay tuned for some awesome updates in the near future.
Also, I don't know if you noticed, but things are just as exciting in MAME land as they've always been. A certain dumper has been working hard to dump a lot of old crappy boards, a certain founder has been cracking encryption schemes, and the regular devs are cranking out more stuff than I've seen in a long time. Congrats to all involved!
Now, back to the fun...
11.27.06
Well that took me long enough...
Wow. How long has it been? A couple of years I think. I've switched jobs and moved apartments twice since I started on this stinking driver, and now, finally, it's starting to do something. Still *tons* to do (and no time to do it), but heck, it's a start. I have to admit though, I made a big mistake awhile back: I purchased a Polygonet Commanders PCB. Man, that game stinks! Good thing it's of historical significance :P...
As far as the network error (in the network) goes, it should be fairly straightforward to fix up - there remain a hearty hunk of writes that aren't going anywhere, and who knows, maybe I can convince Arbee to take another look at this'shizzle after i touch up a few more unimplemented dsp56k opcodes...
03.19.06
BOMBSA!
After (finally) submitting my Psychic 5 blend chip changes, Reip pointed me to another game running on similar hardware to Argus, Valtric, and Butasan. It's called Bombs Away, and it looks to be a quaint 194x-style shooter. I've decoded most of the graphics, found a few bits of the palette, and have the text layer drawing quite nicely. No idea where the tilemaps are, nor the sprites - and the thing reboots after running for a few seconds, but there are still tons of other things to try so stuff may begin to look better, uh, someday :)...
09.28.05
More on the Psychic 5 / Argus blend chip. An anonymous helper pointed me to this website :
http://www.geocities.jp/oyabin4078/kiban/argus/argus.htm
Clearly showing that my implementation was lacking. From this wee tidbit of information, i was able to derive (with the help of someone who is familiar with similar blend chips) how the chip does its thing. I'm missing what a single bit does, but it may have something to do with overall intensity, and that's tough to check based on screen shots taken with various monitors at various gamma settings. Maybe I'll get a real PCB someday so as to do more verification or actually put the chip through its paces... Anyways, these are the Argus results :
And these are the Psychic 5 results. Heh. Please take note that the background shades are indeed purple, grey, and "young rose". All flowery descriptions aside, those were very helpful comments on the MAME message board. Thanks to mamef2 for pointing the color issues out! (also, please ignore the palette issues with the power up in the 3rd image - it's a savestate artifact)
I'm still missing one crucial piece of information before I wrap everything up and submit it though. In the Argus driver, there is code which is poised to change the background colors to purple and grey (just like in Psychic5). Can someone send me an INP for MAME 0.100 that takes me to a spot just *before* the screen changes one of these colors? That'd be great, as I'm not good enough at the thing to actually make the screen change. My e-mail's on the left, yo.
That's all for now... Thanks all!
09.18.05
First, I wanna' express my gratitude for being added to the mamedev.com links section. It's great to be recognized on the official page!
In news, I've nearly completely fixed all of the wires for my PCB's. Unfortunately (as seems to be the case on ebay so often), only one of the two untested but "promised working" boards appears to be good - and even then it's not 100% working. In my case, this may be a good thing, as I might learn something about the hardware from this failure, but remember everyone - don't trust anything on ebay that isn't tested and working 100%.
Anyways, at some point I'll get to working on that boardset.
In the meantime, Pierpaolo pointed me to the argus.c driver. He guessed it had similar palette behaviour as another Jaleco game I've reported on toying with lately - Psychic 5. His guess was correct, and now Argus, Butasan, and Valtric have a preliminary implementation of 'additive' blending :
This probably doesn't fix the Butasan bugs on mametesters.org, but I'm not sure as I haven't been able to reproduce them. It definately fixes a bunch of bugs not listed on Mametesters though, so it's a step in the right direction for sure...
I think I've also figured out that a palette value of 0xf in the blend chip means darkening instead of additive blending, but I still can't be sure without shots from a real PCB (Argus and Psychic 5 would be the most helpful).
In completely unrelated news, has anyone ever see the film "The Last Life in the Universe"? Man is that a good movie... Between that and "Crash" I've had an entertaining film weekend!
09.08.05
Hey all! I don't have anything very interesting to report these days - just that my guests from Sweden and I are having the usual Los Angeles good time... aaaaaaand I received a PCB that I've been eagerly awaiting!
Unfortunately the sizable wiring harness had been cut during the stripping of the original machine, so I've gotta' sort and solder a rats next of wires before I know if the boards are working or not, but that's all part of the fun ;).
I'm probably going to wait until another full release of MAME to clean and submit the Psychic 5 and hng64 additions I've mentioned recently, and I'll be busy with this hardware and my guests for awhile, but hopefully after I get this stuff running I'll be able to get back to the daily MAME.
Until then, then...
08.28.05
Going back to my roots, I've come dangerously close to implementing the 'linescroll' feature of the hng64. This enables the floor in fatal fury wild ambition! Pay close attention to the recognizable features on the floor (like the stars) as they're foreshortened by perspective effects.
fatf0003.jpg
fatf0004.jpg
fatf0013.jpg
The way the hng64 does this is pretty strange (but quite cool). Basically, they load up a 2048x2048 pixel tilemap and then sample it based on lines drawn through it. So if you wanted an orthographic projection of the tilemap, you'd ask for a line from [x,y] (0,0) to (2048,0), then a line from (0,1) to (2048,1), then one from (0,2) to (2048,2), and so on. If, instead, you wanted something interesting, you'd ask for lines calculated based on a perspective projection into the tilemap. You can then rotate the sample-lines to make the floor appear as it's rotating, or scale the sample-line lengths to make it look like the floor's moving further away.
Quite spiffy to be sure, but I can't figure out anything this would be used for except rendering planes... To give the hardware designers credit, it may have been necessary to include this specialized 'textured plane-drawer' since the hng64 polygon rasterizer is probably very slow when drawing large triangles. The rasterizer probably also messes up the textures pretty badly on large polys because of an assumed lack of perspective-correct texture mapping (?). Anyways, hopefully as we improve the emulation further, we'll see how other software uses it.
The implementation isn't complete yet - I'm ignoring 32 bits per [x,y] coordinate and my implementation fails miserably when the camera points down. I do think I'm onto something though, because when the players move around the groundplane moves and rotates correctly - it's just a matter of figuring out the finishing touches.
Oh, and in related news, I think I've figured out which video register controls the animation of the background tilemaps, but lack skill necessary to hook it up properly... Still learnin' :)!
08.23.05
Well look who's posting some screen shots :).
No, unfortunately they're not from Polygonet Commanders. After submitting my core, I've decided to take a Konami break - something I'm guessing many a mamedev has taken throughout history ;).
These screens come from a Jaleco game by the name of Psychic 5.
Andreas Thorsén put a shot of a real Psychic 5 PCB in action on his webpage, showing some limitations of the current MAME driver. Given some help from Reip and a suggestion from Bryan McPhail, I've begun to take cracks at what's causing the ailments. Additive blending has been implemented based on a previously-undocumented "alpha" value hidden in the bottom 4 bits of each palette entry, but it's not quite as clean as I would like. I'll need to examine things a little further... There also appear to be a few other issues with the driver, and Andreas has kindly offered to take more shots of his PCB as needed...
Before and after - preeeeety... (notice the strange outline around the main character disappears too)
To be honest, this is a very simple addition, but it's the first time I've actually looked at video hardware in MAME that isn't 3d, so it's been (and going to be) a good learning experience - I'm sure I'll need the help of Reip (AKA - the bug-squisher) to address some of the more technically interesting bugs, but that's what makes MAME such a great project - so many people with so much dedication :)...
Laters y'all.
08.01.05
The biggest computer graphics conference of the year, SIGGRAPH, is in full swing this week. I just gave my
brief talk-ette this evening and am now free to enjoy the conference sans stress! If you happen to be at the
conference, look for a guy walking around with an Andrew Gardner name tag - chances are he'll be groggy, but
he'll say "hi" nonetheless :)...Since I've been busy preparing for SIGGy, I haven't had much time for MAME'in. The little bit of time I did have, I confirmed a lot of suspicions I had about the dsp56k's host interface. Heh, I know, I said I might take a break, but, well, it's really not my style to let loose ends remain loose. That personality trait of mine is both a curse and a blessing, I assure you ;)...
Anyways, I now have a pretty solid grasp of what the 68020 is trying to say to the dsp, and how the dsp is capable of receiving it. The puzzle pieces are dropping into place at a decent clip these days, and i hope, once i actually figure out how to make the processor do a 'software reset' with a reset vector, I'll have all of the first memory tests licked. Then it's onto the mysterious 4th test. I've got some guesses as to why this isn't going anywhere yet, and once I have some time I hope to see how my guesses fare... But that's it for now - time for some sleep...
Oh, and how about those MAME devs and the Deco156, eh? Chalk another one up to the euro-squad :)...
07.25.05
Seems pleasant enough, doesn't it? Turns out this quote from a Motorola manual I found is pretty much true. Upon
first glance, the floating point arithmetic done on the DSP56k series of processor, dubbed
"Two's-complement fractional," seemed a bit tricky. A Zilog and Motorola manual
later, and I was a master of the (embarrassingly simple) shift left necessary
to do math on the DSP56156.What does this mean to MAME? It means yesterday, after getting back from an awesome AVP tournament (it's always amazing seeing professional athletes up close - makes you realize how good they are at what they do), I was able to spend some time making the second (and third) memory test work in Polygonet Commanders! In my newby opinion, I've found the memory tests for the hardware to be pretty interesting. It's probably more fun discovering what the people who write memory tests do than it is writing the tests themselves, but who knows, maybe there's some sadistic joy to be had in writing particularly mean memory tests for hardware :).
Anyways, a quick rundown of Polygonet Commanders' tests is as such: During the first test the 68020 writes to a piece of memory shared between the two processors and reads it back itself. The second test involves the dsp56156 writing to the same piece of memory, and then letting the 68020 read it back, checking to make sure it's correct. The third test has the 68020 write to a piece of memory, the dsp56156 read it out, perform a bit of math on it, and write the new bits back to the same memory for the 68020 to read again. All of this works very well so far. The fourth test, however, is where I'm stuck...
As one might guess from the above progression, during the fourth test, the dsp56156 nabs even more responsibility. So far, I can watch the dsp code write a lot of haphazard values to memory (both shared and otherwise), overwriting certain bits, and making a big mess of things. It then goes back and checks the memory it wrote to see if everything is in good shape, and unfortunately, at the moment, it's not. I have a sneaking suspicion that the 68020 is supposed to intervene here and there and fix up the dsp56k's mess. I'm hopeful of this hypothesis since the dsp56156 sends a lot of data across a Tx/Rx line during test #4 (presumably to the 68020). Barring any (expected) bugs in my opcodes, I'm thinking I need to get these kids communicating before I can go much further.
The driver's currently written with enough information to kludge together a set of base communications between the two chips. Of course, I really should get true communications hooked up between the two devices, but for now I'm interested in seeing the two run hand in hand without recompiling a special version for each memory test - that'd totally make my day :). Unfortunately, this is where my inexperience with MAME is going to slow me down a bunch. Heh, maybe this is a good thing, but I haven't been MAME'ing enough to even know how to hack the driver to force its processor to jump to a certain opcode at a given time :)! Actually, I'm pretty sure you can't do that in MAME (sounds really [really] ugly if you can), but IRQ's would be a good way to make this work. My next task, therefore, is to figure out the way IRQ's (other than the RESET one) work in MAME.
So that's news in dsp56k-land. I may take a small break from the dsp56156 core to let things settle in my mind. I'll probably clean stuff up a bit and update it to a recent version of MAME too. In the meantime, I'm thinking of adding comments to Aaron's new debugger (see this thread - I'm tellin' ya', I'm incapable of typing a short blurb on anything :P), and possibly trying to start a driver from (near) scratch. I haven't done that yet, and I figure it'll teach me more about MAME and more about the behaviour of hardware in general.
Anyways, that's all for tonight. Type at y'all later!
07.24.05
I re-arranged the posts in order of posting. Seems like it makes more sense that way.
07.15.05
So back in something, like, January, I begged and pleaded with R. Belmont to let me work on a MAME CPU core. He eventually gave in, and let me work on Freescale Semiconductor's most feared processor (not really) - the DSP56156. And what did I do to repay him? I disappeared for 6 months :)! Heh, stay away from real life kids - it's nuts out there...
Anyways, here's a little background about chip I chose to MAME :
The Motorola (now Freescale Semiconductor - Motorola owned them at the time) DSP56k series of processor is a strange beast in many ways... Nothing too crazy - variable length opcodes, strange decoding criteria, a few addressing modes, but honestly nothing to offer too much opposition for the would-be conqueror... To save you the trouble of guessing why I'd be writing a CPU core for such a thing (and why I'd mention R. Belmont and his infinite benevolence), here's the system16 link to the arcade games that use it : Konami's Polygonet Hardware.
Polygonet Commanders is currently in MAME as a non-working driver and Belmont's got the sound hooked up and some hacks to get the thing to pass its memory tests. Then it stops ticking... I haven't looked at why it stops working yet, but I'm guessing it has something to do with the giant hole where a DSP56156 CPU core should be! Anyways, to my knowledge, the other game on the hardware, Poly-Net Warriors, has not been dumped (I'd be impressed if someone out there has even seen it in person), so it looks like it's just me and Polygonet. If anyone knows of any other interesting things that use a DSP56156 (so I can bug-squish the core some more) - feel free to mail me - I'll pass your knowledge on via this page and hopefully enhance the core using it...
But here's the news : last night I finally managed to make the first real strides towards a truly working DSP56156 core in MAME. I removed a single memory-test hack Belmont put into the polygonet driver. Basically, the 68020 used to send a message to a nonexistent DSP56156. This message went nowhere, but Arbee knew the message was going to result in the DSP56156 filling a portion of memory with some simple values, and instead filled the proper piece of memory (using hard-coded C) with data the 68020 was expecting. Now, when the 68020 sends that message, it gets received (via a communications hack I put in :P) by the DSP56k core and it whirrs up, runs a few dozen opcodes, and fills the memory with the proper information!
Now this may not seem all that interesting, and I can't show cool screen shots to back up the work, but rest assured, I'm totally stoked over the fact that my DSP56156 is running in tandem with a 68020, and they're actually getting along :)...
So yeah, exciting stuff, eh? I sure think so!
Next on the todo list is to get the second memory test un-hacked. This is going to be a lot trickier though, as I'm going to need to do some arithmetic on the chip, and it seems to have a somewhat strange way of handling math in its 40-bit accumulator buffers.
Anyways, that's all for now... Since there is actually a glimmer of hope for this project, I'm gonna' submit something to MAMEDev shortly. The code is far from complete, but I hope to work on it until it's as complete as it can be...
Later days, y'all!
Andrew
07.10.05
Hey all y'all cats and kittens...
So after a hiatus of way too long, I'm back, verbose as ever, and itchin' to MAME everything in sight (hide your children).
Twisty of MAMEWorld fame has been extremely kind in allowing me to transfer my base of operations from Yahoo's Geocities (http://www.geocities.com/chowderq) to this super-rad MAMEWorld url... Here's to hoping that I'll be keeping it warm more this time around...
Before I get started, let me preface the drivel you're going to read on this page by stating that I'm no hardware guru - I'm a 3d guy (and not the slightest bit guru'ish at that either). This MAME stuff, however, has captivated me for years now and it's just so much darn fun to finally understand enough about computers and hackery in general to finally be able to contribute! The things I'm gonna' say on this page are probably pretty remedial to a lot of the people who currently work on MAME, but that's one of the reasons I wanted to write here - to talk from the perspective of someone who's learning about everything from the ground-up. So expect me to sound silly an awful lot - it's certainly happened before ;)...
(did I happen to mention that I like to type? A lot? ;) )
Also, before I get started, I wanted to thank Haze for taking the time to guide me through things in the beginning, Aaron for doing amazing stuff every day, Bryan for the kind words when I was working on hng64, OG for listening to me blab about Model 1, and Belmont for always typing something interesting to read :P... Okay, now to tell you what I'm up to...