01-08-2005, 11:48 AM
Voici les quelques échanges que j'ai eu avec Charles MacDonald pour bosser sur un éventuel adaptateur ou d'éventuels sets pour toutes les plateformes SEGA à base de Hitashi FD1094 (le FD1089 étant facilement hackable!)
...ayant évidemment leur pile HS...
1er Mail:
> - For FD1089, i have understand that it's possible to make a 68K working with a
> decrypted rom...Am i wrong ?
Yes. You need to replace the program ROMs with ROMs that are exactly
twice as large, and store the decrypted data in one half and decrypted
opcodes in the other. Then the high order address line is driven by
the FC1 pin of the 68000 (maybe you'd need a buffer or synchronize it
with the CPU clock, but it would be very simple to do)
This is because you can decrypt all of the game program at once, so
you don't need to 'simulate' the actual decryption that the FD1089
does.
> - For FD1094, it seem to be more harder (impossible?)...can i dream to make a
> decrypted rom set of super monaco working with a standrad 68K? why not trying
> to make a TTL adaptator branched on 68K DMA to "modify" what is need to be
> modified! (i'm good at electronic and TTL chip but your work is very "confused"
> du of his dificulty! )
In this case, the data that is extracted from the FD1094 is the key
used by the decryption hardware, so to make a FD1094 replacement, it
would have to implement the decryption logic itself.
The decryption is closely tied to the 68000 and could not be
implemented externally. You'd have to use a FPGA with a modified 68000
processor core. This would be a *lot* of work and AFAIK there are no
'free' 68000 cores (I've been doing some FPGA work recently, and may
try this at some point)
The main problem is that there are several ways that the same
encrypted program ROMs can be decrypted. This is affected by the game
code itself.
One method (I did this for Tetris) is to manually go through the
program and combine the different decrypted pieces of code together,
to make a single decrypted ROM that will work on a 68000.
You can never be 100% sure that you've put all the right pieces
together (in theory), however realistically all games do a few
encryption 'changes' during startup, and never change again. So it is
actually quite easy to identify this.
I was thinking of putting up a section at my webpage with some tools
and an explanation of how to do this, so people with a little 68000
knowledge could make patched ROM sets like this. Do you think that
would be useful?
> ...i think about make an adaptator switching the data bus bits correctly when
> it's needing! (or adress bus)
> ...Or does i need a little RAM chip to do another things? (your famous state bit
> for 1094?)
You'd need all that; plus some way to monitor which instructions are
executed (the RTE and CMPI.L instruction) which is nearly impossible
to do because of the prefetch queue. The decryption logic is closely
tied to the internal state of the 68000 which isn't possible to
determine from the outside - that's why I think the only solution
would be your own modified 68000 processor core, and the only way to
physically implement that would be on an FPGA.
> The best result for your work is to make a real hardware working without HITASHI
> and not "emulating" on computer (it's great and very kind for all guys who
> haven't got the luck to own a real machine to make the dream come true on MAME,
> but think about SEGA hardware golden area wich become to died )
Yeah, I have a dead Alien Storm board myself, and would like to get it
working someday.
Regards,
-- Charles
2ème mail:
> - You mean FD is a real custom 68K (with his own opcodes???)...So the
> Program ROMs ares not "encrypted", there are FD68K designed !!!???
Well, it's a regular 68000 but customized in the sense that some
instructions (RTE and CMPI.L #$imm32, d0), and the 68000's interrupt
management control some aspects of the decryption logic.
> - Why a custom 68K core for hacking dead hardware?
Because there would be no way through external circuitry to make a
68000 act like the FD1094 does.
> - ...for my poor level of computer designed, i know that an opcode is a
> logic group of data (so electricaly, a group of 16Bits binary state on the
> data bus of the CPU)...So why not filtering theses "custom" (???) opcodes
> with TTLs or GAL on a custom little PCBmounted on the 68K soket??? ...or a
> 2x 68K pcb with one making valid code for the other with little RAM and
> TTLs...(easy to say but it seem to be great !)...or directlly ROM patched
> with static walid code...(as i understand, it's more remake a complete game
> unlike patching )
It would take a lot of logic, you'd have to monitor all data fetched
by the 68000 and somehow guess what it's doing to the prefetch queue
to know what data is discarded (e.g. after a branch) and what data was
actually used.
That's the core of the problem, just trying to figure out which
instructions are being executed. Because the 68000 reads several words
at once, it isn't possible to know.
> - ...a section on your web site to explain in detail how the FD work will be
> very necessary. A result of your good work "black on white"
...
Ok, I'll work on that, at some point.
Regards,
-- Charles
...Un personnage vraiment sympa et doué qui plus est
...ayant évidemment leur pile HS...
1er Mail:
> - For FD1089, i have understand that it's possible to make a 68K working with a
> decrypted rom...Am i wrong ?
Yes. You need to replace the program ROMs with ROMs that are exactly
twice as large, and store the decrypted data in one half and decrypted
opcodes in the other. Then the high order address line is driven by
the FC1 pin of the 68000 (maybe you'd need a buffer or synchronize it
with the CPU clock, but it would be very simple to do)
This is because you can decrypt all of the game program at once, so
you don't need to 'simulate' the actual decryption that the FD1089
does.
> - For FD1094, it seem to be more harder (impossible?)...can i dream to make a
> decrypted rom set of super monaco working with a standrad 68K? why not trying
> to make a TTL adaptator branched on 68K DMA to "modify" what is need to be
> modified! (i'm good at electronic and TTL chip but your work is very "confused"
> du of his dificulty! )
In this case, the data that is extracted from the FD1094 is the key
used by the decryption hardware, so to make a FD1094 replacement, it
would have to implement the decryption logic itself.
The decryption is closely tied to the 68000 and could not be
implemented externally. You'd have to use a FPGA with a modified 68000
processor core. This would be a *lot* of work and AFAIK there are no
'free' 68000 cores (I've been doing some FPGA work recently, and may
try this at some point)
The main problem is that there are several ways that the same
encrypted program ROMs can be decrypted. This is affected by the game
code itself.
One method (I did this for Tetris) is to manually go through the
program and combine the different decrypted pieces of code together,
to make a single decrypted ROM that will work on a 68000.
You can never be 100% sure that you've put all the right pieces
together (in theory), however realistically all games do a few
encryption 'changes' during startup, and never change again. So it is
actually quite easy to identify this.
I was thinking of putting up a section at my webpage with some tools
and an explanation of how to do this, so people with a little 68000
knowledge could make patched ROM sets like this. Do you think that
would be useful?
> ...i think about make an adaptator switching the data bus bits correctly when
> it's needing! (or adress bus)
> ...Or does i need a little RAM chip to do another things? (your famous state bit
> for 1094?)
You'd need all that; plus some way to monitor which instructions are
executed (the RTE and CMPI.L instruction) which is nearly impossible
to do because of the prefetch queue. The decryption logic is closely
tied to the internal state of the 68000 which isn't possible to
determine from the outside - that's why I think the only solution
would be your own modified 68000 processor core, and the only way to
physically implement that would be on an FPGA.
> The best result for your work is to make a real hardware working without HITASHI
> and not "emulating" on computer (it's great and very kind for all guys who
> haven't got the luck to own a real machine to make the dream come true on MAME,
> but think about SEGA hardware golden area wich become to died )
Yeah, I have a dead Alien Storm board myself, and would like to get it
working someday.
Regards,
-- Charles
2ème mail:
> - You mean FD is a real custom 68K (with his own opcodes???)...So the
> Program ROMs ares not "encrypted", there are FD68K designed
!!!???Well, it's a regular 68000 but customized in the sense that some
instructions (RTE and CMPI.L #$imm32, d0), and the 68000's interrupt
management control some aspects of the decryption logic.
> - Why a custom 68K core for hacking dead hardware?
Because there would be no way through external circuitry to make a
68000 act like the FD1094 does.
> - ...for my poor level of computer designed, i know that an opcode is a
> logic group of data (so electricaly, a group of 16Bits binary state on the
> data bus of the CPU)...So why not filtering theses "custom" (???) opcodes
> with TTLs or GAL on a custom little PCBmounted on the 68K soket??? ...or a
> 2x 68K pcb with one making valid code for the other with little RAM and
> TTLs...(easy to say but it seem to be great !)...or directlly ROM patched
> with static walid code...(as i understand, it's more remake a complete game
> unlike patching
)It would take a lot of logic, you'd have to monitor all data fetched
by the 68000 and somehow guess what it's doing to the prefetch queue
to know what data is discarded (e.g. after a branch) and what data was
actually used.
That's the core of the problem, just trying to figure out which
instructions are being executed. Because the 68000 reads several words
at once, it isn't possible to know.
> - ...a section on your web site to explain in detail how the FD work will be
> very necessary. A result of your good work "black on white"
...Ok, I'll work on that, at some point.
Regards,
-- Charles
...Un personnage vraiment sympa et doué qui plus est
... It's a long way to the top if you wanna rock'n'roll ...