Considering that you already have a working cycle-accurate 32bit/64bit MIPS core, and that the current CEN64 bottleneck is the RCP and not the CPU, maybe having a working (and real time) SGI Indy emulator could be achieved sooner than achieving a real time N64 emulation.

All Indy hardware (well, except the XZ option) is documented (SGI released their internal hardware docs to the Linux/Indy team). The documented graphics is the XL (Newport) which doesn't have hardware texturing, nor hardware depth buffer, nor microcode programmability... it's just a basic 2D raster engine with a very limited function set.

I tend to believe it would be easier to get a real time XL emulation than RCP. And, to be honest, considering it's just a 2D accelerator, I feel it wouldn't hurt to emulate it with OpenGL... even if it's not pixel exact... given its limited feature set I don't think emulating it with OpenGL would be too bad.

Currently I see two attempts at getting a working Indy emulator: MIEPS (which seems stalled) and MESS (but they're so busy emulating so many computers that the SGI driver doesn't get any effort lately, and it just works until the PROM boot).

And last but not least... Do you imagine what could mean to have a working Indy emulator as well as future progress in CEN64? It could mean that perhaps at some point it would be possible to emulate a real Indy N64 SDK... I don't know if the Indy<>N64 interface is documented, but maybe it could be found how it works and fully emulate the SDK hardware... I mean, maybe at some point it would be possible to "plug" CEN64 into the Indy emulator and have them working together as in a real SDK (agreed, this would require to optimize CEN64 more, and perhaps to get faster future Intel CPUs in the future)

First, regarding the bottleneck - depending on the ROM, the RCP or VR4300 can bottleneck. Some games (Super Smash Bros. 64, Vigilante 8) murder the RDP. Others (Goldeneye 64) heavily tax the VR4300 due to their use of the TLB or lots of framebuffer effects, etc. MooglyGuy (from MESS) noticed the same thing - that an emulator emulator is essentially only as fast as the slowest component.

Secondly - for the VR4300, really the easiest way to test it (and really beat it to hell and back) would be to get it booting Linux or IRIX, whichever is least painful. From there, you can just run something like SPEC CPU 2006 on it to really put it through the paces. I imagine the easiest thing would be to getting running inside QEMU or something?

The RSP is currently being more or less tested by MooglyGuy, who is merging the vectorized portions of the CEN64 RSP into MESS (and comparing everything to the current MESS functionality).

The RDP, since it's more or less coming straight from angrylion, has been looked at by dozens of eyes and gone through several tests of its own.

I was looking at some Ultra 64 SDK specs yesterday. It's a GIO board, the cartridge is replaced by RDRAM than can be accessed from the Indy via DMA. I don't know if the Ultra 64 board is documented, but GIO is, including the GIO DMA protocol.

And also very promising is the fact that the SDK communicates with the board just with three commandline executables: one for sending a game from the Indy to the board and running it. And the other two for reading back data for debugging purposes. No other part of the SDK communicate with the board (and in fact I've read that you can install the Ultra 64 software even if you don't have the board: just these three executables won't work, but the SDK is otherwise functional and you can create games with it).

Maybe if an Indy emulator arrives to a point with 100% GIO emulation (including DMA of course), it might be possible to emulate the Ultra 64 board, just by listening what data these three executables send and receive to/from the GIO bus.

Anyway, you're right that having a functional Indy emulator is a substantial amount of work, but, man, the Previous developers (NeXT emulator) have it more difficult IMHO, and they have progressed a lot lately. It's just a matter of having at least one person with available weekends and devoted to it, because the hardware documentation is there.

BTW, now that you mention QEMU: Does it aim to emulate accurate speed? Last time I checked I arrived to the conclusion that it emulates machines as fast as possible without controlling their speed.

And, also, I forgot another SGI emulator: GXemul. It emulates an O2, and IIRC it successfully boots NetBSD on the emulated O2. But it cannot boot IRIX because IIRC the O2 SCSI interface isn't documented. The O2 is much harder to emulate than the Indy because it isn't documented, and this dude arrived quite far in the emulation. It's what I said, it's a matter of a dude with available weekends, and with SGI passion, of course.

asiga wrote:Anyway, you're right that having a functional Indy emulator is a substantial amount of work, but, man, the Previous developers (NeXT emulator) have it more difficult IMHO, and they have progressed a lot lately. It's just a matter of having at least one person with available weekends and devoted to it, because the hardware documentation is there.

BTW, now that you mention QEMU: Does it aim to emulate accurate speed? Last time I checked I arrived to the conclusion that it emulates machines as fast as possible without controlling their speed.

I don't even have a weekend to spare most of the time, hence the slow progress.

Regarding QEMU - yes, it just emulates machines as fast as possible. But it's good for checking functional-correctness, which is the only part I'm really worried about with the CEN64 core. The pipeline "timing" is quite accurate and model is true to the design, but I am certain there are a couple of functional bugs in it (some known, others not).

asiga wrote:Anyway, you're right that having a functional Indy emulator is a substantial amount of work, but, man, the Previous developers (NeXT emulator) have it more difficult IMHO, and they have progressed a lot lately. It's just a matter of having at least one person with available weekends and devoted to it, because the hardware documentation is there.

BTW, now that you mention QEMU: Does it aim to emulate accurate speed? Last time I checked I arrived to the conclusion that it emulates machines as fast as possible without controlling their speed.

I don't even have a weekend to spare most of the time, hence the slow progress.

Regarding QEMU - yes, it just emulates machines as fast as possible. But it's good for checking functional-correctness, which is the only part I'm really worried about with the CEN64 core. The pipeline "timing" is quite accurate and model is true to the design, but I am certain there are a couple of functional bugs in it (some known, others not).

Writing an SGI emulator would be my #1 hobbyist project I'd take at this moment. They were the only computers I used for almost a decade, so you can imagine the passion I feel for them. In fact, I bought an N64 at that time, just because how I liked SGI hardware. And I remember memorable moments, like some high scores in World Driver Championship named after SGI workstations (IIRC the default high scores for some track were Indy, Indigo2, O2, etc... ) It was a really nice time, I have very nice memories from it, and learnt a lot about hardware acceleration from that time

Unfortunately, because of my employer current needs, I'm now 100% devoted into GPUGP projects and multiplatform framework development for desktop+mobile OSs, which leave me without spare time. It's also very exciting, but, man... I'd really love to have free time, take all the SGI docs, all my stuff from the SGI days, the source of MESS, MIEPS, and GXemul, as well as the source of your VR4300 core (I believe it's the only cycle-accurate emulation I found), and... well... yes: implement an Indy

Maybe somebody achieves it before I get spare time. I'd be very happy in such case, because I'd use such an emulator very frequently. Otherwise, if nobody does it, I hope to have time for doing it someday.