minitel2: Improved ROM list

[fabio-d]

Different revisions of the Minitel 2 came with slightly different ROMs. In addition to the ones already listed (Bv4 and Bv9), this commits adds references to Bv6 and Bv7 too.

The descriptions of the ROMs were updated to mention "France Telecom" (the "ft_" in their names), who commissioned this Minitel model.

A placeholder "Custom ROM (for homebrew development)" was added too, with the maximum possible size (64 KiB). This makes it easy use precompiled MAME binaries to test/debug an homebrew ROM too, by simply copying it into the roms directory under the name "devel.bin" and then booting with "-bios devel".

cc @jfdelnero

[rb6502]

I don't think there's any precedent for something like this. Normally this is done by simply launching MAME directly with a driver from the command line ("mame minitel"), in which case it will warn about checksum mismatches but still start up.

[fabio-d]

The issue with simply replacing an existing one is that all of them are only 32 KB size, but the HW actually supports up to 64 KB if you put a big enough ROM chip. And MAME of course does what ROMX_LOAD says and simply loads the first 32 KB.

I've found this problem with this custom ROM of mine that shows a gallery of images in a loop. Its ROM size is bigger than 32K and I've tested that it does indeed work in a real Minitel 2.

$ cd roms/minitel2

# The original size of my custom ROM is 46857 bytes.
$ stat --format=%n=%s image_gallery.bin
image_gallery.bin=46857

# Let's pad it to 64 KB (doing this or not does not change the
# outcome of the experiment), but we all like round numbers :)
$ truncate -s 65536 image_gallery.bin

# Let's put it in place of both "ft_bv9" and "devel"
$ cp image_gallery.bin bv9.1402
$ cp image_gallery.bin devel.bin
$ stat --format=%n=%s bv9.1402 devel.bin
bv9.1402=65536
devel.bin=65536

Let's run MAME with -bios ft_bv9:

bv9.1402 WRONG LENGTH (expected: 00008000 found: 00010000)
bv9.1402 WRONG CHECKSUMS:
    EXPECTED: CRC(ace5d65e) SHA1(c8d589f8af6bd7d339964fdece937a76db972115)
       FOUND: CRC(c456b557) SHA1(da53d5bb05c10cbb7bda77ff51014edbfdcb3d94)

and this is the screen capture:

And let's run with -bios devel instead:

devel.bin NO GOOD DUMP KNOWN

and this is the screen capture:

Note how after a few images the -bios ft_bv9 invocation starts displaying just white screens until it cycles back to the first image (because the ROM area containing their data has not been loaded), whereas the -bios devel invocation keeps displaying them properly.

I get that I'm "abusing" MAME as a development platform and this devel thing is an ugly workaround for this edge case. Maybe we can call it something else, such as rom64k?

Of course, it's also fine if we decide that it's out of scope for MAME and it should not be supported at all :)

[pmackinlay]

The ROM region should match the address decoding done by the hardware. If the hardware decodes 16 address lines to the ROM device(s), then the ROM region should be defined as 64KiB. If fitting a smaller device is allowed (e.g., 32KiB), it should either be padded/filled with empty data (0x00 or 0xff, typically), or mirrored within the total range, depending on what the hardware does.

Depending on how the region is used, the pad/fill or mirror can be done within the region, or dynamically by whatever installs them in the address map. This approach allows larger and smaller ROMs to be used interchangeably as needed.

In this case, it sounds like the driver should be updated to reflect the 64KiB region supported by the hardware.

[fabio-d]

The hardware does expose address lines A0-A15 on the ROM socket (this pic, pinout on the right). The factory ROM comes as a 87C257, which interprets A15 as chip enable.

In short, the stock ROM leaves a hole in the upper half of the address space with no chip answering. But you can easily fit a different ROM chip, as the A15 line is exposed in the socket.

That said, what are the changes you recommend? I'm not sure I can correlate your advice to code. If we assume that we take the current version of the PR and remove the devel entry, we will have:

• Address map with the full 64 K: map(0x0000, 0xffff).rom();
• ROM region with 64 K too: ROM_REGION( 0x10000, "maincpu", ROMREGION_ERASEFF )
• All the ROM entries with 32 K length, e.g.: ROMX_LOAD("bv9.1402", 0x0000, 0x8000, ... )

In this configuration replacing the bv9.1402 file with a 64 K ROM results in it being loaded only up to 32 K (see experiment above). What changes do you recommend?

[angelosa]

There is a precedent anyway:

mame/src/mame/nec/pc8001.cpp

Lines 828 to 829 in d21dce3

	// empty socket, cfr. notes in header for usage instructions
	ROM_LOAD_OPTIONAL( "exprom.ic13", 0x6000, 0x2000, NO_DUMP )

And it's imo a fair use of ROM_LOAD_OPTIONAL (the socket in this case is empty, the PC-8001 BIOS checks the header at this range to load the extension if present).

[Pernod70]

Instead of using a fake devel region maybe add a GENERIC_SOCKET(config, m_rom, generic_linear_slot, "minitel_rom", "bin,rom"); to the machine.
Then in machine_reset() you can check whether the user has manually loaded a ROM with m_rom->exists() and install it, overwriting your ROM region, with install_read_handler(0x0000, 0xffff, emu::rw_delegate(*m_rom, FUNC(generic_slot_device::read_rom)));.
Ensure to check the loaded ROM has a power of 2 size, ie. 8K, 16K, 32K, 64K, and it will automatically mirror it for you as it's a generic_linear_slot.

[rb6502]

Thanks Pernod, that's what I was going to suggest.