Junior Computer ][

    Hallo Jürgen,


    nur ganz kurz, da ich gleich weg muss. An den beiden Platinen muss nichts mehr gepatched werden.

    Die von dir genannte EhBasic Datei kann nicht mehr genutzt werden. Du benötigst die Version 2.23 und das Junior BIOS 1.0.2, bzw. 1.0.3, die du hier findest.

    Falls du damit immer noch nicht weiter kommst, melde dich bitte nochmal, ich werde dir morgen dann aber erst wieder antworten können.


    Jörg

    Hallo Jörg

    Danke für die antwort, BIOS 1.03 und Basic 2.23 geflasht und getestet, die I/O Karte wird nicht gefunden. Im Terminal gehts sofort in den Monitor.

    Die Digitalen IC's habe ich mit dem TL886II plus per Logic IC Test geprüft.

    Was ist die minimale bestückung damit die Karte gefunden wird?

    Auf dem Junior ist der Step aus und JP1 auf 1 und 2 gejumpert.


    Jürgen

    Nochmal kurze Antwort über das Handy.

    Hast du die Basisadresse der IO Platine eingestellt? Dazu muss auf der linken Seite eine der drei Lötbrücken gesetzt werden.

    Sorry Jürgen, ich hatte das a bei der Revision der I/O-Karte übersehen. Auf meiner Rev 1 war das noch nötig. Jörg hat selbstverständlich recht!

    ___________________________________________________________________________________________________

    "Traue niemals einem Computer, den du nicht aus dem Fenster werfen kannst" (Steve Wozniak)

    Hallo Jürgen,


    offensichtlich wurde bei deinem IO Board nicht in den ROM Bereich umgeschaltet. Versuche deshalb mal das von Hand zu machen.


    Da du K2 als Adressauswahl genommen hast, lautet die Basisadresse bei dir $0800.


    Gib im Monitor mal bitte DFFE.DFFF ein, dann siehst du die letzten zwei Bytes des Basic ROM Bereichs. Du hast da vermutlich gerade noch das RAM eingeblendet und siehst da irgendwelche Zufallszahlen.

    Gib deshalb einfach mal DFFE: 01 02 ein, dann nochmal DFFE.DFFF

    Bekommst du 01 02 wieder aus dem Adressbereich zurückgelesen, oder steht dort wieder das gleiche wie vorher?

    Schalte nun auf das ROM. Das erledigt man durch einen Schreib- oder Lesezugriff auf $0830. Gib dazu am Prompt einfach 830 (RETURN) ein.

    Falls die Umschaltung funktioniert hat, solltest du nun mit DFFE.DFFF als Ergebnis die Magic Number 65 22 bekommen. Ist das nicht der Fall, stimmt vermutlich irgendwas an der Umschaltelektronik nicht, da du ja das aktuelle EhBasic ROM drauf hast.

    Mit 820 (RETURN) schaltest du wieder zurück auf das RAM. Hier sollten dann nach Eingabe von DFFE.DFFF die vorher eingespeicherten Werte 01 02 wieder angezeigt werden.


    Sag mir bitte Bescheid, wie deine Ergebnisse da waren, dann können wir weiter überlegen.


    Liebe Grüße


    Jörg

    Hallo Jürgen,

    Schalte bitte nochmals zuerst auf das RAM (mit 820) dann Eingabe DFFE: 01 02 und dann DFFE.DFFF

    Kommt da 01 02 wieder raus? So wie es bei dir aussieht, konnten ja vom Urzustand die Werte 32 1F nicht überschrieben werden, was ja schon mal seltsam wäre.

    Hallo Jürgen,


    die beiden Daten Byes die bei dir angezeigt werden, liegen im 1K Bereich des Original Junior ROMs und können an der Stelle DC00.DFFF nur deshalb angezeigt werden, weil die beiden Signale BANKA0_SEL (Pin A11 am Bus Konnektor) und BANKC0_SEL (Pin C6) bei dir offensichtlich vollständig in der Luft hängen und somit der Adressbereich nicht komplett decodiert wird. D.h. entweder kommen die Signale über die Busplatine nicht an der IO Platine an, oder werden dort nicht richtig "verarbeitet".

    Das kann dann auf der IO Platine entweder an IC U6 (74LS137) oder an einer der Dioden D3, D4, D5 liegen. Vermutlich sogar nur an D3. Ist die Diode richtig herum eingelötet (Kathode an Pin 9 von U7 - 74LS139, bzw. immer an den quadratischen Lötpads) oder evtl. defekt?

    Schau am Besten mal alle Dioden D1 bis D10 bzgl. Polarität an. Auf der neuen Rev. 1B habe ich die 1N4148 gegen BAT46 getauscht, da diese in Durchlassrichtung näher Richtung 0V kommen. Bisher gab es da zwar keine Probleme mit den 1N4148, aber man weiß ja nie.


    Im Schaltplan der IO Platine liegt der für dich interessante Teil links neben der 6522 VIA (U4). Also die Bauteile D1 bis D5, U6, U7B, U9C, U9D. Ich vermute mal dort den Fehler.


    Die A Reihen der Bus Konnektoren sind übrigens jeweils die unteren. Pin 1 liegt von der Lötseite der Backplane gesehen rechts.

    Hallo Jörg

    Bei allen Dioden die Richtung geprüft, ausser D11 u. D12 sind BAT46. Den U6 u. U7 ausgetauscht.

    Aber es hat sich nichts geändert. Morgen Nachmittag prüfe ich die Messer und Buchsenleiste

    Danke für deine Mühe

    So, jetzt muss ich langsam mal auf eure Antworten bzgl. Grafikkarte reagieren. Zunächst mal vielen Dank für eure Rückmeldungen. :):thumbup:


    Vor allem ThoralfAsmussen hat mir ja eine Menge Vorschläge gemacht, die ich jetzt mal einzeln durchgehen will:


    Ich denke, das Thema Spiele ist natürlich bei einer Grafikkarte wichtig. Bei einer guten Farbpalette wären da von mir aus auch schon 16 Farben ausreichend, was bzgl. Geschwindigkeit für einen 8-bitter wohl noch am besten zu handhaben ist. Wenn der Chip mehr Farben kann, wären dann indizierte Farben in eine größere Farbpalette natürlich auch ganz nett.


    6545 / 6845 möchte ich daher ausschliessen, da eben doch nur Text Mode möglich (OK Grafikzeichen ala PET gehen auch) und Mono Color.


    Ebenso ist mir die PicoVGA Lösung nicht wirklich gut, weil mir das zu kompliziert erscheint die Software des Pico anzupassen.


    Der TMS9918 ist der Vorgänger des von mir bereits in die engere Wahl gebrachten V9938, bloß kann letzterer wesentlich mehr. Ausserdem dürfte der 9918 noch teurer in der Beschaffung sein.


    Den NEC7220 werde ich mir nochmal ansehen. Mit dem hatte ich mich bisher noch nie beschäftigt.


    Den EF9366 hatte ich bereits ausgeschlossen, da dieser nicht wirklich so viel kann. Ausserdem wieder schwer beschaffbar.


    Die Grafiklösung für den Micro-PET kann ich ja nächstes Wochenende direkt mal mit Andre Fachat besprechen, der ist da auch in München auf dem VCFe.

    Apropos Andre Fachat: Ist das nicht der, der den VICE Emulator mit entwickelt hatte? Oder irre ich mich da?


    Der ESP32 scheint ja als Lösung doch für einige akzeptabel zu sein. Jedenfalls kann man damit sehr gut arbeiten und die FABGL lässt sich ganz gut anpassen. Steht bei mir jedenfalls auch immer noch mit am höchsten im Kurs.


    Die Idee, halbe Kartengrößen mit einer angepassten, L-förmigen Backplane zuzulassen, bei der die unteren beiden Slots in Doppelausführung nebeneinander liegen (soz. Slot 1a/b und 2a/b) finde ich echt gut. Einziges Problem, ich habe dann nach hinten keinen Platz für Anschlüsse. Jedenfalls kann man darüber aber gerne mal nachdenken.


    Meine Idee war ja, die Platine der Grafikkarte gleich noch mit einem Floppy Controller (den man z.B. mit einem ATMega realisieren könnte), einem IDE Controller (ebenfalls ATMega), sowie mehr Arbeitsspeicher auszustatten. Dann wäre der Platz einer doppelt breiten Karte wieder gerechtfertigt. Das sind aber alles noch rosa Elefanten.


    Bei den AVR Microcontrollern mache ich mir übrigens wegen deren Retro Tauglichkeit nicht so viele Gedanken. Immerhin sind sie in einem schönen DIL 40 Gehäuse untergebracht. Und früher gab es ja auch schon Microcontroller auf den Tastaturen (z.B. der 8048). Da tue ich mir bei einem ESP, Arduino Nano oder einem Raspi Pico wesentlich schwerer. Die sehen halt eher wie Fremdkörper aus...

    Zitat von 2ee

    Apropos Andre Fachat: Ist das nicht der, der den VICE Emulator mit entwickelt hatte? Oder irre ich mich da?

    Ist er. PET Abteilung und ganz von Anfang an.



    Zitat von 2ee

    hat mir ja eine Menge Vorschläge gemacht, die ich jetzt mal einzeln durchgehen will:

    Ich hätte es eher "Anregungen" genannt, aber OK.


    Bleiben also real eh nur NEC7220, V9938, potentiell die MicroPET Lösung oder ESP32 übrig.

    -- 1982 gab es keinen Raspberry Pi , aber Pi und Raspberries

    Gefällt mir 1
    Zitat von ThoralfAsmussen

    Ist er. PET Abteilung und ganz von Anfang an.

    Ich hab da nur so blöd gefragt, weil ich die verwegene Idee hatte, ob man - als zukünftige Lösung - nicht den VIC II auf einem ESP32 emulieren könnte. Natürlich mit Erweiterung auf 80 Zeichen (wie hat das der C128 gemacht? - Sorry kenn mich bei den Commodore Rechnern wenig aus, bin halt ein alter Apple II Fan). Ich hab mich aber leider bisher zu wenig mit sowohl VIC II als auch ESP32 beschäftigt, um das vollständig programmieren zu können/wollen. Eventuell kann man die FABGL ja auch als VGA Backend nehmen und als Frontend den VIC II nur auf Registerebene emulieren (wobei das dann eigentlich keine Emulation wäre, sondern einfach Registerkompatibilität). Es wäre dann auch denkbar, einfach zu den "normalen" FABGL Modis einen VIC II Mode hinzuzufügen :grübel: ...


    Zitat von ThoralfAsmussen

    Ich hätte es eher "Anregungen" genannt, aber OK.

    Nennen wir es anregende Vorschläge 8-) .


    Zitat von ThoralfAsmussen

    Bleiben also real eh nur NEC7220, V9938, potentiell die MicroPET Lösung oder ESP32 übrig.

    Bin da immer noch offen für weitere mögliche Lösungen.


    Zitat von juergenmeyer

    Morgen Nachmittag prüfe ich die Messer und Buchsenleiste

    Jürgen, wie weit bist du bisher mit dem IO/Language Board Problem gekommen?

    Hier nochmal vor dem VCFe die letzte Version von stack:ed.


    - Dateien können jetzt festgepinnt werden, so dass sie beim nächsten Editorstart gleich geladen werden.

    - Rechts neben dem Work Bench Titel gibt es jetzt ein Recent File Menü mit den letzten geöffneten Dateien.

    - Die Schriftgröße kann jetzt geändert werden.

    - Es gibt jetzt ein "Go To Line"

    - Mit "Go To Label", bzw. Strg-L wird die Zeile gesucht, in der die Definition des Labels steht, auf dem gerade der Cursor liegt.


    Viel Spass damit


    Jörg

    Hallo Jörg, eine Frage an den Experten 2ee:

    Ich habe das Board 3.1b mit BIOS V1.02 (28C64) aufgebaut, ohne Hardware Patch - also ACIA Betrieb.

    Reines Board ohne zusätzliche ext. Komponenten.

    So weit scheint es zu funktionieren, aber beim normalen Hexdump z.B.: 1500.2000<ENTER> stürzt der

    Rechner ab. Immer beim Überschreiten der RIOT Adresse $1A80 bleibt die RS232 Ausgabe unterschiedlich bei

    $1AF1 oder $1A9E und so weiter stehen. Bis $1B00 schafft er es nicht. Alle anderen Speicherbereiche bis

    $FFFF ohne Probleme. Der Disassembler reagiert genauso. CPU SY6502A mit 1 MHz Quarz-Oszillator.


    Mit meinem eigenen BIOS läuft das Board sogar @2MHz mit einer R65C02P2 CPU ohne das o.g. Problem.


    Tritt das Problem bei Dir auch auf ? Ansonsten muss ich weiter suchen....

    Hallo Jörg

    Ich war leider 2 Wochen Offline, die Messer und Buchsenleiste habe ich überprüft, die Lötstellen sind alle in Ordnung.

    Ich habe mir neue 74LS137 u. 74LS139 bestellt. Diesmal von Texas Instruments.


    Danke für deine Nachfrage und deine Mühe


    Jürgen

    Zitat von jet2bue

    So weit scheint es zu funktionieren, aber beim normalen Hexdump z.B.: 1500.2000<ENTER> stürzt der

    Rechner ab. Immer beim Überschreiten der RIOT Adresse $1A80 bleibt die RS232 Ausgabe unterschiedlich bei

    $1AF1 oder $1A9E und so weiter stehen. Bis $1B00 schafft er es nicht. Alle anderen Speicherbereiche bis

    $FFFF ohne Probleme. Der Disassembler reagiert genauso. CPU SY6502A mit 1 MHz Quarz-Oszillator.

    Hallo jet2bue,

    das ist bei mir ebenso und aus meiner Sicht kein Fehler. Der Cursor bleibt bei mir bei $1ADC hängen. In dem Bereich oberhalb $1A00 liegt u.a. die RIOT RAM Area, also das RAM des 6532, das teilweise vom System genutzt wird, unter anderem die Vektoren für NMI und IRQ, sowie die Hardwareadressen der 7-Segment-Anzeige, Timer etc. . Der Zugriff durch den Hexdump verursacht wohl dieses 'Absturzverhalten'. Hier ein Auszug aus dem Monitor-ROM:


    ; RIOT RAM Area ***************************************************************


    SPI_CODEBASE EQU $1A00

    ;SPI_WRITE EQU $1A00 ; copy of SPI_WRITE0 code starts here

    ;SPI_READ EQU $1A00+N ; copy of SPI_READ0 code starts here

    ;SPI_RESET EQU $1A00+M ; copy of SPI_RESET0 code starts here


    DEVLIST EQU $1A28 ; start of device driver list


    STDBEEP EQU $1A66 ; current standard beep routine

    DEVIN EQU $1A68 ; current opened device input routine

    DEVOUT EQU $1A6A ; current opened device output routine

    DEVCMD EQU $1A6C ; current opened device command routine

    STDIN EQU $1A6E ; current standard input routine

    STDOUT EQU $1A70 ; current standard output routine

    STDCMD EQU $1A72 ; current standard command routine

    STDINDEV EQU $1A74 ; standard input device id

    STDOUTDEV EQU $1A75 ; standard output device id

    STDPRINTDEV EQU $1A76 ; standard printer device id

    STOACC EQU $1A77 ; last accumulator before interrupt


    ; Interrupt Vectors ***********************************************************


    BRKUSR EQU $1A78 ; address of user BREAK vector

    NMIVECT EQU $1A7A ; address of NMI vector

    IRQUSR EQU $1A7C ; address of user IRQ vector

    IRQVECT EQU $1A7E ; address of main IRQ vector


    ; Timer Register **************************************************************


    CNTA EQU $1A94 ; CLK/1T no interrupt

    CNTB EQU $1A95 ; CLK/8T no interrupt

    CNTC EQU $1A96 ; CLK/64T no interrupt

    CNTD EQU $1A97 ; CLK/1024T no interrupt


    CNTIRQ EQU $1A9F ; Timer Interrupt Register


    ; Port Register ***************************************************************


    PAD EQU $1A80 ; Port A Data Register

    PADD EQU $1A81 ; Port A Data Direction Register

    PBD EQU $1A82 ; Port B Data Register

    PBDD EQU $1A83 ; Port B Data Direction Register


    WRDC EQU $1A85 ; Write = set positive edge detection, no int.

    ; Read = get Edge Control Interrupt Register


    Jörg: ich hoffe ich habe das in deinem Sinne korrekt wiedergegeben.


    Viele Grüße

    Norbert

    ___________________________________________________________________________________________________

    "Traue niemals einem Computer, den du nicht aus dem Fenster werfen kannst" (Steve Wozniak)

    Einmal editiert, zuletzt von NorbertJ ()

    Hallo Norbert,

    vielen Dank für die umfangreiche Auflistung - wäre aber nicht notwendig gewesen. Das Lesen vom RIOT RAM $1A00 bis $1A7F sowie der Register von PORT A und B hat keinen Einfluss auf den Programmablauf. Mit Lesen vom RIOT Register $1A8C ($1A8E) wird dem RIOT erlaubt, bei gesetzter Timer-Flag einen IRQ auszulösen (Read Timer/ enable Interrupt). Da der 'normale' Programmablauf teilweise mit Interrupts arbeitet, kommt es hier wohl zum Crash. Die IRQ-Leitung bleibt bei mir dauerhaft aktiv Low, da dieser Interrupt offenbar nicht bedient wird.


    Sorry mein Fehler ! Aber wieder etwas dabei gelernt. Ich möchte nochmals betonen, dass ich das tolle Projekt auf gar keinen Fall kritisieren möchte !

    Ich habe großen Respekt vor Jörg (2ee).


    Viele Grüße, Torsten

    Hallo alle zusammen,


    bin wieder zurück aus München mit tollen impressionen, neuen Bekanntschaften und neuen Ideen.


    Ganz tolle Projekte waren z.B. der TIM von mister-freeze , sowie ein Nachbau eines BUSICOM Taschenrechners mit 4004 und original Support Bausteinen von Andres Reichel. Natürlich auch die Micro-PET Hardware von fachat und das Steckschwein Projekt von Thomas und Marco. Der MC68000 von klaly ist einfach klasse, und ich hoffe, dass da noch einiges in Sachen Software gefunden wird. Natürlich waren alle Ausstellungsstücke wieder mal durch die Bank weg einfach sehenswert und interessant (Die Lilith - der Hammer). Ganz herzlichen Dank geht natürlich wieder an Raffzahn , alias Hans Franke für die tolle Organisation und ein paar richtig gute VCFe Tage. 8):thumbup::thumbup:


    Aber jetzt erst mal zum Problem von jet2bue :

    Zitat von jet2bue

    Immer beim Überschreiten der RIOT Adresse $1A80 bleibt die RS232 Ausgabe unterschiedlich bei

    $1AF1 oder $1A9E und so weiter stehen. Bis $1B00 schafft er es nicht

    Das liegt daran, das beim Lesen der Adresse $1A8C der Timer Interrupt des 6532 RIOT aktiviert wird. Im Bereich $1A00 bis $1B00 kann sich diese Adresse mehrfach befinden, weil der Adressraum hier nicht vollständig dekodiert wird.

    Wenn das Inderrupt Disable Flag der 6502 gesetzt ist (z.B. mal 200: 78 60 und dann 200G im Monitor eingeben) kannst du den vollständigen Adressraum von $0000 bis $FFFF anschauen.

    Der Interrupt ist aber im Normalfall immer aktiviert (sonst laufen beim IO Board einige Funktionen nicht), deshalb lässt das einschalten des Timer Interrupts ohne zuständige IRQ Routine den Rechner abstürzen.

    Der Adressraum $1A80 bis 1BFF ist für Leseoperationen also überall da gefährlich und Tabu, wo eine gespiegelte Adresse von Register $0C des RIOT liegt.


    Vielen Dank übrigens mal wieder an NorbertJ für deine Supporthilfe an jet2bue . Du warst da ganz nah am Problem dran. Dass an $1A8C durch einen Lesezugriff was böses Passiert ist echt schwer einzukreisen. Ich kannte das Problem natürlich schon eine ganze Zeit, sonst wäre das wohl ein längerer Suchabend geworden.


    Dann mal zu deinem Problem juergenmeyer :


    Zitat von juergenmeyer

    die Messer und Buchsenleiste habe ich überprüft, die Lötstellen sind alle in Ordnung.

    Am Besten unterhalten wir uns mal direkt miteinander, um das Problem einzukreisen. Da das Junior ][ IO Board ohne irgendwelche Patches problemlos laufen sollte, müssen wir uns da irgendwie zum Fehler hin hangeln. Wenn kein Bauteilfehler vorliegen, dann eventuell in der von dir benutzten Platine. Vielleicht ein schlechter Via Kontakt der Leiterbahnen? Ich bin auch gerade erst mal ratlos.


    Ich melde mich diese Woche mal per PM bei dir.


    Cheers

    Jörg

    Hallo zusammen,


    bei mir hat die Power on RESET Funktion mit der Bestückung nach Schaltplan 3.1b nicht funktioniert / C20 (470nF), D2 (N4148) und R8 (68k).

    Hiermit stellt sich eine Zeit vom RESET von 26,5ms ein. Die max. Spannung am PIN12 (LM556) beträgt ca. 3,53V. Der LM556 benötigt zum Setzen der RESET Leitung auf aktiv Low ca. 3,3V (ca. 2/3 VCC), nach Absinken der Spannung auf ca. 1,67V (1/3 VCC) wechselt RESET wieder in den Zustand High. Die 26,5ms reichen der CPU, direkter Sprung nach $1C1D funktioniert. Der ACIA reagiert nicht, hierbei ACIA mit fester Baudrate konfiguriert. Durch Überbrücken der Diode D2 steigt die max. Spannung am LM556 auf ca. 4V, die dadurch verlängerte RESET Zeit von 30ms reicht dem ACIA immer noch nicht. Erst ab 36,5ms reagiert der ACIA richtig (nur R8 auf 100k geändert). Versuch leider nicht mit BIOS V1.0.2 durchgeführt, aber ab 41ms funktioniert es. Die bereits publizierte Lösung mit 1uF (C20) funktioniert, mit 800nF ergeben sich ca. 45ms.

    (ACIA = R6551P KW24 1985)


    Meine Lösung: Diode D2 gegen Drahtbrücke ersetzen (oder BAT43/BAT46), R8 auf 100k erhöhen und C20 auf 800nF..1uF ändern. Hiermit werden ca. 4,3V am LM556 erzeugt und die RESET Zeit erhöht sich auf 70ms (@800nF).
    An der 1N4148 fallen ca. 0,55V ab, an der BAT43 nur ca. 0,2V.


    Mein Schiebeschalter (SW26) erzeugt sporadisch Kontaktprellen, was den C20 ungewollt auflädt und in der Original Bestückung keinen sauberen (CPU) RESET generiert.


    Über die RESET Taste stellen sich typ. Zeiten von >100ms ein und der LM556 bekommt volle 5V.


    Ich hoffe, dass ich einen positiven Beitrag zum JUNIOR Projekt leisten konnte.


    Gruß Torsten

    Hallo Thorsten,


    vielen Dank für deine RESET Lösung. Ich werde das bei der nächsten Revision berücksichtigen. Auf die Diode D2 würde ich jetzt nicht verzichten, sondern wie von dir vorgeschlagen gegen eine BAT46 ersetzen.

    Der RESET funktioniert übrigens mit dem "Disable-Auto-Baudrate-Detection" Patch immer völlig problemlos, den Grund hierfür hatte ich aber noch nie genauer untersucht.