Sinn und Zweck der Schattenregister

Moderator: Rockford

Antworten
patjomki
Beiträge: 230
Registriert: 18.08.2021 23:21
Has thanked: 66 times
Been thanked: 27 times
Kontaktdaten:

Sinn und Zweck der Schattenregister

Beitrag von patjomki »

Hallo,

ich beschäftige mich ja gerade im anderen Thread viewtopic.php?p=4504#p4504 mit der Nutzung des RAM unter dem ROM.

Da ja dazu der VBI ausgeschaltet werden muss (wie man DLI und VBL trotzdem weiterbenutzen kann recherchiere ich gerade) werden nun logischerweise die Schattenregister nicht mehr aktualisiert.

Macht aber nix, nutze ich halt die Hardwareregister.

Und damit komme ich nun zu meiner Frage:

Was ist überhaupt der Sinn und Zweck der Schattenregister?

Ich verstehe, dass ATARIs Ingenieure Transistoren in GTIA, ANTIC und POKEY) sparen wollten und daher einige Adressen mit untschiedlicher Logik für Lesen und Schreiben versehen haben, z.B. die Adresse $d000 bzw. 53248, die schreibend die horizontale Position des Player0 bedeutet und lesend die Kollision von Missile0 mit den Farben des Playfields.

Will ich also die horizontale Position des Player0 wissen, greife ich also auf das Schattenregister zu.

Aber hätte ich das nicht auch selber machen können? So viele nicht lesbare Hardwareregister gibt es jetzt auch nicht und die wenigen, die man dann tatsächlich benötigt, könnte man doch selber in ein frei definiertes Schattenregister retten?

Der Vorteil wäre aber, dass man den derzeit fest definierten Speicherbereich der Schattenregister für eigene Zwecke frei hätte.

Aktuell werden die Schattenregister ja im VBI aktualisiert, findet also synchron zum Bildaufbau statt, aber das hätte man für die wenigen Register ebenfalls selber im VBL tun können, auch wenn das Rechenzeit im VBI kostet. Wenn der ATARI die Schattenregister aber nicht im VBI füllen würde, hätte man da aber auch mehr Zeit für eigene Routinen.

Anderer Fall ist die Abfrage des Feuerknopfes des Joysticks. Wenn man das nur im Schattenregister erfragt bekommt man durch die (späte) Aktualisierung im VBI das Prellen des Feuerknopfes weg (hat @Jac! hier sehr schön erklärt: https://m.youtube.com/watch?v=OCMzYpHSNa8).

Aber sonst?
Also kann mich jemand zum Sinn und Zweck der Schattenregister erhellen?

Benutzeravatar
cas
Beiträge: 813
Registriert: 18.06.2021 21:01
Wohnort: Solar System
Has thanked: 181 times
Been thanked: 362 times
Kontaktdaten:

Re: Sinn und Zweck der Schattenregister

Beitrag von cas »

Wenn Du den Atari "vollständig" übernimmst (also keine ROM/OS/DOS Routinen verwendest und in Assembler programmierst), dann werden die Schattenregister nicht benötigt bzw. der Programmierer hält sich selbst die Schattenregister.

Wenn Du jedoch das OS/ROM oder DOS verwendest, und diese Programme Hardware-Register schreiben, dann möchte man von Programmiersprachen wie Basic/Turbo-Basic, ACTION!, Quick etc die Möglichkeit haben, die aktuellen Werte aus den Schattenregistern zu lesen oder auch über die Schattenregister via VBI Routine zu setzen.

Auch ist bei der Benutzung der Schattenregister zum Setzen von Werten garantiert, das die Änderungen "off-screen", also während des Zeilenrücklauf geschehen, ohne das der Programmierer selbst dafuer sorgen muss.

Benutzeravatar
Kveldulfur
Beiträge: 624
Registriert: 17.08.2021 02:32
Has thanked: 237 times
Been thanked: 163 times
Kontaktdaten:

Re: Sinn und Zweck der Schattenregister

Beitrag von Kveldulfur »

patjomki hat geschrieben:
14.02.2022 10:22
...Was ist überhaupt der Sinn und Zweck der Schattenregister?...
...Aber hätte ich das nicht auch selber machen können?...
Hallo!

Der Sinn des Betriebssystems ist es einen Standard zu definieren und Routinen zum Betrieb bereit zu stellen.
Das erleichtert den Umgang mit dem ATARI.

Nur weil Du weißt, wie Du im VBI selber Schattenregister erzeugen kannst, kann das aber immer noch nicht jeder.
Ausserdem gibt es viele Interpreter-Sprachen, wo dann jede Sprache seine eigenen Schattenregister festlegen müsste?
Jemand der wirklich sich perfekt mit dem ATARI auskennt, kann theoretisch das OS abschalten und dann machen, was er will... aber wer will immer wieder das Rad von vorne erfinden?

Grüße
Janko

Edit: War nicht schnell genug :mrgreen:

patjomki
Beiträge: 230
Registriert: 18.08.2021 23:21
Has thanked: 66 times
Been thanked: 27 times
Kontaktdaten:

Re: Sinn und Zweck der Schattenregister

Beitrag von patjomki »

@cas und @Kveldulfur,

vielen Dank für die Erläuterung. Das ging ja super fix. :D

cas hat geschrieben:
14.02.2022 11:17
Wenn Du jedoch das OS/ROM oder DOS verwendest, und diese Programme Hardware-Register schreiben, dann möchte man von Programmiersprachen wie Basic/Turbo-Basic, ACTION!, Quick etc die Möglichkeit haben, die aktuellen Werte aus den Schattenregistern zu lesen oder auch über die Schattenregister via VBI Routine zu setzen.
Kveldulfur hat geschrieben:
14.02.2022 11:18
Ausserdem gibt es viele Interpreter-Sprachen, wo dann jede Sprache seine eigenen Schattenregister festlegen müsste?
Oh, ja, stimmt. Die Interpretersprachen hatte ich überhaupt nicht mehr auf dem Schirm. Ergibt natürlich Sinn. Danke Euch.

cas hat geschrieben:
14.02.2022 11:17
Wenn Du den Atari "vollständig" übernimmst (also keine ROM/OS/DOS Routinen verwendest und in Assembler programmierst), dann werden die Schattenregister nicht benötigt bzw. der Programmierer hält sich selbst die Schattenregister.
Verrückt. Ich denke so an Assembler, dass für mich was anderes gar nicht mehr gedanklich in Frage kam. ;)

Kveldulfur hat geschrieben:
14.02.2022 11:18
Jemand der wirklich sich perfekt mit dem ATARI auskennt, kann theoretisch das OS abschalten und dann machen, was er will... aber wer will immer wieder das Rad von vorne erfinden?
Da ich ja für die Nutzung des RAM unter dem ROM im Bereich $c000-$cfff und $e000-$ffff das OS eh abschalten muss, und zur Nutzung von DLI und VBI alles nachprogrammieren muss, war ich auf der Suche nach den Dingen, die ich vom OS überhaupt benötige. Dann könnte ich das OS immer abgeschaltet lassen. Spart die ständige Umschalterei (OS aus, Zugriff auf $c000-$cfff bzw. $e000-$fff, OS wieder an) und hat den Vorteil, dass man den Bereich für Programmcode nutzen kann. Natürlich könnte man den erweiterten Speicher ausschließlich für Daten nutzen, aber das ist dann im Prinzip ja nur noch wie eine Art RAM-Disk und spart Nachladerei.
Da Speicher aber knapp ist, würde ich den natürlich gerne für Programmcode nutzen.

Aber Rad neu erfinden muss natürlich auch nicht sein.

cas hat geschrieben:
14.02.2022 11:17
Auch ist bei der Benutzung der Schattenregister zum Setzen von Werten garantiert, das die Änderungen "off-screen", also während des Zeilenrücklauf geschehen, ohne das der Programmierer selbst dafuer sorgen muss.
Stimmt, das ist ein Super-Vorteil der Schattenregister. Nutze ich gerne und müsste man dann halt tatsächlich nachprogrammieren.

Benutzeravatar
Kveldulfur
Beiträge: 624
Registriert: 17.08.2021 02:32
Has thanked: 237 times
Been thanked: 163 times
Kontaktdaten:

Re: Sinn und Zweck der Schattenregister

Beitrag von Kveldulfur »

Hallo!

Hängt auch ein wenig von der eigenen Organisation des Programmes/Spieles ab.

Man könnte Spielfelder bzw. Landschaft hinterm OS legen und bei Bedarf in den Bildschirm umkopieren.
Oder Musik und Soundeffekte werden i.d.R. vom VBI heraus ausgeführt. Also im VBI das OS ausschalten, die aktuelle Note abspielen und wieder OS anschalten.
Die Logik Deines Spiels hat dadurch den konventionellen Speicherbereich fast für sich alleine.

Alles nur Theorie, evtl. schreibt noch ein "echter" Programmierer etwas dazu :D

Grüße
Janko

patjomki
Beiträge: 230
Registriert: 18.08.2021 23:21
Has thanked: 66 times
Been thanked: 27 times
Kontaktdaten:

Re: Sinn und Zweck der Schattenregister

Beitrag von patjomki »

Kveldulfur hat geschrieben:
14.02.2022 12:04
Hängt auch ein wenig von der eigenen Organisation des Programmes/Spieles ab.

Man könnte Spielfelder bzw. Landschaft hinterm OS legen und bei Bedarf in den Bildschirm umkopieren.
Oder Musik und Soundeffekte werden i.d.R. vom VBI heraus ausgeführt. Also im VBI das OS ausschalten, die aktuelle Note abspielen und wieder OS anschalten.
Die Logik Deines Spiels hat dadurch den konventionellen Speicherbereich fast für sich alleine.
Das meinte ich, als ich von einer Art RAM-Disk sprach. Also Level-, Sound-, Playerdaten werden beim Start des Programmes in den Speicherbereich des RAM unter dem ROM geladen und dann bei Benutzung in den für das OS sichtbaren Bereich umkopiert oder aber man schaltet immer vorher aus, macht eine Aktion, schaltet wieder an.

Dann muss man sich aber ohnehin um das DLI- und VBI-Handling kümmern, sonst blieben ja die Ausführung dieser Interrupts während der OS-Ausschaltung stehen.

Benutzeravatar
LarsImNetz
Beiträge: 152
Registriert: 24.08.2021 18:27
Has thanked: 109 times
Been thanked: 80 times
Kontaktdaten:

Re: Sinn und Zweck der Schattenregister

Beitrag von LarsImNetz »

Moin,
dann zeige ich mal, wie man es richtig macht :D. Das RAM unter dem Atari-OS nutzen, ohne das es zu weiteren Problemen kommt.
Schattenregister können weiter genutzt werden. Der VBI macht was er soll, auch DLI läßt sich nutzen.
Selbst das Umschalten geht, um mal das OS zu nutzen.

Ich verwende es aktuell in Oxygene Be und in einem selbst zusammen gefrickelten Editor. Auch das nächste simple Game wird es verwenden, weil es einfach ist.

Der Code für die Interrupts ist aus Turbo-Basic XL extrahiert, wir wollen das Rad ja nicht neu erfinden.

* Speichert euch den Code als eigenständiges simple64k.inc ab, dann includiert es einmalig in eure Sourcen.

* @INIT_SIMPLE_64K initialisiert die Routine. Es stoppt die Interrupts, aktiviert das RAM unter demm OS, setzt die Pointer $FFFA++ auf die eigenen Routinen und reaktiviert die Interrupts wieder. Danach ist das RAM unter dem OS aktiv.
* @ACTIVATE_RAM wie der Name sagt.
* @ACTIVATE_ROM wie der Name sagt, OS nutzbar.

Wenn jetzt eine OS-Routine wir Print-Char genutzt werden soll, muss vorher das ROM aktiviert werden, danach kann das ROM wieder deaktiviert werden.
Alle Schattenregister funktionieren, DLI etc. funktionieren wie gehabt. Will man SETVBV verwenden, muss das OS aktiviert werden, danach OS wieder abschalten.
Das einzige, was sichergestellt werden muss: Die Sourcen des simple64k.inc müssen im normalen RAM liegen. Vorzugsweise nicht im Bereich $4000-$8000, hier liegen bei >64kb Ataris (130XE...) die Blöcke für die RAM-Erweiterungen. Aber ich denke mal, das bekommt ihr hin.

Noch ein Hinweis: Wer die Player-Missile Grafik Jetzt auf die Adresse $F800 legt, muss nur dafür sorge tragen, das die letzten 6 Bytes ab $FFFA++ nicht überschrieben werden. Als Tipp, die ersten 8 Bytes und die letzten 8 Bytes der einzelnen Player werden bei PAL nicht dargestellt, egal was ihr anstellt. Die sind im nicht sichtbaren Bereich. Bei NTSC sind es die ersten und die letzten 16 Bytes. In euren Clear-Methoden müsst ihr das nur berücksichtigen. Sonst stürzt der Atari gnadenlos ab. Auch wenn ihr ins OS springt, wenn dort RAM liegt ist das Nirvana nahe.

Ihr wollt auf einen Tastendruck warten, aber das OS soll aus sein: dann wartet so lange bis CH (764) nicht mehr 255 ist, dann das OS aktivieren, den Key holen und das OS wieder deaktivieren. Ist für Games natürlich ein Nogo eine OS Routine zu nutzen, weil die Routinen einfach zu langsam sind, aber wenn man etwas von der Platte laden möchte, kein Problem. OS aktivieren, laden, OS deaktivieren.

Die Sourcen sind mit dem atasm nutzbar. Wer einen anderen Assembler verwendet, darf das übersetzen und hier bitte die Sourcen für die anderen Anwender posten.

Liebe Grüße aus dem hohen Norden
Lars

Code: Alles auswählen

; -*- text -*-
;
; OXYGENE#2 Simple 64K
;
; Wir bauen den ganzen VBI nach

; THIS FILE WILL INCLUDE BY OTHER FILE
;

 .local

NMIEN=$D40E ; 54286
; 128 = dli
; 64 = vbi

NMIRES=$D40F ; 54287 write
NMIST=$D40F  ; 54287  read

?VDSLST= $200
?VVBLKI= $222
?VIMIRQ= $216 ; Zeigt nach $c030

PORTB=$D301


; Initialisiert das RAM unter dem OS
; 1. Interrupts stoppen,
; 2. RAM unter OS aktivieren
; 3. Alle wichtigen Pointer in diese Routinen verbiegen
; 4. Interrupts wieder aktivieren
;
; einmaliges INC 54017 aktiviert ROM, wenn RAM aktiv war
; einmaliges DEC 54017 aktiviert RAM, wenn ROM aktiv war
;
@INIT_SIMPLE_64K
 SEI                 ; Stop all IRQs
 LDA #0
 STA NMIEN          ; keine Interrupts mehr zulassen

 JSR @ACTIVATE_RAM
 JSR ?SET_POINTER_FFFA

; Start VBI only.
; Solange DLI (VDSLST) nicht gesetzt ist, ist es gefaehrlich, sonst koennte ein DLI im RAM landen.
 LDA #~01000000
 STA NMIEN ; alle Interrupts wieder zulassen
 CLI

 RTS

; lange Routinen, um das RAM einzuschalten
; dafuer klappt es aber immer! Auch wenn RAM schon aktiv ist
@ACTIVATE_RAM
 LDA PORTB
 AND #~11111100
 ORA #~00000010 ; bit 0==0 OS-RAM bit 1==1 BASIC-RAM
 STA PORTB
 RTS


; lange Routinen, um das ROM einzuschalten
; dafuer klappt es aber immer! Auch wenn ROM schon aktiv ist
@ACTIVATE_ROM
 LDA PORTB
 AND #~11111100
 ORA #~00000011 ; bit 0==1 OS-ROM bit 1==1 BASIC-RAM
 STA PORTB
 RTS

; die Zeiger $FFFA,2 ist f?r den NMI (VBI & DLI) Interrupt
; $FFFC f?r Reset
; $FFFE f?r Maskable Interrupts (Tastatur, ...)
?SET_POINTER_FFFA
 LDX #0
?POINTER_LOOP
 LDA ?NEWPOINTER,X
 STA $FFFA,X
 INX
 CPX #6
 BNE ?POINTER_LOOP
 RTS

?NEWPOINTER
 .word ?NEW_NONE_MASKABLE_IRQ ; $c018
 .word 0                      ; ist mir humpe
 .word ?NEW_MASKABLE_IRQ      ; $c02c


; extract from TurboBasic
; Voll cool gemacht, Wenn ein Interrupt auftritt,
; wird einfach das OS-ROM aktiviert und in den Standard OS Interrupt
; gesprungen
;
; None Maskable Interrupt
; Der Maskable Interrupt macht es genauso, OS-ROM aktivieren
; und die Standard OS Routinen anspringen

?RETURN_FROM_OS_IRQ
L24A4    PLA                    ;    24A4: 68
         TAX                    ;    24A5: AA
?RETURN_FROM_OS_MASKABLE_IRQ
L24A6    DEC PORTB ; OS RAM    ;    24A6: CE 01 D3
         PLA                    ;    24A9: 68
         RTI                    ;    24AA: 40
;-------------------------------; -------------------
?NEW_NONE_MASKABLE_IRQ
L24AB    BIT NMIST             ;    24AB: 2C 0F D4
         BPL L24B3              ;    24AE: 10 03
         JMP (?VDSLST)          ;    24B0: 6C 00 02
;-------------------------------; -------------------
L24B3    PHA                    ;    24B3: 48
         TXA                    ;    24B4: 8A
         PHA                    ;    24B5: 48
         LDA #>?RETURN_FROM_OS_IRQ ; 24B6: A9 24
         PHA                    ;    24B8: 48
         LDA #<?RETURN_FROM_OS_IRQ ; 24B9: A9 A4
         PHA                    ;    24BB: 48
         TSX                    ;    24BC: BA
         LDA $0105,X            ;    24BD: BD 05 01
         PHA                    ;    24C0: 48
         CLD                    ;    24C1: D8
         PHA                    ;    24C2: 48
         TXA                    ;    24C3: 8A
         PHA                    ;    24C4: 48
         TYA                    ;    24C5: 98
         PHA                    ;    24C6: 48
         INC PORTB ; OS ROM    ;    24C7: EE 01 D3
         STA NMIRES            ;    24CA: 8D 0F D4
         JMP (?VVBLKI)          ;    24CD: 6C 22 02
;-------------------------------; -------------------
?NEW_MASKABLE_IRQ
L24D0    PHA                    ;    24D0: 48
         LDA #>?RETURN_FROM_OS_MASKABLE_IRQ ; 24D1: A9 24
         PHA                    ;    24D3: 48
         LDA #<?RETURN_FROM_OS_MASKABLE_IRQ ; 24D4: A9 A6
         PHA                    ;    24D6: 48
         PHP                    ;    24D7: 08
         INC PORTB             ;    24D8: EE 01 D3
         JMP (?VIMIRQ)          ;    24DB: 6C 16 02


Online
Benutzeravatar
Dr. Irata
Beiträge: 937
Registriert: 24.08.2021 14:40
Has thanked: 110 times
Been thanked: 268 times
Kontaktdaten:

Re: Sinn und Zweck der Schattenregister

Beitrag von Dr. Irata »

Vielen Dank Lars!
Hier gibt es einfach Leute, die es echt drauf haben... Respekt!
Gruß
Peter

Benutzeravatar
Kveldulfur
Beiträge: 624
Registriert: 17.08.2021 02:32
Has thanked: 237 times
Been thanked: 163 times
Kontaktdaten:

Re: Sinn und Zweck der Schattenregister

Beitrag von Kveldulfur »

LarsImNetz hat geschrieben:
16.02.2022 23:36
...Auch das nächste simple Game wird es verwenden, weil es einfach ist....
Hallo!

Danke für den Code, dass macht es wirklich einfach den RAM unterm ROM zu nutzen.
Für den eigenen VBI bzw. DLI müsste aber der Code immer im konventionellem RAM stehen? Da ein Interrupt automatich den ROM wieder einschaltet?

Ich will auch noch einen kleinen Einspruch erheben. Nur weil es einfach ist, sollte man es nicht automatisch nutzen.
Der ATARI 400 mit 48MB-Erweiterung und der ATARI 800 haben keinen RAM unterm ROM.
Wenn man also auf den RAM unterm ROM verzichten kann, ist es nicht falsch dies zu tun.

Grüße
Janko

Benutzeravatar
LarsImNetz
Beiträge: 152
Registriert: 24.08.2021 18:27
Has thanked: 109 times
Been thanked: 80 times
Kontaktdaten:

Re: Sinn und Zweck der Schattenregister

Beitrag von LarsImNetz »

Hallo Janko,
ja auch der eigene VBI/DLI Code muss im normalen RAM stehen. Auch hier vorzugsweise außerhalb von $4000-$8000. Aber eigentlich sollte das kein Problem sein. Nur der VBI schaltet das OS kurz an und wieder aus. Die Displaylist Interrupts könnten auch im RAM unter dem OS liegen, allerdings sollte man dann darauf achten, das man das OS nur nutzt wenn gerade kein Displaylist Interrupt ausgeführt werden soll. Da die OS Routinen aber alle sehr viel Zeit nutzen, ist das trotzdem keine gute Idee. Also lieber alles, was mit Interrupts zu tun hat, im normalen RAM ablegen.

OK, die 400/800er haben unter dem OS noch nie RAM gehabt. Es gab mal eine Erweiterung um 4kb die bis an die Chips ab $D000 herangeht. Zudem hat Atari die MMU auf den 3. und 4. Joystick-Port gelegt. Schade eigentlich. Deshalb sind diese beiden Rechner auch außen vor. Irgend welche Zöpfe muss man immer abschneiden. Ich weiß nicht, wie es bei den 400/800er mit mehr RAM aussieht also Compy oder Rambo Erweiterungen.
Speicher ist immer ein leidiges Thema, will man mal ein Programm "kleines" schreiben. Gerade beim Speicher bin ich immer wieder dabei zu refaktorisieren.

Nur, um mal ein Beispielchen zu geben:
* Ich nutze gerade Graphics 12, um zusätzlich in den Genuss der 4 Zeilen Graphics 0 für weitere Eingaben zu kommen.
* Die Displaylist ist trotzdem etwas eigenes und liegt irgendwo bei $0572++.
* Ab $b800 kommt ein Zeichensatz, der reicht bis $bba0 dann beginnt der Bildschirmspeicher von Graphics 12. Das sind dann 116 Zeichen.
* Bei $b000 beginnt die Player-Missile Grafik, die unteren 768Bytes nutze ich für einen 2. Zeichensatz. 96 Zeichen.
* Ab $ae00 liegt ein weiterer Zeichensatz (512bytes) für Graphics 1. 64 Zeichen.
* Jetzt bleibt mir noch der Speicher von $1f00 - $Ae00 für das eigene Programm.

Man könnte natürlich die 6144 Bytes von $1f00 - $0700 auch noch überbügeln und selbst nutzen, aber dann hat man keinen Zugriff mehr auf die Diskette. Oder man nutzt die 14kb unter dem OS. Da ist mir der Speicher unter dem OS lieber.

LG
Lars

Benutzeravatar
Mathy
Beiträge: 1134
Registriert: 18.06.2021 11:13
Wohnort: Heerlen, NL
Has thanked: 449 times
Been thanked: 256 times
Kontaktdaten:

Re: Sinn und Zweck der Schattenregister

Beitrag von Mathy »

.
Hallo Lars

LarsImNetz hat geschrieben:
17.02.2022 15:34
Ich weiß nicht, wie es bei den 400/800er mit mehr RAM aussieht also Compy oder Rambo Erweiterungen.
Compyshop und RAMBO benutzen beide $D301. In der 800 werden Axlon-kompatibelen Erweiterunbgen genutzt. Axlon ist auch eine Firma die Nolan Bushnell gegründet hat, wenn Ich mich nicht irre. Sie nutzt $CFFF. Jede Bitkombination schaltet eine andere Bank ein (soweit vorhanden). Und $CFFF wird nur geschrieben, man kann nicht auslesen welche Bank gerade genutzt wird. Dafür sollte man sich selber ein Schattenregister herrichten.

Tschüß

Mathy
Wer oder was hat denn da geblitzt?

Benutzeravatar
cas
Beiträge: 813
Registriert: 18.06.2021 21:01
Wohnort: Solar System
Has thanked: 181 times
Been thanked: 362 times
Kontaktdaten:

Re: Sinn und Zweck der Schattenregister

Beitrag von cas »

The!Card hat 512KB RAM und der sollte auch auf einem Atari 400/800 funktionieren.

Holger Janz hat fuer The!Card Ramdisk-Treiber erstellt: https://github.com/HolgerJanz/RAMCART

Gerade getestet: The!Card ist eine einfache 512kb Speichererweiterung fuer den Atari800. Nur nicht "standard" Atari Bank-Switching $4000-7FFFF, sondern RAM wird im Bereich der Cartridge-Speichers eingeblendet. D.h. Programme müssen diesen Speicher extra unterstützen.

patjomki
Beiträge: 230
Registriert: 18.08.2021 23:21
Has thanked: 66 times
Been thanked: 27 times
Kontaktdaten:

Re: Sinn und Zweck der Schattenregister

Beitrag von patjomki »

LarsImNetz hat geschrieben:
16.02.2022 23:36
Moin,
dann zeige ich mal, wie man es richtig macht :D. Das RAM unter dem Atari-OS nutzen, ohne das es zu weiteren Problemen kommt.
Schattenregister können weiter genutzt werden. Der VBI macht was er soll, auch DLI läßt sich nutzen.
Selbst das Umschalten geht, um mal das OS zu nutzen.
[...]
Das einzige, was sichergestellt werden muss: Die Sourcen des simple64k.inc müssen im normalen RAM liegen. Vorzugsweise nicht im Bereich $4000-$8000, hier liegen bei >64kb Ataris (130XE...) die Blöcke für die RAM-Erweiterungen. Aber ich denke mal, das bekommt ihr hin.
[...]
Liebe Grüße aus dem hohen Norden
Lars
Vielen lieben Dank. Das ist etwas, das ich gesucht habe. RAM unter dem ROM hatte ich schon genutzt, nur mit VBI und DLI wollte ich mich gerade jetzt beschäftigen. Da kommt Dein Quelltext absolut zum richtigen Zeitpunkt. :D

Jetzt fehlt nur noch Quelltext, um die Bankbelegungen aller möglichen Speichererweiterungen im Bereich $4000-$8000 herauszufinden.

130XE-kompatibler Zugriff auf die 16KB-Blöcke des zusätzlichen Speichers ist ja mit Bit 2 und 3 von PortB standardisiert und sollte, wenn man den im 130XE möglichen getrenntem Zugriff von ANTIC und CPU nicht benutzt, sowohl mit CompyShop- als auch RAMBO-Erweiterungen immer funktionieren.
Aber der Speicher über 128KB hinaus wird ja von gefühlt jeder Erweiterung irgendwie anders gehandhabt (also die Interpretation der Bits von PortB) und es wäre ja schön, wenn ein Programm die Ankopplung mit den weiteren Bits von PortB irgendwie eigenständig herausfinden könnte.

Benutzeravatar
JAC!
Beiträge: 119
Registriert: 18.06.2021 23:13
Has thanked: 66 times
Been thanked: 101 times
Kontaktdaten:

Re: Sinn und Zweck der Schattenregister

Beitrag von JAC! »

Hallo,

oben wurde es im Prinzip schon gesagt, aber man kann das RAM unter dem ROM nutzen und trotzdem VBI&DLIs verwenden.
Das macht z.B. Turbobasic. Die Interrupt Vektoren bei $FFFA..$FFFF im RAM zeigen dort auf einen kleine Routine im unteren RAM.
Diese schaltet das ROM wieder ein (INC $D301), spring auf die Standardvektoren und schaltet das ROM bei der Rückkehr wieder aus (DEC $D301).

Viele Grüße, Peter.
ROMRAM.png
Visit https://www.wudsn.com the home of WUDSN IDE.

Antworten

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 1 Gast