Interessante Idee MMU faults mit einem zweiten Prozessor zu bearbeiten.
Ich hatte jetzt tatsächlich vorgehabt, Abort bei einem Page fault oder einer Zugriffs Verweigerung zu verwenden, schon allein deshalb weil der aktuelle Befehl dann wiederholt werden kann.
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.
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
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.
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.
Wahrscheinlich macht GeckOS aus euer beider Sicht Mist...
Ne, ne, GeckOS ist super 
.Ich finde es wirklich erstaunlich, was du da auf einer so beschränkten CPU (bzgl. vor allem natürlich Stack) fertiggebracht hast. Mein erstes Multitask System lief auf einem 286er und hatte auch beim Speicher natürlich viel mehr Resourcen. Deshalb kann ich da nur den Hut ziehen.
Ausserdem sind Hobby System nie Mist. Die sollen schließlich Spass machen und den Horizont des Erbauers erweitern. Und ich denke, du bist mit GeckOS da an Machbarkeitsgrenzen gestoßen, die sich Chuck Peddle und Bill Mensch bei der 6502 vermutlich garnicht vorstellen konnten.
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 .
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.
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.
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. 
Du müsste doch auch das Video vom VCFe München von André's Vortrag noch haben.
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...
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.
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.
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.
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.
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 IDLEd.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.
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.
Ist super nützlich beim Warten auf externe Ereignisse. Bei Microcontrollern gibt es gerne mal ein SLEEP, bei dem sich der Controller dann in einen Stromsparmodus legen kann und durch einen Interrupt wieder aufgeweckt wird.
PHX : push X register on stack
PLX : pull X register from stack
BRA : branch always
STZ : store zero
WAI : wait for interrupt
PHY und PLY gibt es natürlich auch.
STZ ersetzt ein LDA #0 mit folgenden STA adr und ist ziemlich oft nützlich
Na das wär was auf dass Entwickler damals am allerersten verzichtet hätten wenn sie ein Subsystem einsetzen - weil selbiges kann dann gleich den low level Teil dann am besten gleich selbst übernehmen. Weil wenn schon einen Prozessor dazwischen, dann soll er auch Arbeit abnehmen. Das wär für uns damals eher der Grund gewesen einen Controller einzusetzen (wenn es den denn gegeben hätte) als der DMA. Floppyinterface mit logischer Schnittstelle macht die Anwendungssoftware viel einfacher. Das zahlt sich bei der späteren Entwicklung vielfach aus.
Ich hatte ja schon weiter oben geschrieben, dass ein evtl. eingesetzter uC dann durchaus Funktionen wie LBA in CHS Umwandlung und formatieren einer ganzen Floppy statt nur eines Tracks übernehmen kann. Aber das Stack-In/Out Interface kann man ja ohne weiteres beibehalten. Die Ergebnisphase kann man natürlich auch etwas abkürzen und dann gleich ein einzelnes Result Byte zurückgeben.
However...hier wäre es ja nicht drum gegangen den ganzen Rechner durch einen Microcontroller zu ersetzen, sondern ein - letztlich - lästiges Detail mit etwas moderneren Mitteln zu vereinfachen. Ich will da ja keinen RasPi mit Linux auftopfen.
Na ja, wichtiger als die absolute Anzahl der Takte ist ja dass die 4 innerhalb des Triggers gespart werden, also die Reaktionszeit drastisch reduzieren und damit den Jitter beim erkennen. Das wäre selbst dann noch von Vorteil wenn man hinterher wieder 4 Takte ausgeben müsste um das so zu machen.
Ist mir absolut klar...
Natürlich darf die Floppy nicht schneller Bytes liefern als die Schleife insgesamt braucht
...aber das war ja genau meine Befürchtung. Deshalb: Diskusion allenthalber wegen Nerd Faktor interessant.
Eine Alternative ist an der Stelle höchstens die Verwendung des WAI(t).
Ich verzichte im Code ja absichtlich auf 650C02 Befehle um diejenigen nicht zu verprellen, die den Junior ][ mit einer 6502 bestückt haben. Hätte mir zwar oft mal Arbeit gespart - siehe z.B. PHX/PLX, BRA, STZ - ich bleib da aber standhaft. Deshalb ist WAI natürlich auch keine Alternative.
Nur mal so die Gedanken von jemand der damals schon sowas gebaut hat (und sogar noch dafür bezahlt wurde:))
Ja, ja, die gute alte Zeit...
SCANR :)))
auf gut Deutsch der Depp saß mal wieder am Keyboard... 
Ich sollte aber wohl auch nicht mehr nach 3 Uhr morgens an solchen Problemen arbeiten. Demletzt hatte ich bei so einer Aktion versehentlich einen TTL verkehrt herum auf das Bread board gesetzt und ihn so lange durchgeröstet, dass der Kunststoff darunter schon braun wurde. Gemerkt hatte ich es erst nach dezenter Geruchsbelästigung des mittlerweile verblichenen Bausteinchens. Das war dann das Zeichen für "Ab ins Bett". Mr wird hald ed jüngr.
Bedeutet so vie wie "Problem Between Chair and Keyboard"...
so is es...
Äh, die Schleife wird auf jeden fall um 4 Takte schneller durchlaufen (die Dauer des BIT). Davon wieder 2 hergeben ist also immer noch ein Nettogewinn
Hans, da gebe ich dir natürlich vollkommen recht. Ich wollte nur zum Ausdruck bringen, dass die Euphorie durch den Wegfall des BIT Befehls vier Takte zu sparen, durch das unbedingt benötigte CLV etwas gedämpft werden muss, sprich die Einsparung eben nur zwei Zyklen beträgt. Da das ganze aber ja sowieso auf meiner falschen Befürchtung beruhte, dass die Sampling Phase der Schleife zu lange dauert - was ich mir bei einer Datenrate von 250 kb/s eben auch nicht vorstellen konnte - hat sich die Taktzählerei natürlich erübrigt.
Warum so kompliziert? Ein paar TTL tun es auch. 1980 hatte es noch keinen ATMega:)
Da bin ich durchaus pragmatisch, da in den 80ern ja auch schon Microcontroller wie MCS-48 Serie (die es ja glaube ich sogar schon Ende der 70er gab) verbaut und auf allen möglich Tastaturen, etc. eingesetzt wurden. Die AVR Serie ist ja auch schon seit Anfang der 2000er auf dem Markt und somit kein neumodischer Kruscht mehr. Ausserdem ist der DIP 40 Formfaktor ja durchaus klassisch. Das man mit ein paar TTLs die DMA Logik hinbekommt ist unbestritten, in diesem speziellen Fall hätte ein ATmega mir aber mehr Flexibilität geliefert. Ausserdem, wo hört das auf? Man könnte ja auch auf den Floppy Controller verzichten und alles in TTL aufbauen. Da explodiert irgendwann mein Steckernetzteil bei dem zu erwartenden Stromverbrauch 
Vor allem wenn Du eine extra CPU verwenden würdest, dann kann die eh gleich alles alleine machen - dann ist aber auch der 6502 Spaß weg.
Ne ne ne, die 6502 hat noch ne Menge zu tun, und ich hätte das Programmier Interface sowieso genauso gestaltet, wie es der FDC der CPU anbietet.
PEBCAK?
:)) SCNR
Selbst nach Einsetzten eines Babelfisches in meinen Gehörgang und lautem Vorlesens der Acronyme (?) hab ich leider keine Ahnung was das bedeuten könnte 
. Das musst du mir bitte Übersetzen
Ich hatte mich jetzt die ganze Zeit gewundert, warum immer genau 9 Bytes gefehlt haben. Diese waren über den gelesenen Sektor verteilt an drei Stellen - immer drei Bytes, immer an fast der gleichen Position. Und dann fiel es mir wie Schuppen aus den Ohren... 
Ich hatte zwar am Ende der Leseroutine ein CLI gesetzt um den 1/60 Sekunden Interrupt für die Abfrage der Datasetten-Tasten wieder einzuschalten. Den SEI Befehl um den Interrupt Auszuschalten habe ich aber glatt vergessen 
.
Mit gesperrten Interrupt wird der Sektor jetzt fehlerfrei gelesen.
So muss das aussehen
Gestern Abend mal /SO - synchronisiert mit der fallenden Flanke von PHI1 - an den invertierten Ausgang des INT Signals des FDC gehängt. Das Interrupt Signal wird ja - wie ich jetzt noch nachgelesen habe - bei nonDMA Betrieb für jedes anstehende Datenbyte ausgelöst. Von daher ist das also eigentlich ziemlich ideal.
ABER...
leider funktioniert es immer noch nicht. Die Gate Schleife wird jetzt natürlich schneller durchlaufen, dafür benötige ich in der Hauptschleife aber wiederum ein zusätzliches CLV (zwei Takte) um das extern gesetzte Overflow Flag wieder zu löschen. Sonst rauscht mir natürlich der Code gleich wieder durch die Gate Schleife durch. Somit verpasse ich wieder ein paar Byte. Warum das mit dem WD2797 bei Dietrich funktioniert kann ich beim besten Willen nicht beantworten. Sind die Datenträger da womöglich FM formatiert?
Mit MFM Datenträgern sehe ich jetzt gerade keine Chance mehr, selbst wenn ich, wie von Hans angeregt, den FDC Port in die Zero Page lege und damit nochmals einen Takt in der Hauptschleife sparen kann. Nach ein paar gelesenen Bytes ist der zeitliche Offset dann doch so groß, das Daten durchflutschen...
Ich werde jetzt mal den Versuch starten, einen DMA-Controller mit einem ATMega32 zu programmieren. Der ATMega8 hat leider einen IO Pin zu wenig, somit bräuchte ich wieder etwas etxterne TT-Logik um alles rein zu packen.
Die hatten den SO (set overflow) Eingang der CPU (den sie sonst n.W. nie benutzt hatten) verwendet, um irgendein Signal schneller verarbeiten zu können.
Das SO Signal hängt beim Junior ja am Erweiterungsport. Eventuell könnte man ja das DMA signal des FDC damit koppeln. Die 6502 müsste dann nur mit
DMA_LOOP BVC DMA_LOOPeine Warteschleife zum pollen des Overflog Flags durchlaufen. Wenn man das /DMA Signal leicht verzögert wieder auf /DACK zurückführt, könnte sich der FDC dann selber triggern. Die CPU muss dann natürlich trotzdem schnell genug die Daten lesen und abspeichern. Ein Terminal Count Signal müsste dann zum Schluss auch noch erzeugt werden. Mal experimentieren. Danke für den Hinweis Toast_r .
Kurze Frage für Dummies: Hast du Informationen zum 2797? Den kenne ich nicht, daher kann ich wirklich garnichts dazu sagen.
Ansonsten dachte ich auch, dass es funktionieren müsste. Ich hab zum Testen auch schon auf alles verzichtet, was Zeit kosten könnte. Die erste Abfrage, ob der Datentransfer beginnt habe ich noch mit einem CMP gemacht um abzufragen, ob der FDC sich in der Execution Phase befindet. Danach frage ich nur noch das REQUEST FOR MASTER Flag per BIT Befehl ab. Die beiden 256 Byte Seite beschreibe ich ohne Schleife, um beim Wechsel keine Zeit durch ein DEX zu verlieren und beim indizierten Schreiben nutze ich gerade nur STA abs,Y und keine indirekt indizierte Adressierung. Weniger Taktzyklen geht meiner Meinung nach nicht mehr.
INT_LOOP LDA FDC_MSTAT_REG ; read master status register
CMP #$F0 ; request for master and execution mode ?
BEQ READ ; yes, start reading
BNE INT_LOOP ; no, wait for flags
; start of data read
READ_LOOP_1 BIT FDC_MSTAT_REG ; request for master flag set?
BPL READ_LOOP_1 ; no, wait for flag
READ LDA FDC_DATA_REG ; yes, read data
STA $600,Y ; store it in lower page of destination address
INY ; next index
BNE READ_LOOP_1 ; repeat until overflow
; overflow - read into upper destination page
READ_LOOP_2 BIT FDC_MSTAT_REG ; same as above ...
BPL READ_LOOP_2
LDA FDC_DATA_REG
STA $700,Y
INY
BNE READ_LOOP_2Oh, hier war ja fleißig was los über das Wochenende.
Um die Frage nach dem GAL Assembler aus meiner Sicht zu beantworten: Ich benutze auch WINCUPL. Wie MicrotronicHamburg schon gesagt hat, ist WINCUPL nicht mehr ganz auf der Höhe der Zeit (vor allem der Simulator) aber zum Eingeben und Assemblieren ist es völlig ausreichend.
Der TL866 kann bei mir eigentlich alle GAL Typen programmieren. Einfach als Hersteller Lattice statt Atmel wählen, da sind dann auch 22V10 Typen möglich.
Bzgl. Floppy Controller bin ich am Freitag mal mit dem Lesen einer Diskette weitergekommen - zu mindest was meine Erkenntnisse angeht.
Das Einlessen von Sektor 00 war zwar auf den ersten Blick erfolgreich, allerdings sah ich dann schon sehr schnell, dass das Boot Record Tag 55 AA nicht an der richtigen Stelle lag und das hat sich auch nach mehrmaligen einlesen und Optimieren des Codes nicht wesentlich verändert. Offensichtlich flutschen immer wieder ein paar Bytes durch, die nicht schnell genug vom FDC abgeholt werden können. Somit sind die letzen gelesenen neun Bytes immer bereits die sieben Ergebnis Bytes und zwei mal das letzte Byte des Ergebnisses. Das Ergebnis 40 10 lässt auch schon nichts Gutes hoffen (Abnormal Termination und Overrun) ...
Die Erkenntnis ist also dahingehend, dass es selbst bei einer 720KB Floppy nicht möglich ist, die Daten bei 1 MHz CPU Takt schnell genug zu lesen.
Eine DMA Lösung ist also unumgänglich. Nach einiger Überlegung bin ich zu der Überzeugung gelangt, dass die einfachste und vermutlich effizienteste Lösung der Einsatz eines ATMega8 oder 32 wäre, der dann sowohl als Interface als auch als DMA Controller dient und die gelesenen Daten in sein internes RAM buffert. Das GAL wäre dann hinfällig und die Programmierschnittstelle über den ATMega zum Rechner könnte dann genauso aussehen wie zum FDC. Allerdings wären hier dann als Komforterweiterungen gleich Möglichkeiten geboten, wie z.B. statt einer Anforderung von der Floppy via CHS diese gleich per LBA zu machen. Der uC rechnet das dann doch wesentlich schneller um als es eine 6502 macht. Der ATMega könnte auch eine Floppy autonom formatieren, und wenn man einen ATMega1284 nehmen würde, hätte man 16KB internes RAM und könnte somit einen vollständigen Track zwischenspeichern (für wiederum autonomes Kopieren einer Diskette).
Nachteil ist, dass ich dann die Daten für einen gelesenen Sektor wieder Byte weise aus dem uC auslesen muss, was natürlich wiederum Zeit kostet. Aber ich denke das ist verschmerzbar.
Die Möglichkeit ein externes (DMA) RAM zu nehmen, welches dann per Bankswitching direkt im Junior Adressbereich eingeblendet werden kann wäre natürlich auch möglich, was aber nur Sinn machen würde, wenn man dann auch größere Speicherbereiche auf diese Art umschalten und somit ganze Programme per DMA einlesen könnte. Dann bin ich aber natürlich schon bei der Notwendigkeit einer vollständigen MMU angelangt, was ich erst mal nicht unbedingt anstreben wollte.
Besser ist das! . Jetzt mal das TTL Grab gegen ein GAL 16V8 ausgetauscht.
ThoralfAsmussen : Ich denke, dass ich das auch so lasse. Falls ich mich entschließe eine DMA Schaltung mit einzubauen, benötige ich sowieso noch min. weitere 8 Bausteinchen (2x Zähler, 2x Adress Bustreiber, 2x Datenbus Transeiver, RAM, GAL) wenn ich dafür dann eben auch ein GAL nehme, sonst wesentlich mehr. Damit ist es dann sowieso egal, ob ein oder zwei PLDs auf der Platine drauf sind. Zusätzlich soll ja auch noch der Grafik Controller samt RAM mit drauf. Da möchte ich so viele TTLs wie möglich einsparen.
Eventuell werde ich aber auch zwei Versionen - eine mit GALs und eine nur mit TTLs - machen, dann kann jeder selbst entscheiden, was er aufbauen möchte. Das dann aber nur, wenn ich mich gegen DMA entschließe.
So, bisher erst mal letzte Version des Schaltplans für den Floppy Controller, inkl. des WD37C65B (GM82C765B) und Floppy Connector. Das Pseudo Register (Read DOR) zeigt jetzt dann an Bit 8 den Interrupt und an Bit 7 Disk Changed an.
Du musst aber trotzdem pro Sektor 4 Bytes rasch an den Controller senden, damit er das ID-Feld erzeugen kann. Aber das passt natürlich in einen z.B. 2kB DMA-Puffer stets hinein.
Das stimmt schon, aber da komme ich mit wesentlich weniger Befehlen aus nämlich jeweils nur LDA und STA, das sollte dann zeitlich kein Problem sein.
für diese DMA-Schaltung mit lokalem RAM könnte es zu Problemen bei Formatieren kommen.
Da sehe ich kein Problem. Für die Formatierung benötigt man ja kein DMA. Du musst da ja nur für jeden Sektor im Track die benötigten Daten (ID, GAP3, etc) bereitstellen. Das kann man dann wieder Interrupt gesteuert, bzw. per Polling machen, da die Zeiträume zwischen zwei Anfragen des Controllers ja riesig sind. Ob der Controller irgendwas DMA gesteuert machen soll, kann ich ja per SPECIFY Befehl (Byte 3, Bit 0) angeben und so einzelne Befehle gezielt als non DMA ausführen.
Hallo klaly . Das sieht genauso aus, wie ich mir das vorgestellt hatte. Ein extra Sektor Buffer der via DMA befüllt und dann vom Host eingelesen wird (bzw. umgekehrt bei einem Write). Danke für das Datenblatt. Ich werd mir mal Gedanken machen, wie und ob ich das in den FDC integrieren werde.
Heute Nacht dachte ich, dass es doch noch Probleme mit meiner FDC Schaltung gibt. Ich wollte den Drive Status abfragen - laut Datenblättern von WD und (Unlucky) Goldstar der Befehl $00) - was der Controller standhaft mit Unkown Command quittierte. Zu allem Unglück gab die manuelle Eingabe ein anderes Status Ergebnis zurück, als es die Programm gesteuerte Ausführung machte. Letztlich hab ich dann das Datenblatt des UPD765 zu Rate gezogen und den Befehlscode $04 ausprobiert...und tadaaa... der Drive Status wurde angezeigt.
Echt blöde, da hat WD ein fehlerhaftes Datenblatt rausgebracht und alle schreiben einfach ab. Das ist ja wie in der Grundschule!
Immerhin sind bei Goldstar die Bezeichnungen der Register richtig, die sind nämlich bei WD durchrotiert (MST = ST0, ST0 = ST1 ...).
Jedenfalls scheint die Schaltung jetzt zu tun, was man von ihr erwartet.
Ich bin aber auch nicht vom Fehlerteufel verschont geblieben. Im Schaltplan liegen am 2 zu 4 Decoder die Ausgänge in der Reihenfolge von oben nach unten bei Q0..Q3. Ihr müsst euch da aber die Reihenfolge Q3..Q0 vorstellen, da bei mir wie oben erwähnt ja das MST an $800, Data an $801, /DCR an $802 und /DOR an $803 liegen. Wird natürlich in der endgültigen Schaltung korrigiert.
TTL kann aber jeder nachbauen - auch ohne passenden "Brenner".
Stimmt natürlich schon, aber mittlerweile hat hier im Forum wahrscheinlich jeder einen günstigen Minipro TL866A o.ä. für seine (E)EPROMS und damit sind dann z.B. auch GAL16V8 programmierbar.
