> > dumped more TourVision carts: > > Bomberman '93 > Die Hard > Hit The Ice > Knight Rider Special > V1 2.0 bios > > > Good to know the hash file 'hash/pce_tourvision.xml' is getting more additions. > > > - > http://blog.system11.org/?p=1785 > > http://blog.system11.org/?p=1943 > - > > After reading these two entries, the file src/mame/drivers/tourvis.cpp > is overdue for hardware tech info update. > > It is interesting that there is a bit more of an understanding of how the cab and > hardware operates.
I'd like to see it emulated completely at some point, I'll keep learning as much as I can about how it works. Finding a V1 system exists was a big deal to me, finally answered the question about carts/adapters.
> sorry i meant does it work in turbo grafx emultor? terra cresta 2
Yes. You can play it in Ootake or MagicEngine or even in MAME ! I only use the Arcade part of MAME, so I can't tell if Terra Cresta II works or not. TourVision was part of the arcade, but now it use softlists - I do not know why, but that's it.
> > sorry i meant does it work in turbo grafx emultor? terra cresta 2 > > Yes. You can play it in Ootake or MagicEngine or even in MAME ! I only use the Arcade > part of MAME, so I can't tell if Terra Cresta II works or not. > TourVision was part of the arcade, but now it use softlists - I do not know why, but > that's it.
The games are exactly the same as the normal PCE games, all the arcadey stuff (time keeping, credits, etc.) was done by the board they plugged into. So there was no point in having two sets of the same data in two different romsets. These are console games first, these were not intended to be used in arcades.
Not entirely true, one or two had different dumps, but more importantly the cart system is switching the equivalent of an 8mbit cart regardless of the actual size. I've argued for a while now that these images shouldn't be stripped as many now are. Additionally there's a TourVision specific item of data which goes with each cart - the ID, it's an 8 bit field created by jumpers on 8 extra cart pins.
> Not entirely true, one or two had different dumps, but more importantly the cart > system is switching the equivalent of an 8mbit cart regardless of the actual size. > I've argued for a while now that these images shouldn't be stripped as many now are. > Additionally there's a TourVision specific item of data which goes with each cart - > the ID, it's an 8 bit field created by jumpers on 8 extra cart pins.
They should be stripped
THERE IS NOT 8MBIT OF DATA INSIDE OF THEM
There's not even a valid argument for this any other way, any time you see data duplicated in the dumps it's coming from the exact same physical bits inside a rom due to address lines going nowhere.
I respect your work, but you really are making yourself look like a fool with this one.
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.
You wouldn't stick a 1MBIT rom in a reader, read it as 8MBIT and claim the duplicate data is correct, that's what is being done here, just because there's a bunch of epoxy etc. around those roms doesn't change their capacity.
> Not entirely true, one or two had different dumps, but more importantly the cart > system is switching the equivalent of an 8mbit cart regardless of the actual size. > I've argued for a while now that these images shouldn't be stripped as many now are. > Additionally there's a TourVision specific item of data which goes with each cart - > the ID, it's an 8 bit field created by jumpers on 8 extra cart pins.
It's still an overdump if the actual ROM under the glop is smaller. Repeating the data doesn't properly document a smaller, mirrored ROM. Unfortunately it's a pain in the arse to work out how much ROM is used in a given cart non-destructively.
> 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.
> > 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 
Threaded 
DU: TourVision update
Reply
[Re: 
