Moin Leute
Folgendes...ich habe hier ein Stück Hardware (eine alte Steuerungskarte)
mit einem 68020 drauf und möchte ein paar Testprogramme darauf zum
Laufen bringen. Die Karte an sich funktioniert, nur mein Programm tut
nix.
Gebaut wird per Batchdatei und einer alten Cadul-Toolchain (Assembler
AS68, Compiler CC68 und Linker LD68).
Zunächst will ich bloß eine LED schalten um zu verifizieren daß das
funktioniert, aber daran hängt es schon: Ich bekomme zwar ein S3-File,
aber wenn ich das Programm in ein EEPROM lade tut sich nix.
Batchdatei:
Ab Adresse 0x20000000 fängt das RAM an, mehr als genug RAM. Der Linker
spukt eine Warnung aus die ich nicht so recht verstehe. Er schreibt was
von memory wrap oder so ähnlich, meint jedenfalls daß es einen
Speicherüberlauf geben könnte. Diese Meldung sollte nach der Doku aber
erst kommen wenn er nach 0xFFFFFFFF einen Überlauf feststellt, und den
hat er bei dem kleinen Programm ganz sicher nicht.
Main.c:
1
#pragma noprofile
2
3
#define EL_LATCH 0xe0000000L
4
5
intmain(void){
6
/* Switch all leds off */
7
(*(unsignedshort*)EL_LATCH)=0x00;
8
(*(unsignedshort*)EL_LATCH)=0x01;
9
(*(unsignedshort*)EL_LATCH)=0x02;
10
(*(unsignedshort*)EL_LATCH)=0x03;
11
12
while(1){}
13
return0;
14
}
Dieser Codeschnipsel funktioniert so, wenn ich das Programm mit einer
anderen Toolchain baue. Mit dieser Toolchain kann ich allerdings nicht
arbeiten, da diese das Programm komplett mit einem RTOS lädt, und das
RTOS steht mir für mein Vorhaben im Weg. Und für diese Toolchain habe
ich leider keine Dokumentation, um der das abzugewöhnen.
Hier noch die Assemblerdatei, die der Compiler liefert:
Wie gesagt, bis auf die Warnung vom Linker kommt keine Fehlermeldung.
Die Hardware selber enthält nix, was noch irgendwie initialisiert werden
müßte, jedenfalls nicht um die LEDs zu schalten. Vom EEPROM wird auch
gelesen.
Sieht von euch jemand, was da noch schief laufen könnte?
Ich sehe in dem ganzen Durcheinander etwas von floating point emulation.
Ist dein Programm dann vielleicht doch größer als du denkst?
Und steht in deinem EPROM auch das drin, was du erwartest?
Die Linker.cl verstehe ich nicht, insbesondere die Rechnerei für den
Stack.
Vielleicht versteht der Linke er es auch nicht. Möglicherweise kommt
daher die Warnung.
Gibt auch die Ausgabe des Linkers? Die wäre aufschlussreich.
Hm...mit FP-Rechnerei sollte da nix sein.
Und die Speichergröße ist plausibel, außer daß er etwas merkwürdig viel
Stack verlangt. Im ASM-Code wird der Stack ja nicht benötigt, aber ein
paar Byte will er trotzdem. Ich habe das für eine Standardeinstellung
gehalten.
Da fällt mir ein, ich habe hier noch das Listfile:
Evtl. passt was mit der Vektortabelle am Anfang nicht, 0 ist initialer
Stack, 4 die Einsprungaddresse für den Startup-Code. Disassemblier doch
mal das finale File fürs ROM. Bei den paar Bytes sollte das ja noch
übersichtlich sein...
'ROMABLE CODE' solltest du auf jeden Fall mal ON schalten, wenn die
Nummer in einem EPROM landet.
Und stackbottom liegt auf $00000150? Kann das stimmen?
Mir fallen da zwei Sachen auf:
1. Hoffentlich sorgt m68c0.o für eine korrekte Vektortabelle.
2. Die Stackplatzberechnung ist vergurkt. Es gibt ein stacktop-Label,
dann wird eine negative Menge Platz reserviert, die so berechnet ist,
dass man bei Adresse 0x00000150 herauskommt, die dann als stackbot und
stack gelabelt wirtd. Das mit dem negativen Speicherplatz bemängelt der
Linker dann ja auch.
Warum macht man das mit dem Stack nicht andersherum? Bottom definieren,
Platz reserviern, Top definieren, fertig.
Stack braucht das einfache Programm ja nicht, also wird wohl noch
irgendetwas mit den Vektoren nicht stimmen.
Nosnibor schrieb:> Stack braucht das einfache Programm ja nicht,
Was wir sehen, ist ja nur main().
Die wird vom Startupcode vielleicht mit BSR oder JSR aufgerufen? Dafür
braucht man dann ein paar Byte Stack für SP und Rücksprungadresse.
Hallo, eben,
vielleicht kannst Du, wie Georg schrieb, das EPROM-File diassemblieren,
was da herausgekommen ist?
So sieht das Assembler-Listening, nun mal wie eine C-Funktion aus, die
(von wem?) aufgerufen wird, und nicht wie ein Startcode eines m68k (s.
Klaus.W).
Wird die CPU usw. mit ihren Vektoren von der Toolchain initialisiert?
Initial würde ich einen m68k mit:
reset
move.w #$2700,sr ; IRQ sperren, supervisor bit setzen
; starten
und nicht mit link a6,#0 - was sollte das schon bringen?:
link a6,#0 ; legt a6 auf den Stack ohne offset, meist verwendet
im
; Aufruf einer C-Funktion,
; um dann mit z.B. mit move.l 4(a6),d0 einen
Parameter
; der Funktion zu laden. Die C Funktion wird dann
; mit unlk a6 und rts
; beendet. s. in Deinem Ass-Listening unten.
Der 68k nimmt sich ja Speicherstelle $00000004 als Start PC.
Im EPROM steht also ....(?):
org $00000000
dc.l StartSSP ; ist was? wirklich(?) $150 (also vermutlich ROM?)
dc.l Start_PC ; ist was? => main_ (?) = $170
.. und dann weiter
Gruß Olav.
Klaus W. schrieb:> Nosnibor schrieb:>> Stack braucht das einfache Programm ja nicht,>> Was wir sehen, ist ja nur main().> Die wird vom Startupcode vielleicht mit BSR oder JSR aufgerufen? Dafür> braucht man dann ein paar Byte Stack für SP und Rücksprungadresse.
Nicht nur vielleicht. main hat ein rts, auch wenn das nicht drankommt.
Wenn die Vektortabelle im mc68c.o richtig gesetzt wird (möglich, aber
mit falschem Linker evtl. doch nicht), könnte auch eine falsche
Stackadresse im Startup auf einen doppelten Busfehler (=KO) oder so
rauslaufen, wenn da schon am Stack rumgefummelt wird.
Cfzhfddfhijj schrieb:> Der Compiler liefert 68k/10 Code mit 16bit Integer? 68020 ist> durchgängig 32bit.
Das ist für das Demoprogramm egal, weil wenn überhaupt das nur die
Interpretation von int/long in C trifft. Von der Funktion der Opcodes
gibts bis auf ein paar Sachen im Supervisormode keine Unterschiede
zwischen 68000 und 68020++, .L ist .L und .W ist .W...
Wühlhase schrieb:> Die Karte an sich funktioniert, nur mein Programm tut> nix.
Woran kannst Du erkennen, daß die Karte funktioniert?
Alte EPROMs sind sehr vergesslich.
Was passiert an den Daten- bzw. Adressleitungen, wenn Dein Programm
startet?
Wenn dort nichts passiert, zähle die Zyklen, die die CPU nach einem
Reset macht. Dann kannst Du sehen, wo sie hängen bleibt: Lesezugriff auf
ROM, Schreibzugriff auf RAM, ...
Wenn Du hier den original EPROM Inhalt der Karte (bei der sie
funktioniert) und den EPROM Inhalt des Testprogramm (das nicht
läuft) hier reinstellen würdest könnte man einfach mal schnell
schauen woran es liegt. Alles andere ist Spekulation.
Erstmal danke für die vielen Hinweise und Denkanstöße, ich habe da auf
Arbeit heute einiges ausprobiert. Leider kann ich auf Arbeit seit
einiger Zeit hier nicht mehr schreiben, sonst hätte ich gleich
geantwortet.
Die Stackanordnung im Linkerfile hatte ich ursprünglich aus der Doku von
Cadul geklaut. Ich habe das mal korrigiert, und der Linker warnt jetzt
nicht mehr.
m.n. schrieb:> Wühlhase schrieb:>> Die Karte an sich funktioniert, nur mein Programm tut>> nix.>> Woran kannst Du erkennen, daß die Karte funktioniert?
Es ist halt die Referenzkarte. Ich habe noch ein paar hier, die
definitiv kaputt sind. Ich habe hier u.a. ein EEPROM mit einem
Testprogramm für die Karte, das läuft prima. Außerdem habe ich in der VM
noch eine zweite Toolchain, mit der ich testweise ein LED-Blinklicht
gebastelt habe, das hat auch funktioniert. Der Code aus der obigen main
stammt daraus.
Ich habe zu dieser Toolchain leider keinerlei Doku und der Kram ist so
konfiguriert, daß das Programm in einem RTOS läuft. Und wie gesagt - ich
brauche das ohne RTOS. Ich brauche ein paar Minimaltests (für defekte
Baugruppen).
Ich habe leider keinen anständigen Disassembler, aber da gibt es
mittlerweile nette Onlinewerkzeuge. Im Anhnag habe ich mal das S3-File
angehangen. Wenn ich das aber in diesem Disassembler hier ansehe
https://onlinedisassembler.com
werde ich aus der Ausgabe nicht schlau. Nach sinnvollem Programmcode
sieht mir das nicht aus.
Ob ich das funktionierende Testprogramm hier reinstellen kann ohne das
es Ärger gibt, weiß ich aber nicht...muß ich mal abklären, aber das wird
erst nächste Woche was.
Ach ja, aktuell benutze ich ein Am29F010 als Speicher, das Ding hat 8
Bit. Die Karte ist eigentlich für EPROMs vorgesehen, ich habe aus zwei
DIL-Sockeln einen Adapter gebastelt, jedes Mal eine Viertelstunde
EPROM-Löschen dauert doch etwas zu lange. Und mit einem funktionierenden
Programm habe ich das auch getestet...das sollte soweit funktionieren.
Also wenn "objcopy -I ihex ROM.S3 -O binary rom.bin" keinen Unsinn
produziert, fehlt dir eindeutig die Vektortabelle. Wenn man das
disassembliert (ist jetzt mein eigener, sollte aber egal sein), sieht
schon der Anfang nach sinnvollem Code aus, was nicht sein dürfte:
Der Code aus ROM.S3 sieht so aus, _main habe ich benannt.
Da fehlt relativ sicher die Vektortabelle, ich gehe
davon aus dass es da nicht noch einen zweiten EPROM gibt
der dann nur den Code aus diesem EPROM ausführt.
Ob der ganze Code "drum herum" passt weisst nur Du, ohne
Vergleich mit einem lauffähigen Program kann man wenig dazu sagen.
Wühlhase schrieb:> jedes Mal eine Viertelstunde> EPROM-Löschen dauert doch etwas zu lange.
Als Entwickler hat man da ein paar mehr EPROMs. Gelöscht wird erst, wenn
die Schublade vom UV-Löscher voll ist.
Oder man arbeitet ganz modern mit einem EPROM-Emulator.
Hallo Wühlhase,
dann weißt Du ja schonmal, warum der 68020 Dir nicht anwortet:
Nach dem Listening vom Georg holt er sich nach dem Reset:
$46fc2700 als Stackpointer und startet an:
$23fc7f08 als Startadresse (was er da wohl findet?)
$008000ff wäre die BERR-Error Adresse, autsch.
usw.
Wie die beiden schon schrieben, brauchst Du am Anfang erst die
Vektorentabelle, bis $100 sind die ja von Motorola definiert/ belegt
worde, danach beginnen fakultativ die User Vektoren bis $400.
Du kannst das auf die Schnelle in Assembler ausprobieren, oder Du machst
die grande tour mit linker script und C gemischt mit inline Assembler.
Hier mal auf die Schnelle, quick and dirty:
1
ORG $0
2
SECTION vec,data
3
dc.l RAM_END-4 ; SSP z.B., aber aufpassen in sub_1A0!
4
dc.l sub_0 ; da startet der 68020 sein Programm
5
blk.l $100-8,trapped ; alle anderen Vektoren "trapped"
6
7
8
9
SECTION start,text
10
11
trapped rte ; da passiert nix, hoffentlich brauchst
12
; Du da auch nix (Interrupts und so)
13
14
sub_o move #$2700,sr
15
move.l #$7F080080,($FFFA04).l
16
move.l #$36B70,($FFFA48).l
17
......
18
.. usw., kommt jetzt weiter das, was der Dieter Dir diassembliert hat.
Aber .... wenn ich mir den Assembler Code so anschauen, fehlt mir die
Phantasie, daß man mit der _main-Routine LED ein- und ausschalten kann:
Die Routine macht ja folgendes:
schreibe "0" in $E0000000, dann
schreibe (ca. 0,000002s später) eine "1" hinein.
dann - wieder so nach 0,000002s eine "2"
und dann eine "3"?? Wozu?
Beim Schalten einer LED würde man ja erwarten, daß die CPU die LED
einschaltet, dann wartet, wieder auschaltet, wieder wartet und wieder
einschaltet.
Dann: Bauchschmerzen macht mir die subroutine:
1
sub_1A0: ; CODE XREF: sub_0:loc_62p
2
clr.l ($20000000).l
3
lea ($20000004).l,a0
4
lea ($200000B4).l,a1
5
move.l a1,(a0)
6
adda.l #$20,sp ; ????
7
8
---> dürfte mit "rts" dann crashen und irgendwohin, aber nicht zurückspringen
9
---> und wenn der SSP am RAM Ende steht (was er ja eigentlich tun sollte) wird
10
---> er $1c Bytes nun drüber zeigen
11
12
rts
Also irgendwie wird das ganze - denke ich - nicht klappen: Du brauchst
das RTOS! Der Code ist so - denke ich - nicht brauchbar
Und das RTOS wird seinen Timerinterrupt nutzen und die LED schalten.
auch mal davon abgesehen, daß der generierte Assembler Code ja insgesamt
eher greulich ist:
a1 wird immer wieder mit dem Langwort $E0000000 (movea.l #$E0000000,a1)
geladen, obwohl der Wert doch schon drin steht!
adda.l #20,a7 wird stellenweise verwendet (nur selten addq.l oder lea
$c(a7),a7) oder auch:
1
move.l #$1BA,d0
2
subi.l #$1A0,d0
3
beq.s loc_68
läßt einen ins Grübeln kommen ..... normal wäre das wohl "wegoptimiert"
worden
Also, da gibt es viel zu tun am "Vatertag"
Gruß
Olav
..
>Die Routine macht ja folgendes: schreibe "0" in $E0000000, dann schreibe (ca.
0,000002s später) eine "1" hinein. dann - >wieder so nach 0,000002s >eine "2" und
dann eine "3"?? Wozu?..
PWM ;)
Olav schrieb:> eine "1" hinein.> dann - wieder so nach 0,000002s eine "2"> und dann eine "3"?? Wozu?
Wenn da mehre LEDs am Port hängen, blinken die jeweils mit halber
Taktfrequenz. Kann man hier zwar vmtl. nur mit dem Oszi sehen, aber
immerhin...
Eine Frage hätte ich noch:
Interrupts benutze ich ja nicht. Wie kann denn eine fehlende
Sprungtabelle – soweit ich das sehe, funktiniert das beim 68020 genauso
wie bei den AVRs: Interrupt kommt -> Programm springt an eine
festgelegte Adresse irgendwo am Anfang -> dort steht ein Sprungbefehl zu
einem Programmteil, der den Interrupt abarbeitet.
Was kann eine fehlende Sprungtabelle denn da anrichten?
(Auf die anderen Fragen gehe später ein, die sind nicht vergessen.)
Wühlhase schrieb:> Was kann eine fehlende Sprungtabelle denn da anrichten?
Vermutlich recht schnell CPU-Stillstand. Wenn das "irgendwas" dort als
Sprungvektor interpretiert wird, kann das im Nirvana landen. Und dann
gibt es entweder (weil hinter der Adresse kein Speicher steht) gleich
einen Busfehler oder der Unsinnscode da produziert einen. Wenn der
Busfehler-Vektor auch Müll ist (anzunehmen ohne Vektortabelle ;) ) gibt
es einen zweiten (=doppelten) Busfehler und die CPU macht Feierabend.
AFAIR kann man das auch an irgendeiner Statusleitungskombi erkennen.
Allerdings sind die IRQ-Vektoren egal, solange der IRQL 7 ist. Wichtiger
sind da die anderen Vektoren (Busfehler, Addressfehler, illegal
instruction, DIV/0, TRAP, ...), die können auch so "passieren". Das ist
aber alles derselbe Bereich (ab normalerweise 0), siehe
https://wiki.neogeodev.org/index.php?title=68k_vector_table
Wühlhase schrieb:>> Was kann eine fehlende Sprungtabelle denn da anrichten?>
Das hat weiter oben schon jemand erklärt: Du brauchst mindestens
den Anfangswert für den Stack im ersten 32-Bit Wort (Addresse
0x00000000)
und den Startwert des PC im zweiten 32-Bit Wort (Addresse 0x00000004).
Hallo Wühlhase,
Nur so sicherheitshalber (da schwant mir was), bevor das morgen bei Dir
startet (bitte mit dem SSP Start in 0 und der Startadresse in 4, den
Rest der Vektoren brauchst nicht (zwingend), die beiden aber schon):
>Ich habe leider keinen anständigen Disassembler, aber da gibt es
mittlerweile nette Onlinewerkzeuge. Im Anhnag habe ich mal das S3-File
angehangen. Wenn ich das aber in diesem Disassembler hier ansehe
https://onlinedisassembler.com
werde ich aus der Ausgabe nicht schlau. Nach sinnvollem Programmcode
sieht mir das nicht aus.
Daß das von Dir gesendete S3-File
(https://de.wikipedia.org/wiki/S-Record) ein ASCII-Text ist und nicht
ein diassemblierbares binary bzw. nicht den Machinencode für den 68020
darstellt, ist Dir oder zumindest Deinem Programmer bewußt?!
Ansonsten: Double-Bus-Fault erkennst Du an /HALT aktiv und, daß sich an
/AS auch nix mehr tut.
Gruß Olav.
Olav schrieb:> Daß das von Dir gesendete S3-File> (https://de.wikipedia.org/wiki/S-Record) ein ASCII-Text ist und nicht> ein diassemblierbares binary bzw. nicht den Machinencode für den 68020> darstellt, ist Dir oder zumindest Deinem Programmer bewußt?!
Der Online-Disassembler erkennt das Dateiformat:
> We have detected the object file format as :>> Motorola S-Record; binary data in text format
Und in der Tat, der Disassembler hat nicht die Textdatei
"disassembliert", sondern die in der Datei enthaltenen Binärdaten
interpretiert.
(Die ersten vier Bytes sind 0x46 0xfc 0x27 0x00, die Datei fängt mit den
Zeilen
> S0030000FC> S3150000000046FC270023FC7F08008000FFFA0423FC3F
an. Die zweite Zeile mit dem S3-Record ist so zu lesen:
> S3 15 00000000 46FC270023FC7F08008000FFFA0423FC3F
Das hat so alles seine Richtigkeit.
Wühlhase schrieb:> Ich habe zu dieser Toolchain leider keinerlei Doku und der Kram ist so> konfiguriert, daß das Programm in einem RTOS läuft. Und wie gesagt - ich> brauche das ohne RTOS. Ich brauche ein paar Minimaltests (für defekte> Baugruppen).
mir unverständlich, warum man sich heutzutage mit einer undokumentierten
Legacy-Toolchain rumschlägt, wenn man sich in einer halben Stunde einen
(bestens dokumentierten und tausendfach genutzten) gcc für genau diesen
Zweck bauen kann.
Wenn man nicht weiß, wie das geht: steht sogar hier:
https://www.mikrocontroller.net/articles/GCC_M68k
Naja, ich denke, deswegen hat er wohl hier im Forum um Rat gefragt.
Und wir versuchen ihm klar zu machen, daß das so nicht funktionieren
wird/ kann.
Auf die gcc-toolchain umzusteigen, ist eine prima Idee (ich meine aber,
daß höhergradige gcc-Zicken sich standhaft weigern, die angegebenen
Versionsnummern aus dem Jahr 2010 zu compilieren).
Besser wäre wohl eine vorgefertigte.
.... allein, das würde ihm auch nichts nützen, denn auch diese toolchain
setzt ein laufendes System voraus, die wird sich mit den gleichen
Warnungen verabschieden wie sein legacy Produkt.
Unten auf der Seite https://www.mikrocontroller.net/articles/GCC_M68k
verlinkt ist ein schönes Beispiel, wie man das macht:
Das m68k-example Paket zeigt das, was der Wühlhase alles braucht, um auf
seinem System mit einer c-toolchain arbeiten zu können:
1. Vector.S enthält die Vektorentabelle
2. crt0.S enthält den Start der CPU und die
Systeminitialisierung
3. ram.ld oder rom.ld ist das Linkerskript
4. Makefile
Damit fängt das an: Das braucht er "nur" umzuschreiben für sein System.
Ist eben die grande tour.
Assembler fände ich in dem Fall schneller zielführend. Zumal die
"C-Files" 1-2 auch nur Assembler Files für den m68k-gcc-as sind.
appinit.c, uart.c machen wohl Hardware-Initialisierungen und glue.c
wirkt wie ein kleines Betriebssystem mit sys-calls.
... und erst am Schluß kommt main.c
Letztlich aber wird man/er in dem einen oder anderen Fall nicht
weiterkommen, wenn man nicht weiß:
a) Speicherbelegung:
RAM: von bis
ROM: von bis
Adresse der magischen LED
Adresse z.B. eines Timerbausteines
Adresse z.B. einer UART
b) Was ist das für ein Timer -> wie wird der programmiert
was ist das für eine UART -> wie wird die programmiert
Wie werden die LED geschaltet.
Bestenfalls kann man, wenn man zumindest weiß, wie die LED geschaltet
werden, eine Zeitschleife, "LED an", Zeitschleife, "LED aus"
programmieren (mit Cache aus).
Und wenn das blinkt ...... dann weitersehen.
Gruß
Olav
Olav schrieb:> Das m68k-example Paket zeigt das, was der Wühlhase alles braucht, um auf> seinem System mit einer c-toolchain arbeiten zu können:
wenn's "schnell und schlampig" sein darf, braucht's das alles gar nicht:
1
voidmain(void);
2
longstack[32];
3
4
structzero{
5
long*stack;
6
void(*initialpc)(void);
7
};
8
9
structzero_start
10
__attribute__((section(".text")))={
11
.stack=&stack[31],
12
.initialpc=main
13
};
14
15
16
voidmain(void)
17
{
18
while(1);
19
}
Vektortabelle braucht man nur, wenn man Traps verwendet oder Fehler im
Code einbaut ;).
Das (GC)C-Programm kompiliert mit
So, da bin ich wieder.
@Dieter:
Nein, es gibt keine weiteren (E)EPROMs. Den, den ich da programmiere,
ist der einzige.
@Bernd:
Naja, das mag man früher so gemacht haben, aber so viele EPROMs haben
wir leider nicht. Die Dinger sind heute nicht mehr so einfach zu
bekommen und wenn, dann sind sie sauteuer.
@Olav:
Danke für die Codefetzen, da werde ich gleich mal etwas rumbasteln. Die
"Grande Tour" mit Linker mache ich auch nur, weil ich davon wenigstens
etwas Dokumentation habe und dachte, daß das einfacher wird. Ich hätte
aber auch kein Problem mit reinem ASM (auch wenn ich das schon länger
nicht mehr gemacht habe), das werden nur sehr kleine Programme die ich
schreiben will.
Die Platinen haben, neben dem 68020, noch etwas Logik drauf. Neben einer
seriellen Schnittstelle u.ä. gibt es auch ein paar Hardwareregister, an
einigen dieser Registerbits hängt eine LED. Wird ein bestimmter Wert an
eine bestimmte Adresse geschrieben, wird das Bit gesetzt oder
zurückgesetzt.
Aber wie gesagt, das RTOS kann ich leider nicht verwenden. Das Geraffel
ist so konstruiert, daß es das auszuführende Programm in den RAM lädt,
und genau das soll nicht sein. Ich will z.B. nachher prüfen, ob alle
RAM-IC ok sind und wenn nicht, das defekte aufspüren. Das geht mit RTOS
nicht.
Der ASM-Code ist in der Tat abscheulich, aber die Werkzeuge stammen auch
aus Mitte der 90er. Ich kann langsam gut verstehen, warum viele noch
lange ASM anstatt C vorgezogen haben.
@Bernd:
Nein, tatsächlich keine PWM, sondern einfaches Schalten. Die LEDs hängen
nicht direkt am 68020 dran, sondern da ist noch etwas Logik dazwischen,
die braucht das so. Das hat - mit RTOS, das ja weg soll - auch so
funktioniert.
@Olav:
Ja, daß die S3-Datei nicht direkt Maschinencode ist, ist mir klar. ;)
Und mein Programmiergerät weiß das auch.
Der verlinkte Onlineassembler hat das auch korrekt als S3 erkannt, und
wollte nur noch die Architektur wissen. Und dann spukte er sowas aus:
1
.sec1:00000000 46 db 46h ; F
2
.sec1:00000001 fc db fch ;
3
.sec1:00000002 27 db 27h ; '
4
...
@DerEinzigeBernd:
Genau. Als Architektur noch m68k:68020 auswählen, und dann kommt das
raus, was ich eben geschrieben habe. Oder lese ich das falsch?
@Olav und Markus:
Tja, ich habe anfangs tatsächlich kurz überlegt, ob ich mir einen
GNU-Compiler suche.
Ich hatte irgendwann, schon länger her, mit Cygwin/MinGW irgendwas zu
kompilieren versucht. Ich habe mir danach vorgenommen, mit dem Zeug nie
wieder etwas zu tun haben zu wollen.
Und etwas Funktionierendes umzubauen habe ich mir etwas einfacher
vorgestellt als wieder mit MinGW loszutoben.
Aber ja, ich überdenke dies diese Tage nochmal...für den Rest der Woche
habe ich vorm 68020 jedenfalls erstmal wieder meine Ruhe. ;)
Insbesondere schaue ich mir mal das verlinkte Beispiel an...
Es stimmt tatsächlich: In dem Beispiel vom Compiler-Hersteller, das ich
umgebaut habe, habe ich etwas zuviel rausgeworfen, die
Interruptvektortabelle war da doch drin...leider nur sehr rudimentär, da
scheint immer noch einiges zu fehlen.
