Junior Computer ][

    Mag sein - und v.a., wenn man dann in stromlosen(armen) Zustand verharren kann, ist das bestimmt hin und wieder sehr sinnvoll.

    Ich fand es eher so aus "logischen" Gründen irgendwie "schräg". Die Idee am Interrupt ist ja eigentlich, daß man eben den laufenden Prozess unterbricht und was anderes macht. Nicht, daß der laufende Prozess so eine Art Warteschleife in Form eines einzelnen Befehls ist.

    Das führt dann auch zu der spannenden Frage: was macht so eine CPU eigentlich während sie wartet. Das ist ähnlich rätselhaft, wie der Zustand in dem die Homecomputer so üblicherweise starten - READY und warten auf Eingabe; und das oft mit der besonderen Note, daß alles was passiert eigentlich im Interrupt passiert (Cursor Blinken, Keyabfrage, Time weiterschalten).




    Ich wollte aber nochmal auf den WDC65C02 und was anderes raus - v.a., weil der IC ja doch relativ flott ist

    . https://www.reichelt.de/8-bit-…?CCOUNTRY=445&LANGUAGE=de

    mit 14 MHz.


    Ist der direkt auf den JC2 steckbar ?



    Und dann war da noch die Geschichte mit den illegalen Opcodes bzw. den erweiterten - für den WDC65C02 sagt WikiP


    Zitat

    WDC W65C02S; Rockwell R65C02, R65C102, R65C112; GTE/CMD G65SC02, G65SC102, G65SC112[60][61][62][63]

    • Entwickelt von Western Design Center (WDC)
    • CMOS-Mikroprozessoren, kompatibel mit MCS6502
    • Alle Mikroprozessoren weisen im Vergleich zum MCS6502 zusätzlich die Befehle BRA, PHX, PHY, PLX, PLY, STZ, TRB, TSB auf
    • Bei den Mikroprozessoren der R65C00-Familie und dem WDC W65C02S kommen noch die Befehle BBR, BBS, RMB, SMB hinzu
    • Allein der W65C02S besitzt darüber hinaus die beiden Befehle WAI und STP
    • Zusätzliche Adressierungsmodi (indirekte Adressierung in der Page null; indirekte indizierte Adressierung beim JMP-Befehl)
    • Keine illegalen Opcodes (jeder illegale Opcode gleicht in seiner Wirkung einem oder mehreren aufeinander folgenden NOP-Befehlen)
    • ...


    es gibt also die normalen illegalen NICHT beim WDC65C02, dafür aber die oben schon angesprochenen.


    Nun sind die aber eigentlich fast (?) alle mit anderen Anweisungen ersetzbar. Und damit, je nach dem Assembler, der benutzt wird, wahrscheinlich auch einfach über Makros ersetzbar, wenn man sie benutzen will. Nur daß der Code für den 6502 dann evtl. bißchen größer und evtl langsamer wird. Macht natürlich eigentlich nur Sinn, wenn der 14 MHz Chip sich überhaupt mit dem Board verträgt.


    Wobei: es natürlich gerad im "BIOS" / "OS" schon schön ist, wenn das auf allen Chips direkt in schnellster Variante läuft, was also dann schon heißt, daß man es so macht, wie es jetzt passiert, also daß die 6502 als "Normalstandard" genommen wird und dafür optimiert (und nicht dort dann auch noch der langsamere Code (wegen dem Makro) läuft).



    Interessanter ist aber evtl die Geschichte mit den illegalen Opcodes, die ja anscheinend alle anderen Abkömmlinge vom 6502 doch noch zu haben scheinen. Und da die mittlerweile auch bekannt und beschrieben sind würd ja eigentlich nichts dagegen sprechen, die auch zumindest so zu unterstützen, daß sie frei verwendbar bleiben.


    Nach (ebenfalls WikiP)


    Zitat
    ...
    $0F ASO $C000 ("ASL, ORA") Führt den Befehl ASL mit dem Speicherinhalt an der Adresse C000<sub>16</sub> aus, anschließend wird eine ODER-Verknüpfung des Akkumulators mit dem neuen Speicherinhalt durchgeführt und das Ergebnis im Akkumulator gespeichert.


    ...


    $EF INS $C007 ("INC, SBC") Erhöht den Wert an der Speicheradresse C007<sub>16</sub> um eins und subtrahiert anschließend den neuen Speicherinhalt vom Inhalt des Akkumulators (zusätzlich um eins, falls das Carry-Flag den Wert null besitzt).


    Es wäre also evtl günstig, wenn man das ein bißchen im Hinterkopf hat, daß potentielle illegale Opcodes anscheinend die Adressen $C000 bis $C007 benutzen. Man sich also evtl bemühen sollte, da nicht gerade einen Grafikstart oder sowas hinzulegen, sondern den Bereich freizuhalten, bei allem was noch an Software kommt.

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

    Ein normaler Interrupt unterbricht ein laufendes Programm. Also zum bsp. durch einen Timer Interrupt oder ein anderes unerwartetes Ereignis.

    Manchmal ist es aber besser, einen Prozess vollständig zu blockieren um auf ein einzelnes Gerät zu warten. Eben z.B. auf eine Floppy, oder auf das Drücken einer Taste. Dann ist Idle Waiting mit einem WAI, HLT o.ä. aber wesentlich besser als das pollen eines Flags, da der Prozessor mit diesen Befehlen auch meist weniger Strom benötigt. Außerdem kann es ja sein, dass das zu erwartende Signal sehr kurz ist. Dann hast du das Problem, das Hans vorher angesprochen hatte. Die Trigger Schleife muss dann sehr schnell durchlaufen werden, um das Signal nicht zu verpassen. Mit WAI ist ein Verpassen nicht möglich, da ein Interrupt ja Flanken getriggert ist und die Länge des Signals dann nicht mehr relevant ist. Es geht dann auch direkt nach dem WAI Befehl weiter, ohne sichern der Rücksprungadresse, Register und Status und vice versa. Der Overhead ist also auch wesentlich kleiner.

    Einmal editiert, zuletzt von 2ee ()

    Zitat von ThoralfAsmussen

    Mag sein - und v.a., wenn man dann in stromlosen(armen) Zustand verharren kann, ist das bestimmt hin und wieder sehr sinnvoll.

    Ich fand es eher so aus "logischen" Gründen irgendwie "schräg".

    Schräg? Weis nicht, das ganze ist viel älter als alle Microprozessoren zusammen. Schon die allerersten Computer (Zuse etc.) hatten einen Halt-Befehl. Weil warum soll die CPU arbeiten und Strom fressen wenn es nix zu tun gibt? Bei der /370 z.B. gibts an der Konsole sogar ein extra Lamperl das leuchtet wenn die CPU auf dem IDLE Befehl steht und nix tut. Wenn das leuchtet dann gibts zwei Gründe: es gibt ix zu tun, oder alle Prozesse warten auf die langsamen Platten :))


    Und der IDLE funktioniert praktisch genauso wie der WAI der 65C02:


    - Die CPU geht in einen stromsparenden Wartezustand.

    - Wenn ein Interrupt kommt wird er bearbeitet

    - Wenn der fertig ist, dann gehts hinter dem IDEL Befehl weiter.

    - und das OS schaut was es so alles zu tun gibt als ergebnis von dem Interrupt.


    Und da liegt dann die ganze Eleganz: So ein Interrupt war ja in der Regel eine I/O oder ein Timer. Wars ein Timer, so muss man jetzt mal nachschauen ob die erreichte Zeit irgend einen Task aufweckt oder so. Wars eine I/O, dann will garantiert ebenfalls irgend ein Task aufgeweckt werden - sei es weil die Daten geschrieben wurden und nun die Puffer frei sind, oder weil die angeforderten Daten geliefert wurden. In beiden Fällen will das Userprogramm weiterarbeiten. Und damit das kann muss das Betriebssystem jetzt nachschauen wer das ist und ob der das darf und so weiter.


    So wein IDLE oder WAI ist der zentrale Punkt um den rum das ganze Scheduling aufgebaut wird. Alles andere ist Kinderkram.

    Ich hatte sogar an einem Z80-Pin (ich weiss jetzt nicht welcher) ein mA-Meter über einen Tiefpass dran. Das hat dann die CPU Auslastung von 0%-100% angezeigt (bei MP/M war tatsächlich der "Idle" Prozess ein "HALT")

    Zitat von ThoralfAsmussen

    Ich wollte aber nochmal auf den WDC65C02 und was anderes raus - v.a., weil der IC ja doch relativ flott ist

    . https://www.reichelt.de/8-bit-…?CCOUNTRY=445&LANGUAGE=de

    mit 14 MHz.


    Ist der direkt auf den JC2 steckbar ?

    Der 65C02 kann (auch in der 14MHz) Version völlig Problemlos im Junior ][ eingesetzt werden. Einer Takterhöhung würde im Prinzip auch nichts im Wege stehen, wenn denn alle Support Chips auch höher getaktet werden könnten. Die 65C22er auf dem IO Board können heute von WDC ebenfalls mit 14MHz geordert werden. Problematisch sind aber der 6532 RIOT und der 6551 UART. Eventuell gibt es die in 4MHz Ausführung, aber dann dürfte auch Schluss sein, weil die nicht mehr produziert werden.

    Das Junior ][ BIOS hat nur an einer Stelle einen Delay Routine, die nicht über einen Timer gelöst ist. Dies ist die Time Out Routine im XModem Code, den ich von Deryl Rictor übernommen habe. Hier müsste man also nacharbeiten. Ein Takt von 2MHz sollte aber auch ohne Änderung möglich sein.


    Zitat von ThoralfAsmussen

    Und dann war da noch die Geschichte mit den illegalen Opcodes bzw. den erweiterten - für den WDC65C02

    Na ja, illegale Opcodes sollte man generell nicht benutzen, deshalb sind sie ja illegal. Es sind ja eigentlich auch keine Befehle die du da aufgelistet hast, sondern Glitches die zufälligerweise entstehen, weil das Leitwerk des Prozessors nicht vollständig ausgearbeitet wurde. Bei einem Decoder Design muss ich halt nicht nur die gewünschten Codes durchleiten, sondern auch alle anderen ausschließen. Das wurde beim ursprünglichen 6502 Design vermutlich aus Kostengründen (?) nicht gemacht, da es nochmal eine Menge zusätzlicher Gatter bedeutet hätte. Der W65C02 nutzt ja auch noch nicht alle möglichen 256 Befehle aus, hat aber wahrscheinlich einen vollständigen Befehlsdecoder.


    Zitat von ThoralfAsmussen

    Es wäre also evtl günstig, wenn man das ein bißchen im Hinterkopf hat, daß potentielle illegale Opcodes anscheinend die Adressen $C000 bis $C007 benutzen. Man sich also evtl bemühen sollte, da nicht gerade einen Grafikstart oder sowas hinzulegen, sondern den Bereich freizuhalten, bei allem was noch an Software kommt.

    Ein nicht Belegen von Speicherbereichen, nur weil dort eventuell ein nicht dokumentierter OP was ändern könnte ist für einen Hobby-Retro-Rechner dann doch etwas zu viel des Guten. Wenn es um Sicherheitsbedenken bei neuen Prozessoren ginge, dann wäre ich da voll bei dir. Denn dann wäre ein solches Verhalten möglicherweise (ganz sicher!) ein offenes Scheunentor für Schadcode. Aber so, ist es für mich nur eine witzige Randnotiz, was der Prozessor noch so alles anstellen könnte.


    Edit: Nochmal zum WAI.


    Wenn du ein Multitasking OS hast, wird der Scheduler normalerwiese als Interrupt-Routine - angestoßen durch einen Timer IRQ - implementiert. Zum Auswählen des nächsten Tasks wird also der Scheduler geweckt, der nächste Task gewählt der rechenbereit ist und die CPU an diesen Task durch setzen der Rücksprungadresse aus der IRQ Routine durch ein RTI ( ReTurn from Interrupt) übergeben. Falls es aber keinen rechenbereiten Task gibt, wird und muss der Idle-Task ausgewählt werden. Dieser ist meist so aufgebaut

    Code
    IDLE: WAI
      JMP  IDLE

    d.h. der Idle-Task legt den Rechner schlafen, bis der nächste Timer Interrupt (oder auch irgendein Geräte Interrupt) ausgelöst wird. Dieser bringt dann wieder den Scheduler ins Spiel und der Vorgang beginnt von vorne. Der Idle-Taks ist wichtig, um das System am Laufen zu halten. Dazu würde ich dir dann aber Literatur von bevorzugt Andrew Tannenbaum empfehlen.

    Einmal editiert, zuletzt von 2ee ()

    Gefällt mir 3
    Zitat von 2ee

    Ein nicht Belegen von Speicherbereichen, nur weil dort eventuell ein nicht dokumentierter OP was ändern könnte ist für einen Hobby-Retro-Rechner dann doch etwas zu viel des Guten. Wenn es um Sicherheitsbedenken bei neuen Prozessoren ginge, dann wäre ich da voll bei dir. Denn dann wäre ein solches Verhalten möglicherweise (ganz sicher!) ein offenes Scheunentor für Schadcode. Aber so, ist es für mich nur eine witzige Randnotiz, was der Prozessor noch so alles anstellen könnte.

    Oben sind es ja nur Beispiele wie $EF $C007 (3 Byte Befehl!) welche dann eben die Adresse $C007 betreffen...

    Das wird sicher mit jeder Adresse funktionieren ;)

    Zitat von Reinhard

    Das wird sicher mit jeder Adresse funktionieren ;)

    Genau. Und schon hab ich aus meinem schönen Rechner einen Türstopper gemacht, weil ich Angst habe ihn zu benutzen. 8o


    Edit: Und der gute Mann heißt natürlich Andrew S. Tanenbaum und nicht Tannenbaum.

    Zitat von 2ee

    Edit: Nochmal zum WAI.


    Wenn du ein Multitasking OS hast, wird der Scheduler normalerwiese als Interrupt-Routine - angestoßen durch einen Timer IRQ - implementiert. Zum Auswählen des nächsten Tasks wird also der Scheduler geweckt, der nächste Task gewählt der rechenbereit ist und die CPU an diesen Task durch setzen der Rücksprungadresse aus der IRQ Routine durch ein RTI ( ReTurn from Interrupt) übergeben. Falls es aber keinen rechenbereiten Task gibt, wird und muss der Idle-Task ausgewählt werden.

    Erzähl dass mal besser nicht den Mainframe-Leuten. Scheduler im Interrupt ist eine potentielle potentielle Fehlerquelle und eine mögliche Quelle richtig ekeliger Performanceprobleme. Interrupts sollen so kurz wie möglich sein und nur die Arbeit machen die direkt für die Hardwarebedienung nötig sind. Alles andere, ist außerhalb zu erledigen. Und das ist was der Code nach dem WAI macht. Einen Idle Task basteln ist zwar recht hübsch aus theoretischer Sicht und um gut um Studenten im ersten Semester nicht zu verwirren, in der Praxis isses aber weniger gut.

    Zitat von Raffzahn

    Erzähl dass mal besser nicht den Mainframe-Leuten. Scheduler im Interrupt ist eine potentielle potentielle Fehlerquelle und eine mögliche Quelle richtig ekeliger Performanceprobleme. Interrupts sollen so kurz wie möglich sein und nur die Arbeit machen die direkt für die Hardwarebedienung nötig sind.

    Ein einigermaßen gut konstruiertes Multi-Task OS hat ja auch nicht seinen Application Process Scheduler in der Interrupt Routine. Das wäre natürlich völliger Schwachsinn. Der Kernel Task Manager wählt aus, welcher der Kernel Tasks - also Memory Manager, Device Manager, etc. oder eben der Application Process Scheduler - Rechenzeit bekommt und braucht dazu nur ein Bit Feld abfragen und ein paar Pointer umschalten und kann dann die INT-Routine wieder verlassen. Da gibt es keine Performance Probleme weil man dazu nur ein paar Befehle benötigt. Das High Level Switching macht dann der APS außerhalb der Interrupt Routine. Dass es auch andere Möglichkeiten gibt ist unbestritten, und wie das bei einem Mainframe gehandhabt wird, weiß ich nicht...


    Zitat von Raffzahn

    Einen Idle Task basteln ist zwar recht hübsch aus theoretischer Sicht und um gut um Studenten im ersten Semester nicht zu verwirren, in der Praxis isses aber weniger gut.

    Sorry, aber ohne Idle Task zu arbeiten ist, wie verkettete Listen ohne Guard, nur mit NIL (NULL) Pointer abzuschließen. Dann wundern sich diese schlauen Konstrukteure wenn ihre Softwarebastelei dann dauernd abschmiert und schöne Sicherheitslücken reißt. Mag sein, dass man das mal irgendwann in grauer IT-Steinzeit so gemacht hat, aber mir ist es lieber die Leute haben da im ersten Semester aufgepasst und wenden das gelernte in der Praxis an.

    Entschuldige, aber der Rückpass musste einfach sein.


    Ansonsten würde ich vorschlagen, solche Themen auch in einem anderen Thread weiter zu diskutieren und hier wieder zum Junior ][ zurück zu kommen.

    Yep ... war aber durchaus interessant der kleine Ausflug ins Abseitige.


    Von diesem Tanenbaum steht sogar was hier rum, aber das war auch recht langweilig ... und ziemlich dick.


    Die $C000 - $C007 sind wahrscheinlich wirklich so gemeint, daß das nur Beispiele sind. Hatte ich wohl dezent falsch gedeutet. Trotzdem waren ein paar der "illegalen" Kommandos irgendwie schon interessant. Aber sie sind ja tatsächlich auch in den neuen Ausgaben der Chips nicht mehr vorhanden und werden automatisch durhc NOPs ersetzt.

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

    Gefällt mir 2

    ... OS, 6502, hierzu hab ich mir lezthin einen interessanten Youtube angeschaut.

    GeckOS: a Unix-like 6502 operating system | VCFMW 2019

    https://m.youtube.com/watch?v=jtlAOdJmeDI


    Aber hierfür bitte gleich einen extra Thread aufmachen, damit man hier nicht zu stark abschweift.

    Jetzt hab ich mich erst mal mit dem Floppy Drive Motor On/Off Problem beschäftigt.


    Der Motor darf ja nicht dauern laufen, sollte aber auch nicht zu früh wieder abgeschaltet werden, da man sonst wieder warten muss, bis er vollständig hochgefahren ist. Das könnte man jetzt wunderbar über einen Timer lösen. Allerdings kann ich nicht davon ausgehen, dass eine IO Karte mit VIA (und somit Timer) vorhanden ist. Der zwar immer vorhandene Timer im RIOT ist leider ungeeignet, da er viel zu kurz läuft und auch nicht repetierend ist. Außerdem wollte ich jetzt natürlich auch keine zusätzliche VIA auf dem Floppy Controller verbauen.


    Ich hab das Problem nun mit je einem retriggerbaren Monoflop pro Laufwerk gelöst, welches nach drei Sekunden abläuft und dann einen Interrupt auslöst. Beim Aufruf einer Read-. Write- oder Seek- Routine, wird das Monoflop durch lesen oder schreiben auf eine MOTOREN1/2 Port-Adresse neu gestartet, so dass der Motor-Off Interrupt dann wieder für weitere drei Sekunden verzögert wird.

    Wenn der IRQ ausgelöst wurde, muss dann nur noch durch Lesen meines pseudo Data Option Registers (das DOR ist ja im Normalfall nur Write Only) der "gewünschte" neue Zustand der Motoren ausgelesen, mit $34 ausmaskiert und in das echte DOR zurückgeschrieben werden. Dann wird der Interrupt durch lesen oder schreiben auf eine MOTORRES1/2 Port-Adresse wieder gelöscht und fertig.


    Der Hardwareaufwand hält sich ebenfalls in Grenzen, da im verwendeten 74LS123 zwei Monoflops verbaut sind. Zusätzlich braucht man noch zwei JK Flipflops (74LS112) und nochmals ein GAL16V8, was ich aber für den Graphics Controller so oder so noch benötigt hätte.


    Mittlerweile hab ich auch rausgefunden, wie man den FDC nach dem Lesen eines Sektors sauber abwürgt, damit er nicht automatisch den nächsten Sektor liest und falsche Fehlermeldungen zurückgibt.Es geht also voran.


    Jetzt geht es bei mir ab Samstag nochmal für eine Woche in den Urlaub und am 30.9. und 1.10. bin ich dann in Dietzenbach auf der CC2023. Ich hoffe, da kann ich endlich mal wieder Antikythera , joshy , fachat und Shadow-aSc und natürlich viele andere wieder sehen. Freu mich schon riesig.


    Übrigens: Auch wenn ich mich diesbezüglich noch nicht wirklich geäußert habe. Ich bin immer mal wieder dabei, die Fortschritte von Dietrich s CPM-65 Port auf dem Junior ][ zu verfolgen und auszuprobieren. Ich bin echt begeistert, was da bereits schon alles läuft, ohne das Dietrich einen Junior ][ sein Eigen nennen kann. Super Arbeit! :):thumbup::thumbup: Und ebenfalls einen ganz großen Dank an NorbertJ , der statt meiner bisher die ganzen Test gemacht hat, obwohl er gerade (sehr) viel um die Ohren hat. :anbet:



    Ich hoffe, ihr beide könnt mir verzeihen, dass ich gerade nicht besonders in dem Projekt involviert bin und mich nur um andere Dinge wie den Floppy Controller kümmere. ;(

    Zitat von klaly

    ... OS, 6502, hierzu hab ich mir lezthin einen interessanten Youtube angeschaut.

    GeckOS: a Unix-like 6502 operating system | VCFMW 2019

    https://m.youtube.com/watch?v=jtlAOdJmeDI


    Aber hierfür bitte gleich einen extra Thread aufmachen, damit man hier nicht zu stark abschweift.

    Bitteschön: GeckOS Multitasking Betriebssystem for 6502

    Zitat von 2ee

    Der zwar immer vorhandene Timer im RIOT ist leider ungeeignet, da er viel zu kurz läuft und auch nicht repetierend ist.


    Der Hardwareaufwand hält sich ebenfalls in Grenzen, da im verwendeten 74LS123 zwei Monoflops verbaut sind. Zusätzlich braucht man noch zwei JK Flipflops (74LS112) und nochmals ein GAL16V8, was ich aber für den Graphics Controller so oder so noch benötigt hätte.

    Bei 1 MHz läuft er rund 0,25s, das ist jetzt nicht gerade kurz. 12 mal wieder angetriggert und DU hast deine 3 Sekunden mit einer reinen Softwarelösung, Null Hardware. Und nebenbei kann der auch gleich ne Echtzeituhr und das Gerüst für eine generische Timerliste liefern:))


    Oder halt gleich umgekehrt als 4 Hz Timer selbige Warteschlange betreiben und die Floppy-routine hängt sich dort ein und wird nach12 ticks benachrichtigt. Wenige Befehle, großer fortschritt.

    Zitat von 2ee

    Der Hardwareaufwand hält sich ebenfalls in Grenzen, da im verwendeten 74LS123 zwei Monoflops verbaut sind. Zusätzlich braucht man noch zwei JK Flipflops (74LS112) und nochmals ein GAL16V8, was ich aber für den Graphics Controller so oder so noch benötigt hätte.

    Sagt der Mann dem 2 TTL und ein bisschen Glue zu viel sind um high speed DMA zu machen :))

    Zitat von Raffzahn

    Bei 1 MHz läuft er rund 0,25s, das ist jetzt nicht gerade kurz. 12 mal wieder angetriggert und DU hast deine 3 Sekunden mit einer reinen Softwarelösung, Null Hardware. Und nebenbei kann der auch gleich ne Echtzeituhr und das Gerüst für eine generische Timerliste liefern:))


    Klingt schon wirklich eleganter - aber leider zerreißt es das dann auch als Erstes, wenn doch mal jemand den 14MHz WDC 65C02 probieren will. Oder den - habe ich neulich mal "gelernt" - Nachbau namens 65f02 , als FPGA mit 100 MHz. (sehr interessantes Teil)

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

    Zitat von Raffzahn

    Sagt der Mann dem 2 TTL und ein bisschen Glue zu viel sind um high speed DMA zu machen

    Hmm, hab ich zwar nie gesagt - kannst du weiter oben auch nochmals nachlesen - aber lass mal gut sein... ich bin jetzt nicht wegen anderer Meinungen bzgl. meiner Entwicklungsentscheidungen gleich auf Krawall gebürstet. :)

    Zitat von 2ee
    Zitat von Raffzahn

    Sagt der Mann dem 2 TTL und ein bisschen Glue zu viel sind um high speed DMA zu machen

    Hmm, hab ich zwar nie gesagt - kannst du weiter oben auch nochmals nachlesen - aber lass mal gut sein... ich bin jetzt nicht wegen anderer Meinungen bzgl. meiner Entwicklungsentscheidungen gleich auf Krawall gebürstet. :)


    Wer redet denn von Krawall?


    Ich bin einfach erstaunt über den hohen Hardwareaufwand für was was man auch ohne kann. Auch mit 6532.


    :wegmuss:

    Zitat von ThoralfAsmussen

    aber leider zerreißt es das dann auch als Erstes, wenn doch mal jemand den 14MHz WDC 65C02 probieren will

    wie gesagt, den RIOT würde es mit 14 MHz meines Wissens nach sowieso nicht geben und die ACIA fällt auch durch. Das Experiment wäre also vermutlich zum Scheitern verurteilt. Beim nächsten Rechner dann vielleicht. Der würde aber sowieso von mir eine 65816 spendiert bekommen - auch wenn der wiederum nicht besonders von Raffzahn geschätzt wird, ich finde die CPU toll...so hat halt jeder seine Vorlieben.

    Zitat von ThoralfAsmussen
    Zitat von Raffzahn

    Bei 1 MHz läuft er rund 0,25s, das ist jetzt nicht gerade kurz. 12 mal wieder angetriggert und DU hast deine 3 Sekunden mit einer reinen Softwarelösung, Null Hardware. Und nebenbei kann der auch gleich ne Echtzeituhr und das Gerüst für eine generische Timerliste liefern:))


    Klingt schon wirklich eleganter - aber leider zerreißt es das dann auch als Erstes, wenn doch mal jemand den 14MHz WDC 65C02 probieren will. Oder den - habe ich neulich mal "gelernt" - Nachbau namens 65f02 , als FPGA mit 100 MHz. (sehr interessantes Teil)

    Öh, die Systemlast bleibt die Gleiche, Nicht?


    Die CPU ist 14 mal schneller und muss dann halt 56 interrupts pro Sekunde verkraften. 3 Sekunden gehen dann immer noch gut in ein Byte :)))


    Ok, bei 100x schneller brauchts dann halt noch einen zweiten DEC und einen BNE drumherum um 16 bit zu handhaben. Wobei, hat die Emulation eigentlich auch eine 6532? Und wenn ja, warum den nicht aufbohren, weil ist ja eh nur FPGA:))

    Zitat von Raffzahn

    Wer redet denn von Krawall?


    Ich bin einfach erstaunt über den hohen Hardwareaufwand für was was man auch ohne kann. Auch mit 6532.

    Ich wollte damit nur zum Ausdruck bringen, dass ich mich jetzt nicht darüber streiten möchte, ob ich mich so ausgedrückt habe.


    Das ich mich bei den Timern letztlich für eine Hardwarelösung entschieden habe, liegt natürlich auch daran, dass ich nicht nochmals das ganze BIOS und im speziellen den Interrupt-Handler umkrempeln möchte. Dann funktioniert wieder möglicherweise der Timer für die Datasettenaufzeichnung etc. nicht mehr. Ich wollte das BIOS jetzt einfach langsam als abgeschlossen sehen, um auch mal wieder an anderen Dingen weitermachen zu können.

    Die zwei zusätzlichen Bausteinchen auf den Floppy Controller waren es mir da dann wert. Und wie gesagt, ich hätte sowieso noch einen zweiten GAL eingesetzt um das Decoding zu vereinfachen. Sieht im Schaltplan jedenfalls schlimmer aus als es dann nacher ist :) .

    Zitat von 2ee

    Jetzt geht es bei mir ab Samstag nochmal für eine Woche in den Urlaub und am 30.9. und 1.10. bin ich dann in Dietzenbach auf der CC2023. Ich hoffe, da kann ich endlich mal wieder Antikythera , joshy , fachat und Shadow-aSc und natürlich viele andere wieder sehen. Freu mich schon riesig.

    aber SICHSCHER doch!


    nur: mein Junior- II befindet sich immer noch im Status: "mal guggen, wann ich damit anfang :tüdeldü: "

    ich bin signifikant genug:razz:

    Gefällt mir 1
    Zitat von 2ee

    Übrigens: Auch wenn ich mich diesbezüglich noch nicht wirklich geäußert habe. Ich bin immer mal wieder dabei, die Fortschritte von Dietrich s CPM-65 Port auf dem Junior ][ zu verfolgen und auszuprobieren. Ich bin echt begeistert, was da bereits schon alles läuft, ohne das Dietrich einen Junior ][ sein Eigen nennen kann. Super Arbeit! :) :thumbup: :thumbup: Und ebenfalls einen ganz großen Dank an NorbertJ , der statt meiner bisher die ganzen Test gemacht hat, obwohl er gerade (sehr) viel um die Ohren hat. :anbet:

    2ee Das geht runter wie Öl. Wir sind da auf einem guten Weg. Eine kleine Hürde bleibt noch, aber das knacken wir auch noch. 😇


    Dietrich

    Meine Computer: Elektor Junior, EPSON HX-20, Robotron PC1715, Poly-Computer 880, Schneider CPC464, APPLE II+, VIKTOR V386PX

    Mein Betriebssystem: CPM-65

    Gefällt mir 1
    Zitat von Shadow-aSc

    nur: mein Junior- II befindet sich immer noch im Status: "mal guggen, wann ich damit anfang :tüdeldü: "

    Das ist mir ziemlich Wurscht :) . Ich freu mich trotzdem, dich auf der CC zu sehen. Zumal du auf dem VCFe so schnell weg warst, dass ich mich nicht mal verabschieden konnte.


    Zitat von Dietrich

    Das geht runter wie Öl. Wir sind da auf einem guten Weg. Eine kleine Hürde bleibt noch, aber das knacken wir auch noch. 😇

    Ehre wem Ehre gebührt.

    Weil mich klaly bzgl. der Zukunft des Junior ][ und eines eventuellen Nachfolgers gerade befragt hat, hier mal meine Aussichten:


    Junior Computer ][


    Die Floppy/Graphics Controller Karte wird von meiner Seite aus wahrscheinlich die letzte Hardware Erweiterung für den Junior ][ sein. Mit einer Fertigstellung rechne ich auf alle Fälle bis Ende des Jahres. Das heißt aber nicht, dass ich dann das Interesse an dem Rechner verlieren werde. Ich denke nur, die Möglichkeiten der Erweiterung sind dann erst mal soweit ausgereizt.

    Bei der Software wird von meiner Seite natürlich noch am M/OS 65 weitergeschraubt (bzw. erst mal richtig angefangen). Das soll aber auch für den tatsächlich bereits angedachten neuen Rechner ebenso funktionieren.


    Neue Hardware


    Den Entschluss einen neuen Rechner zu bauen, der dann die alten Zöpfe abschneidet (also definitiv nicht Junior Computer I / ][ kompatibel sein wird) schlummert schon lange in mir.

    Da ich (leider?!) mit der Z80 CPU nicht viel anfangen kann - auch wenn sie ein paar tolle Features bietet - bleibe ich beim 6502, bzw. bei dessen Nachfolger dem 65816. Dieser bietet durch seinen 24 Bit Adressbus die Möglichkeit 16MB Speicher anzusprechen - wenn auch durch eine etwas krude Bankswitching Methode via eines Bank Register. Dafür kann er dann aber auch Long Jumps im ganzen Adressraum ausführen. Ansonsten bietet er alles, was die 65C02 auch kann, nur halt an einigen Stellen (so finde ich) a Muggesäckele ( = ein wenig : Anmerkung des Übersetzers 8o ) mehr. Die bisher geplante Hardware hier im Einzelnen:


    CPU: 65816 mit 4 bis 8 MHz (14MHz wird dann schon wegen des Platinenlayouts vermutlich schon schwieriger)

    Speicher on Board bis 8 MB statisches RAM (natürlich extern auf 16MB erweiterbar)

    Paging MMU

    Priorisierte Interrupts

    DMA

    8 Erweiterungsslots

    Grafik Controller (V9938)

    Floppy Controller (WD37C65C)

    SD-Karte

    Serielle RS232 Schnittstelle

    Parallele Schnittstelle

    SPI und I2C Schnittstellen

    Echtzeituhr

    Sound

    PS/2 Tastatur (evtl. auch Maus)


    Vieles davon werde ich ähnlich dem, was sich auf dem Junior ][ tummelt übernehmen.

    Beim Speicher Management möchte ich aber andere Wege gehen.

    Die geplante MMU soll aus einem schnellen S-RAM (für die Seitentabellen) und entsprechender Glue-Logik aufgebaut werden, die dann sicherlich in einem PLA sitzen wird. Über die MMU werden dann bis zu 256 per Hardware selektierte Tasks möglich sein. Sprich jeder Task (bzw. Prozess) bekommt seinen Speicher inkl. Stack und Zero Page über die MMU als n x 4KB zugewiesen und über ein Task Register kann dann der Adressbereich auf den Bus gelegt werden. So ist dann ein schnelles Taskswitching möglich. Ob 256 Tasks sinvoll sind ist erst mal dahingestellt. Mehr braucht man sicherlich nicht, weniger wäre auch möglich, also warum nicht 256.

    Für ein eventuelles zusätzliches Multithreading hatte ich noch überlegt, einen weiteren 64KB Speicher als Stack-Pool für zusätzlich 256 Threads mit einzubauen. Diese 256 Thread liegen dann also soz. in diesem Pool aus dem sie dann von den Prozessen angefordert werden können, bis dieser leer ist. Also ein Prozess könnte auch alle 256 Threads nutzen, oder einer 20 und ein anderer die restlichen 236...

    Hintergrund ist ja, das der 6502 nur einen 256 Byte großen Stack nutzen kann. Die 65816 macht das schon besser, und kann in den untersten 64KB mehrere Stacks (á 256Bytes) verteilen. Auch das wäre eine Möglichkeit vereinfachter Multithreading zu nutzen. Allerdings wird die unterste 64KB Page von der CPU besonders behandelt (Interrupt Handler etc.), so dass es eigentlich Sinn macht, diese für den Betriebssystemkern zu reservieren. Mal schauen. Das ist alles noch sehr Vage.

    Für die Interrupts bietet die 65816 (wie auch die 65C02) das Schmankerl des VP Signals, welches für Vektor Pull steht, und dann ausgelöst wird, wenn die CPU einen Interrupt Vektor aus dem Speicher liest. Damit ist es dann Möglich bei vorher bereits priorisierten Interrupts (z.B. über einen 74148 8 zu 3 Prioritätsdekoder) den Interruptvektor dann gleich auf eine andere Adresse umzuleiten, sprich wie eine Interrupt Tabelle in den x86 Prozessoren zu nutzen.


    Ich werde wie von Klaus vorgeschlagen auch mal einen Thread für den neuen Rechner aufmachen und gerne Vorschläge und Anregungen entgegennehmen.


    Tja und dann noch der Name. Es wird definitiv nicht Junior Computer III lauten (diese Namenserweiterung hat auch bei Apple ja bekanntlich nur Unglück gebracht). Da ich ein großer Fan des BBC Micro (the Beep) bin, und das Australische Gegenstück dazu der MicroBee ist (was ich absolut klasse finde), habe ich jetzt mal den Namen


    aamoo (vielleicht dann auch aaMoo geschrieben)


    gewählt, was in der Sprache der Cree Indianer eben das Wort für Biene ist. Bis auf weiteres wird das also erst mal (zumindest) der Arbeitsname sein.


    Das also erst mal zum Ausblick. Wir sind dann doch bereits ab heute Abend im Urlaub. Daher werde ich erst ab dem 4.10. wieder was am FDC weiterarbeiten, den Tread eröffnen usw.


    Machts erst mal gut und evtl. sieht man sich auf der CC2023. 8-)


    See ja


    Jörg

    Jörg, das sind wirklich faszinierende Zukunftsaussichten.

    Ich kann Dir schon mal vor ab sagen, auch wenn es noch viele Monde dauern wird:

    einen 65816 basierenden Computer aus Deiner Feder werde ich definitiv nachbauen.


    Natürlich auch alles was es noch zum Junior ][ geben wird - aber das versteht sich ja von selber :thumbup:


    Danke für Deine Bemühungen und einen erholsamen Urlaub :prost:

    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é

    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.

    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.