Ernesto's To-Do List: Difference between revisions

From MAMEDEV Wiki
mNo edit summary
 
(One intermediate revision by the same user not shown)
Line 25: Line 25:


There's many things that make writing a driver for this somewhat complicated:
There's many things that make writing a driver for this somewhat complicated:
* The driver requires [http://en.wikipedia.org/wiki/Advanced_Graphics_Architecture AGA] emulation.  
* The driver requires [http://en.wikipedia.org/wiki/Amiga_Advanced_Graphics_Architecture AGA] emulation.  
* The current Amiga emulation we have in Mame is basically written for a M68000, which uses a 16 bit data bus, where the CD32 uses a 68EC020 which has a 32 bit data bus. So some 'bridge' read/write handlers had to be written to communicate with the 16 bit chips on the bus (this is mostly written, would need a more testing). To further complicate things, we keep the native endiannes on data arrays, so moving from 16 bits to 32 bits is not as trivial as it sounds.
* The current Amiga emulation we have in Mame is basically written for a M68000, which uses a 16 bit data bus, where the CD32 uses a 68EC020 which has a 32 bit data bus. So some 'bridge' read/write handlers had to be written to communicate with the 16 bit chips on the bus (this is mostly written, would need a more testing). To further complicate things, we keep the native endiannes on data arrays, so moving from 16 bits to 32 bits is not as trivial as it sounds.
* The CD32 introduces a new custom chip (Akiko) that contains:
* The CD32 introduces a new custom chip (Akiko) that contains:
** A standard [http://en.wikipedia.org/wiki/I2C I2C] bus.
** A standard [http://en.wikipedia.org/wiki/I%C2%B2C I2C] bus.
** A custom CDROM controller.
** A custom CDROM controller.


There's a 1KB EEPROM connected to the I2C bus.
There's a 1KB EEPROM connected to the I2C bus.
The chips used to drive the CDROM optics and decoding are Sony chips. Unfortunately, Akiko probably has it's own built in microcode to talk to the chips, so it implements it's own custom protocol.
The chips used to drive the CDROM optics and decoding are Sony chips. Unfortunately, Akiko probably has it's own built in microcode to talk to the chips, so it implements it's own custom protocol.
The only source of documentation for the Akiko seem to be the reverse engineering work done by the [http://en.wikipedia.org/wiki/WinUAE UAE] guys.
The only source of documentation for the Akiko seem to be the reverse engineering work done by the [http://en.wikipedia.org/wiki/UAE_%28emulator%29 UAE] guys.


Currently, I think I've fixed most of the 16 bit->32 bit issues, and basically crunched in the WinUAE code for the I2C in there. The CDROM controller code is only a skeleton of what it should be. This allows the driver to boot up to the logo screen (which doesn't really show up properly due to the lack of AGA emulation), and causes Mame to crash soon after.
Currently, I think I've fixed most of the 16 bit->32 bit issues, and basically crunched in the WinUAE code for the I2C in there. The CDROM controller code is only a skeleton of what it should be. This allows the driver to boot up to the logo screen (which doesn't really show up properly due to the lack of AGA emulation), and causes Mame to crash soon after.

Latest revision as of 03:26, 25 November 2014

Current Projects

  • Toshiba T5182 ROM extraction
  • Help ElSemi reverse engineer the Fujitsu MB8623x TGP used in Sega Model 1/2
  • Cubo CD32 driver
  • Disassembly of Pioneer LDV1000 code for Konami BadLands
  • Konami Badlands driver
  • Fix little annoying things on the Amiga driver

Project Status

Help ElSemi reverse engineer the Fujitsu MB8623x TGP used in Sega Model 1/2:

This is actually coming along very well. There are some screenshots at Haze's WIP showing the progress ElSemi has done so far. I want to mention that the bulk of the work has been done by ElSemi, and I've only been contributing small tidbits here and there.




Cubo CD32 driver:

There's many things that make writing a driver for this somewhat complicated:

  • The driver requires AGA emulation.
  • The current Amiga emulation we have in Mame is basically written for a M68000, which uses a 16 bit data bus, where the CD32 uses a 68EC020 which has a 32 bit data bus. So some 'bridge' read/write handlers had to be written to communicate with the 16 bit chips on the bus (this is mostly written, would need a more testing). To further complicate things, we keep the native endiannes on data arrays, so moving from 16 bits to 32 bits is not as trivial as it sounds.
  • The CD32 introduces a new custom chip (Akiko) that contains:
    • A standard I2C bus.
    • A custom CDROM controller.

There's a 1KB EEPROM connected to the I2C bus. The chips used to drive the CDROM optics and decoding are Sony chips. Unfortunately, Akiko probably has it's own built in microcode to talk to the chips, so it implements it's own custom protocol. The only source of documentation for the Akiko seem to be the reverse engineering work done by the UAE guys.

Currently, I think I've fixed most of the 16 bit->32 bit issues, and basically crunched in the WinUAE code for the I2C in there. The CDROM controller code is only a skeleton of what it should be. This allows the driver to boot up to the logo screen (which doesn't really show up properly due to the lack of AGA emulation), and causes Mame to crash soon after.

At this point, and now that I have a better overview of the system, this is what would need to be done:

  • Rewrite the I2C code as a stand alone module based on the Phillips specification.
  • Write a I2C->serial protocol bridge for the EEPROM, so we can use our existing serial EEPROM infrastructure.
  • Finish the CDROM controller emulation, adding the CHD support to it.
  • Add AGA emulation.

Work on some of these items might start soon.




Disassembly of Pioneer LDV1000 code for Konami BadLands:

This is something I started to work on a while ago, and Matt Ownby from Daphne joined in. It has been known that the Pioneer LDV1000 in Konami BadLands used a different firmware than the stock one found in games such as Dragon's Lair. A few new commands have been added. Luckily, the hardware used is a Z80 + CTC. What has been mostly done right now is disassembling the firmware and mapping out how it controls the hardware. More work needs to be done to know exactly what all the new commands do. After long sessions of disassembling and trying to map the hardware from very bad resolution schematics, I've taken a little break on this to work on other things. But I expect to come back to this soon.




Konami Badlands driver:

I wrote the base code for this one, and it should not be much of a problem to finish it. However, it doesn't make much sense to keep working on it until the LDV1000 emulation can handle the new set of commands this game uses.




Fix little annoying things on the Amiga driver:

The Amiga driver currently has a few issues I'd like to see fixed:

  • The video code needs to be made aware of DMA cycles and priorities, and needs to abort or delay actions accordingly. I believe this is why we have to use an incorrect value for Copper delay after a WAIT command. I tried some ideas I had, but was not entirely happy with the results, either performance-wise or timing-wise. I need to discuss this with Aaron some more when his platter is not that full and see if he has some other ideas.
  • The display delay used for scrolling is not properly emulated. It works for most of the simple cases, but if you load the World of Commodore demo on MESS, you can see a problem with it in two places: The green-blue-white pulsating and scrolling screen, and the credits section which should look 3D.