Hallo Besucher, der Thread wurde 3,5k mal aufgerufen und enthält 18 Antworten

letzter Beitrag von cbmhardware am

Userport: SP1 funktioniert, aber kein CNT1

    Ich wollte mal testen, was mit den schnelleren Shift-Registern des Userport so geht. Auf SP1 kann ich mit dem Logiktester den Pegelwechsel beim Schreiben von $2A gut nachvollziehen, aber CNT1 auf Pin 4 bleibt stur auf "High". Was mache ich denn da wohl falsch ?


    Das Register (cra) im Source: http://unusedino.de/ec64/technical/aay/c64/cia114.htm



    Ah, ich habe es:



    Das Register war nicht richtig gesetzt. Zusätzlich habe ich dann noch die Warteschleife eingebaut.


    Über TA LO und TA HI kann man scheinbar die Geschwindigkeit einstellen. Maximal geht wohl Phi2/4 und dann nochmal / 8 Shifts. Wo landet man da ? - Gut 15Kbyte/s - Programmlaufzeit ... ?

    Ach, endlich mal wieder dazu gekommen. :) So wie es aussieht, shiftet der C64 aber (heute unüblich) "LSB first" ?


    Edit: hat sich erledigt. 6526 Datenblatt: ". SDR data is shifted out MSB first and serial input data should also appear in this format."





    Ich muss das alte Thema nochmals aufgreifen. Ich habe ein 2364 ROM auf dem Steckboard und PB0-7 sollen die Datenleitungen lesen. Im Moment werden die unteren Adressleitungen (A0-7), also 256 Byte von einem Shiftregister CD4094 adressiert. Die oberen Adressleitungen sind auf GND festgelegt. Das klappt im Einzelschritt auch ganz gut.
    Sobald ich aber eine Schleife verwende, sieht der Readout aus, als wenn jemand in eine sich drehende Drehtür rennt: ähnlich, total daneben ... jeder Versuch war eher ernüchtern.



    Was mache ich falsch oder könnte ich besser machen ?

    also man sollte schon warten bis das Shift-Register fertig ist um weiter zu machen. Also die Warte-Schleife sollte wieder rein. Richtig wäre aber statt lda #$80 -> lda #$08 zu verwenden, da man hier explizit das SP-Bit für den seriellen Transfer pollt, welches gesetzt wird wenn die Kommunikations fertig ist. Ausserdem wäre wichtig zu Wissen welchen CIA Du verwendest. Das sieht man Deinem Code leider nicht an. Falls Du CIA1 verwendes ($dc0x), dann solltest Du unbedingt sei und cli mindestens um die seriellen zugriffe herum verwenden, da sonst ein ausgelöster irq den icr rücksetzen würde und man dann in einer Endlosschleife festhängen würde beim poll von icr. Bei dem CIA2 müßte schon ein NMI ausgeführt werden, dass der icr rückgesetzt wird.

    Wird das Schieberegister ordentlich angesteuert? Vielleicht mal eine Zeitverzögerung einbauen und den "Adressbus" anschauen.

    Eine Verzögerung brachte nur geringe Verbesserung, dann werde ich mal einen anderen Ansatz versuchen. Im Moment verwendete ich sp1 also $dc0x. Werde ich beim gesperrten IRQ nicht das Problem haben, dass im ICR Bit 3 gar nicht gesetzt wird ?
    Ansonsten würde ich die ganze Schleife in den gesperrten IRQ packen, das Y-Register bleibt dann auf 0 und es wird mit inc t_lo hochgezählt, wie man es bei alten Commodore Sources auch öfter sieht.

    Zitat von cbmhardware

    Werde ich beim gesperrten IRQ nicht das Problem haben, dass im ICR Bit 3 gar nicht gesetzt wird ?

    nein, denn das Bit wird ja in Hardware vom CIA gesetzt (und nicht in Software vom IRQ) und ein lesen des ICR löscht alle gesetzten Status-Bits inkl dem Bit 3. Daher sollte der IRQ gesperrt werden, dass der IRQ nicht dieses lesen des ICR durchführt und somit das bit löscht.

    Tja, nüscht. Das erste Byte ist richtig und steht gleich dreimal am Anfang, also $91 $91 $91 ... und dann wird es unschöner. CBM kann man noch mit falschen Zeichen dazwischen erkennen und der Rest ist Ziehung der Lottozahlen. Verwende ein ROM vom Frogmaster-Cartridge.


    Dies war der nun verwendete Source. Vielleicht ist ein grober Lapsus drin ?


    Edit: sehe eben, Zeile 68 müsste noch ein bit icr rein. Das Anlegen der Adresse $00 hatte ich ansonsten absichtlich so gelassen.

    Erstmal Dank für die Tipps. Ich werde es am Wochenende nochmals systematisch prüfen. Also Shift-Register mit Logic-Analyzer und auch mal die Software vom MM1 zerlegen.

    Schau am besten auch mal ins Datenblatt. Da stehen die Timingrelevanten Daten normalerweise drin.

    Da habe ich eben tatsächlich etwas gesehen. Der CD4094 übernimmt das Byte bei steigernder Flanke (1) und sp1 shiftet es bei fallendem CNT (0) heraus. Vielleicht wird damit schon die Adressierung in der Schleife durcheinander gebracht. Sollte aber eigentlich passen ... ?


    Ich habe aber auch noch TTL-Shift-Register da. Die werde ich dann auch mal mit Programm testen. Das will ich jetzt wissen ... :)

    Die Flanken sollten nichts mit der Schleife in Software zu tun habe, da die Flanken von der Hardware gesteuert werden. So wie Du die Flanken beschreibst ist es perfekt. Denn der CIA ändert sein Signal an der fallenden Flanke und bis zur steigenden Flanke ist dann dieses Signal stabil, so dass der CD4094 es bei der steigenden Flanke abgreifen kann.

    Zuerst hatte ich mal auf sp2 gewechselt: identisches Ergebnis. Danach habe ich einen 74LS164 zum Schreiben der Adressen verwendet: der C64 zeigt eine Bitplane nach dem Einschalten. Dieses merkwürdige Verhalten hatte ich auch zuvor schon mit einem anderen ROM, als wenn die Portleitungen überlastet werden. Sobald man diese trennt, ist die Einschaltmeldung wie gewohnt da.


    Ein anderes Board verwendet: alles ok, Einschaltmeldung da.


    Ich habe da einen Verdacht ... ;)

    Habe den CIA mal getauscht und es verhält sich schon etwas passender. Allerdings klappt es mit dem Shift-Register (sp1) immer noch nicht. Das Shift-Register läuft unabhängig von der Timer-Geschwindigkeit asynchron zum Programm.



    Ich hatte mir die Routinen in der Micromaxi-Software auch mal angeschaut. Ab $3668 wird wohl die Adresse in die kaskadierten Shift-Register über sp2 geschoben. Da ist allerdings keine Abfrage des ICR drin.


    So langsam bin ich ratlos ...



    Und mit SP2 klappt es problemlos. Das müsste mir mal jemand erklären. :)






    Die Timerwerte sollte man besser auf den Stack schieben und nachher wieder restaurieren. Läuft aber auch erst mal so:


    Edit: wenn man das bit icr in Zeile 57 durch nop ersetzt, sind die kleinen Lesefehler auch raus.