Junior Computer ][

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.

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

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

Quote from 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

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.

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

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

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

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

Du müsste doch auch das Video vom VCFe München von André's Vortrag noch haben.

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

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.

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

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

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

Quote from Shadow-aSc

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

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.

Quote from 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 ) 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.

See ja

Jörg

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