Beiträge von fachat

  • Ersatz-Keyboard für PET

    Die e-bay-Auktion von oben ist schon beendet... Ihr habt nicht zufällig eine echte Part number / Hersteller?

    Gedruckt habe ich es schon - aber der eigentliche Taster fehlt leider noch...

  • Quiz

    Ich könnte aus dem Bauch nicht sagen was schneller ist. Der C128 hat langsame 80 Zeichen Ausgabe. Der C610 hat langsame Variablen.


    Wenn es 1000 prints sind sind mind 975 single line scrolls drin. Das dürfte die Performance bestimmen. Also vlt doch der C610 schneller...?

  • Junior Computer ][

    Zitat von 2ee

    Hallo André, ich hab den SD-Adapter von AZ-Delivery genommen. Auf der neuen IO-Board Version werde ich aber darauf verzichten und einen SD-Karten Sockel mit Pegelwandlern direkt auf der Platine unterbringen.

    Gibt es einen Schaltplan von AZ-Delivery?


    Welchen SD-Karten Sockel willst Du nehmen? Ich suche einen der noch 'von Hand' lötbar ist. D.h. auch smd, aber ohne 'versteckte' pins.

  • CBM 3040 justieren - original Floppy in Berlin?

    Ja, die B-R und B-W sind nicht als Befehle geeignet um ganze 'Blöcke' im Sinne von Disk Blocks zu lesen oder schreiben - genau aus genannten Gründen mit der Record Lenght. IIRC das folgt der Logik der REL Records des letzten Blocks einer Datei. Insb. Beim Schreiben wird auch in das erste zweite Byte die Länge des Record geschrieben.


    U1/U2 sind dann dafür da, ganze Blöcke zu lesen und zu schreiben. IIRC kamen die aber erst in DOS 2 - ich meine in DOS 1 sind die noch nicht drin, kann mich aber auch irren


    Edit: ich hab das jetzt nach der Beschreibung von IchBinAlt korrigiert. Aber so richtig will mein Gedächtnis das nicht akzeptieren... ich meine doch dass es das erste Byte das Blocks als Länge nimmt und nicht das Zweite. Aber das muss ich dann mal testen...

  • Danke für die CC 2023

    Auch von mir vielen lieben Dank an Alle, die die CC wieder zu einem solch coolen Event gemacht haben!

    Insb 1ST1 für die Orga und die ganzen anderen Helfer und Helferinnen;

    Toast_r für die Reparatur meines PET;

    for(;;) und lydon für die Gespräche zur FPGA Programmierung;

    CBM_Ba für seine PET Ausstellung und dass wir uns mal persönlich getroffen haben;

    Und all den Anderen mit denen ich gesprochen habe!

  • Junior Computer ][

    Zitat von 2ee
    Zitat von fachat

    Die Frage bleibt aber, ob man 65816 überhaupt mit einer MMU kombinieren muss

    Hallo André, vielen Dank für den Link. Ich muss mir das dann daheim mal ansehen, hier hab ich gerade nur mein Handy zum drauf schauen.


    Die MMU war für mich eben auch ein Anreiz, um den Tasks mehr als 64KB linearen Speicher zu bieten. Das dadurch mögliche schnelle Task Switching ist da eher noch eine schöne Dreingabe. Ich möchte dafür ein SRAM mit 16 Bit Datenbus nehmen, dann hätte ich bei 4KB Seitengröße auch noch 4 Bit für einen rudimentären Speicherschutz (read/write) und Unterstützung für Paging (available, dirty) frei.

    Die Idee mit der SRAM MMU hatte ich vor einigen Jahren mal irgendwo als Ersatz für eine Motorola 68xx MMU gesehen. Seither schwirrt der Gedanke einer etwas Erweiterten Version bei mir durch den Kopf. Ist also auch für mich soz. einer der Antriebs Punkte für den neuen Rechner.


    Die 74LS610 hatte 12 bit. 8 habe ich für Adresserweiterungen genutzt, und 3 weitere für:

    - page valid

    - write protect

    - no-execute


    Details siehe hier: http://www.6502.org/users/andre/csa/cpu/index.html


    Da die 6502 aber kein ABORT kennt wird im Fehlerfall die 6502 nur via RDY (geht grundsätzlich damit nur mit CMOS, da writes in NMOS nicht halten) angehalten, und die Auxiliary CPU übernimmt den Bus (siehe hier http://www.6502.org/users/andre/csa/auxcpu/index.html )


    Wäre sicher interressant, das ganze via ABORT und nur einer CPU zu lösen. Bei ABORT müsste man die MMU dann z.B. in einen "Default" Config setzen - entweder per HW (z.B. kernel in top page einblenden) oder einfacher per SW wenn der kernel / top page mit den Vektoren eh immer gemappt ist.

  • Junior Computer ][

    Sieht nach einem spannenden Projekt aus!


    Hier mal ein Beispiel für eine MMU basierend auf fast SRAM - damals als Ersatz für den nicht mehr zu bekommenden 74LS610 gedacht: http://www.6502.org/users/andre/hwinfo/ls610/index.html


    Die Frage bleibt aber, ob man 65816 überhaupt mit einer MMU kombinieren muss. Schliesslich könnte man einzelne Tasks in andere Banks legen (solange sie nicht mit $0100,x auf den Stack zugreifen...) Das OS, sowie die Task-spezifischen Stacks und Zeropages könnten in Bank 0 liegen, nur code/data in den Task-spezifischen Banks. So ähnlich habe ich mir das für meine (bisher nur geplante) Erweiterung von GeckOS mal zurechtgelegt.


    Gruß,

    André

  • GeckOS Multitasking Betriebssystem for 6502

    Und da wir gerade von interruptbaren Schedulern reden....


    System: meine Port für die Original-Maschine CS/A, i.e. PET-Clone mit MMU at $effx, die die 16x4k CPU address pages einzeln aus einem 1M bus address space mappen kann. Also $eff3 mapped dann den Speicher $3xxx der CPU eben in den physikalischen Adressraum.


    Symptom: häufig aber nicht immer hängt sich die Maschine beim Booten auf, und zwar wenn Programme von der Disk geladen werden. In diesem Fall ein Monitor auf der zweiten Konsole und eine Shell auf der ersten Konsole. Heisenbug, ziemlich nervig.


    Den Fehler habe ich genau hier im interrupteten Scheduler gefunden....:



    Hinweis: Jeder Thread hat zwei Bytes in der Zeropage (zth, 6/7), die für ihn reserviert sind, jeder Task ebenso (zta, 4/5), und jedes "environment" (zen, 2/3). Diese müssen natürlich bei jedem Context-Switch umgeschrieben werden. In Systemen wie dem C64 oder PET, die nur ein "Environment" (also im Grunde nur eine zeropage/stack) kann man die dann einfach in die gespeicherten Task-/Thread-Tabellen umkopieren.


    In einem system wie dem CS/A hier mit MMU hat aber jeder Task sein eigenes Environment mit eigenem Stack und zeropage. Da muss das umkopieren darüber erfolgen, dass die Task-spezifische Page woanders eingeblendet wird und die Daten von/nach dort kopiert werden. Hier wird Page 3 ($3xxx, bzw. MMU entry an $eff3) verwendet.


    In obigem Code switcht "settask" auf einen neuen Thread/Task um. Mittendrin kommt ein Interrupt, der mit "memsys" versucht "nochmal" in den kernel zu kommen. Das merkt er auch schnell und macht via devr einen short path.... Allerdings muss er, um das zu merken, den Entry-Counter des Kernel lesen - dazu mappt die Routine den kernel zero-block ($0xxx) auf die CPU page 3 - genau dahin, wo der Scheduler in setthread den zero-block eines Tasks gemappt hat, um dessen zta/zth values umzuschreiben...


    Warum fällt das so spät auf - weil erst die lib6502-basierten Programme diese zta und zth Speicher via die lib6502 implementierung nutzen ....


    Edit: das log-file enthält im Prinzip den kompletten Boot-Prozess, ist ca. 3.6GB groß, und es hat > 2 Tage gebraucht das zu flöhen....!

  • GeckOS Multitasking Betriebssystem for 6502

    Ohne Raffzahn jetzt im einzelnen zu zitieren - am Ende sind wir denke ich gar nicht so weit auseinander.


    Auch bei mir ist der IRQ ein "Sprung in den kernel" eben mit einer eigenen Routine. Das wird im Taskstatus vermerkt ob eben aus dem Interrupt oder aus einem Blocking call oder YIELD. Und wenn der Task wieder dran ist wird entsprechend zurückgesprungen.

    Der "Scheduler" ist fast ein eigener Task, nur läuft er eben im kernel space - aus Effizienzgründen. Der Scheduler ist sogar interruptbar. Wenn ein Interrupt passiert, werden zuerst die Interrupt-Routinen aufgerufen und damit das Interrupt flag gelöscht. Damit kann der kernel ein CLI machen, und in den Scheduler springen. (Ich bin mir allerdings nicht mehr ganz sicher ob in jedem Port, weil ich mich erinnere dass ich im Original-Port einen I/O hatte in dem ich die IRQ Leitung separat lesen konnte und ich nicht mehr weiss ob das genutzt wird)


    Bezgl. Lauffähiger Tasks - da Interrupts nur bedingt in den Scheduler eingreifen können (aktuell) können sie dafür Signale absetzen. Da wird dann der Kontext und Stack des wartenden/interrupteten Tasks entsprechend modifiziert, so dass beim Wiederanlauf erst die Signal-Routine aufgerufen wird, und die dann mit IIRC RTI in den ursprünglichen Code zurückspringt. D.h. ein "waiting for signal" task gilt auch als lauffähig. "waiting for receive" (wie z.B. die Dateisystem-Tasks wenn sie nichts zu tun haben) sind nicht lauffähig, denn sie warten auf einen anderen Task.


    Für IO gibt es zwei Möglichkeiten: mit char-devices via Streams zu kommunizieren, wie z.B. Konsole oder Serial. Alles andere ist asynchron. Typischerweise gibt es einen eigenen Task, der mit RECEIVE auf Aufträge wartet etwas zu tun. Wobei die eigentliche Datenkommunikation auch über Streams abläuft. Der "FSDEV" task übernimmt dabei die Aufgabe, die Devices auf ein Filesystem abzubilden, so dass man Devices wie Dateien ansprechen kann und nicht nur über den DEVCMD kernel call.


    Da der SEND/RECEIVE buffer als eines der letzten Überbleibsel noch an einer fixen Adresse steht ($0200) und die character-weise Übertragung von Dateien via Streams laaaanngggsssaaaammm ist, will ich beides über sog. Buffer und Channel neu umsetzen: https://github.com/fachat/Geck…er/GeckOS-NG-Buffers.adoc