News:

Printed Amstrad Addict magazine announced, check it out here!

Main Menu
C

Amstrad CPC 6128 Spanish Version now correctly dumped

Started by Coherencia, 01:52, 10 April 16

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

Gryzor

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?

khaz

High horses everywhere.

Get off of them, people!

1024MAK

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
Looking forward to summer in Somerset :-)

Urusergi

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

Gryzor

What's the CRC of the newly dumped ROM? (sorry, am at work and can't check)

Urusergi

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

khaz

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?

Gryzor


Executioner

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.

Audronic

I thought that an "" Expert ""  (Ex Spurt) was DRIP Under Pressure.


Ray
Procrastinators Unite,
If it Ain't Broke PLEASE Don't Fix it.
I keep telling you I am Not Pedantic.
As I Live " Down Under " I Take my Gravity Tablets and Wear my Magnetic Boots to Keep me from Falling off.

remax

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.
Brain Radioactivity

Gryzor

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.

KaosOverride

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!!!
KaosOverride · GitHub
MEGA Amstrad Public Amstrad folder

andycadley

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:

1024MAK

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


Looking forward to summer in Somerset :-)

1024MAK

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
Looking forward to summer in Somerset :-)

arnoldemu

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. :)
My games. My Games
My website with coding examples: Unofficial Amstrad WWW Resource

robcfg

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 , 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.

remax

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.
Brain Radioactivity

remax

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.

Brain Radioactivity

1024MAK

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
Looking forward to summer in Somerset :-)

1024MAK

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
Looking forward to summer in Somerset :-)

remax

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).
Brain Radioactivity

1024MAK

Quote from: remax on 23:47, 15 April 16
Well, 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
Looking forward to summer in Somerset :-)

Enrique Ausina

#49
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.

Powered by SMFPacks Menu Editor Mod