Posts by Diddl

    Meine beiden CBMs, die ich ab 1980 besaß, hatten beide RAM im Bereich der Extension-Sockel.

    Sowas hab ich mir mal gebastelt für meinen 3032.


    Aber nun mit dem 8296 braucht man das ja nicht mehr, der kann da sowieso RAM haben wenn man es möchte ...




    Gibt es dafür eine fertige Schaltung, die ich einfach umsetzen könnte?

    Naja die Schaltung ist ja eher simpel ...


    Ich hab so etwas ähnliches gemacht, aber halt EPROM statt SRAM.


    Diese Platine kann mehrere 23xx ROM ersetzen durch ein einzelnes 29F040.

    Man steckt die Platine in einen 23xx Sockel des PET und braucht dann noch Drähte zu den /CS der anderen 23xx Sockel.


    So kann man alle drei EPROM Steckplatze eines PET ersetzen, und zwar natürlich mehrfach durch banking.

    Damit kannst du alle deine EXBASIC Varianten einfach umschalten.





    =======


    Natürlich kann man das auch umstricken und ein SRAM einsetzen.

    Ein 16K SRAM ersetzt dann alle drei ROM Sockel am PET.


    Man braucht dann halt noch ein R/W von irgendwoher ...

    (also ein weiterer Draht)

    Nach langem Kampf ist nun ein Teil Erfolg gelungen! :)



    Neben FLEX und CUBIX läuft nun endlich auch NitrOS9 Level 1auf meinem SBC-09 Board:





    Die Tests sind alle erfolgreich, das Ding läuft wie ein Uhrwerk.


    Hab ich schon erwähnt, wie toll ich OS9 finde? :D


    Es ist einfach SENSATIONELL!!!


    ====


    Und nun geht's weiter mit dem eigentlichen Ziel: NitrOS9 Level2

    Ich bin mir noch nicht sicher, ob ich das wirklich so haben möchte. :grübel:

    Der CBM wäre dann für mich kaum noch für andere Dinge nutzbar. Ich habe praktisch immer irgendeine Erweiterung im Bereich 9000-BFFF aktiv.

    Naja das könnte man ja sehr leicht adaptieren.


    Dazu müsste ein größeres EPROM auf die Hires Karte kommen.


    Mit einem POKE schaltet man zwischen

    • HiRES
    • ROM Betrieb (also wie ohne HiRES)
    • RAM Betrieb (damit könnte man jede Erweiterung einfach laden)


    Mit einem zweiten POKE macht man das Banking.

    Finde ich super, mir sind ähnliche Gedanken durch den Kopf gegangen.

    Wenn man es nicht kompatibel machen kann, würde ich gerne an der Software Anpassung mitarbeiten.



    Zum anderen würde ich gerne das Ding modernisieren.

    Modernere Bauteile, GAL oder CPLD, moderne RAM, Chip Reduktion wo möglich.

    40mb druckbuffer?

    Lächerlich.

    Heutzutage 5 Bilder aus dem Handy.


    Ein HP Drucker Driver hat schon hunderte MB


    Und ein kleiner Printer Server hat hunderte GB Buffer.



    Aber anbetracht der Tatsache, dass es vermutlich ein Nadeldrucker ist, der hauptsächlich Text druckt...


    Und Bilder haben da auch kaum Auflösung und nur eine Farbe ...

    Hab ich halt nicht mitbekommen, weil ich fast nie im Forum64 unterwegs bin. :(

    Finde das 'ne klasse Idee, und würde mich freuen, wenn jemand noch einen Bausatz für mich übrig hätte.

    Im Forum64 scheint die Aktion ja abgeschlossen zu sein.

    Eigentlich gibt es das schon seit Jahren.

    Jedes Jahr eine eigene verbesserte Edition.


    Und nicht nur Weihnachten, auch Ostern und andere Events.

    OS9 Level 1 läuft auf meinem Tandy CoCo3 und auf meinem Dragon64.

    NitrOS9 Level 2 läuft auf meinem Tandy CoCo3.



    Gibt es eigentlich auch ein OS9 für die Thomson?


    Man findet im Netz Spuren, daß jemand versucht hat, OS9 auf einen M05 zu portieren.

    Leider verliert sich die Spur.

    Die Homepage gibt es nicht mehr.


    Am M05 wäre der Sinn eh fraglich.

    Mit 32K RAM...


    Aber der T08, der wäre ja prädestiniert für Level 1.

    Mach doch bitte vielleicht mal noch ein paar Links dazu, die Du ja wahrscheinlich mittlerweile gut kennst und gebookmarked hast, damit man auf einfache Art die drei, vier wichtigen Webseiten findet.

    FLEX Wiki:

    https://de.wikipedia.org/wiki/Flex_(Betriebssystem)

    https://en.wikipedia.org/wiki/FLEX_(operating_system)


    FLEX User Group:

    FLEX User Group - Welcome!


    SWTPC:

    Overview


    SWTPC Emulator:

    FLEX UniFLEX User Group Wiki


    UniFLEX hardware mit MMU:

    GitHub - kees1948/UniFLEX: an UniFLEX compatible hardware/software project on Eurocards
    an UniFLEX compatible hardware/software project on Eurocards - GitHub - kees1948/UniFLEX: an UniFLEX compatible hardware/software project on Eurocards
    github.com

    Wenn man sich mit historischen Computern auf Basis der Motorola 6809 beschäftigt, dann kommt man nicht an FLEX vorbei.



    FLEX ist ein Disk-Operating-System (DOS) und wurde 1976 von der Firma TSC (Technical Systems Consultants) entwickelt.

    Die erste Version von FLEX hieß Mini-FLEX und lief auf der Motorola CPU 6800.

    Aus dem Mini-FLEX wurde etwas später FLEX 2 entwickelt.

    Als Motorola die 6809 brachte, wurde FLEX angepasst (FLEX 9)



    FLEX hatte eine sehr große Anhängerschaft.

    Es gibt eine FLEX Version für die meisten Computer auf Basis des 6809.

    Und es gibt sehr viel Software und Utilities für FLEX.

    Auch viele Compiler und Interpreter.



    Unterschiede zwischen FLEX und CUBIX:


    Beide DOS System benötigen im Betrieb 8KB Speicher. Aber im Gegensatz zu CUBIX das auch im ROM läuft, braucht FLEX 8KB RAM für den Betrieb. In dem 8K Speicherbereich den FLEX benötigt ist aber auch wirklich ALLES enthalten, inklusive System Variable, Stack, Buffer für Disk Sektoren und sogar ein Bereich für ladbare Treiber und Utilities! Außer den 8KB RAM benötigt FLEX keinerlei Speicher im System.


    Anpassung des DOS an eine neue Hardware: CUBIX bekommt man als Source Code, das ist absolut perfekt weil man es anpassen und für beliebige Speicherbereiche übersetzen kann. Bei FLEX bekommt man ein Handbuch (FLEX Adaption Guide), einen Binär Code (FLEX.COR) und die Utilities als Dateien. Für beide Betriebssysteme muss man Driver Code entwickeln für RS232, Disk Zugriff und optional Printer Unterstützung.


    Während CUBIX in jedem Speicherbereich ausgeführt werden kann, muss FLEX genau im Adressbereich C000-E000 sein und es muss RAM sein.


    Der Systemstart ist bei CUBIX denkbar einfach, das CUBIX muss einfach nur an beliebiger Adresse zur Verfügung stehen. Das kann sein als ROM, als Block im RAM kopiert aus einem ROM oder geladen von Disk. Das FLEX könnte man natürlich auch direkt aus dem RAM kopieren. Aber es ist ein spezieller Bootvorgang angedacht, ähnlich wie beim MSDOS. Auf der FLEX Systemdiskette ist erste Sektor (Track 0, Sektor 0) reserviert als Boot Sektor. Der Sektor enthält den System Boot Code der immer an der Adresse C100 geladen und ausgeführt wird. Der Boot Code lädt dann den eigentliche FLEX Core samt Treiber (FLEX.SYS) von Disk in den Speicher und startet FLEX (Cold Start).


    Sowohl CUBIX als auch FLEX greifen auf bis zu 4 Disk Laufwerke zu. Aus Sicht des OS sind es eine Anzahl Sektoren die über Track/Sektor adressiert werden. In beiden OS kann es maximal 256*256 (65536) Sektoren geben auf einem Laufwerk. FLEX arbeitet mit 256 Byte großen Sektoren, dadurch ergibt sich eine maximale Datenträger Größe von 16MB pro Laufwerk. CUBIX hat pro Sektor 512 Bytes was zu einer maximalen Datenträger Größe von 32MB führt. Dateien sind eine Menge an Sektoren die verkettet sind. Während CUBIX die Verkettung in eigenen Sektoren verwaltet, verwendet FLEX die ersten beiden Bytes in jedem Sektor als Link zum folgenden Sektor (wie bei Diskettenlaufwerken von Commodore). Zudem verwendet FLEX weitere 2 Bytes für die Verwaltung des Dateizugriff, daher stehen eigentlich nur 252 Bytes zum speichern von Daten zur Verfügung.


    Das FLEX kennt keine Verzeichnisse für Dateien, was bei Floppy Laufwerke nur marginal stört aber für Festplatten schon eine große Einschränkung darstellt. Das CUBIX hingegen kennt bereits eine Verzeichnis Struktur, wobei alle Dateien in einem Verzeichnis liegen müssen (es gibt kein Root Verzeichnis). Zudem bietet CUBIX keine hierarchische Struktur, jedes Datei ist in einem Verzeichnis und jedes Verzeichnis befindet sich im Root.



    Fazit:


    Beide DOS Varianten sind brauchbar für einfachste 6809 Systeme. Während das CUBIX moderner wirkt, bietet FLEX eine riesige Sammlung an Programmen und Informationen zu FLEX.


    Das CUBIX kann extrem einfach an eine Zielhardware angepasst werden. In wenigen Stunden kann man CUBIX in Betrieb nehmen, indem man den vorhandenen Treibercode anpasst. Das FLEX ist ein wenig komplexer bei der Anpassung, wenn man es so macht wie es von den Entwicklern vorgesehen ist.



    FLEX Anpassung an den SBC:


    Die Anpassung von FLEX 9 an meinen 6309 SBC habe ich Schritt für Schritt nach dem PDF (FLEX Adaption Guide) gemacht. Im ROM steht ein minimaler Code der die MMU initialisiert und den Bootsektor lädt. Der Bootcode lädt den FLEX Core (FLEX.SYS) in den Speicher und startet FLEX:


     



    Es macht richtig Spaß mit FLEX herum zu spielen. Die zahlreichen Tools auszuprobieren und zu testen. Das BASIC, das extended BASIC, FORTH und C Compiler sind auf Anhieb perfekt gelaufen.


    Der C-Compiler kompiliert ein "Hello World" Programm vollautomatisch in mehreren Durchläufen (siehe Screenshot).

    Das kompilierte Programm wird vom Compiler als HELLO.CMD abgespeichert und kann durch EIngabe von HELLO gestartet werden.

    Auf der Diskette sind noch andere C Sources drauf die man als Test des Compilers benutzen kann.

    Es funktioniert sehr einfach und gut, wie bei MSDOS Compilern kann man mit argc und argv[] ganz einfach Parameter von der Kommandozeile auswerten.

    Zum Thema 3.3V Typen nehmen:

    Das könnte schwierig werden, da die Spannungsversorgung des PLCC44 Sockels auf dem Board (4 Layer) aus einem der inneren Layer kommt. Da ist nix mit Leiterbahn unterbrechen und Spannungsregler reinhäkeln…

    Müsste man dann wohl schon einen Zwischensockel bauen…


    Nee, das wäre bloß eine Alternative für ein PCB Redesign.

    Hier kann man nur auf 5V Typenausweichen.

    Die ja erhältlich sind und sogar noch in Produktion.



    Die 3,3V Typen habe ich bei meiner UC2 in einem Redesign [optional] ermöglicht.

    Weil zeitweise waren die 3,3V Typen besser erhältlich und preisgünstiger.

    Der 3,3V Regler in SMD braucht kaum Platz und kostet fast nichts.

    Bei 5V CPLD bestückt man den Regler einfach nicht.



    Weiteres Hier

    Der <mytek> irrt mit der Aussage, dass 5V ein Problem sei bei Verwendung der ATF1502.


    Zum einen gibt es reine 5V Typen (AS und ASL).

    Zum anderen sind auch die 3,3V Typen (ASV und ASVL) 5V tolerant.

    Da braucht es halt einen Spannungsregler und gut.

    Oops, lese gerade hier dass das ganze nur für ATF1502/04/08 geht

    Nun ja, den ATF1500 hab ich noch nie verwendet, nur die 2, 4, 8

    Deswegen weiß ich auch nicht Bescheid über den 1500.


    Ich dachte eigentlich dass alle (da ja ATF15xx steht) gleich programmiert werden.

    Halt JTAG und ATMISP.


    Aber tatsächlich scheint der ATMISP den ATF1500 nicht zu kennen, zumindest kann man den Typ nicht auswählen in der Device List.


    Sorry ...

    Den Programmer habe ich.

    Ich mach das auch gerne für dich.

    Das Problem ist nur, die Versandkosten zwischen D und A sind abartig.


    Also wenn es jemanden gibt in deiner Nähe, wäre das sicher günstiger.



    Den Programmer kannst du dir auch einfach selbst nach bauen.

    Man braucht ein FT232H Modul und Kleinkram.

    Das Modul kostet nur ein paar Euro.

    Das Shield kann man auf Lochraster aufbauen oder eine Print bestellen.


    ATF150x –

    Erasing and Programming the ATF1504 CPLD | hackup.net
    Last year, I acquired my first VIC-20 and when I discovered that someone shared the Gerber files for a fairly recent version of the Final Expansion 3 (english)…
    www.hackup.net

    Ich bin vor ein paar Tagen auf ein Projekt namens 'UniFlex' gestoßen. Dort kommt auch ein 6309 zum Einsatz und die Hardware besitzt ebenfalls bezüglich MMU und Betriebssicherheit einige sehr bemerkenswerte Eigenschaften.

    In der Tat ist UniFlex wirklich sehr beeindruckend.


    Das FLEX wurde von TSC entwickelt.

    Es hatte eine große Anhängerschaft.

    Und es gibt sehr viel Software und Utilities für FLEX.

    Auch viele Compiler und Interpreter.


    TSC hat dann UniFlex entwickelt.

    Es hat aber mit FLEX nichts mehr zu tun.

    Leider hat es dann schließlich zum Untergang von TSC geführt.

    Es war einfach die Ära der 8 Bitter vorbei, die 16 Bitter waren schon im kommen.


    Die Entwicklung von UniFlex kam um Jahre zu spät, es konnte sich kaum noch verbreiten.

    Für einfache Maschinen hat man FLEX verwendet, noch jahrelang.

    Für komplexe Dinge hatte man ja schon OS9 und dann zunehmend die 16 Bitter.



    Schade, denn FLEX hatte eine große Community.

    Etwas früher hätte UniFlex denselben Erfolg einfahren können.



    Interessant ist auch, es gibt ein angepasstes FLEX das als Task von UniFlex läuft.

    Das heißt, die FLEX device driver rufen einfach die korrespondierende Funktion im UniFlex auf.

    Dadurch konnte man seine FLEX Software ohne Änderung einfach im UniFlex betreiben.


    Kompatibilität war damals schon ein Thema.

    Denn bis jetzt nutze ich lieber putty mit SSH anstatt CMDer/ConEmu/ANSIcon um RunCPM for Windows laufen zu lassen :)

    Nee, das ist schon klar, putty nutzen wo es geht.


    Aber bei einem CPM Emulator oder einem beliebigen anderen SBC Emulator nutzt man ja keinen Putty sondern schreibt direkt in die Console.


    Hmm - wie motzt man die CMD.EXE von Win-32/64 "ganz einfach" auf? ;)

    Ach so ja, der Link ...

    Es sind einfach zwei Win32 API Aufrufe, dann macht der CMD das, solange er läuft.


    Console Virtual Terminal Sequences - Windows Console
    Virtual terminal sequences are control character sequences that can control cursor movement, color/font mode, and other operations when written to the output…
    learn.microsoft.com



    Das ist der Code der das einschaltet:

    damit man den NNANSI nachladen kann, denn der DOXBox-X ANSI ist auch nicht besser als der vom MS-DOS :(

    Interessant, weil ich auch gerade genau dieses Thema habe;



    Man kann die CMD.EXE von Win-32 und Win-64 ganz problemlos aufmotzen.

    Dann kann die ANSI und sogar VT-100 über ganz normale Console Befehle (getc(), putc(), printf() ...).

    Man kann auch die Anzahl Zeichen und Zeilen fixieren und derlei Dinge.


    Sehr praktisch wenn man ein Terminal emulieren will für einen emulierten SBC oder MBC.


    Unter DOS geht das auch, wenn man den ANSI.SYS Treiber lädt.

    Das CUBIX habe ich etwas verbessert, damit es mit der MMU und dem Banking umgehen kann.

    Da alle Systemaufrufe mit SWI gemacht werden, ist das keine große Sache.


    CUBIX läuft nun in der MAP des Task#0 und die User Programme laufen auf Task#2.

    Damit befinden sich nun alle Programme in einem geschützten Bereich.

    Das CUBIX und die System RAM Bereiche sind nun geschützt vor dem Zugriff durch Programme.


    Leider können die Programme aber trotzdem nicht den gesamten Speicher frei benutzen.

    Die Programme sehen zwar nun 64K freien RAM, aber leider nicht das CUBIX.

    Das CUBIX kann nicht so einfach den Speicher ab $D000 des Task#2 zugreifen.

    Dazu müsste man sehr umfangreiche Änderungen im CUBIX machen ... :(


    Die Freude ist leider etwas getrübt.


    ====


    Aber dafür läuft jetzt FLEX.

    Zumindest im Emulator.


    Auf der Hardware muss noch was getan werden.

    Der Arduino muss neue Befehle lernen.

    Damit man die Größe der Sektoren umschalten kann zwischen 512 Byte (CUBIX) und 256 Byte (FLEX, NITROS, OS9).

    Dann sollte es auch auf dem SBC Board laufen.


    Leider setzt FLEX auf eine Sprungtabelle und die Programme nutzen auch den direkten Zugriff auf OS Variable im RAM.

    Damit ist es völlig untauglich für den Betrieb mit mehr als 64K.


    Aber es gibt extrem viel Programme für Flex.

    Das ist schon mal richtig cool.