Voll cool das Ding!
Die Hardware ist schnell gemacht.
Der Assembler Code ist sehr gewöhnungsbedürftig ... 
Beiträge von Diddl
-
-
Obwohl dies natürlich (neben dem Spielen) immer als einer der Standard Use Cases genannt wurde: Briefe schreiben 😉
Nun ja, zu der Zeit war ich ja noch Jugendlicher.
Standard Use Cases waren was für meine Eltern:
"brauche ich für die Schule"
"brauche ich zum lernen
"Textverarbeitung"
"..."
Kommt gleich viel besser wie "ich brauche einen Spiele Computer"
-
Ich sehe gerade einen Tippfehler bei meinem Kommentar.
"mein CoCo-3 ist so aufgerüstet." wollte ich schreiben statt "kein ..."
Verflixte Wortkorrektur am Tablet!!
-
Klasse der BLOG Eintrag, gefällt mir.
Hab auch schon einen Kommentar hinterlassen.
Was für mich nicht stimmt ist:
Irgendwo steht, "die Eignung als Spiele und Homecomputer sei schlecht wegen der fehlenden Kleinbuchstaben".
Dem kann ich nicht zustimmen.
Gerade bei Spiele spielt es keine Rolle ob man Kleinbuchstaben hat.
Zudem kann man ja im Grafik Modus auch Kleinbuchstaben haben.
Commodore hatte ja anfänglich auch nur Großbuchstaben:
- die ersten PET hatten nur Großbuchstaben
- erst ab CBM 40xx startet der Computer mit Groß- Kleinbuchstaben
- VC-20 startet auch im Großbuchstaben Modus
- der C64 startet auch im Großbuchstaben Modus
Commodore hat das Problem "gelöst", indem es einen zweiten Char ROM spendiert hat.
Dadurch kann man wahlweise Groß-Klein Buchstaben haben oder Großbuchstaben mit Grafik Zeichen.
Das selbe wäre auch möglich beim Dragon.
Ich denke mal, am Anfang war es "üblich" nur Großbuchstaben zu haben.
Die Dinger stammen ja doch irgendwie ab vom Fernschreiber ...
Erst im Laufe der Zeit wurde das als Makel gesehen und das Bedürfnis nach Groß-Klein Buchstaben hat sich entwickelt.
Für eine Büromaschine natürlich undenkbar.
Aber dafür waren diese Dinger ja nie gedacht.
Erst die CBM 40xx waren "richtige" Büromaschinen.
-
ber wenn jemand ein eindeutiges Maximun Rating ignoriert, z.B. VIH <= VCC , dann ist das für mich ein Design aus der Stümperliga. Egal ob das Commodore macht oder Helmut.
Commodore hat da wahrscheinlich noch den Vorteil, das sie das Design (der CPU) selber im Griff hat und nicht irgendwelche CPU kaufen muss.
Solche Tricksereien gibt's immer wieder. Meistens rächen sie sich nach ca. 5 - 15 Jahren. Das beruht auch auf eigener Erfahrung!Deiner Argumentation kann ich durchaus etwas abgewinnen.
Mir wäre ein "sauberes" Design auch viel lieber.
Auf der anderen Seite sieht man halt aber doch auch, dass diese "Maximun Rating" vom Hersteller halt doch auch ziemlich überzogen zu sein scheint. Da unterstelle ich, dass manche Hersteller das nie wirklich untersucht oder getestet haben. Das wirkt für mich so "aus der Nase gezogen". So, schreiben wir halt mal was das eventuell ein Problem sein könnte. Wahrscheinlich geht es da um Garantie Dinge usw.
-
Thomson Homecomputer sind auch als wichtige 'Technologieträger' in der Hinsicht nicht zu vergessen.
Richtig!
Aber leider außerhalb von Frankreich praktisch unbekannt ...
-
Du kannst ja von deinem Blog Eintrag dann hierher verlinken.
Dann hat auch das Forum was davon.
-
Ja,das ist sogar Hochglanzpapier, wellt sich leicht und neigt zum Gilb.
Ja und es gibt in der Bucht einen Händler, der deswegen seit Jahren ein gutes Geschäft macht mit einem Ersatz Label
-
Ansonsten gibt es da schon ganz heftige Gurken, ungeachtet ihres wirtschaftlichen Erfolges, oder vielleicht gerade deswegen.
Nun ja, mein Acorn BBC Master ist ähnlich gut verarbeitet wie der Dragon.
Gut diese Sinclair sind schon grottig.
Aber sonst sind englische Produkte aus dieser Zeit schon sehr wertig.
-
Dann liege ich ja richtig gut, dass ich einen Coco3 und einen Dragon 32 habe
Oja da liegst du goldrichtig.
Das hab ich auch so, und noch einen Dragon-64.
Alle drei haben ein eigenes CoCoSDC.
Macht richtig Spaß mit dem CoCoSDC.
-
Siehst du die Verbreitung von Tandy im amerikanischen Markt mit beiden Linien, oder speziell dem Coco?
Hab gerade geschaut, ob man gesicherte Verkaufszahlen des CoCo findet ...
Leider finde ich auf die schnelle nichts.
Meine Informationen beruhen auf Aussagen von Tandy Veteranen.
Es gibt immer noch eine sehr lebendige Tandy CoCo Community.
Die sagen der CoCo war in USA sowas wie der C64 hier.
Das lag einfach an der großen Anzahl an Vertriebsstellen (RadioShack).
Tatsächlich bekommt man einen CoCo aus den USA auch heutzutage noch sehr leicht.
Wie bei uns der C64.
Dragons sind da eher seltener zu haben.
-
Für mich stellt sich die Frage, ob der Dragon in irgendwas besser war als der CoCo 1/2?
Der Dragon ist richtig robust gebaut.
Böse Zungen behaupten, er ist klobig.
Mir persönlich passt auch die Tastatur besser.
Die CoCo wirken leichter und verletzlicher.
Der CoCo 1 hat überhaupt nur so eine Folientastatur.
Ich würde mir immer einen Dragon anlachen statt eines CoCo.
Mit Ausnahme des CoCo-3, da gibt es keinen Dragon der dem technisch das Wasser reichen kann.
Die Community ist beim Tandy auch viel größer.
-
Das ist nicht korrekt. Das Design des Dragon32 ging, wie das des Tandy CoCo, direkt auf die Applikationsschaltung von Motorola zurück, d.h. die Firmen haben es sich einfach gemacht und die Beispielschaltung (AN-825: An interactive graphic system using the MC6809) für ihre Zwecke angepasst.
Das ist sehr nett ausgedrückt und im Kern auch sicher wahr.
Und doch, es wurde beim Design des Dragon schon darauf geachtet, dass das Memory Mapping und die wesentlichen Hardware Dinge kompatibel sind.
Es ist kein Zufall, dass praktisch alle Tandy CoCo Programme unverändert auf dem Dragon laufen ...
-
Der Motorola 6809 war sicherlich ein weniger oft verwendeter Prozessor im Vergleich zu Z80 oder 6502.
Er hat insbesondere die Ausführung von relativer Adressierung unterstützt.
Wenn man nur den europäischen Markt von damals betrachtet, dann schon.
Aber am amerikanischen Markt waren die Tandy Computer weiter verbreitet als Commodore.
-
4. Die walisische Herkunft ist wirklich was besonderes, wie auch der Gründer von Dragon Data. Dass eine Blechspielzeugfirma wie Mettoy einen Computer herausbrachte ist genauso ungewöhnlich wie Tandy RadioShack (Lederwaren/Elektronikprodukte), die den TRS80 entwickelten.
Nun ja, es gibt einige Computer aus England.
Die meisten waren aber nur in England bekannt.
Hierzulande hatte man so ohne Internet und ohne Vertriebsnetz auch kaum eine Chance davon zu erfahren ...
Was den Dragon angeht:
- der Dragon ist klasse, ich liebe meine beiden Dragons
- ABER der Dragon ist nur ein Nachbau vom Tandy CoCo, die haben das Designe einfach kopiert
-
3. Keiner scheint wirklich Erfahrungen mit OS-9 gemacht zu haben. Damit war OS-9 wahrscheinlich genauso ein Feigenblatt für professionelles Arbeiten auf dem Dragon, wie es CP/M für viele Z80-Computer (z.B. Amstrad/Schneider) war. Hatte nicht auch der C128 einen Z80? Und wer hat wirklich CP/M darauf genutzt?
OS-9 ist absolut klasse.
Im Vergleich zu CP/M ist das wie MS-DOS zu Linux.
Allerdings konnte nur der CoCo-3 die Leistung von OS-9 richtig ausspielen.
Da hatte man wenigstens bis zu 2MB Speicher.
Allerdings hat Tandy an der MMU gespart.
Diese Billig MMU Lösung ist für OS-9 eine sehr holprige Lösung.
Aber vielleicht hatte Tandy auch recht: der durchschnittliche Homecomputer Benutzer wollte eh kein OS-9 ...
-
Keiner ist auf die grafischen Fähigkeiten des Rechners oder die fehlenden Kleinbuchstaben eingegangen. Im Vergleich zu der Konkurrenz scheinen die schlechter zu sein. Und deshalb war er ein schlechterer Spielcomputer. Immerhin war das einer der Haupteinsatzzwecke
Der CoCo 3 von Tandy ist dem C64 haushoch überlegen, auch in Bezug auf die Grafik.
Das einzige Manko, es fehlen die Sprites.
Aber in Bezug auf Farben, Auflösung und Modi ist der CoCo besser.
-
Der 6809 war kein schlechter Prozessor. Leider wurde das Potential weder von Tandy noch von Dragon oder Entwicklern gehoben. Der Tandy CoCo 3 sei eine Ausnahme. Die will ich mir nochmal anschauen.
Nun ja, "kein schlechter Prozessor" halte ich für stark untertrieben.
Im Vergleich der 6502 und der 6809, -- das ist wie ein Trabi zu einem Mercedes.
Mal davon abgesehen, gibt es den Pin kompatiblen 6309 von Hitachi.
Man kann den Prozessor in jedes 6809 System rein stecken und ist ultimativ happy.
Im Vergleich der 6502 und der 6309, -- das ist wie ein Trabi zu einem Tesla.
- 4 * frei verwendbare 8 Bit Register
- 7 * 16 Bit Register
- die 8 Bit Register können zwei 16 Bit Register formen
- die 8 Bit Register können ein 32 Bit Register formen
- Hardware Multiplikation 2 x 16 Bit --> 32 Bit
- Hardware Division 32 Bit / 16 Bit --> 16 Bit + 16 Bit Rest
- 16 Bit Stack
- zweiter Stack (als User Stack)
- Stack basierte Adressierung, wodurch die CPU sich prima für Hochsprachen eignet
- PC basierte Adressierung
- relative Adressierung über den ganze Adressraum, wodurch Programme relokatibel sind
- Ausgabe des Prozessor Zustand, was ideal für den Einsatz einer MMU ist
- DMA fähig
-
UC-Builder RC v1.13 (Release Candidate)
Der UC-Builder ist ein Kommandozeilen Tool für Windows.
Das Tool dient dazu, Programme in C64 Module zu packen.
Es beinhaltet einen Menü Generator, einen internen File Browser und den Modul Code zum laden und starten von Programmen.
Der UC-Builder unterstützt folgende C64 Modul Typen:
- UC-1
- UC-2
- UC-1.5
- EasyFlash
- MagicDesk
- Hucky-64K
Abhängig vom Modul Typ werden folgende Programme unterstützt:
- 8K Module
- 16K Module (nur UCx und Easyflash)
- UltiMax (nur UCx und Easyflash)
- OneFiler die mit RUN gestartet werden
- OneFiler die mit SYS gestartet werden
- OneFiler die mit RESET gestartet werden
Der UC-Builder gibt zwei Dateien aus:
- .BIN Datei -- diese Datei kann direkt in das EPROM oder FLASH geschrieben werden
- .CRT -- Datei für den VICE Emulator, so kann das Ergebnis direkt getestet werden
.
-
Du brauchst zwei EPROM mit 64k Bytes (27512).
Das PLA hat 16 Eingabe und 8 Ausgänge.
Deshalb passt ein 64k Speicher perfekt.
Es existieren aber auch bessere Lösungen.
Mit CPLD und GAL zum Beispiel.
Die EPROM Ersatzlösung arbeitet ganz ok.
Der CBM tut was er tun soll.
Und doch gibt es manchmal tubiose Dinge.
Nicht wiederholbar, nicht nachstellbar.
Seit ich die EPROM Ersatzlösung umgestellt habe, läuft mein 8296 wirklich fehlerfrei, auch stundenlang.
-
Das VAX-Problem ist damit noch nicht gelöst, und jetzt fehlt mir eine zweite DB50F, um einen zweiten Loopback-Stecker zu löten, denn wenn ich nur einen aufstecke, schlägt der Test im Bootmonitor mit einer kryptischen Meldung fehl.
Ganz früher, zu 486er Zeiten habe ich das Problem mit zwei COM Schnittstellen und einem speziellen Programm gelöst.
Die beiden Signale RX und TX auf jeweils einem RX meiner beiden COM.
So konnte man dem Datenverkehr belauschen und auf das Protokoll rückschließen.
Später hatte ich eine Lösung mit einem Mega AVR.
Der konnte den Datenverkehr belauschen und auch alle sonstigen Signale beim RS232.
Diese Lösung konnte sogar Baudrate ermitteln und bei Bedarf ohne PC arbeiten, indem es alles auf SD aufgezeichnet hat.
Heutzutage macht man das einfach mit dem LA.
Das funktioniert mit RS232, I2C, SPI und viele andere Dinge.
-
Das VIA war defekt? Hätte nicht erwartet. Schön dass du es gefunden hast!!
-
Also reagiert die Floppy auf Befehle?
Oder kommen Blinksignale an der LED?
Wenn man den Diskstatus abfragen kann, dann ist die CPU Platine wohl in Ordnung und es liegt "nur" an dem analog Teil.
Für den Analogteil gibt es im Service Manual beschriebene Messpunkte.
Hast du ein Multimeter und ein Oszi?
-
Es gab mal hier eine Diskussion über einen Apple II Nachbau.
Leider kann ich den Faden nicht mehr finden ...
Nun macht das einer zur Realität!
Der Macher nennt sich auf YouTube: DrMattRegan
Es gibt zahlreiche hoch interessante Videos von dem Mann:
- Selbstbau von Grafikarten (VGA etc.)
- TTL CPU's
- universelle CPU durch Microcode Programmierung
- 6502 als TTL CPU
- 6502 Mini System
- ...
Aus den Diskussion unter diesem Video geht hervor, dass es demnächst PCB und Anleitung geben wird:
https://www.youtube.com/watch?v=zwSVNcuYhy4
Der Clou: der Apple II+ braucht keine 6502, auch die ist mit TTL realisiert.
-
Es scheint, bei Zimmers gibt es nur DE und keine US Version.
Gab es denn den 8296 nur in Deutschland?
Nun ja, man kann sich das große EPROM ja aus den einzelnen ROM zusammenbauen.
Vermutlich muss man ja nur das Editor ROM ersetzen im Standard ROM.
Wahrscheinlich funktioniert jedes Editor ROM vom 8032.
Testen kann man das ja im VICE.
===
Übrigens gibt es einen genialen Kernel vom Benutzer Bit Shifter: BSOS-8296: BSOS 8296
-
Schönes Gerät! Ich liebe diese letzte Generation der CBM-1.
Ah die PLA ist ersetzt durch ein EPROM.
Das zweite PLA (UE6) ist noch original.
Wenn ich mich recht erinnere hat der 8296 nur ein EPROM, da ist alles drin: Kernal, BASIC, Editor ROM.
Also musst du nur das für dich passende nehmen.
Zusätzlich gibt es ein ROM für das Charset.
Wahrscheinlich sollte das auch getauscht werden, denn der US Typ hat ja keine Umlaute.
-
Endlich habe ich wieder etwas Zeit für eine neue Version des UC-Builder.
Es stehen schon seit längerer Zeit ein paar neue Features an:
- Unterstützung für die Hucky 64K Cartridge
Die Hucky 64K Karte ist weit verbreitet, technisch gesehen ist sie ähnlich wie eine MagicDesk mit 64K.
Unterstützt werden OneFiler und 8K Cartridges direkt aus dem ROM.
Optional kann man den File Browser FB im Menü einbinden.
Der UC Builder kann auch ein Hucky CRT File für den VICE erstellen.
So kann man die Images auch vorab im VICE direkt testen. - Dump eines Image File in mehrere UCF Dateien
Eine UC Image Datei kann nun wieder "zerlegt" werden.
Für jedes Programm im UC Menü wird eine UCF Datei erzeugt.
Die UCF Dateien können dann wieder verwendet werden, um neue Image Dateien zu erstellen.
Vorteil: Die UCF Dateien brauchen keinerlei Angaben im CSV File, alle Informationen sind bereits im UCF File vorhanden.
Einschränkung: Die Image Datei muss die Version 1.13 oder höher haben, von alten Image Dateien kann kein UCF Dump erstellt werden.
. - Unterstützung von UCF Dateien
Aus einer Sammlung von UCF Dateien kann man sich auf einfachste Art und Weise neue Image Dateien erstellen.
UCF Dateien können genau so wie CRT Dateien vom internen FB geladen und ausgeführt werden werden.
Eine Sammlung von UCF Dateien auf einer Diskette oder SD Karte sind also einfach ausführbar.
Einschränkung: Die UCF Datei läuft nicht auf jeder Cartridge Hardware, da gelten die normalen Beschränkungen. Auf UC Module läuft jede UCF Datei.
. - Menü Einträge als Textzeilen
Bisher war jeder Menüeintrag ein ausführbares Programm.
Nun sind auch Textzeilen zugelassen.
So kann man den Aufbau des Menü optisch frei gestalten
Wiki: https://oe7twj.at/index.php?ti…_Cartridge#Der_UC-Builder
- Unterstützung für die Hucky 64K Cartridge
-
Der Preis ist etwas ambitioniert.
Oja!
Um 125€ bekommt man ja fast schon den Nachbau des HP-42 ...
-
Das "jeglicher Kopierschutz mitkopiert wird" halte ich etwas für übertrieben.
Nun ja, beim C64 / 1541 sieht man eigentlich, dass man ohne besondere Hardware JEDEN Kopierschutz mit kopieren kann.
Es genügt eine normale Standard 1541.
Und ein Nibble Copy (MNIB).
Der Beweis, das Disketten Image (G64) läuft auf dem VICE.
Das Problem ist also nicht das LESEN.
Das Problem ist immer das SCHREIBEN.
Wir sind in der Lage alle original Disketten samt Kopierschutz zu kopieren.
Wir können es aber (in vielen Fällen) nicht ohne Spezial Hardware zurück schreiben auf eine Diskette.
-
Danke für den Tip. Bin eh schon drüber gestolpert. Ist das eigentlich open source? Schaltplan hab ich gefunden jeoch keinen code.
-robert
Da bin ich etwas überfragt ob das Open Source ist.
Mir wurde das CoCo SDC in einem englischen Forum empfohlen als ich nach DriveWire gefragt habe.
Ich hab eines aus Amerika geordert und war so begeistert, dass ich nochmals zwei aus England gekauft habe.
Jetzt haben alle meine Schätzchen je ein eigenes.
Seither liegen die Floppy Laufwerke im Kasten, es ist ein vollwertiger Ersatz und noch viel mehr.
Von DriveWire gar nicht zu reden, ist mir viel zu umständlich.
