Beiträge von kmg

Der Emic 2 ist auch gut, der serielle Anschluss wäre sogar noch besser. Eine Hörprobe der wav-File klingt sogar recht gut - mich stört jedoch, dass nur English und Spanisch als Sprache möglich sind. Englische Phoneme fuer deutsche Texte zu nehmen dürfte ein recht schwer verständliches Ergebnis erzeugen. Können die Phonem-Daten des Talker-80 ausgetauscht werden ? Im Ordner /Talker-80-master/src/atmega644 gibt es einige *.h Files die das vermuten lassen.

Die Dinge sind leider doch etwas komplizierter: Mein erster Gedanke war, den Talker-80 über einen 8255-IO Port zu steuern (Mein CP/M-System besteht nur aus einem FPGA plus 8255-PIO). Dann muß die Software aber vermutlich anders ansteuern, d.h., Signale wie n_WR & n_RD etc. müssen per Software gesteuert werden, damit es geht. Grundsätzlich sollte das aber kein großes Problem sein, solange der Datenfluß stimmt oder ?

ganz schön abgedreht ! Da ich aber weder einen TRS80-M1 noch M3/M4 besitze gleich die Frage: ginge das auch für CP/M ? Im zip auf Github sind alle Basic-Progs tokenized bzw. als *.cmd Programme enthalten. Das ist etwas hinderlich. Läst sich das offener gestallten, d. h. als ASCII bzw. im source ?

hier gibt's die Würfel auch einzeln für knapp €30.-- inkl. Versand:

PANO-Würfel Typ G1 für PANO-Z80

Meiner hatte einige Lackschäden u. eine Stoßstelle. aber das tut dem Würfel keinen Abbruch. Lieferzeit war ca. 1.5KW bis vor die heimische Tür.

Zitat von Creep

Ich selbst habe bisher z80pack Diskimages zum Testen benutzt. Interessanter sind sicher die multicomp Images. Aber hier ist die Rede von 8MB img Files. Weiß darüber jemand mehr? Ich kenne nur ein deutlich größeres SD-Card Image, was wahrscheinlich aus den Diskimages einfach zusammengesetzt ist. Kann man die cpmtools nutzen, um multicomp Images zu erstellen/bearbeiten? Ich würde mir gern ähnliche Images basteln wie für den Z80-MBC2.

Soweit mir bekannt, hängen die 8MB pro Disk mit CPM2.2 zusammen. Dort gehen max. 8MB als Höchstgrenze. Der Wert im Weiteren ist eine Übereinkunft (bei den Multicomps), damit die Disk-Images unter allen CPM-Versionen nutzbar sind. CPM3 koennte mehr, aber eben nicht CPM2.

Wie das mit den Disk-Images am besten geht, wurde im Retrobrewcomputers Forum von Rienk Koolstar beschrieben. Ich hab' mir das als pdf rausgezogen, nur leider finde ich im Augenblick den File nicht Sobald ich ihn gefunden habe, stelle ich ihn ein.

=> leider nicht wieder zu finden, aber ich habe eine passende Kurzbeschreibung gefunden:

Card layout:

sector --------------------------------------------------------------

0 the first 8 Mbytes unused: \ Put partition table here

16384 8MB volume 1 | if desired.

32768 8MB volume 2 |

49152 8MB volume 3 |

= . |

= . | 2 Gbyte maximum reserved memory

1949696 end of 1 GB card, or |

= . |

= . |

4161536 8MB volume 254 (RAMDISK) |

4177920 8BM left unused (disk -1) /

4194304 unused space to be formatted as FAT partition

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

Unter Linux könnte man dann mit dd das Gesamt-image in Disks zu 16384 Sektoren zerlegen bzw. ein neues durch aneinanderfügen der einzelnen Disks zusammenbauen. Unter Windows sollte es auf ähnliche Weise machbar sein.

=> doch noch gefunden, man sollte spät Nachts nichts suchen

Klingt vielversprechend. Bin gespannt wie sich das Board so im Detail schlägt.

Wenn's nur nicht so heiß wäre. Da ich mein "Rechenzentrum" auf dem Dachboden habe, ist an langere Computerei bei derzeit ~30°C (volle Südweite, trotz offener Dachfenster) nicht so recht zu denken. Vielleicht regnets morgen ja etwas, der Garten kann's brauchen, gezieltes gießen reicht bald nicht mehr.

Mitunter geht's schnell, 2 Lösungen - 1 "totes" Problem: Das Thema 'Multi-Pak' kann ich abhaken, denn dazu bedarf es eines echten CoCo3, welchen ich selbstredend nicht besitze. Besagtes Pak-Interface sieht so aus:

Damit sind auch die Menüpunkte unter F12 erklärt. Das Interfacing von Wifi & Clock existiert unter Plan-B in identischer Weise, weshalb es sinnvoll ist, ersteinmal mit dieser Baustelle weiter zu machen. Als Schnittstellen begegnen mir dort I2c und RS232, beides bekannte Gegener und kein USB-Controller, dessen Interface ich nicht kenne. NitrOS9 ist schon arbeit genug, da darf's an anderer Stelle ruhig übersichtlich sein...

Zitat

Vielleicht sehr der Core das Dann um, es wird ein mögliches PAK aus dem USB Device.

Keyboard, Joystick und Maus funktionieren ja auch auf diese Weise.

Also Wifi am USB-Port sähe dann so aus (s. Bild). Das Wifi-Modul wird seriell angesprochen, bedeutet: RS232-Pak ? Wenn ja, wie ziehe ich NitrOS9 die Information aus der Nase, welche Pak's erkannt wurden/aktiv sind bzw. was das OS von der an den USB-Buchsen angeschlossenen Hardware so hält/erkennt ? Hier wäre jetzt der Ball im Spielfeld vom Sidi-Wiki (wegen der Pak's). Vermutlich reicht das "Gestecktsein" allein nicht aus, wie immer fehlt die Wunderwaffe "Anwenderprogram mit Treiber" auf ganzer Linie. Bezüglich einermöglichen Antwort werde ich jetzt als nächstes die ungeliebten Handbücher konsultieren - die ja meist keiner liest (oder erst ganz am Schluss). Bin gespannt, was sich da so finden läßt.

Ein Uhren-Modul ließe sich übrigens auf ähnliche Weise an den Start bringen, dann aber als USB-auf-I2C - Lösungen gibt's genug, wo sind die Probleme...

Zitat

Nee, die PAK sind einfach Module.

Da wird nichts angeschlossen über USB.

Der Core implementiert einige dieser Module, so wie das FDC.

Man kann es ein- und ausschalten.

Danke für den Hinweis, das bringt etwas Licht ins Dunkel. Alle Paks habe die gleichen Menüpunkte, u.a. BT (Bluetooth ?) und WiFi (?). Das kann man schlecht intern implementeren, daher ja meine Verwirrung. Wifi wäre schon schön, Datum & Zeit per ntpserver käme meiner Tipfaulheit entgegen... Das in dem kleinen Kästchen das Uhrenmodul fehlt, ist schon ein misslicher Umstand.

Ja, der CoCo3FPGA ist eine tolles System, setzt aber neben dem DE1-Board selbst (wird seit Jahren nicht mehr gefertig) das Analog-Board voraus. Letzteres fehlt mir und damit die Uhr und das Wifi-Modul. Ich hatte schon mal angefangen, das Analog-Board für Durchsteckbauteile neu zu entwerfen, dass dann aber wegen meines Z80 CPM System wieder auf Eis gelegt, damit war ich genug beschäftigt.

Beim Durchforsten des Sidi-Wiki's bin ich auf diesen Link gestoßen:

https://github.com/eubrunosilva/SiDi

Die Cores sind zwar alle vom januar diesen Jahres, aber zwei sind trotzdem Interessant: Grant's Multicomp (als Mikrocomputer getarnt) und ein TRS80 Core (welches Model steht nicht dabei, Verdacht: Model-1). Damit hätte ich alle meine "Sünden" der Vergangenheit als Retrosysteme im Sidi vereint...

Ich mußte wegen Tea-Time unterbrechen,... gut. Beim Sidi gibt es im F12-Menü für den CoCo Menüpunkte für Hardware-Packs !. Einzig mir ist unklar, wie das zu nutzen ist, gibt es doch außer den USB-Anschlüssen nichts, wo man was wie Cartridges anschließen könnte - oder gibt es USB-Caddies für Cartridges ? Fällt mir schwer zu glauben, der Original-CoCo3 hat m.W.n. keine USB-Buchsen gehabt

Oder kommt da bei Manu Ferghi vielleicht noch was nach ?

Ich habe etwas mit den NitrOS9-Dsk (6809/6309 u. L2/l3) experimentiert. CPUTYPE (NitrOS9-L2/6809) sagt zwar 6309-CPU im 6809-Modus, NitrOS9-L2/6309 verendet dann aber mit einem Bildschirm voller Text wie "l3l3l3l3l3l3..." und es geht außer Reset oder F12 nichts mehr. Übersehe ich da irgendetwas ? Ist für mich eigentich keine Katastrophe, es gibt auch so noch genug zu lesen/zu erkunden/auszuprobieren, da ist der 6309 erste einmal nachrangig (obwohl, da stimme ich dir zu, ein sehr interessanter Kandidat).

Ich stehe da erst am Anfang, aber wie kommt man eigentlich ohne allzu heftige Verenkungen zu, sagen wir mal 30-120MB großen boot-fähigen HD-Images mit NitrOS9 drauf ? Gefühlt tendiere ich eher zu 30MB, denn unter CPM3 habe ich bei 8MB regelmäßig ~200 Dateien auf der Disk. Das auf 30MB hochskaliert, ergibt genug Spaß beim suchen...

Zitat

Der Core kann eigentlich alles, was es so an gängigen Hardware Erweiterungen für den CoCo-3 gibt.

Inklusive Sound Cartriges mit 16bit Stereo usw.

Auf jedenfall interessant, wie flanscht man bei dem Board denn diese externe Hardware dran ? Soll das über das Pad-Feld erfolgen. Im Wiki ist dazu nichts erwähnt !

Zitat

Erstaunlich finde ich, dass nur der SiDi es Wert findet, den CoCo Core zu erwähnen.

Bei Mist und Mister sieht man in der Core Auflistung nur den TRS-80 1 (Z80) und keinen CoCo.

Ich meine irgendwo gelesen zu haben, dass das eine extra angestoßene Community-Entwicklung ist, könnte sein, das Manuel Ferghi der Initiator ist (und damit ev. eine gewissen Exklusivität besteht). Aufgefallen ist mir das auch schon.

Zitat

Man kann jedes zugängliche File im lokalen Netz oder auch im WWW direkt zugreifen.

Wie wenn es lokal auf einer Diskette wäre ...

Das macht Cross Development zu einem bequemen Vorgang.

Hört sich sehr gut an.

Damit liegst Du sicherlich genau richtig. Gab es da in der Vergangenheit nicht diesen Wettstreit der Paradigmen: "Think Big" vs "Kiss" (Keep it stupid simple ) ? Ersteres diente dazu, sich unersetzlich zu machen, letzteres, damit es garantiert verstehbar u. zuverlässig funktioniert. Die 8-bit Fans gehören sicherlich alle zur Kiss-Fraktion.

ups..., meine letzten Ausführungen sollten keine Kritik am Tempo von Floppies, CPU's etc. sein. Es ist wohl mehr dem heutigen Zeitgeist geschuldet, der bereits mit den Füssen scharrt, sobald etwas länger wie eine 10tel Sekunde dauert. Da man selbst ja die Temponöte von damals kennt (erinnert ?), beschleicht einen schon eine gewisse Verwunderung (eingedenk der heutigen 'schnellen Zeit'), wie man das so erdulden konnte... Nein, ganz im Gegenteil, ich finde es faszinierend, wie aus heutiger Sicht die damaligen Möglichkeiten so beschleunigt werden können, sodaß sie wieder (erneut) in den Fokus rücken ohne den alten Flair dabei zu verlieren (runtertakten geht schließlich immer, wenn man's 'echt' haben will).

In Hinsicht auf kompakten Code gebe ich Dir recht, da wird heutzutage nicht so drauf geachtet. Wichtig ist da schon eher, ein möglichst großes Funktionsportfolio auf die Beine zu stellen. Ich erinnere mich noch gut daran, das es schon fast ehrenrührig war, Programmcode nicht zu optimieren und so kompakt wie möglich zu halten. Assembler war das Mittel der Wahl und bei den Hochsprachen an forderster Stelle FORTRAN - wurde im erzeugten Code als sehr effizient und schnell gehandelt (bitte keinen Meinungsstreit, mir ist bewußt, dass das alles Ansichtssache ist).

Man ist halt Kind der heutigen Zeit und sieht die Dinge von damals entsprechend - ich tue das zumindest nicht im negativen Sinne, sonst würde ich mich nicht so begeistert damit beschäftigen. Das dabei mit beschränkten Resourcen (max. Codegröße, 64kB, wenige MHz,...) dennoch beachtliches auf die Beine gestellt werden konnte, betont eher den Wert der geleisteten Arbeit. Vielleicht ein Grund, warum die Retrocomputer Scene derzeit so brodelt, das was alles so geht (mit dem alten Kram ), begeistert.

Wohl war...

Habe gerade einen Server im Web aufgetan, der fertige NitrOS9 L2 V3.3.0 Dsk-Images für den CoCo3 hat. Damit steht mir endlich ein "Vergleichsnormal" zu Verfügung.

https://nitros9.sourceforge.io/snapshot/

Während OS9 beim CoCo3 Bildschirmformat bleibt, was eher abschreckt, schaltet NitrOS9 gleich auf angenehme 80x?? um. Das quadratische Format geht auf rechteckig über, was deutlich ansprechender ist und den Zeichensatz wesentlich lesbarer werden läßt. CPU-Takt: ja, bei 25MHz wird das System sehr kurz in den Antwortzeiten sein. Die lame Reaktion von OS9 (um 1980) war, soweit ich mich erinnere, ein großer Kritikpunkt. Das dann auch noch in Verbindung mit einem Floppy-Laufwerk, aber warum die Geister der Vergangenheit wecken...

Tja, jetzt heißt es Handbücher lesen, bei dem Befehlssatz/Leistungsumfang geht's nicht anders. Auf jedenfall finde ich meine Erwartungen bestätigt. Damit steht Plan-B (Multicomp6809) ganz oben auf der Todo-Liste, da hardware-seitig bei meinem System alles vorhanden ist, was der CoCoDEV auch hat - bis auf das SPI-Flash ROM, aber das kann man nachstricken wenn man's braucht. Plan-C (CoCoDEV) als zweites - als Alternativ-Projekt (zumal wenn's schon fertig aufgebaut ist).

Mir deucht, dass es für den Rest des Jahres reichlich zu tun gibt - es bleibt also spannend...

Die ROM-Größe stimmt also, superund Danke für's nachschaun. Es paßt also alles irgendwie zusammen...

Der Preis für den CoCoDEV finde ich überzeugend, sehr gutes Preis/Leistungsverhältnis. Danke für die Auskunft, da fällt es schwer zu widerstehen...

Na, manchmal zahlt sich Ausdauer doch aus. Es gibt einen reproduzierbaren Weg ins Disk-Basic !, wenn denn nur das Readme besser gewesen wäre...

Also: es wird der mitgelieferte Core zum CoCo3 benötigt - schon mal gut. Das ROM "COCO3.ROM" muß wie beschrieben auf die SD-Karte ins Root-Verzeichnis: ich habe alles in Kleinbuchzustaben umgeschrieben (also 'coco3.rom'). Ein 'DISK21.ROM' wird NICHT benötigt. Damit hatte ich es anfangs versucht !, geht aber NICHT.

Als nächstes ist die 'mist.ini' anzupassen (ist im Root-Verzeichnis zu finden):

[mist]

scandoubler_disable=0 ; set to 1 to run supported cores in 15khz

joystick_remap=0079,0006,1,2,4,8,200,20,10,100,400,800,0,0,40,80,0,0

[coco3]

rom=coco3 ;Das Diskbasic ROM aus dem Github Repository zum CoCo3

Die letzten beiden Zeilen sind nachzusetzen und entscheidend. Die Extension '.rom' muß entfallen, die hängt der ARM-Controler selbst dran ! Der zu bootende Core des CoCo3 ('coco_SiDi_20200518a.rbf') kommt ins Verzeichnis 'computer'. Das F12-Menü zeigt diesen dann unter dem Auswahlpunkt 'computer' entsprechend an und ist mit <cr> zu selektieren bzw zu starten. Nach etwas gerötel erscheint der Disk-Basic Prompt. Desweiteren habe ich im Root-Verzeichnis einen Ordner 'CoCo3' erstellt, in dem die DSK-Images abgelegt sind. Über F12 kann dieser Ordner besucht und ein Image ausgewählt werden. Alles weitere geht dann wie gewohnt: 'DIR' zeigt den Disk-Inhalt an etc....

Morgen gehts' weiter. Einige Punkte sind da noch offen...

Emulatoren sind mir zu "synthetisch". Ich habe hier einen xtrs mit TRS80-M1/M3/M4 installiert. Läuft super. Aber mir fehlt die Hardware dahinter und die Möglichkeit daran was zu ändern. Ein geeigneter Emu wäre beim CoCo3 auch ein Weg, aber siehe xtrs...

Kannst Du die Größe der ROM Images von Ext. Color Basic & Disk Basic ermittel ? Das beim Sidi mitgelieferte CoCo3-ROM hat 41kB, das ist ungewöhnlich groß, zumal alle ROMs die man sonst so findet meist 16kB groß sind.

Ich denke mal, das Roger jetzt ran muß. Ich hätte zumindest gern gewußt, ob Abhilfe möglich ist oder nicht. Egal wie's ausgeht, ich werde meinen Plan B wiederbeleben und damit parallel weiter machen. Der hat ebenfalls NitrOS9 zum Ziel, aber auf vorhandener Hardware.

Kannst Du es "verantworten" den Preis für den CoCoDEV zu nennen ? Wenn der Preis moderat ist, könnte ich mich ev. überwinden. Mein letzter ruinöser Spontankauf (SX-1) war etwas zu ausufernd - auch wenn ich im Nachherein davon begeistert bin.

ja, der Core enthält einen FDC, Man kann über F12 Disk-Images laden, ebenso Cartridges und andere ROM's. In der mist.ini muss das zusätzliche ROM in der [coco3] Sektion (muss man hinzufügen) eintragen - so sagt es zumindest das Sidi-Wiki. ABER, und das ist das verwirrende, genau das habe ich mit dem Disk-Basic ROM (Quelle s. meinen Post) gemacht und es gelang nur 2 mal (und das nicht nachvollziehbar !!!) so ins Diskbasic zu starten. Alle male danach kam nur ein "ok" Prompt, Diskzugriff ging trotzdem nicht ("?SN ERROR") und das war's (Reset etc. brachte nichts mehr, nach Kaltstart wieder "Ext. Color BASIC 2.0" Prompt). Wenn man einmal von dem reichlich kurzen Readme zum CoCo im Github Archiv absieht (keine Details wo was hingehört oder zur "mist.ini" und was da reingehört, außer eben "soll auf die SD-Karte"), wäre meine Vermutung, das etwas mit dem Core noch nicht so läuft wie gedacht (Core = 20200518b). So wie's jetzt ist, weis ich mit meinem Sidi in Sachen CoCo3/Dsiketten u. NitrOS9 nicht weiter, eigentlich wäre jetzt Roger Taylor gefragt, er hat den Core ja gebaut und an den Sidi adaptiert.

Wie verhält sich Dein Sidi beim CoCo3 ?, müste ähnliche Ergebnisse liefern, den der Core ist ja seit 2 Monaten unverändert (auf Github).

Mit dem XRoar Emulator war ein CoCo2 mit NitrOS-9 L1 wenn auch extrem träge (wegen der Disketten-Emulation) möglich. Auf dem Sidi komme ich nicht über die Boot-Meldung "Extended Color-Basic 2.0" hinaus. Unabhängig davon, ob ein Disketten-Image geladen ist (ich habe von https://colorcomputerarchive.c…k%20BASIC%202.1/Original/ einige .dsk-Files genomment). Laut Disk-Basic Handbuch sollte dann als Boot-Meldung "Disk Extended Color Basic..." ausgegeben werden, was aber nicht der Fall ist. Kommandos wie DIR oder DOS enden stets mit einem "?SN ERROR" oder anderen Rrror-Meldungen. Das Readme zum Core ist nur ein Einzeiler und weist nur darauf hin, das COCO3.rom und den .rbf File auf die SD-Karte zu schreiben sind. Ich habe alles unter dem F12-Menü durchprobiert, komme aber über die "Extended Color-Basic 2.0" Meldung bzw. ein schnödes "OK" nicht hinaus. Es ist gut möglich, das ich mit einem falschen Verständnis an die Sache heran gehe, der CoCo3 ist Neuland für mich. Es ändert sich auch nichts, wenn ich alles was *.rom ist weglasse und nur den .rbf File stehen lassen. Es scheint, als wenn das ROM im rbf-File enthalten ist, denn die genannte Boot-Meldung kommt trotzdem !?.Kann mir da jemand mit tiefergehenden CoCo3-Kenntnissen weiterhelfen ?, dass es gehen muß, habe ich in einer Beschreibung des Sidi/CoCo3-Core gesehen (http://www.cococommunity.net/m…ga-coco-3-in-development/). Die dort gezeigte Boot-Meldung kam vom Disk-Basic ! Zur Konfiguration wurde aber nichts gesagt - leider.

Das Video spricht eindeutig den Bastler an: 'Pick and Mix'. Wenn's nicht viel kostet - und davon gehe ich einmal aus, das meiste sieht aus wie gehorteter Schrott - dann das erstandene anschließend bis auf die Knochen ausschlachten und der Rest wandert endgültig in die Schrott-Tonne. Soetwas ist eindeutig nur was für Leute, die daraus Honig saugen können..., Flohmarkt total.

Das Video sollte "strafbewehrt" sein (also Hände in die Taschen und die Maus nicht anfassen dürfen), denn er hat Suchtpotential und animiert zu 'ruinösen Spontankäufen' auf eBay... Hätte nie gedacht das es noch so viel von dem alten Rechnerzeugs gibt.

Ich mußte zusammenpacken, es war Tea-Time... Widerspruch war Zwecklos ! ;-))

Das BIOS-Setup neu zu erstellen war erste Amtshandlung, die Platte konnte man aus einer umfangreichen Liste auswählen. Was ev. auf ihr an Geometriedaten steht (wenn...), habe ich nicht kontrolliert. Läßt sich beim nächsten Versuch nachholen. Ins Floppylaufwerk muß ich ja eh sehen, um festzustellen was da so "emsig am Rad dreht". Das "multible Organversagen" kam tatsächlich etwas überraschend.

Die Floppy muß wieder laufen, vielleicht kann man dann mittels DOS Boot-Diskette mehr erkennen bzw. den HD-Zugriff testen. Ohne Diagnostik-Möglichkeit ist das alles wie Negerkampf im Tunnel.

So, der Uhrenchip Austausch ist durch, leider mit gemischtem Ergebnis. Er startet wieder, man kommt jetzt auch wieder ins BIOS-Setup, ...aber er bootet nicht mehr von der HD. Ab und an kommt auch mal die Meldung "Loading DOS...", dann ist sense. Die meisten Startversuche enden jedoch mit der Meldung, das ein HD-Controller Diagnostic Fehler erkannt wurde (???). Die Platte startet, es wird wohl auch was gelesen, aber dann scheint der Loader (oder was auch immer) per Absturz zu verrecken. Der Vorbesitzer (ein ehemaliger Arbeitskollege) hatte die HD komprimiert betrieben, um mehr Daten drauf zu bekommen (120MB Platte). Kann gut sein, das im Uhren-RAM irgendwas abgelegt war, was jetzt weg ist und die komprimierten Daten nicht ausgepackt werden können (nur eine Vermutung, was da nun tatsächlich nicht mehr funktioniert weiß der Kukuck). Andere Baustelle ist das Floppy-Laufwerk. Scheint eine Version mit Seilantrieb zu sein. Man hört wie ein Motor recht fleißig dreht, aber ganz so als wenn die Last fehlt. Auch vermisse ich das typische Geräusch, wenn die Fensterabdeckung (bei eingelegter Floppy) für den Schreib/Lesekopf beiseite geschoben wird. Ich würde sagen: eins gewonnen, zwei verloren...

Den Ausbau des Uhrenchips betreffend, habe ich nach ersten "Grabungsversuchen" recht schnell beschlossen, dass das so nichts wird (Bild (1)). Die beiden freizulegenden Anschlußpunkte lagen sehr tief im Verguß, vom Dreck den das machte ganz zu schweigen Also die Fräse beiseite gelegt und das Mainboard kurzerhand ausgebaut. Display, HD, Floppy und Mainboard sind ein Modul. Im Grunde mußte also nur die Unterschale entfernt werden und schon kam man wunderbar an den Uhrenchip heran (kein Foto wegen zu schlechter Ausleuchtung). Entlöten der Pins habe ich garnicht erst in Betracht gezogen sondern Gleich einen Fässchnitt auf der zur Platinenkante hin liegenden Seite ca. 1.5mm oberhalb der Gehäuseunterkante des Uhrenchips gelegt (Bild (2)). Den schmalen Grad konnte man leicht abbrechen und hatte dann freie Bahn auf die Pins. Mit einem geeigneten Seitenschneider diese durchzukneifen, war schnell getan, die anderen Pins dann durch mehrmaligen biegen abbrechen und schwubs war die schwarze Box frei von ihren Verpflichtungen (auch Bild (2)). Die Pin-Reste noch auslöten und die Löt-Pads vom Lötzinn zu befreien ist schon fast ein Selbstgänger. Bild (3) zeigt die einbaufertige Situation. Bild (4) dann die Situation "Missetat vollbracht". Was dann kam steht ja weiter oben beschrieben.

Damit stehe ich wieder am Anfang. Wann ich versuchen werde, das Floppy-Laufwerk wieder benutzbar zu machen, lasse ich mal offen. So wichtig ist die TARGA-Kiste nun auch nicht. Ich habe glücklicherweise zwar noch WIN3.1 Disketten bei mir gefunden, aber inwieweit das reicht ohne ev. die speziellen Treiber die üblicherweise bei Windows noch benötigt werden, ist ohne intaktes Floppy-Laufwerk eh' nicht feststellbar. Der Rechner hat kein Wifi oder USB, kann auch nur von HD oder Floppy booten, was die Möglichkeiten generell stark einschränkt. Tja, Schitt happens... Museal halt =:O)

Ist ja auch nicht wie bei den Bestellungen in China, Spanien liegt da quasi gleich um die Ecke...

Waren die Scart-Kabel etc. mit dabei oder sind die extra mitbestellt ?

Ich laß' mich gern überzeugen...

Appropos Toolchain: mir fallen da ad-hoc nur BASIC (für Nitros9 (?) ) und AS9 (für PC) ein. Für den CoCo gibt es wohl auch noch andere Sachen, aber da habe ich bisher nicht so genau hingesehen. Die letzte Zeit war ich ausschließlich in Sachen CPM unterwegs und habe passende Treiber (RSX) zur Hardware erstellt. Macht einfach keinen Spaß, wenn sich die kleinen Extras nicht nutzen lassen.

Generell ist es schon so, das ich auch für den 6809/NitrOS9 auf meinem System bleiben möchte. Da habe ich eine hinreichend große Schnittstellenvielfalt und somit Raum zum 'externen experimentieren'. Alles andere sollte sich entweder in VHDL oder Software abspielen. Zum Glück hat Dave mit seiner Hardware wohl ähnliches im Sinn, da paßt dann wieder so manches zusammen. Neal Crook pflegt auf Github (https://github.com/nealcrook/multicomp6809) sein Multicomp6809 System. Da meines die gleichen Wurzeln hat, ist die Adaption nicht allzu aufwendig. So gesehen der unmittelbare Konkurent zum CoCoDEV (für mich irgendwie die bessere wahl, wegen der vielen Gemeinsamkeiten, man kennt sich im VHDL-Code halt schon aus).

Das ist das was mich im Augenblick so umtreibt, nur..., passen die letzten aktuellen Beiträge eigentlich noch zum anfänglichen Thema ? Ist zwar in gewisser Weise noch 'MC6809EP SBC...' aber irgendwie verändert sich die Zielsetzung, wäre ein neues Thema zu starten da nicht besser ?

Es kommen leider auch SMD-Bauteile neben THT Komponenten zum Einsatz. Ein Bausatz scheidet damit für mich aus (zu frickelig), bevorzugt sind definitiv bedrahtete Komponenen (meine gesamte 'Lagerhaltung' besteht aus THT). Da ich bereits mehrere FPGA-Rechner habe (neben dem Sidi) hat eine Erweiterung der Sammlung ersteinmal keine Priorität, eher schon die Adaption an mein eigenes FPGA-System. Das läßt sich aber immer noch klären, denn mir geht es in der Hauptsache um die Kombination 6809/NitrOS9, das ist aber auch mit dem Sidi machbar. Alles weitere ergibt sich dann, seine Mail-Adresse steht ja im Manual auf der ersten Seite...

Ich bin auf Deinen Bericht gespannt.

Um auf's Threat-Thema 6809-SBC zurück zu kommen, in Beitrag #12 klingt an als gäbe es (inoffizielle) Informationen zum Preis, den Dave Philipsen für seinen CoCoDEV so im Sinn hat. Ist sein System Kaufware oder ev. Open-Source ? Die Ausführungen im zugehörigen Wiki klingen auch für mich vielversprechend, zumal er nicht eng am CoCo bleibt sondern sich etwas davon löst und mehr Gewicht auf funktionale Anwendung legt (inkl. NitrOS9 als OS). Die Möglichkeit bis zu 1000 Volumes auf einer SD-Karte mountbar zu verwalten triggert mich besonders. Gleiches steht mir bei meinem CP/M3-System ebenfalls zur Verfügung und ist ausgesprochen praktisch.

Das Kistchen hat was, ich war überrascht, wie gut die einzelnen Implementationen der Retro-Rechner funktionieren. Muß eine Menge Arbeit drin stecken. Besonders angenehm ist, das man nicht mehr auf die 3.5" Disketten angewiesen ist, stattdessen werden die Images auf die SD-Karte geschrieben und von dort geladen. Gleiches gilt für emulierte HD's.

Es ist eine konzeptionelle Entscheidung, mir fehlt der Stellplatz. Der Sidi mit 8" Bildschirm, Tastatur, Maus und Netzteil ist schnell auf- und abgebaut. Für meine Bedürfnisse ideal - und keine Diskettenkästen mehr, kann man alles auf dem Laptop oder ext. USB-HD vorhalten.

Danke für die vielen Infos. Der Tip mal unter die beiden Label zuschauen & "Dallas DS1287" zu finden war genau richtig. Hab' in der "Mittagspause" kurz gegoogled und u. A. einen Link auf einen Threat von 2012 gefunden, in dem 'mein' Problem schon einmal behandelt wurde. Zusammen mit den heutigen Infos bin ich jetzt gut aufmunitioniert und es kann los gehen. Per Taschenlampe auf's Mainboard geleuchtet ist gut zu erkennen, das es eine multilayer Platine sein muß. Die Masselage zeichnet erkennbar gut ab. Ich denke, den Baustein auszulöten, könnte schwierig werden, zumal ich den Laptop erst einmal zerlegen muß, um an das Mainboard zu kommen. Da ich passendes Werkzeug zum fräsen habe (ist auch schon gute 32 Jahre alt, dieses museale Zeug, man weis nie wann es wieder wichtig wird ), entscheide ich mich fuer den 'archeologischen' Weg und werde die beiden Kontaktpunkte an der Flanke freilegen. Die beiden Links von Toast_r werden mir den Weg weisen... So'n ähnlichen Satz gab es doch schon mal irgendwo ?

Ich melde mich zurück mit hupen, wenn's geklappt hat, mit Glockengeläut, wenn er in die Tonne muß =:O)