Guru finally correctly dumped the roms of the spanish Amstrad CPC 6128. The existent roms in internet are bad dumped and not work in the actual emulators, now the roms dumped by guru yes, work.
You can read all the news here:
The Guru's ROM Dump News - AUSTRALIAN MIRROR (http://members.iinet.net.au/~lantra9jp1_nbn/gurudumps/)
I paste the partial info of that webpage here, you can read all the news in the posted webpage:
"7th April 2016
Another unusual item rolled up today..... an Amstrad CPC6128. The Spanish version. Thanks to Enrique for sending it out.
Here's some pics....
There is a fairly large archive of CPC ROMs (etc) at ROM List - CPCWiki (http://www.cpcwiki.eu/index.php/ROM_List)
However a lot of the OS ROMs are bad and don't work in emulators, including the Spanish version..... which is why the CPC6128 was sent to me for a re-dump :-)
The BASIC and BIOS are combined into one 32k 'OS' ROM and the Floppy OS is in a 16k ROM. You can see those two ROMs in the pic above, located just below the Z80 CPU.
The Floppy OS ROM is marked 'AMSTRAD 40015' at IC204 and the OS ROM is marked 'AMSTRAD 40038' at IC103.
The Floppy OS ROM is common to all versions of the CPC6128 and under the ROM, printed on the PCB is '40015'.
Under the OS ROM printed on the PCB it says '40025' so I'm guessing the regular common English version would be marked with that number too.
The existing dump of the Spanish OS ROM is 16k, therefore incomplete and thus bad.
The actual ROM is a 23256 mask ROM, but this particular OS ROM used in the CPC6128 is not 100% compatible with a 27256 and can't be read using that type. Because the ROMs are slightly non-standard it requires a little trick to get a good dump out of it.
I'm told the most important key on a Spanish keyboard is the enye (ñ), which is located next to the L key.
As you can see from the screen shot below (running in MAME), it is there and emulation is working just fine using my re-dumped ROMs :-)
The only other difference I see is the top title has a (s3) at the end, whereas the existing English version says (v3)."
Good it has been dumped again. There is no link on the page?
But I am confused: I believed all the dumps are good. The webpage claims most are bad?
Normally they are dumped using a program on the machine so are 100% correct. The ROMs may appear bad to MAME/MESS because they may be exactly 16384 bytes (without a header), or they may be larger and have an AMSDOS 128-byte file header on them which can be removed. They are also split into 16KB blocks because they are seen this way by the programmer. (first 16KB is 0000-3fff, remainder of 16KB is c000-ffff).
MAME expects ROMs to be represented as they are on the PCB. Dumps via software are generally only acceptable if there are no other options.
Quote from: mahlemiut on 23:25, 10 April 16
MAME expects ROMs to be represented as they are on the PCB. Dumps via software are generally only acceptable if there are no other options.
Whilst that makes sense for arcade boards that might have weird and wonderful hardware interactions, it seems a bit overkill for an 8-bit computer that can provably read the entire ROM accurately.
In the case of the Amstrad CPC I don't think it would make a difference, but remember that you can have roms splitted in odd and even chips but you'll be reading it as a single one.
So, if it's easy to take them out of a socket, just dump it with a programmer.
A special case is the rom inside a MCU, like some DMP Printers' ones, which you can only dump by using arcane software tricks (we had a lot of fun burning an eprom with a special program to read the MCU rom, sending it to the CPC and reading it with a basic program 8) ).
This is a bit odd.
We (CPCWIKI) have had the Spanish dump for years (think I uploaded it from a dump I got somewhere online years and years ago).
It works perfectly in WinCPC, WinApe, and burnt to an eprom and fitted in a real 6128.
So what is it that is wrong with the dump we have...what does not work ???
And if there is a genuine issue, are the French and English dumps we have correctly dumped ?? How to tell ??.
From 'The guru's' site...
QuoteThere is a fairly large archive of CPC ROMs (etc) at ROM List - CPCWiki (http://www.cpcwiki.eu/index.php/ROM_List)
However a lot of the OS ROMs are bad and don't work in emulators, including the Spanish version..... which is why the CPC6128 was sent to me for a re-dump :-)
The BASIC and BIOS are combined into one 32k 'OS' ROM and the Floppy OS is in a 16k ROM. You can see those two ROMs in the pic above, located just below the Z80 CPU.
The Floppy OS ROM is marked 'AMSTRAD 40015' at IC204 and the OS ROM is marked 'AMSTRAD 40038' at IC103.
The Floppy OS ROM is common to all versions of the CPC6128 and under the ROM, printed on the PCB is '40015'.
Under the OS ROM printed on the PCB it says '40025' so I'm guessing the regular common English version would be marked with that number too.
The existing dump of the Spanish OS ROM is 16k, therefore incomplete and thus bad.
The actual ROM is a 23256 mask ROM, but this particular OS ROM used in the CPC6128 is not 100% compatible with a 27256 and can't be read using that type. Because the ROMs are slightly non-standard it requires a little trick to get a good dump out of it.
Cheers,
Shane
Is this related to the address decoding used to actually access the ROM?
Only the data in the ROM chip is contained in it as a continuous memory range from 0x0000 through to the last physical memory location. If you put the ROM in a programmer and "dump" (copy) the data, this is the file you get.
But in some computers, the memory decoding circuitry controls the ROM so that different parts appear in different places in the CPUs address range. So the BIOS will be in one part, and BASIC will be in a different part.
Of course, if you use the computer to copy data from it's own ROM chip(s), this should be known about, and so can be compensated for. But what format do the emulators want the file containing the ROM in?
Mark
Quote from: andycadley on 08:14, 11 April 16
Whilst that makes sense for arcade boards that might have weird and wonderful hardware interactions, it seems a bit overkill for an 8-bit computer that can provably read the entire ROM accurately.
MAME is a documentation project - you should be able to burn new ROMs and knowing which ROMs contain what would be rather important.
And don't get me started on the FM Towns, which has 5 or 6 (or 10 on the FM Towns Marty) separate ROM areas mapped, but only has 1 or 2 larger ROMs on the board (plus a serial ROM containing model info). All are readable in software, and as such, most dumps are based on those software methods. There are only 2 proper FM Towns ROM dumps in MAME, out of 10 sets in total. And one of the proper dumps lacks the serial ROM anyway. Computer systems certainly can be just as crazy (probably more so) as arcade systems, which often don't use the hardware to it's fullest potential.
for those 2 good FM Towns ROM dumps, are you including the FM Towns Marty? I dumped that from a PCB that was sent here some years ago.
I wasn't aware there was a serial ROM on that board? but then again I probably wasn't looking for it either ;-)
for the Spanish dump, I tried the one from cpcwiki and all I got was a white screen.
Both ROMs were 16k. The floppy ROM matches my dump. The OS ROM is only 16k which means the OS ROM is bad, dumped at half size.
The OS ROM should be 32k. As far as MAME is concerned any other size makes it bad. The real ROM is 32k so it is dumped as 32k.
The dumps on CPCWiki are not bad, but they are not necessarily representative of the actual ROM (e.g. they may be separate 16KB instead of 32KB) and therefore they should be more classed as not suitable for mame rather than bad dumps.
I know mame claims anything is a bad dump if it doesn't match it's criteria, but in reality they are not because the data is accurate.
many of those computer/console dumps are classic examples of amateur dumps that were done for emulators. in the case of some they were hacked to work with emulators and dont work on real hardware. we found out what was bad/hacked and many people such as Cowering have spent a great deal of time and money over the last 15 years cleaning up those inaccurate dumps (i.e. NES/SNES/Mega Drive etc etc) and redumped the ROM files so they are actual dumps from ROMs.
We *really* don't need more of that kind of emulator-only thing. now we only do it right.
Dumps should be of actual chips so they can be used to repair the real thing. At the very least roms dumped on a computer should be tested on the real thing to verify they really are good. Archives of inaccurate dumps are really not useful for anything except emulators, which is not proper preservation.
as far as the CPC6128 is concerned, the manual clearly states there is 48kbytes of ROM. 16+32=48. The math doesn't lie.
anyway, it doesn't matter to me if the CPCWiki dumps are good or not. As far as MAME is concerned most of those don't exist because they don't work with the CPC6128 emulation in MAME. If you want to host a pile of ROMs that don't represent the real thing that's up to you and your decision.
I have tested all the OS ROMs on the Wiki and ALL are good and ALL work on real hardware. You may just be referring to the fact that the 32K ROMs are sometimes split into 2x 16K (Lower ROM and BASIC). Lack of knowledge of the CPC system is no reason to call them bad. 10 seconds with a hex editor and you can paste them back into one 32K ROM if required.
Bryce.
Quote from: Mr T. Guru on 11:05, 12 April 16
many of those computer/console dumps are classic examples of amateur dumps that were done for emulators. in the case of some they were hacked to work with emulators and dont work on real hardware. we found out what was bad/hacked and many people such as Cowering have spent a great deal of time and money over the last 15 years cleaning up those inaccurate dumps (i.e. NES/SNES/Mega Drive etc etc) and redumped the ROM files so they are actual dumps from ROMs.
We *really* don't need more of that kind of emulator-only thing. now we only do it right.
Dumps should be of actual chips so they can be used to repair the real thing. At the very least roms dumped on a computer should be tested on the real thing to verify they really are good. Archives of inaccurate dumps are really not useful for anything except emulators, which is not proper preservation.
as far as the CPC6128 is concerned, the manual clearly states there is 48kbytes of ROM. 16+32=48. The math doesn't lie.
anyway, it doesn't matter to me if the CPCWiki dumps are good or not. As far as MAME is concerned most of those don't exist because they don't work with the CPC6128 emulation in MAME. If you want to host a pile of ROMs that don't represent the real thing that's up to you and your decision.
Welcome on board ;)
Now, if you are that picky on using original[nb]I can send you files that represent the ROM of the CPC, dumped from the ROM and using SW, if you can tell me which are which, I'll eat my hat[/nb] dump, you should go away from the CPC at all.
[sarcasm]
Do you know that the heart of the CPC is a gate array and so far no one have dumped the top metal layer that makes the generic chip CPC specific.
So for now every CPC emulator are amateur emulation in the sense that they to not use the GA ROM mask to make it work. If you have cash to throw at, just do a proper dump of that metal layer, and when you're at it, get all underneath layers as well for your documentation.
[/sarcasm]
Hi guys,
I'm on the MAME side of things when it comes to dumping and documenting systems, but I can understand that for the casual user of emulators any format that gets the emulator launched with his favourite game is good enough.
Now, when it comes to the content of the files, these are correct, but splitted. It would be nice to take advantage of the situation and verify that the rom dumps match.
I think we should have a clear distinction between roms for emulators and exact dumps of the chips, maybe have both formats available.
@gerald (http://www.cpcwiki.eu/forum/index.php?action=profile;u=250) : CPCManiaco and I just send some GA chips for decapping and we have already the 40010 picture. I'm figuring out how to upload the beast to the wiki :D
Please, let's keep the thread positive, arguing is not going to bring anything useful.
Quote from: robcfg on 11:53, 12 April 16
I'm on the MAME side of things when it comes to dumping and documenting systems, but I can understand that for the casual user of emulators any format that gets the emulator launched with his favourite game is good enough.
I'm ok with the concept of having a 32K image. But bitching at the ROM stored on CPCWiki (or anywhere else) is just too much.
Everyone knowing how the CPC works is able to make a 'device' file out of them. Only ignorant or snob will tell these do not work.
Quote from: robcfg on 11:53, 12 April 16
@gerald (http://www.cpcwiki.eu/forum/index.php?action=profile;u=250) : CPCManiaco and I just send some GA chips for decapping and we have already the 40010 picture. I'm figuring out how to upload the beast to the wiki :D
Can you share detail on who did the de-capping/ imaging. I've got an ASIC waiting for that ;)
We sent a 40007, 40010, PreASIC and ASIC ;D
Quote from: Mr T. Guru on 11:05, 12 April 16
as far as the CPC6128 is concerned, the manual clearly states there is 48kbytes of ROM. 16+32=48. The math doesn't lie.
The ROM images concerned are original dumps of the unmodified Spanish firmware and BASIC. The AMSDOS ROM is a separate chip in the CPC (16K), and the Operating System and BASIC ROM are contained in a single chip but are mapped into two separate 16K memory spaces. These are not hacked in any way to work on emulators. As far as I know all emulators for the CPC work with standard ROM images, although most won't work with a single 32K OS image. If MESS insists on such a thing then join the two files.
So after all the arguing, it does come down to how the address decoding splits the physical 32k byte ROM in to the different address ranges that the Z80 CPU sees in the CPC.
As Bryce says, any decent Hex editer can split or combine the relevant binary ROM files as required. [And some command line OS systems can combine two binary ROM files faster than you can type the command...].
Talk about making a mountain out of a mole hill.... ???
Mark
Quote from: 1024MAK on 12:43, 12 April 16
So after all the arguing, it does come down to how the address decoding splits the physical 32k byte ROM in to the different address ranges that the Z80 CPU sees in the CPC.
As Bryce says, any decent Hex editer can split or combine the relevant binary ROM files as required. [And some command line OS systems can combine two binary ROM files faster than you can type the command...].
Talk about making a mountain out of a mole hill.... ???
Mark
yes it is down to address decoding, but statements like this are untrue:
"
However a lot of the OS ROMs are bad and don't work in emulators, including the Spanish version..... which is why the CPC6128 was sent to me for a re-dump :-)"
That is what angered me.
I do agree with @robcfg (http://www.cpcwiki.eu/forum/index.php?action=profile;u=4), having both "full" dumps and separated dumps is the best thing to do.
I don't see it as arguing, it is Just that we have all been using the ROM dumps on the WIKI for years, and someone comes along and says they are no good.
Simple fact is, they are good and work on real machines. Have burnt them to eproms myself and on a Spanish machine no less using the exact dump that was deemed rubbish (as mentioned, you just need to concatenate the OS 16k & BASIC 16k files).
That 6128 has been flawless for years with everything from all manner of software and hardware add ons that I have tested on it.
Cheers,
Shane
Quote from: robcfg on 11:53, 12 April 16
@gerald (http://www.cpcwiki.eu/forum/index.php?action=profile;u=250) : CPCManiaco and I just send some GA chips for decapping and we have already the 40010 picture. I'm figuring out how to upload the beast to the wiki :D
Please, let's keep the thread positive, arguing is not going to bring anything useful.
Oh really?. You can reverse enginering the ga circuit schematic?. I love this things, as i study it a little in the university. :) .
Prior to the CPC6128 being sent out I had no knowledge of the CPCWiki or what it contained. As far as using whatever emulator you used, nothing has changed.
My ROMs work in MAME, your ROMs work with whatever you say they work with. I neither care to check further nor am I going to argue with anyone about it.
I spent more than 15 years repairing and working with electronics and thousands of dollars on equipment and dumped many thousands of ROMs. Arguing with me is pointless, I'm an expert in this field, regardless of what you or others think.
This is exactly the kind of contempt and disrespect for my work that causes me to add delays to releases or not release things at all.
The bottom line is I was told by a guy in Spain the Spanish dump does not work in emulators and he sent me a unit to dump. I dumped it and tried it in MAME and it works. The dump from the Wiki doesn't work in MAME. It's as simple as that.
Regarding most of the previous posts, all I can say is if you think my dumps are no good and the existing ROMs are good, then clearly you do not understand the importance of proper archiving and documentation for future generations.
But fine, just continue as-is with whatever makes you happy.
My CPC6128 dumping work is done and therefore I'm done here. I won't be reading, replying or returning.
The end.
Wow, someone got up on the wrong side of the bed this morning.
Where can we download this new spanish 6128 ROM?
@Mr T. Guru: I am sure that you have lots of experience in dumping ROMs etc and I also understand that you did this at the request of someone else. However, making statements such as "a lot of the OS ROMs are bad" without having first investigated whether they were really bad or just not the exact format that some specific emulator needs was perhaps not such a good idea. A quick read of the CPCWiki and a few clicks in a Hex-editor would have saved a lot of time and postal costs.
Bryce.
Maybe the problem here is terminology. In electronics a "ROM" is a physical chip. They come in different sizes and in different bit widths (8 bit / byte wide, 16 bit / word size etc).
Over time, the cost of memory including ROM chips has fallen. So computer manufacturers combined more code in to larger and larger ROM chips. Even when the actual code or data contained in the ROM chip is used in different areas of the memory map of the computer.
The term "ROM" is also used to mean "ROM" file. "ROM" files come in many different forms and formats. The simplest is a straight binary file which contains a digital copy of the contents of a real ROM chip. But there are many more "ROM" file types. When combined with people's tendency to abbreviate, sometimes it is not always clear exactly what is being talked about.
Leaving aside some sites where game files (etc) are also known as "ROM"s even though some of these are versions of digital representations of disk or cassette files...
So briefly moving away from the CPC for the moment, Atari with their STFM and STE range of computers started off using six ROM chips. But in later issue boards, combined the content of theses six chips into only two chips. As far as the computer's CPU is concerned, there is NO difference between the OS being on six ROM chips or two ROM chips. A copy of the data/code from these six ROM chips is no more or less valid than the code/data from the two ROM chips. A simular thing happened with the Acorn Electron, the first version had two 16k byte ROM chips. Later issue boards used a single 32k byte ROM chip. The code for both versions is exactly the same.
Because (I presume) MAME emulates the address decoding of the hardware at the hardware level, it may well need the ROM file to be 32k bytes in size (which will contain the OS/lower ROM area with the BASIC ROM). However, that does not at any point make the two seperate 16k bytes ROM files (seperate OS/lower ROM file and seperate BASIC ROM file) any less valid. For use in an emulator like MAME, the two 16k byte files just need to be combines/joined.
This combining of ROM files is exactly what Atari ST hardware guys have been doing for years. Same with the Sinclair Spectrum and Acorn BBC/Electron communities. It's not new.
So this problem is not unique to the CPC.
@Mr T. Guru (http://www.cpcwiki.eu/forum/index.php?action=profile;u=1724) - regardless of why you copied the ROMs, it is always good that people want to ensure that the ROMs of machines are preserved, and we of course welcome MAME being maintained and extended :D
However, if someone from this forum was to go and say that one or more of the ROMs used by MAME was bad because it did not work in a real machine, no doubt you would get upset.
I don't think you intended to upset this community, but that is what has happened.
The 32k byte ROM image posted by Mr T. Guru is not wrong/bad and the 16k byte ROM images on the CPC Wiki are also not not wrong/bad.
Mark
Wow, how did it come to this?
Indeed, when I was sent the ROM dump I was wondering what's wrong with the dumps we already have, but thought - eh, I never use the Spanish ROM so I'll look around, there might be something to it.
I can see the value of proper archiving, but does it really matter if, say, you got a ROM that's some bytes long and you type it instead of dumping it? Is the dumped result any better for archival reasons?
In the end, I think T Guru's approach wasn't unwarranted - he's not familiar with the CPC per se and he was told (erroneously so) that the existing dump was bad, so he went about fixing that - which is something admirable. At most, an effort duplication. But the "Arguing with me is pointless, I'm an expert in this field, regardless of what you or others think" part really irked me; obviously you can be an expert in electronics but not an expert in common sense.
it saddens me that it escalated this way - after all, we're all after the same, more or less, thing.
I'm uploading the ROM here, should we add it to the Wiki with a relevant explanation?
High horses everywhere.
Get off of them, people!
Quote from: Gryzor on 14:54, 12 April 16
it saddens me that it escalated this way - after all, we're all after the same, more or less, thing.
I'm uploading the ROM here, should we add it to the Wiki with a relevant explanation?
It saddens me too, as well. There should be no difference between a 32k byte ROM file copied from a real ROM chip and a combined 32k byte ROM file made by joining a 16k byte OS/lower ROM file and a 16k byte BASIC ROM file.
However, it would be worthwhile adding an explanation to the Wiki and there is certainly no harm in adding the 32k byte ROM files so that it makes life easier for all. After all, we want to help preserve CPCs both the hardware and also encourage proper and correct emulation, as the hardware will not last forever.
Mark
os6128(Spanish).rom -> 16.384 bytes -> CRC32: A9937F75
basic6128(Spanish).rom -> 16.384 bytes -> CRC32: B6E4ACD2
C:\COPY /B os6128(Spanish).rom+basic6128(Spanish).rom cpc6128sp.rom
cpc6128sp.rom -> 32.768 bytes -> CRC32: 2FA2E7D6
What's the CRC of the newly dumped ROM? (sorry, am at work and can't check)
Quote from: Gryzor on 15:21, 12 April 16
What's the CRC of the newly dumped ROM? (sorry, am at work and can't check)
cpc6128.rom -> 32.768 bytes -> CRC32: 2FA2E7D6
cpcados.rom -> 16.384 bytes -> CRC32: 1FE22ECD
Quote from: Urusergi on 15:19, 12 April 16
os6128(Spanish).rom -> 16.384 bytes -> CRC32: A9937F75
basic6128(Spanish).rom -> 16.384 bytes -> CRC32: B6E4ACD2
C:\COPY /B os6128(Spanish).rom+basic6128(Spanish).rom cpc6128sp.rom
cpc6128sp.rom -> 32.768 bytes -> CRC32: 2FA2E7D6
Quote from: Urusergi on 15:30, 12 April 16
cpc6128.rom -> 32.768 bytes -> CRC32: 2FA2E7D6
cpcados.rom -> 16.384 bytes -> CRC32: 1FE22ECD
So, much ado about nothing then?
It would appear so??
Quote from: Mr T. Guru on 14:12, 12 April 16
I spent more than 15 years repairing and working with electronics and thousands of dollars on equipment and dumped many thousands of ROMs. Arguing with me is pointless, I'm an expert in this field, regardless of what you or others think.
This is exactly the kind of contempt and disrespect for my work that causes me to add delays to releases or not release things at all.
What an arrogant prick. I've been doing similar for over 30 years now, about twice as long as you have.
QuoteMy CPC6128 dumping work is done and therefore I'm done here. I won't be reading, replying or returning.
The end.
What a relief, with your attitude. You obviously won't read this reply either.
I thought that an "" Expert "" (Ex Spurt) was DRIP Under Pressure.
Ray
Guru is doing a great job dumping lots of chips, but has a problem with communication, to such an extend that main MAME developpers insists what he says represents in no way the MAME team.
So think what you want of what he said here, but don't blame it on MAME.
I don't think there was any blame placed on MAME - its philosophy was discussed briefly and that was it... totally separate, of course, from Guru's tone.
O man... after reading the threath just some thoughts...
I understand the MAME way of work, to use exact dumps as the machine does, for documental porpouses, etc... Because of this at some far version they changed the rom structure of lot of dumps because they where reconstructed to optimize, like even/odd roms unified in one file, then later splitted or redumped to meet hardware fidelity. That's OK
On the other side we have the CPC emulation community that for lot of years has been able to dump and make them working under emulation the CPC system roms and others. Because we see the CPC rom system at the system banking side, we have one rom for firmware, other for basic, other for amsdos... just works and is OK also
But for any reason that does not fit with the MAME needs
Is the dump bad? no, it's not BAD
Is the dump unnacurate? YES for MAME's own standars, NO for use at the real machines (Bryce's FlashROM and ToTo's X-MEM board,etc...) and for the rest of emulators.
If one finds that there is no "MAME compatible dump" he could ask here and could obtain the instructions to concatenate the firmware+basic rom without AMSDOS headers and everything sholud be OK, problem ended
Other thing is that for MAME the dump MUST be certified coming from REAL hardware and chips, and any other dumps should be considered as provisional, for documental porpouses.
People that knows very well the machine can think that with an UK CPC MAME dump and some HexEditor sorcery can make the SP CPC MAME dump. It works, it's CRC OK, etc etc but can't be certified that comes directly from an SP ROM chip.
But for MAME this could not be a sane method, then Mr T Guru work is OK, just for certification porpouses. If there is no severe need that the info must come from a real chip without manipulation, then the dumps where well done, just because MAME needs hardware splits, the AMSTRAD CPC community has been doing logical ROM PAGE splits. Each community their own methods.
No one has the unique truth, each one has their own needs
Maybe is a good moment to think about hosting the firmware dumps this way along with the actual ones, if someone want's to flash some ROM for a real CPC (Example: Use an UK board to repair an FR CPC and we have no FR ROM chip dump ) the same way the cartdrige are hosted as .CPR and .BIN. Just because someone knows how to build a BIN from a CPR does not mean that other one knows how... And also for documental porpouses of the CPC community!!!
This are just my thoughts, nothing more
Peace for everyone!!!
Going into a community, dismissing all their work as "bad", claiming to be the only expert and then having a hissy fit when people don't "appreciate" your effort even though it lead to exactly the same results as previous work you derided? Not really a wise move. And probably the reason that Mame's CPC emulation is way behind, the people who really are experts just can't be bothered dealing with that much ego.
But hey ho, I look forward to the Mame community showing us all up by producing "certified" versions of all those GX conversions that CPCWiki is foolishly hosting "bad" versions of. :picard2:
So, is the data from a ROM chip any different when read by a CPU in a programmer or when read by the CPU in a working computer that actually contains the very same ROM chip?
No, as long as the correct ROM chip / area is paged in, there is NO difference to the read data.
This is a bit like debating whether today's date should be written 15/04/2016 or 2016-04-15 - both are correct, both have the same data...
Or whether addresses should be written as 0x5B5A or as &5B5A etc...
And as I said in an earlier post, computer manufacturers have changed the ROM size as larger chips have come down in cost. So which ROMs would MAME consider to the the "correct" ones?
And how the data in a computer ROM is seen by a CPU depends on the glue logic or custom IC(s) that carry out the address decoding. Not the just on the ROM chip alone.
Mark
Oh, and one final thought from me. I think the problem here is that all our CPC systems must not be working correctly, as the CPU in our systems cannot access the correct data from the ROM in the same way that a programmer can....
This can be proved by the fact that the "bad" ROM dumps on the CPC Wiki work in real CPC systems. This proves that all real CPC systems are flawed...
Mark
Quote from: 1024MAK on 14:41, 15 April 16
So, is the data from a ROM chip any different when read by a CPU in a programmer or when read by the CPU in a working computer that actually contains the very same ROM chip?
On some machines it *is*. The BBC has memory mapped i/o over part of it's ROM, so the bit underneath contains messages. So the CPU doesn't read the exact rom contents.
I think one cpc device, maybe mirage imager(?) has the i/o addresses mixed up, so reading rom data is different to what the cpu can read (actually not sure the cpc can read the rom easily, it may only exist when nmi is triggered).
But we all know that the CPC rom is easily and readable completely. :)
Guys, I think it's more than enough.
I've dumped a lot of stuff for MAME and I appreciate that they try to document the hardware faithfully. In this point of view, if the chip has 32KB of data, you should have a single 32KB file.
For example, Acorn Archimedes have two big 2MB chips, one for the odd addresses and another for the even addresses. Emulators do work with one single 4MB file, sure, same as CPC emulators work with split rom files. But from a hardware point of view this is not correct, which is what Guru tried to tell.
Now, whether this is practical for CPC emulators or not, it's not clear. Obviously if you want accurate hardware information, the MAME way is the way to go. If you just want to play some games, it's not really that important.
As I suggested, it would be nice to have the roms in both formats as, for example @mahlemiut (http://www.cpcwiki.eu/forum/index.php?action=profile;u=89) , is doing quite a nice work on the MAME CPC drivers.
I really think there should be a way to avoid this clashes, as collaboration yields better results for everyone.
Quote from: Gryzor on 13:12, 13 April 16
I don't think there was any blame placed on MAME - its philosophy was discussed briefly and that was it... totally separate, of course, from Guru's tone.
Well. Look at the last posts and you'll what i mean.
Quote from: 1024MAK on 14:41, 15 April 16
So, is the data from a ROM chip any different when read by a CPU in a programmer or when read by the CPU in a working computer that actually contains the very same ROM chip?
No, as long as the correct ROM chip / area is paged in, there is NO difference to the read data.
This is a bit like debating whether today's date should be written 15/04/2016 or 2016-04-15 - both are correct, both have the same data...
Or whether addresses should be written as 0x5B5A or as &5B5A etc...
In some computers, the whole rom is not accessible or is modified (interleaved for example). The only way to be sure the Dump match the original rom is to dump directly from the chip. That doesn't mean dumping from software necessarily means that the resulting dump is bad.
QuoteAnd as I said in an earlier post, computer manufacturers have changed the ROM size as larger chips have come down in cost. So which ROMs would MAME consider to the the "correct" ones?
Mame dumps the various chips and documents them as variations.
Quote from: arnoldemu on 19:43, 15 April 16
On some machines it *is*. The BBC has memory mapped i/o over part of it's ROM, so the bit underneath contains messages. So the CPU doesn't read the exact rom contents.
I think one cpc device, maybe mirage imager(?) has the i/o addresses mixed up, so reading rom data is different to what the cpu can read (actually not sure the cpc can read the rom easily, it may only exist when nmi is triggered).
But we all know that the CPC rom is easily and readable completely. :)
Yes, I am well aware that in systems that use memory mapped IO, the IO area can share addresses with the ROM area. Some systems also share ROM and RAM areas, And some dynamically remap ROM and RAM (Atari ST/STFM/STE etc) during start-up. But the principle is the same, All data and code that is available to the CPU is the same whether the CPU reads it, or a programmer reads it.
Before someone gets really picky and points out that some expansions for some systems had the address and data lines for the ROM/PROM/EPROM wired in a non-standard way, yes that does mix the sequence up, but that is rare.
And for the record (although I think I may have alluded to this already), I have got nothing against MAME. And most of the people involved in maintaining and extending it are good people, who are doing good work - may this continue until all retro systems are fully emulated.
Mark
Quote from: remax on 20:23, 15 April 16In some computers, the whole rom is not accessible or is modified (interleaved for example). The only way to be sure the Dump match the original rom is to dump directly from the chip. That doesn't mean dumping from software necessarily means that the resulting dump is bad.
With data busses that are larger than 8 bits, for the hardware engineer there is the option of using 8 bit wide ROMs, or 16 bit ROMs etc. If like in an ATARI ST/STFM/STE they decided to use 8 bit ROMs, half have the low bytes and the rest have the high bytes. But the data could be stored in a 16 bit wide ROM in a later version of the board if the manufacturer wanted (say when the cost of the larger ROM chips had fallen). This is not much different to the address decoding putting different bit of the ROM address space in different areas of the CPU address space. As long as the layout is known, it is relatively simple to write a program to rearrange the "software ROM dump" to match the data as copied from a/the ROM chip(s). The thing is, if the machine is a rare example, we don't want to be desodering ROM chips just because of a strange notion that the only "correct" copy is via a programmer.
Quote from: remax on 20:23, 15 April 16Mame dumps the various chips and documents them as variations.
Good. But this does mean that there will be duplication. So good record keeping is needed.
Mark
Quote from: 1024MAK on 23:27, 15 April 16
With data busses that are larger than 8 bits, for the hardware engineer there is the option of using 8 bit wide ROMs, or 16 bit ROMs etc. If like in an ATARI ST/STFM/STE they decided to use 8 bit ROMs, half have the low bytes and the rest have the high bytes. But the data could be stored in a 16 bit wide ROM in a later version of the board if the manufacturer wanted (say when the cost of the larger ROM chips had fallen). This is not much different to the address decoding putting different bit of the ROM address space in different areas of the CPU address space. As long as the layout is known, it is relatively simple to write a program to rearrange the "software ROM dump" to match the data as copied from a/the ROM chip(s). The thing is, if the machine is a rare example, we don't want to be desodering ROM chips just because of a strange notion that the only "correct" copy is via a programmer.
Well, there are numerous example of people "who knows" and who have been proven wrong by copy via a programmer.
QuoteGood. But this does mean that there will be duplication. So good record keeping is needed.
Mark
Well the parent/child rom system avoid a lots of the duplication (even if not all).
Quote from: remax on 23:47, 15 April 16Well, there are numerous example of people "who knows" and who have been proven wrong by copy via a programmer.
Of course, as people make mistakes. That's why mankind invented and developed computers based on machines instead of using people trained as computers... This is one of five programmers that I have:-
[attach=2]
Mark
You have a good programmer, Guru only say what the pre-existent roms dumped of the spanish version not are divided, classified, and documented, are in a single file, not one rom for the OS(BASIC) and other for the keyboard, you understand me?, sorry, my english is poor (:.
Now you have the roms dumped by Guru in this thread, I sended to Gryzor and he posted here. I are the donator.
Thanks to Guru, Gryzor, and I.
Quote from: robcfg on 19:51, 15 April 16
Guys, I think it's more than enough.
I really think there should be a way to avoid this clashes, as collaboration yields better results for everyone.
AMEN!!! :) :) :)