- Offizieller Beitrag
Ich zweifle. Der 128er nutzt eines der Bits, und wenige Programme stören sich daran.
Es gibt 651 Antworten in diesem Thema, welches 131.425 mal aufgerufen wurde. Der letzte Beitrag (
Ich zweifle. Der 128er nutzt eines der Bits, und wenige Programme stören sich daran.
Dann sagen wir so:
Wenn ich das verwirklichen wollen würde, würde ich es nach Freds "Strategiepapier" machen. Denn dann sollte es auch wirklich "authentisch" sein. ![]()
MOS6509R7 aus der CBM-II (z.B. P500) Reihe. Metall layer, Pads und Labels sind gestern fertig geworden!
Wenn nur nicht immer Diffusion wäre ![]()
Wenn nur nicht immer Diffusion wäre
Ohja....
Poly ist aber genauso ätzend.
Uder der 7502 sollte identisch mit dem 8502 sein... also der C128 Prozi,
Nein. Der 7502 ist die CPU des 'C64 PLUS mit eingebauter 80-Zeichem-Karte'. Das war natürlich in gewisser Weise der prä-alpha-Draft auf dem Weg zum C128, stand aber noch sehr viel näher am PET-II (P500)
Hat den jemals jemand gesehen?
Frag Bil Herd. Ich perslnlich glaube nicht, daß es von dem Ding viel mehr gab als den Schaltplan auf c128.com
Ich hab' mir den Plan mal angesehen - und wenn man nun annimmt, daß de "EA" Port identisch zum 6509 ist, ist es
fast genau das was ich baue:
In der MockA steckt im Grunde der 7502 und über die 4 DIPs wird entschieden, welche der Signale auf welchem Pin des DIL40
herauskommen.
Die Funktionalität für die I/O Ports und EA-Ports läuft praktisch immer mit.
Einziges Problem: EA-Port und I/O-Port sind bei den "echten" Chips immer $0/$1... da hätten wir Addresskollision.
Einziges Problem: EA-Port und I/O-Port sind bei den "echten" Chips immer $0/$1... da hätten wir Addresskollision.
Wieso ist das ein Problem?
Wieso ist das ein Problem?
Ist kein echtes Problem... ich müsste eben nur entscheiden welche Funktion an welcher Adresse steht!
Das ganze ist aber eh Fiktion:
"Niemand hat die Absicht, eine Mauer 7501-replik zu bauen!"
Ohja....
Poly ist aber genauso ätzend.
Zum Glück ist schon einiges vorhanden:
Bitte melde dich an, um diesen Anhang zu sehen.
Alles anzeigenIch hab' mir den Plan mal angesehen - und wenn man nun annimmt, daß de "EA" Port identisch zum 6509 ist, ist es
fast genau das was ich baue:
In der MockA steckt im Grunde der 7502 und über die 4 DIPs wird entschieden, welche der Signale auf welchem Pin des DIL40
herauskommen.
Die Funktionalität für die I/O Ports und EA-Ports läuft praktisch immer mit.
Einziges Problem: EA-Port und I/O-Port sind bei den "echten" Chips immer $0/$1... da hätten wir Addresskollision.
ich finde die Lösung mit $00/01 in beiden Fällen unglücklich. Man wird das aber nicht mehr ändern können. besser wäre es gewesen, ungenutzte (Crash-) Opcodes zu aktivieren um damit "Register" zu laden, die dann die 00/01 Funktion erledigen. Am Besten bei 6509/6510(+ Varianten) unterschiedliche Opcodes für Register und Banking.
Beim C128 ist es ja leider so, dass jedes Bit, das beim Schreiben nicht don't care ist, und jedes Bit, das beim Lesen nicht genau den C64 Inhalt zurück gibt, eine Inkompatibilität erzeugt hat. Wie $00,$01, $D030. Zum Glück haben die die MMU ausgeblendet im C64 Modus!
Dass das veränderte I/O Memory decoding in C128 oder 1571 Probleme gemacht hätten, wäre mir allerdings nicht bekannt.
Naja... von Kompatibilität zu sprechen bei einer CPU, die es wohl nie physisch gab, ist fragwürdig.
Aber sich weitere Gedanken darüber zu machen erst Recht: Wer soll das Ding je bauen und nutzen?
Aber sich weitere Gedanken darüber zu machen erst Recht: Wer soll das Ding je bauen und nutzen?
aber mal im Ernst: wir sind nur hier im Forum um uns diese krummen Gedanken zu machen.
Der Maßstab ist die 6502. Alles was darauf aufsetzt ist inkompatibel ... mit 6510 und 7501 hat man sich arrangiert. Aber schon 8502 machte Probleme wegen dem einen extra Bit. Genau deshalb finde ich es jetzt auch komisch den "7502" als Heilsbringer zu deklarieren. Die sogar zwei extra Bits hätten ihm auch das Genick gebrochen.
Nochmal: Erweiterungen über Crash Opcodes hätten funktioniert. Über unbenutzte Bits hat es nicht und wird es auch nicht ![]()
kinzi
![]()
aber mal im Ernst: wir sind nur hier im Forum um uns diese krummen Gedanken zu machen.
![]()
Die sogar zwei extra Bits hätten ihm auch das Genick gebrochen.
Also erst mal haben 6510/8500, x501 und 8502 diese zwei extra Bits auch. Nur nicht herausgeführt. ![]()
Außerdem schreibt ja wohl ungefähr jeder ein
LDA Bitte melde dich an, um diesen Link zu sehen.
STA 01
und nicht
LDA #B7
STA 01
usw. - also niemand setzt die oberen beiden Bits absichtlich - wozu auch?
Ferner, das SERDIR-Bit kann man mit einem Gatter abhängig vom MODE-Bit machen, wenn der C64-Mode aktiv ist hat es also dann gar keine Auswirkung. Bleibt ein Bit. ![]()
Über unbenutzte Bits hat es nicht
Logisch, weil es noch niemand gemacht hat. Was noch niemand versucht hat, kann gar nicht funktioniert haben. ![]()
und wird es auch nicht
Was erst noch zu beweisen wäre. ![]()
Aber das führt hier glaube ich zu weit.
Nochmal: Erweiterungen über Crash Opcodes hätten funktioniert. Über unbenutzte Bits hat es nicht und wird es auch nicht
Nicht bei mir... die Crash Ops sind bei mir für was anderes gedacht. (Wobei man das auch umschaltbar machen könnte! Aber in die Statemachine
einzugreifen um diese OPs vernünftig zu machen ist IMHO ein Riesengeschiss.
Das ganze auf $2/$3 unterzubringen wäre wesentlich einfacher.
Das ganze auf $2/$3 unterzubringen wäre wesentlich einfacher.
Dann kann man es gleich auf einen I/O-Bereich legen.
$02 ist so beliebt (da frei), das würde ziemlich in die Hose gehen.
Das ganze auf $2/$3 unterzubringen wäre wesentlich einfacher.
Dann kann man es gleich auf einen I/O-Bereich legen.
$02 ist so beliebt (da frei), das würde ziemlich in die Hose gehen.
Oder gleich über eine Key-Byte-Sequenz ähnlich den Flash-Bausteinen o.ä.
Dann würde es garnix blockieren
Dann würde es garnix blockieren
Ich verstehe ja immer noch nicht, was es bei Bit 6/7 in $00/$01 blockiert ... ![]()
Aber ich lass es jetzt, es ist eh nur akademischer Natur. ![]()
Aber ich lass es jetzt, es ist eh nur akademischer Natur.
Ja... in der Tat; außer jemand macht sich mal daran es zu bauen.
Ich bin zwar kein zu großer Fan von Atari (außer bei meinem Asteroids Automaten im Keller)...
man muß der Firma aber zu Gute halten, daß die regelmäßig 6502 eingesetzt haben.
Im Atari 800XL war dann sogar eine eigene Variante "Sally" verbaut. Ganz klar, daß die auch
umgesetzt werden muß! ![]()
Bitte melde dich an, um diesen Anhang zu sehen.
Danke an Jogi für den Atari 800XL und an kinzi für die Ersatz-Sally-CPU!
Nachdem ich das Board erstmal auf S-Video umgerüstet habe, kann es jetzt losgehen...
und an kinzi für die Ersatz-Sally-CPU!
geil... eine MOS CPU im Atari
(ich weiß,.. nur der Aufdruck
)
wenn das die "Atari-Freaks sehen" ![]()