https://wiki.mamedev.org/api.php?action=feedcontributions&feedformat=atom&user=F205v 2026-04-25T22:40:46Z User contributions MediaWiki 1.41.0 https://wiki.mamedev.org/index.php?title=MAME_Italia&diff=9136 2024-04-29T10:05:11Z

<p>F205v: </p> <hr /> <div>Mame Italia is a collective name, representing all the members of the [https://web.archive.org/web/20170122112839/http://www.mameitalia.net/ MAME Italian Forum], no longer active.</div>

F205v https://wiki.mamedev.org/index.php?title=Dumping_roms&diff=5308 2017-03-28T07:22:56Z

<p>F205v: </p> <hr /> <div>Let's have a look at the most difficult part of the documentation process: the dumping!&lt;br&gt;<br /> I usually go through a 3 steps path:&lt;br&gt;<br /> '''1)Components identification'''&lt;br&gt;<br /> '''2)Actually dumping them'''&lt;br&gt;<br /> '''3)Checking what I've done'''&lt;br&gt;<br /> <br /> ==Components identification.==<br /> On a standard PCB we will find one, more or even all of the following components: CPUs, TTLs, ROMs, RAMs, PLDs, Others.<br /> I use coloured water-markers (of the kind used to write on CDs) to mark each single component when it is correctly identified: green is for CPUs, blue for TTLs, gold for ROMs, purple for RAMs, silver for PLDs. This colour marking system is of great help when working on PCBs, it gives an immediate visual overview of what is what, it avoids missing out something important to dump, it saves a lot of time because I do not have to re-identify components when I look at a PCB after some time.<br /> <br /> ===CPUs===<br /> First thing we have to find the main CPU (maybe there are more than one!); it's usually the only chip whose size is remarkably different from all the others. We have to remember that [http://en.wikipedia.org/wiki/MOS_Technology_6502 6502], [http://en.wikipedia.org/wiki/Z80 Z80] and [http://en.wikipedia.org/wiki/Motorola_68000 68000] are the most used CPUs in arcade game history, learning by heart what they look like is fundamental. Obviously each chip sports some writing (markings), and looking that up on the Internet is always a good way to confirm what a chip is. For CPUs identification I would recommend [http://www.cpu-world.com/ CPU-World] as a reference.<br /> Sound CPUs are usually found grouped together, close to the volume trimmer. Most common sound CPUs are M6295 (and clones) and all of the various YMxxxx.<br /> On some PCBs we will also find MCUs; they are like CPUs, but with an internal memory which is unfortunately read-protected 99% of the times.<br /> On some PCBs there will also be “support chips” like I/O chips, CRC controllers or Peripheral Interface Adapter; let's mark all of them green as well.<br /> <br /> ===TTLs===<br /> Second thing let's rule out all of the TTLs; they are easy to identify, because they are small (300mil) and marked 74xxx (in very old PCBs they can also be 54xxx), let's mark them blue. TTLs are usually the most common component, ranging from some tens to some hundreds of them on a single PCB. They are pure logical operators and are of very scarce interest for the dumper, apart from a few remarkable exceptions: 74s188, 287, 288, 370, 387, 471, 472, 473, 474, 570, 571, 572, 573. These are all PROMs, they have to be marked gold and are addressed here following.<br /> <br /> ===ROMs===<br /> Third thing is to correctly identify and colour mark ROMs. They come in a variety of forms: PROMs, EPROMs, EEPROMs, FlashROMs, MaskROMs. The most common are EPROMs, they sport a transparent window, they are 600mil, ranging from DIP24 to DIP42. In most PCBs they are socketed, and their extraction is very easy using a small flat screwdriver and slowly lifting them with small movements from BOTH sides to avoid any pin bending. MaskROMs are of the same size as EPROMs, but without the window, and very often they are soldered through the PCB. Removing them is a little bit more complicated, and the best suggestions for it can be found at [http://members.iinet.net.au/~lantra9jp1_nbn/gurudumps/tutorials/how_to_remove/index.html Guru's site]. EEPROMs and FlashROMs have different sizes, are usually SMD, and special adaptors are required to insert them into your programmer; adaptors could be rather expensive. Finally PROMs are small chips (300mil) usually soldered through and quite similar to TTLs, therefore learning by heart their specific markings and labels comes handy in many cases. A good reference is available [http://www.citylan.it/wiki/index.php/PROM here].<br /> <br /> ===RAMs===<br /> Fourth thing are RAMs, they come in many sizes, from long 300mil to thin 600mil to other (less common) sizes. Mark them out, because you will need to mention them in the documentation.<br /> <br /> ===PLDs===<br /> Fifth thing is to find out if any PLD is on your PCB. To understand what a PLD is, please refer to this very good article on [http://en.wikipedia.org/wiki/Programmable_logic_device wikipedia]. PLDs always incorporate a “read protect” feature, in 95% of the case it's activated by the producer; until recently it was impossible to read them, a dumper simply gave them a try hoping to be lucky and get into the 5% which is not protected. Recently [http://www.techno-junk.org Charles McDonald] found a way to read also a certain category of PLDs (the most common on arcade PCBs), so the above situation is changing.<br /> <br /> ===Others===<br /> Sixth and last thing is to identify all other components of the PCB. You will find resistors, trimmers, LEDs, audio parts, heat exchangers, connectors, jumpers, switches and a lot of other things. You will need to describe them in the documentation as well.<br /> <br /> <br /> ==Components dumping==<br /> Dumping memory chips is the core part of the whole dumping process. It basically requires an EPROM programmer, a PC and some dedication. I'm not going into describing various EPROM programmers, their pros and cons, what they can do and the like. There are too many of them, let's assume that you know how your EPROM programmer works.&lt;br&gt;<br /> Before inserting chips into the programmer's socket you have to check for all the legs to be clean and straight. If any rust or dirt is on the legs, use a piece of very fine sand-paper to clean them, on all sides (internal, external and in-between legs). If legs are bent use a small plier (or your fingers) to straight them back; be very gentle and use a very minimum of force, it's easy to break them.&lt;br&gt;<br /> Then insert your chip into the programmer, configure your software accordingly to the make/model of the chip you have inserted, read it and save the result in a safe place. Now comes the very important part: remove the chip, clean the cache of the software, insert back the chip and read it again. Then do all of this a third time. Only if the three reads are IDENTICAL (check it with crc32) then you have a good dump. If there is any difference, start again from the cleaning part of the procedure. Sometimes, even after perfectly cleaning and polishing all the legs, you can not get a constant read of a chip. In this case try to read it with a slightly different voltage/current if your reader supports such a feature; firstly try with ±5%, eventually with ±10%. Do not go beyond ±10%, you will risk to ruin both the chip (not so important) and your programmer (much more important)! Some modern readers automatically perform the three reads procedure, and the reads are also made with different voltage/current parameters; it's an incredible speed up of the whole process. Do not forget to save all resulting files with a sensible name, possibly following the standard convention for roms naming: label.position (e.g.: vb401.u14 ); if label is missing, number them yourself; if position is missing, skip it.<br /> <br /> <br /> ==Checking the dump==<br /> -stub-</div>

F205v https://wiki.mamedev.org/index.php?title=How_to_correctly_document_a_PCB&diff=5307 2017-03-28T07:15:50Z

<p>F205v: </p> <hr /> <div>PCBs (Printed Circuit Boards) are the source and the goal of the whole MAME project.<br /> They are the goal, because emulating their behaviour and their working mechanism is what MAME does.<br /> They are the source, because every information in a MAME driver comes directly from them; and because the driver itself is a &quot;virtual&quot; PCB, mimicking the real one.<br /> <br /> We'll focus therefore on how to correctly extract information from a PCB, and how to organize them in such a way that this information will be useful to MAMEDevs when they'll code a driver.<br /> <br /> Documenting a PCB is a 3 steps job:<br /> 1) taking pictures<br /> 2) dumping ROMs<br /> 3) writing documentation<br /> <br /> Each of the 3 steps will have a separate article in the near future, detailing everything that is needed to know; for the moment let's just have a quick look at them.<br /> <br /> 1) [[Taking pictures and other medias]] (like recording sounds and filming videos) is usually the first and easiest thing you can do with a PCB; no special expertise is needed for this task, just a little bit of patience and care.<br /> With a digital camera you should take pictures of the whole PCB, both front (component) and back (solder) side. If the PCB consists of different boards packed one over the other, separate them and take pictures individually. If you can connect the PCB to a cabinet or to a test rig, do it; and take pictures of the game at boot up, at title screen, at intro and attract mode, and during game as well.<br /> If your camera is capable of recording videos, film some seconds of the game during title / attract mode and in game. This task is needed if your PCB is particularly rare and good videos of the game are not available; filming kof2k is usually not needed ;)<br /> Same goes for game sound recordings, they could be needed by MAMEDevs if your game is rare or with a strange dedicated sound board. A game generating sounds out of a AY-3-8910 usually doesn't require any recording.<br /> <br /> 2) [[Dumping roms]] is somewhat considered the &quot;cool&quot; part of the documenting process; it isn't. It's a long and tedious task requiring dedicated equipment, extreme accuracy, electronics background and a forgiving better-half! ;)<br /> The minimum equipment required is an &quot;EPROM programmer&quot;: that is a dedicated hardware and software appliance, where you will put the EPROMs extracted from the PCB and &quot;read&quot; them. The software will then save the content in a file on your PC. Obviously an EPROM programmer capable of reading 10.000+ different kind of chips is better then one reading only some hundreds; and the cost for it will be proportional.<br /> You will probably also need one or more soldering irons, an hot air reworking station, some desoldering tools, pliers, screwdrivers, chip removers, etc.<br /> You will need to dump EVERYTHING that is dumpable on the PCB, so it will be PROMs, EPROMs, EEPROMs, maskROMs, flashROMs, PLDs, PALs, GALs, and everything else which contains a memory like MCUs and the like.<br /> You will need to dump every single chip a minimum of 3 times (possibly with different current/voltage levels), and compare the 3 reads to check if they match. If they don't you will have to figure out why, solve the problem and read them 3 times again.<br /> You will need to compare the files you dumped with already known files and check if there is any match.<br /> <br /> 3) Writing documentation is the last task for you, and it's even more tedious than dumping.<br /> All important parts of the PCB need to be listed, their function explained.<br /> Also the pictures you took in step 1 must be listed, as well as files you dumped in step 2.<br /> A meaningful description of the PCB is extremely important for MAMEDevs, they will only have it as a guide while coding a driver, so the more accurate you are the more likely there will be a working driver sooner or later.<br /> <br /> Isn't documenting PCBs tedious? Well, it's also extremely satisfactory and ego-building; when you correctly document a PCB, and in a few days you have it emulated in MAME, you can proudly pat yourself on the shoulder: a piece of the arcade games history has been preserved for the future, and you were a part of it!</div>

F205v https://wiki.mamedev.org/index.php?title=F205v&diff=1960 2009-03-22T21:32:37Z

<p>F205v: </p> <hr /> <div>f205v is the nickname used by Antonio Gerli, member of [[MAME Italia]] forum.</div>

F205v https://wiki.mamedev.org/index.php?title=Developer_WIPs&diff=1954 2009-03-09T21:25:27Z

<p>F205v: </p> <hr /> <div>These pages are here to serve as WIPs, to-do lists, or whatever else the developer wants to talk about here (as long as it's MAME related!)<br /> <br /> * [[Aaron's To-Do List]]<br /> * [[Ernesto's To-Do List]]<br /> * [[Phil B's To-Do List]]<br /> * [[Reip's To-Do List]]<br /> * [[Robbie's To-Do List]]<br /> * [[Arbee's To-Do List]]<br /> * [[Couriersud's To-Do List]]<br /> <br /> And here are links to individual developers' pages that are maintained elsewhere:<br /> <br /> * [http://mamelife.blogspot.com/ Nicola's MAME Ramblings]<br /> * [http://mamedev.emulab.it/haze/ David Haywood's Homepage]<br /> * [http://www.aarongiles.com/ Aaron Giles' Homepage]<br /> * [http://rbelmont.mameworld.info/ Arbee's WIP Emporium] (R. Belmont)<br /> * [http://avoidspikes.blogspot.com/ Avoid Spikes] (Frank Palazzolo)<br /> * [http://cgfm2.emuviews.com/ Charles MacDonald's Home Page]<br /> * [http://www.vcmame.net/wip/ VCMAME.NET] (Bryan McPhail)<br /> * [http://reip.mameworld.info/ Reip's MAME WIP] (Pierpaolo Prazzoli)<br /> * [http://doxdev.blogspot.com/ Tomasz Slanina]<br /> * [http://www.emulab.it/kale/ Angelo Salese Page]<br /> * [http://www.lucaelia.com/mame.php Luca's MAME Drivers] (Luca Elia)<br /> * [http://vlinde.mameworld.info/ Ville's Development Log] (Ville Linde)<br /> * [http://ajg.mameworld.info/ Drew's MAMEography] (Andrew Gardner)<br /> * [http://derrick.mameworld.info/ D's MAME Stuff] (Derrick Renaud)<br /> * [http://smf.mameworld.info/ smf's Blog]<br /> * [http://tourniquet.mameworld.info/ Tourniquet's MAME News] (Paul Priest)<br /> * [http://philwip.mameworld.info/ PhilWIP] (Philip Bennett)<br /> * [http://robbie.mameworld.info/ Risen From My Grave] (Roberto Fresca)<br /> * [http://www.manuelabadia.com/blog/CategoryView,category,Games.aspx Manuel Abadia]<br /> * [http://web.utanet.at/nkehrer/index.html Norbert's Emulators] (Norbert Kehrer)<br /> * [http://mamedev.emulab.it/robiza/ Robiza’s MAME blog] (Roberto Zandonà)</div>

F205v https://wiki.mamedev.org/index.php?title=Dumping_roms&diff=1951 2009-02-05T17:37:55Z

<p>F205v: </p> <hr /> <div>Let's have a look at the most difficult part of the documentation process: the dumping!&lt;br&gt;<br /> I usually go through a 3 steps path:&lt;br&gt;<br /> '''1)Components identification'''&lt;br&gt;<br /> '''2)Actually dumping them'''&lt;br&gt;<br /> '''3)Checking what I've done'''&lt;br&gt;<br /> <br /> ==Components identification.==<br /> On a standard PCB we will find one, more or even all of the following components: CPUs, TTLs, ROMs, RAMs, PLDs, Others.<br /> I use coloured water-markers (of the kind used to write on CDs) to mark each single component when it is correctly identified: green is for CPUs, blue for TTLs, gold for ROMs, purple for RAMs, silver for PLDs. This colour marking system is of great help when working on PCBs, it gives an immediate visual overview of what is what, it avoids missing out something important to dump, it saves a lot of time because I do not have to re-identify components when I look at a PCB after some time.<br /> <br /> ===CPUs===<br /> First thing we have to find the main CPU (maybe there are more than one!); it's usually the only chip whose size is remarkably different from all the others. We have to remember that [http://en.wikipedia.org/wiki/MOS_Technology_6502 6502], [http://en.wikipedia.org/wiki/Z80 Z80] and [http://en.wikipedia.org/wiki/68000 68000] are the most used CPUs in arcade game history, learning by heart what they look like is fundamental. Obviously each chip sports some writing (markings), and looking that up on the Internet is always a good way to confirm what a chip is. For CPUs identification I would recommend [http://www.cpu-world.com/ CPU-World] as a reference.<br /> Sound CPUs are usually found grouped together, close to the volume trimmer. Most common sound CPUs are M6295 (and clones) and all of the various YMxxxx.<br /> On some PCBs we will also find MCUs; they are like CPUs, but with an internal memory which is unfortunately read-protected 99% of the times.<br /> On some PCBs there will also be “support chips” like I/O chips, CRC controllers or Peripheral Interface Adapter; let's mark all of them green as well.<br /> <br /> ===TTLs===<br /> Second thing let's rule out all of the TTLs; they are easy to identify, because they are small (300mil) and marked 74xxx (in very old PCBs they can also be 54xxx), let's mark them blue. TTLs are usually the most common component, ranging from some tens to some hundreds of them on a single PCB. They are pure logical operators and are of very scarce interest for the dumper, apart from a few remarkable exceptions: 74s188, 287, 288, 370, 387, 471, 472, 473, 474, 570, 571, 572, 573. These are all PROMs, they have to be marked gold and are addressed here following.<br /> <br /> ===ROMs===<br /> Third thing is to correctly identify and colour mark ROMs. They come in a variety of forms: PROMs, EPROMs, EEPROMs, FlashROMs, MaskROMs. The most common are EPROMs, they sport a transparent window, they are 600mil, ranging from DIP24 to DIP42. In most PCBs they are socketed, and their extraction is very easy using a small flat screwdriver and slowly lifting them with small movements from BOTH sides to avoid any pin bending. MaskROMs are of the same size as EPROMs, but without the window, and very often they are soldered through the PCB. Removing them is a little bit more complicated, and the best suggestions for it can be found at [http://www.mameworld.net/gurudumps/tutorials/how_to_remove/index.html Guru's site]. EEPROMs and FlashROMs have different sizes, are usually SMD, and special adaptors are required to insert them into your programmer; adaptors could be rather expensive. Finally PROMs are small chips (300mil) usually soldered through and quite similar to TTLs, therefore learning by heart their specific markings and labels comes handy in many cases. A good reference is available [http://www.citylan.it/immagini/promref.txt here].<br /> <br /> ===RAMs===<br /> Fourth thing are RAMs, they come in many sizes, from long 300mil to thin 600mil to other (less common) sizes. Mark them out, because you will need to mention them in the documentation.<br /> <br /> ===PLDs===<br /> Fifth thing is to find out if any PLD is on your PCB. To understand what a PLD is, please refer to this very good article on [http://en.wikipedia.org/wiki/Programmable_logic_device wikipedia]. PLDs always incorporate a “read protect” feature, in 95% of the case it's activated by the producer; until recently it was impossible to read them, a dumper simply gave them a try hoping to be lucky and get into the 5% which is not protected. Recently [http://cgfm2.emuviews.com/index.php Charles McDonald] found a way to read also a certain category of PLDs (the most common on arcade PCBs), so the above situation is changing.<br /> <br /> ===Others===<br /> Sixth and last thing is to identify all other components of the PCB. You will find resistors, trimmers, LEDs, audio parts, heat exchangers, connectors, jumpers, switches and a lot of other things. You will need to describe them in the documentation as well.<br /> <br /> <br /> ==Components dumping==<br /> Dumping memory chips is the core part of the whole dumping process. It basically requires an EPROM programmer, a PC and some dedication. I'm not going into describing various EPROM programmers, their pros and cons, what they can do and the like. There are too many of them, let's assume that you know how your EPROM programmer works.&lt;br&gt;<br /> Before inserting chips into the programmer's socket you have to check for all the legs to be clean and straight. If any rust or dirt is on the legs, use a piece of very fine sand-paper to clean them, on all sides (internal, external and in-between legs). If legs are bent use a small plier (or your fingers) to straight them back; be very gentle and use a very minimum of force, it's easy to break them.&lt;br&gt;<br /> Then insert your chip into the programmer, configure your software accordingly to the make/model of the chip you have inserted, read it and save the result in a safe place. Now comes the very important part: remove the chip, clean the cache of the software, insert back the chip and read it again. Then do all of this a third time. Only if the three reads are IDENTICAL (check it with crc32) then you have a good dump. If there is any difference, start again from the cleaning part of the procedure. Sometimes, even after perfectly cleaning and polishing all the legs, you can not get a constant read of a chip. In this case try to read it with a slightly different voltage/current if your reader supports such a feature; firstly try with ±5%, eventually with ±10%. Do not go beyond ±10%, you will risk to ruin both the chip (not so important) and your programmer (much more important)! Some modern readers automatically perform the three reads procedure, and the reads are also made with different voltage/current parameters; it's an incredible speed up of the whole process. Do not forget to save all resulting files with a sensible name, possibly following the standard convention for roms naming: label.position (e.g.: vb401.u14 ); if label is missing, number them yourself; if position is missing, skip it.<br /> <br /> <br /> ==Checking the dump==<br /> -stub-</div>

F205v https://wiki.mamedev.org/index.php?title=Dumping_roms&diff=1949 2009-01-22T10:16:24Z

<p>F205v: </p> <hr /> <div>Let's have a look at the most difficult part of the documentation process: the dumping!<br /> I usually go through a 3 steps path:<br /> '''1)'''Components identification<br /> '''2)'''Actually dumping them<br /> '''3)'''Checking what I've done<br /> <br /> <br /> '''1- Components identification.'''<br /> On a standard PCB we will find one, more or even all of the following components: CPUs, TTLs, ROMs, RAMs, PLDs, Others.<br /> I use coloured water-markers (of the kind used to write on CDs) to mark each single component when it is correctly identified: green is for CPUs, blue for TTLs, gold for ROMs, purple for RAMs, silver for PLDs. This colour marking system is of great help when working on PCBs, it gives an immediate visual overview of what is what, it avoids missing out something important to dump, it saves a lot of time because I do not have to re-identify components when I look at a PCB after some time.<br /> <br /> First thing we have to find the main CPU (maybe there are more than one!); it's usually the only chip whose size is remarkably different from all the others. We have to remember that [http://en.wikipedia.org/wiki/MOS_Technology_6502 6502], [http://en.wikipedia.org/wiki/Z80 Z80] and [http://en.wikipedia.org/wiki/68000 68000] are the most used CPUs in arcade game history, learning by heart what they look like is fundamental. Obviously each chip sports some writing (markings), and looking that up on the Internet is always a good way to confirm what a chip is. For CPUs identification I would recommend [http://www.cpu-world.com/ CPU-World] as a reference.<br /> Sound CPUs are usually found grouped together, close to the volume trimmer. Most common sound CPUs are M6295 (and clones) and all of the various YMxxxx.<br /> On some PCBs we will also find MCUs; they are like CPUs, but with an internal memory which is unfortunately read-protected 99% of the times.<br /> On some PCBs there will also be “support chips” like I/O chips, CRC controllers or Peripheral Interface Adapter; let's mark all of them green as well.<br /> <br /> Second thing let's rule out all of the TTLs; they are easy to identify, because they are small (300mil) and marked 74xxx (in very old PCBs they can also be 54xxx), let's mark them blue. TTLs are usually the most common component, ranging from some tens to some hundreds of them on a single PCB. They are pure logical operators and are of very scarce interest for the dumper, apart from a few remarkable exceptions: 74s188, 287, 288, 370, 387, 471, 472, 473, 474, 570, 571, 572, 573. These are all PROMs, they have to be marked gold and are addressed here following.<br /> <br /> Third thing is to correctly identify and colour mark ROMs. They come in a variety of forms: PROMs, EPROMs, EEPROMs, FlashROMs, MaskROMs. The most common are EPROMs, they sport a transparent window, they are 600mil, ranging from DIP24 to DIP42. In most PCBs they are socketed, and their extraction is very easy using a small flat screwdriver and slowly lifting them with small movements from BOTH sides to avoid any pin bending. MaskROMs are of the same size as EPROMs, but without the window, and very often they are soldered through the PCB. Removing them is a little bit more complicated, and the best suggestions for it can be found at [http://www.mameworld.net/gurudumps/tutorials/how_to_remove/index.html Guru's site]. EEPROMs and FlashROMs have different sizes, are usually SMD, and special adaptors are required to insert them into your programmer; adaptors could be rather expensive. Finally PROMs are small chips (300mil) usually soldered through and quite similar to TTLs, therefore learning by heart their specific markings and labels comes handy in many cases. A good reference is available [http://www.citylan.it/immagini/promref.txt here].<br /> <br /> Fourth thing are RAMs, they come in many sizes, from long 300mil to thin 600mil to other (less common) sizes. Mark them out, because you will need to mention them in the documentation.<br /> <br /> Fifth thing is to find out if any PLD is on your PCB. To understand what a PLD is, please refer to this very good article on [http://en.wikipedia.org/wiki/Programmable_logic_device wikipedia]. PLDs always incorporate a “read protect” feature, in 95% of the case it's activated by the producer; until recently it was impossible to read them, a dumper simply gave them a try hoping to be lucky and get into the 5% which is not protected. Recently [http://cgfm2.emuviews.com/index.php Charles McDonald] found a way to read also a certain category of PLDs (the most common on arcade PCBs), so the above situation is changing.<br /> <br /> Sixth and last thing is to identify all other components of the PCB. You will find resistors, trimmers, LEDs, audio parts, heat exchangers, connectors, jumpers, switches and a lot of other things. You will need to describe them in the documentation as well.<br /> <br /> <br /> '''2- Components dumping'''<br /> Dumping memory chips is the core part of the whole dumping process. It basically requires an EPROM programmer, a PC and some dedication. I'm not going into describing various EPROM programmers, their pros and cons, what they can do and the like. There are too many of them, let's assume that you know how your EPROM programmer works.<br /> <br /> Before inserting chips into the programmer's socket you have to check for all the legs to be clean and straight. If any rust or dirt is on the legs, use a piece of very fine sand-paper to clean them, on all sides (internal, external and in-between legs). If legs are bent use a small plier (or your fingers) to straight them back; be very gentle and use a very minimum of force, it's easy to break them. Then insert your chip into the programmer, configure your software accordingly to the make/model of the chip you have inserted, read it and save the result in a safe place.<br /> <br /> Now comes the very important part: remove the chip, clean the cache of the software, insert back the chip and read it again. Then do all of this a third time. Only if the three reads are IDENTICAL (check it with crc32) then you have a good dump. If there is any difference, start again from the cleaning part of the procedure. Sometimes, even after perfectly cleaning and polishing all the legs, you can not get a constant read of a chip. In this case try to read it with a slightly different voltage/current if your reader supports such a feature; firstly try with ±5%, eventually with ±10%. Do not go beyond ±10%, you will risk to ruin both the chip (not so important) and your programmer (much more important)! Some modern readers automatically perform the three reads procedure, and the reads are also made with different voltage/current parameters; it's an incredible speed up of the whole process.<br /> <br /> Do not forget to save all resulting files with a sensible name, possibly following the standard convention for roms naming: label.position (e.g.: vb401.u14 ); if label is missing, number them yourself; if position is missing, skip it.<br /> <br /> '''3- checking the dump'''<br /> -stub-</div>

F205v https://wiki.mamedev.org/index.php?title=Dumping_roms&diff=1938 2008-12-10T13:00:12Z

<p>F205v: </p> <hr /> <div>Let's have a look at the most difficult part of the documentation process: the dumping!<br /> I usually go through a 3 steps path:<br /> '''1)'''Components identification<br /> '''2)'''Actually dumping them<br /> '''3)'''Checking what I've done<br /> <br /> <br /> '''1- Components identification.'''<br /> On a standard PCB we will find one, more or even all of the following components: CPUs, TTLs, ROMs, RAMs, PLDs, Others.<br /> I use coloured water-markers (of the kind used to write on CDs) to mark each single component when it is correctly identified: green is for CPUs, blue for TTLs, gold for ROMs, purple for RAMs, silver for PLDs. This colour marking system is of great help when working on PCBs, it gives an immediate visual overview of what is what, it avoids missing out something important to dump, it saves a lot of time because I do not have to re-identify components when I look at a PCB after some time.<br /> <br /> First thing we have to find the main CPU (maybe there are more than one!); it's usually the only chip whose size is remarkably different from all the others. We have to remember that [http://en.wikipedia.org/wiki/MOS_Technology_6502 6502], [http://en.wikipedia.org/wiki/Z80 Z80] and [http://en.wikipedia.org/wiki/68000 68000] are the most used CPUs in arcade game history, learning by heart what they look like is fundamental. Obviously each chip sports some writing (markings), and looking that up on the Internet is always a good way to confirm what a chip is. For CPUs identification I would recommend [http://www.cpu-world.com/ CPU-World] as a reference.<br /> Sound CPUs are usually found grouped together, close to the volume trimmer. Most common sound CPUs are M6295 (and clones) and all of the various YMxxxx.<br /> On some PCBs we will also find MCUs; they are like CPUs, but with an internal memory which is unfortunately read-protected 99% of the times.<br /> On some PCBs there will also be “support chips” like I/O chips, CRC controllers or Peripheral Interface Adapter; let's mark all of them green as well.<br /> <br /> Second thing let's rule out all of the TTLs; they are easy to identify, because they are small (300mil) and marked 74xxx (in very old PCBs they can also be 54xxx), let's mark them blue. TTLs are usually the most common component, ranging from some tens to some hundreds of them on a single PCB. They are pure logical operators and are of very scarce interest for the dumper, apart from a few remarkable exceptions: 74s188, 287, 288, 370, 387, 471, 472, 473, 474, 570, 571, 572, 573. These are all PROMs, they have to be marked gold and are addressed here following.<br /> <br /> Third thing is to correctly identify and colour mark ROMs. They come in a variety of forms: PROMs, EPROMs, EEPROMs, FlashROMs, MaskROMs. The most common are EPROMs, they sport a transparent window, they are 600mil, ranging from DIP24 to DIP42. In most PCBs they are socketed, and their extraction is very easy using a small flat screwdriver and slowly lifting them with small movements from BOTH sides to avoid any pin bending. MaskROMs are of the same size as EPROMs, but without the window, and very often they are soldered through the PCB. Removing them is a little bit more complicated, and the best suggestions for it can be found at [http://www.mameworld.net/gurudumps/tutorials/how_to_remove/index.html Guru's site]. EEPROMs and FlashROMs have different sizes, are usually SMD, and special adaptors are required to insert them into your programmer; adaptors could be rather expensive. Finally PROMs are small chips (300mil) usually soldered through and quite similar to TTLs, therefore learning by heart their specific markings and labels comes handy in many cases. A good reference is available [http://www.citylan.it/immagini/promref.txt here].<br /> <br /> Fourth thing are RAMs, they come in many sizes, from long 300mil to thin 600mil to other (less common) sizes. Mark them out, because you will need to mention them in the documentation.<br /> <br /> Fifth thing is to find out if any PLD is on your PCB. To understand what a PLD is, please refer to this very good article on [http://en.wikipedia.org/wiki/Programmable_logic_device wikipedia]. PLDs always incorporate a “read protect” feature, in 95% of the case it's activated by the producer; until recently it was impossible to read them, a dumper simply gave them a try hoping to be lucky and get into the 5% which is not protected. Recently [http://cgfm2.emuviews.com/index.php Charles McDonald] found a way to read also a certain category of PLDs (the most common on arcade PCBs), so the above situation is changing.<br /> <br /> Sixth and last thing is to identify all other components of the PCB. You will find resistors, trimmers, LEDs, audio parts, heat exchangers, connectors, jumpers, switches and a lot of other things. You will need to describe them in the documentation as well.<br /> <br /> <br /> '''2- Components dumping'''<br /> Dumping memory chips is the core part of the whole dumping process. It basically requires an EPROM programmer, a PC and some dedication. I'm not going into describing various EPROM programmers, their pros and cons, what they can do and the like. There are too many of them, let's assume that you know how your EPROM programmer works.<br /> Before inserting chips into the programmer's socket you have to check for all the legs to be clean and straight. If any rust or dirt is on the legs, use a piece of very fine sand-paper to clean them, on all sides (internal, external and in-between legs). If legs are bent use a small plier (or your fingers) to straight them back; be very gentle and use a very minimum of force, it's easy to break them.<br /> Then insert your chip into the programmer, configure your software accordingly to the make/model of the chip you have inserted, read it and save the result in a safe place. Now comes the very important part: remove the chip, clean the cache of the software, insert back the chip and read it again. Then do all of this a third time. Only if the three reads are IDENTICAL (check it with crc32) then you have a good dump. If there is any difference, start again from the cleaning part of the procedure. Sometimes, even after perfectly cleaning and polishing all the legs, you can not get a constant read of a chip. In this case try to read it with a slightly different voltage/current if your reader supports such a feature; firstly try with ±5%, eventually with ±10%. Do not go beyond ±10%, you will risk to ruin both the chip (not so important) and your programmer (much more important)! Some modern readers automatically perform the three reads procedure, and the reads are also made with different voltage/current parameters; it's an incredible speed up of the whole process. Do not forget to save all resulting files with a sensible name, possibly following the standard convention for roms naming: label.position (e.g.: vb401.u14 ); if label is missing, number them yourself; if position is missing, skip it.<br /> <br /> '''3- checking the dump'''<br /> -stub-</div>

F205v https://wiki.mamedev.org/index.php?title=Dumping_roms&diff=1937 2008-12-10T12:58:54Z

<p>F205v: </p> <hr /> <div>Let's have a look at the most difficult part of the documentation process: the dumping!<br /> I usually go through a 3 steps path:<br /> '''1)'''Components identification<br /> '''2)'''Actually dumping them<br /> '''3)'''Checking what I've done<br /> <br /> <br /> '''1- Components identification.'''<br /> On a standard PCB we will find one, more or even all of the following components: CPUs, TTLs, ROMs, RAMs, PLDs, Others.<br /> I use coloured water-markers (of the kind used to write on CDs) to mark each single component when it is correctly identified: green is for CPUs, blue for TTLs, gold for ROMs, purple for RAMs, silver for PLDs. This colour marking system is of great help when working on PCBs, it gives an immediate visual overview of what is what, it avoids missing out something important to dump, it saves a lot of time because I do not have to re-identify components when I look at a PCB after some time.<br /> <br /> First thing we have to find the main CPU (maybe there are more than one!); it's usually the only chip whose size is remarkably different from all the others. We have to remember that [http://en.wikipedia.org/wiki/MOS_Technology_6502 6502], [http://en.wikipedia.org/wiki/Z80 Z80] and [http://en.wikipedia.org/wiki/68000 68000] are the most used CPUs in arcade game history, learning by heart what they look like is fundamental. Obviously each chip sports some writing (markings), and looking that up on the Internet is always a good way to confirm what a chip is. For CPUs identification I would recommend [http://www.cpu-world.com/ CPU-World] as a reference.<br /> Sound CPUs are usually found grouped together, close to the volume trimmer. Most common sound CPUs are M6295 (and clones) and all of the various YMxxxx.<br /> On some PCBs we will also find MCUs; they are like CPUs, but with an internal memory which is unfortunately read-protected 99% of the times.<br /> On some PCBs there will also be “support chips” like I/O chips, CRC controllers or Peripheral Interface Adapter; let's mark all of them green as well.<br /> <br /> Second thing let's rule out all of the TTLs; they are easy to identify, because they are small (300mil) and marked 74xxx (in very old PCBs they can also be 54xxx), let's mark them blue. TTLs are usually the most common component, ranging from some tens to some hundreds of them on a single PCB. They are pure logical operators and are of very scarce interest for the dumper, apart from a few remarkable exceptions: 74s188, 287, 288, 370, 387, 471, 472, 473, 474, 570, 571, 572, 573. These are all PROMs, they have to be marked gold and are addressed here following.<br /> <br /> Third thing is to correctly identify and colour mark ROMs. They come in a variety of forms: PROMs, EPROMs, EEPROMs, FlashROMs, MaskROMs. The most common are EPROMs, they sport a transparent window, they are 600mil, ranging from DIP24 to DIP42. In most PCBs they are socketed, and their extraction is very easy using a small flat screwdriver and slowly lifting them with small movements from BOTH sides to avoid any pin bending. MaskROMs are of the same size as EPROMs, but without the window, and very often they are soldered through the PCB. Removing them is a little bit more complicated, and the best suggestions for it can be found at [http://www.mameworld.net/gurudumps/tutorials/how_to_remove/index.html Guru's site]. EEPROMs and FlashROMs have different sizes, are usually SMD, and special adaptors are required to insert them into your programmer; adaptors could be rather expensive. Finally PROMs are small chips (300mil) usually soldered through and quite similar to TTLs, therefore learning by heart their specific markings and labels comes handy in many cases. A good reference is available [http://www.citylan.it/immagini/promref.txt here].<br /> <br /> Fourth thing are RAMs, they come in many sizes, from long 300mil to thin 600mil to other (less common) sizes. Mark them out, because you will need to mention them in the documentation.<br /> <br /> Fifth thing is to find out if any PLD is on your PCB. To understand what a PLD is, please refer to this very good article on [http://en.wikipedia.org/wiki/Programmable_logic_device wikipedia]. PLDs always incorporate a “read protect” feature, in 95% of the case it's activated by the producer; until recently it was impossible to read them, a dumper simply gave them a try hoping to be lucky and get into the 5% which is not protected. Recently [http://cgfm2.emuviews.com/index.php Charles McDonald] found a way to read also a certain category of PLDs (the most common on arcade PCBs), so the above situation is changing.<br /> <br /> Sixth and last thing is to identify all other components of the PCB. You will find resistors, trimmers, LEDs, audio parts, heat exchangers, connectors, jumpers, switches and a lot of other things. You will need to describe them in the documentation as well.<br /> <br /> <br /> '''2- Components dumping'''<br /> Dumping memory chips is the core part of the whole dumping process. It basically requires an EPROM programmer, a PC and some dedication. I'm not going into describing various EPROM programmers, their pros and cons, what they can do and the like. There are too many of them, let's assume that you know how your EPROM programmer works.<br /> Before inserting chips into the programmer's socket you have to check for all the legs to be clean and straight. If any rust or dirt is on the legs, use a piece of very fine sand-paper to clean them, on all sides (internal, external and in-between legs). If legs are bent use a small plier (or your fingers) to straight them back; be very gentle and use a very minimum of force, it's easy to break them.<br /> Then insert your chip into the programmer, configure your software accordingly to the make/model of the chip you have inserted, read it and save the result in a safe place. Now comes the very important part: remove the chip, clean the cache of the software, insert back the chip and read it again. Then to all of this a third time. Only if the three reads are IDENTICAL (check it with crc32) then you have a good dump. If there is any difference, start again from the cleaning part of the procedure. Sometimes, even after perfectly cleaning and polishing all the legs, you can not get a constant read of a chip. In this case try to read it with a slightly different voltage/current if your reader supports such a feature; firstly try with ±5%, eventually with ±10%. Do not go beyond ±10%, you will risk to ruin both the chip (not so important) and your programmer (much more important)! Some modern readers automatically perform the three reads procedure, and the reads are also made with different voltage/current parameters; it's an incredible speed up of the whole process. Do not forget to save all resulting files with a sensible name, possibly following the standard convention for roms naming: label.position (e.g.: vb401.u14 ); if label is missing, number them yourself; if position is missing, skip it.<br /> <br /> '''3- checking the dump'''<br /> -stub-</div>

F205v https://wiki.mamedev.org/index.php?title=Dumping_roms&diff=1933 2008-11-17T11:41:32Z

<p>F205v: </p> <hr /> <div>Let's have a look at the most difficult part of the documentation process: the dumping!<br /> I usually go through a 3 steps path:<br /> '''1)'''Components identification<br /> '''2)'''Actually dumping them<br /> '''3)'''Checking what I've done<br /> <br /> <br /> '''1- Components identification.'''<br /> On a standard PCB we will find one, more or even all of the following components: CPUs, TTLs, ROMs, RAMs, PLDs, Others.<br /> I use coloured water-markers (of the kind used to write on CDs) to mark each single component when it is correctly identified: green is for CPUs, blue for TTLs, gold for ROMs, purple for RAMs, silver for PLDs. This colour marking system is of great help when working on PCBs, it gives an immediate visual overview of what is what, it avoids missing out something important to dump, it saves a lot of time because I do not have to re-identify components when I look at a PCB after some time.<br /> <br /> First thing we have to find the main CPU (maybe there are more than one!); it's usually the only chip whose size is remarkably different from all the others. We have to remember that [http://en.wikipedia.org/wiki/MOS_Technology_6502 6502], [http://en.wikipedia.org/wiki/Z80 Z80] and [http://en.wikipedia.org/wiki/68000 68000] are the most used CPUs in arcade game history, learning by heart what they look like is fundamental. Obviously each chip sports some writing (markings), and looking that up on the Internet is always a good way to confirm what a chip is. For CPUs identification I would recommend [http://www.cpu-world.com/ CPU-World] as a reference.<br /> Sound CPUs are usually found grouped together, close to the volume trimmer. Most common sound CPUs are M6295 (and clones) and all of the various YMxxxx.<br /> On some PCBs we will also find MCUs; they are like CPUs, but with an internal memory which is unfortunately read-protected 99% of the times.<br /> On some PCBs there will also be “support chips” like I/O chips, CRC controllers or Peripheral Interface Adapter; let's mark all of them green as well.<br /> <br /> Second thing let's rule out all of the TTLs; they are easy to identify, because they are small (300mil) and marked 74xxx (in very old PCBs they can also be 54xxx), let's mark them blue. TTLs are usually the most common component, ranging from some tens to some hundreds of them on a single PCB. They are pure logical operators and are of very scarce interest for the dumper, apart from a few remarkable exceptions: 74s188, 287, 288, 370, 387, 471, 472, 473, 474, 570, 571, 572, 573. These are all PROMs, they have to be marked gold and are addressed here following.<br /> <br /> Third thing is to correctly identify and colour mark ROMs. They come in a variety of forms: PROMs, EPROMs, EEPROMs, FlashROMs, MaskROMs. The most common are EPROMs, they sport a transparent window, they are 600mil, ranging from DIP24 to DIP42. In most PCBs they are socketed, and their extraction is very easy using a small flat screwdriver and slowly lifting them with small movements from BOTH sides to avoid any pin bending. MaskROMs are of the same size as EPROMs, but without the window, and very often they are soldered through the PCB. Removing them is a little bit more complicated, and the best suggestions for it can be found at [http://www.mameworld.net/gurudumps/tutorials/how_to_remove/index.html Guru's site]. EEPROMs and FlashROMs have different sizes, are usually SMD, and special adaptors are required to insert them into your programmer; adaptors could be rather expensive. Finally PROMs are small chips (300mil) usually soldered through and quite similar to TTLs, therefore learning by heart their specific markings and labels comes handy in many cases. A good reference is available [http://www.citylan.it/immagini/promref.txt here].<br /> <br /> Fourth thing are RAMs, they come in many sizes, from long 300mil to thin 600mil to other (less common) sizes. Mark them out, because you will need to mention them in the documentation.<br /> <br /> Fifth thing is to find out if any PLD is on your PCB. To understand what a PLD is, please refer to this very good article on [http://en.wikipedia.org/wiki/Programmable_logic_device wikipedia]. PLDs always incorporate a “read protect” feature, in 95% of the case it's activated by the producer; until recently it was impossible to read them, a dumper simply gave them a try hoping to be lucky and get into the 5% which is not protected. Recently [http://cgfm2.emuviews.com/index.php Charles McDonald] found a way to read also a certain category of PLDs (the most common on arcade PCBs), so the above situation is changing.<br /> <br /> Sixth and last thing is to identify all other components of the PCB. You will find resistors, trimmers, LEDs, audio parts, heat exchangers, connectors, jumpers, switches and a lot of other things. You will need to describe them in the documentation as well.<br /> <br /> <br /> '''2- Components dumping'''<br /> -stub-<br /> <br /> <br /> '''3- checking the dump'''<br /> -stub-</div>

F205v https://wiki.mamedev.org/index.php?title=Dumping_roms&diff=1932 2008-11-09T23:03:42Z

<p>F205v: </p> <hr /> <div>Let's have a look at the most difficult part of the documentation process: the dumping!<br /> I usually go through a 3 steps path:<br /> 1)Components identification<br /> 2)Actually dumping them<br /> 3)Checking what I've done<br /> <br /> <br /> 1- Components identification.<br /> On a standard PCB we will find one, more or even all of the following components: CPUs, TTLs, ROMs, RAMs, PLDs, Others.<br /> I use coloured water-markers (of the kind used to write on CDs) to mark each single component when it is correctly identified: green is for CPUs, blue for TTLs, gold for ROMs, purple for RAMs, silver for PLDs. This colour marking system is of great help when working on PCBs, it gives an immediate visual overview of what is what, it avoids missing out something important to dump, it saves a lot of time because I do not have to re-identify components when I look at a PCB after some time.<br /> <br /> First thing we have to find the main CPU (maybe there are more than one!); it's usually the only chip whose size is remarkably different from all the others. We have to remember that 6502, Z80 and 68000 are the most used CPUs in arcade game history, learning by heart what they look like is fundamental. Obviously each chip sports some writing (markings), and looking that up on the Internet is always a good way to confirm what a chip is. For CPUs identification I would recommend [http://www.cpu-world.com/ CPU-World] as a reference.<br /> Sound CPUs are usually found grouped together, close to the volume trimmer. Most common sound CPUs are M6295 (and clones) and all of the various YMxxxx.<br /> On some PCBs we will also find MCUs; they are like CPUs, but with an internal memory which is unfortunately read-protected 99% of the times.<br /> On some PCBs there will also be “support chips” like I/O chips, CRC controllers or Peripheral Interface Adapter; let's mark all of them green as well.<br /> <br /> Second thing let's rule out all of the TTLs; they are easy to identify, because they are small (300mil) and marked 74xxx (in very old PCBs they can also be 54xxx), let's mark them blue. TTLs are usually the most common component, ranging from some tens to some hundreds of them on a single PCB. They are pure logical operators and are of very scarce interest for the dumper, apart from a few remarkable exceptions: 74s188, 287, 288, 370, 387, 471, 472, 473, 474, 570, 571, 572, 573. These are all PROMs, they have to be marked gold and are addressed here following.<br /> <br /> Third thing is to correctly identify and colour mark ROMs. They come in a variety of forms: PROMs, EPROMs, EEPROMs, FlashROMs, MaskROMs. The most common are EPROMs, they sport a transparent window, they are 600mil, ranging from DIP24 to DIP42. In most PCBs they are socketed, and their extraction is very easy using a small flat screwdriver and slowly lifting them with small movements from BOTH sides to avoid any pin bending. MaskROMs are of the same size as EPROMs, but without the window, and very often they are soldered through the PCB. Removing them is a little bit more complicated, and the best suggestions for it can be found at Guru's site. EEPROMs and FlashROMs have different sizes, are usually SMD, and special adaptors are required to insert them into your programmer; adaptors could be rather expensive. Finally PROMs are small chips (300mil) usually soldered through and quite similar to TTLs, therefore learning by heart their specific markings and labels comes handy in many cases. A good reference is available [http://www.citylan.it/immagini/promref.txt here].<br /> <br /> Fourth thing are RAMs, they come in many sizes, from long 300mil to thin 600mil to other (less common) sizes. Mark them out, because you will need to mention them in the documentation.<br /> <br /> Fifth thing is to find out if any PLD is on your PCB. To understand what a PLD is, please refer to this very good article on [http://en.wikipedia.org/wiki/Programmable_logic_device wikipedia]. PLDs always incorporate a “read protect” feature, in 95% of the case it's activated by the producer; until recently it was impossible to read them, a dumper simply gave them a try hoping to be lucky and get into the 5% which is not protected. Recently [http://cgfm2.emuviews.com/index.php Charles McDonald] found a way to read also a certain category of PLDs (the most common on arcade PCBs), so the above situation is changing.<br /> <br /> Sixth and last thing is to identify all other components of the PCB. You will find resistors, trimmers, LEDs, audio parts, heat exchangers, connectors, jumpers, switches and a lot of other things. You will need to describe them in the documentation as well.<br /> <br /> <br /> 2- Components dumping<br /> -stub-<br /> <br /> <br /> 3- checking the dump<br /> -stub-</div>

F205v https://wiki.mamedev.org/index.php?title=Dumping_roms&diff=1931 2008-11-09T22:56:33Z

<p>F205v: </p> <hr /> <div>Let's have a look at the most difficult part of the documentation process: the dumping!<br /> I usually go through a 3 steps path:<br /> 1)Components identification<br /> 2)Actually dumping them<br /> 3)Checking what I've done<br /> <br /> <br /> 1- Components identification.<br /> On a standard PCB we will find one, more or even all of the following components: CPUs, TTLs, ROMs, RAMs, PLDs, Others.<br /> I use coloured water-markers (of the kind used to write on CDs) to mark each single component when it is correctly identified: green is for CPUs, blue for TTLs, gold for ROMs, purple for RAMs, silver for PLDs. This colour marking system is of great help when working on PCBs, it gives an immediate visual overview of what is what, it avoids missing out something important to dump, it saves a lot of time because I do not have to re-identify components when I look at a PCB after some time.<br /> <br /> First thing we have to find the main CPU (maybe there are more than one!); it's usually the only chip whose size is remarkably different from all the others. We have to remember that 6502, Z80 and 68000 are the most used CPUs in arcade game history, learning by heart what they look like is fundamental. Obviously each chip sports some writing (markings), and looking that up on the Internet is always a good way to confirm what a chip is. For CPUs identification I would recommend [http://www.cpu-world.com/ CPU-World] as a reference.<br /> Sound CPUs are usually found grouped together, close to the volume trimmer. Most common sound CPUs are M6295 (and clones) and all of the various YMxxxx.<br /> On some PCBs we will also find MCUs; they are like CPUs, but with an internal memory which is unfortunately read-protected 99% of the times.<br /> On some PCBs there will also be “support chips” like I/O chips, CRC controllers or Peripheral Interface Adapter; let's mark all of them green as well.<br /> <br /> Second thing let's rule out all of the TTLs; they are easy to identify, because they are small (300mil) and marked 74xxx (in very old PCBs they can also be 54xxx), let's mark them blue. TTLs are usually the most common component, ranging from some tens to some hundreds of them on a single PCB. They are pure logical operators and are of very scarce interest for the dumper, apart from a few remarkable exceptions: 74s188, 287, 288, 370, 387, 471, 472, 473, 474, 570, 571, 572, 573. These are all PROMs, they have to be marked gold and are addressed here following.<br /> <br /> Third thing is to correctly identify and colour mark ROMs. They come in a variety of forms: PROMs, EPROMs, EEPROMs, FlashROMs, MaskROMs. The most common are EPROMs, they sport a transparent window, they are 600mil, ranging from DIP24 to DIP42. In most PCBs they are socketed, and their extraction is very easy using a small flat screwdriver and slowly lifting them with small movements from BOTH sides to avoid any pin bending. MaskROMs are of the same size as EPROMs, but without the window, and very often they are soldered through the PCB. Removing them is a little bit more complicated, and the best suggestions for it can be found at Guru's site. EEPROMs and FlashROMs have different sizes, are usually SMD, and special adaptors are required to insert them into your programmer; adaptors could be rather expensive. Finally PROMs are small chips (300mil) usually soldered through and quite similar to TTLs, therefore learning by heart their specific markings and labels comes handy in many cases. A good reference is available [http://www.citylan.it/immagini/promref.txt here].<br /> <br /> Fourth thing are RAMs, they come in many sizes, from long 300mil to thin 600mil to other (less common) sizes. Mark them out, because you will need to mention them in the documentation.<br /> <br /> Fifth thing is to find out if any PLD is on your PCB. To understand what a PLD is, please refer to this very good article on wikipedia. PLDs always incorporate a “read protect” feature, in 95% of the case it's activated by the producer; until recently it was impossible to read them, a dumper simply gave them a try hoping to be lucky and get into the 5% which is not protected. Recently “C. McDonald” found a way to read also a certain category of PLDs (the most common on arcade PCBs), so the above situation is changing.<br /> <br /> Sixth and last thing is to identify all other components of the PCB. You will find resistors, trimmers, LEDs, audio parts, heat exchangers, connectors, jumpers, switches and a lot of other things. You will need to describe them in the documentation as well.<br /> <br /> <br /> 2- Components dumping<br /> -stub-<br /> <br /> <br /> 3- checking the dump<br /> -stub-</div>

F205v https://wiki.mamedev.org/index.php?title=Dumping_roms&diff=1930 2008-11-09T22:53:10Z

<p>F205v: </p> <hr /> <div>Let's have a look at the most difficult part of the documentation process: the dumping!<br /> I usually go through a 3 steps path:<br /> 1)Components identification<br /> 2)Actually dumping them<br /> 3)Checking what I've done<br /> <br /> <br /> 1- Components identification.<br /> On a standard PCB we will find one, more or even all of the following components: CPUs, TTLs, ROMs, RAMs, PLDs, Others.<br /> I use coloured water-markers (of the kind used to write on CDs) to mark each single component when it is correctly identified: green is for CPUs, blue for TTLs, gold for ROMs, purple for RAMs, silver for PLDs. This colour marking system is of great help when working on PCBs, it gives an immediate visual overview of what is what, it avoids missing out something important to dump, it saves a lot of time because I do not have to re-identify components when I look at a PCB after some time.<br /> <br /> First thing we have to find the main CPU (maybe there are more than one!); it's usually the only chip whose size is remarkably different from all the others. We have to remember that 6502, Z80 and 68000 are the most used CPUs in arcade game history, learning by heart what they look like is fundamental. Obviously each chip sports some writing (markings), and looking that up on the Internet is always a good way to confirm what a chip is. For CPUs identification I would recommend [http://www.cpu-world.com/ CPU-World] as a reference.<br /> Sound CPUs are usually found grouped together, close to the volume trimmer. Most common sound CPUs are M6295 (and clones) and all of the various YMxxxx.<br /> On some PCBs we will also find MCUs; they are like CPUs, but with an internal memory which is unfortunately read-protected 99% of the times.<br /> On some PCBs there will also be “support chips” like I/O chips, CRC controllers or Peripheral Interface Adapter; let's mark all of them green as well.<br /> <br /> Second thing let's rule out all of the TTLs; they are easy to identify, because they are small (300mil) and marked 74xxx (in very old PCBs they can also be 54xxx), let's mark them blue. TTLs are usually the most common component, ranging from some tens to some hundreds of them on a single PCB. They are pure logical operators and are of very scarce interest for the dumper, apart from a few remarkable exceptions: 74s188, 287, 288, 370, 387, 471, 472, 473, 474, 570, 571, 572, 573. These are all PROMs, they have to be marked gold and are addressed here following.<br /> <br /> Third thing is to correctly identify and colour mark ROMs. They come in a variety of forms: PROMs, EPROMs, EEPROMs, FlashROMs, MaskROMs. The most common are EPROMs, they sport a transparent window, they are 600mil, ranging from DIP24 to DIP42. In most PCBs they are socketed, and their extraction is very easy using a small flat screwdriver and slowly lifting them with small movements from BOTH sides to avoid any pin bending. MaskROMs are of the same size as EPROMs, but without the window, and very often they are soldered through the PCB. Removing them is a little bit more complicated, and the best suggestions for it can be found at Guru's site. EEPROMs and FlashROMs have different sizes, are usually SMD, and special adaptors are required to insert them into your programmer; adaptors could be rather expensive. Finally PROMs are small chips (300mil) usually soldered through and quite similar to TTLs, therefore learning by heart their specific markings and labels comes handy in many cases. A good reference is available here.<br /> <br /> Fourth thing are RAMs, they come in many sizes, from long 300mil to thin 600mil to other (less common) sizes. Mark them out, because you will need to mention them in the documentation.<br /> <br /> Fifth thing is to find out if any PLD is on your PCB. To understand what a PLD is, please refer to this very good article on wikipedia. PLDs always incorporate a “read protect” feature, in 95% of the case it's activated by the producer; until recently it was impossible to read them, a dumper simply gave them a try hoping to be lucky and get into the 5% which is not protected. Recently “C. McDonald” found a way to read also a certain category of PLDs (the most common on arcade PCBs), so the above situation is changing.<br /> <br /> Sixth and last thing is to identify all other components of the PCB. You will find resistors, trimmers, LEDs, audio parts, heat exchangers, connectors, jumpers, switches and a lot of other things. You will need to describe them in the documentation as well.<br /> <br /> <br /> 2- Components dumping<br /> -stub-<br /> <br /> <br /> 3- checking the dump<br /> -stub-</div>

F205v https://wiki.mamedev.org/index.php?title=Dumping_roms&diff=1929 2008-11-09T22:43:34Z

<p>F205v: New page: Let&#039;s have a look at the most difficult part of the documentation process: the dumping! I usually go through a 3 steps path: 1)Components identification 2)Actually dumping them 3)Checking ...</p> <hr /> <div>Let's have a look at the most difficult part of the documentation process: the dumping!<br /> I usually go through a 3 steps path:<br /> 1)Components identification<br /> 2)Actually dumping them<br /> 3)Checking what I've done<br /> <br /> <br /> 1- Components identification.<br /> On a standard PCB we will find one, more or even all of the following components: CPUs, TTLs, ROMs, RAMs, PLDs, Others<br /> I use coloured water-markers (of the kind used to write on CDs) to mark each single component when it is correctly identified: green is for CPUs, blue for TTLs, gold for ROMs, purple for RAMs, silver for PLDs. This colour marking system is of great help when working on PCBs, it gives an immediate visual overview of what is what, it avoids missing out something important to dump, it saves a lot of time because I do not have to re-identify components when I look at a PCB after some time.<br /> <br /> First thing we have to find the main CPU (maybe there are more than one!); it's usually the only chip whose size is remarkably different from all the others. We have to remember that 6502, Z80 and 68000 are the most used CPUs in arcade game history, learning by heart what they look like is fundamental. Obviously each chip sports some writing (markings), and looking that up on the Internet is always a good way to confirm what a chip is. For CPUs identification I would recommend CPU-World as a reference.<br /> Sound CPUs are usually found grouped together, close to the volume trimmer. Most common sound CPUs are M6295 (and clones) and all of the various YMxxxx.<br /> On some PCBs we will also find MCUs; they are like CPUs, but with an internal memory which is unfortunately read-protected 99% of the times.<br /> On some PCBs there will also be “support chips” like I/O chips, CRC controllers or Peripheral Interface Adapter; let's mark all of them green as well.<br /> <br /> Second thing let's rule out all of the TTLs; they are easy to identify, because they are small (300mil) and marked 74xxx (in very old PCBs they can also be 54xxx), let's mark them blue. TTLs are usually the most common component, ranging from some tens to some hundreds of them on a single PCB. They are pure logical operators and are of very scarce interest for the dumper, apart from a few remarkable exceptions: 74s188, 287, 288, 370, 387, 471, 472, 473, 474, 570, 571, 572, 573. These are all PROMs, they have to be marked gold and are addressed here following.<br /> <br /> Third thing is to correctly identify and colour mark ROMs. They come in a variety of forms: PROMs, EPROMs, EEPROMs, FlashROMs, MaskROMs. The most common are EPROMs, they sport a transparent window, they are 600mil, ranging from DIP24 to DIP42. In most PCBs they are socketed, and their extraction is very easy using a small flat screwdriver and slowly lifting them with small movements from BOTH sides to avoid any pin bending. MaskROMs are of the same size as EPROMs, but without the window, and very often they are soldered through the PCB. Removing them is a little bit more complicated, and the best suggestions for it can be found at Guru's site. EEPROMs and FlashROMs have different sizes, are usually SMD, and special adaptors are required to insert them into your programmer; adaptors could be rather expensive. Finally PROMs are small chips (300mil) usually soldered through and quite similar to TTLs, therefore learning by heart their specific markings and labels comes handy in many cases. A good reference is available here.<br /> <br /> Fourth thing are RAMs, they come in many sizes, from long 300mil to thin 600mil to other (less common) sizes. Mark them out, because you will need to mention them in the documentation.<br /> <br /> Fifth thing is to find out if any PLD is on your PCB. To understand what a PLD is, please refer to this very good article on wikipedia. PLDs always incorporate a “read protect” feature, in 95% of the case it's activated by the producer; until recently it was impossible to read them, a dumper simply gave them a try hoping to be lucky and get into the 5% which is not protected. Recently “C. McDonald” found a way to read also a certain category of PLDs (the most common on arcade PCBs), so the above situation is changing.<br /> <br /> Sixth and last thing is to identify all other components of the PCB. You will find resistors, trimmers, LEDs, audio parts, heat exchangers, connectors, jumpers, switches and a lot of other things. You will need to describe them in the documentation as well.<br /> <br /> <br /> 2- Components dumping<br /> -stub-<br /> <br /> <br /> 3- checking the dump<br /> -stub-</div>

F205v https://wiki.mamedev.org/index.php?title=How_to_correctly_document_a_PCB&diff=1928 2008-11-09T22:43:18Z

<p>F205v: </p> <hr /> <div>This article is a stub, it will be enriched with more information in due time.<br /> <br /> How to (correctly) document a PCB.<br /> <br /> PCBs (Printed Circuit Boards) are the source and the goal of the whole MAME project.<br /> They are the goal, because emulating their behaviour and their working mechanism is what MAME does.<br /> They are the source, because every information in a MAME driver comes directly from them; and because the driver itself is a &quot;virtual&quot; PCB, mimicing the real one.<br /> <br /> I'll focus therefore on how to correctly extract information from a PCB, and how to organise them in such a way that these infos will be useful to MAMEdevs when they'll code a driver.<br /> <br /> Documenting a PCB is a 3 steps job:<br /> 1) taking pictures<br /> 2) dumping ROMs<br /> 3) writing documentation<br /> <br /> Each of the 3 steps will have a separate article in the near future, detailing everything that is needed to know; for the moment let's just have a quick look at them.<br /> <br /> 1) [[Taking pictures and other medias]] (like recording sounds and filming videos) is usually the first and easiest thing you can do with a PCB; no special expertise is needed for this task, just a little bit of patience and care.<br /> With a digital camera you should take pictures of the whole PCB, both front (component) and back (solder) side. If the PCB consists of different boards packed one over the other, separate them and take pictures individually. If you can connect the PCB to a cabinet or to a test rig, do it; and take pictures of the game at boot up, at title screen, at intro and attract mode, and during game as well.<br /> If your camera is capable of recording videos, film some seconds of the game during title / attract mode and in game. This task is needed if your PCB is particularly rare and good videos of the game are not available; filming kof2k is usually not needed ;)<br /> Same goes for game sound recordings, they could be needed by MAMEdevs if your game is rare or with a strange dedicated sound board. A game generating sounds out of a AY-3-8910 usually doesn't require any recording.<br /> <br /> 2) [[Dumping roms]] is somewhat considered the &quot;cool&quot; part of the documenting process; it isn't. It's a long and tedious task requiring dedicated equipment, extreme accuracy, electronics background and a forgiving wife! ;)<br /> The minimum equipment required is an &quot;EPROM programmer&quot;: that is a dedicated hardware and software appliance, where you will put the EPROMs extracted from the PCB and &quot;read&quot; them. The software will then save the content in a file on your PC. Obviously an EPROM programmer capable of reading 10.000+ different kind of chips is better then one reading only some hundreds; and the cost for it will be proportional.<br /> You will probably also need one or more soldering irons, an hot air reworking station, some desoldering tools, pliers, screwdrivers, chip removers, etc.<br /> You will need to dump EVERYTHING that is dumpable on the PCB, so it will be PROMs, EPROMs, EEPROMs, maskROMs, flashROMs, PLDs, PALs, GALs, and everything else which contains a memory like MCUs and the like.<br /> You will need to dump every single chip a minimum of 3 times (possibly with different current/voltage levels), and compare the 3 reads to check if they match. If they don't you will have to figure out why, solve the problem and read them 3 times again.<br /> You will need to compare the files you dumped with already known files and check if there is any match.<br /> <br /> 3) Writing documentation is the last task for you, and it's even more tedious than dumping.<br /> All important parts of the PCB need to be listed, their function explained.<br /> Also the pictures you took in step 1 must be listed, as well as files you dumped in step 2.<br /> A meaningful description of the PCB is extremely important for mamedevs, they will only have it as a guide while coding a driver, so the more accurate you are the more likely there will be a working driver sooner or later.<br /> <br /> <br /> Did I told that documenting PCBs is tedious? Well I have to tell you that it's also extremely satisfactory and ego-busting; when you correctly document a PCB, and in a few days you have it emulated in MAME, you can proudly pat yourself on the shoulder: a piece of the arcade games history has been preserved for the future, and you where part of it!</div>

F205v https://wiki.mamedev.org/index.php?title=Corrado_Tomaselli&diff=1675 2008-04-20T20:36:03Z

<p>F205v: </p> <hr /> <div>Corrado Tomaselli, AKA Kold666, is a member of the Italian Dumping Team and former moderator for [http://www.mameitalia.net MAME Italian Forum]</div>

F205v https://wiki.mamedev.org/index.php?title=Corrado_Tomaselli&diff=1674 2008-04-20T20:33:23Z

<p>F205v: New page: Corrado Tomaselli, AKA Kold666, is a member of the Italian Dumping Team.</p> <hr /> <div>Corrado Tomaselli, AKA Kold666, is a member of the Italian Dumping Team.</div>

F205v https://wiki.mamedev.org/index.php?title=Taking_pictures_and_other_medias&diff=1660 2008-03-23T22:03:52Z

<p>F205v: New page: Taking pictures and other medias to document a PCB is usually the first step in the process. The minimum requirement is a digital still camera, the higher resolution the better. Just to gi...</p> <hr /> <div>Taking pictures and other medias to document a PCB is usually the first step in the process.<br /> The minimum requirement is a digital still camera, the higher resolution the better. Just to give you some indication I have a 5Mega pixel camera and it's more than enough; let's say that every modern camera is good for our porpouse.<br /> What is not good is a phone camera because usually it has got a way inferior resolution, a very bad contrast range and it's very difficult to keep it steady.<br /> <br /> The first step is to take pictures of the PCB; prepare a place that will become your &quot;studio&quot;, I like very much to take pictures of PCBs while they are vertically laying against a wall, some other prefer to take pictures with the PCB flat on the ground. In both cases use a monocolour, flat, opaque, neutral background; avoid plain white, it will reverberate back to the camera; avoid multicolours tiles, they usually shine and tend to alterate camera contrast; eventually you can use for your background a brown paper of the kind used to wrap up delivery parcells.<br /> If you take pictures of a vertical PCB use a tripod, even a very small one to hold the camera; if you do not have a tripod, put the camera at the same heigh of the PCB, possibly resting over some books with a rigid cover; do not hold the camera in your hands because it's much more easy to &quot;move&quot; the picture.<br /> If you take picures of an horizontal PCB use a tripod again, of the kind with the tilting head to hold the camera horizontal as well; if you do not have a tripod hold the camera in your hands, tray to stay over the PCB with your legs slightly open, and hold your breath while taking the picture; if possible try to lay against a wall, this will help you to remain steady.<br /> The lighting of your &quot;studio&quot; is very important: the best possible source of light is the sun, but it's not always available, therefore a very good alternative is a couple of halogen lamps of about 300-500W, illuminating the PCB from a few meters away. The very important thing is to avoid direct lighting of the PCB, but to illuminate it with light reflecting out of the walls and ceiling, resembling as much as possible the natural ambient light. NEVER use the flashlight incorporated into your camera, because it will reflect back from the PCB and &quot;blind&quot; the picture.<br /> A good thing is to clean the PCB from dust before taking pictures; if the PCB is very dirt, at least clean the surface of the ICs with a soft slightly humid cloth, so that markings and labels are clearly visible.<br /> Remember to take pictures of both sides of the PCB (components and solder), if the PCB consists of different boards packed one over the other, separate them and take pictures individually.<br /> <br /> If the PCB is working, it's now time to go to step 2: taking pictures of the game in action.<br /> So connect the PCB to your test rig, fire it up and let the game run for a few minutes so that your monitor gets to the right temperature. Calibrate your monitor to have a good full picture of the game, with warm saturated colors, and make sure that the full image is shown within the borders. Now shitch off all ambient lights so that the monitor itself is the only source of light, and holding the camera in your hands keep as steady as possible and take pictures of the game at boot up, at title screen, at intro and attract mode, and during game as well. It is not important to have them at very high resolution, on the contrary 640x480 or 800x600 are more than good. Sometimes it's a good idea to film a few seconds of the game, especially if the game is extremely rare and there are no movies of it available on the net. A similar thing is valid for sounds: if the game is extremely rare or very old and there are no sample available, record the sounds of the game. There are 2 ways to do it: with a microphone or directly connecting the PCB to your computer sound card. With a microphone you get a lower quality samples, possibly degradated by the quality of the speakers on your test rig and by the quality of the microphone itself; but it's a simple method and it's higly recomended if you do not know how your PCB works. Connecting the PCB directly to your sound card requires a little of electronic knowledge, a soldering iron and a clear idea of what you are doing; if you do not know how to do it DO NOT DO IT! otherwise you will end up with a broken PCB and a broken sound card.</div>

F205v https://wiki.mamedev.org/index.php?title=How_to_correctly_document_a_PCB&diff=1659 2008-03-23T22:03:00Z

<p>F205v: </p> <hr /> <div>This article is a stub, it will be enriched with more information in due time.<br /> <br /> How to (correctly) document a PCB.<br /> <br /> PCBs (Printed Circuit Boards) are the source and the goal of the whole MAME project.<br /> They are the goal, because emulating their behaviour and their working mechanism is what MAME does.<br /> They are the source, because every information in a MAME driver comes directly from them; and because the driver itself is a &quot;virtual&quot; PCB, mimicing the real one.<br /> <br /> I'll focus therefore on how to correctly extract information from a PCB, and how to organise them in such a way that these infos will be useful to MAMEdevs when they'll code a driver.<br /> <br /> Documenting a PCB is a 3 steps job:<br /> 1) taking pictures<br /> 2) dumping ROMs<br /> 3) writing documentation<br /> <br /> Each of the 3 steps will have a separate article in the near future, detailing everything that is needed to know; for the moment let's just have a quick look at them.<br /> <br /> 1) [[Taking pictures and other medias]] (like recording sounds and filming videos) is usually the first and easiest thing you can do with a PCB; no special expertise is needed for this task, just a little bit of patience and care.<br /> With a digital camera you should take pictures of the whole PCB, both front (component) and back (solder) side. If the PCB consists of different boards packed one over the other, separate them and take pictures individually. If you can connect the PCB to a cabinet or to a test rig, do it; and take pictures of the game at boot up, at title screen, at intro and attract mode, and during game as well.<br /> If your camera is capable of recording videos, film some seconds of the game during title / attract mode and in game. This task is needed if your PCB is particularly rare and good videos of the game are not available; filming kof2k is usually not needed ;)<br /> Same goes for game sound recordings, they could be needed by MAMEdevs if your game is rare or with a strange dedicated sound board. A game generating sounds out of a AY-3-8910 usually doesn't require any recording.<br /> <br /> 2) Dumping roms is somewhat considered the &quot;cool&quot; part of the documenting process; it isn't. It's a long and tedious task requiring dedicated equipment, extreme accuracy, electronics background and a forgiving wife! ;)<br /> The minimum equipment required is an &quot;EPROM programmer&quot;: that is a dedicated hardware and software appliance, where you will put the EPROMs extracted from the PCB and &quot;read&quot; them. The software will then save the content in a file on your PC. Obviously an EPROM programmer capable of reading 10.000+ different kind of chips is better then one reading only some hundreds; and the cost for it will be proportional.<br /> You will probably also need one or more soldering irons, an hot air reworking station, some desoldering tools, pliers, screwdrivers, chip removers, etc.<br /> You will need to dump EVERYTHING that is dumpable on the PCB, so it will be PROMs, EPROMs, EEPROMs, maskROMs, flashROMs, PLDs, PALs, GALs, and everything else which contains a memory like MCUs and the like.<br /> You will need to dump every single chip a minimum of 3 times (possibly with different current/voltage levels), and compare the 3 reads to check if they match. If they don't you will have to figure out why, solve the problem and read them 3 times again.<br /> You will need to compare the files you dumped with already known files and check if there is any match.<br /> <br /> 3) Writing documentation is the last task for you, and it's even more tedious than dumping.<br /> All important parts of the PCB need to be listed, their function explained.<br /> Also the pictures you took in step 1 must be listed, as well as files you dumped in step 2.<br /> A meaningful description of the PCB is extremely important for mamedevs, they will only have it as a guide while coding a driver, so the more accurate you are the more likely there will be a working driver sooner or later.<br /> <br /> <br /> Did I told that documenting PCBs is tedious? Well I have to tell you that it's also extremely satisfactory and ego-busting; when you correctly document a PCB, and in a few days you have it emulated in MAME, you can proudly pat yourself on the shoulder: a piece of the arcade games history has been preserved for the future, and you where part of it!</div>

F205v https://wiki.mamedev.org/index.php?title=How_to_correctly_document_a_PCB&diff=1619 2008-02-17T21:49:42Z

<p>F205v: </p> <hr /> <div>This article is a stub, it will be enriched with more information in due time.<br /> <br /> How to (correctly) document a PCB.<br /> <br /> PCBs (Printed Circuit Boards) are the source and the goal of the whole MAME project.<br /> They are the goal, because emulating their behaviour and their working mechanism is what MAME does.<br /> They are the source, because every information in a MAME driver comes directly from them; and because the driver itself is a &quot;virtual&quot; PCB, mimicing the real one.<br /> <br /> I'll focus therefore on how to correctly extract information from a PCB, and how to organise them in such a way that these infos will be useful to MAMEdevs when they'll code a driver.<br /> <br /> Documenting a PCB is a 3 steps job:<br /> 1) taking pictures<br /> 2) dumping ROMs<br /> 3) writing documentation<br /> <br /> Each of the 3 steps will have a separate article in the near future, detailing everything that is needed to know; for the moment let's just have a quick look at them.<br /> <br /> 1) Taking pictures and other medias (like recording sounds and filming videos) is usually the first and easiest thing you can do with a PCB; no special expertise is needed for this task, just a little bit of patience and care.<br /> With a digital camera you should take pictures of the whole PCB, both front (component) and back (solder) side. If the PCB consists of different boards packed one over the other, separate them and take pictures individually. If you can connect the PCB to a cabinet or to a test rig, do it; and take pictures of the game at boot up, at title screen, at intro and attract mode, and during game as well.<br /> If your camera is capable of recording videos, film some seconds of the game during title / attract mode and in game. This task is needed if your PCB is particularly rare and good videos of the game are not available; filming kof2k is usually not needed ;)<br /> Same goes for game sound recordings, they could be needed by MAMEdevs if your game is rare or with a strange dedicated sound board. A game generating sounds out of a AY-3-8910 usually doesn't require any recording.<br /> <br /> 2) Dumping roms is somewhat considered the &quot;cool&quot; part of the documenting process; it isn't. It's a long and tedious task requiring dedicated equipment, extreme accuracy, electronics background and a forgiving wife! ;)<br /> The minimum equipment required is an &quot;EPROM programmer&quot;: that is a dedicated hardware and software appliance, where you will put the EPROMs extracted from the PCB and &quot;read&quot; them. The software will then save the content in a file on your PC. Obviously an EPROM programmer capable of reading 10.000+ different kind of chips is better then one reading only some hundreds; and the cost for it will be proportional.<br /> You will probably also need one or more soldering irons, an hot air reworking station, some desoldering tools, pliers, screwdrivers, chip removers, etc.<br /> You will need to dump EVERYTHING that is dumpable on the PCB, so it will be PROMs, EPROMs, EEPROMs, maskROMs, flashROMs, PLDs, PALs, GALs, and everything else which contains a memory like MCUs and the like.<br /> You will need to dump every single chip a minimum of 3 times (possibly with different current/voltage levels), and compare the 3 reads to check if they match. If they don't you will have to figure out why, solve the problem and read them 3 times again.<br /> You will need to compare the files you dumped with already known files and check if there is any match.<br /> <br /> 3) Writing documentation is the last task for you, and it's even more tedious than dumping.<br /> All important parts of the PCB need to be listed, their function explained.<br /> Also the pictures you took in step 1 must be listed, as well as files you dumped in step 2.<br /> A meaningful description of the PCB is extremely important for mamedevs, they will only have it as a guide while coding a driver, so the more accurate you are the more likely there will be a working driver sooner or later.<br /> <br /> <br /> Did I told that documenting PCBs is tedious? Well I have to tell you that it's also extremely satisfactory and ego-busting; when you correctly document a PCB, and in a few days you have it emulated in MAME, you can proudly pat yourself on the shoulder: a piece of the arcade games history has been preserved for the future, and you where part of it!</div>

F205v https://wiki.mamedev.org/index.php?title=User:F205v&diff=1618 2008-02-14T21:00:46Z

<p>F205v: New page: f205v is the nickname used by Antonio Gerli, admin for the MAME Italia forum.</p> <hr /> <div>f205v is the nickname used by Antonio Gerli, admin for the [[MAME Italia]] forum.</div>

F205v https://wiki.mamedev.org/index.php?title=How_to_correctly_document_a_PCB&diff=1617 2008-02-14T18:18:56Z

<p>F205v: New page: This article is a stub, it will be enriched with more information in due time. How to (correctly) document a PCB. PCBs (Printed Circuit Boards) are the source and the goal of the whole M...</p> <hr /> <div>This article is a stub, it will be enriched with more information in due time.<br /> <br /> How to (correctly) document a PCB.<br /> <br /> PCBs (Printed Circuit Boards) are the source and the goal of the whole MAME project.<br /> They are the goal, because emulating their behaviour and their working mechanism is what MAME does.<br /> They are the source, because every information in a MAME driver comes directly from them; and because the driver itself is a &quot;virtual&quot; PCB, mimicing the real one.<br /> <br /> I'll focus therefore on how to correctly extract information from a PCB, and how to organise them in such a way that these infos will be useful to MAMEdevs when they'll code a driver.<br /> <br /> Documenting a PCB is a 3 steps job:<br /> 1) taking pictures<br /> 2) dumping ROMs<br /> 3) writing documentation<br /> <br /> Each of the 3 steps will have a separate article in the near future, detailing everything that is needed to know; for the moment let's just have a quick look at them.<br /> <br /> 1) Taking pictures and other medias (like recording sounds and filming videos) is usually the first and easiest thing you can do with a PCB; no special expertise is needed for this task, just a little bit of patience and care.<br /> With a digital camera you should take pictures of the whole PCB, both front (component) and back (solder) side. If the PCB consists of different PCBs packed one over the other, separate them and take pictures individually. If you can connect the PCB to a cabinet or to a test rig, do it; and take pictures of the game at boot up, at title screen, at intro and attract mode, and during game as well.<br /> If your camera is capable of recording videos, film some seconds of the game during title / attract mode and in game. This task is needed if your PCB is particularly rare and good videos of the game are not available; filming kof2k is usually not needed ;)<br /> Same goes for game sound recordings, they could be needed by MAMEdevs if your game is rare or with a strange dedicated sound board. A game generating sounds out of a AY-3-8910 usually doesn't require any recording.<br /> <br /> 2) Dumping roms is somewhat considered the &quot;cool&quot; part of the documenting process; it isn't. It's a long and tedious task requiring dedicated equipment, extreme accuracy, electronics background and a forgiving wife! ;)<br /> The minimum equipment required is an &quot;EPROM programmer&quot;: that is a dedicated hardware and software appliance, where you will put the EPROMs extracted from the PCB and &quot;read&quot; them. The software will then save the content in a file on your PC. Obviously an EPROM programmer capable of reading 10.000+ different kind of chips is better then one reading only some hundreds; and the cost for it will be proportional.<br /> You will probably also need one or more soldering irons, an hot air reworking station, some desoldering tools, pliers, screwdrivers, chip removers, etc.<br /> You will need to dump EVERYTHING that is dumpable on the PCB, so it will be PROMs, EPROMs, EEPROMs, maskROMs, flashROMs, PLDs, PALs, GALs, and everything else which contains a memory like MCUs and the like.<br /> You will need to dump every single chip a minimum of 3 times (possibly with different current/voltage levels), and compare the 3 reads to check if they match. If they don't you will have to figure out why, solve the problem and read them 3 times again.<br /> You will need to compare the files you dumped with already known files and check if there is any match.<br /> <br /> 3) Writing documentation is the last task for you, and it's even more tedious than dumping.<br /> All important parts of the PCB need to be listed, their function explained.<br /> Also the pictures you took in step 1 must be listed, as well as files you dumped in step 2.<br /> A meaningful description of the PCB is extremely important for mamedevs, they will only have it as a guide while coding a driver, so the more accurate you are the more likely there will be a working driver sooner or later.<br /> <br /> <br /> Did I told that documenting PCBs is tedious? Well I have to tell you that it's also extremely satisfactory and ego-busting; when you correctly document a PCB, and in a few days you have it emulated in MAME, you can proudly pat yourself on the shoulder: a piece of the arcade games history has been preserved for the future, and you where part of it!</div>

F205v https://wiki.mamedev.org/index.php?title=MAME_Italia&diff=1415 2007-12-17T10:47:19Z

<p>F205v: New page: Mame Italia is a collective name, representing all the members of the [http://www.mameitalia.net MAME Italian Forum]</p> <hr /> <div>Mame Italia is a collective name, representing all the members of the [http://www.mameitalia.net MAME Italian Forum]</div>

F205v https://wiki.mamedev.org/index.php?title=F205v&diff=1414 2007-12-17T10:46:37Z

<p>F205v: </p> <hr /> <div>f205v is the nickname used by Antonio Gerli, admin for the [[MAME Italia]] forum.</div>

F205v https://wiki.mamedev.org/index.php?title=MAME_0.112u3&diff=1413 2007-12-17T10:45:47Z

<p>F205v: /* Contributors */</p> <hr /> <div>== Release Date ==<br /> MAME 0.112u3 was released on 26 February 2007.<br /> <br /> <br /> == Contributors ==<br /> The known contributors for this version are, in alphabetical order:<br /> <br /> * [[Aaron Giles]]<br /> * [[Bob Seidel]]<br /> * [[Brian Troha]]<br /> * [[Curt Coder]]<br /> * [[David Haywood]]<br /> * [[Derrick Renaud]]<br /> * [[Dirk Best]]<br /> * [[JohnBoy]]<br /> * [[MAME Italia]]<br /> * [[Nathan Woods]]<br /> * [[Nicola Salmoria]]<br /> * [[Pierpaolo Prazzoli]]<br /> * [[smf]]<br /> * [[stephh]]<br /> * [[Ville Linde]]<br /> <br /> == Specific Contributions ==<br /> The known contributions for this version are, in the order specified in the whatsnew:<br /> <br /> * [[Bob Seidel]] modified ledutil to save the LED state when returning from pause.<br /> <br /> * [[Ville Linde]] fixed the crashing in debug builds and added controls for Ski Champ.<br /> <br /> * [[Dirk Best]] updated the makefile to remove the map file when making clean.<br /> <br /> * [[Derrick Renaud]] made significant changes to the input system:<br /> ** Added the -vol shortcut to -volume to match the docs.<br /> ** Added new joystick options -joy_deadzone &amp; -joy_saturation. Removed -a2d_deadzone. These now apply to the analog and digital-from-analog data. See windows.txt for more info.<br /> ** Analog joystick data is divided into chunks for IPT_POSITIONAL controls. e.g., for a 7 position emulated control, a joystick axis will move 3 positions each way from center + center = 7 positions. One good use for this is 49way sticks. The driver input code just needs to be set to IPT_POSITIONAL PORT_POSITIONS(7) and use a PORT_REMAP_TABLE.<br /> ** IPT_PEDAL controls are now nothing special in the core. They can use any control like a paddle does. At the OS input level, the code has been changed to supply full joystick axis and the +/- axis. This means any half axis or full axis can be used for any emulated control. e.g., a pedal that only outputs Y- data can be used for the full range of the gun in boothill. Or a full axis slider on a joystick can be used in its full range as an emulated pedal. INC now increases the pedal value, not DEC.<br /> ** When seting up the player controls in the menu, the first time an analog joystick axis is selected it will use the full range. If you immediately select the same joystick axis it will toggle to the half +/- axis.<br /> ** Analog joysticks can now simulate relative devices such as a trackball. The further you move the joystick, the faster the trackball spins. Use the sensitivity setting to adjust.<br /> ** Added support for mouse +/- axis to be used as button input.<br /> ** Modified IPT_PADDLE and IPT_AD_STICK so they do not behave as pedals using half the joystick range if their default value is equal to one of the PORT_MINMAX values. Now you can select it as the full or +/- part axis.<br /> <br /> * [[stephh]] updated the acefruit driver: <br /> ** added 'sidewndr' and 'spellbnd' (was 'sidewnda') which were missing in previous releases<br /> ** reorganised the layout to have all lamps and solenoids at the top (where there's nothing)<br /> ** also renamed some lamps and solenoids<br /> ** added 'starspnr' ... unfortunately, the game is not working due to a bad dump (H11)<br /> <br /> * [[Derrick Renaud]] updated the DISCRETE_OP_AMP_OSCILLATOR circuit to get it ready for a future driver. It allows the DISC_OP_AMP_OSCILLATOR_1 | DISC_OP_AMP_IS_NORTON oscillator to use nodes to adjust the resistance values instead of only being static values.<br /> <br /> * [[Derrick Renaud]] fixed thrust control in Lunar Lander.<br /> <br /> * [[Nathan Woods]] created a new utility module pool.c for managing memory pools. Rebuilt auto_malloc on top of this concept. <br /> <br /> * [[David Haywood]] added speedups to many of the Eolith games.<br /> <br /> * Added sprite rotation to the realbrk driver. This fixes the jigging reels in the pachinko games and the cue position and orientation in the pool games.<br /> <br /> * [[Derrick Renaud]] added discrete sound for Amazing Maze. Also added new Discrete modules: DISCRETE_LOOKUP_TABLE &amp; DISCRETE_LOGIC_JKFLIPFLOP.<br /> <br /> * [[Curt Coder]] Fixed the small graphic issues in the Cidelsa driver. Draco still has imperfect colors.<br /> <br /> * [[JohnBoy]] fixed naming and identification of several Neo Geo ROMs.<br /> <br /> * [[David Haywood]] Fixed regression in the GeeBee driver.<br /> <br /> * [[smf]] sent in a major update to the Konami System 573 driver:<br /> ** added state saving to emu\sound\cdda.c &amp; mame\drivers\ksys573.c<br /> ** added DS2401 emulation<br /> ** added X76F100 emulation<br /> ** added ZS01 emulation (HLE of System 573 PIC)<br /> ** added write support to X76F041 emulation<br /> ** many new games partially supported<br /> <br /> * [[MAME Italia]] connected brightness support on the CPS1 board (not just CPS2) after verifying that the real board does support it. <br /> <br /> * [[Ville Linde]] improved the K001604 tilemap chip emulation.<br /> <br /> * [[Aaron Giles]] fixed garbage in fonts on some systems.<br /> <br /> * [[Aaron Giles]] added a new tool makemeta.exe, which can generate properly formatted metadata for laserdisc CHDs using either a specially captured AVI as input (preferred) or a hand-crafted set of encoded Philips codes.<br /> <br /> * [[Aaron Giles]] rewrote throttling code to be more forgiving of OSD-level glitches and uneven frame rates.<br /> <br /> * [[Aaron Giles]] Changed sound streaming engine to be emulated time based instead of sample based. This means that emulation behavior is independent of the user-specified sample rate (except that some sound cores still use this value; to fixed in a future update). Also separated sound generation from video frame rate. Sound is now pushed to the OSD layer at a fixed rate of 50 updates per emulated second. This entailed a change in the way sound is handed to the OSD layer. Instead of the OSD layer requesting arbitrary numbers of samples each frame, the core now pushes the appropriate number of samples based on the emulated time.<br /> <br /> * [[Aaron Giles]] simplified the OSD interface for sound. Removed osd_start_audio_stream and osd_stop_audio_stream; OSD initialization code is now responsible for initialization. Removed osd_get_mastervolume and osd_sound_enable, keeping management of the main volume in emu/sound.c.<br /> <br /> * [[Aaron Giles]] changed K054539 to run at native sample rate.<br /> <br /> <br /> == Game Support ==<br /> '''New games added or promoted from NOT_WORKING status'''<br /> * [http://www.mameworld.net/maws/romset/crazywar Crazy War]<br /> <br /> <br /> '''New clones added'''<br /> * [http://www.mameworld.net/maws/romset/spf2ta Super Puzzle Fighter II Turbo (Asia 960529)]<br /> * [http://www.mameworld.net/maws/romset/meikyuha Meikyuu Hunter G (Japan, set 2)]<br /> * [http://www.mameworld.net/maws/romset/chinhert Chinese Heroe (Taito)]<br /> <br /> <br /> '''New games marked as GAME_NOT_WORKING'''<br /> * [http://www.mameworld.net/maws/romset/ddrja Dance Dance Revolution (GC845 VER. JAB)]<br /> * [http://www.mameworld.net/maws/romset/dsftkd Dancing Stage featuring TRUE KiSS DESTiNATiON (G*884 VER. JAA)]<br /> * [http://www.mameworld.net/maws/romset/ddrsbm Dance Dance Revolution Solo Bass Mix (GQ894 VER. JAA)]<br /> * [http://www.mameworld.net/maws/romset/ddrs2k Dance Dance Revolution Solo 2000 (GC905 VER. AAA)]<br /> * [http://www.mameworld.net/maws/romset/ddr3ma Dance Dance Revolution 3rd Mix]<br /> * [http://www.mameworld.net/maws/romset/dncfrks Dance Freaks (G*874 VER. KAA)]<br /> * [http://www.mameworld.net/maws/romset/drmn2m DrumMania 2nd Mix (GE912 VER. JAA)]<br /> * [http://www.mameworld.net/maws/romset/ddr3mp Dance Dance Revolution 3rd Mix Plus (G*A22 VER. JAA)]<br /> * [http://www.mameworld.net/maws/romset/ddr4m Dance Dance Revolution 4th Mix (G*A33 VER. AAA)]<br /> * [http://www.mameworld.net/maws/romset/ddr4ms Dance Dance Revolution Solo 4th Mix (G*A33 VER. ABA)]<br /> * [http://www.mameworld.net/maws/romset/ddrusa Dance Dance Revolution USA (G*A44 VER. UAA)]<br /> * [http://www.mameworld.net/maws/romset/ddr4mp Dance Dance Revolution 4th Mix Plus (G*A34 VER. JAA)]<br /> * [http://www.mameworld.net/maws/romset/ddr4mps Dance Dance Revolution 4th Mix Plus Solo (G*A34 VER. JAA)]<br /> * [http://www.mameworld.net/maws/romset/dmx2m Dance Maniax 2nd Mix (G*A39 VER. JAA)]<br /> * [http://www.mameworld.net/maws/romset/ddr5m Dance Dance Revolution 5th Mix (G*A27 VER. JAA)]<br /> * [http://www.mameworld.net/maws/romset/dmx2majp Dance Maniax 2nd Mix Append J-Paradise (G*A38 VER. JAA )]<br /> * [http://www.mameworld.net/maws/romset/salarymc Salary Man Champ (G*A18 VER. JAA)]<br /> * [http://www.mameworld.net/maws/romset/ddrmax DDR Max - Dance Dance Revolution 6th Mix (G*B19 VER. JAA)]<br /> * [http://www.mameworld.net/maws/romset/ddrmax2 DDR Max 2 - Dance Dance Revolution 7th Mix (G*B20 VER. JAA)]<br /> <br /> [[Category:Releases 2007]]</div>

F205v https://wiki.mamedev.org/index.php?title=MAME_0.112u3&diff=1412 2007-12-17T10:45:16Z

<p>F205v: /* Contributors */</p> <hr /> <div>== Release Date ==<br /> MAME 0.112u3 was released on 26 February 2007.<br /> <br /> <br /> == Contributors ==<br /> The known contributors for this version are, in alphabetical order:<br /> <br /> * [[Aaron Giles]]<br /> * [[Bob Seidel]]<br /> * [[Brian Troha]]<br /> * [[Curt Coder]]<br /> * [[David Haywood]]<br /> * [[Derrick Renaud]]<br /> * [[Dirk Best]]<br /> * [[JohnBoy]]<br /> * [[MAME_Italia]]<br /> * [[Nathan Woods]]<br /> * [[Nicola Salmoria]]<br /> * [[Pierpaolo Prazzoli]]<br /> * [[smf]]<br /> * [[stephh]]<br /> * [[Ville Linde]]<br /> <br /> == Specific Contributions ==<br /> The known contributions for this version are, in the order specified in the whatsnew:<br /> <br /> * [[Bob Seidel]] modified ledutil to save the LED state when returning from pause.<br /> <br /> * [[Ville Linde]] fixed the crashing in debug builds and added controls for Ski Champ.<br /> <br /> * [[Dirk Best]] updated the makefile to remove the map file when making clean.<br /> <br /> * [[Derrick Renaud]] made significant changes to the input system:<br /> ** Added the -vol shortcut to -volume to match the docs.<br /> ** Added new joystick options -joy_deadzone &amp; -joy_saturation. Removed -a2d_deadzone. These now apply to the analog and digital-from-analog data. See windows.txt for more info.<br /> ** Analog joystick data is divided into chunks for IPT_POSITIONAL controls. e.g., for a 7 position emulated control, a joystick axis will move 3 positions each way from center + center = 7 positions. One good use for this is 49way sticks. The driver input code just needs to be set to IPT_POSITIONAL PORT_POSITIONS(7) and use a PORT_REMAP_TABLE.<br /> ** IPT_PEDAL controls are now nothing special in the core. They can use any control like a paddle does. At the OS input level, the code has been changed to supply full joystick axis and the +/- axis. This means any half axis or full axis can be used for any emulated control. e.g., a pedal that only outputs Y- data can be used for the full range of the gun in boothill. Or a full axis slider on a joystick can be used in its full range as an emulated pedal. INC now increases the pedal value, not DEC.<br /> ** When seting up the player controls in the menu, the first time an analog joystick axis is selected it will use the full range. If you immediately select the same joystick axis it will toggle to the half +/- axis.<br /> ** Analog joysticks can now simulate relative devices such as a trackball. The further you move the joystick, the faster the trackball spins. Use the sensitivity setting to adjust.<br /> ** Added support for mouse +/- axis to be used as button input.<br /> ** Modified IPT_PADDLE and IPT_AD_STICK so they do not behave as pedals using half the joystick range if their default value is equal to one of the PORT_MINMAX values. Now you can select it as the full or +/- part axis.<br /> <br /> * [[stephh]] updated the acefruit driver: <br /> ** added 'sidewndr' and 'spellbnd' (was 'sidewnda') which were missing in previous releases<br /> ** reorganised the layout to have all lamps and solenoids at the top (where there's nothing)<br /> ** also renamed some lamps and solenoids<br /> ** added 'starspnr' ... unfortunately, the game is not working due to a bad dump (H11)<br /> <br /> * [[Derrick Renaud]] updated the DISCRETE_OP_AMP_OSCILLATOR circuit to get it ready for a future driver. It allows the DISC_OP_AMP_OSCILLATOR_1 | DISC_OP_AMP_IS_NORTON oscillator to use nodes to adjust the resistance values instead of only being static values.<br /> <br /> * [[Derrick Renaud]] fixed thrust control in Lunar Lander.<br /> <br /> * [[Nathan Woods]] created a new utility module pool.c for managing memory pools. Rebuilt auto_malloc on top of this concept. <br /> <br /> * [[David Haywood]] added speedups to many of the Eolith games.<br /> <br /> * Added sprite rotation to the realbrk driver. This fixes the jigging reels in the pachinko games and the cue position and orientation in the pool games.<br /> <br /> * [[Derrick Renaud]] added discrete sound for Amazing Maze. Also added new Discrete modules: DISCRETE_LOOKUP_TABLE &amp; DISCRETE_LOGIC_JKFLIPFLOP.<br /> <br /> * [[Curt Coder]] Fixed the small graphic issues in the Cidelsa driver. Draco still has imperfect colors.<br /> <br /> * [[JohnBoy]] fixed naming and identification of several Neo Geo ROMs.<br /> <br /> * [[David Haywood]] Fixed regression in the GeeBee driver.<br /> <br /> * [[smf]] sent in a major update to the Konami System 573 driver:<br /> ** added state saving to emu\sound\cdda.c &amp; mame\drivers\ksys573.c<br /> ** added DS2401 emulation<br /> ** added X76F100 emulation<br /> ** added ZS01 emulation (HLE of System 573 PIC)<br /> ** added write support to X76F041 emulation<br /> ** many new games partially supported<br /> <br /> * [[MAME Italia]] connected brightness support on the CPS1 board (not just CPS2) after verifying that the real board does support it. <br /> <br /> * [[Ville Linde]] improved the K001604 tilemap chip emulation.<br /> <br /> * [[Aaron Giles]] fixed garbage in fonts on some systems.<br /> <br /> * [[Aaron Giles]] added a new tool makemeta.exe, which can generate properly formatted metadata for laserdisc CHDs using either a specially captured AVI as input (preferred) or a hand-crafted set of encoded Philips codes.<br /> <br /> * [[Aaron Giles]] rewrote throttling code to be more forgiving of OSD-level glitches and uneven frame rates.<br /> <br /> * [[Aaron Giles]] Changed sound streaming engine to be emulated time based instead of sample based. This means that emulation behavior is independent of the user-specified sample rate (except that some sound cores still use this value; to fixed in a future update). Also separated sound generation from video frame rate. Sound is now pushed to the OSD layer at a fixed rate of 50 updates per emulated second. This entailed a change in the way sound is handed to the OSD layer. Instead of the OSD layer requesting arbitrary numbers of samples each frame, the core now pushes the appropriate number of samples based on the emulated time.<br /> <br /> * [[Aaron Giles]] simplified the OSD interface for sound. Removed osd_start_audio_stream and osd_stop_audio_stream; OSD initialization code is now responsible for initialization. Removed osd_get_mastervolume and osd_sound_enable, keeping management of the main volume in emu/sound.c.<br /> <br /> * [[Aaron Giles]] changed K054539 to run at native sample rate.<br /> <br /> <br /> == Game Support ==<br /> '''New games added or promoted from NOT_WORKING status'''<br /> * [http://www.mameworld.net/maws/romset/crazywar Crazy War]<br /> <br /> <br /> '''New clones added'''<br /> * [http://www.mameworld.net/maws/romset/spf2ta Super Puzzle Fighter II Turbo (Asia 960529)]<br /> * [http://www.mameworld.net/maws/romset/meikyuha Meikyuu Hunter G (Japan, set 2)]<br /> * [http://www.mameworld.net/maws/romset/chinhert Chinese Heroe (Taito)]<br /> <br /> <br /> '''New games marked as GAME_NOT_WORKING'''<br /> * [http://www.mameworld.net/maws/romset/ddrja Dance Dance Revolution (GC845 VER. JAB)]<br /> * [http://www.mameworld.net/maws/romset/dsftkd Dancing Stage featuring TRUE KiSS DESTiNATiON (G*884 VER. JAA)]<br /> * [http://www.mameworld.net/maws/romset/ddrsbm Dance Dance Revolution Solo Bass Mix (GQ894 VER. JAA)]<br /> * [http://www.mameworld.net/maws/romset/ddrs2k Dance Dance Revolution Solo 2000 (GC905 VER. AAA)]<br /> * [http://www.mameworld.net/maws/romset/ddr3ma Dance Dance Revolution 3rd Mix]<br /> * [http://www.mameworld.net/maws/romset/dncfrks Dance Freaks (G*874 VER. KAA)]<br /> * [http://www.mameworld.net/maws/romset/drmn2m DrumMania 2nd Mix (GE912 VER. JAA)]<br /> * [http://www.mameworld.net/maws/romset/ddr3mp Dance Dance Revolution 3rd Mix Plus (G*A22 VER. JAA)]<br /> * [http://www.mameworld.net/maws/romset/ddr4m Dance Dance Revolution 4th Mix (G*A33 VER. AAA)]<br /> * [http://www.mameworld.net/maws/romset/ddr4ms Dance Dance Revolution Solo 4th Mix (G*A33 VER. ABA)]<br /> * [http://www.mameworld.net/maws/romset/ddrusa Dance Dance Revolution USA (G*A44 VER. UAA)]<br /> * [http://www.mameworld.net/maws/romset/ddr4mp Dance Dance Revolution 4th Mix Plus (G*A34 VER. JAA)]<br /> * [http://www.mameworld.net/maws/romset/ddr4mps Dance Dance Revolution 4th Mix Plus Solo (G*A34 VER. JAA)]<br /> * [http://www.mameworld.net/maws/romset/dmx2m Dance Maniax 2nd Mix (G*A39 VER. JAA)]<br /> * [http://www.mameworld.net/maws/romset/ddr5m Dance Dance Revolution 5th Mix (G*A27 VER. JAA)]<br /> * [http://www.mameworld.net/maws/romset/dmx2majp Dance Maniax 2nd Mix Append J-Paradise (G*A38 VER. JAA )]<br /> * [http://www.mameworld.net/maws/romset/salarymc Salary Man Champ (G*A18 VER. JAA)]<br /> * [http://www.mameworld.net/maws/romset/ddrmax DDR Max - Dance Dance Revolution 6th Mix (G*B19 VER. JAA)]<br /> * [http://www.mameworld.net/maws/romset/ddrmax2 DDR Max 2 - Dance Dance Revolution 7th Mix (G*B20 VER. JAA)]<br /> <br /> [[Category:Releases 2007]]</div>

F205v https://wiki.mamedev.org/index.php?title=F205v&diff=1411 2007-12-14T15:55:20Z

<p>F205v: New page: f205v is the nickname used by Antonio Gerli, admin for the Mame_Italia forum.</p> <hr /> <div>f205v is the nickname used by Antonio Gerli, admin for the [[Mame_Italia]] forum.</div>

F205v https://wiki.mamedev.org/index.php?title=Mame_Italia&diff=1410 2007-12-14T15:52:20Z

<p>F205v: New page: Mame Italia is a collective name, representing all the members of the [http://www.mameitalia.net MAME Italian Forum]</p> <hr /> <div>Mame Italia is a collective name, representing all the members of the [http://www.mameitalia.net MAME Italian Forum]</div>

F205v