Hacker News Reader

Comment by mmastrac | Hacker News Reader

I wonder if we'll see viable emulators for PS4/XboxOne sooner than we did for the previous generation given that they are both x86-based (and the PS4 using FreeBSD as well).

The original Xbox hasn't seen a lot of emulation activity either -- I found that strange. It feels like we might lose an entire generation of games to bitrot.

View on HN

I'm fixing that: http://xqemu.com

What's required to test retail games / demos for the original XBox? I've done a reasonable amount of testing for Xenia because of easy access to demos. Can the discs be read in PC DVD players?

You have to use an Xbox console (or specially modified DVD drive) to dump your discs.

I'm tempted to bring my old Xbox out of retirement to play around with this. Have you considered a Show HN?

You may need to mod it to dump games.

Could you use (just) a DVD drive from an original XBOX?

This looks like a much better approach than cxbx. Thanks for the pointer!

Cheers to you and JayFoxRox.

There is nothing strange about it. The original Xbox used a custom NVidia chipset for GPU, sound, peripherals, network etc. The only semi off-the-shelf part was the Intel's CPU (the exact same CPU was not on the market but it seems like a different packaging of a regular Celeron). The system is very complex and all its documentation is very confidential, it was not given to the third parties and, by this time, I am afraid even NVidia does not have it readily available so you cannot hope somebody will break the NDA and release it. The same is true for the later generations: 360, PS3, PS4, X1 all have custom chipsets and SoC in the current gen. Having a known ISA from the point of view of writing an emulator is similar to having a known encoding when writing a translation program from an unknown language.

The Xbox gpu and apu are 'off-the-shelf' in the sense that they were re-used in nvidia retail chips. But you're right, that doesn't mean much in terms of public documentation.

So you do some reverse-engineering. On the whole it isn't much work than other consoles of that generation. The only reason there hasn't been any activity is because nobody (outside of the Xbox backwards compatibility team) sat down and did the work (because there's no incentive to)

>The Xbox gpu and apu are 'off-the-shelf' in the sense that they were re-used in nvidia retail chips.

Not really[1]. It was based on the GeFroce 3 architecture (NV20) but the actual chip had been quite different from the ones you could get on a retail card (NV2A). Even if it had been a straight off-the-shelf device it does not mean you know how it works. Look at the open-source drivers for the off-the-shelf video cards to see what is possible through reverse-engineering and what is not.

I cannot speak for other consoles of that generation, as I have not touched the GC but PS2 devkits came with nice printed manuals, describing every register and every command for almost every device (if memory serves there was not printed IOP manual but it was pretty much the PS1 chipset so its documentation had been obtainable too).

1. https://en.wikipedia.org/wiki/GeForce_3_series

The actual graphics core has only elementary differences from the retail chips [1]. The differences were mainly in integration (merging in a northbridge, tweaks for UMA, ...)

1. https://github.com/espes/xqemu/blob/xbox/hw/xbox/nv2a.c#L708

You can get very detailed ISA's for GPU's NVIDIA ones require an NDA (rubber stamped to some degree).

There have been quite a few Xbox 360 and Xbox SDK's appearing on Ebay, even some of the early PowerPC based Mac Soft SDK's for the Xbox 360 have appeared online so some one has them, too bad that people who buy them either collect them or in the case of the 360 dev box to create free XBLA gold accounts :P

I worked on a couple of Xbox games when the Xbox was around. You didn't get much concrete information about it even as part of the official docs. Plenty of stuff about the performance characteristics and memory layout for texture/vertex/index data, but nothing low level. I think there might have been enough exposed by D3D to let you bypass it entirely, at least in theory, but you'd have been on your own when it came to figuring out the ins and outs of what needed to go in the FIFO...

I vaguely recall somebody from MS saying on the Xbox developer newsgroups that providing the full information wasn't part of their deal with NVidia, and that was that.

Yes, Microsoft signed a pretty bad contract with NVidia so it could not publish much since the NV owned all the IP rights. When asked about the "push-buffer" layout and format MS would plainly tell "We won't prevent you from figuring it but we are prohibited from telling you directly". So everybody did just that, reversed the push-buffer to write their own APIs/debug tools.

I am more worried about some small but amazing Flash games. Currently it is still possible to play them in the browser, but what about in 5 or 10 years. I image there might be some kind of emulator which wraps tje flash player and the game in a single exe so it can be played independent of a browser.

You could do just that with a modern.ie VM today. The biggest challenge there is ripping the flash and all its assets (and maybe patching it up to remove any dependencies on stale domains)

Check out Shumway - it can play SWFs in the browser without using Flash: http://mozilla.github.io/shumway/

If you have the SWF, you can run them in the Flash Projector, the standalone Player. What'll be problematic is if they preload resources from external locations.

There are a lot of third-party Flash implementations. If the official Flash client becomes unusable, one of these open-source implementations will emerge as the new de-facto standard. I don't think we have to worry much about Flash's survival.

You Gnash , Lightspark and Shumway.

You can download SWF files with unplug for Firefox and such.

That depends on reverse engineering the custom chips that they use in those systems.

The Amiga had custom chips, but had released the information on how they worked so Amiga emulators could be made. I doubt Sony or Microsoft would release the information.

Just having a X86 CPU doesn't always mean the system can be emulated. For example I got BeOS for X86 and there is no emulator that can run it that I know of. My only hope of running BeOS apps is Haiku.

The latest revisions of PCem can run BeOs I think.

Qemu can run BeOSPeMax with some tweaks. I tried it. You have to run in safe mode first.

Especially since the original Xbox was infamous for randomly dying. Thirty years from now there will still be working NES consoles, but will there be any Xbox ones?

The original front-loading NES is quite infamous for having a poorly designed cartridge mechanism that bends and loses contact with the game cart pins. This is why people were always blowing on games and jamming them back in the NES back in the day. The later top-loading NES fixed the problem but is kinda rare and doesn't have RCA video outputs.

I don't think the original Xbox had many reliability problems though, maybe you're thinking of the Xbox 360 and its red ring of death problem?

The NES cart connector can be repaired with some patience or replaced inexpensively.

A lot of sites selling new connectors claim they are made with more robust materials than the original connectors, but I'm not sure how true that is.

One of the biggest differences between the NES and much newer consoles like the Xbox is that the NES is, in comparison, extremely simple; it's been reverse-engineered down to the transistor level:

http://breaknes.com/ (If you are interested in advanced RE, I recommend learning Russian...)

http://www.qmtpro.com/~nes/chipimages/

In other words, even if there are no original physical NES or their parts around in 30 years, relatively speaking it would be trivial to perfectly emulate one in software or hardware (e.g. an FPGA), because the functionality of the entire system is known.

Its a major misconception that emulators are easier for Xbox/PS4/Xbox one because they use x86. According to that logic it should be super easy to port something from windows to linux x86_64, but compiling the same program for x86_64 and ARM linux should be very hard. Turns out it is the complete opposite.

Here's what the developer of CBXB (a xbox original emulator) has to say about it, gives the reasons as to why it is to blatantly false: http://www.neogaf.com/forum/showpost.php?p=48088464&postcoun... (original is deleted)

That post is actually more meaningless speculation than accurate.

I don't see how the same logic applies: porting a source program to compile to something which runs on a new architecture seems pretty different to me than writing an efficient software to emulate another architecture for the purposes of running a program.

>t should be super easy to port something from windows to linux x86_64, but compiling the same program for x86_64 and ARM linux should be very hard. Turns out it is the complete opposite.

WineLib. And if not, just use the Wine as a binary loader and run your stuff.

Reply on news.ycombinator.com