Hardware emulation

[StrikerX3]

• [x] PIC
• [x] PIT (System timer)
• [x] Super I/O (Debug Kits and Dev Kits only)
  • [x] Serial ports
  • [x] Character drivers
    • [x] Null driver
    • [x] Windows serial ports
    • [ ] Linux serial ports
    • [ ] stdin/stdout (low priority)
    • Possibly others, such as TCP, UDP, file and more (low priority)
• [x] CMOS (MC146818 RTC) (#14)
• [x] SMBus
  • [ ] EEPROM: a simple .bin file should do (#7)
  • [x] SMC
    • [x] AV pack
    • [x] Conexant TV encoder
    • [ ] Power/reset controls
    • [x] LED
    • [ ] Fan controller
    • [ ] DVD tray
    • [x] Temperature monitor (ADM1032) (#6)
• [x] PCI bus
  • [x] LPC / ISA bridge
  • [ ] MCPX ROM overlay (#13)
  • [ ] ACPI timer
  • [ ] TV encoder
  • Possibly others
  • [x] PCI bridge
  • [x] AGP bridge
  • [x] IDE controller (#10)
  • [x] ATA/ATAPI-4 / SCSI (#10)
  • [ ] NV2A (#4)
  • [ ] USB (OHCI) (#9)
  • [ ] XID devices (#9)
  • [ ] MCPX APU (#5)
  • [ ] Front-end Engine (FE)
  • [ ] Voice Processor (VP)
  • [ ] Global Processor (GP) (compatible with the Motorola DSP56300)
  • [ ] Encode Processor (EP)
  • [ ] MCPX ACI / AC97 (#5)
  • [ ] NVNet (#8)

Device tree based on this, this and other sources.

[StrikerX3]

Cxbx-Reloaded has an architecture we could use. See here.

[StrikerX3]

I ported over Cxbx-Reloaded's implementation of many devices, with the exception of NV2A for now. It seems that we're hanging at some point during initialization. The system clock should probably attached to PCI bus and remain disabled until the appropriate command is sent. But there's probably more stuff that needs to be done until we get past the system initialization code and go through the boot animation -- NV2A being an obvious missing component.

[StrikerX3]

Super I/O has been bumped up in priority since it will help debug some issues. I think the kernel is bug checking and the kernel debugger is trying to enable the serial port to tell us what is happening.

[StrikerX3]

Super I/O is implemented and seems to be working, but now we need to attach it to a serial port on the system and hopefully it will let WinDbg connect to the Xbox kernel debugger.

[StrikerX3]

There is now a native serial port driver for Windows. It's buggy, uses up 100% of a CPU core and tends to lock up very easily, but sometimes WinDbg connects succesfully for a brief moment and figures out that it is connected to an Xbox, like this:

Sometimes it goes even further and tries to load symbols for xboxkrnl.exe, but fails because they obviously are not available.

[StrikerX3]

I wrote a new implementation of the serial character driver for Windows that uses two threads: one for receiving data and processing events, and another for transmitting data. It can handle continuous streams of 115200 bps transfers both ways simultaneously without a problem.

I'll bring this over to OpenXBOX soon, and hopefully this will let WinDbg attach to the Xbox kernel without a problem.

[StrikerX3]

The new implementation is now ported to OpenXBOX. With some additional fixes, we can debug the virtual Xbox kernel! With it, I noticed that some IRQs are incorrect, which is likely due to an incomplete implementation of certain devices. Here's the kernel debugger in action:

[StrikerX3]

The kernel debugger sometimes prints the following message: ReadVirtual() failed in GetXStateConfiguration() first read attempt (error == 997.. This clearly means we need to emulate other hardware (in this case, XID / USB devices) before continuing.

[StrikerX3]

OpenXBOX can now detect and respond to fatal errors and bug checks. It will also detect the running kernel version and log it.

[StrikerX3]

With #10 solved, StrikeBox can now boot into games.