@RiGaL Nunca he tenido Neo Geo CD pero a mi no me suena que saliera ningún accesorio/extra de MPEG asi que, supuestamente, no. Alguien que la tenga que te diga.
@titosan No ha dicho concretamente nada, pero pretende sacarlo este año. Esta en pruebas y puliendo el producto para que sea funcional y, sobretodo, ahorrarse bugs.
Si quereis seguir sus novedades esta es su web. En su twitter apenas escribe nada.
https://www.patreon.com/prof_abrasiveOs copy/pasteo (en ingles) su última entrada de hace justo justo 1 mes, donde explica un bug que tenia aparentamente aleatorio que le habia quitado el sueño:
Bug Hunt
Hi gang! I hope you're all doing well out there. Thanks for tuning in.
In my last post I mentioned an intermittent hang on startup. Here's the story of how I hunted it down and fixed the fiendish thing.
To recap, the issue was that occasionally the console would hang on startup - typically just when the Satiator would normally fade out the CD menu and present its own. I vaguely remember this happening for a long time - but my memory's pretty sketchy, and the project has had hiatuses, so I can't tell when it began. I do have memories of having it fail to start up a few times and getting frustrated. Then I'd wiggle the Satiator in its slot and - sometimes - it would start working again. I was happily blaming a dodgy cart slot on my dev Saturn, but then I restored my second Saturn, built a brand new Satiator, and... same problem was occurring.
Of course, this isn't too surprising; human memory is pretty sketchy at the best of times, and when data is rare our intuition tends to lead us astray. In this case the bug only cropped up sometimes, and I'd always be working on something else, so I never really paid enough attention. The only fix for this is to (as my boss puts it) Science The Hell Out Of It™.
The first step was to cut out my crappy memory. I don't normally keep a whole lot of notes while I work, preferring to cart stuff around in my head. (I do keep a little journal so my future self can remember what was up.) But here I was investigating something of unknown origin, in an unknown part of the system, and with unknown frequency. In cases like this you've got to hoard every scrap of evidence you can find, and carefully log every change that you make, so that you can clearly rule things out and narrow down your search. Cue a new text file.
So I sat down with my new Saturn and new cart and just... turned it off and on again. Ten times in a row, and it hung twice. Then I wiggled the Satiator in its socket, and tried another ten times: no hang! So was it the socket after all? That seems profoundly unlikely, on two consoles. The only reasonable conclusion is that it is, in fact, just a rare bug.
Next step was to attach a debugger (gdb) to the Satiator's CPU and find out what it thought was going on at the hangs. I'd sit and restart the console over and over until it hung, and then poke around in the Satiator to see what was up. In each case, I found that the Satiator was waiting for a transfer to or from the Saturn's CD Block (CDB). This needs a little explanation.
When the Satiator hijacks the CDB's execution flow, it sets up a channel for transferring data and commands between Satiator and CDB, which is called the shint (for historical reasons). The shint carries CD drive commands from the CDB to the Satiator, and emulated CD drive status and data back to the CDB. It uses DMA, where possible, so that it uses minimal CPU time on the CDB. This avoids disrupting all the normal processes that run in the CDB, unaware that they are talking to an emulated drive.
So the observations I made all had the same form: the Satiator had initiated a shint transfer, but the CDB had never started actually transferring data. It hung on many different types of transfer - CD command, CD status, CD data, etc. - but always with no data transferred. That's a significant bit of evidence, but what does it mean?
It might mean the CDB is crashing, or that there is a bug in the shint, or a bug in the CPLD which affects the data transfer path. But the latter two are very unlikely - because I never see hangs after startup; once a game is running, the shint data transfer is flawless for hours at a time. It's something to do with the startup process.
My notes run on for some time at this point exploring dead ends. But then I accidentally hit on a big clue. I'd been poking around with an oscilloscope looking at the timing of a few things, and I decided to 'scope the chip select line that is used by the shint.
Time for another explanation. A chip select is one way of having multiple chips on the same address/data bus. The Saturn's MPEG card slot has three chip selects: one for the MPEG video decoder chip, one for MPEG audio, and one for the card's ROM. When the CDB wants to talk to one of these devices, it activates that chip select, leaving the rest inactive.
The shint uses the card ROM chip select. In normal operation I don't ever touch the MPEG video or MPEG audio regions. But I accidentally put my probe on the MPEG video chip select pin - and I saw a pulse when the console hung!
This led me back down the path of memory to something from the very first days of the Satiator's development. The Saturn issues many kinds of command to the CD block; one of these is command 0x93, MPEG Init. This particular command is issued during startup, just before loading our menu - which masquerades as an MPEG BIOS. And one of the things the CDB does when you run it? It resets the MPEG DMA system which I use for the shint!
I knew about this problem right from the start, because at that point everything would just stop working - the thing would never boot. As a result there's code in the Satiator to detect command 0x93 and restore the DMA setup, which works great. Almost - almost! - always.
And here lies the bug. The shint is idle most of the time during startup; it just does a little burst of status transfers every 16ms or so (as the CD drive normally does). And when it's idle, and command 0x93 happens, everything gets reset and carries on happily. But if command 0x93 happens during that small window of activity - in the middle of a shint transfer - it would get stuck and never resume.
As any fule kno, the key to fixing - and proving that you have fixed - an intermittent bug is to reproduce it. With this information I was able to write a little Saturn program that calls command 0x93 on every frame, and it... hung instantly. Perfect!
Armed with this tool I was able to debug my command 0x93 recovery system. Interestingly, the first changes I made made things a lot better - it would run for ten seconds before hanging, instead of one - but they didn't fix it completely. Eventually I was able to let it run for half an hour without a hang, at which point I declare it completely fixed. This is why reproduction is so important; without the repro I would have got that 10x improvement and declared it fixed - while still having 1 hang every 100 boots, which I think is unacceptable.
This is a very long-standing bug: it's been there for the entire working life of the Satiator, gradually driving me batty and leaving me waving the blamethrower around. (It also gave me a deep-seated anxiety that I'd never get the thing working reliably!) Now that it's fixed I'm delighted by flawless boot after flawless boot, which makes my development workflow easier as well as helping me sleep better at night.
For my next trick I'm working on the production test system. This is the thing that will test newly assembled Satiators coming off the production line, to make sure that every part works correctly. It's mandatory for production - "I plugged it into a Saturn and it works" is neither reliable nor scalable - and I'm going to need it for the beta run. This will also give me a chance to test it out. I've had some seemingly clever ideas on how to avoid building a pogo pin jig for this job, which is something I'm not well placed to do at the moment, and we'll see how that pans out over the next week. Updates to come.
Edit: Something I didn't really cover here, but would like to, is the psychology of debugging. The story here - reconstructed from my notes - is pretty straightforward, but that's not how this stuff actually goes down on the ground. For this particular bug I spent hours and hours and quite a few late nights probing around and squeezing little driblets of information out. And for most of that time, I had no idea where the bug was. Could I ever find it? The potential area was huge; the Saturn is complex and so is the Satiator. It was a very unpleasant and uncomfortable feeling, but I just had to keep working through it.
Ultimately, solving hard bugs is not about being a wizzard; it's about being stubborn, and systematic. Hang in there!
46 Likes
![[+risas]](/images/smilies/nuevos/risa_ani3.gif "más risas")
. ![[beer]](/images/smilies/nuevos2/brindando.gif "brindis")
. Cumplí mí deuda con el pasado cuando babeé al ver un mueble con el Sega Rally.![[noop]](/images/smilies/net_thumbsdown.gif "Nop")
.
, me costó sudor y lágrimas. Pedazo decatacrac de juego. La lista es visual, por si tienes curiosidad:![[carcajad]](/images/smilies/nuevos/risa_ani2.gif "carcajada")
. ![[tadoramo]](/images/smilies/adora.gif "Adorando")
/Destruction%20Derby%20(J).png)
/Andretti%20Racing%20(E).png)
