Posts by StefR

    Sieht schwierig aus. Die TOS-Roms habe ich bislang noch nicht ausgelesen, das wird der nächste Schritt sein, aber zum großen Teil durchgemessen.


    Die MMU liefert die 4/8 MHz, ihre Datenleitungen landen ordentlich in den 373er/244er. RAS/CAS alles da.


    Am 68K sind stehen FC0 auf low, FC1 auf high, FC2 auf high, CLK geht rein, Reset ist auf high. HALT ist high, BERR ist high, IPL0-2 high, UDS und AS takten mit hoher Frequenz, LDS bleibt auf dem gleichen Pegel. Der Shifter liefert 16 MHz.


    Was auffällig war: Beim LS05 für den Reset standen sowohl Eingänge als auch Ausgänge auf low. Frohlockend getauscht, war aber sinnlos. Erst bei einem Pull entweder von GLUE als auch MMU und wieder reinsetzen konnte die Reset-Line nach Tasterdruck schalten. Zufallsbefund oder nicht, in der Regel spinnt Reset nach dem Einschalten wieder; das legt sich aber nach ein paar Minuten.


    Der 68K kann Reset auch selbst low ziehen, wies scheint. Wann und warum er das tun kann- kein Plan.


    Falls sich die ROMs als in Ordnung erweisen, wird es wohl in der Tat der 68000er sein. Entweder liest oder interpretiert er durch einen defekten Adress/Datenbus Mist, oder das Ding hat grudnsätzlich eienn Hau weg. Was anderes kan nich mir gerade nicht erklären. Vor allem, warum die Ksite anfangs ein paar Minuten lief und dann komplett mit dunklem Schirm abkachelte.


    Ja, das hätte und könnte auf die RAMS/ROMs verweisen können, aber das Verhalten der Reset-Line ist abnormal. Das darf nicht sein. Und der 68K ist , -eventuell- neben der GLUE bzw der MMU der einzige, der eine bidirektionale Reset-Line hat. Wenn die CPU Reset nach Gusto aus jedweden Gründen ständig nach low zieht, kann man lange probieren. Aber selbst bei normalem High-Pegel arbeitet das Mistteil ja nicht.

    Vor allem, wenn das eine Failcondition sein sollte und die CPU Reset selbst low zieht, warum lässt sie Reset nicht mehr los.


    Edit: Aha, mal nachgelesen: Um den 68K vollständig zu resetten muss sowohl RESET als auch HALT low gezogen werden. Deswegen gehen beide Signale wohl auch in einen Open Collector-Buffer. Und, wunder was, beim Druck auf den Resettaster geht nur RESET low, aber HALT bleibt high. Das is nich richtig.

    Viel wird man nicht mehr sehen können, da ich schon Brücken gezogen habe. Das war eine Erweiterung, die zusätzlich 2 MB, also insgesamt 3 MB lieferte. Wenn ich das richtig interpretiere, gabs an den Widerständen rechtsseitig von dRAM (wohl [MA0..7}) einen Abgriff und dann gibts ja oberhalb nochmal drei /vier Widerstände (Quelle / Ziel im Moment nicht erkennbar), die dazu einseitig ausgelötet wurden und wie in einer Art Brücke über die Speichererweiterung geleitet wurden.


    Dann wie gesagt das Anflanschen an die 244er - und an der GLUE wirden noch zwei Adressleitungen verknotet. Dann halt noch die gecutteten und ein paar neu gezogene Leitungen unterhalb dieser vier Widerstände - Ziel-Quelle nicht erkennbar. Müsste ich durchpiepen.


    ich muss ohnehin noch nach einer PDF für die Erweiterung zwecks eventuellem Wiedereinbau suchen, dürfte sich allerdings wohl außerordentlich schwer gestalten. In der Einbauanleitung soll das Prozedere wohl dargelegt sein. In einer Atari-Magazinausgabe von 1992 wurde das Teil vorgestellt und mit 249 Tacken beworben.

    Wenn ich das Teil mal am laufen habe ,schaue ich mir das in Ruhe nochmal an. Im Moment zuviel mit Fehlersuche beschäftigt :-(

    Edit: Nach Schalplankonsultation dürften die vier Widerstände oberhalb (ebenfalls korrigiert) MAD [0..8] zu CAS0H/CAS0L/RAS1H/RAS1L gehören. Macht Sinn. Vermutlich konnte man nicht einfach einen Abgriff ohne auslöten vornehmen.

    In jedem Falle auch ei mn großes danke für den Tip mit der elektrischen Entlötpumpe. Für was "richtiges" fehlen die Kohlen, Entlötlitze ist idR arschteuer und meine Plastiknuckelgeäte sind völliger Mist.


    Was ich aber auch noch probieren werde, wenn wir gerade beim Thema Plastik und Entlöten sind: Auch wenn das lustig und bescheuert klingt - Ich habe vor kurzem aus einer Art "nimm mich mit"-Tauschhäusle, das es bei uns gibt, eine Art batteriebetriebenes Nuckelgerät zur Hautstraffung mitgenommen und das Teil macht mal wirklich einen bösen Unterdruck. Wenn es mit sowas auch geht und die Plastekappe vorne nicht abkokelt - why not. Werde ich in jedem Falle mal probieren. Haja, ´ne Entlötstation ist ja auch nichts anderes.


    Erfinderisch muss man sein :-)

    Edit: Na, das hat keinen Sinn, die Luftgeschwindigkeit reicht nicht. Hab mir jetzt die elektrische Pumpe gezogen; das soltle ja eine halbwegs sinnvolle und (hoffetnlich) langfristige Investition sein. Nicht das wahre, aber besser als der Plastescheiß, von dem man ohnehin alen Furz lang neue Pumpen bzw Spitzen braucht.

    Und die Metall + Plasteteile sind nebenbei auch nicht gerade ungefährlich. Es hat mir, sogar bei fast neuen Pumpen, einige male beim Spannen die Spitze samt Plastikgewinde rausgeschossen. Und das ein oder andere Geschossziel in vllt 40 cm Entfernung will ich nicht näher definieren. Es hat in jedem Falle zwei Tage lang ziemlich weh getan....

    HAbe ich zT schon gemacht, schaue heute Nacht nochmal drüber, bin zzt geistig zu versemmelt als das ich da noch ordentlich was messen kann. CPU hat Takt, RAS/CAS-Aktivität ist vorhanden.


    Zzt steht HALT der CPU auf high, was ja ansich schon mal nicht schlecht ist, aber ich kann keine Transferaktivitäten mehr am Adress/Datenbus feststellen; zumindest nicht mit meinem ollen Oszi.

    Dafür muß ich ohnehin den Analyzer konsultieren.

    Ah, habe nochmal nach der Speichererweiterung geschaut. Die hat sogar 2 MB.


    Wie gesagt, wichtig wäre erst einmal für die Boardadrevision der passende Schaltplan. Mit den RevB und RevC Schaltplänen lässt sich zwar auch was anfangen, aber leider nicht vollständig. Wäre wichtig, auch die Zugehörigkeit von verbauten Widerständen usw zu ermitteln.


    Udn wie gesagt, wie die Initialisierungsreihenfolge aussieht. Das Service Manual meint bei schwarzen Schirm und keiner Floppyaktivität => CPU, GLUE und MMU auszutauschen. Und das versuche ich zu vermeiden, solange der Fehler nicht zu 100% eingegrenzt ist. Für die Speichererweiterung musste ja auch am Board selbst herumgepopelt werden.

    Danke für den Tip - kommt drauf an, wie der Defekt aussieht. Wenn das defekte DRAM Pin2 und 14 stänfig high oder low zieht, kann ein funktionierendes DRAM huckepack nciht viel ausrichten. So einen DRAM-Fehelr hatte ich bspw am CPC464. Ein Versuch ist es in jedem Falle wert (passendes DRAM vorausgesetzt).


    Ich habe ja noch die Speichererweiterung mit 4 DRAMs je (anscheinend) 256 KiB. Wenn alle Stricke reißen, kommen die originalen Speicherchips raus und die 4-Chip-Version als Ersatz rein - vorausgesetzt, die hat auch keine Macke. Und für die Erweiterung muß ich auch erst einmal ein Pinout finden.,n nennt sich IMEX II. Wurde über zwei Flachbandkabel je den 244ern und an den Widerständen rechtsseitig vom originalen Board-DRAM verlötet.

    Wäre denkbar. Wundert mich halt, dass das von jetzt auf gleich passierte. Die Kiste war für 20 Jahre eingekellert (roch auch danach). dicke Caps

    oder dergleichen kan nich nciht erkennen und auch die zwei Spannungen sind eigentlich stabil.


    Ich werde mal hergehen und die PROMs sukzessive gegen ein Binary vergleichen. Ein bischen Schaltungskram mit einem Microcontroller aufzubauen ist ja nicht die Welt.

    Aber ich habe die schwere Vermutung, das ich das gleiche mit den DRAMs veranstalten muss. Und davor graust es mir, weil es ohne Entlötstation und nur mit Nuckelpumpe bei der Anzahl von DRAMs

    "a pain in the ass" ist. Einen Fön zu nutzen wäre eine Alternative, aber die Erfahrung hat gelehrt, dass das nicht unbedingt für das Board und die Bausteine destruktionsfrei verlaufen muss.


    Aber, wie gesagt, im Moment baue ich noch darauf, das irgendwas am TOS faul ist. Wenn es die MMU oder der GLUE-Stein ist, dann gute Nacht....


    Wenn irgendwas an den Commodore-8-Bittern oder einem anderen 8-Bitter faul ist, kann ich den Fehler relativ zuverlässig beheben, da ich schon einige auch mit schweren Macken wiederbeleben konnte. Aber das ist ´ne andere Hausnummer.

    Super, danke !


    Eigentlich dat hier:


    https://temlib.org/AtariForumW…0stf_motherboard_revD.jpg


    Nachtrag: Mitterweile HALT ständig auf High, aber auch keine weiteren Aktivitäten mehr zu erkennen.


    Ach je....Wochenendbeschäftigung.....den kleinen Analyzer mal anklemmen und schauen, ob sich was erkennen lässt....


    Beim C64 und Konsorten ist das ja alles noch "relativ" einfach, aber die Dinger sind dann doch ´ne andere Hausnummer....

    Moin zusammen,


    neuer Rechner, neues Pech - habe mir mal wieder einen 1040STF geschossen, der einen gewaltigen Defekt zu haben scheint.


    Problem an der Kiste: Es kommt kein Bild, die Floppy läuft nicht an. Die Kiste lief beim Eintreffen vllt 2 Minuten, dann war Sense - hing sich auf.


    In dem Rechner befand sich eine Speichereweiterung, die ich zwar erfolgreich entfernen konnte (hilft ja nichts, wenn die als potentieller Fehler in Frage kommen könnte),

    allerdings mussten dafür ein paar ehemals gecuttete Leitungen wieder verbunden werden und bei der ein oder anderen Neuverbindung stehe ich auf dem Schlauch,

    weil bspw eine gecuttete Leitung auf der Bestückungsseitig dummerweise genau unter einer Latte von Widerständen verläuft und ich das Signalziel nicht erkennen kann.



    Das Board ist ein C070523-001 Rev D - zu der Revision finde ich keinerlei Schaltpläne im Netz. Andere Pläne helfen nur bedingt weiter, da eben die Bautelenummerierung nicht

    stimmt und leider auch PCB-Layouts (Top/Solderside) völlig fehlen; die in dem Falle am wichtigsten wären.


    Fakt ist, das die CPU mit und ohne Speichererweiterung nach dem Einschalten bzw einem Reset ziemlich schnell HALT auf low zieht bzw auf HALT gezogen wird.

    Speicherseitig kann ich bei gehaltenem RESET auf den entsprechenden Bit-Ein/ausgängen bei den ersten sechs RAMs von links aus gesehen ziemlich viel Noise auf dem Oszi

    erkennen und auch über den Lautsprecher des SM124 ein ziemliches Signalmischmasch hören, was bei den restlichen RAMs nicht auftritt. Wenn RESET losgelassen wird,

    normalisiert sich das ganze wieder. Bei den 373er-Latches kann ich keine Aktivität an LE feststellen (immer low, auch kein großartiges Pulsen, ebensowenig, das an den 244ern

    an den OE-Pins sich irgendwas, ausser einem ständigen High-Level, irgendwas rühren würde.


    RAS/CAS-Aktivität lässt sich durchgehend an den RAMs feststellen.


    Die Adress-Datenleitungen wie auch CE an den TOS-ROMs habe ich auf Konnektivität bis hin zur CPU durchgemessen, auch alle gesockelten Chips raus und wieder rein.


    Die Frage ist -was kann da los sein.


    Ich kenne den Ablauf des TOS-ROMS nicht, aber ich glaube zu meinen gelesen zu haben, das erst die Initialisierung der Peripherie (so wohl auch Bildschirm)

    erfolgt und dann der Speichertest vollzogen wird. D.h. er -könnte- ja -eventuell- potentiell Bomben werfen, wenn die Peripherieinitialisierung erfolgreich war.


    Es gibt kurzzeitigen Zugriff auf die beiden untersten TOS-ROMs, die anderen vier stehen ständig high. D.h. weit kommt er wohl gar nicht.


    Es kann ja wie bei Computern so üblich potentiell alles sein, aber am wichtigsten wäre erst einmal die Originalkonfiguration so ordentlich wie möglich hinzubekommen und

    dazu fehlen mit die passenden Schematics.


    Daher meine Bitte: Es wäre super, wenn jemand die passenden Schematics für die oben genannte Boardrevision hätte. Denn sonst ist an einigen Stellen Rätselraten

    angesagt :-(


    Lieben Dank & Gruß

    Ja, Speedlock scheint extrem empfindlich auf unpassende Synchronisation zu reagieren; - was der Name eigentlich impliziert.

    Nun, mit dem Schlepp als Audioquelle und den entsprechenden Progs klappt das mittlerweile auch (kann auch hier zu Fehlern führen, wenn der "tongebende" Kopf des Kasettenadapters nicht passend sitzt); meine Lösung muckt aber trotz einer Menge herumgebuffere auf der Ausgabeseite leider immer noch herum - iund entweder sind die Umrechnungen nicht genau genug oder es kommt trotz Verwendung von Assembler und einem relativ hohen Grundtakt zu minimalen Aussetzern - wobei da ncihts zu hören ist.

    Deswegen wäre es interessant gewesen zu wissen, wie Speedlock arbeitet oder wie tolerant es ist; denn eigetnlich ist ja kein Kasettenlaufwerk zu 100% Laufstabil während der Wiedergabe und wenigstens eien minimale Toleranz solltee ja vorhanden sein. Klar, ein Disassembly des entsprechenden Loader-Blocks kann man sich aus einem CDT immer noch generieren.


    Natülrich, es gibt fertige Lösungen für lau; auch eine Menge Code, der die Umrechung zeigt - hilft in meienm Falle aber nix, da die Vorgehensweise bzgl der Weidergabe eine andere ist - im Extremfall würde auch ein einfacher Mp3-Player ausreichen; allerdings bastel ich auch gerne. Und leider so lange, bis es funktioniert.

    Scho gschwätzt. Pegel zum Kasettenadapter schlicht zu hoch. Hätte ich nciht gedacht, weil der nicht mit SpieedLock abgesicherte Rest ja selbst mit abnormalen Baudraten auf maximaler Lautstärke zu laden war.


    Man lernt nie aus.

    Moinsen zusammen,


    nun, ich bin dabei, mir eine eigene Hardware zum Übertragen von cdt-Dateien per Kassettenadapter auf den CPC464 zu basteln, was bislang auch super klappt, allerdings mit der Einschränkung, das ich Probleme mit Spielen habe, die mit Speedlock abgesichert sind.

    Wie Speedlock-cdt´s aufgebaut und zu behandeln sind, d.h. Single-Pulses mit verschiedener Pulslänge auszugeben, Hederlasse Datablocks senden usw , ist bekannt.


    Fakt ist aber, das ich schon seit einer ganzen Weile herumprobiere, solche Speiel zu übertragen, aber nicht wirklich etwas klappt. Das betrifft bei Speedlock-Spielen aber auch CDT2WAV / CDTMaster. Vornehmlich habe ichs mit "Ace of Aces" und "Raid" sowohl per cdt2wav als auch CDTmaster probiert. Wie bei meiner Hardwarelösung gehen die ersten zwei Standarddblöcle, die den Speedlock-Loader beinhalten, normal durch, ab dann sieht man nur noch ab und an das Bild "flaschen" bzw am Rand kommen dann die Streifen, wenn Daten durchgejat werden. Und eigentlich müsste es gerade mit den zwei Programmen klappen, denn sie dekodieren das jeweilige cdt eigentlich richtig.


    Deswegen meine Frage: Ist es bekannt, wie Speedlock in den ersten Versionen ohne Encryption prinzipiell arbeitet, wie genau die einzelnen Impusle sein müssen , on irgendwelche Impulslängentoleranzen erlaubt sind usw. Der CPC-Emulator Arnold nimmt diese cdts allerdings klaglos an. Deswegen weiß ich nicht, wo das Problem liegt - ob das meine Hardware ist; der Rechner, ob cd2wav udn konsorten inkorrekt arbeiten etcpp.

    Über jegliche Tips bin ich sehr dankbar !


    Viele Grüsse

    Moiin zusammen,


    mein neu erstandener 464 schwächelt - von jetzt auf gleich. Symptomatik: "halbsynchronisierter Schnee" auf dem Schirm, keine Reaktion auf blinde Befehlseingabe.


    Die Boardversion ist die Übergangsversion mit dem 40010 Gate Array, auf das wahlweise auch ein 40007 gesteckt werden kann; das verbaute GAL ist somit der Pinbelegung im 664 zuzurechnen.

    Einiges am Datenbus getauscht (LS244, LS373, probehalber betreffendes 64x1 RAM raus), aber D5 (Pin1) am Gate Array bleibt high. Lässt sich zwar auf ungesunde Art vom Sockel getrennt low ziehen, bleibt ansosnten aber high mit völliger Inaktivität, daher scheint die Logik dahinter nicht mehr korrekt zu arbeiten. Und wie es halt so ist, wenn das Gate Array nicht mehr will, geht halt gar nichts mehr...


    Meine Frage: Gibts irgendwo in einer mir bislang unbekannten Quelle noch einen CPC-Gebrauchtteile-Lieferanten oder irgendwas NOS-artiges betreffend des 40007 oder 40010 oder hätte vielleicht sogar hier im Forum jemand netterweise eines dieser GALs anzubieten?


    Besten Dank & viele Grüsse !

    Super Sache :-)

    Ich hing lange Zeit auf meiner AVR-6510-Emu fest, die auch ein gutes Stück weit nutzbar ist, kam aber nicht von dem Problem weg, das ich den Controller-Takt vom C64-Quarz

    abgreifen musste, weil man nach einer gewissen Zeit mit einem externen Quarz/Oszillator ins "asynchrone" rutscht und der AVR ins "leere" liest. PLL wäre wohl vllt eine Lösung. Es läuft zwar mit den 17.734MHz

    (schon irre genug) auch stabil inkl aller illegalen OPs, aber wie gesagt, man rutscht gerne in befehlsseitige Timingprobleme und diese Taktgeschichte ist halt ein no-go.

    War jetzt wirlklich nur ein Zufallstreffer, weil ich nur die zwei 4416er auf dem C16 da hatte; jene, die ich halt rausholte.


    Ich bin grade ohnehin dabei, nochmal eine kleine Platine zusammenzunageln, die beide 4416er durch 44256er ersetzt.

    Geht zwar Kapazität flöten, aber von denen hab ich wenigstens mehrere da. Altbestand aus A500-Speichererweiterungen.


    Geil wärs allemal, wenn sich herausstelle würde, das es 4464er als 4416er gibt, die vielleicht nicht ganz die Specs einhalten, aber

    vielleicht doch im eingesetzten Falle zuverlässig arbeiten. Klar, das man so verfahren hat, wird seinen Grund haben.



    Ich hab mich mit dem C16-Kernal bislang nicht auseinandergesetzt - ich hab das Ding erst seit ein paar Tagen - zieht der C16 einen

    vollständigen Speichertest analog zum C64 / $FD50 durch oder -weil er ja im Verhältnis gesehen recht schnell geht- klappert er nur

    die ersten paar Speicherstellen der hjeweiligen 256 Byte- Page ab?


    Ich kann ja später mal versuchen oberhalb von 16K durchzupeeken/poken und mal schauen, was er mit dem seltsamen 4416er zu melden hat.

    Nehme ich halt mal das übliche 0x55/0xaa-Raster und verschiedene andere Patterns, dengel ich mal auf jede Speicherzelle ein paar hundert mal ein.

    Moin,


    bin gerade dabei meinen C16 auf 64K hochzurüsten und eines macht mich stutzig.


    Wie´s der Teufel so will, waren meine aus diversen 64er mit 250469-Platine übrig gebliebenen 32K-DRAMs fast alle kaputt, eines

    schien im Betrieb zumindest nicht den Hitzekoller zu bekommen.


    Gut, dachte ich mir, basteln wir halt eine kleine Platine zusammen, die ein 44256-Derivat verwendet. Reingesteckt,tut nicht. Nach längerem

    verifizieren hat sich herausgestellt, das sie gehen muss.


    Dachte ich mir, komm, steck doch mal anstelle des letzten vorhandenen C64-DRAM, das "eigentlich" gehen müsste, eins von den originalen 4416ern rein.

    Also meine Platine plus einem 4416er.*bling*, Bild da, 60.671 Bytes verfügbar. Ich - höh? Dieses 4416er-RAM wieder raus, das andere 4416er rein, nur noch 12K frei.


    Die haben beide das tupfengleiche Label, aber scheinbar tatsächlich unterschiedliche Kapazitäten. Ich weiß, das später nur noch die 4464er mit der höheren

    Kapazität verwendet wurden, aber der Fall ist mir unbekannt.


    Schon mal jemand ähnliche Erfahrungen gemacht?


    Gruß

    Stef

    In der Tat; schlecht ist die Kiste nicht, weist halt nur seltsame Eigenheiten auf. Im Moment nagel ich eine Platinenverschon der 8-bittigen 32 K Speichererweiterung zusammen; denke, dieses mal sollte es klappen.


    Mit den Cartridges ist es wirklich schwierig, weil sich die entsprechenden Module, eben gerade das ziemlich dringend benötigte Extended Basic kaum finden lässt und ich aufgrund ziemlich schiefer Finanzlage nicht auf Maximal

    versionen wie eben den SD/Cartridgeumsetzer ausweichen kann. Die Bauteile dafür hätte ich zwar (fast) prinzipiell da, aber keinen dafür benötigten programmierten XC95144 CPLD. ´ne rein controllerbasierte Lösung könnte sicherlich auch irgendwie funktionieren, wenn genug Dampf und der entsprechende MC vorhanden ist, aber aufwandsseitig, vor allem wegen der Programmiererei, wäre das wohl mit Kanonen auf Spatzen geschossen.



    Aber es wäre schon viel Wert zu wissen ob die neue Erweiterung überhaupt arbeitet; das lässt sich leider ohne Extended Basic mal gar nicht sagen - wenn sich das Ding nicht nur auf die 16-bittige Ereiterung stützt und mit der 8-bittigen gar nichts anfangen kann. Ich weiß nicht mal, ob es ausreichen könnte, statt der Cartridge nur eins von den beiden ROM-Chips mit jenem von EXBasic zu ersetzen, weil ich nicht weiß, in welchen von den beiden ROMS im Rechner das Basic liegt oder ob es sich gar noch teils auf das eingebaute Basic stützt.

    Versuche, mir mal ein paar Eigenantworten zu liefern, soweit wie rausgefunden : Nein, das eingebaute TI Basic kann nicht mit Speicherweiterungen umgehen, Programme ohne Speichererweiterung sind meistens TI-Basic-Programme , die im Video-RAM abgelegt werden und da das CPU-RAM für Assemblerprogramme ohne Erweiterung nur 256 Bytes groß ist, reicht das natürlich für nichts aus; selbst Extended Basic kann keine Assemblerprogramme vom Tape in Richtung Speichererweiterung laden. Von Diskette ja, von Tape aus nicht. Gründe=?.