NKC Forum
Registrieren | FAQ | Suche | Wer ist online? | Mitgliederliste | Heutige Beiträge | Kalender | Einloggen



Autor Thema: Minimales Testprogramm für 68008?
m.haardt
Voll in Gange
***
ID # 93


  Erstellt am 31. August 2017 18:07 (#1)  |  Zitat Zitat   PN PN   E-Mail E-Mail
Hallo,

ich versuche einen 68008 aus ungetesteten Teilen zusammen zu bauen und natürlich geht es nicht: BUS2, ROA64 mit einem 28C64, CPU68k8 sowie eine getestete IOE mit LEDs an Port 0.

Könnte mir jemand sagen, ob dieses Programm in Ordnung ist? Es ist mein erstes 68k Programm, d.h. es kann sehr falsch sein. Die Einrückung müsst ihr Euch denken, das Forum formatiert auch Leerzeichen in code tags.

org 0

ioe equ $f00030 ; Basisadresse der IOE bei 68008

ioe_p0 equ ioe+0
ioe_p1 equ ioe+1

supmode on

entry dc.l $10100 ; Supervisor stack (2. ROA64)
dc.l main
dc.l 0
dc.l 0

main move #$2700,sr
move 0,d0
loop:
move.b d0,(ioe_p0)
addq.l #1,d0
move 0,d1
delay:
subq.l #1,d1
bne.s delay
bra.s loop

Michael

Beiträge: 501 | Mitglied seit: April 2008 | IP-Adresse: gespeichert
DerInder
Fast schon Admin
Seitenadmins
***
ID # 2


  Erstellt am 31. August 2017 18:24 (#2)  |  Zitat Zitat   PN PN   E-Mail E-Mail
Moin Michael,

da sind noch so einige Fehler in deinem Programm ;)

org 0

ioe equ $ffffff30 ; Basisadresse der IOE bei 68008

ioe_p0 equ ioe+0
ioe_p1 equ ioe+1

* supmode on ???? kenn ich überhaupt nicht

entry:
dc.l $10100 ; Supervisor stack (2. ROA64)
dc.l main
dc.l 0
dc.l 0

main:
move #$2700,sr
move #0,d0 *hier bräuchtest du nur ein Bytewert (move.b #0, d0)
loop:
move.b d0, ioe_p0
addq.l #1,d0 *hier verwendest du wieder ein Langwort (besser addq.b #1.d0)

move #0,d1 *hier lädtst du nur eine Wort! besser moveq #0,d1
delay:
subq.l #1,d1 *hier arbeitest du mit Langwort!
bne.s delay
bra.s loop

So in etwa sollte es klappen.

PS: statt einem move.x #0,dx kann man auch ein clr.x dx verwenden. Das bringt zwar keinen Geschwindigkeitsvorteil, aber ist besse zu lesen. Generell sollte man aber bei Werten <128 lieber moveq (ist immer Langwort)verwenden, das ist am schnellsten.

-----------------------
Gruß
-=jens=-

Beiträge: 912 | Mitglied seit: Juni 2004 | IP-Adresse: gespeichert
m.haardt
Voll in Gange
***
ID # 93


  Erstellt am 31. August 2017 18:49 (#3)  |  Zitat Zitat   PN PN   E-Mail E-Mail
Vielen Dank, das war schon mal sehr hilfreich! :) Hier die überarbeitete Version:


org 0

ioe equ $ffffff30 ; Basisadresse der IOE bei 68008

ioe_p0 equ ioe+0
ioe_p1 equ ioe+1

supmode on

entry dc.l $10100 ; Supervisor stack (2. ROA64)
dc.l main
dc.l 0
dc.l 0

main move #$2700,sr
clr.b d0
loop:
move.b d0,(ioe_p0)
addq.b #1,d0
move.l #$8000,d1
delay:
subq.l #1,d1
bne.s delay
bra.s loop


Warum die f statt 0 in der Basisadresse der IOE? Ich sehe in der Schaltung nur, dass die obersten 4 bits verknüpft werden. Ist das bei anderen CPUs anders?

supmode on ist ASL-spezifisch, damit es keine Warnungen gibt, wenn man supervisor mode Befehle benutzt.

Michael

Beiträge: 501 | Mitglied seit: April 2008 | IP-Adresse: gespeichert
DerInder
Fast schon Admin
Seitenadmins
***
ID # 2


  Erstellt am 31. August 2017 19:06 (#4)  |  Zitat Zitat   PN PN   E-Mail E-Mail
Moin Michael,

eigentlich hast du recht, was die IO-Adressen angeht, aber man gibt besser immer $ffffffxx für den 68008 an. Denn dann braucht man für den 68000 nur $ffffffxx*2 und für den 68020 $ffffffxx*4 angeben.

Das macht man normalerweise über ein EQU:

CPU equ 1 ;(1=68008, 2=68000, 4=68020)
IOE equ $ffffff30*cpu

Dann braucht man im Programm nur noch den CPU-Wert ändern.

Übrigens deine Delayloop wird bei 8MHz (ohne Wartezyklen) etwa 0,06 Sekunden dauern ;)

-----------------------
Gruß
-=jens=-

Beiträge: 912 | Mitglied seit: Juni 2004 | IP-Adresse: gespeichert
m.haardt
Voll in Gange
***
ID # 93


  Erstellt am 31. August 2017 19:36 (#5)  |  Zitat Zitat   PN PN   E-Mail E-Mail
Gut, dann ändere ich das so.

Es funktioniert natürlich trotzdem nicht. Inzwischen habe ich in das EEPROM eine Z80 Version des Codes geladen. Mit gezogenen Jumpern auf der ROA64 funktioniert das. Mit obigem Code und gesteckten Jumpern funktioniert es beim 68008 nicht, d.h. BUS2 und ROA64 sind ok und das Problem liegt bei der 68k Karte.

JMP1 steckt auf Position 1 (8 MHz CPU, 150 ns EEPROM)
JMP2 ist offen
JMP3 ist geschlossen
JMP4 und JMP5 sind geschlossen

Ideen?

Michael

Beiträge: 501 | Mitglied seit: April 2008 | IP-Adresse: gespeichert
DerInder
Fast schon Admin
Seitenadmins
***
ID # 2


  Erstellt am 31. August 2017 19:58 (#6)  |  Zitat Zitat   PN PN   E-Mail E-Mail
Moin,

evtl. solltest du JP1 auf Position 3 setzen, obwohl das bei der IOE eigentlich egal sein sollte und für 150ns EEPROM auch. Spätestens für die GDP und die FLO muss es aber dann Pos. 3 sein.

Der Befehl:
move.b d0,(ioe_p0)
ist noch falsch, der muss lauten:
move.b d0, ioe_p0

Vielleicht liegts ja da drann.

-----------------------
Gruß
-=jens=-

Beiträge: 912 | Mitglied seit: Juni 2004 | IP-Adresse: gespeichert
m.haardt
Voll in Gange
***
ID # 93


  Erstellt am 31. August 2017 20:10 (#7)  |  Zitat Zitat   PN PN   E-Mail E-Mail
Leider nicht. Ist nicht beides absolute Adressierung (neue und alte Syntax)?

Wie berechnen sich die waitstates als Zeit? Das wurde mir im Buch nicht klar.

Michael

Beiträge: 501 | Mitglied seit: April 2008 | IP-Adresse: gespeichert
DerInder
Fast schon Admin
Seitenadmins
***
ID # 2


  Erstellt am 31. August 2017 20:16 (#8)  |  Zitat Zitat   PN PN   E-Mail E-Mail
Also neuer und alter Syntx sind mir bis dato nicht unter gekommen.
Aber lt. Motorola ist ein Wert in Klammern eine indirekte Adressierung.

Ehrlich gesagt hab ich das mit den Waitstates nie so ganz auseinander gefrimelt. Mir reichte es zu wissen, wie viele eingefügt werden und was wieviele Waits braucht.

-----------------------
Gruß
-=jens=-

Beiträge: 912 | Mitglied seit: Juni 2004 | IP-Adresse: gespeichert
m.haardt
Voll in Gange
***
ID # 93


  Erstellt am 31. August 2017 23:46 (#9)  |  Zitat Zitat   PN PN   E-Mail E-Mail
Motorola hat irgendwann die Syntax geändert. In der neuen Syntax schreibt man die absolute Adressierung von Speicher in Klammern. Die Idee dahinter ist wohl, dass man es auch als indirekte Adressierung sehen kann, weil man nicht die Adresse ändert, sondern den Speicher, auf den die Adresse verweist.

Ich habe mal den Logic Analyzer zum CPU Board befragt und er meint: Reset ist dauerhaft high, die Taste tut nichts und es gibt keinen Takt. Da scheint einiges kaputt zu sein. Ich sehe es mir morgen im Detail an.

Michael

Beiträge: 501 | Mitglied seit: April 2008 | IP-Adresse: gespeichert
DerInder
Fast schon Admin
Seitenadmins
***
ID # 2


  Erstellt am 01. September 2017 11:38 (#10)  |  Zitat Zitat   PN PN   E-Mail E-Mail
Moin Michael,

hast du mal nen Link oder ne Doku zu dem "neuen Syntax"? Ich hab absolut nichts darüber gefunden...

Also für mich ist es ein gewaltiger Unterschied, ob ich schreibe:
move.l a0, d0 ; Der Inhalt von A0 wird nach D0 geschrieben
oder:
move.l (a0), d0 ; Der Inhalt der durch A0 adressierten Speicherzelle wird nach D0 geschrieben.

-----------------------
Gruß
-=jens=-

Beiträge: 912 | Mitglied seit: Juni 2004 | IP-Adresse: gespeichert
m.haardt
Voll in Gange
***
ID # 93


  Erstellt am 01. September 2017 14:21 (#11)  |  Zitat Zitat   PN PN   E-Mail E-Mail
Ja, klar ist das ein Unterschied. Die neue Syntax bezieht sich nur auf absolute Adressierung von Daten im Speicher.

Schau mal http://www.nxp.com/docs/en/reference-manual/M68000PRM.pdf an.

Auf Seite 2-20 siehst Du "Absolute Data Addressing". Das ist in Klammern geschrieben. In den meisten freien Assemblern gibt es aber nur die alte Notation ohne Klammern. ASL hat seit kurzem beide, weil ich beim Autor fragte, wieso ein Stück Code (nicht von mir) nicht assemblierte und der hat sich das angesehen und erstaunt festgestellt, dass Motorola das irgendwann geändert hat.

Bei der indirekten Adressierung wird der Wert eines Registers als Adresse benutzt. Bei der absoluten Adressierung wird der Wert einer Adresse benutzt.

Das Problem mit dem Reset habe ich gelöst, aber der Oszillator will nicht anschwingen. Manchmal schwingt er kurz, dann wieder nicht, und wenn er schwingt, dann nicht symmetrisch. Ich habe einen Sockel mit schlechtem Kontakt getauscht und verschiedene 74LS04 benutzt, von denen manche gar nicht funktionieren (kann sein, die sind alt). Erstaunt stellte ich fest, dass der 8 MHz Takt durch das Flipflop geteilt wird, d.h. bei dem Board gab es wohl schon immer Probleme. Die Jumperposition für den direkten Takt war nicht bestückt.

Kann ein Quarz kaputtgehen? Widerstände und Kondensatoren habe ich geprüft. Ideen?

Michael

Beiträge: 501 | Mitglied seit: April 2008 | IP-Adresse: gespeichert
DerInder
Fast schon Admin
Seitenadmins
***
ID # 2


  Erstellt am 01. September 2017 14:38 (#12)  |  Zitat Zitat   PN PN   E-Mail E-Mail
Moin Michael,

danke für die Info. Ich hab mal in meinen Unterlagen nachgeschaut und siehe da, es steht da so wie du es verwendet hast. Allerdings ist mir dass in 40 Jahren 68k Praxis noch nie unter gegommen ;)

Quarze können durchaus kaputt gehen, die vertagen z.B. keine Stöße.
Daher kommt auch immer wieder die Diskussion, ob man das Gehäuse eine Quarzes anlöten soll oder nicht. Wenn es angelötet wird übertragen sich ja Stöße an der Platine auf den Quarz. Wenn man es nicht anlötet kann es vibieren usw.

PS: Hast du schon mal einen 7404 probiert?

-----------------------
Gruß
-=jens=-

Beiträge: 912 | Mitglied seit: Juni 2004 | IP-Adresse: gespeichert
m.haardt
Voll in Gange
***
ID # 93


  Erstellt am 01. September 2017 14:55 (#13)  |  Zitat Zitat   PN PN   E-Mail E-Mail
Ja, ein 7404 war ursprünglich drin, obwohl der Rest vom Board mit LS bestückt ist. Der schwingt auch nicht.

Mal schauen, ob ich noch einen passenden Quarz finde.

Michael

Beiträge: 501 | Mitglied seit: April 2008 | IP-Adresse: gespeichert
m.haardt
Voll in Gange
***
ID # 93


  Erstellt am 01. September 2017 15:21 (#14)  |  Zitat Zitat   PN PN   E-Mail E-Mail
Ich fand einen 4 MHz Quarz und damit und dem einen LS04, was zuvor wenigstens zuckte, schwingt der Oszillator an, hat mit JMP3 auf ungeteilt einen symmetrischen Takt und der Computer läuft, was ich am Testprogramm sehe. :-)

Also ist wirklich der 8 MHz Quarz kaputt. Sowas ist mir ja noch nie passiert.

Ich werde also mal einen 8 MHz Quarz und einen neuen LS04 kaufen und meine Sammlung der anderen LS04 wegwerfen.

Und danach mache ich mal Bilder, wie das mit den verschiedenen Waitstates aussieht, damit man das Timing mal kennt.

Michael

Beiträge: 501 | Mitglied seit: April 2008 | IP-Adresse: gespeichert
DerInder
Fast schon Admin
Seitenadmins
***
ID # 2


  Erstellt am 01. September 2017 15:58 (#15)  |  Zitat Zitat   PN PN   E-Mail E-Mail
Moin Michael,

dann heist es jetzt wohl "Willkommen in der 32/16 Bit Welt" :D

-----------------------
Gruß
-=jens=-

Beiträge: 912 | Mitglied seit: Juni 2004 | IP-Adresse: gespeichert
m.haardt
Voll in Gange
***
ID # 93


  Erstellt am 01. September 2017 16:21 (#16)  |  Zitat Zitat   PN PN   E-Mail E-Mail
So etwa. Die ersten 32 bit Systeme, die ich in Assembler programmierte, waren allerdings Transputer. :)

Als nächstes sehe ich zu, ein serielles Testprogramm zu schreiben und dann wird der 68008 eine BANKBOOT bekommen mit dem Ziel, einen Bootmonitor zu portieren.

Michael

Beiträge: 501 | Mitglied seit: April 2008 | IP-Adresse: gespeichert
DerInder
Fast schon Admin
Seitenadmins
***
ID # 2


  Erstellt am 01. September 2017 16:26 (#17)  |  Zitat Zitat   PN PN   E-Mail E-Mail
Menno,
Transputer waren immer ein Traum von mir, nur hab ich nie einen in die Finger bekommen (auch mangels Geld) :eek:

Für dein Testprogramm kannst du ja Routinen aus dem Grundprogramm übernehmen, die laufen ja schon ewig. Und einen Großteil davon kann man mit leichten Änderungen auch standalone verwenden.

-----------------------
Gruß
-=jens=-

Beiträge: 912 | Mitglied seit: Juni 2004 | IP-Adresse: gespeichert
m.haardt
Voll in Gange
***
ID # 93


  Erstellt am 01. September 2017 16:42 (#18)  |  Zitat Zitat   PN PN   E-Mail E-Mail
Du kriegst bei Ebay noch Transputer zu bezahlbaren Preisen. Die Dokumentation ist frei verfügbar und die Hardware einfacher als beim 68k aufgebaut. Eine Transputerkarte für den NKC? Absolut machbar.

Ich werde mich im Grundprogramm umsehen. Schade, dass das gelbe Buch so sparsam mit Testprogrammen ist. Das war im ersten Z80 Buch besser.

Michael

Beiträge: 501 | Mitglied seit: April 2008 | IP-Adresse: gespeichert
m.haardt
Voll in Gange
***
ID # 93


  Erstellt am 05. September 2017 16:54 (#19)  |  Zitat Zitat   PN PN   E-Mail E-Mail
Der neue 8 MHz Quarz ist da und damit funktioniert es auch korrekt.

Die Frage nach den Waitstates zeigte eine interessante Abweichung zwischen Z80 und 68008: Beim Z80 werden die Adressen früher auf den Bus gelegt, aber kein Signal zeigt das an. Beim 68008 wird #IORQ aus #AS gewonnen und damit deutlich früher als beim Z80 aktiv. #WR wird allerdings aus #DS gewonnen und damit erst erheblich später als #IORQ aktiv. Das sollte man bei der Hardwareentwicklung im Kopf behalten.

Bei 8 MHz dauert ein #WR etwa 180 ns. Jeder Wartezyklus verlängert die Signale um einen Takt, d.h. 125 ns.
Mit einem Wartezyklus dauert #WR also 305 ns.

Der 6551 braucht in der 2 MHz Version etwa 270 ns, d.h. die SER wird in dem Fall 1 Wartezyklus brauchen.

Mir ist nicht klar, warum FLO und GDP so viel länger brauchen. Ich weiß aber auch nicht, wie lange #WR beim Z80 mit 4 MHz aktiv ist.

Michael

Beiträge: 501 | Mitglied seit: April 2008 | IP-Adresse: gespeichert



| https://hschuetz.selfhost.eu | Boardregeln | Datenschutzerklärung


Tritanium Bulletin Board 1.8
© 2010–2021 Tritanium Scripts


Seite in 0,030359 Sekunden erstellt
16 Dateien verarbeitet
gzip Komprimierung eingeschaltet
2577,39 KiB Speichernutzung