Skip to content

Commit

Permalink
New machines marked as NOT_WORKING
Browse files Browse the repository at this point in the history 
----------------------------------
TwinBee (Bubble System) [Raki, Dumping Union]
  • Loading branch information
@Osso13
Osso13 committed May 4, 2020
1 parent 42508a5 commit bdb6889
Show file tree
Hide file tree
Showing 2 changed files with 20 additions and 1 deletion.
20 changes: 19 additions & 1 deletion src/mame/drivers/nemesis.cpp
View file
Original file line number Diff line number Diff line change
Expand Up @@ -3034,6 +3034,24 @@ ROM_START( gradiusb )
ROM_LOAD( "400a2.1b", 0x100, 0x100, CRC(2f44f970) SHA1(7ab46f9d5d587665782cefc623b8de0124a6d38a) )
ROM_END

ROM_START( twinbeeb )
ROM_REGION( 0x80000, "maincpu", ROMREGION_ERASE00 )
ROM_LOAD16_WORD( "boot.bin", 0x000, 0x1e0, CRC(ee6e93d7) SHA1(7302c08a726a760f59d6837be8fd10bbd1f79da0) )

ROM_REGION( 0x40300, "bubblememory", 0 )
ROM_LOAD16_WORD_SWAP( "gradius.bin", 0x00000, 0x40300, CRC(4d396a0a) SHA1(ee922a1bd7062c0fcf358f5079cca6424aadc975) )

ROM_REGION( 0x1000, "mcu", ROMREGION_ERASE00 ) // Fujitsu MCU
ROM_LOAD( "mcu", 0x0000, 0x1000, NO_DUMP )

ROM_REGION( 0x10000, "audiocpu", 0 )
ROM_LOAD( "400-e03.5l", 0x00000, 0x02000, CRC(a5a8e57d) SHA1(f4236770093392dec3f76835a5766e9b3ed64e2e) )

ROM_REGION( 0x0200, "k005289", 0 )
ROM_LOAD( "400-a01.fse", 0x00000, 0x0100, CRC(5827b1e8) SHA1(fa8cf5f868cfb08bce203baaebb6c4055ee2a000) )
ROM_LOAD( "400-a02.fse", 0x00100, 0x0100, CRC(2f44f970) SHA1(7ab46f9d5d587665782cefc623b8de0124a6d38a) )
ROM_END

void nemesis_state::bubsys_init()
{
/*
Expand Down Expand Up @@ -3062,7 +3080,7 @@ void nemesis_state::bubsys_init()

GAME( 1985, bubsys, 0, bubsys, bubsys, nemesis_state, bubsys_init, ROT0, "Konami", "Bubble System BIOS", MACHINE_IS_BIOS_ROOT )
GAME( 1985, gradiusb, bubsys, bubsys, bubsys, nemesis_state, bubsys_init, ROT0, "Konami", "Gradius (Bubble System)", MACHINE_UNEMULATED_PROTECTION )
// Bubble System Twinbee
GAME( 1985, twinbeeb, bubsys, bubsys, bubsys, nemesis_state, bubsys_init, ROT0, "Konami", "TwinBee (Bubble System)", MACHINE_NOT_WORKING | MACHINE_UNEMULATED_PROTECTION ) // doesn't seem to like the MCU simulation
// Bubble System RF2
// Bubble System Galactic Warriors
// Bubble System Attack Rush
1 change: 1 addition & 0 deletions src/mame/mame.lst
View file
Original file line number Diff line number Diff line change
Expand Up @@ -31211,6 +31211,7 @@ rf2 // GX561 (c) 1985
salamand // GX587 (c) 1986
salamandj // GX587 (c) 1986
twinbee // GX412 (c) 1985
twinbeeb // Bubble System

@source:neogeo.cpp
neogeo // NeoGeo MV-6F
Expand Down

14 comments on commit bdb6889

@MooglyGuy
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, uh, what? gradius.bin? Even if we don't have the correct ROM markings, can we at least try to name the relevant ROMs after the game they're part of?

@Osso13
Copy link
Member Author

@Osso13 Osso13 commented on bdb6889 May 4, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm just an entry level dev, so sometimes I make copy/paste errors :)
Anyway, if more devs were interested in adding dumps then I would have less to do and would probably do less of this heinous commits.

@Osso13
Copy link
Member Author

@Osso13 Osso13 commented on bdb6889 May 5, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, I'll report your findings to the DU.

@MooglyGuy
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As I understand it, the data was trojaned out of it by running code on the 68k(?) to read each page in sequence and scribble it out to some FRAMs which could then be dumped. That being the case, the data would naturally lack any kind of low-level auxiliary information since it's effectively data that's already been pre-processed by the bubble memory MCU.

@Lord-Nightmare
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The bubble mcu doesn't completely decode the data, I'm not certain it decodes the data at all. a bunch of the decoding is done by the bootloader program uploaded to the 68k. This dump seems like its a capture from after the 68k has already done the decoding pass of the data, so that decoding would have to be undone first. Given this strips off all the CRC data, getting a second dump from a different bubble cart would be ideal, as we have no proof that this dump wasn't modified, either when it was extracted from the bubble cart to the bubbless fpga cart, or by the bubbless itself somehow.

@MooglyGuy
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well, you could have brought these concerns up on the DU list in the first place, but...

@MooglyGuy
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Weird how it always seems to be everyone else who has the problem.

@ika-musume
Copy link

@ika-musume ika-musume commented on bdb6889 May 11, 2020 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry. I don't know what's going on here but I'd like to give you some information.

  1. Fujitsu FBM54DB 1Mbit bubble memory has 584 minor loops and 2053 bubble positions(=pages). Got this information from Fujitsu datasheet. So the number of page should be 2053(0x000-0x804). Any page beyond 0x804 boundary is just a repeat of previous pages.
  2. There are no CRC, page number, intended padding data on a REAL bubble cartridge.
  3. There's no identical bubble dump, since every bubble memory their own error maps.
  4. For some reason, the bubble memory controller copies 6-bit right-shifted data to the shared RAM from 0x00000 (this bubble memory controller was not made by Fujitsu, designed by Yamaha with Fujitsu's technical support and manufactured by Sharp)
  5. Data organization of bubble memory depends on the vendor and the person using it. It's not a silicon device. There are many papers and patents about this.

@ika-musume
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I know how the controller controls bubble memory and how raw data is transferred, but I will not say here since I think they are not important in this emulation. In short, every bits of actual raw bubble data is "inverted". The controller re-inverts raw bubble data, "cuts" several bits of head and tail of each bubble page data and masks bad minor loops. It transfers modified data by DMA, and CPU can manually reset(write 0 on 0x40004) pointer of internal bubble buffer.

@happppp
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In that case, Gradius is the 'wrong' one? How was it dumped? Possibly the metadata (page numbers, checksum?) is added during loading the raw data.

@balr0g
Copy link
Contributor

@balr0g balr0g commented on bdb6889 May 11, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  1. Fujitsu FBM54DB 1Mbit bubble memory has 584 minor loops and 2053 bubble positions(=pages). Got this information from Fujitsu datasheet. So the number of page should be 2053(0x000-0x804). Any page beyond 0x804 boundary is just a repeat of previous pages.

Is there a place the datasheet could be found? I'd be interested in it (even if it it is in Japanese). Thanks!

@ika-musume
Copy link

@ika-musume ika-musume commented on bdb6889 May 11, 2020 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In that case, Gradius is the 'wrong' one? How was it dumped? Possibly the metadata (page numbers, checksum?) is added during loading the raw data.

I can't say it's wrong. Because bubble memory can have a different organization depending on a user or a vendor, so dumpers can organize it in different way. It's not a device like an EPROM.

I remember that there's no checksum on Gradius dump. All pages have been 6 bit right shifted. "Overflowed" 6 bits makes an additional byte. Just like DDDD/DD??.(D is a overflowed bit, ? bit is not used) And I can definitely say that page numbers are the metadata. There' no page number on a real cartridge.

@ika-musume
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  1. Fujitsu FBM54DB 1Mbit bubble memory has 584 minor loops and 2053 bubble positions(=pages). Got this information from Fujitsu datasheet. So the number of page should be 2053(0x000-0x804). Any page beyond 0x804 boundary is just a repeat of previous pages.

Is there a place the datasheet could be found? I'd be interested in it (even if it it is in Japanese). Thanks!

https://www.advantest.com/documents/11348/146752/pdf_mn_JTR45102_OPERATING_MANUAL.pdf

Look at appendix, page A-11. Can read Japanese but I am neither a native Japanese nor a English speaker. Here's my crude translation.
"There are 584 minor loops for a data storage, and one minor loop can store 2053 bits"

@ika-musume
Copy link

@ika-musume ika-musume commented on bdb6889 May 11, 2020 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In addition, if you want to be strict, the bubble system bootloader is not a correct dump. There's header data(or starting bit) that only the controller can recognize. The bubble controller continues to rotate the external magnetic field of the bubble memory until this data pattern is detected, which initializes the controller's internal bubble memory page register when the pattern is detected. However, this data is not required in this level of emulation.

(This is an usual power-up sequence for a major track-minor loop architecture bubble memory.)

Please sign in to comment.