Hallo,

im Z80 GP 2.0/3.0/3.1 habe ich Darstellungsfehler in "Speicher ändern" .. die Adressen und alle Bytes bis auf das letzte blitzen nur kurz auf und sind dann nur mehr ein paar Pixel.

Ist das auch ein Problem mit dem Wrap-Around beim EF9367?

Ich vermute das GP schreibt einfach nach dem letzten Zeichen fix X Leerzeichen um eine ev. frühere längere Zeile zu löschen und statt nach rechts aus dem Bild zu fallen überschreiben sie so den Anfang der neuen Zeile?

Dass das GP2018b+ den EF9367 unterstützt ist mir bewusst (ich habe es auch erfolgreich getestet) aber die dort weggefallene Symbolverwaltung bedeutet leider, dass die Beispiele aus den RDK-Büchern nicht mehr 1:1 funktionieren. Für den (in diesem Bereich) Einsteiger-Kollegen von mir, der auch gerade einen NKC baut, wäre das meiner Meinung nach wichtig.

Gruß,
Christian

Moin Christian,

wenn du ähnliche Bildfehler hast wie auf meinen Bild, dann ist es das "Wrap-Around" Problem mit dem EF9367.



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

Hallo Jens,

ja genau die sinds .. ich nehme an es ist dieser Teil in "befprint"?


befprx:
ld b,40 ;rest auffuellen mit leerzeichen
bef2pr:
call blank ;um alten teil zu loeschen
djnz bef2pr


Wenn ich die 40 im Binary patche verschwinden sie, aber ja dafür bleibt manchmal der alte Rest stehen

Hab noch kaum auf Z80 programmiert, auf 6809 und 68k würde ich den Buffer bis Ende füllen, muss aber sehen wie das dort geht...

Gruß,
Christian

Moin Christian,

mit deiner Vermutung liegst du richtig.
Die Routine schreibt stur 40 (weitere) Leerzeichen in die Zeile. Wenn jetzt schon Zeichen vorhanden sind werden da 40 weitere angehängt.
Man müste also das Register B mit der entsprechenden Anzahl setzen. Alternativ könnte man den Buffer auch erst mit obiger Routine löschen und dann erst den Text reinschreiben...

Aber ich bin da auch nicht der Z80 Experte...

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

Hallo,

so jetzt wollte ich mir das mal genauer anschauen, konnte aber den Quelltext der auf ndr-nkc.de verfügbar ist mit dem dort empfohlenen TASM nicht korrekt assemblieren.

Ich bekomme 100te Fehlermeldungen über nicht verfügbare Labels, und das dennoch erzeugte Objektfile ist >8KB unabhängig von den Optionen.

Was ich aus dem Listfile zu erkennen meine, ist, dass der TASM die verschachtelten #IF .. #ENDIF nicht korrekt behandelt (er beachtet immer nur die "neueste" Bedingung) und daher Codeblöcke und Menütexte einbindet die nicht gewünscht sind. So z.B. bei Auswahl deutsch und CAS .. auch die englischen CAS-Texte und ein Teil der USB-Routinen.

Außerdem steht im GP3.1 Quelltext noch "Grundprogramm 3.0" .. das erscheint mir also nicht die Endversion zu sein.

Hat die jemand?

Gruß,
Christian

Okay, mit TASM 3.2 statt dem dort hinterlegten TASM 2.8 ließ es sich übersetzen ...

Aber ich hab geflucht über den Z80 Befehlssatz, da geht ja garnix, den Pointer IX mit einer Endadresse vergleichen .. da muss man ja voll "von hinten durch die Brust ins Auge.." .. bin ich zu sehr 68K verwöhnt?

Das ist mein aktueller Hack, mir gefällt es nicht weil kein 16bit Vergleich .. muss mal nachlesen wie man das beim Z80 macht..


befprx:
call blank

push ix
pop bc ; IX nach BC kopieren

ld a,(ausbuf+40)%256
cp c ; Hack, C vergleichen reicht erstmal ..
jr nc,befprx ; Buffer auffüllen bis IX an Zeilenende

ld hl,ausbuf ;Adresse Buffer holen
call textsetaus ;Zeile ausgeben
ret


Es funktioniert aber soweit ..

Und jetzt muss ich raus das Hoftor zusammenflicken.

Gruß,
Christian

Ja, Du bist verwöhnt. 68k und Z80 sind sehr verschiedene Architekturen. Ein Problem ist, dass die allermeisten Bücher über Mikroprozessoren nicht erklären, warum die Architektur so ist, wie sie ist.

IX und IY sind keine Universalregister, sondern spezielle Indexregister. Sie werden gerne zur Addressierung in einem Stackframe oder Workspace benutzt. In Pascal hat man ja geschachtelte Scopes und damit einen Stack von Adressen von Stackframes. Man sieht im generierten Code von Turbopascal, wie die Indexregister gut verwendet werden, meine ich. Man kann beim Verzicht auf Rekursion Unterprogramme ohne Stack benutzen, indem die Stackframes aller Unterprogramme statisch alloziert werden und die Indexregister zeigen dann auf deren jeweilige Basis.

Der Z80 ist ein klassischer Prozessor, wo sich alles um den Akkumulator dreht, dem aber noch ein paar Register zur Seite gestellt wurden, um etwas effizienter zu werden, und der alles enthält, was ältere Minicomputer hatten - nur dass die wenigsten Programmierer von Mikros zu der Zeit Erfahrung mit Minicomputern hatten und darum nicht wussten, wie die Architektur gedacht ist.

68k ist ein klassischer Prozessor mit Universalregistern, ebenfalls sehr von Minicomputern inspiriert (PDP11, IBM/360). Es ist kein Zufall, dass diese Systeme viel bekannter und kommerziell erfolgreicher als andere waren, weil effizienter Code leichter zu schreiben war.

Michael

Hallo,

nun, der 6809 ist IMHO auch eine Akkumulator-Maschine, finde ich aber nicht ganz so furchtbar .. aber gut, der ist 4 Jahre jünger, was in dieser Zeit mehrere Generationen bedeutete. Und dazu eigentlich beinahe eine 16 bit-CPU.

Und ja, vermutlich ists es auch Gewohnheit und ich versuchte meine 6809/68000 Prinzipien auf den Z80 anzuwenden, was halt schief geht.

Nach etwas Konsultation des Internets bin ich jetzt bei folgender Lösung angelangt:


befprx:
call blank

push ix
pop bc ; IX nach BC kopieren

or a ; Carry löschen
ld hl,ausbuf+40
sbc hl,bc ; Vergleich
jr nc,befprx ; Buffer auffüllen bis IX an Zeilenende

ld hl,ausbuf ; Adresse Buffer holen
call textsetaus ; Zeile ausgeben


Soweit funktionierts, mal sehen wo ich noch drauf stoße

Und 68000 "sehr von PDP11 inspriert" .. allerdings. Schon allein die 6bit Adressefelder mit 3bit Modus und 3bit Registernummer ..

Gruß,
Christian

Moin,

ich sagte ja, das ich nicht so der Z80 Experte bin, ich bin nämlich auch 68000er geschädigt (verwöhnt)

Deine Routine sieht doch eigentlich schon sehr gut aus.

PS: Eine 6809 CPU Karte wollte ich auch nochmal umsetzen...

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

Hi,

nun ihr habt eine 6502-CPU-Karte. Paar Pins umsortieren und die Kiste sollte laufen, ist ja mehr oder weniger der selbe Bus.

Man kann sich allerdings das Timing etwas unkritischer machen, indem man den Takt Q benutzt um die Gültigkeit der Adressen festzulegen. Das benutze ich in meinem anderen System (ursprünglich Selbstbausystem meines Vaters) extensiv.

Und gönne dir einen6309, die Hitachi-Version. Die "geheimen" Features machen den fast so komfortabel wie einen 68K... wenn du ihn in den "Native"-Mode schaltest ist er auch nochmal 30-40% schneller.

Gruß,
Christian