Junior Computer ][

Hallo ThoralfAsmussen, danke für das Manual. Ich hatte es zwar schon der Binary in der Zip Datei beigelegt, aber so ist das etwas ersichtlicher, dass es auch eine Beschreibung dazu gibt

Zitat von ThoralfAsmussen

Mir gefallen ja DEEK und DOKE ganz gut

Ja, die Befehle sind schon praktisch, ich hätte sie aber DPOKE und DPEEK genannt. Deek und Doke klingt irgendwie nach zwei kleinen Schweinchen .

Zitat von ThoralfAsmussen

Schöne Schleifen haben auch was für sich

Genau, ebenfalls eine sehr gute Befehlserweiterung. Allerdings erschließt sich mir nicht, warum er es so umständlich gemacht hat. DO...UNTIL, DO...WHILE und DO...LOOP wären geschickter gewesen als DO...LOOP UNTIL und DO...LOOP WHILE. Ausserdem macht eine DO...WHILE Schleife eigentlich keinen Sinn, dass müßte dann schon WHILE...DO oder so ähnlich sein, da ich eine WHILE Abfrage bitte sehr vor dem Eintritt in eine Schleife haben möchte (siehe Pascal).

Die IF...THEN...ELSE Abfrage ist leider auch etwas inkonsequen, da bei einem ...ELSE... : ... alles nach dem Doppelpunkt immer ausgeführt wird, statt dann im ELSE Zweig behandelt zu werden.

How ever, ich bin aber froh, dass es EhBasic gibt. Ich hab zwar schon einige (Basic) Interpreter geschrieben, allerdings nicht in Assembler, dass ist nochmal eine extra Herausforderung und muss gerade wirklich nicht sein. Vor allem vor den FP Funktionen kann es einem bei einem 8Bit Prozessor schon gruseln .

Zitat von ThoralfAsmussen

Nur mit der Grafik hapert es naturgemäß ein wenig.

Da das Projekt glaube ich ursprünglich für Terminalbetrieb ausgelegt war, macht Grafik natürlich keinen Sinn. Auch ansonsten hätte die Portierbarkeit ziemlich gelitten. Aber mal schauen, ob der Junior noch irgendwann eine Grafikkarte spendiert bekommt, dann kommen da auch Grafikbefehle in EhBasic rein .

Zitat von ThoralfAsmussen

Dafür sehen diese Interruptsteuerungen wieder sehr interessant aus, verdienen auf Fälle noch mal irgendwann einen zweiten Blick.

Die beiden Befehle habe ich bisher noch nicht angelangt. Prinzipiell sollte IRQ kein Problem sein, da ich sowieso eine Interrupt Daisy-Chain implementiert habe. Beim NMI muss ich da noch ein wenig Hand anlegen.

Zitat von ThoralfAsmussen

Da gäbe es ja doch "nebenan" gerade dieses interessante PET Grafik Teil namens "Low Speed Grafik".

Das werde ich mir morgen gleich mal anschauen. Vielen Dank für den Tipp. Die Auflösung hört sich für mich nach einem EF9366 an. Bin gespannt...

Bezüglich EhBasic: Ich hab gerade den Befehl BEEP implementiert. Frei nach Tom Hanks: "ICH HABE FEUER GEMACHT!!!"

Ergebnis: Beep...

Anbei das neue Goldstückchen (keine Sorge, ich werde jetzt nicht stündlich neue Versionen veröffentlichen).

Zitat von ThoralfAsmussen

Da gäbe es ja doch "nebenan" gerade dieses interessante PET Grafik Teil namens "Low Speed Grafik". Müßte an sich passen und man kann wahrscheinlich die Software relativ 1:1 übernehmen. Wenn man das kann zumindest. Vielleicht wäre es ja einen Blick wert. und 512x256 oder 512x512 ist so schlecht nicht. Der Nachteil ist wohl v.a. dieses ExtraRAM, aber dadurch vereinfacht sich wohl die "Einbindung ins System" etwas, aber für schnelle Grafik ist das schlecht, Games z.B. - weil man ja mit der CPU nicht direkt ins VideoRAM kommt.

Hallo ThoralfAsmussen , ich hab mir den Thread mal angesehen. Wie ich vermutet hatte, handelt es sich um den EF9366. Den hatte ich tatsächlich bereits mal als GDP angedacht. Ich hab zwar bei mir noch einen in der Bastelkiste, aber ansonsten ist der IC leider nur noch schwer herzubekommen.

Das tolle am EF9365/66 ist ja, dass du beliebig viele Speicher Panes übereinander schalten kannst und damit die Fartiefe problemlos auch auf 32Bit bringen könntest (was dann aber 32 Speicherseiten a 16KB = 512KB wären).

Auf dem VCFe habe ich mich mit den zwei Jungs vom Steckschwein Projekt unterhalten. Die nehmen einen Yamaha V9958, den Nachfolger des TMS9929, der glaube ich auch im TI99/4A verwendet wurde. Der V9958 scheint recht gut erhältlich zu sein, allerdings habe ich mich mit dem Chip noch nicht wirklich beschäftigt. Jedenfalls nutzt der auch seinen eigenen Speicher.

Bevor ich mit einer Grafikkarte anfangen würde, stände bei mir aber auch erstmal ein (3,5") Floppy-Controller auf der Wunschliste. Den würde ich zur Not auch mit einem Microcontroller basteln, da die alten ICs auch nicht mehr beim Bäcker zu bekommen sind. Und wenn ich tatsächlich ein uC für die Floppies nehme, lässt sich sicherlich auch noch recht einfach eine SD Karte darüber ansprechen.

Zitat von NorbertJ

Bei der Implementierung einer Grafikkarte wäre aber auch ein PS/2 Keyboard sinnvoll.

Das kann man natürlich auch über den uC anbinden. Ich hatte aber daran gedacht, den 6532 RIOT neben dem Druckeranschluss noch dazu zu verwenden, eine ASCII Tastatur anzuschließen. An meiner Apple 1 Replica hab ich ja eine Cherry ASCII Tastatur dran, mit der wollte ich mal anfangen und eventuell dann eine eigene Tastatur entwerfen.

Das ESP32 Terminal könnte man ja auch problemlos als Grafikkarte nutzen. Die FabGL Library kann auch Sprites, VGA Auflösungen, Sound, etc. und die ESP Modue sind billig und einfach auf eigenen Platinen zu nutzen. Aber letztlich geht es mir wie ThoralfAsmussen schon gesagt hat ja um einen Grafik Chip, der, wenn irgend möglich, noch retro ist. Bei so Dingen, wie Floppy Controller hab ich weniger Hang zum Alten, weil diese Controller ja eigentlich auch schon spezielle, vorprogrammierte Microcontroller waren. Bei einem Grafik Chip könnte ich mir aber auch vorstellen einen uC im standesgemäßen DIL 40 Gehäuse (ATMega 64, Propeller etc.) zu nutzen. Aber einen ESP32 oder einen Controller im Quadpack Gehäuse wie bei dem Olimex ist für mich eher eine Notlösung.

Gestern Abend gab es jetzt noch den Befehl PLIST von mir als Erweiterung von EhBasic.

Und hier das Ergebnis

Gerade eben hab ich auch noch einen Fehler im SWAP Command behoben. Der Befehl hat immer Type mismatch Error geworfen.

Für alle, die den Fehler auf einem anderen Rechner haben: Einfach in der Routine LAB_SWAP den Befehl BPL SwapErr in BNE SwapErr ändern.

Hmmm, bin gerade vom Preis des V9958 etwas schockiert. Zwischen 50 bis 60€ inkl. Versand ist schon ganz schön happig.

Jetz hätte ich gerne mal eure Meinung zu folgender Problemstellung gehört.

-------------------------------------------------------------------------------------------------------------

Auf der Erweiterungsplatine wollte ich ursrünglich ein 32KB ROM einsetzten, von dem dann eine per Software wählbare 8KB Bank im Speicherbereich $C000 bis $DFFF eingeblendet werden könnte. Durch den Einsatz des EhBasic hat sich der Plan eigentlich erübrigt, da folgendes Problem:

Das EhBasic braucht bisher 10.322 Byte und im Haupt-ROM habe ich jetzt gerade noch 4.142 Bytes frei.

Ich kann also nun auf der Erweiterungsplatine eine der folgende drei Möglichkeiten gestalten:

(Anmerkung - Die im unteren 8KB Block liegenden 2KB Speicher werden im folgenden nicht berücksichtigt, da sie durch I/O Blöcke vom Hauptspeicher ab $2000 abgetrennt sind und vom Basic Interpreter deshalb nicht genutzt werden können)

1. 16KB ROM mit dem Basic auf die Zusatzplatine. Dann wären nur noch 32KB RAM aber insgesamt 9KB ROM übrig. Adress-Decodierung einfach.

2. 16KB ROM auf die Zusatzplatine, von dem nur 12KB als 3x4KB im Speicherbereich $B000 bis $DFFF eingeblendet werden. 36KB RAM und 5KB ROM frei. Zusätzliche Adress-Decodierung aufwändig.

3. 8KB ROM auf die Zusatzplatine, den freien Bereich des Haupt-ROMs an den Anfang schieben und so zusammenhängende 12KB aus 4KB+8KB schaffen. Keine zusätzliche Adress-Codierung nötig, 40KB RAM frei, aber das Basic muss in zwei ROMs aufgeteilt werden. Knapp 2KB ROM wären dann Stand jetzt noch für Gedöns übrig (Basic Erweiterungen, Kassetten Monitor, etc.).

Mein Favorit ist natürlich 3. wegen des geringsten Hardwareaufwands. Es könnte auch jeder, der keine VIA-Karte braucht, ohne viel Aufwand eine kleine ROM Karte an den Slot hängen und den Junior so Basic fähig machen. Aber klar ist auch, dass das Aufteilen des Basics in zwei ROMs nicht gerade schön ist, und ein Rumschrauben am Basic-Interpreter dann auch nicht gerade einfacher wird.

Die ersten Variante wäre auch einfach zu bewerkstelligen, bietet ebenfalls die einfache Anbindung des Interpreters an den Rechner, verschwendet aber ziemlich viel RAM und Stand jetzt wüsste ich nicht, was ich in die 9KB freies ROM quetschen sollte (OK in Zukunft evtl. ein DOS, Grafik Kernel, blabla).

Variante 2. braucht einfach eine komlexere Adress-Decodierung, (weil die bisherige Aufteilung 8KB Adressblöcke sind) und ist deshalb nicht gerade mein Freund. Bietet aber immerhin 4KB mehr RAM als 1. Einfaches "ROM an den Slot hängen und fertig" ist dann aber nicht mehr.

Was meint Ihr?

Hallo Norbert,

der (original) Junior Computer hat ja das Problem, dass er für die (wenigen) I/O Bereiche jeweils nur 1KB reserviert hatte, und der Junior 2 das aus kompatibilitäts Gründen natürlich auch so macht. Das ROM konnte als einzelner Baustein auch nie größer als (nutzbar) 8KB werden - wegen der Kompatibilität. Ausserdem gibt es bei der 6502 leider keinen getrennten I/O Bereich wie bei einer 6510 oder einer Z80, sprich ich verbrate hier immer kostbaren Adressbereich des Hauptspeichers.

In dem pro I/O Port nutzbaren 1KB des Juniors liegt dann jeweils der Registerbereich des I/O Bausteins und ein eventuelles ROM, welches für rudimentären Code zur Chip Steuerung ausreichen kann, bei z.B. komplexen Grafikfunktionen aber schon eng wird. Deshalb ist natürlich ausreichend Platz im System ROM wichtig, wenn es gesetzte Funktionen sind, sprich, ich weiß (oder voraussetze), dass der RTC, der Sound-Chip oder der Grafik-Controller immer im System vorhanden ist. Das ist bei einer Steckkarte aber gerade nicht der Fall. Hier ist alles Option und das System ROM für solche Code definitiv der falsche Ort.

Bei einem DOS wiederum, kann und sollte ich (siehe CP/M, MS-DOS) nur einen System abhängigen Teil im ROM halten und den Rest vom Datenträger lesen. Deshalb ist hier eine ausreichende Menge RAM genauso, oder sogar noch wichtiger. Ein DOS BIOS muss eigentlich "nur" den Controller-Baustein (Motor An/Aus, Kopf auf Position X, etc.) steuern, was locker in ein paar hundert Byte eines Steckkarten ROMs passt. Der Rest ist dann das eigentliche DOS, dass ich aber natürlich erst durch den Boot Vorgang ins RAM lade.

Bei einer Implementierung von FAT (besser FAT32) schätze ich mal ca. 5-8KB Speicherbedarf, inkl. LOAD, SAVE, CD (legt mich da aber bitte nicht fest). Die weiterführenden Befehle (DIR, FORMAT...) werden dann erst bei Bedarf wieder vom Datenträger geladen, gehören also nicht zum DOS Kern dazu und können auch mehrere KB verbraten.

Kurz, mehr RAM wäre also wichtiger als mehr ROM, außer man implementiert ein sehr statisches DOS im ROM, was aber auch keine besonders gute Idee ist. Deshalb gefällt mir ja auch die Option 3 am Besten, auch wenn ich dann das Basic stückeln müßte. Ein 8KB Basic wäre natürlich das Schönste gewesen, aber dann fehlen oft wichtige Befehle oder ich kann den Befehlssatz schlecht oder garnicht erweitern.

Übrigens bin ich beim Sound-Chip gerade mit dem SN76489 am liebäugeln - kennt den jemand aus den MSX Rechnern, und wie gut ist der im Vergleich mit einem AY-3-8910?

Zitat von NorbertJ

Der Soundchip soll im Tandy 1000 gewesen sein, drei Rechteckgeneratoren und einen Noise-Channel haben. hier

Danke! Ich werde mir das definitiv überlegen, vor allem, weil der noch so schön billig zu haben ist (oder zu mindest die Fake Bausteine ). Ausserdem kann man den offensichtlich leichter ohne vorgeschalteten VIA/PIA Port nutzen.

Zitat von orion7

Möglicherweise könnte man hier Deine ursprüngliche Idee mit dem 32 K Eprom verbinden.

Wenn man (per Jumper?) eine Bank mit Forth oder Comal auswählt sollte der ausgelagerte Teil des Basics egal sein.

Das sehe ich auch so. Allerdings hat das Comal, dass ich mir angesehen habe auch schon wieder mehr als 8KB . Forth müsste aber z.B. gehen. Die Überlegung ist auch, die 8K ROM der Erweiterungskarte komplett ausblendbar zu machen, so dass das RAM wieder nutzbar wird, dann hat man die Option, hier einen anderen Interpreter zu nach zu laden und verliert nicht noch mehr Speicher. Das Bank Switching mache ich über das Schreiben in eine Speicheradresse der Karte. Dann muss man da keine Jumper bewegen. Ich werde den bisherigen Schaltplan diese Woche mal posten.

Zitat von orion7

Einziger Nachteil ist es den Basic-Code teilen zu müssen. Das stelle ich mir aber als nicht so großes Problem vor

Die Aufteilung ist kein Problem. Einfach nach 8192 Byte abschneiden und den Rest dann ins System ROM. Es geht da letzt endlich nur um die Tatsache, immer zwei ROMs brennen zu müssen, wenn man eine Änderung in das Basic eingepflegt hat. Aber das sollte ja hoffentlich auch mal ein Ende haben, ich will ja nicht dauernd neue Features in EhBasic pflanzen.

Hallo Dietrich,

beim Junior Computer 2 habe ich sowieso schon den Bereich $2000-$DFFF vollständig mit RAM gefüllt und die unteren 2K Adressen werden auch vom RAM genutzt. Außerdem sind 512 Byte im I/O Bereich der ACIA eingeblendet, die in meinem erweiterten Monitor als String- und Datenbuffer für Ein-/Ausgabe genutzt werden. Und genau dort habe ich auch den iBuffer des EhBasic reingelegt. Zudem liegen alle Sprungvektoren im RAM des RIOT.

Eine Änderung der Ursprünglich Adressdekodierung oder ein Ändern des Original Monitor ROMs war für mich von vorne herein für den Junior 2 ausgeschlossen. Das wollte ich einfach so hinbekommen. Ich denke aber, dass man mit den vorhandenen Resourcen auch ganz gut zurecht kommt, immerhin hatten Rechner wie der C64 auch nicht viel mehr Speicher für Basic frei. Und ich finde es ja auch immer spannend, aus dem bischen verfügbaren Speicher und der Rechenleistung das Maximum heraus zu quetschen.

I2C werde ich via VIA (Wortspiel ) auch implementieren, das Bussystem fand ich immer sehr praktisch und hab das früher oft mit der Parallel-Schnittstelle unter MS-DOS implementiert um Elektronikbasteleien zu steuern. Eventuell kommt auch SPI mit dazu, aber wir werden sehen...