[NES] 3D Block (1989)

Post all database contributions here.
Post Reply
Great Hierophant
Posts: 20
Joined: 02 Apr 2020 22:16

[NES] 3D Block (1989)

Post by Great Hierophant »

This game, 3D Block (1989) by Hwang Shinwei is incompletely dumped. A fully-functional dump of this game must contain a PRG of 32KiB with a CRC32 of 86DBA660 and an extra 1KiB of ROM with a CRC32 of 116C9BDF. The extra kilobyte of data is needed for the firmware of the PIC16C54 microcontroller contained on the PCB. The firmware handles copy protection and is also required for the title screen animation to display correctly. The NES 2.0 header format is used to designate the mapper number, 355 and that the ROM contains a "miscellaneous ROM" not properly characterized as PRG-ROM or CHR-ROM.

The correct file size of a combined ROM is 32,792 (33,808 with a header) and a CRC32 of B8D931FE.
KingMike
Posts: 586
Joined: 22 Sep 2012 16:36

Re: [NES] 3D Block (1989)

Post by KingMike »

32,792 is only 32,768 + 24. Wouldn't it be 33,792/34,808?
Great Hierophant
Posts: 20
Joined: 02 Apr 2020 22:16

Re: [NES] 3D Block (1989)

Post by Great Hierophant »

KingMike wrote: 04 Apr 2020 02:11 32,792 is only 32,768 + 24. Wouldn't it be 33,792/34,808?
It would, I mistyped. So ultimately the file size should be 16 + 32768 + 1024 = 33808
User avatar
Tauwasser
Datter
Posts: 228
Joined: 04 Oct 2010 06:51

Re: [NES] 3D Block (1989)

Post by Tauwasser »

Was the NES not included in the database change that enables multiple files per entry? Isn't this exactly a situation that would warrant it?

IIRC there was talk for NES specifically about splitting PRG and CHR using that mechanism, but I cannot recall specifics and when (and if) that change will be done or is planned to be done.
Hiccup
Datter
Posts: 1004
Joined: 09 Oct 2015 11:29

Re: [NES] 3D Block (1989)

Post by Hiccup »

Tauwasser wrote: 20 Apr 2020 00:25 Was the NES not included in the database change that enables multiple files per entry? Isn't this exactly a situation that would warrant it?

IIRC there was talk for NES specifically about splitting PRG and CHR using that mechanism, but I cannot recall specifics and when (and if) that change will be done or is planned to be done.
Well when the feature was added, there weren't any files implimented into it straight away, I think, other than moving the NDS stuff from the hardcoded system they used before.

I think it'd be a good idea to start implimenting split dumps, but where would the size information come from? Can NES dumping software determine where one ROM chip's data ends and the other begins? (maybe that's how some dumping software creates iNES headers). If it can, this info isn't recorded in the the dump entires. Another way could be from the ROM chip markings (but this would have to be done manually, could be inaccurate and some dumps may not have photos/chips may not have markings).
KingMike
Posts: 586
Joined: 22 Sep 2012 16:36

Re: [NES] 3D Block (1989)

Post by KingMike »

PRG and CHR ROMs are physically separate ROMs on the cartridges which are accessed separately by different chips (the CPU and the PPU).
Hiccup
Datter
Posts: 1004
Joined: 09 Oct 2015 11:29

Re: [NES] 3D Block (1989)

Post by Hiccup »

I see. Then we just need to make sure people submit the sizes from the iNES header produced by the dumping software from now on.
Great Hierophant
Posts: 20
Joined: 02 Apr 2020 22:16

Re: [NES] 3D Block (1989)

Post by Great Hierophant »

At the very beginning of NES emulation (1995-96), the pasofami emulator format split games into a .prg file, a .chr file (if the game used CHR-ROM) and later a .prm file which was supposed to describe how the game was supposed to work. Then in later 1996, the iNES emulator format combined prg and chr data into one file and added a header designed to describe hardware. Later, when the deficiencies of the iNES 1.0 format were too restrictive and UNIF was not going to be a good substitute, the NES 2.0 format was introduced. Based on the experience of the past 25 years, a split format is a terrible idea.

NES 2.0 has a "miscellaneous ROM" entry that can handle extra data not properly considered PRG or CHR data. The existing ROM of 3D Block uses the miscellaneous ROM bits and tacks the extra data onto the end of the file. It works because 3D Block is assigned to a distinct NES 2.0 header. There is also another game from the same developer called Block Force which requires a miscellaneous ROM for the same reason as 3D Block and uses the same Mapper. PlayChoice-10 ROMs require three miscellaneous ROMs and there is a pirate version of Moero Pro Yakyuu which has had its PCM ROM dumped and tacked on as a miscellaneous ROM. All these things are supported in certain emulators.

Any dumper can distinguish between PRG ROM and CHR ROM because the chips are on separate buses. They must know something about the hardware to dump the ROMs if there is bankswitching hardware in the cartridge, so the dumper will try to add a NES header to the resulting file.
Hiccup
Datter
Posts: 1004
Joined: 09 Oct 2015 11:29

Re: [NES] 3D Block (1989)

Post by Hiccup »

Well datomatic could also dat the iNES 2.0 version of each ROM, as long as there is a proper standard so the ROMs are consistent.
Great Hierophant
Posts: 20
Joined: 02 Apr 2020 22:16

Re: [NES] 3D Block (1989)

Post by Great Hierophant »

Hiccup wrote: 23 Apr 2020 09:33 Well datomatic could also dat the iNES 2.0 version of each ROM, as long as there is a proper standard so the ROMs are consistent.
This is now : http://forums.nesdev.com/viewtopic.php?f=3&t=19940 This database covers over 90% of the No-Intro set at present.
relax
High Council
Posts: 882
Joined: 27 May 2008 17:52

Re: [NES] 3D Block (1989)

Post by relax »

I replaced the the ROM in dat with the extended ROM with the added 1KiB firmware.
Post Reply