> > MAME currently completely misrepresents the storage capacity of each cart for any
> > dump that isn't stripped, a grand total of 0 of them can actually store 8MBIT, that
> > physical capacity does not exist inside of them.
>
> Have you actually tested the address lines on any of these carts, to probe for ESD
> protection diodes? It's about the only way to work out the actual amount of ROM
> without decapping the glops. At least some of the PCE carts have more ROM than they
> need with the data repeated because NEC had better economies of scale on the larger
> sizes. Representing them all as 8Mb is silly, though.
well given in cases where carts have gone bad, overdumps this way have repeated the bad data, I'd say it was pretty certain.
If there were multiple copies, they wouldn't have all gone bad in the same way ;-) Simple logic dictates the most likely ROM capacity, what we do now with the 8MBIT dumps is the most illogical and least likely.
MAME deals with the actual physical storage capacity of the chips.
Also, the 8-bit ID code really shouldn't be a list of comments in the XML header, it should either be a single byte file (kinda silly) or (much more sensible) as part of the driver-readable cartridge information in the XML, so that the driver can actually read it, and the extra CPU can feed in the inputs for that game code. Representing it as a 0-255 decimal value when it's 8 lines, and would be far better represented as hexidecimal seems silly too.
The way the 8-bit number was provided by game specific adapters on the V1 carts in order to use them with the later motherboard (as the V1 wouldn't need it) confuses things a bit, but a comment probably suffices to say that's the case; the V1 tourvision will however need emulating as a separate machine that doesn't use the ID byte, it's a different PCB, not just a different bios.
|
Index 
Flat 
Re: DU: TourVision update
Reply
