Posts by HofMar

    Diddl hat im ersten Post meinen Artikel zittiert. Leider hat er wichtige Teile ausgelassen. In diesen wird erklärt wie die Adressdekodierung funktioniert. Das auch am Beispiel der RROITs für die CBM-Floppies. Dort wird CS1 nicht verwendet. Und CS2 ist eigentlich nur eine Negation von RS0. Das wäre prinzipiell nicht nötig und könnte anders gelöst werden.


    Wie Diddl auch schon anmerkte, kann mit dem RRIOT und einer CPU ein vollständiges System aufgebaut werden. Wozu dann ein "Chip Select"? Der RRIOT ist immer selektiert, er liefert den Programmcode aus dem ROM, führt den Zugriff auf das RAM durch und liefert auch die IO-Zugriffe. Es wird also vielfach nur eine reine Adressierung (ROM, RAM, IO) benötigt. Intern werden dann aus den optionalen Adressleitungen, CS1, CS2 oder RS0 die Selektierung von ROM, RAM und IO gemacht. Genau das sind die programmierbaren Fuses im RRIOT.

    In der ersten Revision des CBM-BASIC war ein Fehler, der RND(0) betrifft. Hier wurde eine VIA an Adresse $904x und nicht $E84x erwartet! Das erklärt den konstanten Wert, da hier immer das Highbyte der Adresse (also $90) gelesen wird.


    Im Microsoft-Quelltext wird das als Konstante CQHTIM mit dem oktalem Wert ^O164104 (entspricht $E844) aufgeführt. Es war bei dem zweiten Abgleich (zur zweiten Revision) bereits korrigiert worden.


    Commodore führt das mit der Konstanten CHTIM korrigiert fort. Weiteres unter:

    Warum diese falsche Adresse hier Einzug erhalten hat, ist mir leider nicht bekannt, zumal dieser Aufruf der Zufallsfunktion mit dem Argument 0 nur in der Commodore Edition des MS-BASIC enthalten war.


    MInd. ein Board erlaubte das Umschalten des IO-Bereichs von $E zu $9. Ob es damit zusammenhängt?

    You called the monitor via break (see the b* in the first line). The program counter (pc) is $0073. This is at the CHRGET routine. This as called to read the BASIC text or a direct line from the input buffer. This routine is a copy from $E0F9. But it seems you have bad RAM at the zero page. So the copy of CHRGET is lost and with the data byte $00 at $0073 the monitor is called.


    Have a look at you DRAM!

    Wenn er läuft und man nicht lädt, bleibt er sehr stabil an.

    Das könnte auch auf ein thermisches Problem hindeuten. Was ich auch schon mal hatte, waren Probleme bei den Durchkontaktierungen. Die sehen zwar auf dem Foto gut aus, aber ich kenne die Unterscheite nur zum Teil. Das könnte auch die Probleme beim Laden (höhere Stromaufnahme durch den Motor) erklären.

    Hier mal die Jumperbelegung von Bestückungsplan etwas übersichtlicher:

    Code
    --- SH1 ---  ------- SH2 -------
    A B C D E F  H I J K L M N P R S
    
    - - X X - X  X X X X - - - X - X  32K used with item 4116
    - - X X - X  - X X X - X - X - X  16K used with item 4116
    - X - X X -  - X X X - X - X - X  16K sub used with item 4108-30
    X - - X X -  - X X X - X - X - X  16K sub used with item 4108-31
    - X - X X -  - - X X X X - X - X   8K used with item 4108-30
    X - - X X -  - - X X X X - X - X   8K sub used with item 4108-31

    Es gibt als die Möglichkeit neben der 8 K Byte (4108-30 oder 4108-31) und 32 K Byte (4116) Bestückung auch bei der 16 K Byte auf einen Satz 4116 oder zwei Sätze 4108 zurückzugreifen. Schon sehr universell ausgelegt.


    Deine Belegung nach #32:

    Code
    --- SH1 ---  ------- SH2 -------
    A B C D E F  H I J K L M N P R S
    
    - - X - - X  X X X - - - - X - X  32K used with item 33

    Wie Du schon schreibst sind die Unterschiede nur bei den fehlenden Jumpern D und K. Schaut man sich die Jumper auf den Schaltplänen an, findet man die Ausschlüsse. Also hier mal die Jumper, die niemals zeitgleich gebrückt sein sollten:

    Code
    --- SH1 ---  ------- SH2 -------
    A B C - - -  - - - - - - - - - -  RAM type (8K-1 / 16K / 8K0) see sheet 5
    - - - D - -  - - - - - - - - - -  ???
    - - - - E F  - - - - - - - - - -  row selectd (8K / 16K) see sheet 6
    - - - - - -  H - - - - M - - - -  see sheet 5
    - - - - - -  - I - - L - - - - -  see sheet 5
    - - - - - -  - - J - - - - - - -  see sheet 5
    - - - - - -  - - - K - - - - - -  ???
    - - - - - -  - - - - - - N P - -  ROM's 9, A, B (OUT / IN) see sheet 1
    - - - - - -  - - - - - - - - R S  IO address (88xx / E8xx) see sheet 1

    Auffallend ist, die Jumper D und K finde ich nirgends. Mit Deiner Erkenntnis stelle ich mir die Frage, ob dieser überhaupt Kontakt haben? Dieser Frage würde ich als erstes nachgehen.

    Schaue ich mir die ASSY 320351 an, gibt es dort verschiedene Versionen. darunter die 320351-05, 320351-06, 320351-11 und 320351-12 als 8 KB Version. Auf der Seite 5 findet man dann die Lösung:

    • 901470-02: IC 8K DYNAMIC RAM 4108-30 MOSTEK
    • 901470-03: IC 8K DYNAMIC RAM 4108-31 MOSTEK

    Warum zwei Varianten? Und warum 8 K DRAM? Wie Christian schon schrieb war DRAM damals sehr wertvoll, so wertvoll, daß man sogar defekte Bausteine versuchte weiter zu verwenden. War ein 16 K DRAM defekt, hatte man gute Chancen, daß dies nur eine "Hälfte" betraf. Also wurden diese Bausteine nun als 8 K DRAM verkauft. Je nach nutzbarer Hälfte als 4108-30 oder 4108-31. Und auf Seite 5 des Schaltplan findet man oben links auch die passenden Brücken für die 8 K DRAM Bestückung. Drei Positionen für:

    • 8 KB mit nutzbarer erster Hälfte,
    • 8 KB mit nutzbarer zweiter Hälfte und
    • 16 KB.

    Zum "Aufrüsten" waren also nur die DRAM-Chips zu tauschen und die Brücken zu ändern. Das scheint bei Dir auch gemacht worden zu sein.

    Quote

    Also müßte man den Pin 21 (A12) des 2364 auch neben der Fassung offen lassen können.

    Helmut hatte es natürlich aus der "praktischen Sicht" super beschrieben. Ich vergaß dabei, daß Du schon einen Adapter-Sockel hast. Da macht es dann auf jeden Fall Sinn, mit weiteren (Low-Cost) IC-Fassungen "Türmchen" zu bauen um diesen Pin 21 "aufzutrennen" (und auf Isolation achten) um diesen dann gesondert zu beschalten.

    Nun ein 8 KB-ROM kann man unter Umständen auch zur Hälfte über einen Steckplatz der für 4KB-ROMs vorgesehen ist auslesen. Wie der Zufall so will unterscheiden sich 2332 (4K) und 2364 (8K) nur durch Pin 21. Beim 2332 ist das ein weiteres (bei Commodore high-aktives) Chip-Select und beim 2364 eine weitere Adressleitung A12. Solange man auf das Chip-Select verzichten könnte, würde man (durch das high-aktive) den oberen 4 KB-Teil auslesen können, wenn man das ROM direkt in den Sockel steckt.

    Aber ACHTUNG, die Chip-Select-Leitung des Boards führt nun zu A12 des ROMs. D.h. das 2364 liefert u. U. auch Daten (den unteren 4 KB-Teil), wenn das 2332 deselektiert wäre. Das kann zu Kurzschlüssen führen!

    Nun wäre es wichtig zu wissen, welche Board Du verwendest. Schaue ich mir die ROMS von 8032029 an, wird hier nur das /NOROM-Signal als weiteres Chip-Select (Pin 21) verwendet. Dieses kommt von einem nicht beschalteten Pin der 6502. Erst mit einer Erweiterung sollte das Signal eine Rolle spielen.

    Also müßte man den Pin 21 (A12) des 2364 auch neben der Fassung offen lassen können. Dieser offene Pin ist dann mit GND auf log. 0 zu legen, damit der untere Teil ausgelesen wird oder auf VCC (+5 V) auf log. 1 zu legen um den oberen Teil auszulesen. Also eine kleine Art des Bank-Switching. Man könnte auch ein Bit des User-Ports nutzen.

    Die Anpassung der Bildwiederholrate an die Netzfrequenz ist definitiv kein "Unfug". Das haben alle Hersteller gemacht. Auch die TV-Normen passen sich dem an. Neben der EMV (Elektomagnetischen Verträglichkeit) spielt auch die Raumbeleuchtung eine große Rolle. Immerhin "flackert" das Bild (entsprechend der Nachleuchtkraft der Bildröhre) mit der Bildwiederholrate. Solange die Raumbeleuchtung nun mit der gleichen Frequenz "flackert", entsteht nur eine Schwebung, die man kaum wahrnimmt.

    Die PET ohne CRTC erzeugen die Videosigale (damit auch die Bildwiederholrate) fest auf 60 Hz.

    Beim CRTC kann dieser neben der Vorgabe des Editor-ROM (siehe auch hier oder hier) jederzeit umprogrammiert werden. Jedoch werden bei 60 Hz weniger Rastterzeilen pro Bild dargestelt. Damit kann es sein, daß die Bildgeometrie des Monitors angepaßt (eingestellt) werden muß.

    Das Editor-ROM unterscheidet sich neben den angepaßten Werte für den CRTC auch in der Interrupt-Routine. Diese ist immer für 60 Hz ausgelegt. Bei 50 Hz wird bei jeder fünften Auslösung die Routine doppelt ausgeführt. Die Jiffy springen dann um zwei.

    Es scheint so, daß es dort noch Modelle mit einem bestücktem Centronics-Ausgang gibt. Das würde den unbestückten Teil neben dem IEEE-488 Eingang erklären. Die passenden Portzugriffe scheinen im vorhandene Programm-Code nicht vorhanden. Also muß es weitere EPROM-Versionen geben.

    Bitte auch beachten, daß ein Trafo mit der Zeilenfrequenz schwingen kann. Hier wären es je nach Bildröhre (und Editor-ROM) 20 oder 17 kHz. Das kann auch die mechanische Belastung des Zeilentrafos auf die Platine verstärken. Die Idee mit dem Silikon als Kleber für den Zeilentrafo erscheint mir logisch.

    Ich hab diverse verschiedene MC6845 getestet - und keiner lief im 8032 oder 8296.

    Dann bliebt die spannende Frage nach dem "warum".

    Hier hatte ich mal die verschiedenen Register abhängig vom Editor-ROM ausgeführt. Mir fällt dabei nichts weiter auf. Oder ist es nur ein Timing-Problem? Nur meines Wissens wird der CRTC nur einmal zum Start initialisiert. Später gibt es normal keine weitere Zugriffe. Der Cursor wird nicht über den 6545 erzeugt, sondern über Software in der Interrupt-Routine.

    André zeigt hier gut die Unterschiede zwischen den verschiedenen Typen/Herstellern auf. Spannend ist dabei, daß der (oben nicht funktionierende) Motorola 6845 mit dem (von Commodore genutzen) Hitachi 46505 gleichgesetzt wird. Ich bin auch etwas verwundert, daß der nicht funktionierte und vermute hier eher einen anderen Fehler.

    HIer eine Variante für die Gleichungen des 82S123:

    Code
      D7 = Not(Not(A3) And A1)
      D6 = 0
      D5 = A1 And Not(A0 Or A3 And A2)
      D4 = A1 And (Not(A3) And A2 And Not(A0) Or        Not(A2) And A0)
      D3 = A1 And (Not(A3) And A2 And     A0  Or A3 And Not(A2)       )
      D2 = Not(Not(A4) And A1 And (A3 Or A2 Or A0) And Not(A3 And (A2 Or A0)))
      D1 =     A3 And Not(A2) And A1 And Not(A0)
      D0 = Not(A3 And Not(A2) And A1 And     A0 )

    Nun müßten wir noch A0 (Pin 10), A1 (Pin 11), A2 (Pin 12), A3 (Pin 13), A4 (Pin 14), D0 (Pin 1), D1 (Pin 2), D2 (Pin 3), D3 (Pin 4), D4 (Pin 5), D5 (Pin 6), D6 (Pin 7) und D7 (Pin 9) mit Namen füllen. Wie ich sehe kommen die Adressen alle vom 374 (A0 von Pin 9, A1 von Pin 15, A2 von Pin 6, A3 von Pin 5 und A4 von Pin 16). Jedoch sehe ich auch, daß einige Daten zum 374 gehen. Das wären mind. Pin 3 (D2) zu Pin 18 des 374 und Pin 6 (D5) zu Pin 8 des 374 kommt. Also gibt es mind. eine Rückkoppelung zwischen D5 und A0.

    Das VSYNC Signal kommt aus PIN40 des 6545 und geht danach über 7486(UC2) an den Ausgangspin des Monitorsteckers. ABER es geht auch noch irgendwo anders hin, dahinter steht eine 3. Heißt das, man muss auf Blatt drei kucken?

    Völlig korrekt. Das vertikale Synchronisationssignal kommt aus dem 6545. Leider ist der bei Dir nicht gesockelt, sonst könnte man den mal tauschen. Mit dem folgendem 74LS86 kann die Polarität gewechselt werden. Der Abgang zum Blatt 3 führt dann auf die Eingänge für den Interrupt. Das müßten CB1 der PIA1 und PB5 der VIA sein.

    Da keine Eingaben über die Tastatur möglich sind, könnt es sein, daß dieses Signal eben fehlt oder gestört ist. Folgende Fehlerquellen sind denkbar:

    • 6545 liefert kein VSYNC mehr (tauschen),
    • 74LS86 ist defekt (tauschen oder Signal zu Testzwecken direkt am 6545 abgreifen und über einen Buffer oder Inverter führen) oder
    • einer der Eingänge für den Interrupt zieht das Signal gegen Masse oder VCC (Pin 18 an PIA1 und Pin15 der VIA mal "abkemmen").

    Es bleibt natürlich die Frage des Grundes. Evtl. wurde vom Monitor etwas zurückgespeist. Das könnte PIA1, VIA und 74LS86 beschädigen.

    Viele Prommer unterstützen nur den 2732. Dann muss man sich einen Adapter bauen und 3 Anschlüsse drehen.

    Vorsicht ist geboten. Ich meine mit den 2732 kamen weitere Programmierverfahren auf. Normal war zu dieser Zeit ein Programmierimpuls von 50 ms. Da dauert das Programmieren schon mal einige Minuten. Bei den neueren Programmierverfahren hatte jeder Hersteller sein eigenes Verfahren. Teilweise wurde auch die Versorgungsspannung erhöht. Das klappt meines Wissens nicht bei dem 2532. Also aufpassen, welches Programmierverfahren der EPROMer für 2732 verwendet.

    es sind alles programmierbare Logikbausteine.

    Das sehe ich anders. Es Ist in meinen Augen keine Logik. Es ist ein normales ROM mit dem GCR-Daten (bzw. binären Daten) auf der Adresseingang und den binären Daten (bzw. GCR-Daten) auf dem Datenausgang.

    Bei der Dekodierung (binär nach GCR) kommt ein wenig Logik ins Spiel. Diese befindet sich aber NICHT im ROM, da dieses nur acht Ausgangsbis hat, aber zehn Bits benötigt werden.


    Das 2716 wird dort ja nicht als Programmspeicher verwendet...

    Nun nicht als Programmspeicher, aber als Datenspeicher. Es ist definitiv im Datenpfad eingekoppelt.


    Aber gut, wir wissen nun, was Du meinst. Magst Du das ROM mal auslesen? Die Position des ROMs läßt leider nichts genaues vermuten. Fakt ist aber, daß der 273 die Datenleitungen speichert. Der 393 vermutlich einen Teil der Adressleitungen speist. Es könnte also ein Generator oder gar eine State-Machine sein. Es gibt da noch ein weiteres ROM: 82S123. Das sollte die nötigen Taktsignale (/RAS, /CAS, MUX ...) erzeugen.

    Auf dem Controller ist auch ein 2716, welches als PLA verwendet wird - genau wie in den CBM Laufwerken...

    Wie meinst Du das? Mir ist nicht bekannt, daß die CBM Laufwerke eine PLA nutzen. Einzig der GCR-De- und Encoder (901467-01) ist bei einigen Laufwerken mit Hardware-Dekodingung vorhanden.

    Zum Glück war ja nicht so viel defekt, so daß ich die schöne HD wieder zum Laufen bekommen habe!

    Was hatte die "Kleine" denn?

    Das ganze geht nur dann gut, wenn das Gerät ebenfalls noch mit dem Schutzleiter verbunden ist.

    Und auch überall einen sehr guten Kontakt zur Ableitung hat. Jede Steckverbindung z.b auch bei Mehrfachsteckdosen minimiert diesen. Bei Hochspannung können da auch bei geringen Schleifenwiderstand schon mal einige Volt abfallen.


    Das ganze hat Ähnlichkeit mit einem Blitzeinschlag. Es wurde dabei eine Fremspannung über den Schutzleiter zum Meßgerät eingespeist. Genau dieser Teil ist hier genauer anzusehen.

    Das ROM meldet sich aber offenbar mit "H & W DISK VERS. 1.2". Das steht etwas im Widerspruch zu dem ROM-Dateinamen V11A. Ich habe auch mehr den Verdacht, auf dem Label der ROMs steht VIIa (das könnte eine römische sieben oder auch nur zwei sein). Darunter ist eine 12.3 vermerkt. Das Handbuch beschreibt auch eine VERS. 1.0. Alles sehr verwirrend.


    Scheinbar eine 6809 Implementierung eines CBM-DOS ähnlichen System. Das hatten wir bei der SSE Hardbox schon einmal für den Z80.


    Das ist ein sehr spannendes Gerät. Herzlichen Glückwunsch, wxo hast Du das her?

    Hallo Helmut,


    das sieht jetzt richtig gut aus. Dann war mein Veto nicht so verkehrt.


    Ich fange mal mit den drei Gleichungen für die 139er an:

    Code
     SEL0 =   /A * /B *    E
    /SEL0 = /(/A * /B * /(/E))
    
     SEL2 =   /A *  B *    E
    /SEL2 = /(/A *  B * /(/E))
    
     SEL3 =    A *  B *    E
    /SEL3 = /( A *  B * /(/E))

    Dann ersetzen wir mal fleissig:

    Code
    /CS_ROM = /(A                                        *  B      * /(/E   ))
    /CS_ROM = /(/SEL2                                    *  /NOROM * /(/SELE))
    /CS_ROM = /(/(/A                    *  B    * /(/E)) *  /NOROM * /(/SELE))
    /CS_ROM = /(/(SEL0                  *  BA11 * / 0  ) *  /NOROM * /(/SELE))
    /CS_ROM = /(/((/A   * /B   * /(/E)) *  BA11        ) *  /NOROM * /(/SELE))
    /CS_ROM = /(/((/BA8 * /BA9 * /BA10) *  BA11        ) *  /NOROM * /(/SELE))

    Und nun wird vereinfacht:

    Code
    /CS_ROM = /(/( /BA8 * /BA9 * /BA10  *  BA11        ) *  /NOROM * /(/SELE))
     CS_ROM =   /( /BA8 * /BA9 * /BA10  *  BA11        ) *  /NOROM *    SELE

    Die letzte Gleichung lauetet sprachlich: DasROM ist selektiert, wenn nicht die Adresse x8xx anliegt, kein NOROM gewünscht wird, aber der Bereich E ausgewählt wird. Perfekt, so sollte es sein.


    Mir geht es manchmal genauso. Ich kann sowohl mit Bausteinen (Gatter) als auch mit Gleichungen "denken". Mal überwiegt das eine, mal das andere. Gut ist es, wenn man das in einander überführt und es weiterhin stimmig bleibt.


    Nette Idee übrigens das 139 als kleine PLA zu nehmen. Entsprechend der Wahl des Ausgangs (0, 1, 2 oder 3) negiert man zwei der Eingänge dieses "NAND"s mit drei Eingängen.


    Gruß Martin

    Hallo joshy,


    Du hast natürlich recht. Und ich versuche es mal ein wenig herzuleiten. Vielleicht kann uns CBM_Ba doch noch folgen.


    Neben den Adressbussignalen BA0 bis BA15 (16 Adressbit für 64 KB) gibt es schon das /SELE-Signal, was low-aktiv ist, wenn eine Adresse $EXXX anliegt.

    Code
    SELE = BA15 * BA14 * BA13 * /BA12

    oder wenn wir beide Seiten negieren:

    Code
    /SELE = /(BA15 * BA14 * BA13 * /BA12)

    Um ein Signal zu erzeugen, daß bei der Adresse $X8XX reagiert, nutzen wir BA8 bis BA11:

    Code
    X8XX = BA11 * /BA10 * /BA9 * /BA8

    Jetzt kommt mein Fehler. Das ROM soll selektiert sein, wenn zwar die Adresse $EXXX (SELE) anliegt, aber nicht der IO-Bereich adressiert wird (X8XX):

    Code
     CS_ROM = SELE * /X8XX

    Da das gesuchte Chip-Select Signal low-aktiv ist, negieren wir wieder beide Seiten:

    Code
    /CS_ROM = /(SELE * /X8XX)

    Nun kommt ein wenig boolsche Algebra. Eine Negierung am Ausgang kann zum Eingang geändert werden, wenn aus dem UND ein ODER wird und umgekehrt:

    Code
    /CS_ROM = /SELE + X8XX

    Das hatte Joshy schon unter #89 aufgeführt. Nun kann ich aber weiter, wie bei #88 ersetzen:

    Code
    /CS_ROM = /SELE + (BA11 * /BA10 * /BA9 * /BA8)

    Und wieder sehe ich das Problem, dies in ein 138 oder 139 zu bekommen. Beides sind Dekoder und haben nur Produktterme. Hier einmal der 138 mit den Eingänge C4, B2 und A1 sowie dem high-aktiven Enable-Eingang E3, den zwei low-aktiven Enable-Eingängen /E1 und /E2 und den low-aktiven Ausgängen /OUT_n:

    Code
    /OUT_0 = /(/C4 * /B2 * /A1 * E3 * /(/E2) * /(/E1))
    /OUT_1 = /(/C4 * /B2 *  A1 * E3 * /(/E2) * /(/E1))
    /OUT_2 = /(/C4 *  B2 * /A1 * E3 * /(/E2) * /(/E1))
    /OUT_3 = /(/C4 *  B2 *  A1 * E3 * /(/E2) * /(/E1))
    /OUT_4 = /( C4 * /B2 * /A1 * E3 * /(/E2) * /(/E1))
    /OUT_5 = /( C4 * /B2 *  A1 * E3 * /(/E2) * /(/E1))
    /OUT_6 = /( C4 *  B2 * /A1 * E3 * /(/E2) * /(/E1))
    /OUT_7 = /( C4 *  B2 *  A1 * E3 * /(/E2) * /(/E1))

    Oder was mache ich jetzt falsch?


    Gruß Martin

    Hallo Helmut,

    so nun wohl die endgültigste version. wenn mir nicht noch etwas einfällt ;)

    nun wird kein x8xx signal mehr vom board extra benötigt.
    es wird selbst erzeugt, von den schon vorhandenen signalen. am rom sockel.

    mit zwei 74ls139 oder mit einem 74ls138 und einem 74ls00

    Ich befürchte, Du hast da einen Fehler drin. Das Ausgangssignal /CS ROM + EPROM ist aktiv (low), wenn die Adressen $E800 bis $E8FF anliegen. Das Signal X8XX ist aber ein Ausschluß. Daher fehlt eine Invertierung an diesem Signal. Dann läßt sich die Gleichung aber nicht so gut vereinfachen:

    Code
    X8XX    =           /BA8 * /BA9 * /BA10 *  BA11
    /CS_ROM = /SELE * /X8XX
    /CS_ROM = /SELE * /(/BA8 * /BA9 * /BA10 *  BA11)
    /CS_ROM = /SELE *  ( BA8 +  BA9 +  BA10 + /BA11)
    
    * = log. UND, + = log. ODER, / = Invertierung

    MIt einem 138 oder 139 bekommt man das nach meiner Auffassung nicht mehr hin. Von dem weiteren Signal /NOROM mal ganz abgesehen.


    Oder habe ich da einen Gedankenfehler?


    Gruß Martin