Stimmt doch nicht, Jiffydos hat den Original-code vom Kernal.
Posts by Acorn
-
-
Könnte sein, Jiffydos hat den fix auch drin.
-
Im Kernal von Frodo wurde ein Fix eingebaut.
-
4kB RAM, dass muss man sich mal vorstellen. Mit 4kB RAM könnte ein C64, nicht einen einzigen Pixel auf dem Bildschirm ausgeben, weil die beiden einzigen Grafikmodi die dieser besitzt rund 8kB benötigt. Ein Pixel von der Größe einen Klotzes macht in einer 4kB Maschine Sinn, es spart Speicher. Ist mehr Speicher da, macht es auch kaum noch Sinn
Das ist nicht ganz richtig, der C64 hat 5 Grafik-Modi, drei mit Zeichensatz die je 1 KB RAM für den Bildschirmspeicher + 8 Bytes pro Zeichen für die Grafik belegen und nur in den beiden Bitmap-Mode werden 9 KB benötigt. Im Prinzip braucht der C64 sogar weniger Speicher als der Atari, da Sprites nur 64 Bytes belegen und es keine Displayliste gibt. Es gibt zwar ein paar Grafikstufen die sehr wenig Speicher auf dem Atari verwenden, die sind aber von extrem niedriger Auflösung und spielen wahrscheinlich auch kaum eine Rolle.
-
Das zeigt wieder einmal, jeder tickt anders, natürlich macht es wenig Sinn, das Programm auf funktionierender Hardware zu testen. Aber zum Spaß oder aus Neugier, was das Programm so macht, kann man es doch mal laufen lassen. Nebenbei die Routine ist aus meinen Coder-Kernal und verwendet unter anderem auch Illegal Opcodes.
-
Seltsamer Fehler, wenn der Speicher wirklich fehlerfrei ist, müsste dieses Programm den Cursor blinken lassen.
10 fort=0to69:ready:poke49152+t,y:next:sys49152
20 data120,169,0,133,204,44,17,208,48,251,44,17,208,16,251,165,204,208,48,198
30 data205,208,44,169,20,133,205,164,211,167,207,73,1,133,207,240,17,165,209
40 data133,243,165,210,41,3,9,216,133,244,177,243,141,135,2,177,209,133,206,73
50 data128,145,209,189,134,2,145,243,76,5,192
-
Wissen nicht, aber bei einem vorhandenen Emulator der extra auf dem PC zum Entwickeln von Konsolenspielen geschrieben wurde, ist das durchaus denkbar. Eine Zeit lang hat sich die Rechenleistung des PC (ohne Multi-Core) nahezu alle 18 Monate verdoppelt.
-
Allgemein wird auf dem 6502 gerade für solche Fälle die Zero-Page verwendet, es ist auch Teil der Architektur das so zu handhaben. Es gibt eigentlich keinen Grund es nicht so zu machen.
LDY #$00 ; 2 Takte
LDA ($FB),Y ; 5 Takte
Beim 65C02 hat man die Adressierungsart sogar erweitert oder gekürzt je nachdem wie man es sieht.
LDA ($FB) ; 5 Takte
Man kann auch um eine Architektur drum herum programmieren, dann sieht das ganze so aus.
LDX $02A4 ; 4 Takte
LDA $02A5 ; 4 Takte
STA MOD+2 ; 4 Takte
MOD LDA $0000,X ; 4 Takte
Und bei ROM-Code bleibt fast nur der Umweg über die Zero-Page, $FB enthält dabei schon $00. Wobei man sich hier schon selber die Frage stellen sollte, warum nicht direkt per Zero-Page.
LDY $02A4 ; 4 Takte
LDA $02A5 ; 4 Takte
STA $FC ; 3 Takte
LDA ($FB),Y ; 5 Takte
Ich liebe die Gemeinschafts-Videos von Zerobrain mit Wolfgang. Im Video ab 24:26 wird der Sourcecode zum Füllen des Bildschirmspeichers in Assembler gezeigt, die Routine verwendet die Zero-Page. Man merkt, das Wolfgang nicht mehr so tief in der Programmierung drin steckt.
[External Media: https://www.youtube.com/watch?v=it56M4LwGe8] -
Was meinst du genau, kann der Sinclair nur 8 der 16 Farben in einer Zeile auf dem Bildschirm bringen und der CPC nur 16 der 27 Farben. Oder spielst du beim ZX81 auf die zwei Helligkeitsstufen an so das es eben nur 8 Farbtöne sind.
-
Nach den ganzen Postings hier habe ich nochmal etwas mehr mit dem Atari befasst. Meine Meinung hat sich nicht geändert, der Atari kann die vielen Farben nicht wirklich verwenden. Nur bei Farbverläufen sind viele Farben möglich.
Demos:
Die Demos würde ich außen vor lassen, da sie z.B. die gesamte CPU-Leistung und auch den Speicher aufbrauchen können.
Spiel:
Beim Spiel Albert sieht das anders aus, aber das wurde auch sehr geschickt designt, so das die Limits nicht direkt ins Auge springen. Wenn man etwas genauer hinschaut, viele Farben werden durch einen Farbverlauf des Hintergrundes erzeugt. Betrachtet man die Bildschirmzeilen auf ganzer Länge, sind nicht so viele Farben vorhanden. Trotzdem ist es ein sehr buntes Spiel mit vielen Farben, besonders im Vergleich zu frühen Atari Spielen. Dafür wurde auch sehr viel Aufwand betrieben, um das zu ermöglichen.
Hardware:
Habe mich noch nie mit den Atari direkt befasst, jetzt aber mal einen kurzen Blick ins Atari Profibuch geworfen. Viele Grafikmodi des Atari benötigen im Verhältnis zur Anzahl der Farben viel Speicher. Die Sprites benötigen auch relative viel Speicher im Verhältnis zur Breite, da diese immer die volle Bildschirmhöhe haben. Deshalb gibt es auch viele Modi mit verringerter Auflösung, um Speicher zu sparen. Und hier gibt es den einen entscheiden Unterschied, der C64 verringert die Auflösung, um die Anzahl der Farben zu erhöhen.
Die anderen Rechner aus den 80'er:
Apple II von 1977 mit 15 Farben.
TI-99/4A von 1981 mit 15 Farben.
VC-20 von 1980 mit 16 Farben.
Sinclair ZX81 1981 mit 16 Farben.
BBC Micro von 1981 mit 16 Farben.
Schneider CPC von 1984 mit 27 Farben.
Kein anderer Rechner bietet so viele Farben wie der Atari. Leider war zur dieser Zeit Speicher sehr teuer, deshalb wurde im 400er nur 8 KB und im 800er 16 KB verbaut. Um viele Farben auf dem Bildschirm zu bringen, braucht man aber auch viel Speicher. Deshalb wiederhole ich mich, der Atari kann die Auflösung nur zugunsten von Speicher opfern. Man kann die Farben nur Zeilenweise auf dem Bildschirm bringen.
Offene Fragen:
Kann man auch Software Bildschirm-Modi erzeugen, die von der Hardware nicht vorgesehen sind. Ist eine Bildausgabe ohne Displayliste möglich damit die CPU nicht bei DMA zugriffen angehalten wird.
-
Nein, das wird über die Hardware des C64 gesteuert. Wenn sich der VIC im Multicolor-Zeichensatzmode befindet, entscheidet Bit-3 aus dem Farbram ob das Zeichen in Hires oder Lores ausgeben wird. Das verhalten kann auch nicht abgeschaltet werden, deshalb sind nur 11 der 16 Farben möglich. Oft sind es auch nur 10 Farben, je nach Hintergrundfarbe.
Schnelltest
POKE53270,216:POKE1024,1
POKE55296,0-7 = Hires und 8-15 = Lores
-
Solche Vergleiche sind immer schwierig, da viele Faktoren entscheidend sind. Die Strukturbreite ist eine unbekannte aber sehr wichtig bei Chips. Siehe 6502 Vs. Z80 fast doppelt so viele Transistoren, aber trotzdem kleiner. Dazu kommen noch die anderen Vorteile einer kleineren Strukturbreite, wie Takt oder Stromverbrauch.
Ansonsten habe noch folgende Ideen dazu.
Es könnte sein das die 256-Farben relativ viele Transistoren kosten, die an anderer Stelle fehlen. Der ANTIC kann die Farben in hoher oder mittlerer Auflösung gar nicht richtig nutzen. Ohne Software-Tricks einfach mal das Titelbild von Boulderdash-II vergleichen. Deshalb wäre es vielleicht besser gewesen auch nur 16 Farben zu verwenden und dafür die Videologik mehr Fähigkeiten zu geben. Des Weiteren wäre das Scrollen in Hardware zu nennen, diese Fähigkeit kostet bestimmt einiges an Transistoren. Aber diese Aufgabe kann genauso gut die CPU wie beim C64 übernehmen, selbst die 1MHz Takt reichen dafür aus. Selbst mit Software-Tricks kann der Atari die Farbauflösung scheinbar kaum erhöhen. Mit anderen Worten, der Atari kann seine 256 Farben nicht auf die Straße bringen.
-
Die Begrenzung hat aber nichts mit der Limitierung der CPU-Power zu tun. Mit einem reinen Multicolor-Zeichensatz hätte man eben alle 16 Farben als nur die 10–11 Farben, die es jetzt nur gibt. Keine Ahnung warum man diesen Mode nicht eingebaut.
So ein Modus würde durchaus auf Lasten der CPU-Bandbreite gehen. Wenn jeder Pixel in einem 4x8 Char eine eigene Farbe haben soll, wären 4 statt 2 Bit pro doppelt breitem Pixel nötig. Da wären die 2 Mhz, die der Bus hat, schon weg, und die CPU hätte nur noch wenige Zyklen pro Zeile im Austastbereich übrig, sofern der Teil nicht für Spritefetches auch noch drauf geht. Während einer Bad-Line würde die Bandbreite gar nicht mehr reichen, und man müßte eine Rasterzeile ganz frei lassen.
Ich meinte Bit-3 im Farbram, das beim Zeichensatz für Multicolor oder Hi-Res sorgt. Ein Mode ohne dieses Verhalten wäre sicher möglich gewesen.
-
Die Begrenzung hat aber nichts mit der Limitierung der CPU-Power zu tun. Mit einem reinen Multicolor-Zeichensatz hätte man eben alle 16 Farben als nur die 10–11 Farben, die es jetzt nur gibt. Keine Ahnung warum man diesen Mode nicht eingebaut.
-
Da fällt mir gerade Master of the Lamp ein, ohne Soundausgabe bei Vice hängt das Spiel im Intro fest, wie sieht das beim SwinSID aus.
-
Da fehlen einfach ein paar Grafikmodi, die man leicht hätte integrieren können
Mit den vorhandenen Ressourcen? Klingt spannend.
Welche denn? Gerne in einem separaten Fred.Ich glaube Retrofan fehlt ein Multicolor-Mode der alle 16 Farben beim Zeichensatz ermöglichen würde.
-
Habe mir das nochmal überlegt, die Verschiebung vorher könnte sogar die bessere Option sein. Wenn Rocky doch von einem Stein oder so getroffen wird, ist er ja noch teilweise in diesem Feld und es passt optisch eigentlich besser als die andere Variante.
-
Ich verstehe Endurion bedenken.
Wenn man die Bewegung sofort ausführt, gibt es unweigerlich ein Problem. Angenommen, das Spiel läuft konstant mit 8 Frames, so dass Rocky sich mit X Pixeln bewegen kann. Obwohl Rocky noch nicht an der Reihe ist, wird bereits eine feinere Bewegung in Richtung zum Zielfeld ausgeführt. Dies würde nebenbei auch das Latenzproblem der Joystick-Abfrage lösen, da die Bewegung sofort (schneller) ausgeführt werden kann. Hört sich zunächst erstmal ganz gut an, aber wenn Rocky sich gar nicht mehr bewegen kann, weil es eine Kollision gibt, hätte die Bewegung gar nicht mehr stattfinden dürfen. Genau genommen gibt es dann ein optisches Problem, man stirbt im vorherigen Feld, obwohl man scheinbar schon viel weiter war. Oder umgekehrt, man wartet bis Rocky an der Reihe ist und führt erst dann die Bewegung aus, in diesen Fall gibt es kein Kollisionsproblem. Da sich Rocky aber noch teilweise im vorherigen Feld befindet, teilt er sich eventuell den Platz mit einem anderen Objekt, da er dieses noch nicht ganz verlassen hat.
Die einzige Lösung wäre so etwas wie, PUH, das ist aber verdammt knapp hier und führt in einem solchen Fall eine Kann noch gerade ausweichen-Animation aus. Dazu müsste man wohl immer direkt mit 8 Pixeln springen, damit man so eine Animation optisch noch gut darstellen kann.
-
Der Download ist etwas versteckt oder besser dieser versteckt sich unter Artifacts.
-
Im Chamberlain sind die ersten Töne des Titelbildes nur hörbar, wenn der DigiBoost aktiviert ist.
Ah Danke für die Mühe, bin gar nicht auf die Idee gekommen, weil ich den 6581 verwende.
Gibt es eigentlich die Möglichkeit dass die Grafik nicht weichgezeichnet wird?
Ja man muss CRT ausschalten und die lineare Interpolation deaktivieren.
