Beiträge von 2ee

    Auf dem VcFe hatte ich mir natürlich nicht nur die Amiga vom Flohmarkt geholt, sondern dort stand auch noch diese Sparc Classic mit Vertical Stand, Tastatur und Maus. Da konnte ich natürlich nicht widerstehen.



    Ich hatte bereits 2009 eine Classic bei eBay für einen Euro erstanden, bei der aber durch Blitzschlag sowohl das Netzteil als auch das Mainboard defekt waren. Ich hatte damals deshalb einfach ein Micro ATX Mainboard mit einem Intel Atom eingebaut, auf dem heute OpenSolars läuft. Jetzt doch noch eine funktionsfähige Sparc Classic mit Original Hardware zu bekommen war also einfach genial.


    Klar war, das nach all den Jahren die Batterie des NVRAMs MK48T08 - oder auch Timekeeper RAM - leer sein musste. Aber zunächst wollte ich sehen, ob die Maschine noch läuft. Das Netzteil lieferte bei nur angeschlossener Festplatte auf den 5V Leitungen nur noch 4,85V, also vermutlich die Bufferkondensatoren nicht mehr in Ordnung. Die +-12V Versorgungen waren OK.


    Nach dem Einschalten meldete sich der Rechner natürlich erst mal mit "The IDPROM contents are invalid", was mir allerdings erst mal egal war. Nach Eingabe von "boot disk" war klar, dass der Rechner mal an der Uni Freiburg seinen Dienst verricht hatte.


    Weniger schön waren allerdings zwei sporadische Vollabschaltungen, und am nächsten Tag ließ sich der Rechner dann garnicht mehr einschalten.


    Offensichtlich hatte sich der Boot Strap Elko des Schaltnetzteils verabschiedet. Also erst mal Netzteil aufschrauben und inspizieren.



    Da besonders gerne die Elkos in der Nähe der Kühlkörper verenden, ging hier also erst mal meine Suche los. Und tatsächlich konnte man schon an einigen Elkonahen Bauteilen ausgelaufenes Elektrolyt erkennen. Von den drei Elkos rund um den PWM Baustein waren alle vollständig defekt, weshalb mein Vertrauen in die restlichen Kondensatoren schon ziemlich zerstört war. Die Buffer Kondensatoren für die 5V Versorgung waren auch bereits 30% unter Wert. Deshalb wurden dann von mir gleich alle Elkos getauscht. Fazit: Von 22 Elkos waren 12 entweder vollständig defekt, hatten zu niedrige Werte, oder bereits Spuren auslaufenden Elektrolyts. Nach dem Tausch läuft das Netztteil jetzt wieder zuverlässig.


    Beim NVRAM wollte ich kein neues kaufen, schließlich geht es hier ja um den Erhalt alter Hardware. Aber wenigstens gibt es das noch als Option.

    Prinzipiell gibt es zwei mechanisch verschieden aufgebaute Timekeeper RAMs. Das bei meiner Sparc verbaute NVRAM hatte einen "schwebenden" Anbau. D.h. der Teil mit der Batterie und dem Oszillator ist links und rechts auf den RAM/Uhrenbaustein geklebt und hat einen Spalt zwischen den beiden Komponenten.



    Das macht eine Reparatur etwas schwieriger, wie sich noch zeigen wird. Um an die Anschlüsse für die Batterie zu kommen, muss man seitlich vorsichtig das Gehäuse auffräsen, was bei mir noch wunderbar funktionierte. Beim anschließenden Freikratzen der Anschlüsse, hat dann allerdings irgend so ein Depp ( :tüdeldü:) zu kräftig mit dem Schraubenzieher zugelangt, so dass nicht nur die Anschlüsse vom Chip zur Batterie, sondern auch einer der Quartanschlüsse abgebrochen ist :wand: .

    Zum Glück waren die aus dem RAM kommenden Anschlüsse noch lang genug, um hier ein Batterieanschlusskabel und einen passenden Uhrenquarz anzulöten.


     


    Das ganze habe ich dann links und recht mit zurechtgeknippsten, aufgeklebten Teilen von Kaminzündhölzern "eingeschalt", und darauf wieder den Originaldeckel geklebt. Dann noch etwas Heißkleber zum Fixieren der Leitung und Fertig.


     


    Den Batteriehalter habe ich auf eine Lochrasterplatine gesetzt, welche als Sandwich noch eine zweite Platine zum Schutz und zur Befestigung via Kabelbinder darunter gelötet bekommen hat. Zum Schluss noch den Original Aufkleber des NVRAMS wieder aufgeklebt und gleich mal ausprobiert.


     


    Nach dem Speichern der MAC Adresse und Host-ID blieben die Werte dann wie erwartet auch ohne Strom erhalten. Und die Uhr tickt auch. Was will man mehr. Als nächstes muss noch ein neues Betriebssystem drauf. Das kann aber erst mal noch warten. Hauptsache der Rechner läuft wieder.


    So, jetzt bin ich doch gerade selber etwas erschrocken, als ich gesehen habe, dass es bereits 6 Wochen her ist, als ich mich das letzte mal hier gemeldet hatte. In den letzten Wochen waren bei mir so viele private aktivitäten, die mich von Basteleien und dem Junior im speziellen abgehalten hatten.


    Aber jetzt habe ich wieder Zeit und auch richtig viel Lust am Junior ][ weiter zu arbeiten. Hier mal meine Agenda für die nächsten Wochen:


    Als erstes werde ich mich noch ein wenig um die Software kümmern, sprich den Boot Code zumindest mal soweit angehen, dass auch jemand anderes als ich ein kleines DOS für den Junior basteln könnte. Dazu wird eventuell nochmal eine kleine Änderung am ROM Code nötig sein, weshalb ich mich vielleicht auch gleich noch mit dem fehlenden Treiber für einen (parallelen) Papertape Reader beschäftige.


    Der nächste Punkt ist die dritte Erweiterungsplatine. Hier soll zumindest ein Grafikprozessor und ein Floppy-Controller drauf. Eventuell auch gleich noch eine Banking Logik um die zweiten 64K RAM anzusprechen. Eventuell kommt aber auch gleich noch ein weiterer 128K RAM Baustein mit drauf. Ein Joystick-Port wäre natürlich fein, ließe sich aber auch mit dem zweiten VIA des bisherigen IO-Boards erledigen. Mal schauen.


    Beim Grafikprozessor war ja der ESP32 mit FabGL eine große Option. Hier werde ich mich wohl erst mal mit der FabGL beschäftigen müssen. Das Interfacing ist hier auch noch nicht ganz geklärt.

    Beim Floppy Controller hatte ich zuerst überlegt, diesen mit einem ATMega zu realisieren. Das war mir aber dann doch zu viel Aufwand, da die MFM Codierung doch recht zeitkritisch ist und ich dann alles hätte in Assembler schreiben müssen. Ich habe mich jetzt deshalb für den GM82C765B Floppy Sub System Controller entschieden, der bei UTSource noch in ausreichender Stückzahl und recht günstig zu haben ist. Ich werde dort in den nächsten Tagen mal ein paar ICs auch für andere Projekte bestellen und mich dann ausgiebig mit diesem Controller beschäftigen.


    So weit erst mal wieder ein Lebenszeichen von mir. Ich hoffe, es gibt noch ein paar wenige, die sich für den Junior ][ interessieren, um mich da weiterhin ein wenig vorran zu treiben.


    Cheers


    Jörg

    Der Stecker ist doch sicherlich mal durch meine Hände gegangen?

    Hab gerade mal nachgesehen: eBay Händler tatsächlich pc-rath_de. Da hätte ich mir aber eigentlich schon einen Foren-Rabatt erhofft. :)

    Jedenfalls Danke für den Stecker samt Gehäuse. Hast meinem Amiga das Leben ein Stück bunter gemacht (mit meiner Löt-Hilfe natürlich 8-) ).

    Na dann ist doch gut, daß man schon bei AmigaOS1.3 die Gui "anpassen" konnte. :sunny: Für die Zeit eigentlich schon ganz schön.

    Wie war das eigentlich bei den AtariSTs und den Macs zu der Zeit? Ging sowas dort auch? :grübel:

    Mit dem Resourcen Editor ResEdit konnte man unter MacOS so ziemlich alles anpassen, im Control Panel war das aber - wenn ich mich richtig erinnere - nicht möglich. Beim Atari hab ich keine Ahnung ob es möglich war das Aussehen des (der) Maus Cursor zu ändern.


    Edit: Ich meinte natürlich, den Maus Cursor zu ändern, war im Mac Control Panel nicht möglich. Sound, Background Pattern Farbe, etc natürlich schon.

    So, jetzt hab ich meine absolute NICHT-Lieblingsarbeit vollendet. War aber für einen guten Zweck, nämlich der Amiga den grauen Star austreiben, sprich ein RGB Kabel basteln.




    Ein SCART Kabel hatte ich letztes Jahr noch irgendwo bestellt um für meinen Triumpf Adler Alphatronic PC auch mal ein RGB Kabel zu löten. Hatte da aber irgendwie noch keine Lust gehabt. Jetzt musste ich feststellen, dass diese Kabel wohl offensichtlich doch nicht mehr sooo in Gebrauch sind, sonst wäre wohl deren Qualität wohl nicht so grotten schlecht. Teilweise waren an den Crimpanschlüssen Übergangswiderstände von 500-600 Ohm messbar, weil die Anschlüsse schlampig gequetscht waren.


    Wie auch immer. Mission erfüllt, mein Amiga kann nun auch Farbe.



    Beim Mauszeiger konnte ich leider nicht anderns als den in was brauchbares zu ändern. Bin halt ein alter MacOS Liebhaber. Sorry :tüdeldü:

    Aber dieses Pfeil Dingsda der Work Bench ist doch echt ziemlich gewöhnungsbedürftig.


    Leider hat sich übrigens nach ein paar Tagen herumliegen der Zustand des Floppy Laufwerks wieder etwas verschlechtert. Ein Booten war erst nach zwei Anläufen möglich. Hier muss ich also demnächst nochmal ran.

    Nachdem der Amiga jetzt mal so weit wieder lief, war zunächst nur noch das Fehlen einer Workbench Diskette das abschließende Problem. Im Internet konnte ich dann für wenig Geld eine Workbench 1.3 und die Amiga Extras 1.3 mit Amiga Basic 1.2 Disketten erstehen.


    Beim Booten gab es dann allerdings neben ständigen Lesefehlern ein sehr unangenehmes Quietschgeräusch aus dem Laufwerk. Offensichtlich hatte sich der Wasserschaden auch auf das Lager des Steppermotors für den Schreib-/Lesekopf ausgeweitet. Mit einem Tropfen Maschinenöl in die Achslager, etwas Schmierfett auf die Spindel und einer gründlichen R/W-Kopf Reinigung wurde der Bootvorgang mit jeder Wiederholung dann etwas besser ausgeführt.

    Mittlerweile startet der Rechner ohne Quietschen vollständig bis zum Desktop, und eine Backup Kopie der Workbench-Diskette konnte ich auch schon fehlerfrei erstellen.



    Nächstes Projekt ist nun noch ein RGB-Monitorkabel. Die etwas unübliche DB-23 Buchse ist jedenfalls schon mal bestellt.

    Rostumwandler ... ?

    Wo gibt es sowas ?

    Scheinbar hat der tatsächlich braunen Rost in "Glanz" verwandelt (vorletztes Bild).

    Oder warst da noch mit Schleifpapier drean ?


    Den Rostumwandler hatte ich noch im Keller meines Vaters gefunden. War ursprünglich für Autorost gedacht, sprich es gibt so was auch im KFZ Zubehörhandel.

    Die Schleifspuren stammen noch von der Vorbehandlung mit der rauen Seite eines Küchenschwamms. Ansonsten ist es so, wie Holger gesagt hat. Es bildet sich eine Eisenphosphatschicht, die dann als Schutz vor weiterem Rost drauf bleibt. Das sieht dann so leicht gülden aus.

    Auf dem VCFe in München konnte ich nicht widerstehen und hab mir dort auf dem Flohmarkt eine(n) Amiga für wenig Geld gekauft.

    Da ich eher aus dem Apple Lager komme, waren für mich Commodore Amiga und Atari ST eigendlich nie von Interesse gewesen. Mittlerweile besitze ich nun aber zwei Atari ST und noch keine Amiga, deshalb wurde es also Zeit.


    Ein erster Blick auf das neu erstandene Schmuckstück zeigte schon, dass hier etwas getan werden musste. Eine Gehäuseecke war vollständig herausgebrochen und der Verdreckungsgrad war unanständig.



    Ausserdem war weder eine Maus, noch ein Netzteil im Karton. Das Netzteil konnte ich dann gleich auf dem VCFe via eBay kaufen. Vermeindlich defekt, was mir aber egal war, ich brauchte eigendlich nur den quadratischen Netzteilstecker.


    Als ich den Rechner dann zuhause das erste mal öffnen konnte, war klar, dass der Wasserfleck auf dem Karton entstanden war, als sich die Amiga darin befand.




    Das Mainboard hatte ein paar Stellen, an dem das Kupfer schon leicht angegriffen war. Allerdings allesamt Masseflächen und ohne Kontaktierungsverluste. Nach der Reinigung der Platine waren dann erst mal keine weiteren Probleme zu erkennen.


    Das (defekte) Netzeil war mittlerweile auch eingetrudelt. Also aufschrauben und erst mal schauen, ob doch was zu retten ist. Und siehe da, an der Platine waren alle Spannungen vorhanden. Allerdings tat sich nach dem Anschluss an den Rechner nichts. Am Floppylaufwerk kamen gerade mal 300mV an. Die +/-12V waren aber in Ordnung. Als ich mir dann den Netzteilstecker ansah, war klar, dass dieser auch mal Feuchtigkeit gesehen hatte. Die Pins waren alle ziemlich grün. Also den Stecker erst mal mit Essig, dann mit Alkohol und zum Schluss mit Kontaktspray fluten. Nach dem erneuten Anschluss an den Rechner tat sich zwar immer noch nichts, dafür war aber die 5V Versorgungsspannungen auch an den einzelnen ICs in Ordnung.


    Eine Oszi-Messung am Takteingang der 68000 zeigte dann, dass dort nichts taktete, dafür war aber der 28MHz Takt am Quartz vorhanden. Ein Blick auf den Schaltplan zeigt, dass Fat Agnus für die Takterzeugung zuständig ist. Nach einem Wasserschaden also das nächstliegende probieren: IC aus der Fassung, Kontaktspray reinpusten und nochmal probieren. Und tatsächlich bekam ich dann auf dem Bildschirm nach kurzer Zeit die Aufforderung eine Boot Diskette einzulegen.



    Allerdings leuchtete die Power LED auf dem Keyboard noch nicht, die Caps Lock LED wollte auch nicht leuchten und Ctrl-Amiga-Amiga hatte keinen Reset Effekt. Wieder ein Blick auf den Schaltplan zeigte, dass die Power LED einfach direkt zwischen dem Status Pin und Masse geschaltet ist. Und genau hier war das Problem. Die Pins Masse, Status und In Use waren im Stecker weggerottet. Glücklicherweise hatte ich noch genau ein 8 poliges Anschlusskabel mit Stecker und - witzigerweise - genau der gleiche Farbkodierung.

    Nach dem umlöten der Stecker tat dann der Rechner wieder soweit vollständig!



    Der Rest war dann intensives Schrubben der Tastatur, die wohl offensichtlich in einem Katzenhaushalt ihren Dienst getan hatte und behandeln der Abschirmbleche mit Rostumwandler.



    Beim Gehäuse tat sich dann bei eBay ein unbeschädigter Ersatz für ein paar Euro auf.



    Da ich wie gesagt nie mit einer Amiga gearbeitet habe, fehlt mir zum Glücklichsein noch eine Workbench Diskette. Vielleicht findet sich ja auf der kommenden CRT in Stuttgart ja ein (Kopier) Spender. Ich komme jedenfalls mal mit ein paar leeren Disketten vorbei. Ansonstenwürde ich mich auch freuen, falls hier im Forum jemand zufälligerweise eine Kopie übrig hätte.

    Jetzt muss ich doch noch ein ROM Update nachschieben, weil sich in der Version 1.0.3 zwei Fehler eingeschlichen hatten.


    Zum einen konnte nach einer Umschaltung der Standard Eingabe von ASCII-Tastatur auf Terminaleingabe (z.B. in BASIC via IN#0) die XModem Routine nicht mehr fehlerfrei Daten lesen. Jetzt läuft alles wieder so wie es soll.


    Das andere Problem hatte sich in der Boot Routine ergeben.

    Ich war stillschweigend davon ausgegangen, dass ich im Boot Block der FAT32 Partition auf der SD-Karte das erste Byte (x86 Opcode $EB = short jump) gegen einen 6502 Opcode $B0 = BCS (Branch on Carry Set) austauschen kann, damit ich nur noch zum Anfang des Boot Block Buffers ($0600) springen muss, um den Boot Code zu laden. Es hat sich aber herausgestellt, dass Windows eine Änderung an genau diesem Byte des BB nicht wirklich mag und nach einer solchen Änderung die SD-Karte immer als unformatiert angezeigt wird.

    Die Lösung ist nun, erst nach dem Einlesen des Boot-Blocks, den Wert $EB im RAM Buffer an $0600 gegen ein $B0 zu tauschen und dann erst mit einem JMP $0600 den Boot-Code auszuführen.


    Ich hab jetzt mal einen kleinen Dummy Boot-Code in den Boot-Block geschrieben. Das ganze sieht dann gerade so aus.



    Der nächste Schritt ist nun, das Root Directory zu lesen, eine Datei BOOT.SYS zu finden und diese zu laden. Somit können dann die FAT-Treiber und das DOS vom Datenträger geladen werden.

    Kleiner Tipp: morgen ist ab 18 Uhr wieder ein Retroabend im shack und nächste Woche findet dort die zweitägige CRT statt. ;)

    Morgen wird es bei mir leider nichts. Aber an der CRT sollte es evtl. klappen. Am Samstag werde ich wohl so gegen 13:30 Uhr auf dem Campus sein und dann mal sehen, ob man in das Computermuseum rein kommt (je nach Andrang).

    Wo habt ihr denn den WANG 144-T ausgegraben? Hast du den mitgebracht, oder war der irgendwo im Uni-Keller gelegen?

    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.

    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 :

    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 :


    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

    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

    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: ...


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

    Nennen wir es anregende Vorschläge 8-) .


    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.


    Morgen Nachmittag prüfe ich die Messer und Buchsenleiste

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

    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...

    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ü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,


    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

    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.

    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

    Zum Thema Grafikkarte:


    Zunächst, ich fühle mich durch eure Kommentare nie unter Druck gesetzt. Im Gegenteil, die Rückmeldungen, ob ihr für den Junior ][ irgendetwas sinnvoll/notwendig findet ist für mich ja auch eine sehr interessante Information.


    Bzgl. der Planung einer Grafikkarte hatte ich bereits mit Norbert einige Überlegungen ausgetauscht.

    Grundsätzlich gäbe es zwei Ansätze:


    1. Retro Bauteile

    2. Moderne Alternativen.


    Bei den Retro Bauteilen hatte ich den Yamaha V9938 im Auge. Mit Auflösungen bis 512x512 Pixel, Linien und Sprite Befehlen eigentlich der geeignete Kandidat. Show Stopper sind aber der Preis (ca. 35€) und die Tatsache, das ich hier nur SCART RGB oder mit Zusatzbaustein auch SVHS und Composite, aber eben kein VGA Signal bekomme (ließe sich aber per SVHS/VGA Wandler machen).

    Die moderne Alternative wäre für mich ein ESP32 mit der Grafikbibliothek FABGL. Kann VGA mit 64 Farben und Auflösungen bis 800x600 (evtl auch 1024x768), Sprites, Linien, Rechtecke, Ovale. Ausserdem benötigt man keinen zusätzlichen Speicher, und die Kosten liegen bei ein paar Euro. Fühlt sich natürlich irgendwie nach "Beschiss" an, ist aber pragmatisch gesehen die bessere Lösung.Da die Bib schon existiert, spart man sich da eine Menge Zeit und Nerven. Alternativ gibt es natürlich auch die BitLuni Bibliothek, mit der man sogar auf 14Bit Farbtiefe kommt.


    Propeller und EF9366 habe ich schon mal ausgeschlossen, weil nicht wirklich gut (Propeller) oder zu teuer, schwer zu bekommen und sehr eingeschränkt in der Funktion (EF9366).


    Ich eröffne jetzt also mal die Diskussion, was für euch wichtig/richtig/notwendig wäre, welche anderen (eventuell von mir noch nicht berücksichtigten) Grafik Chips noch möglich wären, und welche Ziele damit überhaupt erreicht werden sollten (besonders hohe Auflösungen, viele Farben, Schnittstelle, Kompatibilität, echtes Retro oä.).


    Bin gespannt


    Jörg

    Hier die neue BIOS Version 1.0.3 für den Junior ][.


    Darin enthalten:


    SPI Treiber

    SD-Card Treiber

    Boot Code für SD Karte und künftige Floppy- und Festplattenlaufwerke

    Fehlerkorrektur für den Disassembler, wie von jet2blue gefunden und vorgeschlagen.


    SD Karten werden- wenn vorhanden - soweit korrekt erkannt und bei einem Reset wird zunächst der MBR geladen. Wenn hier der Boot Indikator gesetzt ist, wird der Boot Block der Partition 0 geladen. Falls dort dann der OEM String "JCOS" gefunden wird, springt die Reset Routine zum im Boot Block gespeicherten Code und führt ihn aus. Falls ihr eine SD Karte eingelegt habt, könnt ihr nach einem Reset den Boot Block im Adressbereich $600-$7FF ansehen und so prüfen, ob die Karte erkannt wurde. Ihr dürft mir da gerne Rückmeldung geben, ob das bei euch funktioniert. Ich habe jetzt mal 7 Karten mit unterschiedlichen Größen ausprobiert, bei denen das Lesen problemlos funktionierte.


    Natürlich kann z.Zt. noch nicht auf die SD Karten Daten zugegriffen werden, da noch kein DOS und somit keine FAT Treiber vorhanden ist. Ich werde in den kommenden Monaten daran arbeiten. Zusätzlich steht aber noch eine Grafikkarte ganz oben auf der ToDo Liste. Mal sehen, was mich da mehr antreibt.


    Vom 29.4. bis 1.5 bin ich auf dem VCFe in München. Vielleicht sehe ich ja dort ein paar von euch. Würde mich sehr freuen.


    Soweit wünsche ich euch erst mal viel Spass mit dem neuen BIOS.


    Jörg

    Hier nochmal ein Update meines kleinen 6502 Assembler Editors stack:ed.


    Ich hab jetzt noch ein größeres Problem bei der Fehleranzeige gefunden. Bei längeren Datendeklarationen im Code (DB $01 02 ... oder TEXT 'Hello World') erzeugt der a65 Assembler aus einer Zeile Code im Ergebnislisting mehrere Zeilen mit jeweils 8 Byte, was dann zu Verschiebungen in darauffolgenden angezeigten Fehlerzeilen führte. Also z.B. Fehler ist in Zeile 100, wird aber für Zeile 105 angezeigt. Das Problem ist jetzt behoben.

    Ausserdem könnt ihr jetzt Datei-Typen (also z.B. .asm) unter Windows dem Editor zuweisen, so dass diese wie gewohnt per Doppelklick den Editor öffnen (Kontext Menü: Öffnen mit -> Standardprogramm auswählen... -> Weitere Optionen -> Andere App auf diesem PC suchen).


    Drag and Drop funktionierte ja bereits für den Editor Bereich, in einer der nächsten Versionen werde ich das dann auch auf den Work Bench Bereich ausweiten. Aussderdem kommt dann noch eine Favorite Liste hinzu und häufig benötigte Dateien sollen dann im Work Bench angeheftet werden können.


    Ich hab jetzt endlich auch wieder etwas mehr Zeit, so dass ich hoffentlich diese Woche den SPI/SD-Card Code endlich in das Junior BIOS bekomme, bevor das VCFe in München stattfindet. Sobald fertig, werde ich mich natürlich gleich melden.

    Hallo Norbert


    Kannst dsu mir bitte beizeiten mal erklären, wie das mit den I2C Port Expandern funktioniert?

    In deinem Fall musst nur den PCF8574 an SDA, SDC des IO Boards hängen, A0..A2 des PCF auf Masse (Basisadresse ist dann 32) und P0..P3 an den 4 zu 16 Decoder statt dort die Portpins des 6532 zu nutzen.



    In der angehängten ZIP findest du die Datei PCF8574 Keyboard.asm. Die Routine KEY_DOWN musst du dann an der Stelle deines Codes mit JSR aufrufen, an der du die 6532 Port Pins P0..P3 setzt. Rückgabe ist dann Carry gesetzt = Taste gedrückt, Carry nicht gesetzt, keine Taste gedrückt.


    Zusätzlich zu der asm Datei ist auch der geupdatete Stack Editor, der jetzt stack:ed heißt in der ZIP. Es sind ein paar neue Funktionen hinzugekommen und Fehler behoben:


    - Der Editor speichert jetzt Position und größe des Editor Fensters

    - Ctrl-X/C/V/A funktioniert jetzt auch in den Such Eingabefeldern

    - Löschen aller gesetzter Positionsmarken geht jetzt

    - Zusätzlich zum Kontextmenü: Ctrl-Shift 1..9 toggelt eine Positionsmarke

    - Zusätzlich zum Kontextmenü: Ctrl 1..9 springt zu einer gesetzten Positionsmarke

    - Klicken in den Zeilennummernbereich setzt Positionsmarken. Ein Klick auf ein Positionsmarkensymbol löscht die Marke wieder

    - Geänderte, nicht gespeicherte Dateien werden in der Work Bench jetzt farblich (rot) hervorgehoben

    - Es wird vor dem Speichern eine Backup Datei angelegt

    - Die assemblierten BIN und LST Dateien werden nun auch in das Ursprungsverzeichnis zurück kopiert - sind also nicht nur im Pfad des Editors zu finden


    Die PDF-Anleitung für den A65 Assembler ist nun auch in der ZIP mit drin.