News:

Printed Amstrad Addict magazine announced, check it out here!

Main Menu
avatar_robcfg

Gate array decapped!

Started by robcfg, 16:54, 12 April 16

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

robcfg


Hi guys!


I uploaded the 40010, PreASIC and ASIC 20x pictures to Mega.


The 40010 pictures are jpg and the 40226 and 40489 are in deep zoom format as they are otherwise unmanageable.


I included the OpenSeaDragon deep zoom viewer and created convenient html files. For viewing them from your disk, I recommend FireFox as Chrome is too picky with the data origin.


40010 Metal Layer: https://mega.nz/#!hkEwxLjA!ACfSH1p6Cp7QkbkdcA3NmPPB_bIdtaSz2TQdBmCt5ss
40010 Metal Layer Removed: https://mega.nz/#!E0ljlKoK!nErCPUcuzMt8smAj_NWjx8wJmrIyL67qqdxx5Dz1eBQ
40226 and 40489 Deep Zoom Images: https://mega.nz/#!o0dE1ATL!5eHANmjOS-aTHR2tiN0hLZw0AGeLvInTIcca-IooZJQ


@Gryzor : I sent you an email a while ago, but seems to have been lost in the tides of time. Would it be possible to upload the Deep Zoom Images and the viewer to the wiki?If it's possible, I'd like to put proper credits first to the html files but you can try with the files I uploaded.

Quote from: dragon on 19:26, 14 July 16
Just for curiosity any news obtaining the 40010 schematic or the other ics?


@gerald was working on it. No easy task, so please be patient  ;)

Gryzor

Hey mate,


I don't seem to have that email, this is the first time I hear about Deep Zoom :D But... are we talking about the 1.4GB file? I think it's a bit too much, though if enough people are interested I'll upload it to the server; not through the wiki though.

gerald

Quote from: robcfg on 11:04, 13 September 16
@gerald was working on it. No easy task, so please be patient  ;)
Most of the job is done. I just need to check it against real HW.
Preliminary schematic attached.
I have VHDL code ongoing, but in standby for the last 2 weeks.

Duke

Impressive work @gerald . And thanks @robcfg for the images.

Arnaud

Quote from: gerald on 16:54, 13 September 16
Most of the job is done. I just need to check it against real HW.
Preliminary schematic attached.
I have VHDL code ongoing, but in standby for the last 2 weeks.

You can directly translate the electronic shematic in VHDL ?
It's rather different from FPGAmstrad which is an adaptation of java emulation with Javacpc or it's finally the same "code" ?


gerald

Quote from: Arnaud on 17:53, 13 September 16
You can directly translate the electronic shematic in VHDL ?
Reverse engineering have been done with degate. While it is supposed to generate a vhdl model of the 'extracted' design, it is rather buggy and did not let me add proper hierarchy to the design, which makes it unreadable. It has also some other bugs that make me use the old paper and pencil method.
With the paper schematics, I did the pdf one in Kicad, simplifying most of the equation to make them more human readable. The original design is optimised by using polarity optimisation wherever it's possible. This help reducing the number of transistors but make comprehension difficult.

Quote from: Arnaud on 17:53, 13 September 16
It's rather different from FPGAmstrad which is an adaptation of java emulation with Javacpc or it's finally the same "code" ?
Chances are quite low that the code is the same  ;)
The 40010 uses a lot of asynchonous tricks and these may have been implemented as synchronous logic.

dragon

Quote from: gerald on 18:12, 13 September 16
Reverse engineering have been done with degate. While it is supposed to generate a vhdl model of the 'extracted' design, it is rather buggy and did not let me add proper hierarchy to the design, which makes it unreadable. It has also some other bugs that make me use the old paper and pencil method.
With the paper schematics, I did the pdf one in Kicad, simplifying most of the equation to make them more human readable. The original design is optimised by using polarity optimisation wherever it's possible. This help reducing the number of transistors but make comprehension difficult.
Chances are quite low that the code is the same  ;)
The 40010 uses a lot of asynchonous tricks and these may have been implemented as synchronous logic.

You are a genius hardware guy gerald. Gate array was designed with paper and pencil method, and was reverse enginered with pencil and paper method. :).

Do you have thinking about made a gate array plus?. Compatible but with posibility of more colours in all modes.

TotO

#132
I personally expect to be able to restore the Gate Array's 64 colours original palette.
About displaying more colours per pixel, it is related to the CRTC frequency...
"You make one mistake in your life and the internet will never let you live it down" (Keith Goodyer)

PulkoMandy


"Restoring" the 64 colors is a matter of copy-paste (mostly in "ink registers" and "color mux" parts of the schematics, the 6th bit was removed there to save space I guess) and then finding a way to output them (we'll need 3 extra pins).More colors in all modes would be possible but tricky. There are two solutions inspired by the Thomson hardware. The first is to use 16-bit memoryt accesses, for example, 8 bit from main memory, and 8 bits from banked memory. This would not need this many changes to the Gate Array, but a major rework of the motherboard (and again, probably a chip with some extra pins). The other option is to use RAM which can perform multiple accesses in the same page very fast, as it was done in the Thomson TO8. And of course there's always the option of running everything at 8MHz to avoid all these changes.

TotO

Quote from: PulkoMandy on 08:05, 14 September 16
"Restoring" the 64 colors is a matter of copy-paste (mostly in "ink registers" and "color mux" parts of the schematics, the 6th bit was removed there to save space I guess) and then finding a way to output them (we'll need 3 extra pins).
I have looked the schematics done by gerald yesterday evening. Yes, that will require this sort or work to be acheived. About the 3 extra pins, it is not really a problem as you can implement the 6-bit RGB DAC using resistors into the Gate Array's PCB replacement. So, the pins going to the socket doesn't change.

"You make one mistake in your life and the internet will never let you live it down" (Keith Goodyer)

dragon

#135
So,probably in the Plus range they make copy paste to 12bits. :).

If more colours to Mode 0 1 and 2 is posible the best is the  method take less modificación in the motherboard.

robcfg

More colors means more memory and more time needed to draw a frame.


For an adventure game it may not be a problem, but for any action game it's not going to work good.


Another thing would be to oveclock the machine...

TotO

You may display more coulours w/o wasting the display or the memory by using attributes.
"You make one mistake in your life and the internet will never let you live it down" (Keith Goodyer)

Gryzor

Quote from: TotO on 21:21, 13 September 16
I personally expect to be able to restore the Gate Array's 64 colours original palette.


Wait - what?   

pelrun

WOW. This is a truly amazing piece of work, and probably the most exciting bit of base-CPC hardware documentation news in years.

robcfg

Quote from: TotO on 09:53, 14 September 16
You may display more coulours w/o wasting the display or the memory by using attributes.


You mean like the Spectrum?  ;D

TotO

#141
I just said that is a way to do...  ;D


Quote from: Gryzor on 09:57, 14 September 16Wait - what?

The INKR allow to set 6bit for the palette but only 5bit are used. By extending that, you come with a 64 colours RGB palette.
"You make one mistake in your life and the internet will never let you live it down" (Keith Goodyer)

Ast

Quote from: TotO on 10:07, 14 September 16
I just said that is a way to do...  ;D



The INKR allow to set 6bit for the palette but only 5bit are used. By extending that, you come with a 64 colours RGB palette.

Would it be able to to that workable ?
_____________________

Ast/iMP4CT. "By the power of Grayskull, i've the power"

http://amstradplus.forumforever.com/index.php
http://impdos.wikidot.com/
http://impdraw.wikidot.com/

All friends are welcome !

TotO

I hope... The Aleste 520 and KC Compact does that if I'm not wrong.  ;D
"You make one mistake in your life and the internet will never let you live it down" (Keith Goodyer)

robcfg

I was wrong on the memory requirement, as it's no new graphic mode, you have only more colours to choose from.

dragon

#145
I don't remember now if this is finally solved early sorry.

Whith the schematic finished finally what is the cause of this in 40010/b?.


andycadley

Quote from: TotO on 10:07, 14 September 16
I just said that is a way to do...  ;D



The INKR allow to set 6bit for the palette but only 5bit are used. By extending that, you come with a 64 colours RGB palette.


It's actually something of a misnomer. The CPC was originally designed with 16 colours (using 4 bits) but later in the design it was spotted that a little hardware hackery and two extra bits to help control colour intensity could bump that up to 27 colours for very little additional cost. From a purely "digital" standpoint, it seems weird because 6-bit colour settings should give you as much as 64 colours but from a more analogue perspective the design makes sense. It's also why the "hardware colours" seem to contain a lot of duplicates.

Now you theoretically could build new hardware to "fill in the blanks" (i.e. replace some of those duplicate colours with something else) and produce a palette of 64 colours instead of 27, but the chances are fairly high that you'll get weirdness in some software which is using a different (but perfectly workable) hardware colour to get the same output as it'll suddenly start using some random other colour.

A better way of extending the palette is to forego the 6 bit colour selection method entirely, using it only as a shorthand way of changing real RGB colour registers. Which, unsurprisingly enough, is how Amstrad chose to do it on the Plus machines. The only real downside being that if you use more than 8 bit RGB values (such as the Plus 12 bit registers) you run into the problem that a Z80 can't make atomic colour changes.

TotO

#147
With only 1R, 1G, 1B, a "suposed" design without hi-Z can only produre 8 coulours (CGA). I have never read about a 16 coulours palette CPC based.
The INKR register is fully used on Alest 520 and KC Compact to handle a nice 64 coulours palette (EGA) w/o compatibility problem... Why ?
Because the hardware palette is not the software palette. The colours are remapped to match with the existing. (and I will use it)

If more coulours are required, yes you can do many things to improve that (as Pulko said)... Here is just an existing way to do.  :)
But... When you can't display more than 2/4/16 at once, a big palette is not really an advantage.
"You make one mistake in your life and the internet will never let you live it down" (Keith Goodyer)

arnoldemu

Quote from: TotO on 12:02, 14 September 16
...
The INKR register is fully used on Alest 520 and KC Compact to handle a nice 64 coulours palette (EGA) w/o compatibility problem... Why ?
Because the hardware palette is not the software palette. The colours are remapped to match with the existing. (and I will use it)
...
On KC Compact it has the potential for 64 colours. However, the EPROM (D09) translates it to 27 colours.
Replacing the EPROM should in theory (not tested) allow 64 colours to be used.

The Aleste can do 64 colours. it has a "msx mode" and a "cpc mode" which boils down to "MAPMOD" being 1 or 0.
Again an EPROM is used (D62) which gives differing values depending on mapmod and so enables 27 or 64 colour mode. The ROM could be modified to output 64 colours in CPC mode too.

My games. My Games
My website with coding examples: Unofficial Amstrad WWW Resource

TotO

Sure, the EPROM act as a look-up table to set the good software palette.
But... What about directly using the KC Compact hardware palette ? Can you access the 64 colours?
"You make one mistake in your life and the internet will never let you live it down" (Keith Goodyer)

Powered by SMFPacks Menu Editor Mod