letzter Beitrag von fachat am
Mit dem avr-gcc 4.5.1 aus dem aktuellem CrossPack for AVR compilieren die Firmware-Quellen nicht. prog_uint8_t scheint den Ärger zu machen, ist auch als deprecated gekennzeichnet.
Mit ein paar kleinen Änderungen compiliert es zumindest, mehr konnte ich noch nicht testen -- bin aber schon sehr gespannt, vor allem auf die IEEE-Routinen, die Du dankenswerterweise bearbeitet hast.
Vielen Dank, dass Du Dein Projekt veröffentlicht hast!
Seufz... auch mit der aktuellen fw.hex aus dem git tut sich bei mir exakt gar nichts.
LOAD und SAVE hängen sich auf, und fsser liefert nur "dir=/Users/j" und danach gar nichts mehr.
Mit einem angeschlossenen Terminal-Programm kann ich den XS-1541-Prompt lesen (und bin etwas verwundert über die Ausgabe, die viel zu sehr an die alte XS-1541-Firmware erinnert...)
Eine Idee, was ich machen könnte?
CBM 8296 mit Standard-BASIC 4.0
XS-1541 REV. D mit 644p, low fuse 0xff, high fuse 0xd4, efuse 0xfc
Firmware: Deine fw.hex aus dem git bzw. selbstgebaut mit AVR GCC 4.5.1 / avr-libc 1.8.0 aus dem CrossPack for AVR für Mac
PC Server: läuft auf einem Mac mini, übersetzt mit GCC 4.2.1 (X-Code)
In der Tat nachdem ich heute viel getestet habe merke ich selbst, dass es wenn man das XS1541 einfach einschaltet nicht direkt geht 
Ich hatte immer nur RESET gedrueckt...
Aber nach einem Druck auf den RESET button des XS1541 geht es bei mir!
Das kommt dann mit dem - auch schon im README erwähnten - noch fehlenden RESET Command.
Hier noch der Beispiel-Output bei mir - ich setze das auf setuid root und gebe nach Öffnen der seriellen Schnittstelle die Root-Rechte auf.
Hast Du fsser als root gestartet?
Ach ja, offensichtlich muss ich die firmware Version noch ändern 
Aber dafür ist es ja eine BETA.
Gruß,
André
Auch das Drücke von RESET hat nichts gebracht. Ich habe das Makefile für meine Schnittstellenbezeichnung /dev/tty.usbserial-A9009SJS angepasst und dann erst als normaler Benutzer "make run", dann als root "make run" aufgerufen -- unverändert nüscht.
Zu blöd, dass ich mir meine Linux-Box gerade zerschossen habe. Na, dann bin ich wohl erst mal mit Reparieren beschäftigt...
Ich probier's dann unter Linux.
edit:
Linux-Box läuft wieder mit frischem Debian Squeeze und tadaaa: das XD2031 läuft auch!
Der Wehmutstropfen: es kommt vereinzelt zu "device not present" Fehlern. Ist das bei Dir auch so? Das Directory mittels caT angezeigt kann man nun aber mit der Space-Taste verlangsamen, ohne dass es dadurch bedingt zu Abbrüchen kommt -- das ist schon mal ein riesen Schritt nach vorne.
Habe mal Bilder von einem der Abbrüche beigefügt, vielleicht hilft es bei der Fehlersuche?
Vielleicht ist das ATN-Acknowledge in Software einfach zu langsam? Wäre interessant, wie es sich mit Hardware-ATN-Acknowledge verhält, dazu könnte man noch ein LS86 und LS06 (wie bei der 2031) einflicken.
Ja, caT war durchaus als Protokolltest gedacht.
Schlechte Nachrichten: wenn ich die Firmware selber baue, funktioniert caT gar nicht. Einfaches LOAD funktioniert dagegen.
Meistens liefert es direkt "device not present" error, in sehr seltenen Fällen hängt es. Nach einem von caT verursachten "device not present" kommt es manchmal vor, dass auch ein schlichtes LOAD hängt.
Ich habe die Firmware mit und ohne Debug-Ausgabe (981ff) getestet und sowohl unter der Linux-Kiste (gcc 4.3.5, avr-libc 1.6.8-2) gebaut, als auch auf dem Mac mit neueren Versionen (s.o.) -- das Verhalten ist bei allen Varianten das selbe.
Was ist bei mir anders?
edit:
Ich glaube mittlerweile nicht mehr daran, das CBM IEEE-Busprotokoll stabil nur mit dem Software-ATN-Acknowledge erschlagen zu können. Wir hatten im Forum hier ja auch mal eine Diskussion darüber, ob das in Software schnell genug ist oder nicht. Die damalige Diskussion unterliegt nur leider einem Denkfehler, sie geht nämlich davon aus, dass beim Auftreten des ATN-Interrupts die selbigen auch frei gegeben sind. Das ist aber eben *nicht* immer der Fall, nämlich dann nicht, wenn schon ein anderer Interrupt (z.B. wegen der RS232-Kommunikation) abgearbeitet wird.
Bei AVR sind verschachtelte Interrupts unter C auch eher die absolute Ausnahme, wenn auch prinzipiell möglich. Damit könnte z.B. der ATN-Interrupt behandelt werden, wenn gerade der RS232-Interrupt bearbeitet wird. Aber selbst dann hat man immer noch eine erhöhte Antwortzeit, da der derzeit bearbeitete Interrupt sich erst mal selbst ausknipsen muss, bevor er wieder neue (andere, sprich: ATN-)Interrupts zulässt.
Ich könnte mir vorstellen, dass es so gerade eben klappen könnte, wenn man die ganze Interrupt-Bearbeitung nicht in C (wegen dem overhead) macht, sondern in Assembler -- allerdings macht man dann die nächste Dose Maden auf, die erst mal wieder eingesammelt werden möchte, nämlich ein gemischtes C/Assembler-Projekt.
Deshalb würde ich auf Hardware-ATN-Acknowledge wechseln, wie das bei der 2031 gemacht wurde. Die verwendeten TTL-ICs sind allesamt nicht exotisch, vielleicht hast Du die ja noch bei Dir rumliegen.
Deshalb würde ich auf Hardware-ATN-Acknowledge wechseln, wie das bei der 2031 gemacht wurde. Die verwendeten TTL-ICs sind allesamt nicht exotisch, vielleicht hast Du die ja noch bei Dir rumliegen.
nicht nur ATN.
sondern auch NRFD und NDAC.
hallo nils,
würdes du mir ein petSD zum testen zusenden?
oder dürfte ich es bei dir in leverkusen abholen,
wenn ich joshy besuche?
dann würde ich es erstmal hardwaremässig mit zwischenadapter am AVR
und den IEC-leitungen ATN, NDAC, DAC und NRFD versuchen zu lösen.
habe auch keinen lauffähigen cbm rechner.
da würde mir aber toast_r sicherlich helfen.
da gibt es aber auch einen, hier im forum, aus bergheim,
kenne ihn von der doreco 12/2010. der auch einen cbm8032 hatt.
name fällt mir gerade nicht ein.
oder telespielator fragen, bin ja fast jede woche in bonn.
gruß
helmut
Wenn ich schlummernde petSD-Bestände hätte, sehr gerne. Aber ich habe nur behalten, was ich zum Entwickeln brauche und alles andere an Donald für seinen Shop abgegeben. Grüß Joshy von mir, wenn Du ihn siehst!
Hast Du vielleicht eine Idee, ob und wie man die ATN-Acknowledge-Schaltung aus der CBM 2031, die ja insgesamt drei ICs (74LS86, 7406, 7414) verwendet vereinfachen könnte?
Hast Du vielleicht eine Idee, ob und wie man die ATN-Acknowledge-Schaltung aus der CBM 2031, die ja insgesamt drei ICs (74LS86, 7406, 7414) verwendet vereinfachen könnte?
Ein 74LS136 (Quad-XOR mit Open-Collector-Ausgängen) würde exakt passen, bräuchte allerdings noch zwei Pullup-Widerstände.
Das wurde im Umbau 1541 -> 2031 verwendet, der vom 64'er Magazin veröffentlicht wurde und wäre quasi perfekt -- alles in einem IC erschlagen. Was mir allerdings Sorgen bereitet, ist sein IOL (low level output current) von gerade mal max. 16 mA vergleichen mit den stolzen 48 mA eines 7406 bzw. 75161. Der AVR des XS-1541 konnte IHMO 20 mA und da gab es schon mal Probleme bei mehreren Geräten.
Oder auf Deutsch: funktioniert es noch, wenn (wie?) viele Geräte am IEEE-Bus angeschlossen sind?
Hat jemand eine mit dem 64er Umbau zur 2031 umgebaute 1541 und kann berichten, ob/wann es Probleme gibt, wenn mehrere Geräte am IEEE-Bus hängen?
Ich wüsste auch gerne, welcher IEEE-Interface-Chip bzw. welche Schaltung wie viele mA Buslast erzeugt, die ggfs. auf low gezogen werden sollen, aber da werde ich aus den Datenblättern der MC3446 bzw. SN75161 nicht richtig schlau.
Was mir allerdings Sorgen bereitet, ist sein IOL (low level output current) von gerade mal max. 16 mA vergleichen mit den stolzen 48 mA eines 7406 bzw. 75161. Der AVR des XS-1541 konnte IHMO 20 mA und da gab es schon mal Probleme bei mehreren Geräten.
Ok, auf dieses Detail hatte ich nicht geachtet. Wie wäre es alternativ mit einem halb verwendeten 76LS86 und zwei Transistoren statt der beiden Inverter aus dem 7406? Die Schmitt-Trigger-Eigenschaft des 7414 sollte ja hinter dem Bustreiber-Baustein egal sein.
Was mir allerdings Sorgen bereitet, ist sein IOL (low level output current) von gerade mal max. 16 mA vergleichen mit den stolzen 48 mA eines 7406 bzw. 75161
74ls136 sogar nur max. 8mA !!!
aber was sehr schlimm ist, nur max. 5V am ausgang!
das würde nicht lange gutgehen selbst mit nur einem gerät am iec-bus.
7406 = max. 30V am ausgang
7416 = max. 15V am ausgang
selbst die stärkeren 7406 sterben oft am ser. iec bus vom C64
nicht unbedingt an der belastung. die meisten haben ja nur max. eine
floppy und einen drucker angeschlossen und trotzdem geht der 7406 kaput.
vor ca. 30 jahren war der 7406 eine zeitlang sehr schlecht lieferbar
und kostete mich bei abnahme von 100 stück bis zu 20 DM das stück!
der normaler großhandel einkauf war unter 1 DM.
da habe ich in der not, bei reparaturen, für meine guten kunden,
damit diese nicht wochen warten müssen.
(reparaturzeit bei commodore = monate, meine nur tage)
einen der defekten treiber-inverter im 7406 durch einen mos-transistor ersetzt.
dieser mos-transistor kostete ca. 2DM stück.
den kunden wurde mitgeteilt das wen 7406 wieder lieferbar und nochmal defekt
wird kostenlos original 7406 eingebaut.
die reparierten, mit den mos-transistoren,
habe ich mit einem defekt am 7406 nie wieder gesehen.
in unserem test c64, waren auch die mos-transistoren,
welcher zum testen von hunderten drucker interface benutzt wurde.
an dem war die ser. buchse oft ausgeleiert und andere sachen defekt aber nie
die mos-transistoren für den ser. iec-bus.
welcher mos-transistor das dahmals war weis ich nicht mehr.
aber seit ca. 20 jahren benutze ich den BS170 gerne.
er kostet nur ca. 10 cent. treibt mit 500 (1200) mA 12 x mehr als ein 7406.
sogar bis 60V und hat nur 10nS verzögerungszeit wie ein TTL IC.
ich benutze ihn als inverter / treiber.
und als ein nand-gatter mit einem invertierten eingang.
z.b. als ersatzaufbau mit 2 gattern vom 7400.
(pin 1+2 zusammen. pin 3 an pin 4. pin 5 ist der und-gatter eingang.
der pin 1+2 ist der invertierte eingang und der pin 6 ist der ausgang)
das gleiche aufgebaut mit nur einem BS170:
der gate-pin ist der und-gatter eingang, der source-pin der invertierte eingang
und der drain-pin ist der ausgang mit oder ohne widerstand für z.b. CS-leitungen usw.
man braucht bei einem mos-transistor auch
keinen basis (gate) widerstand. somit ideal als 1/6 7406 inverter ersatz.
gate-pin ist der eingang, drain-pin der ausgang und source kommt an masse / gnd.
alles ohne widerstände.
76LS86 und zwei Transistoren statt der beiden Inverter aus dem 7406
74ls86 und zwei BS170 
Hast Du vielleicht eine Idee, ob und wie man die ATN-Acknowledge-Schaltung aus der CBM 2031, die ja insgesamt drei ICs (74LS86, 7406, 7414) verwendet vereinfachen könnte?
sie benötigt nicht nur diese ICs ( oder 74ls86 und zwei BS170 )
sondern viel schlimmer, eine freie portleitung an deinem AVR!
für die zusätzliche ATN-A freigabe! (ATN-A PIN10 am 6522 in der 2031)
habe in meinen alten schaltplänen bei den IEC-IEEE488 versionen,
die ich noch finden konnte nachgesehen:
1. IEC 1540/4031
(war die erste version mit 4031 vor der 2031,
toast_r hat eins der ersten von 1982 von mir umgebauten geräten ersteigert)
2. 1540-IEC
3. ultra electronic IEC 1541
4. 2031/1540 I/O
5. 1541 IEC+VC (für ser. und par. IEC)
6. IEC1541
7. IEC1541.1
leider habe ich überal die ATN-schaltung aus der dahmaligen 4031 übernommen.
welche auch in der späteren 2031 ist.
deswegen wolte ich ein petSD zum testen. um möglichst eine schaltung
herauszubekommen damit du nicht noch einen pin am avr opfern musst.
oder dir zu helfen den fehler einzukreisen.
habe auch schon darüber mit toast_r gesprochen und ihn gebeten
etwas an der proxa7000 und IEC zu testen.
