(eventually)
NEW NEWS
OLD NEWS
TODO
QSound - worth the wait.
Remember the last post below? The one where Dr. Decap decapped a mystery chip? Well, as noted on his blog shortly after (which now appears to have departed), it was the QSound chip, found in nearly every CPS2 game and a handful of others (zn.c & cps1.c).
QSound is a chip capable of spatializing sound samples in a 3d manner. To do this, a Head Related Transfer Function is run on the sounds as they are played. In the QSound chip, this function is executed by an on-die AT&T DSP16A CPU, currently unemulated in MAME (its CPU core is only a disassembler). MAME's QSound emulation already plays audio samples, but not in their fully-spatialized awesomeness, so to get the full QSound experience we need to emulate the DSP16A so it can run its internal program on the samples. As with many of these decaps, the HRTF program was locked away in the QSound chip. Two years ago, the doc photographed it, and things began to unfold.
The doc's photos were decent, and after some work by s_bastian, the monkeys sprung into action. All the bits were typed up within a couple of weeks, and we had ourselves a bit pattern. Problem was, this one was very difficult to decode. I tried and failed (twice), and every few months I'd prod other devs to see if they were up to the challenge. At least one of them found it really difficult as well. But then, near the end of 2012, Quench (as with a lot of other decap decodings) saved the day, giving us a proper decode. And here we are...
A good deal of work remains before the QSound DSP16 HRTF algorithm runs in MAME, but we're on our way. The DSP16A CPU core needs its opcodes implemented so it can run the software us monkeys typed up, and the glue logic inside the QSound chip will need to be figured out as well. Adding to the challenge, a few difficult regions of the decap photos mean a few opcodes might be wrong, and given that this is the only dump we have of DSP16A software (unless someone out there finds additional software?), it will be a challenge to make work correctly.
All-in-all this is great new for QSound fans! Thanks to Quench, hopefully now it will just be a matter of time before the DSP16A in the QSound chip runs its proper HRTF algorithm on the sound samples. MAME 0.148 contains a few opcodes for the DSP16 CPU core, and more will be forthcoming. Keep an eye on the whatsnew.txt for work on the DSP16A CPU core. The better this core gets, the more potential MAME has for emulating the QSound chip properly. I'll do my best to report any successes (big or small) we might have along the way.
1.21.11
More decapping news.
The last chip Dr. Decapitator expertly decapped was the BSMT2000. s_bastian's typing tool was used by the following mameworld members to type 65,536 bits 3 times each:
amarok, angrylion, Armatic, ASI, bdam, BrianT, Canim, casper, ChuKy, Cpt. Pugwash, DarylC, Dr. Spankenstein, drewcifer, fireinthehole, franciscohs, Fungo, john666, Klez, Layne, leniad, Lord_Nightmare, Malice, MAMu_, MASH, mitice, MonkeyEgg, MrDuncanM, NaokiS, niiiih, Osso, Qun Mang, Rad R, real, SothoTalKer, superultrahyper, s_bastian, TAZ-NZ, Various For, Warpath0007, Xiaou2, x_wins, Zer0
Decoding the ROM was very challenging this time around. Numerous people, myself included, have looked at it for a good chunk of time, but have gotten nowhere. Earlier this week, Quench, with some expert suggestions from Dr. Decapitator, figured it out! It was especially tricky since some bits were burned 'forward' and some 'backward' in alternating patterns.
Quench fully decoded the ROM and handed it to Aaron, who hooked it up to the BSMT2000 device in MAME. The emulation of Brian Schmidt's classic sound chip should now work in MAME 100% as it originally did. If there are any bugs, please report them on MAMETesters after the next u release.
In related news, the doc just photographed another sound chip. This one is used by dozens of games, and is only partially emulated in MAME. I'm in the process of stitching the new set of images together, and will hand it over to s_bastian when it's done. Stay tuned to the mameworld news board for further announcements!
1.3.11
BamBan.
A few months ago, Pete Ogoun decapsulated a MCU from the game BanBam. The images were very crisp and clear, and it took less than an hour to stitch them together. Phil Bennett reminded me that Nicola and Ernesto had previously decoded the same type of MCU, so the knowledge about how to convert typed-in bits to bytes was already in our archives.
Meanwhile, s_bastian on the mameworld boards was busy configuring his online data entry tool to get some help from the masses. He completed some new features on his tool, and the following users typed in all of the bits from the photographed ROM:
etabeta
robiza
Frankie
Gonario
sev
bernoulli
mrdriller
Zer0
BrianT
MASH
Stick
MooglyGuy
Mosquito2001
TE
bdam
s_bastian
Armed with the redundant data from the typing project, it was confirmed that Phil and I had typed a few bits incorrectly. I fixed these bits in the dump, ran Ernesto's decoder on the bits, stuffed the ROMs into MAME, and let the MCU rip. The disassembly appeared quite nice; the code traced well, and there did not appear to be any questionable instructions.
The MCU was, however, very difficult to hook up to BanBam. I had made some good headway into figuring out how the MCU was connected, when Phil discovered the same MCU was very likely used in Arabian. Luckily, we have the schematics for that.
The schematics turned out to be mostly legible and correct, and Phil successfully hooked BanBam's MCU into Arabian. This appears to work 100% and is documented in the whatsnew.txt for MAME 0.141. Hooking the MCU into the Arabian driver was somewhat convoluted though, so it isn't much of a surprise to us that we haven't quite succeeded with the BanBam hookup yet. It will come in due time, and we will likely be able to close the book on the BanBam MCU sometime in the not-so-distant future.
12.28.10
MC Ewe.
A few months ago, Phil Bennett took it upon himself to tackle the Kaneko MCUs Dr. Decapitator photographed and gave to MAMEDev. I'm as good as the next guy at typing in bits, so I offered to help. The doc's images were nice, allowing us to type in all the data in a short amount of time. Phil figured out how to convert the bits to bytes, and quickly got DJ Boy to talk to the newly-typed-in (dumped) MCU.
Often times, looking at the disassembly of a ROM gives a person a pretty good sense of the quality of what we have typed. Things were looking good, but there were a few errors. A little bit twiddling fixed these errors, but looking back at the original die images made us very concerned - sometimes the disassembly made Phil sure a bit should be a 1, but the die image was subtly blurry, and we both typed in a 0. Because of this, we asked for another set of images of the DJ Boy MCU from the Doc, and he very graciously gave us a higher magnification level. This new set of images was so good, it was no problem typing the whole ROM in again, and Phil hooked it up quickly and effectively.
We had the same situation going on with the MCU in Heavy Unit. The doc's images were good, but not amazing. We typed them in, but asked for higher magnification images, knowing there may be some issues. Just the other day, the Doc sent us those higher resolution images. Phil typed in the images (I didn't finish my typing), fixed a couple of bits we had improperly typed with the lower-resolution images, and hooked up the MCU.
The results should show up in the next release of MAME. In the meantime, David Haywood was kind enough to test out the emulation and record a video of MAME running the game Heavy Unit.
There is also a set of images posted on MAMEWorld here showing the very cool progress : link.
So in conclusion, this post is mainly to assert I'm still alive, but it's also meant as a preview of another set of MCU-related work Phil (and a tiny bit by myself) have done. I'll post more on that around the next release of MAME, but it's related to the MCU the "typing monkey" project was working on many months ago! Plenty of cool stuff happening these days!
3.30.10
Slowin it down.
Last release cycle I changed the lighting from a lame additive model to a more reasonable one. It seems like I might have even gotten the intensity correct.
I've also been playing around with a debug menu in Roads Edge. It doesn't really do much, but it does highlight the fact that the hng64's 3d subsystem is in a delicate state. As soon as I popped up the debug menu, the video timing changed ever so slightly, making all of the cars' colors correct. This is kind of annoying, since it means the color problem I was attempting to track down isn't a color problem at all; it's likely a display list / missing geometry problem. I'm also guessing a number of other problems are related to this same missing geometry issue.
I've begun the task of fixing the missing geometry a couple of times. This requires tracing the MIPS code and various things other MAMEDev are way better at than me. Each of my attempts have resulted in mild disillusionment due to a lack of time and expertise. Unfortunately this means things have slowed down considerably.
It's not like all hope is lost (especially if I can convince convince a MAMEDev who's smarter than me to figure out what's going on :-), but progress is certainly going to be stymied for a good chunk of time. So it goes.
There are still plenty of 2d things left unimplemented that I can mess with to maintain my sanity :-)!
2.24.10
Obscura.
I fixed most of the textures in Roads Edge by partially implementing the sub-texture-page indexing modes. This seems to have broken the SNK logo in the intro, but that should be pretty easy to fix once I have more examples of how the indexing really works. Kinda' cool seeing the textures correct, but I still gotta' fix the palette on the trucks.
In other, more exciting-to-me news, I've derived additional info about how the 3d camera's projection matrix is constructed. There's still a value I'm not using, but it's pretty darn close. I believe I'm within ~5% tolerance in most cases I've seen. The following shots are of 3d rasterized geometry (on the left) that is supposed to line up with the 2d sprite (on the right). The first is of the HNG64 intro in Roads Edge and the second is of the 3d SNK logo that swings into place. You may recall these were too small before this recent discovery.
2.14.10
Picture pages.
I figured out a different palette indexing mode used in the Samurai Showdown games. It allows a piece of geometry to use less than an entire 0x80-sized palette entry for its colors. This fixes many of the background objects in the sams games, and should eventually help out with Roads Edge if that ever makes sense to me.
1.25.10
Lite Brite.
I've had a hunch about 3d function "0010" for awhile now, but I've been too busy with other things to act on said hunch. Luckily my guess was right - "0010" is a lighting function containing at least one directional light.
I don't have absolute proof that things are working correctly, but the globe in Fatal Fury Wild Ambition is supposed to be lit from the left, so I'm at least getting it correct for that part. Of course the sams64 games do things their own weird way, and I haven't found the light color parameters yet, but ya' gotta' start somewhere.
1.21.10
Mo Geo.
Continuing the trend of hyper-configurability, I found yet another geometry type in the hng64 that doesn't have any rotations. This is good for things that never move, like the road in the racing games and the ring in buriki.
1.4.10
Why hello there.
A lucky guess made a bunch of the 3d show up in the hng64 Samurai Showdown games. It's not 100% yet, and my lucky guess needs a lot more exploration before I'm happy with it, but now all the games in the hng64 driver are showing 3d!
Sams64 has some camera issues, but I believe sams64_2 is completely playable. I'd love to see some screen grabs if anyone manages to get anywhere in it!
12.23.09
Pretty in pink.
Inspired by Haze and Kale's work on the hng64 2d system (and the fact that Kale made previously-unworking games go in-game), I dug back into improving the hardware's 3d emulation. I last left the 3d emulation in a bit of a shambles, so there was some simple refactoring work to warm me back up to the system. After some retooling, I've managed this in Roads Edge:
Andrew
10.06.09
Polygonz attack!
The other day i figured out one of the things I was doing wrong with the dsp56156 CPU core. Adding a little logic allowed Polygonet Commanders to go "in-game." Arbee and Haze hooked up the ROZ layer, giving us a dandy little sky:
3 tank variations.
One more tank variation, a personnel carrier, and a grab bag of vehicle parts (there's a wheel floating at the origin that presumably gets instanced under the truck).
A couple more vehicles, a bunch of 'bullets', and a bunker of some sort.
Some messages, and the entire alphabet all piled on top of each other (i was too lazy to separate them). They also really wanted to write "YOU ARE ABOUT TO BE DESTROYED" in a different font. At least i think that's what one would be most interested in spelling with those letters :P .
Tanks.
Some text I didn't flip (maybe some of my coordinate systems are backwards? Oh well). Interestingly enough, the word "POLYNET" is present in the geometry. I wonder why that is? A plug for Polynet Warriors maybe?
I've seen this logo somewhere before.
Some miscellaneous 3d junk.
Here is one of the memory dumps I pulled this geometry from. It corresponds to the second image up there. If you're up for a challenge, see if you can figure out the format Polygonet Commanders stores its 3d data in. If you can, you might just have emulator coding in yer blood. (A hint; not all those 16-bit values should be interpreted unsigned).
Now I've gotta go back to the chore of fixing dsp56k opcodes so it transforms the geometry properly (and whatever else it's supposed to be doing). No more 3d fun for awhile. So it goes...
Andrew
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...