Antic 14

[Dr. Irata]

Hallo,
mal eine echt blöde Frage:
Ich will eine Displaylist machen mit Antic 14 - also 4 Farben und volle Auflösung und hänge gerade an dieser 4K Grenze.
Wenn jemand hier mal "kurz" mir eine passende DL posten kann, wäre ich höchst erfreut - ansonsten müsste ich es mir mühsam herleiten!
Vielen Dank schon mal,
Liebe Grüße
Peter

[Kveldulfur]

Hallo!

Eine Zeile hat 40 Bytes, wobei man 192 Zeilen hat.
So hat man gesamt 7680 Bytes.

Die 4k Grenze liegt bei 4096 Bytes

Also bekommt man 102 Zeilen in die eine Hälfte und 90 Zeilen in die andere Hälfte, der 4k Grenze.

102*40 = 4080
90*40 = 3600

Nun soll der Bildschirmspeicher nach $A000 bis $BFFF, das bedeutet,
man lässt den Bildschirmspeicher bei

$A010 beginnen, damit dieser nahtlos bis nach $BE10 geht.

...
$4E,$10,$A0 = Speicherbereich 1
101 x $0E
$4E,$00,$B0 = Speicherbereich 2
89 x $0E
...

Grüße
Janko

[atarixle]

Ich habe mich kürzlich auch mit der Displaylist beschäftigt und hier Fragen gepostet.

Willst du quasi Graphics 15 auf einem 800er einstellen? Nimm Graphics 8 und ändere die bereitsvorhandene Displaylist ab.

Ansonsten kann man hier keine DL posten, da sich die 4k-Grenze je nach Startadresse des Bildschirmspeichers woanders im Bild befinden wird. Selbst die Startadresse des Bildschirmspeichers muss an der 4k-Grenze ausgerichtet werden, wenn der Bildschirmspeicher linear bleiben soll.

Ich selbst habe die 4k-Grenze in Mitten eines Bildes mit 32 Bytes / Zeile gehabt und (in dem Fall besonders) einfach die Start-Adresse an die nächste 32 Byte-Grenze verschoben, denn eine 4k-Grenze ist gleichzeitig eine 32 Byte-Grenze.

[Olix]

Eine Zeile hat 40 Bytes, wobei man 192 Zeilen hat.
So hat man gesamt 7680 Bytes.

Die 4k Grenze liegt bei 4096 Bytes

...

Achtung! Diese Rechnung funktioniert natürlich nur, wenn man mit seinem Bildspeicherbereich auf einer 4K Grenze beginnt, also $1000, $2000, $3000 ...
Wenn ich mit meinem Bildspeicher z.B. bei $A800 beginne liegt die 4K Grenze bereits nach 2048 Byte

Oder ganz extrem, mein Bildschirmbereich beginnt bei $AFFF wird es ganz blöde, denn ich habe bereits nach einem Byte eine 4K Grenze überschritten.
Es ist also immer am einfachsten, wenn man mit seinem Bildspeicher auch bei einer 4K Grenze beginnt.

Das Problem mit der 4K Grenze kommt übrigens daher, dass ANTIC die oberen 4 Bits des Memory Scan Counters nur bei einem LMS-Befehl neu einliest.


Und es gibt zum Thema Displaylist noch eine Speichergrenze zu beachten:

Die Display List selbst darf eine 1K-Grenze nicht überschreiten. (Siehe Atari Powerbuch Seite 88/89)
Andernfalls muß eine JMP-Anweisung genau vor dieser 1K-Grenze platziert werden. Der Operand ist dann die Adresse des ersten Bytes auf der anderen Seite der 1K-Grenze.

1K Grenzen sind: $0400, $0800, $0C00, $1000 usw.

Dies ist besonders relevant wenn die Displaylist selbst wieder an einer blöden Stelle beginnt, also auch hier am besten an einer 1K Grenze die DL platzieren. Ich musste das lernen, als ich in einem meiner ersten Assemblerversuchen die Displaylist einfach direkt an den Programmcode abgelegt hatte, ohne den Speicherbereich fest zu definieren.

Auch hier liegt das Problem beim ANTIC, da der Display-List-Counter (also quasi der Programmzähler des ANTIC) die oberen 6 Bits nur bei einem Sprungbefehl neu einliest. ($01, $81, $41 oder $C1)


Falls gewünscht kann ich das Thema nochmal etwas ausführlicher (hoffentlich verständlicher) mit Beispielen aufgreifen....

[Erhard]

Hi,

Achtung! Diese Rechnung funktioniert natürlich nur, wenn man mit seinem Bildspeicherbereich auf einer 4K Grenze beginnt, also $1000, $2000, $3000 ...

also bislang hatte ich auch nur gehört / gelesen, daß eine 4k-Grenze nicht überschritten werden darf.

Von daher fand ich Kvedulfur's Rechnung und Vorgehensweise einleuchtend:

- man suche sich für sein Proggi einen Bereich aus, wo man den Bildschirmspeicher ungefähr hinpacken will und dann geht man vom nächsten $x000 nach unten 4080 Bytes und nach oben 3600 Bytes.

Wenn man dagegen mit dem Bildschirmspeicher bei $X000 beginnen würde kommt man doch sicher an eine Stelle, wo man nach $(x+1)000 springen muß und hat dann davor schlecht nutzbares RAM, oder?

CU, Erhard

[Olix]

Von daher fand ich Kvedulfur's Rechnung und Vorgehensweise einleuchtend:
- man suche sich für sein Proggi einen Bereich aus, wo man den Bildschirmspeicher ungefähr hinpacken will und dann geht man vom nächsten $x000 nach unten 4080 Bytes und nach oben 3600 Bytes.

... ja da hast Du natürlich vollkommen recht. Hab mich nicht gut ausgedrückt.

Was ich sagen wollte ist, dass die 4K Grenze nicht automatisch 4096 Bytes nach der Anfangsadresse kommt, dies wäre eben nur der Fall, wenn diese auch bei einer 4K Grenze beginnt.
Ich wollte nur auch darauf hinweisen, dass man den Start des Bildspeichers mit Bedacht setzen soll ... da ist Kvedulfur's Rechnung und Vorgehensweise natürlich absolut richtig.

[Dr. Irata]

... lieben Dank für die schnellen Antworten.
Da mein Bildschirm bei 4096 eh anfängt, passt die Lösung von Janko perfekt!

Allerdings muss man die Werte umtauschen:

Code: Alles auswählen

dlist		.by 117,117,117
		.by $4e,$a0,$10
:101		.by $0e
		.by $4e,$b0,$00
:89		.by $0e
		.by $41
		.word dlist

[Olix]

Hier mal noch ein Beispiel für eine Displaylist (OS Gr. 8+16)

Code: Alles auswählen

  8036: x3   blank 8
  8039:      mode F @ 8150
  803C: x93  mode F
  8099:      mode F @ 9000
  809C: x97  mode F
  80FD:      waitvbl 8036

Bildspeicher beginnt bei $8150
die ersten 94 Modelines gehen also genau bis $8FFF (40 Byte pro Zeile * 94)
... da die nächste Adresse auf eine 4K Grenze fällt wird die nächste Zeile mit einem neuen Ladebefehl (LMS) ausgeführt mit der Adresse $9000

[Kveldulfur]

Allerdings muss man die Werte umtauschen:

Code: Alles auswählen

.by $4e,$a0,$10

Die Reihenfolge müsste aber LOW, HIGH sein und somit $10, $a0 ?
Wo habe ich jetzt den Denkfehler?

Grüße
Janko

[Kveldulfur]

Hallo!

Vielleicht passt das hier dazu, ich würde gerne einmal über meine Erfarung mit der Speicheraufteilung des ATARI berichten:

1k- und 4k-Grenzen des Antic:
So darf eine Displaylist nicht die 1k-Grenze überschreiten und Bildschirmspeicher nicht die 4k-Grenze.
PMG muss ebenfalls an eine 4k-Grenze ausgerichtet sein und der Zeichensatz unterliegt wiederum der 1k-Grenze.

$C000, bzw. 48kB-Grenze:
Sollte man den Bereich unterm ROM ab $C000 nutzen, ist ein Spiel nicht mehr kompatibel zum ATARI 800.

$4000, bzw. 16kB-Grenze:
Diese Grenze ist mehrfach interessant, so kann ein ATARI 400, bzw. ein ATARI 600XL mit 16kB ein Programm, das den RAM! oberhalb $4000 benötigt, nicht ausführen.
Sollte man ein Cartridge erstellen wollen, sollte man versuchen den RAM für Variabeln, Bildspeicher usw. bis max. $3FFF nutzen, weil dann das Cartridge auch auf den 16kB-Rechnern läuft.
Möchte man sein Spiel auf den ATARI 5200 portieren, so darf man ebenfalls max. den RAM für Variabeln, Bildspeicher usw. bis $3FFF nutzen, da der A5200 nur 16kB RAM hat und danach bereits das Cartridge beginnt.
Der Programmcode >$4000 sollte sich, wie in einem ROM, nicht überschreiben.

$2000 DOS-Grenze bzw. 8kB-Grenze:
Benötigt man das DOS, sollte man den Bereich unterhalb $2000 während des Ladevorgangs nicht überschreiben. Wenn man die DOS-Routinen nach dem Ladevorgang nicht mehr benötigt, kann man hier nach dem Ladevorgang Variablen usw. ablegen.

Wenn man kein Basic nutzt, muss man nicht den Bildschirmspeicher hinten (oben) im RAM haben, sondern kann sich das ganze recht einfach nach vorne holen:
$2000 = PMG-Grafik ($2300 bis $27FF)
$2000 bis $22FF z.B. für ein Zeichensatz für Gr. 1 oder Gr. 2, da dort nur die ersten 64 Zeichen genutzt werden.
Ab $2800 Zeichensätze, Bildspeicher usw... Erst im Anschluss der Programmcode.

Grüße
Janko

[patjomki]

Hallo!

Vielleicht passt das hier dazu, ich würde gerne einmal über meine Erfahrung mit der Speicheraufteilung des ATARI berichten:

Vielen Dank erstmal für Deinen Beitrag.

Da hänge ich mich mal dran und poste auch mal die Erkenntnisse, die ich so über die Jahre (für mind. 64KB XL/XEs, bei den 600XL fehlt natürlich der Speicher oberhalb 16KB) gesammelt habe. Wäre gut, wenn jemand mit einem kritischen Auge mal drüberschauen könnte, um nachzusehen, ob alles verständlich (und richtig) wiedergegeben ist.

Im oberen Teil ist zum Vergleich auch mal die Speicheraufteilung des C64 angegeben, weil Weekendsoft eben für C64 und ATARI-8-Bit programmiert.

Code: Alles auswählen

; Memory Map C64 (nur Kurzfassung):
; ===============
; $0000-$03ff     0-1023  belegt 1K         Zeropage, Stack, Systemvariablen 
; $0400-$07ff  1024-2047  belegt 1K         Bildschirmspeicher ($400-$7e7), frei($7e8-$7f7), Spritepointer ($7f8-$7ff)
; $0800-$9fff  2048-40959 frei   38K        RAM
; $a000-$bfff 40960-49151 frei   8K         Basic
; $c000-$cfff 49152-53247 frei   4K         RAM
; $d000-$dfff 53248-57343 (frei) 4K         OS (Zeichensatz, Hardwareregister Custom Chips (SID etc.) (frei nur über $1, schwierig)
; e0000-$ffff 57344-65535 (frei) 8K         OS (frei nur über $1, Interrupts schwierig)

; Memory Map ATARI (Kurzfassung - erweiterte Memory Map siehe unten):
; =====================================================
; $0000-$05ff     0- 1535 belegt 1,5K       Zeropage, Stack, Systemvariablen
; $0600-$06ff  1536- 1791 frei   256 Bytes  Page 6 (Aber Achtung! Tapespeeder etc.)
; $0700-$0fff  1792- 4095 belegt 2,25K      DOS (LiteDOS)
; $1000-$1fff  4096- 8191 frei   4K         DOS (frei nur mit LiteDOS, sonst meist belegt durch DOS)	
; $2000-$9fff  8192-40959 frei   32K        RAM ($4000-$7fff, 16K-Block für Bankswitching RAM wie im 130XE)
; $a000-$bfff 40960-49151 frei   8K         Basic (kann zur freien Nutzung ausgeschaltet werden)
; $c000-$cfff 49152-53247 (frei) 4K         OS (frei nur mit OS aus, Interrupts und Schattenregister schwierig)
; $d000-$d7ff 53248-55295 belegt 2K         Hardwareregister Customchips (GTIA, ANTIC, POKEY)
; $d800-$dfff 55296-57343 (frei) 2K         OS (Fließkomma, Parallelbus, nur mit OS aus, siehe oben)
; e0000-$ffff 57344-65535 (frei) 8K         OS (frei nur mit OS aus, Interrupts und Schattenregister schwierig)

; Memory Map ATARI (erweitert):
; =============================
; $0000-$007f belegt Zeropage OS
; $0080-$00ff frei   Zeropage Platz für User
; $0100-$01ff belegt Stack
; $0200-$02ff belegt OS Vectors, Register
; $0300-$03ff belegt OS Vectors
; $0400-$047f belegt OS Puffer 
; $0480-$05ff frei
; $0600-$06ff frei   Page 6 (Object Code in Basic, Tape-Speeder etc.)
; $0700-$0fff belegt LiteDOS
; $0700-$1fff belegt DOS
; $2000-$9fff frei   RAM 
; 	$4000-$7fff  16K-Block für Bankswitching RAM wie im 130XE, 4 Blöcke
;	$5000-$57ff  Selbsttest, standardmäßig AUS
; $a000-$bfff frei   Basic, Standardmäßig AN (kann zur freien Nutzung ausgeschaltet werden)
;    ab	$bc00		Standardscreen (Displaylist)
; $c000-$cfff (frei) OS (frei nur mit "Bankswitching")
;    $cc00-$cfff         OS Internationaler Zeichensatz
; $d000-$d0ff belegt GTIA
; $d100-$d1ff belegt PBI
; $d200-$d2ff belegt POKEY, genau genommen jedoch nur $d200-$d20f, die Adressen $d210-$d2ff sind immer in 16er-Blöcken die ersten sechszehn gespiegelt
;					 für STEREO-, QUAD-Pokey etc. liegt dann der zweite Pokey auf $d210-$d21f, der dritte auf $d220-$d22f etc. Theoretisch maximal 
;					 sind so also 16 Pokeys möglich
; $d300-$d3ff belegt PIA (Joysticks, MMU), genau genommen jedoch nur $d300 - $d303, die Adressen $d304-$d3ff sind immer die ersten vier gespiegelt (in Viererblöcken) 
;					 Crux: die Ultimate1MB-Speichererweiterung nutzt davon die Bereiche $d380-$d3ff, dies führt zu Inkompatibilitäten 
;					 (z.B. mit den Programmen vom User xxl)
; $d400-$d4ff belegt ANTIC
; $d500-$d5ff belegt Modulport (R/W), z.B. für SID-Cartridges im ROM-Port, 
;			wie SlightSID ($d500-$d51f 1.SID und $d520-$d53f 2. SID), SIDari ($d500-$d51f nur 1 SID)
; $d600-$d7ff belegt reserviert (VBXE, SIDE etc.)
; $d800-$dfff (frei) OS (Fließkomma, Parallelbus, frei nur mit OS aus)
; $e000-$ffff (frei) OS (frei nur mit OS aus)
;    $e000-$e3ff         OS Zeichensatz ATASCII

[LarsImNetz]

Mein Senf noch dazu:
PMG Graphics benötigt eine 2k Grenze und nicht 4k (In hoher Auflösung)
PMG Graphics benötigt 1k Grenze in niedriger Auflösung.
(Siehe Original Profibuch S. 84 unter PMBASE)

Fonts haben eine 512Bytes Grenze für Graphics 1&2
(Profibuch zu CHBASE)

BTW: Vernünftige Assember bieten einen Align Befehl.

Atasm z.B. ".align 1024" damit wird der Speicher ab dieser Position "Begradigt"
MADS dito. ".align 1024"

So kann man einfach hinter seinem Programm Code die Displaylist beginnen lassen und danach auch noch die Grafik.

Noch etwas fieses, der Original 130XE kann Speicher so schalten das der Antic bei $4000 Graphics Daten ausließt (Bankgeswitcht) und die CPU den selben Speicher als Programm Speicher nutzen kann. Das geht auf den meisten Fremderweiterungen leider nicht, also mein Tipp, Finger weg davon.

LG
Lars

[DjayBee]

Noch etwas fieses, der Original 130XE kann Speicher so schalten das der Antic bei $4000 Graphics Daten ausließt (Bankgeswitcht) und die CPU den selben Speicher als Programm Speicher nutzen kann. Das geht auf den meisten Fremderweiterungen leider nicht, also mein Tipp, Finger weg davon.

Um in Produkten zu sprechen: CompyShop kann's, Rambo kann's nicht.

[CharlieChaplin]

Noch etwas fieses, der Original 130XE kann Speicher so schalten das der Antic bei $4000 Graphics Daten ausließt (Bankgeswitcht) und die CPU den selben Speicher als Programm Speicher nutzen kann. Das geht auf den meisten Fremderweiterungen leider nicht, also mein Tipp, Finger weg davon.

Um in Produkten zu sprechen: CompyShop kann's, Rambo kann's nicht.

Und einige werden denken: Compyshop-kompatible Ramerweiterungen können den sep. Antic Zugriff, Rambo-kompatible Erweiterungen können das nicht.

Problem: Nicht alle Compyshop-kompatible Erweiterungen beherrschen den sep. Antic Zugriff von Haus aus, z.B. sind die Megaram 1, 2 und 3 Erweiterungen zwar Compyshop-kompatibel (nutzen auch die gleichen Bänke), jedoch scheint hier der sep. Zugriff nicht standardmäßig implementiert zu sein (bei meinen Megaram 1, 2 und 3 Erweiterungen mit 256k XRAM lief Video-Blitz damals nicht, jedenfalls war von der Animation nichts zu sehen). Scheinbar muss da noch irgendwas "nachgerüstet" werden (oder ein Kabel irgendwo verlötet werden) damit es klappt...?!? Die Anzahl der Programme, die sep. Antic Zugriff nutzen ist zwar inzwischen auf ca. 10 Programme gestiegen, doch viel ist das nach knapp 40 Jahren des 130XE Standards (1985) ja immer noch nicht.

Und komplett lötfreie (plug & play) PBI-Ramerweiterungen können leider auch keinen sep. Antic Zugriff, dafür müsste man dann doch wieder ein oder mehrere Kabel verlöten.

[Dinadan]

Also am besten Lars Tipp befolgen und bei Neuentwicklungen die Finger vom separaten Antic-Zugriff lassen. Die Zielgruppe ist zu klein.

[GoodByteXL]

Und einige werden denken: Compyshop-kompatible Ramerweiterungen können den sep. Antic Zugriff, Rambo-kompatible Erweiterungen können das nicht.

Problem: Nicht alle Compyshop-kompatible Erweiterungen beherrschen den sep. Antic Zugriff von Haus aus, z.B. sind die Megaram 1, 2 und 3 Erweiterungen zwar Compyshop-kompatibel (nutzen auch die gleichen Bänke), jedoch scheint hier der sep. Zugriff nicht standardmäßig implementiert zu sein ...

Bleibt die Frage offen, wie CS-kompatibel definiert ist. Wenn nur die gleichen Bänke verwendet werden, reicht das nicht aus. Aber eine 'vollwertig CS-kompatible' sollte das beherrschen. Wer z.B. mit BASIC XE programmiert, freut sich darüber. Auch Demo-Freunde kommen da durchaus auf ihre Kosten, denn so manche Demo flickerte mangels der Funktion.

Was die Zielgruppe angeht: Die ist im Zeitalter von Altirra und Co. vmtl. sehr viel größer geworden.

Meine originale 256K-CS-Erweiterung läuft jetzt seit ewigen Zeiten in meinem 800XL, in einem 130XE habe ich eine voll CS-kompatible 256K-Erweiterung. Man kann damit schöne Effekte erreichen und, wenn man will, kann man Schmankerl in die eigene Software einbauen, die nach erfolgreichem Austesten auf das Vorhandensein einer voll CS-kompatiblen Erweiterung quasi Ostereier zeigt.

[patjomki]

Also am besten Lars Tipp befolgen und bei Neuentwicklungen die Finger vom separaten Antic-Zugriff lassen. Die Zielgruppe ist zu klein.

Hmm, komme mir gerade ein bisschen so vor, als wäre ich in einer Zeitschleife gefangen.

Puristen oder Erweiterungen?
Wo fängt man an, wo hört man auf? Was ist der Standard?
CTIA oder GTIA?
PAL/NTSC?
16K/48K/64K/128K oder sogar noch mehr?
1/2/4 POKEYS?
Covox?
VBXE? Sophia?
SID? (PokeyMax, SIDari etc.)
usw.

Das ist schon in den 80ern einer der Nachteile unserer 8-Bitter gegenüber dem C64 gewesen. Es gab und gibt keinen Standard. Beim C64 hat es erst so richtig mit dem C128 angefangen, strubbelig zu werden, so Kleinigkeiten wie verschiedene SIDs sind eher zu vernachlässigen, vorher war (bis auf PAL/NTSC) klar: ein C64 ist ein C64. 64,5K, ein SID, 8 Sprites, 16 Farben.

Um aus der Zeitschleife auszubrechen finde ich daher, dass es als Programmierer besser ist, zu wissen, dass es diese verschiedenen Konfigurationen auf den ATARIs gibt und wenn man das Feature benötigt, halt eine Fehlermeldung auszugeben, wenn das Feature fehlt.

Ohne Not würde ich separaten ANTIC/CPU-Zugriff jetzt auch nicht verwenden, aber das Feature hat schon was.

[Dr. Irata]

... was genau macht denn der separate Zugriff des ANTIC auf die CPU?
Was kann man damit besonderes machen und wie???
Neugierde pur!!!!!

[Mathy]

.
Hallo Peter

... was genau macht denn der separate Zugriff des ANTIC auf die CPU?

Es geht um den separaten Zugriff von ANTIC und CPU auf die extra Speicherbänke. Man kann nur ANTIC, nur CPU, beide oder keiner von beiden Zugang zum Speicher oberhalb von 64kB geben. Wer keinen Zugang bekommt, kann nur auf die unteren 64kB zugreifen.

Tschüß

Mathy

PS was man damit genau machen kann, kann ich dir leider nicht sagen.

[Mathy]

.
Hallo Patjomki

Das ist schon in den 80ern einer der Nachteile unserer 8-Bitter gegenüber dem C64 gewesen. Es gab und gibt keinen Standard. Beim C64 hat es erst so richtig mit dem C128 angefangen, strubbelig zu werden, so Kleinigkeiten wie verschiedene SIDs sind eher zu vernachlässigen, vorher war (bis auf PAL/NTSC) klar: ein C64 ist ein C64. 64,5K, ein SID, 8 Sprites, 16 Farben.

Dafür gab's dann beim Lionel Richie Computer den PET, den VIC20, den C64, den C16 und den Plus/4.

Tschüß

Mathy

[cas]

PS was man damit genau machen kann, kann ich dir leider nicht sagen.

Man kann damit einen oder mehrere Bildschirmspeicher (bei gr. 8 immerhin 8K) in das erweiterte RAM legen und hat den Speicher trotzdem für Programmcode zur Verfügung. Man kann den Kuchen also essen und trotzdem behalten :)

D.H. im Bereich $4000-7FFFF "sieht" die CPU 6502 Programmcode, der ANTIC "sieht" in diesem Bereich (via Display-List) aber Bildschirmspeicher.

Wenn man Grafikdaten in die Banks der Speichererweiterung legt, kann man damit 16KB schnell (als Bildschirmspeicher des ANTIC) umschalten. Wenn man ultra-schnelle Grafikumschaltung (Page-Flipping) braucht ist das ideal. Man füllt den Speicher "in Ruhe" mit der CPU, um ihn danach blitzschnell in den Adress-Raum des ANTIC einzublenden. Die CPU kann dann die nächste Speicherseite berechnen und füllen.

Ist schon toll, funktioniert aber nur bei original Atari 130XE und kompatiblen (wie CS) Speichererweiterungen.

[Dr. Irata]

...ich kann also meinen 8kB Bildschirmspeicher z.B. in Bank 4 packen .... muss dann aber bei jeder Bildschirmaktion wo Daten vom Bildschirmspeicher in den sichtbaren Bildschirm geladen werden entsprechend das Bankswitching vornehmen... was natürlich etwas Zeit kostet?!

[cas]

...ich kann also meinen 8kB Bildschirmspeicher z.B. in Bank 4 packen .... muss dann aber bei jeder Bildschirmaktion wo Daten vom Bildschirmspeicher in den sichtbaren Bildschirm geladen werden entsprechend das Bankswitching vornehmen... was natürlich etwas Zeit kostet?!

Das Bankswitching ist ja nur Schreiben einer Speicherstelle, das geht schnell. Das sollte man mit dem Bildschirmaufbau synchronisieren, so das es nicht in der Mitte des Bildschirms passiert.

Beispiel ohne Page-Flipping:

Keine Bildschirm-Updates notwendig:

* ANTIC -> sieht in 4000-7FFF BANK 4
* CPU -> sieht in 4000-7FFF Code

Bildschirm-Update:
* CPU Zugriff auf extra RAM einschalten (LDA/STA)
* ANTIC -> sieht in 4000-7FFF BANK 4
* CPU -> sieht in 4000-7FFF BANK 4
* Bildschirm-Inhalte anpassen (Code hierfuer muss ausserhalb von 4000-7FFF liegen)
* CPU Zugriff auf Basis-RAM einschalten (LDA/STA)

Beispiel mit Page-Flipping:

* ANTIC -> sieht in 4000-7FFF BANK 4 mit Grafikdaten (Grafik-Page 1)
* CPU -> sieht in 4000-7FFF Basis-RAM mit Grafikdaten (Grafik-Page 2)
* CPU beschreibt neue Grafikdaten in 4000-7FFF (werden von ANTIC nicht gesehen, kein Sync notwendig)
* Wenn CPU "fertig" mit den Grafikdaten, MMU Umschalten (ein LDA/STA)
* ANTIC -> sieht in 4000-7FFF Basis-RAM (Grafik Page 2)
* CPU -> sieht in 4000-7FFF BANK 4 (oder 1/2/3)
* CPU schreibt neue Grafik-Daten in 4000-7FFF
* Wenn CPU "fertig" mit den Grafikdaten, MMU Umschalten (ein LDA/STA)
* repeat ...

[cas]

Der ANTIC kann via Display-List durch die 16K einer RAM-Bank "scrollen" und so 16K Bildschirm-Daten anzeigen.

Die CPU hat 64KB "frei" (minus ROM und IO), der Atari 130 XE kann somit 80 KB (64+16KB) "gleichzeitig" adressieren.

[patjomki]

...ich kann also meinen 8kB Bildschirmspeicher z.B. in Bank 4 packen .... muss dann aber bei jeder Bildschirmaktion wo Daten vom Bildschirmspeicher in den sichtbaren Bildschirm geladen werden entsprechend das Bankswitching vornehmen... was natürlich etwas Zeit kostet?!

Hier gibt es auch noch Infos dazu.

https://abbuc.de/mitglieder/software-re ... es-130-xe/

Besonders spannend ist das, was im letzen Satz steht
"z.B. wählt POKE 5401 7,255 die erste Bank (Bank 0) aus und läßt den 6502 Prozessor darauf zugreifen, wobei der ANTIC Video Chip nach wie vor mit dem normalen Speicherbereich arbeitet (Modus 2)."

Die Bänke sind ja 16K groß. Beim Umschalten "verlierst" Du also die 16K, um sie durch andere 16K zu ersetzen. Im Mischmodus aber nicht. Da kannst Du z.B. sagen, dass nur der ANTIC auf diese Bank zugreifen soll, Dein Programmcode bleibt in der ursprünglichen Bank (Du verlierst also nix) und Du kannst trotzdem nach Herzenslust dem Antic sagen, wo er seine Daten in $4000-$7fff finden kann obwohl Dein Programmcode ja eigentlich dort liegt. Hoffe, ich konnte es halbwegs verständlich machen, bei meinem Beispiel liegen halt Antic-Daten in der RAM-Bank, im oben zitierten Beispiel ist es genau umgekehrt.

[patjomki]

Die CPU hat 64KB "frei" (minus ROM und IO), der Atari 130 XE kann somit 80 KB (64+16KB) "gleichzeitig" adressieren.

Und ich schreibe mir 'nen Wolf.

Mit wenigen Worten perfekt ausgedrückt, wofür ich 'nen Roman geschrieben habe. @cas: Hut ab.

[patjomki]

Dafür gab's dann beim Lionel Richie Computer den PET, den VIC20, den C64, den C16 und den Plus/4

Die, so verrückt es erstmal klingt, den Vorteil hatten alle inkompatibel zueinander zu sein. Den "Fehler" Abwärtskompatibilität haben sie erst beim C128 nachgeholt.

Aber bitte nicht falsch verstehen, ich liebe meine ATARIs seit 40 Jahren, finde die 70er-Jahre-Architektur(!) des Systems extrem elegant und habe noch nie einen C64 besessen. Dafür ist der Freund bei Weekend-Soft da, kenne aber dadurch auch beide Plattformen recht gut, da ich den C64 des Freundes trotzdem schon (bereits in den 80ern) programmiert habe.

Der echte Vorteil der einheitlichen Plattform konnte sich auch erst später richtig entfalten, als Millionen C64 verkauft waren. Zu Beginn war das Rennen noch recht ausgeglichen und ATARI hatte auch keine große Wahl, gab es von den 400/800 doch schon ein, zwei Milliönchen. Da konnte man die Userbasis nicht verprellen, zumal (s. oben) die Hardwarestruktur (mit POKEY, ANTIC etc.) auch noch so gut war, dass man sie ohne Not nicht wegwerfen sollte.

[Dr. Irata]

... das ist ja cool und praktisch!
Also brauche ich im Mischmodus gar nicht umschalten...

[Mathy]

.
Hallo Patjomki

Das ist aber auch der Nachteil der unterschiedlichen Cs. Die 8 Bit Ataris sind wenigstens zu 90% gleich und die letzten 10% kann man meistens per Software erkennen.

Tschüß

Mathy

[patjomki]

Die Anzahl der Programme, die sep. Antic Zugriff nutzen ist zwar inzwischen auf ca. 10 Programme gestiegen, doch viel ist das nach knapp 40 Jahren des 130XE Standards (1985) ja immer noch nicht.

Du hast ja meistens Listen für sowas. Welche Programme sind es denn?

[patjomki]

Das ist aber auch der Nachteil der unterschiedlichen Cs. Die 8 Bit Ataris sind wenigstens zu 90% gleich und die letzten 10% kann man meistens per Software erkennen.

Stimmt. Heute hat sich der Nachteil auf Userseite relativiert. Die PETs, VC20 etc. sind heute wirklich so gut wie nicht mehr im Einsatz. Ab und zu kommt mal ein beeindruckendes Programm für einen Plus/4 raus, der Rest spielt sich in der C= Retroszene - wie damals auch - weitestgehend auf dem 64er ab.

Da haben es die ATARI-User tatsächlich einfacher, die selbst mit einem 48K 400/800er noch einige Programme nutzen können.

Wo es halt schwierig ist, "neuen" Programmierern (da gibt es tatsächlich viele von, die gerne mal auch die ATARIs kennenlernen wollen) begreiflich zu machen, dass man verschiedene Konfigurationen berücksichtigen sollte bzw. wie man hier im Thread ja gut verfolgen kann, auch muss.

[Dr. Irata]

gibt es irgendeine schlaue Möglichkeit dem Antic zu sagen, Bildschirminhalte stehen zB in Bank 4 und der CPU zu sagen ... Code in Bank 2?
Also gleichzeitig??

[andymanone]

Schau doch mal in das 130XE Handbuch (das hatte ich dir glaube ich früher schon mal als DL angehängt ).
Da steht das mit dem separaten CPU/ANTIC Speicherzugriff drin (in der DE Ausgabe auf Seite 95)

Edit: hier nochmal die relevante Seite angehängt...

Gtx.,
andY

[patjomki]

gibt es irgendeine schlaue Möglichkeit dem Antic zu sagen, Bildschirminhalte stehen zB in Bank 4 und der CPU zu sagen ... Code in Bank 2?
Also gleichzeitig??

[Unsinn gelöscht]

Da ja immer eine Bank in den Speicherbereich eingeblendet wird, geht das wohl (doch) nicht. Es geht wohl nur, dass der eingeblendete Bereich für entweder die CPU oder den ANTIC im Zugriff ist (oder beides wie bei Rambo).

[Dr. Irata]

ich wette es gibt irgendeine richtig schlaue Möglichkeit dem Antic immer fix eine Bank zuzuweisen und zusätzlich ein normales Bankswitching für die CPU zu machen...

[Mathy]

.
Hallo Peter

Das würde mich sehr wundern. Denn die Adresse mit der man die Bank zuweist ist auch die Adresse mit der man den Zugriff zuweist.

Tschüß

Mathy

[CharlieChaplin]

Die Anzahl der Programme, die sep. Antic Zugriff nutzen ist zwar inzwischen auf ca. 10 Programme gestiegen, doch viel ist das nach knapp 40 Jahren des 130XE Standards (1985) ja immer noch nicht.

Du hast ja meistens Listen für sowas. Welche Programme sind es denn?

Das Problem vieler vieler A8 Listen ist, dass ich mit dem updaten nie hinterher komme. Auf meiner Liste stehen noch ca. 8 Programme drauf, letztes Jahr (oder dieses Jahr?) gab es auf der SV aber ein 128k Demo, das nur mit sep. Antic läuft, Name leider vergessen. Und ein weiteres Programm fehlt auch noch und dessen Name will mir partout nicht einfallen...

Hier meine unvollständige Liste (englisch, war für's AA Forum):

Some A8 programs that (I know) make use of sep. Antic access:

01) The Wedge (Tool) by Ed Bachmann => format option, tool works under SpartaDOS only!
02) Video Blitz (Demo) by Helvetica Bold => patched version by HiasSoft available, that does not require sep. Antic!
03) TL Cars (Game) by T.L. => patched version by Homesoft available that does not require sep. Antic!
04) AD 6502: Arsantica 2 (Demo) by Heaven/Desire, Karolij Nadj
05) Apple II Emulator (Tool) by Piotr "Artax" Mejer
06) RGB picture slideshow (Demo) by metalguy666 => changed version by me available that works with 64k RAM and therefore does not require sep. Antic!
07) ???
08) Kompleks K-12 (Game-Teaser) by Bocianu (320k Compyshop)
09) State of the Slayer (Demo) by X-Men
10) ???


Afaik, Kompleks K-12 is the only program that requires min. 320k RAM, while all others work with 128k RAM...

sep_Antic.txt

Programme für sep. Antic

(878 Bytes) 76-mal heruntergeladen

[patjomki]

Das Problem vieler vieler A8 Listen ist, dass ich mit dem updaten nie hinterher komme.

Ich bewundere das ja sowieso, wie viele Listen Du so pflegst. Dass Du da nicht hinterherkommst, wundert mich nicht.

Auf jeden Fall vielen Dank für diese Liste, dann kann man mal testen und so.

[CharlieChaplin]

So, hier eine neuere Liste mit Programmen, die sep. Antic Zugriff benötigen:

01) AD6502: Arsantica 2 by Desire [demo] (fractal part)
02) Apple II Emulator by Piotr "Artax" Mejer [tool/application]
03) Atariwriter+ XE for Omniview 80 by Atari & Newell Industries [tool/application]
(modified version of AW+, especially made for Omniview 80 by Newell)
04) Gr.8 RGB picture show by MetalGuy [demo/slideshow] (slideshow program)
05) TL-Cars by T.L. [game]
06) Video Blitz by Helvetica Bold [demo]
07) (The) Wedge by Ed Bachman [tool/application] (format option!)
08) Kompleks K-12 [game-Teaser] by Bocianu (320k Compyshop)
09) State of the Slayer [demo] by X-Men
10) ??? (one more program, but I always forget its name...)

So in almost 40 years (130XE released in 1985) we do have 10 programs that utilize sep. Antic access.
Afaik, Kompleks K-12 is the only program that requires min. 320k RAM, while all others work with 128k RAM.

[LarsImNetz]

ich wette es gibt irgendeine richtig schlaue Möglichkeit dem Antic immer fix eine Bank zuzuweisen und zusätzlich ein normales Bankswitching für die CPU zu machen...

Hallo Peter,
wenn ich die XE Anleitung richtig verstehe, geht das. Der Antic zeigt dabei in das normale RAM und nur die CPU nutzt dann die 4 Bänke des XE für sich.

LG
Lars