Alles anzeigenhier passt vielleicht folgende Frage rein:
In den Source-Codes zum JavaCPC hab ich das Assembler-Mnemonic BREAK
Es wird mit dem Opcode DB FF assembliert.
Kann mich jemand aufklären? Ich finde weder "BREAK" noch "DB FF" irgendwo in den offiziellen und illegalen Opcodes. Was macht der Opcode?
Ich schätze mal, dass das ein Breakpoint ist, der direkt in den Debugger in JavaCPC reinspringt. Unter WinApe gibt es zumindest sowas... Da kann man mit dem Befehl "db 0xed, 0xff" einen Breakpoint im Programm setzen.
Beitrag gelöscht
In den Source-Codes zum JavaCPC hab ich das Assembler-Mnemonic BREAK
Es wird mit dem Opcode DB FF assembliert.
Kann mich jemand aufklären? Ich finde weder "BREAK" noch "DB FF" irgendwo in den offiziellen und illegalen Opcodes. Was macht der Opcode?
Was heist mit dem Opcode DB FF ? Ist das der erzeugte Binaercode, oder die Assemblerzeile? Erstere waere ein IN von FF, letztere ein RST8, was durchaus Sinn macht wenn man an ein echtes System vor Augen hat, wo man die CPU zur Mitarbeit ueberreden muss. Der RST8 fuehrt dann in den Trace/Debugger.
Ich schätze mal, dass das ein Breakpoint ist, der direkt in den Debugger in JavaCPC reinspringt. Unter WinApe gibt es zumindest sowas... Da kann man mit dem Befehl "db 0xed, 0xff" einen Breakpoint im Programm setzen.
EDFF ist eine undefinierte Funktion, die wie 2 NOP ausgefuehrt wird (beim ersten NOP mit gesperrten Interrupts, wie bei allen Prefix-Befeheln - eine der Macken der Z80) Bei einem Software-Emulator, der ja dann was anderes machen kann, ist das durchaus ein gangbarer weg, um Breakpoints zu basteln. Man scannt ja sowiso den ganzen Befehlsstrom und kann bei diesem Opcode dann in einen Debugingmode gehen. Die Mitwirkung einer Echten CPU muss ja nicht eingefordert werden :). Schliesslich will man ja alle moeglichen Rechner emulieren koennen, auch solche die alle RST bereits belegt haben.
Aber wie gesagt, ich nix Z80 Spezi, ich weis nur das was man so am Rande (und bei Dinos Vortraegen) mitbekommt.
H.
Beitrag gelöscht
Ja: ED FF -> Break instruction. Gibt es auch im WinApe Assembler.
Jo, aber nur im Emulator - eine echte Z80 wird da aber nicht BREAK-en, sondern zwei huebsch M1 Zyklen hinlegen (=8 Takte nix tun), und weiterarbeiten. Schoen Idee feur einen Emulator, aber auch einer der Fallstricke wenn man darauf Programme fuer echte Rechner entwickelt (siehe der andere Thread).
Gruss
H.
Beitrag gelöscht
Beitrag gelöscht
Sorry, aber das ist Käse! Es wäre wohl eine Macke inmitten der Befehlsausführung zu Unterbrechen und einen Interrupt zuzulassen.
Auf cpus wie 6502, bei denen jeder Befehl nur ein Byte lang sein kann, muss man sich darum freilich nicht scheeren.
Also bitte keine Z80 Verunglimpfung!
Auf eine vermeindliche Verunglimpfung gleich mit 'Kaese' (obwohl ich Kaese mag) reagieren ist doch unter Deiner Wuerde Stefan, oder? Lass man Sachlich sein.
Ich hab jetzt extra ins Manual geschaut, wie gesagt, die Z80 ist bei mir nie so im Fokus gestanden, haette mich ja Irren koennen.
Die Z80 prueft am Ende jeden Befehls, also im letzten T-Zyklus (Bei 1-Byte Befehlen ist das der M1 Zyklus, in dem das Befehlsbyte geholt wird) die INT-Leitung. Aus Sicht der Befehlsdekodierung sind die Prefixe jeweils ein eigener Befehl, ein Befehl mit dem der Befehlsdecoder umgeschalten wird. Nach dem Umschalten ist der Befehl vorbei, wie jeder andere Ein-Byte-Befehl, und ein neuer M1-Zyklus startet, der den folgenden Befehl holt, welcher ueber den umgeschaltenen Decoder bearbeitet wird. Damit jetzt nicht im T4 des Prefix-Bytes ein Interrupt reinhaut - der ja vor dem neuen M1 Zyklus zulaessig waere - wird hier der Interrupt gesperrt. FF ist in der ED Tabelle als ein 1 Byte NOP definiert. Damit ergiebt sich die Ausfuehrungszeit von EDFF genauso wie bei 2 NOP hintereinander ... nur halt ohne die Moeglichkeit dass zwischendrinn ein Interrupt reinhauen kann.
Oder Kurz gesagt, die Z80 fuehrt bei Befehlen mit Prefix nicht einen sondern 2 Befehle aus, wobei der erste am Ende keinen Interrupt zulaesst. Wenn Du wo einen Beleg hast, dass es anders lauft, lass ich mich gerne ueberzeugen.
Der Trick ist eigenlich ganz simpel, und passt auch gut zu der Art wie der Fetch bei der Z80 gemacht wird. Bei der 6502 ist das nicht einfacher, sondern im Gegenteil wegen des Pipelinings sogar komplizierter, da die Abarbeitung des letzten Befehls paralell zum nachsten Fetch stattfindet.
H.
Ja, der Hans, der kanns 
@TFM: Sorry, nichts für ungut, aber Dein Beitrag war irgendwie überflüssig. Geht's hier um Götzenanbetung oder um Informatik? Bei ersterem solltest Du besser das Forum wechseln 
Ansonsten wäre es schön, wenn man sich auf die Technik konzentriert und nicht irgendwelche Wut- und Liebesgefühle vermengt äußert gegenüber solchen, die einfach nur neutral fachsimpeln wollen.
CU,
Prodatron
@TFM: Sorry, nichts für ungut, aber Dein Beitrag war irgendwie überflüssig. Geht's hier um Götzenanbetung oder um Informatik? Bei ersterem solltest Du besser das Forum wechseln
Lass man, TFM und ich, wir verstehen uns schon
H.
Beitrag gelöscht
...ich hätte noch ein Frage hierzu:
Ich disassembliere gerade eine Datei aus einem Demo von "Grim" mit dem Namen '800x600 Interlaced' "Code.bin"
Hier werden zwei Mode 2 Overscan Bilder "geflippt". Das disassemblierte File schaut im JavaCPC o. auch WinApe wie folgt aus:
;; JavaCPC disassembled binary
;; disassembled from #FA00 to #FA59
;; Fri Jul 13 14:46:07 CEST 2012
ORG #FA00
DI ;;FA00: . F3
LD BC,&BC01 ;;FA01: ... 01 01 BC
OUT (C),C ;;FA04: .I ED 49
INC B ;;FA06: . 04
DB &ED,&71 ;;FA07: .q ED 71
LD SP,&FA09 ;;FA09: 1.. 31 09 FA
LD BC,&7FC4 ;;FA0C: ... 01 C4 7F
OUT (C),C ;;FA0F: .I ED 49
LD HL,&4000 ;;FA11: !.@ 21 00 40
LD DE,&0000 ;;FA14: ... 11 00 00
LD BC,&4000 ;;FA17: ..@ 01 00 40
LDIR ;;FA1A: .. ED B0
LD DE,&8000 ;;FA1C: ... 11 00 80
LD BC,&7FC5 ;;FA1F: ... 01 C5 7F
CALL &FA4F ;;FA22: .O. CD 4F FA
LD BC,&7FC0 ;;FA25: ... 01 C0 7F
OUT (C),C ;;FA28: .I ED 49
LD HL,&8000 ;;FA2A: !.. 21 00 80
LD DE,&4000 ;;FA2D: ..@ 11 00 40
LD BC,&3800 ;;FA30: ..8 01 00 38
LDIR ;;FA33: .. ED B0
LD DE,&8000 ;;FA35: ... 11 00 80
LD BC,&7FC6 ;;FA38: ... 01 C6 7F
CALL &FA4F ;;FA3B: .O. CD 4F FA
LD DE,&C000 ;;FA3E: ... 11 00 C0
LD BC,&7FC7 ;;FA41: ... 01 C7 7F
CALL &FA4F ;;FA44: .O. CD 4F FA
LD BC,&7FC0 ;;FA47: ... 01 C0 7F
OUT (C),C ;;FA4A: .I ED 49
JP &3800 ;;FA4C: ..8 C3 00 38
OUT (C),C ;;FA4F: .I ED 49
LD HL,&4000 ;;FA51: !.@ 21 00 40
LD BC,&3800 ;;FA54: ..8 01 00 38
LDIR ;;FA57: .. ED B0
RET ;;FA59: . C9Bei Adresse &FA07 gibt den Eintrag "DB &ED,&71" was ja laut http://www.z80.info/z80undoc.htm ein illegaler Opcode ist und eigentlich OUT F,(C) sein sollte. MAXAM selbst mach daraus zwei Befehlszeilen (einmal &ED mit ??? und dan &71 mit LD (HL),C) - egal.
Wie kann ich mir illegale Opcodes beim Disassemblieren richtig anzeigen lasen? Gibt es so etwas?
Bei Adresse &FA07 gibt den Eintrag "DB &ED,&71" was ja laut http://www.z80.info/z80undoc.htm ein illegaler Opcode ist und eigentlich OUT F,(C) sein sollte.
Und mit einem '?' dahinter - weil in wirklichkeit machts ein OUT mit 00h - ein beliebter Trick auf allen Z80 ... und auf der HD64180 glaube ich sogar ein offizieller Befehl. (*1.*2)
MAXAM selbst mach daraus zwei Befehlszeilen (einmal &ED mit ??? und dan &71 mit LD (HL),C) - egal.
Wie kann ich mir illegale Opcodes beim Disassemblieren richtig anzeigen lasen? Gibt es so etwas?
Das ist kniffelig. Ich denke mal es sollte nicht schwer sein die einzubauen, aber gerade weil nicht alle undokumentierten ueberall auch was bewirken muss man dann dem Dissassembler wieder Schalter verpassen wie er den Input sehen soll. das kann schnell schwierig werden.
H.
--
*1 - in der Liste ist auch der ED70 als IN (C),f benannt, wobei das nicht ganz richtig ist, es wird nicht das Flagregister mit dem Wert vom Port gelesen, sondern nur entsprechend des gelesenen Wertes gesetzt - der Wert selbst geht verloren.
*2 - Ich mag dass mit del Illegal nicht so sehr. Es sind erstmal undokumentierte Befehle. Dafuer gibts vielerlei Gruende entweder sind es
- Unbeabsichtigte Seiteneffekte auf Grund des Designs der Hardware (wie bei der 6502 die fehlende Dekodierung der x2 und x4 Spalte bzw. die unbelegten ED 01xxxxxx/10xxxxxx bei der Z80 (da aber wenigstens richtig ausdekodiert)), oder
- es sind Funktionen die unter bestimmten Umstaenden macken haben (ROR bei der 6502), oder
- 'Ueberfluessig' waren (move A nach A oder sowas (ja, ich weis, das ist der 8080-NOP)
- Aus was fuer ueberlegungen heraus auch immer nicht offiziell gemacht wuerden
Wichtig ist dabei nur ob diese Absichtlich drinnen waren, und dann auch in Weiterentwicklungen drinnen blieben, oder aber nur Zufall. In letzterem Fall ist es besser darauf zu verzichten.
So eine Diskussion hatten wir letztens in diesem Thread (etwas verstreut):
undocumented/illegal OpCodes im Z80
CU,
Prodatron
Beitrag gelöscht
So eine Diskussion hatten wir letztens in diesem Thread (etwas verstreut):
undocumented/illegal OpCodes im Z80
CU,
Prodatron
Ja, das stimmt. Ich dachte, ich frage hier nochmal, weil Devilmarkus von einer Einstellung / Funktion zum Debuggen sprach.
WinApe und JavaCPC verstehen den Opcode ED, FF (JavaCPC, wenn man diese Funktion im Debugger aktiviert )
Bis dann.
