@TheMogMiner might be able to help with this
-
-
Sure can. What do you want to know,
@Robotube? It varies widely based on the individual handheld. If you want the whole-hog history of how it was handled in the context of MAME, I can do that, or if there's a particular date range or brand, I can probably describe that too.1 vastaus 0 uudelleentwiittausta 3 tykkäystä -
Vastauksena käyttäjille @TheMogMiner ja @JVeg199X
I think what I'm super interested in knowing is if this is "emulation" in the traditional sense, ie. is there a CPU that's being emulated and a ROM of some sort that is being dumped and fed in? If so, how are you getting the ROM read? Thanks for any info!!
1 vastaus 0 uudelleentwiittausta 0 tykkäystä -
In all cases currently supported by MAME: Yes. Systems-on-a-chip (SoCs) are old hat these days, and probably most familiar to people through the Arduino and other dev boards, but they've existed since the late 70's, although they were called microcontrollers (MCUs) then.
1 vastaus 0 uudelleentwiittausta 2 tykkäystä -
A wide variety of MCUs were used in seriously vintage LCD/VFD things: The NatSemi COP400 range, the TI TMS1xxx range (Speak 'n Spell, anyone?), Mitsubishi MELPS 4, AMI S2000, Rockwell PPS-4, Sharp SM5-series, and many others. For the most part, 4-bt architecture.
1 vastaus 0 uudelleentwiittausta 2 tykkäystä -
Yes, 4-bit architecture: Register widths tended to be one nybble in width, getting paired together for bytewise operations. ROM sizes were on the order of 1-2 kilobytes, RAM usually between 64 and 128 nybbles.
1 vastaus 0 uudelleentwiittausta 2 tykkäystä -
As for dumping the ROM contents, it boils down to one of two ways, with some overlap: 1a) Depackage the chip using sulfuric or nitric acid, remove the metallized layer with fluoric acid. Remove chip die, clean in Whink.
1 vastaus 0 uudelleentwiittausta 2 tykkäystä -
1b) Throw the exposed chip die under a metallurgist's microscope, since they light downward from the objective, not upward through the slide. Hopefully have good X/Y control of the stage. Take lots of photos. Stitch. Manually transcribe bits.
1 vastaus 0 uudelleentwiittausta 2 tykkäystä -
Sometimes the ordering of bits into usable ROM words is obvious. Sometimes it isn't, and some additional tracing of the silicon is needed. This tends to only work when it's a mask-ROM part, since the ROM bits are physically "printed" on the die through the manufacturing process.
1 vastaus 0 uudelleentwiittausta 2 tykkäystä -
In other cases, this was done for the first few handhelds, then some additional time was spent investigating the surrounding circuitry to look for a possible verification mode for the chip, where it'll spit out its internal ROM if poked the right way on its pins.
1 vastaus 0 uudelleentwiittausta 2 tykkäystä
The idea is that the IC manufacturer's customer typically needs a way to verify that the product is programmed correctly. So, if that can be done, then there's: 2) Use documented (or not) methods to dump the ROM contents electronically.
-
-
Once the data is in-hand, it's a straightforward enough thing to handle. It's just adding another CPU core to MAME (if it's an unsupported architecture), and bashing out a machine driver. The machine driver itself is usually pretty small, too.
1 vastaus 0 uudelleentwiittausta 2 tykkäystä -
Art-wise, there's usually some additional doing that needs done: Either wire up the VFD/LCD so that you can photograph all elements, and hand-vectorize them, since MAME supports segmented artwork in SVG format.
1 vastaus 0 uudelleentwiittausta 2 tykkäystä - Näytä vastaukset
Uusi keskustelu -
Lataaminen näyttää kestävän hetken.
Twitter saattaa olla ruuhkautunut tai ongelma on muuten hetkellinen. Yritä uudelleen tai käy Twitterin tilasivulla saadaksesi lisätietoja.