CBM 8296... 255 bytes free :-/

Hallo Zusammen,

Ich bin mir sicher Ihr Profis hier könnt mir einen heißen Tip geben...

Nachdem mein 8296 ein paar Jährchen im Keller schlummerte dachte ich es sei mal an der Zeit, die Prinzessin wach zu küssen....

Sauber gemacht war sie schnell. Huch, das ist ja ein "G"... ganz vergessen - naja dann mal anwerfen die Dame: Kein Düdeldüt und auch kein Bild.
Ok, bestimmt die PLA denk' ich mir... adapter für UE5 gebraten, Sockel rein und: Dudeldüt & Bild Aaaaber leider sehr, äh, rudimentärer Speicher. Also so:

Ja, 0255 bytes... egal ob im "8032 emu mode" oder ohne Jumper... spaßeshalber habe ich mal alle 4 MUXe getauscht (UA9, UB9/10/11) keine Änderung.
UE6 ist OK (Gegenprobe mit EPROM-PLA gemacht), 5V sind sauber da.
Dank der HRG-Emu (denke ich) ist ein komplettes strippen - alle ROMs raus etc. - keine Option, oder?

Habt Ihr eine Idee, wo ich nach der Bitverklemmung suchen könnte?

Danke & Grüße,
Axel

Zitat von tokabln

...und die 255 Byte reichen jetzt nicht um die Lohnabrechnung zu programmieren ?

Sorry habe gerade einen Kasper gefrühstückt

Naja, stimmt schon [wer den Schaden hat,....] - nachdem ich gerade einen C116 reanimiert habe, erscheinen mir jetzt dessen 16384 bytes geradezu überdimensioniert.
Aber n'Bissel mehr als ein 1/4K hätt' ich mir von den ganzen RAM-Käfern schon erwartet

Während als hier Kasper und Clowns Mojitos zum Frühstück trinken hab' ich nochmal allen gesockelten Käfern die Beinchen geschrubbt und Lötstellen unterm Opa-skop begutachtet - nüscht Auffälliges...

Zitat von Diddl

Ich würde auch Mal die ROM prüfen. Vielleicht ist der RAM ja ok und der RAM Test defekt?

Gute Idee, hätt' ich ja auch mal drauf kommen können ! Moment... Ok, mein ROM scheint das 324746-01_b.bin zu sein (das "ohne b" bringt kein Bild), aber auch neu gebrannt das gleiche Verhalten. Schade, wäre so schön einfach gewesen.

Zitat von Toast_r

Schonmal mit dem Monitor probiert, was die vom Speichertest bemängelte Speicherstelle macht?

Hint: 255+1025=1279=$4FF

Da aber nicht 255, sondern 0255 angezeigt wird, würde ich auch auf fehlerhaften Speicher bereits in der Zeropage tippen.

Da der 8296 aber 64Kx1 RAMs hat, ist vor allem nach dem defekten Bit zu suchen.

[255 + 1025 sind bei mir $500 - aber worscht... hab's verstanden ]

Ok, also CALL -151, äh nee, hab's gleich, ah ja, SYS 54386.... und büttöschööööön:

Wenn ich mir das RAM so ab $0000 anschaue (also eigentlich $1000), dann habe ich immer ab $xx80 ein "Loch" von 128 bytes:

Ich würde also vermuten, daß bit 7 in die Suppe spuckt - aber warum klemmt dann das komplette byte?

Zitat von Toast_r

Was passiert denn, wenn Du an den betroffenen Speicherstellen versuchst, Werte reinzuschreiben?

Nix - oder ich bin zu doof für TIM... egal, wo ich hinschreibe, $500 oder weiter oben bei z.B. $1500 (":0500,A5" ist doch korrekt, oder?) die bytes bleiben stoisch bei FF oder 00... dabei fielen mir jetzt div. gekippte bits auf. Ich habe die nicht angefasst, ich schwör'!
Hier z.B. $14fE - $1502 und $1530 ff.

Zitat von x1541

ist es nicht bit 4?

Das scheint auf dem Datenbus hin und wieder zu "flattern" - bit 7 könnte auf dem Adressbus für Verwirrung sorgen, denn immer wenn es "dran" ist kippt 6-0 um... (siehe die 128byte Lücke ab $xx80). Daher war meine Vermutung defekter MUXer gar nicht so doof - aber die hatte ich ja schon testweise getauscht.
Ich wollt's mir eigentlich ersparen, aber dann werd' ich wohl morgen mal die unteren 64K sockeln...

P.S: Gerade mal das HRG-Emu daughter-board gezogen - wow, das scheint ja mit der Hand gebrutzelt worden zu sein. Berge von altem Flux auf der Lötseite. Das schrubb' ich dan, wohl auch mal.
P.P.S: Die restlichen 2332 ROMs (HiRes-Basic etc.) habe ich auch mal alle ausgelesen und gegen die Images von zimmer.net verglichen - alles OK.

Zitat von x1541

lass dich von dem 00 00 00 / FF FF FF Muster im Speicher nach dem Einschalten nicht ins Bockshorn jagen. Dieses Muster ist normal,...

Alles klar - dann nehm' ich das erstmal so hin - ist ja auch ganz hübsch anzuschauen.

Zitat

vielleicht geht es erstmal ohne, mit der Huckpackmethode. Ich stecke dazu ein gutes DRAM in einen Präzisionssockel und stülpe den über einen eingelöteten, zu testenden, DRAM. Dann einschalten und prüfen. hält normalerweise bombenfest. Oft kann man so ein teildefektes DRAM "übersteuern".

Prima Idee - das kommt meiner Faulheit entgegen Leider brachte das auch nix - außer daß der PET nun einen Reset nach dem 1. Einschalten braucht, damit er hoch kommt. Ohne huckepack-RAM kommt er direkt.

Da das HRG Emu board schon mal draußen war, fielen mir die beiden bei mir gesockelten '244 Buffer (UC10/UD8) auf - verdächtig, sind also wohl schon mal getauscht worden... beide mal getestet, sind ok OK.

Dann habe mal einen RAM-test für Arme gemacht... sehr konsistent, diese 0x10. Immer in zwei aufeinanderfolgenden bytes.
Mangels hex$() etwas mühselig zu lesen:

Also in den Adressen $500/$501, $700/701, $900/901, $B00/B01,...$4300/4301 (und sehr wahrscheinlich bis zum Ende des RAMs) steht die $10 alle 512 bytes in Stein gemeißelt.
Es ist m.E. also eher ein Adressierungs-, denn Speicherproblem. Und zwar mit A8 (und A0 wenn A8 mitspielt...)
Ein Blick in den Schaltplan verrät mir, daß A8 und A0 am selben MUXer (UB9) hängen - aber den hatte ich ja schon getauscht. Und wenn ich das richtig lese bekommen die BA0-15 von UD8/UC10, welche ich ja auch schon überprüft habe.

Zitat von x1541

War der RAM test mit dem Huckepack?

Was passiert wenn du ein an anderes RAM behuckepackst? Auch Probleme beim einschalten?

Ja... bei anderen RAMs auch... aaaaber: Jetzt braucht die Kiste jedes Mal "Starthilfe"
Sowas kenn' ich wenn nicht genug Sprit im Vergaser ankommt. Also nochmal die 7805'er messen und siehe da: VR2 bringt noch passable 4.99V aber beim Messen von VR1 resettet die Dame. Reproduzierbar. Verdammt, das Ding zerbröselt mir unter den Händen.

Zitat

Würde den RAM CHIP jetzt einfach Sockeln und tauschen. Da der Chip die kompletten ersten 32/64kB abdeckt kann er sehr wohl das Adressmuster erzeugen.

yup - einer ist ja auch erstmal kein Akt... wird aber wohl erst morgen was.

Zitat von geekdot

yup - einer ist ja auch erstmal kein Akt... wird aber wohl erst morgen was.

Taadaaa:

Dabei noch die beiden 7805 gegen Neue getauscht... hat den Zwangsreset leider nicht behoben. Da VR1 ja "komisch" ist, habe ich auch mal C6 ausgelötet und gemessen: Mein LCR sagt 65uF (statt der aufgedruckten 47uF) - C7, C11/12 (hinten beim RAM) geben mir sogar 160uF (in-system gemessen)... Kapazitätserhöhung bei gealterten Kondensatoren ist eher seltener, aber entsteht wohl durch den verringerten Isolationswiderstand... kann da evtl. einer von Euch netten Jungs nachmessen?
(Werde mal ein paar von den Elkos ordern - irgendwie hab' ich nie das da, was ich gerade brauche )

Aber jetzt erstmal ein dickes Danke an Euch alle für's mitgrübeln und all die guten Tips!

And the journey continues...

Da ist ja auch noch eine 8250LP. Beide LW brav ge-recapped, Mechanismus geschmiert... keine Morsecode. So weit so gut.

Aber wie soll's anders sein..

Drive 0 (JU-570-2) tut nicht -> Läuft, rattert, schwitzt, ist bemüht... file not found.
Drive 1 (interessanterweise das längere JU-570) funzt. Ließt und... schreibt. Leider Warum leider?

Vor ca. 100 Jahren, als ich die Combo erstand, hat mir ein netter User eine LOS-96 Diskette geschrieben und geschickt (warst Du das evtl. Toast_r ? Ist eine EDIXA 2D) - die habe ich gehütet und gepflegt .
Nun war sie also endlich dran, und siehe da, Drive 1 konnte sie lesen:

...uhhh "8296d diagnostic", das klingt praktisch. Starte ich mal...

[Währenddessen: Rrrrrrrrt, rrrrrrrt, rrrrrt....] toll, sieht ja alles Piko aus! Wie komme ich denn hier raus? ESC, Run/Stop, Ctrl-C... damn, egal, Reset.

Nuja. Und seitdem is' meine schöne Floppy hin. Total. diR verhackstückt, wahrscheinlich BAM auch... ::

In tiefer Trauer daher 3 (weitere) Fragen:

• Kann mir hier jemand evtl. wieder eine LOS-96 Disk mit all den schönen Dingen bauen?
• Warum himmelt der Test Disketten?
• Was könnte Drive 0 denn so haben ?

Wie immer: 1000 Dank für Eure Hilfe!

Zitat von x1541

Zitat von geekdot

Was könnte Drive 0 denn so haben ?

Im schlimmsten, leider häufigen Fall Kopf defekt. Den erst mal durchmessen, und dann weiter sehen.

Ha! Ein Stecker war falsch draufgefriemelt... wer das wohl war? (Klassisches Layer 8 Problem ...)

Jetzt muss ich nur noch dem (mittlerweile sporadischen) Reset-nach-Einschalten-benötigt Problem auf die Spur kommen...