Bildschirminhalt in RAM sichern (CBM4032/8032/etc)

Zitat von CBM_Ba

Besteht die Möglichkeit, in Basic den Inhalt des Bildschirms in den Ram zu sichern, um ihn relativ flott wieder zurückholen zu können?

Ja natürlich.

Sind ja auch nur 1K RAM (bzw. 2K bei 80 Zeichen)

Manche Erweiterungen bieten von vornherein 4 Seiten Bildschirm, die man umschalten kann.

Allerdings würde ich zwei Mini Assembler Routinen vorschlagen (geht viiiiel schneller).

Die vom BASIC aus mit SYS oder USR() aufgerufen werden ...

Zitat von CBM_Ba

Aber erstens ist dies zeitintensiv in Basic, und zweitens weiß ich nicht, ob es da eine Möglichkeit gibt, welche weit weniger Variablenspeicher benötigen würde?

Man kann das schon in Variable ablegen.

Zum Beispiel in einem String Array.

Aber das macht es etwas komplizierter.

Ich würde den BASIC Speicher oben etwas abschnippeln (HIMEM) und das als Buffer verwenden

Manche CBM haben sowieso 4KB RAM.

Da kannst du immer zwei Seiten speichern (oder 4 bei 40 Zeichen).

Ohne dass du regulären RAM dafür verbratest.

Wegen dem Bildschirm "Retten". Wenn es tatsächlich nur um das Beibehalten und nicht ums Abspeichern geht, dann probier doch mal Assembler direkt. Klappt natürlich nur, wenn genug RAM vorhanden ist.

Die ganz simple Variante wäre jedes Byte des Bildschirmspeichers auslesen und in einen anderen Bereich des RAMs kopieren. Beim Ausblenden des HelpScreens dann wieder genau andersherum.

Als Tip: Versuche Schleifen zu machen, die zeilenweise auslesen. Noch optimaler wird es, wenn man unterhalb von 256 Bytes bleibt und z.B. gleich 4 Zeilen auf einmal kopiert.

Der Ablauf in der Schleife ist ungefähr LDA $Bildadresse,X : STA $AndereAdresse,X : INX : Vergleiche ob Länge erreicht.

Zitat von CBM_Ba

Zum Thema laden/speichern bin ich aktuell auch noch nicht zufrieden... ein Level hat gute 17 blocks, da ich den Wert einer jeden Speicherzelle des Bildschirms wegsichere.

Da gibt es ein schönes Stichwort, was hier vmtl. Super funktioniert. Heißt "Run Length Encoding" (RLE).

Es bedeutet, daß Du schaust, ob ein SPACE als nächstes kommt und wenn ja, ob das übernächste auch noch ein SPACE ist, und wenn ja, ob das Über-Über-Nächste immer noch ein SPACE ist. Die zählst Du solange durch, bis es dann dochmal ein anderes Zeichen wird ( Blockstein ). Abgespeichert wird dann nicht jedes SPACE einzeln sondern: SPACE + Anzahl wieviel es waren.

Beim Einlesen weiß man dann ja, daß nach einem gelesenen SPACE die Anzahl der zu zeichenenden SPACEs kommt. Beachten muß man nur, daß natürlich beim 8Bit Rechner nur bis 256 gezählt wird, man muß also auch einplanen nach dieser Zahl schonmal ein "SPACE"+256 abzuspeichern und dann mit einem neuen Zähler bei "0" wieder anzufangen.

Die Levelumrandung wird natürlich gar nicht mitgespeichert, wenn es eine gibt ("*").

Muss man den Bildschirm denn wirklich zwischenspeichern?

Wenn man eine zentrale Routine hat, die den Bildschirm aufbaut, dann muss man ihn nicht zwischenspeichern.

- Bildschirm löschen

- Hilfeschirm anzeigen

- auf Taste warten

- Bildschirm löschen

- zentrale Bildschirm Routine starten

Hex wird einfach verwendet, weil es die platzsparendste Form einer Binärzahl darstellt. Schliesslich war gerade zu Beginn der 8 Bit Computerzeit der Platz auch auf dem Bildschirm oft begrenzt. Z.B. VC-20 mit 23 Zeichen pro Zeile...

Du musst auch weniger tippen, wenn Du es in Hex eingibst.

Zitat von Holger

Ich würde mir den Source ja gerne ansehen, aber ich traue mich nicht, einen CBM einzuschalten, weil der 720 nach 15 Minuten im Netzteil Silvester feierte.

Seufz.. das macht man ja auch nicht, wenn man nicht VORHER mal die original verbauten Netzfilter-Kondensatoren im Netzteil angeschaut hat. Zu 99% haben die nämlich die besagten Alterungsrisse, durch die sie innerhalb einer relativ kurzen Frist nach Einschalten effekt- und duftvoll abrauchen. Da passiert aber meist nicht mehr als eben *pfffffft...* und *bäh!*, deshalb einfach austauschen, dann geht alles wieder. Und halt am besten schon vor dem Einschalten prüfen und umlöten - die Austauschkondensatoren kosten da nicht die Welt, und zusätzlich kann man auch gleich die Elkos ersetzen, da die auch seeeehr häufig platt sind. Hab ich grad bei meinem CBM 720 erledigt, als nächstes ist der CBM 710 dran.

Altbekanntes Thema aber. Nach meinen bisherigen Erfahrungen scheint bislang eine der größten Raritäten im Computerbereich nicht ein bestimmtes Gerät zu sein, sondern ein golden-teiltransparenter RIFA-Netzfilter im Netzteil eines Retro-Geräts *ohne Alterungsrisse*... (und nein, bitte jetzt keine Bilder solcher "Raritäten" hier posten, der Thread soll damit nun nicht zugespammt werden!)

Welche möglichen Inhalte kann denn eine Position Deines Levels / Leveleditors auf dem Bildschirm haben? Nur "Wand oder leer"? Oder noch weitere andere Zeichen pro Position? Und die Spielfeldbegrenzung (Außenrand) ist ebenfalls dann ein "Wand"-Zeichen, oder?

H Matthias,

hast Du mal irgendwie eine Zeichnung des Labels? Welche "Bausteine" kommen vor? Wand, Gegner, Türen, ect? Liegt das Level schon im Speicher oder muss dieses von Disk geladen werden? Evtl. kann ich Dir eine Assembler-Routine programmieren.

Beste Grüße

Marco

Ich fragte deshalb nach der Anzahl möglicher verschiedener Symbole im Bereich des Spielfelds, weil man da ggf. einiges ausnutzen *könnte*. Bei simplem "Wand oder Nicht-Wand" könnte man das gesamte Spielfeld in 105 Bytes kodiert unterbringen, und das Kodieren und Dekodieren wäre in Assembler recht einfach machbar. Bei 4 verschiedenen Symbolen (inkl. Leerzeichen) wäre das Spielfeld in 210 Bytes ablegbar, bei 16 Symbolen immerhin noch in 420 Bytes. Und Assembler ist so schnell und speichereffektiv, dass auch die notwendigen Routinen kaum Rechenzeit fressen.

Erläuterungsansatz:

Man speichert für jede Bildschirmposition nur einen Code für eines der möglichen Zeichen - sind nur 2 Symbole vorgesehen, reicht ein einzelnes Bit. "0" wäre in dem Fall z.B. dann das Leerzeichen, "1" die Wand. Über die Bitshift-Befehle des 6502 lassen sich jeweils 8 dieser Bits zu einem Byte zusammenpacken. Beim Wiederherstellen schiebt man einfach die Bits wieder eins nach dem anderen aus den eingelesenen / abgelegten Bytes raus und setzt je nach Ergebnis (Bit steht dann im Carry-Flag, kann man über BCC / BCS prüfen) an der jeweils aktuellen / nächsten Bildschirmposition für "0" ein Leerzeichen, für "1" eine Wand. Nach 8x Bitschieben (innere Schleife) nimmt man sich dann das nächste Byte vor, bis der Bildschirm gefüllt ist (äußere Schleife).

Bei mehr verfügbaren Symbolen generiert man aus einer Zeichentabelle einen Index, der dann eben "1 von 4 Zeichen" oder "1 von 16 Zeichen" gemäß einer Tabelle repräsentiert. Ersteres verwendet 2 Bit, dann gehen 4 Positionen in ein Byte, Letzteres nutzt 4 Bit ( = ein Nibble), reicht also für 2 Zeichenpositionen in einem Byte. Bei 4 Bit pro Zeichen kann man sich dann auch das bitweise Rollen (fast) komplett sparen, weil man über "AND #$0F" den ersten Tabellenindex und danach über 4x "LSR A" den zweiten Tabellenindex ermitteln kann... (natürlich brauchst Du noch ein paar weitere Assemblerbefehle dazu, aber es ging mir erstmal um die Einfachheit der Logik in der Kodierung; die Auswertungsroutinen sind programmtechnisch relativ trivial..)

Zitat von Dekay

Hex wird einfach verwendet, weil es die platzsparendste Form einer Binärzahl darstellt. Schliesslich war gerade zu Beginn der 8 Bit Computerzeit der Platz auch auf dem Bildschirm oft begrenzt. Z.B. VC-20 mit 23 Zeichen pro Zeile...

Du musst auch weniger tippen, wenn Du es in Hex eingibst.

Ähm, nein. Sondern weil man das im Kopf in Binär umwandeln kann. Und weil alle modernen Computer als Speicherbreite ein Vielfaches von 8 Bit verwenden. Das ist genau eine Hex-Ziffer.

Als Computer noch üblicherweise ein Vielfache von 3 als Speicherbreite hatten (12 Bit, 18 Bit, ...) wurde das Oktal-System verwendet, weil 3 Bit genau einen Octal-Ziffer darstellen. Oktal ist nicht platzsparender als Dezimal.

OK, das klingt schon wieder nach Hardcore-Coden 😊

Ich hätte tatsächlich ab irgendeiner Adresse die Bytes ausgelesen und dementsprechend als "Zeichen" interpretiert. Da hast Du tatsächlich von 00 bis ff mögliche Zeichen (für ein sehr gestalterisch umfangreiches Level 😅). Deine Tricks ...d.h. das ich noch viel lernen kann.

Beste Grüße

Marco

Zitat von CBM_Ba

Was meinst du mit "zentraler Bildschirm Routine"? Der Aufbau des Levelrandes, etc... passiert eh mit so einer Routine- aber das geht flott, weils eben nur der Rand ist. Um das ganze Level nach Wechsel in einen anderen Bildschirminhalt neu darstellen zu können, bräuchte ich deutlich schnellere Varianten, als mit FOR-NEXT. Sonst nervt das Spiel, es soll ja flüssig zu spielen sein.

Eine zentrale Routine, die das ganze Spielfeld neu aufbaut.

Muss ja nicht schnell sein.

Nachdem man die Hilfe gelesen hat, kann sich das Spielfeld ja wieder langsam aufbauen.

Und irgendwo: "drücken Sie 'W' um weiter zu spielen ..."

Zitat von detlef

Ähm, nein.

Erklär mir wo der Widerspruch ist. Was moderene Computer tun oder nicht spielt ja hier keine Rolle. Kennst Du ein Zahlensystem wo man binäre 8 Bits kürzer und lesbarer darstellen kann?

So, ich hab mal im "Quick-and-dirty"-Modus den theoretischen Ansatz für das Sichern und Zurückschreiben des Spielbildschirms in Assembler umgesetzt.

Code ist weitgehend kommentiert, die Vorgaben ebenfalls. Ich bin mal von maximal 16 verschiedenen Elementen / Symbolen auf dem Bildschirm ausgegangen und habe daher eine "2-Bildschirmbytes-in-1-Sicherungsbyte"-Kodierung verwendet.

Keinerlei Anspruch auf Fehlerfreiheit, weil ich grad keine Chance zum Ausprobieren habe. Der Code sollte aber keine groben Böcke mehr haben. Er ist aber natürlich nicht zwingend syntax-korrekt für einen Assembler vorbereitet, was Variablen und Sprunglabel-Format (hier mit führendem ":") anbetrifft. Sollte sich aber verstehen und umsetzen lassen - darauf kommt es an, denke ich...

Fragen - gerne! Korrekturen - auch!

Grüße aus Frankfurt,

Ralph.

            ;    Spielfeld-Startadresse: 32888 (32768+120), also Hex $8078
            ;    Version:    16 mögliche Codes / Zeichen als Spielfeld-Elemente
            ;    zu sichernde Zeichen = 21x40 = 840 Zeichen = #$0348
            ;    Zeropage-Adressen:
            ;    $5E/$5F      -    Zeiger in Bildschirm-RAM (Lo/Hi)
            ;    $60/$61      -    Zeiger in Sicherungsspeicher (Lo/Hi)

### Hauptprogramm(e) ###
            ; - geladenen / gesicherten Screen wiederherstellen mit SYS [Start]
            ; - Screen sichern / im RAM ablegen mit SYS [Start+3]


:Start
JMP    Load_Screen_from_Ram

:Save_Screen_to_Ram
JSR    Init        ;    Zeropage sichern und Zeiger neu setzen, alle Arbeitsregister auf #$00
:Save_Screen
JSR    Find_next_Char    ;    Erstes Zeichen identifizieren und -> Hi-Nibble
TXA
ASL    A
ASL    A
ASL    A
ASL    A
LDX    #$00
STA    ($60,X)        ;    zwischenspeichern im Ergebnisspeicher
INY

JSR    Find_next_Char    ;    Zweites Zeichen identifizieren und -> Lo-Nibble
TXA
LDX    #$00
ORA    ($60,X)        ;    mit Hi-Nibble verknüpfen
STA    ($60,X)        ;    Ergebnis in Ergebnisspeicher

INC    $60        ;    und Zeiger in Ergebnisspeicher um eine Position weiter
BNE    Label1
INC    $61        ;    (bei Überlauf des Lo-Bytes des Zeigers natürlich dann auch das Hi-Byte weiterzählen)
:Label1
INY            ;    Zeiger in Bildschirm-RAM weiterschieben
BNE    Label2
INC    $5F        ;    Hi-Byte bei Überlauf auch anpassen
:Label2
CPY    #$48        ;    auf Erreichen des Spielfeldendes prüfen:
BNE    Save_Screen    ;    Ende ist erreicht, wenn der Gesamtzeiger ins Video-RAM auf $8078 + $0348 zeigt, also hier: Y= #$48 und Zeiger in $5F = #$83
LDA    $5F        ;    (Zeiger Lo-Byte ist bereits fix auf #$78 gesetzt, also ergibt Zeiger $5E/5F + Y in obigem Fall $8378+0048=$83C0 -> Ende)
CMP    #$83
BNE    Save_Screen    ;    ...man könnte statt BNE auch mit BCC springen, ist aber hier identisch in der Wirkung...
    
JMP    Return        ;    Zeropage wieder restaurieren und von dort direkt zurück zum aufrufenden Programm


:Load_Screen_from_Ram
JSR    Init        ;    Zeropage sichern und Zeiger neu setzen, alle Arbeitsregister auf #$00
:Restore_Screen
LDX    #$00
LDA    ($60,X)        ;    Ein Byte aus kodiertem Ergebnisspeicher holen
PHA            ;    auf Stack retten
LSR    A        ;    Hi-Nibble zu Lo-Nibble machen (4x nach rechts schieben)...
LSR    A
LSR    A
LSR    A
TAX            ;    ...und als Index in X verwenden
LDA    Zeichencodes,X    ;    korrektes Zeichen für Bildschirm aus Tabelle holen, mit eben ermitteltem Index...
STA    ($5E),Y        ;    ...und in den Bildschirmspeicher schreiben
PLA            ;    geretteten Akku vom Stack holen
AND    #$0F        ;    Lo-Nibble isolieren...
TAX            ;    ...und als Index in X verwenden
INY            ;    Zeiger in Bildschirmspeicher auf nächste Position (Y wird an dieser Stelle IMMER ungerade, also keine Überlaufprüfung nötig!)
LDA    Zeichencodes,X    ;    korrektes Zeichen für Bildschirm aus Tabelle holen, mit eben ermitteltem Index...
STA    ($5E),Y        ;    ...und in den Bildschirmspeicher schreiben

INC    $60        ;    und Zeiger in Ergebnisspeicher um eine Position weiter
BNE    Label3
INC    $61        ;    (bei Überlauf des Lo-Bytes des Zeigers natürlich dann auch das Hi-Byte weiterzählen)
:Label3
INY            ;    Zeiger in Bildschirm-RAM weiterschieben
BNE    Label4
INC    $5F        ;    Hi-Byte bei Überlauf auch anpassen
:Label4
CPY    #$48        ;    auf Erreichen des Spielfeldendes prüfen:
BNE    Restore_Screen    ;    Ende ist erreicht, wenn der Gesamtzeiger ins Video-RAM auf $8078 + $0348 zeigt, also hier: Y= #$48 und Zeiger in $5F = #$83
LDA    $5F        ;    (Zeiger Lo-Byte ist bereits fix auf #$78 gesetzt, also ergibt Zeiger $5E/5F + Y in obigem Fall $8378+0048=$83C0 -> Ende)
CMP    #$83
BNE    Restore_Screen    ;    ...man könnte statt BNE auch mit BCC springen, ist aber hier identisch in der Wirkung...
    
JMP    Return        ;    Zeropage wieder restaurieren und von dort direkt zurück zum aufrufenden Programm



;### Subroutinen ###
; wegen mehrfacher Nutzung und besserer Übersicht ausgelagert in Unterprogramme



:Find_next_Char        ;    Subroutine
LDA    ($5E),Y        ;    nächstes Byte aus Bildschirm-RAM holen
LDX    #$0F        ;    Pointer auf Ende Vergleichstabelle setzen
:Check_Char
CMP    Zeichencodes,X    ;    Bildschirmzeichen mit Elementtabelle vergleichen
BEQ    Char_found    ;    an Position X gefunden!
DEX            ;    nicht gefunden, Zeiger auf nächstes Element der Tabelle
BNE    Check_Char    ;    und weitersuchen
:Char_found        ;    gefunden und weiter! Falls der Bildschirmcode NICHT in der Tabelle ist, wird als Ergebnis ein Leerzeichen (Index=0) gesetzt.
RTS


:Init
LDX    #06
:Save_ZP        ;    Zeropage-Inhalt sichern
LDA    $5D,X        ;    6 Bytes ab Adresse $5E holen
STA    ZPSave-1,X    ;    und sichern
DEX
BNE    Save_ZP
LDA    #$78        ;    Zeropage neu für Kopieren setzen
STA    $5E
LDA    #$80
STA    $5F
LDA    #Sicherungsspeicher Lo-Byte
STA    $60
LDA    #Sicherungsspeicher Hi-Byte
STA    $61
TXA            ;    Akku und Y-Register auch auf #$00 setzen
TAY
RTS


:Return
LDX    #06
:Restore_ZP        ;    Zeropage-Inhalt wiederherstellen
LDA    ZPSave-1,X    ;    6 Bytes aus Sicherungsablage holen
STA    $5D,X        ;    und ab Adresse $5E speichern
DEX
BNE    Restore_ZP
RTS


:Zeichencodes        ;    müssen an die Bildschirmcodes der verwendeten Spielfeld-Symbole angepasst werden!! $20 (Leerzeichen) sollte an 1. Pos bleiben!
.BYTE    $20, $41, $42, $43
.BYTE    $44, $45, $46, $47
.BYTE    $48, $49, $4A, $4B
.BYTE    $4C, $4D, $4E, $4F

:Sicherungsspeicher
.BYTE    (420x $00)

Sieht so aus als würde das gut gehen.

Aber Anfängerfreundlich ist anders, irgendwie.

Zu dem Hilfetext gibt es auch noch so ein Variante, die evtl auch komplett ohne Speichern des Bildschirmes auskommt. Zumindest nicht in so einem Sinn, daß man das wirklich in gut auch als Level wegspeicherbare Sachen "komprimiert", wobei das natürlich eleganter ist.

Hier mal die einfache Variante für's Überblenden, allerdings auch mit bißchen mehr "Zauber" als nötig.

# wird von BASIC aus mit SYS .start aufgerufen
# der Bildschirmspeicher liegt liegt fix bei $8000 und in $60/$61
# der Pufferspeicher liegt bei $1C00 und in $62/$63

# bei Aufruf werden die Inhalte von Puffer und Bildschirmspeicher ausgetauscht
# dabei werden 21 Zeilen als "Pakete" von 7mal je 3 Zeilen umkopiert
# der Hilfetext sollte also schon im Pufferspeicher drinstehen
# am Einfachsten beschreibt man dazu einmal den Bildschirm und ruft die Routine auf

# Anpassen der Startzeile durch Ändern der Adressen in .init
# in $64 liegt der Faktor 7 und drei Zeilen sind die LDY#$77 ganz am Beginn


.start
JSR init

.loop1
LDY #$77
.loop2
LDA ($60),Y
TAX
LDA ($62),Y
STA ($60),Y
TXA
STA ($62),Y
DEY
BPL loop2

JSR bildspeicherhochzählen
JSR pufferspeicherhochzählen

DEC $64
BPL loop1
RTS
BRK


.init
LDA #$00
STA $60
STA $62
LDA #$80
STA $61
LDA #$1C
STA $63
LDA #$07
STA $64
RTS
BRK


.bildspeicherhochzählen
LDA $60
CLC
ADC #$77
BCC keinübertrag1
INC $61
.keinübertrag1
STA $60
RTS

.pufferspeicherhochzählen
LDA $62
CLC
ADC #$77
BCC keinübertrag2
INC $63
.keinübertrag2
STA $62
RTS

Zitat von CBM_Ba

Ich kapier nicht, wie ich hex (ist es hex?) in normale Zahlen umwandle... also $1C00 =?

Am einfachsten in dem Du den Windows Calculator startest und auf "Programmier" stellst, dann kannst Du die Zahlensysteme umstellen. Oder halt per Website:

https://www.binaryhexconverter.com/hex-to-decimal-converter

https://www.hexadecimaldictionary.com/hexadecimal/0x1C00/

Hier der zweite Link nochmal , damit es gleich klickbar ist.

https://www.hexadecimaldictionary.com/hexadecimal/0x1C00/

Ich benutze für sowas einfach einen normalen Taschenrechner, der so einen Modus hat. Aber auch die Desktop Taschenrechner in Software können das üblicherweise, auch wenn man es manchmal erst "freischalten" muß ( Scientific Mode oder so ).

Ansonsten ist es eigentlich, so, daß man das sich i.a. viel besser einfach als HEX Zahl "denkt". Also gar nicht erst versucht das umzurechnen. Dazu muß man sich mal anschauen, wie das Zahlensystem gedacht ist, aber das ist eigentlich nicht schwierig, es funktioniert ganz normal nur eben mit ein paar mehr Ziffern als üblich.

Wenn man das macht ist man oft auch viel näher an der Einteilung solcher Rechner dran und man kapiert bestimmte Grenzen besser und einfacher.

Zum Beispiel: Der 8Bit Rechner kann 65536 Bytes adressieren. Das sind HEX $10000 bzw. als letzte möglich Adresse die $FFFF . Und wenn man jetzt weiß, das $F für 15 steht ist das also, wegen 0 bis 15, genau 16 hoch 4.

Viel interessanter ist aber, daß die Hälfte von 16 eine 8 ist - und da die ja genauso in HEX als Ziffer benutzt wird, ist als die Hälfte der adressierbaren Adressen bei $8000. DAS ist nun aber eine interessante Sache für Deinen PET, weil Du ja schon von oben die $8000 als Adresse für den Bildschirm kennst. Der Bildschirminhalt wird da also genau auf der Mitte des maximal möglichen RAMs dargestellt.

Sowas merkt sich als $8000 viel (!) einfacher, als der entsprechende Dezimalwert.

Und das geht dann z.B. weiter mit $100 , was quasi die kleinste Einheit ist, die man mit einer 8Bit Zahl durchzählen kann. Nämlich 256. Und wenn man z.B. einen Bildschirm mit 40x25 Zeichen hat, dann sind das ja quasi auch 4x250, und damit weiß man, daß man dafür ungefähr ca. 4x $100 Adressen braucht - nur für die Bildschirmdarstellung.

Wenn man diese $400 Adressbytes irgendwo reservieren will, so daß sie an einem halbwegs sinnvollen Ende liegen, dann kann man z.B. die $2000 als Grenze nehmen, was dann quasi so einen Minimalausbau des Gerätes mit 4KB sind und davon nun ganz einfach 4x $100 zurückrechnen, also $400 von $2000 abziehen.

Und das ist dann erstmal gewöhnungsbedürftig, weil andere Notation, aber da kommen dann heraus :

$2000 - $100 = $1F00 ; nochmal $1F00 - $100 = $1E00 ; nochmal $1E00 - $100 = $1D00 ; und noch ein viertes Mal $1D00 - $100 = $1C00

und siehe da, den Wert solltest Du oben auch schon gesehen haben. Rechnet sich so wesentlich einfacher.

Und ähnliches gilt auch für die Sachen mit den 16 Werten die der Ralph_Ffm da für die Abspeicherroutine benutzt. Das sind dann eben einfach die Zahlen $0 bis $F und davon kann man in einem Byte quasi 2 Stück unterbringen, nämlich eine "vorn" und eine "hinten" ( als high bzw- low Nibble ). Zusammen sind es dann $FF. Das mit Dezimalzahlen auszuschreiben wird dann richtig schwierig.

Zitat von CBM_Ba

WIE zum Henker müsste ich diese Programmbeispiele eintippen/kompilieren/anwenden?

WAS bedeutet beispielsweise "Pufferspeicher liegt bei $1C00?

Nochmal explizit dazu was. Pufferspeicher heißt, daß man da was hineintut an Zahlen. Und der Pufferspeicher muß natürlich genau wie z.B. der Bildschirmspeicher oder der Speicher für das BASIC Programm irgendwo im RAM eine Anfangsadresse haben, und natürlich auch eine Länge bzw. eine Endadresse. Wenn der Puffer bei $1C00 beginnt ist das das, was damit gemeint ist, daß er bei $1C00 liegt. Die Startadresse ist also die $1C00.

Dazu ist dann noch wichtig, wie groß er ist, damit man da nicht was anderes weiter oben reinschreibt. Bei einer Größe von 4x $100 = $400 ist also der Bereich von $1C00 bis $1FFF ( also ein genau Byte vor $2000 ) der gesamte Pufferbereich.

Interessant ist das v.a., weil Dein BASIC Programm ja irgendwo "unten" im Speicher liegt und z.B. bei $800 oder $1000 oder ähnliches beginnt. Das BASIC wird man nicht so einfach ändern können. Aber, wenn Du z.B. 32 KB RAM verbaut hast, dann hättest Du ja RAM von $0000 bis $7FFF ( also ein Byte vor der Hälfte von 64KB, nämlich bei $8000 ). Und dann wäre es z.B. extrem sinnvoll, den Puffer weiter oben zu nutzen. Der könnte dann z.B. bei $7C00 beginnen - und man könnte dann auch sagen, der Puffer "liegt" bei $7C00.

Dem Maschinenprogramm ist sowas i.a. egal, v.a. weil man es ja selbst auch anpaßt. Es hat aber dann den großen Vorteil, daß das BASIC Programm länger sein kann, weil es eben nicht so schnell den kompletten Speicher bis $7C00 gefüllt hat, wogegen die $1C00 schnell mal erreicht ist.

Und: der Puffer kann natürlich auch an jeder beliebigen anderen Stelle beginnen. Etwa bei $4000 oder $6400 oder ...

Das gleiche Thema hast Du auch bei der Abspeicherroutine. Dort versteckt sich das aber ein bißchen. Die letzte Zeile von dem Programm reserviert aber auch einen Pufferspeicher.

Zitat von Ralph_Ffm

Code

:Sicherungsspeicher 
.BYTE    (420x $00)

Der Unterschied ist hier nur, daß die Adresse nicht fix festgelgt ist, sondern eben die 420 Bytes einfach direkt am Ende vom Programm angeschlossen werden.

Und wie gibt man sowas nun ein ??

Normalerweise benutzt man dafür einen Assembler. Das ist ein Prgramm, was Maschinensprachkommandos versteht und zusätzlich aber bestimmte Adressberechnungen automatisch machen kann. Deshlab kann man dann einfach sowas wie :Sicherungsspeicher oder .loop1 da reinschreiben und beim Übersetzen ermittelt der Assembler, an welcher Adresse im Speicher das nun genau ist - und setzt den Wert dann z.B. dort ein wo ein Sprung auf dieses "Label" steht.

Der Vorteil ist, daß man sich beim Programmschreiben noch nicht festlegen muß, wo genau im RAM das Programm mal liegen soll.

Wer es handfester mag, kann das auch mit einem sogenannten "Monitor" eingeben. Natürlich am Besten mit einem der auch Assemblerbefehle versteht. Der Monitor macht ber z.B. diese Adressberechnungen NICHT und man muß dort selber die richtigen Adressen einsetzen.

Du brauchst also für Deinen PET einen a.) Assembler oder b.) Monitor

Welche da gut sind, kann ich mangels PET nicht sagen. Woanders gab es HypraAss oder GigaAssembler oder was auch immer. Die Sachen findet man aber.

Dort tippst Du die Sachen ein und mußt noch eine Startadresse mit vorgeben. Dann wird beim Assemblieren das Programm an genau diese Stelle abgelegt und man kann es dann auch direkt aus dem Speicher heraus abspeichern.

Vielleicht kann ja Jan1980 mal was dazu sagen, was man am PET günstigerweise dafür benutzt,

Ich habe am PET nicht sehr viel in Assembler gemacht. Am C64 selber nutze ich den Turboassembler für kleinere Sachen. Am Atari 800XL den Assembler Editor oder MAC/65. Ansonsten bin ich nach ein paar kleineren Programmen am Endgerät selber dann doch relativ schnell bei Crossassembler gelandet. Für C64 und PET nutze ich CBM-Studio und für den Atari 800XL und das VCS nutze ich WUDSN.

Beim PET hab ich kleine Programme auf Papier geschrieben und diese von Hand assembliert und dann im TIM eingegeben, in HEX versteht sich. Das hat mir viel gebracht und eine ganze Zeitlang konnte ich dann auch gängige opcodes aus dem Kopf. Also zum Lernen ist das eine super Möglichkeit ! Den Tip bekam ich hier im Forum.

Wenn du einen Basic-Loader schreibst, müssen die Data-Zeilen ja dezimal eingegeben werden. Irgendwie mag ich keine Basic-Loader. Aber wenn jemand unbedingt in Basic programmieren will und zeitkritische Routinen braucht, wird man nicht drum rum kommen. Ich könnte mir gut vorstellen, dass man die ganzen hex-Zahlen in eine Excel-Tabelle reinkopieren kann und diese wandelt das dann in dezimal um, dann schreibt man die Werte ab oder kopiert zurück und ergänzt die Kommata. Ausprobiert hab ich das nie.

Nochmal zum Thema. Also wie gesagt, von Hand assemblieren und im TIM eingeben. Oder einen Assembler. Hier im Forum hat doch jemand einen tollen Assembler geschrieben für den PET. Mit was ich noch experimentiert hatte und was in meinem 8032 zB drin ist, ist das Batpro-Toolkit. Das ist eine Basic-Erweiterung, ein Assembler und ein Texteditor. Ich lade es hier mal in den Anhang inkl. Anleitung.

Ich glaube mit dem Monitor und der Basic-Erweiterung kann man bequem DATA Zeilen für einen Basic Loader erzeugen.. Ich hab mir jetzt nicht alles durchgelesen.

EDIT: Das Batpro-Kit wird in ein Eprom geschrieben, also keine "Soft-Software"...

EDIT2: Ich sehe gerade, Batpro 4.8 ist nur für CBM 8032. CBM_BA bräuchte für seinen 4032 aber Batpro 4.0. Mal schauen, ob sich das auch irgendwo findet...

Gruß Jan

Hi Matthias,

stell' Dir einfach vor Du hättest 16 Finger. Dann würdest Du nicht von 1 bis 10 sondern von 1 bis F zählen, wobei die zusätzlichen Finger einfach A bis F heißen würden. Erst wenn der erste Finger ein zweites Mal dran ist hast Du die 11.

Der Vorteil dabei ist, dass Du ein Byte in zwei Hexzahlen wiedergeben kannst: FF = 255

Guckst Du: https://sps-tutorial.com/hexadezimalzahlen/

:)Franky

P.S.: Einen Rechner (den ich seit Jahren einsetze) findest Du hier: https://www.romanblack.com/hexcon.htm

Zitat von Franky

stell' Dir einfach vor Du hättest 16 Finger.

Das finde ich super! ...aber auch irgendwie erschreckend 😅

Zitat von Dekay

Zitat von detlef

Ähm, nein.

Erklär mir wo der Widerspruch ist. Was moderene Computer tun oder nicht spielt ja hier keine Rolle. Kennst Du ein Zahlensystem wo man binäre 8 Bits kürzer und lesbarer darstellen kann?

Du hattest geschrieben, dass Hex verwendet wird, WEIL es platzsparender ist als Dezimal. Das ist nicht korrekt.

Was nicht bedeutet, dass es nicht platzsparender ist.

Und wenn es um's Platzsparen ginge, warum verwendet man dann nicht gleich ein Zahlensystem, das alle Buchstaben nutzt?

Hexzahlen sind einfach sehr praktisch, weil eine Stelle exakt 4 Bits abbildet.

Den 16 Bit Adressraum kann man dadurch mit 4 Hexzahlen darstellen.

Oktal Zahlen haben diesen Vorteil auch (3 Bits pro Stelle), allerdings ist Hex platzsparender in der Darstellung.

Ich persönlich hab durch Hexzahlen eine bessere Vorstellung als mit Dezimalzahlen (bei digitaler Anwendung).