Principal Engineer Amstrad (Société cotée en bourse ; secteur Produits électroniques grand public ) février 1987 — juin 1996 (9 ans 5 mois) I worked on quite a range of things - modems, fax machines, PC's, etc.
Après c'était y'a vingt ans, et le type n'était sans doute pas seule sur l'affaire.
Reste à voir si il tient à faire plaisir à la poignée de passionnés ou si il est passé à autre chose, de plus il n'a peut être pas trop le temps aussi...lol...
En gros, même si il ne se souvient plus des codes exacts, rien que de dire la démarche...les principes de fonctionnement, ça serait déjà bien.
ça permettrait de savoir quoi mesurer/tester pour avoir les bonnes infos.
En tout cas, vivement que ça aboutisse ce décryptage des cartouches.
Honnètement une cartouche 512Ko en multiEeprom, je pense que ça permettrait de unleashed la puissance de l'Asic.
Pas de manière si intense niveau CPU, mais le fait d'avoir autant de données "instanténément" en ROM, donc de switcher à volonté les banques de 16Ko...
Bref les sons, la musique, et les Sprites à volonté, sort of...
Rien que en 256ko y'a moyen déjà de faire le meilleur d'action truc jamais sortis sur un Amstrad 8bit.
Les jeux d'arcades étaient si bien grasse à ça, tout était en ROM et quasi pas de RAM... Bon, en gros c'est aussi qu'ils avaient une chiée de sprites Hards en fait, tout en HARD.
MAis sinon bin en gros les cabinet Arcade de l'époque c'était bien souvent un Z80 pour CPU principal (vidéo entre autre) et un Z80 pour le Son...
Et des résolutions pas tellement impressionnantes en fait.
Je parle des jeux comme la borne de black tiger par exemple qui était encore assez old school en fait.
En fait un Mode 0 en full screen, bin la résolution est même largement potable par rapport a ces machines d"époques...
Et si on est alors en mode "console" et jeux d'action, bin logiquement y'a pas trop besoin de mettre du lecteur de disc et autres truc comme ça qui peuvent pomper de la ressource. Même le clavier on peut s'en passer.
Je pense que c'est pour ça que la GX4000 n'avait que 64Ko en fait. Ils pensaient que comme les jeux étaient prévus en Cartouche donc full ROM, bin pas besoin d'avoir une bank de 64Ko en plus, puisque c'est déjà tout en ROM. Mais le problème c'est que comme les cartouches ne faisaient que 128Ko, bin ils furent limités, donc ont dù par exemple compresser les données parfois...
Et rien que ça bin ça foire tout, déjà que le Plus/4000 n'a pas un système de sprites particulièrement rapide/pratique...
Pour les jeux de reflexions sans crollings (Pang, Plotting) c'est pas un problème, mais dès que tu veux un jeux avec de gros levels genre Barbarian2...ou batman, bin là tout de suite c'est plus pareil.
Je pense donc qu'avec des Cartouches en 256 et 512 on arriverai a faire de bons Shm'ups et run and gun, platformers et autres...
D'ailleurs, quelle différence notable entre de la Ram et de la Rom dans le cadre d'un jeux ?
Vu que le Z80 n'a que 64Ko dont 16-24Ko bouffés par la vidéo (24 pour le full screen...donc max).
Esque c'est plus rapide de bank switcher depuis de la Rom ou de la Ram ? ou pareil ?
L'idée c'est que la Ram permet de mettre de la donnée "vivante"...Sans doute utile si y'a de la "matière qui bouge". donc pour du jeux de rôle, wargame et autre truc gourmant en calcules et modifs de stats...peut être pour de la 3d aussi alors...
Mais de l'action Pure à base de tuiles et sprites, bin logiquement avoir tout ça en Rom revient au même non ? Surtout si avec un cartouche grande on est plus obliger de compresser le tout...me semble t'il.
Autre truc : la plupart des consoles peuvent ajouter des chips et co-processeur dans les cartouches.
Le Plus peut il le faire aussi ? en gros, esque le port cartouche est plus ou moins un port extension ou juste de la bank mémoire seulement ,
Enfin peut on alors théoriquement ajouter de la Ram avec le port cartouche aussi ?
Genre une cartouche dite multi Eprom (eprom amovible) avec en outre de la Ram...c'est faisible ?
S'il peut donner des info sur l'ACID pourquoi pas ... mais ce qui m'interesse surtout c'est de savoir s'il a des infos sur l'ASIC !
McDeath26, en ce qui concerne les roms 512ko, le port cartouche propose déjà des broches d'adresses sur 19 bits = 512ko adressables. Je n'ai pas testé, mais je ne serais pas étonné que si une cartouche existait avec 4 roms de 128ko reliées de façon adéquate aux broches d'adresses, l'ACID existant serait suffisant. (En résumé je pense que l'ACID est universel même pour les cartouches de >512ko mais ce n'est qu'une supposition )
Pour tes questions RAM/ROMS: - pour le bank switching ram ou rom la différence de vitesse n'est pas significative à mon sens - Il est toujours plus pratique d'avoir du code en RAM (on peut l'auto-modifier) mais on peut s'en passer
Le port cartouche permet de lire des valeurs dans une rom à des adresses que l'on passe en paramètre, on peut (théoriquement) corrompre son fonctionnement comme on veut du moment que l'interface avec le cpc+ est respectée (les signaux in/out). Ainsi, si ça te chante, tu peux ajouter un peu d' électronique sur une cartouche pour switcher une led on/off lorsque tu lis à une adresse donnée. (exemple stupide mais ce pourrait être un processeur embarqué, un PIC, ou autre ...)
A tes questions est-il possible d'utiliser une cartouche comme ram (est-il possible d'y écrire) je répondrais oui, puisque (je me répète) c'est précisément ce qu'à fait RAM7 avec son interface pour ripper les cartouches, cela dit, je ne connais pas les détails de cette interface et j'aimerais bien savoir comment elle fonctionne (surtout la partie écriture) quelqu'un aurait-il le schéma/plan de cette interface ?
Inscription : 15 Août 2008, 13:00 Message(s) : 968 Localisation : Troyes, France
Attention au bad trip...
A voir mais j'avais l'impression que l'interface de RAM7 se branchait sur le port extension.
Pour l'écriture sur une cartouche , je n'ai pas vu de signaux /WR /RD sur le connecteur, n'est ce pas nécéssaire pour pouvoir écrire sur une RAM ? J'avais pensé justement aussi à l'histoire du PIC voire à une RAM avec une pile au lithium (merci RAM7!) pour les sauvegardes comme les cartouches SNES.
Pour les 512K, je pense que c'est juste l'histoire des LK qui semblent jouer sur les 3 bits hauts de l'adresse.
Sinon avoir de la ROM en cartouche serait très avantageux pour un jeu sur + car en connectant la ROM en #C000 il est possible d'alimenter directement l'ASIC en #4000, notamment via des sprites compilés, nettement plus rapides (temps de transfert jusqu'à 5 fois plus rapide) mais gourmands en mémoire ce qui n'est malheureusement possible qu'avec une bank sur 4 avec le switching des RAM.
_________________ "NOP" tel est le programme parfait ! court, rapide, lisible et sans bugs (connus)
Le truc de Ram7 se branche sur le port extension, voir : http://cpcwiki.eu/index.php/RAM7_Cartridge_Hacker Du coup je me demande comment elle fait pour récupérer les signaux qui viennent de l'asic qui concernent l'adressage physique des roms ??
Oui, il manque des signaux pour écrire sur le port cartouche comme une ram, je voulais dire qu'on peut arriver à écrire dessus même sans (enfin je pense, mais je ne suis pas spécialiste)
On peut imaginer de sacrifier des bits des signaux d'adressage -> 1 switch sur la cartouche : write mode on,off -> 19 bits d'adressage ca peut permettre d'envoyer 8 bits sur une adresse de 11 bits, je sais c'est encore un exemple stupide bob ok, je sors
Inscription : 15 Août 2008, 13:00 Message(s) : 968 Localisation : Troyes, France
fkey a écrit :
On peut imaginer de sacrifier des bits des signaux d'adressage -> 1 switch sur la cartouche : write mode on,off
Lol je pensais à la même chose , par exemple sacrifier le bit 19 pour s'en servir avec une bascule pour les signaux /RD et /WR ce qui ferait les RAM/ROM de 0 à 15 en lecture et de 16 à 31 en écriture.Ou encore mieux , le bit 0 donc toutes les adresses paires en lecture et les impaires en écriture lol Certes on limite à 256K mais ça n'empêche pas de partager 128k RAM de travail avec un copro/microcontroleur qui derrière lui adresse tout seul une ROM beaucoup plus grosse et qui rapatrie à la demande dans la RAM de travail, voire prémache les données...
Voilà, c'était mes deux minutes de rêve tout éveillé.Faudra quand même qu'un de ces jours je me mette à l'électronique numérique (et à l'électronique tout court !)
_________________ "NOP" tel est le programme parfait ! court, rapide, lisible et sans bugs (connus)
a partir du moment ou tu peux connecter une ROM/RAM, tu peux écrire dedans... C'est comme une connection de bank !!! Vous n'avez jamais programmé une ramcard ?
si BDCIron, Mais le port cartouche est moins riche en signaux que le port extension et ne présente pas (comme l'a dit fano) des signaux nécessaire pour la synchro de l'écriture en RAM. C'est d'ailleurs certainement pour ça que le truc de RAM7 se branche sur le port extension, je suppose qu'il a modifié un peu la ramcard pour répondre aux signaux ROM et simuler la cartouche.
Hi! Got the cartridge from fano (thanks!) and started to work on it saturday. First day I've wasted on unimportant stuff, desoldering the chip, verifying the pin-outs, nothing really required, but it's a nice way to get familar with the hardware
The cartridge pin-outs are the same as the known A1-A18 and B1-B18 pin-numbers. Though counted differently (odd pins: CartPpin1..35 = CpcPinB18..B1, and even ones: CartPin2..36 = CpcPinA18..A1.
The six LKs are for A15,A17,A18 (address lines, of course, not the "A1-A18" pins). VCC ---LK1--- EPROM.A18---LK2---CPC.A18 VCC ---LK3--- EPROM.A17---LK4---CPC.A17 VCC ---LK5--- EPROM.A15---LK6---CPC.A15 My cartridge PCB doesn't have any LKs installed, instead, the etched circuit has hardwired connections between some of them. One could scratch them off, and then use the LK soldering points to reconfigure the board for eproms of other size.
----
Okay, now to the ACID. The pin-outs listed on cpcwiki are correct, not much new new there. The two GND pins are really both GND (they are interconnected with each other inside of the chip). The NC pin seems to be always high.
For testing I've simply wired the chip to the parallel printer port on my PC. A0-A7=Data0-7, OE=SELECT, CLK=STB, CCLR=INIT, SIN=BUSY. Of course, the PC's I/O waitstates are making the transfer a bit slower than on the CPC, instead of 4MHz, I can't get CLK faster than 200kHz or so. Been a bit worried that it could cause problems (in case there'd by any stuff like dynamic refresh going on). Fortunately, it works 100% stable, I can even run a mp3 player in background.
SIN outputs the serial data stream to the CPC. CCLR is an input, setting it to LOW does reset the chip, which is (on a CPC) probably done only once at power-up to sync ACID and ASIC, or in case of errors (which would explain why people reported it to toggle on/off when cartridge is connected).
Aside from synchronizing, CCLR is (sometimes) also needed to get the ACID to output anything at all. I had a funny situation where SIN did output data all fine, then switched off the computer for a while - and when I wanted to continue SIN didn't output anything but zeros took me quite a while to figure out why it didn't work anymore (needed to drag CCLR=LOW for a moment, then it started to send data).
----
Now to the data stream - after reset via CCLR, it outputs 16 high levels on SIN (one per CLK), and then starts to output "random" bits. So it's quite obvious even at first glance that the ACID is some simple shift-xor stuff, ie. as used in noise generators in sound chips.
Only problem is that one sees only one bit at a time (not the whole value in the shift register). Which made it a bit difficult to find out how it works: The shift register is 17bits wide, one bit is output on SIN, four bits are XORed with each other, shift occurs once per CLK cycle, and the XORed bits are shifted in at the top (or bottom, whatever you turn it around).
My test proggy can calculate the data stream by software, and it matches up perfectly with the data coming from the ACID chip. So that part is solved.
----
The other part - that I've more or less ignored for now - is the 9bit data bus, fed by the A0-A7 and /OE signals. The interesting part here is that the hardware is more or less ignoring it, too.
After CCLR=LOW, the first some thousands bits on SIN are usually always the same, no matter what is injected on the 9bit data bus. In many cases its even the complete data stream (not just only the first thousands bits) unaffected by the data.
Checking what is going on there will be my next step. My current bet is that the hardware does something like "IF ValueOnDataBus = ValueInShiftRegister THEN toggle some bits" which would explain why it reacts to incoming data only once every some thound cycles. If it that simple, then I am about half done with reverse engineering
Cu, Martin
Citer :
> Could you confirm that the feedback fonction is : > feedback=b0 XOR b4 XOR b7 XOR b16 > with b16 being the SIN value and feedback being > the bit shifted in the register (in b0). Please?
I am shifting right (other way around), so, in that way, your values would be: newbit16 = oldbit16 xor oldbit12 xor oldbit9 xor oldbit0 yup, that are the same bits as the ones I am using. I am using oldbit1 (aka newbit0) for SIN, though that just matters on whether you do the calculation before or after the CLK pulse.
How did you find the bits? Did you connect the ACID chip to a PC, too? Thought I'd have been the first one having that idea, then on the other hand it's so obvious to do it, that other people probably had the idea too
About the data inputs, /OE is simple. If it's high, then the data stream advances in normal way. If it's low, then the A0-A7 are somehow compared with the shiftregister, and if the values do match, then some bits are modified.
How the comparision & modification works exactly is still unclear to me. I can reproduce the effect for a dozen of values, and hoped I could calculated the remaining values from them. Ie. hoped that, if I know the effects on address=01h and on address=08h, for example, then address 09h should have the two ones XORed together - but that theory didn't worked, or I did something wrong
Citer :
Got it! Fixed some mistakes in my proggy, found out that one of the 17 bits is ignored in the comparisions. And now the compare/adjust stuff is working fine
That should be all about the ACID chip. I think everything is reverse engineered now, there should be no further secrets.
Let's see, 13th-16th February, 4 days altogether. Hmmmm, I claimed I could do it in 2 days, damn but it's been a funny action-research time. Didn't do that kind of stuff for a while. Maybe I should go on with the NES, it has a similar chip - does somebody know if it's still unknown how the lockout chip in NES works?
Utilisateur(s) parcourant ce forum : Aucun utilisateur inscrit et 100 invité(s)
Vous ne pouvez pas publier de nouveaux sujets dans ce forum Vous ne pouvez pas répondre aux sujets dans ce forum Vous ne pouvez pas éditer vos messages dans ce forum Vous ne pouvez pas supprimer vos messages dans ce forum Vous ne pouvez pas insérer de pièces jointes dans ce forum