Play your favorite classic games and more with the GameEx front end. Read more.

bubsys: MAME ROM Information.

MAME Info:

Bubble System BIOS (Konami 1985)

BIOS:

400b03.8g (audiocpu $0 - 8k)

400a1.2b (k007232 $0 - 256)

400a2.1b (k007232 $100 - 256)

sram1.ic1 (sram $0 - 8k)

sram2.ic3 (sram $2000 - 8k)

NOTES:

- A 68000/Z80-based arcade system PCB with an additional Bubble Memory Cassette containing the game data which can be changed easily. The data in the Bubble Cassette can be corrupted if subjected to magnetic interference. The bottom PCB appears to be exactly the same as used on Nemesis hardware.

- The boot sequence is: On power up, displays a blue screen containing some junk pixels and speech says: "Presented By Konami", then "Getting Ready..... Fifty" and "Getting Ready..... Forty Nine" etc, until about 30, then the screen displays some orange text 'WARMING UP NOW' on a black background and numbers that count down from 99 to 0, and below that text 'PRESENTED BY KONAMI". A tune also plays while the numbers count down. When the counter reaches 0 the game boots.

WIP:

- 17th July 2011: Charles MacDonald - Back in 2007 Guru and I did some experiments with a Konami Bubble System board. The system has a 68000 with 128K of work RAM implemented as DRAM, and the first 4K is replaced with two 2Kx8 SRAM chips. The SRAM is shared with a unknown MCU (64-pin SDIP) that can halt the 68000 and read/write SRAM as needed. The MCU directly interfaces with the bubble memory. There are dedicated hardware registers at $40000 for the 68K to make sector read/write requests, and the MCU uses $F00-$F7F in shared RAM as a sector buffer for these requests. After a power-up reset the MCU writes the vector table and a boot program into shared RAM for the 68000 to execute. Guru replaced the SRAM with NVRAM so we could get the boot program before it was overwritten by the game program. It does the following: * Wait for a fixed period of time. * Kick the watchdog. * Copy MCU-supplied data from 14C to D00. I think this is the bad sector bitmap and is 304 bytes. That's 2432 bits for each 128-byte sector, or 304K total. Sectors are actually 132 bytes each, with 128 bytes of usable data. The BIOS strips the excess data out after the MCU has read a raw sector into RAM. * If offset $78000 contains $5555, jump to $78002. This corresponds to external EPROM attached to the daughterboard connector, presumably for development. * Read bubble memory sectors $001, $001, $801. This data isn't used, so these are probably dummy reads to prepare the bubble memory for later access. Bit 11 of the sector number may have a special purpose here (e.g. sectors $001 and $801 are the same). * Read eight sectors from sector $181 onwards to RAM at $10000, converting each raw 132-byte sector to a 128-byte sector. * Jump to $10000 where the first 1K of the game program loaded from bubble memory resides. This is the higher area of work RAM that isn't shared with the MCU. From this point the game is running, and it will continue to load more sectors into memory and perform game specific operations. It has a simple BIOS in the low 4K of work RAM where trap #0 reads a sector and trap #1 writes a sector. I don't know if games commonly write data such as high scores back to the bubble memory however, or if the sector buffer for a sector write operation has to be in the raw format or not. Now for the sake of preservation and emulation our goal is to read all of the bubble memory data for each game. In order to do this a trojan has to be executed by the 68000 to talk to the MCU and request sectors to read. As the 68000 program code is either loaded from bubble memory or copied from the MCU internal ROM, there is no easy way to run our own code. Replacing the SRAM with ROM (in our case, write-disabled NVRAM) prevented the MCU from starting up correctly as it expects to read and write data when booting, so the only remaining option is to use the daughterboard connector. A custom PCB could be attached to it with the identifying signature and 68000 code that would get executed directly. Some additional hardware like more NVRAM or a USB interface could be added to the board for saving sectors as they are read. Or, another option would be to replace the 68000 with a Fluke module and break execution once the startup program passes control to the program loaded from bubble memory, then overwrite RAM at that address with a trojan. At some point we probably want to get the MCU decapped, identified, and read for the sake of accuracy. The bubble memory games are quite rare and expensive so it's been hard to find people with access to working boards who want to risk doing something like this. In the meantime it's probably sufficient to just dump the bubble memory and simulate the MCU for emulation.

- 0.143u1: Guru and Angelo Salese added Bubble System BIOS (Konami 1985).

- 21st January 2008: Guru - I've been working with Charles on the Bubble system I have here and we've managed to find the missing 68000 loader code. It appears it's in a MCU (a custom Konami chip) in shared RAM (put there by the MCU, which we have partly extracted) and then pulls the data out of the bubble memory IC's one bit at a time. Yes that's right, we've got part of the bubble memory now (about 4k of it). Still a alot of work to do though before we get it all. So the above item is very on-topic with regards to my current WIP work.

Romset: 25 kb / 5 files / 11.5 zip

MAME XML Output:

<description>Bubble System BIOS</description>

<manufacturer>Konami</manufacturer>

</input>

</dipswitch>

</dipswitch>

</dipswitch>

</dipswitch>

</dipswitch>

</dipswitch>

</dipswitch>

</dipswitch>

</dipswitch>

</dipswitch>

</game>

Developed by: Spesoft Headsoft Terms of use Privacy Advertise