XS-1541 mit sd2iec Firmware?

  • hallo andé,

    auch noch wach?

    device not present, würde bedeuten, falsche geräteadresse angesprochen.

    oder atn nicht rechtzeitig ausgewärtet.
    dafür währe die hardwarelösung mit dem 74(LS)33 die einfachste lösung
    um unbegrenzte zeit zum auszuwärten und zum antworten zu haben.

    timeout habe ich mit einem monoflop auf der proxa7000 usw. gelöst.
    um dav und ndac etwas zu verzögern damit timeout ohne (kernal) programmänderung
    kompatibel zu der 1MHz version ist.
    da sonnst bei 2MHz und gleichen zyklen timeout nur die hälfte der zeit hätte, als vorgesehen.

    aber
    1. das richtige handshake verhalten,
    2. sich bei der komunikation anderer geräte raushalten und
    3. iec/ieee treiber
    sind überhaupt das wichtigste.

    gruß
    helmut
  • axorp schrieb:

    deswegen muss auch nils einen viel höheren programmier und timingaufwand (wie bei den 600/700)
    machen, da er ja auch die 75160 und 75161 auf der petSD benutzt.
    bei der XD-2031 gibt es ja keine treiber somit ist es da viel einfacher und mit viel
    weniger zyklen zu lösen als beim petSD.

    Das ist falsch. Tatsächlich ist das petSD durch die Verwendung des INT0-Interrupts statt pin-change-interrupt ein paar Zyklen schneller, und diese werden mit 18... statt 14... MHz auch noch schneller abgearbeitet:

    Quellcode

    1. ; ATN change interrupt
    2. .global INT0_vect ; cycles in IRQ
    3. INT0_vect:
    4. push r2 ; make place for status register ; 2
    5. in r2, _SFR_IO_ADDR(SREG) ; save status register ; 1
    6. push r16 ; save working register ; 2
    7. ; ATN acknowledge
    8. lds r16, PORTC ; clear port output ; 2
    9. andi r16, 255 -_BV(PC6) | _BV(PC7) ; PC6 is NDAC, PC7 is NRFD ; 1
    10. sts PORTC, r16 ; 2
    11. lds r16, DDRC ; set lines to output ; 2
    12. ori r16, _BV(PC6) | _BV(PC7) ; 1
    13. sts DDRC, r16 ; 2
    14. ;===
    15. ;15
    16. noatn:
    17. ; end of interrupt routine
    18. pop r16
    19. out _SFR_IO_ADDR(SREG), r2
    20. pop r2
    21. reti
    Alles anzeigen
  • for(;;) schrieb:

    Das ist falsch. Tatsächlich ist das petSD durch die Verwendung des INT0-Interrupts statt pin-change-interrupt ein paar Zyklen schneller, und diese werden mit 18... statt 14... MHz auch noch schneller abgearbeitet:
    hallo nils,

    ich meinte bei gleicher hardware und programmbenutzung.
    das du es nochschneller gelöst hast ist super.
    würde man es aber doch auch so am xd-2031 oder xs-1541 machen
    währen die doch schneller, da keine treiber 75160 + 75161 vorhanden?

    oder liege ich da falsch. ist ja auch spät, werde schlafen gehen.

    gruß
    helmut
  • Wenn es nur um den Unterschied der Busanbindung geht, müssen natürlich auch beide Lösungen NRFD und NDAC als Ausgang schalten, dann den Wert 0 ausgeben. Bei der Verwendung von Bustreibern muss man dazu noch die Flussrichtung aller an den Bustreibern angeschlossenen Signale anpassen, da das Gerät ja nun busseitig zum Listener wird und dann durch TE=0 auf Listener am Bustreiber umschalten. Das würde beim petSD schneller gehen, wenn ich alle Handshake-Signale am selben Port hätte, was ich bei der Überarbeitung auch ändern werde...

    Kurz: ja, Bustreiber gehen zu Lasten des Timings, haben aber im Vergleich der konkreten Hardware XS-1541 / petSD keinen relevanten Einfluss. Ausser vielleicht den, dass man es auch mit mehreren Geräten am IEEE-Bus betreiben kann.

    Folgender Fall bei der Verwendung von Bustreibern:

    AVR mit 75160/75161 Bustreibern ist TALKer und gibt gerade ein Datenwort mit EOI=0 aus. Der Busmaster "PET" setzt ATN auf 0, was zur Folge hat, dass der Bustreiber die Flussrichtung von EOI automatisch umschaltet. Nun versucht der AVR die Leitung auf Null zu ziehen, während der Bustreiber zum AVR hin den Wert hochziehen möchte -- die beiden treiben gegeneinander.

    Im Datenblatt des 75161 habe ich den Wert "Ios Short-circuit output current" gefunden, mit min. -15 mA, typ. -35 mA und max. -75 mA -- sollte ich mir Sorgen machen?
  • Ich stehe mit Brandon (dem Entwickler des Flyer) in regem Mailkontakt. Da er keine funktionierendem IEEE-488 Devices hat, kann er leider nicht alles selbst testen.
    Bei der aktuellen Beta-Firmware (noch nicht öffentlich) klappt der IEEE-Bus aber inzwischen ganz passabel.
    Vermutlich wird er die neue Version bald freigeben.
    Für den Triumph des Bösen reicht es, wenn die Guten nichts tun.
    Edmund Burke (1729-1797)
  • Müsste ich ihn mal fragen ... gut wärs, denn er hat zwar den 75160 Treiber verbaut, aber den 75161 weggelassen. Das wird wohl die Ursache dafür sein, daß es bei mir nicht mit mehr als 2 weiteren Geräten am Bus funktioniert.
    Da kommt man immer wieder zum gleichen Theema: Bustreiber weglassen bringt's nicht.
    Für den Triumph des Bösen reicht es, wenn die Guten nichts tun.
    Edmund Burke (1729-1797)
  • Prinzipiell läuft die XD-2031-Software jetzt auf der petSD-Hardware :)

    CATALOG, LOAD und SAVE funktioniert -- mehr habe ich bislang nicht getestet.
    Momentan aber nur mit 644p, nicht mit 1284p. Ich musste also den AVR erst mal austauschen. Da hat sich wohl an den UART-Definitionen was geändert, was ich erst noch anpassen muss. Wenn alles soweit ist, poste ich hier mal ein .bin-file, was man dann mit dem SD-Karten-Bootloader ausprobieren kann.

    Der disk status funktioniert auch mit dem XS-1541 nicht mehr? Da wird gebastelt?
  • Es gibt eine gute und eine richtig besch... schlechte Nachricht.

    Die gute: die XD-2031-Firmware läuft jetzt auch mit dem 1284p AVR, die auf den petSD verbaut sind.

    Die... ihr wisst schon welche: nachdem ich den Code für die Übertragung über die serielle Schnittstelle an den 1284p angepasst hatte und lange Zeit immer noch Fehler in der Übertragung auftraten, fand ich heraus, dass der Fehler nicht in der Software, sondern in den Fuse-Settings des AVRs liegt. Leider lassen sich die Fuses nicht über den Bootloader per SD-Karte verändern, so dass auf jeden Fall ein ISP-Programmiergerät wie z.B. ein STK-200 oder ein AVRISPmkII verwendet werden muss.

    DIE FUSES NUR PROGRAMMIEREN, WENN MAN GENAU WEISS, WAS MAN TUT!
    ES BESTEHT DIE GEFAHR, DASS DER AVR SONST NICHT MEHR ANSPRECHBAR WIRD UND DAS petSD SEINE FUNKTION DAUERHAFT VERLIERT!

    Für die, die genaueres wissen wollen:

    Die Fuses für die Takterzeugung standen bislang auf "Ext. Crystal Osc., Frequency 8.0- MHz" und müssen auf "Full Swing Oscillator" geändert werden. Es reicht, die low fuse zu ändern, z.B. mit

    Quellcode

    1. avrdude -c avrispmkii -P usb -p m1284p -v -U lfuse:w:0xf7:m


    Bei "full swing" wird der Quarz mit mehr Strom angesteuert, was geringfügig mehr Strom verbraucht (in der Größenordnung um 1mA), aber den Takt stabiler werden lässt. Der Fehler in der Datenübertragung lässt sich damit reproduzierbar an- bzw. abstellen -- leider.

    Wer seinen AVR gerne umgefust hätte, kann sich gerne an mich wenden.
  • Update: im github steht jetzt eine Version, die schon ziemlich nahe an eine mögliches Release rangeht. Was m.E. für ein 0.9 noch fehlt ist, dass das Fehlerhandling überarbeitet wird (letztendlich nur wann welche fehlercodes erzeugt werden - aktuell gibt es schon mal noch ein "234,?,00,00". o.ä....).

    Für eine 1.0 fehlt mir dann nur noch:
    - Nutzung der LED
    - IEC support
    - ggf. device# Umschalter (hardware support wie auch in Software)

    In spätere releases können dann
    - D64 support (auf der server-Seite)
    - ieeeout/iecout support (auf der Firmware-Seite) - d.h. vom PET aus eine IEC Floppy oder vom C64 eine IEEE floppy ansteuern
    - SD-card support (firmware-Seite)
    - ...

    kommen. Aber erstmal muss diese hier raus...

    So alles klappt stelle ich das device (in 0.9 oder 1.0) auf der Classic Computing vor.

    Gruß,
    André
  • Benutzer online 1

    1 Besucher