Hallo Besucher, der Thread wurde 13k mal aufgerufen und enthält 64 Antworten

letzter Beitrag von Acorn am

Hires Grafik scrollen möglich ?

    Danke Arndt!

    Habe den Converter fertig gemacht. Sieht jetzt besser aus der Sprite.

    Jetzt bastele ich noch am Multiplexer denn das Fliimmern in den Sprites ist echt kacke.

    Der Code von Kusch ist echt hart.

    MC64

    Na die Bitmap in die Reu stashen und 320 Bytes weiter vorne wieder zurück in den Bitmap Bereich Fetchen.


    In meinem Demo ist die Spielegrafik komplett in der REU und wird wenn Softscroll =0 ist mittels doublebuffering (ja ganze VIC Bank) 320 bytes weiter nach $2000 oder $4000 ge fetched. ja alle 8000 bytes +1000 videoram +1000 coloram.


    Aber das geht bei deinem Textsample ja nicht weil es ja dynamisch sein muss.

    oh sorry. zuviel Text und heute zuviel Assembler gesnifft ;-)
    habe den REUCODE von da geliehen: https://www.retro-programming.de/
    vorher blitte testen ob REU überhaupt da ist : ich fetche nach 0400 und frage ab ob es eh was hingeschrieben hat

    sonst passiert einfach - nix -

    Mir war das Prinzip klar wie du das machst. Mich hat anfangs nur verwirrt das du was von "bitter der reu" geschrieben hast. Ich dachte erst das du was entdeckt hast, was ich bisher übersehen habe. Ich hab mir einen Treiber für den c64 Modus geschrieben und experimentier mit der schon eine Weile. Ich war am ausloten ob damit noch ein bißchen mehr geht als nur ram disk.

    Ramdisk ja aber:


    Na zum Beispiel schreibe ich grad einen Treiber der die Sprites animiert direkt aus der REU

    statt 07f8 manipulationen bleibt alles gleich und ich aktualisiere bei Raster 0 direkt die Spritebuffer

    so spare ich wertvollen Speicher in der 16K vic bank weil die Sprites ausgelagert sind.


    Bin sicher die Reu kann auch Bitmasken manipulation aber dazu müsste man eine echte REU haben um zu schauen was die Register können

    wenn man es an die Grenzen treibt. Wie ich commodore kenne, haben die unter Zeitdruck sicher eine lücke gelassen


    Wenn man die REU neu konstruiert kann man diese Sachen auch gleich einbauen....


    lda hires

    and sprmaske

    ora spritedata

    sta hires


    Das könnte man dann in einem Taktzyklus in Hardware machen


    Hoffe die Mega65 Leute würden da einen Blitter verbauen ähnlich des DTV64

    Schade das Jerri damals nicht einen C65 auf basis ihres FPGAs gebaut hat und nicht diesen C One der irgendwie halb fertig veröffentlicht wurde...

    bits manipulieren geht nicht. du kannst kopieren und vergleichen.

    und mit bischen tricksen speicherbereiche füllen. das wars..... leider.



    logische verknüpfungen wären genial, da man so die grafik beschleunigen könnte.

    für benutzeroberflächen in hires.

    Zitat von ivettaB

    Ich mach das mit REU wegen der Geschwindigkeit.

    Verzeihung, ich hätte mal eine Frage bezüglich der Verwendung der REU zum Scrollen einer Bitmap. Soweit mir bekannt ist (ich bitte um Korrektur, falls meine Informationen falsch sein sollten), übernimmt die REU für ihrem DMA die Speicherzyklen vom Prozessor. Damit das funktioniert, muß der Prozessor in der Zeit des Speichertransfers lahmgelegt werden. Bei einer vollständigen Bitmap wären das dann 8000 Taktzyklen zuzüglich Farbram.

    Wie verhält es sich aber nun mit den Rasterinterrupts, wenn der Prozessor quasi abgeschaltet wurde? Sorgt der Interrupt dafür, daß der DMA unterbrochen und der Prozessor aus dem Winterschlaf geholt wird, um den Interrupt zu bearbeiten (und am Ende den DMA neuzustarten)? Oder teilst Du den Kopierprozess in mehrere Häppchen auf, damit zwischenzeitlich immer die Möglichkeit besteht, daß ein IRQ ausgelöst werden kann?

    Ich befürchte, das dürfte nicht funktionieren, da die Speicherzugriffe jeweils einen Taktzyklus benötigen, d. h. 4 Takte wären hier das Minimum. Für schnellere Aktionen bräuchte man auch neues, schnelleres Ram, das mehr Zugriffe innerhalb eines 1 Mhz-Zyklus erlaubt als nur 2 (Prozessor und VICII).

    Zitat von M. J.

    Verzeihung, ich hätte mal eine Frage bezüglich der Verwendung der REU zum Scrollen einer Bitmap. Soweit mir bekannt ist (ich bitte um Korrektur, falls meine Informationen falsch sein sollten), übernimmt die REU für ihrem DMA die Speicherzyklen vom Prozessor. Damit das funktioniert, muß der Prozessor in der Zeit des Speichertransfers lahmgelegt werden. Bei einer vollständigen Bitmap wären das dann 8000 Taktzyklen zuzüglich Farbram.

    zu der bitmap kommt ja auch noch das farbram. aber du mußt nicht die vollen 10k kopieren. sondern immer nur eine zeile. in dem moment wo der dma chip (rec) arbeitet, liegt die cpu brach. alles andere, timer usw. laufen weiter.

    Zitat von MC64

    aber du mußt nicht die vollen 10k kopieren. sondern immer nur eine zeile

    Das meinte ich mit "mehrere Häppchen", allerdings weiß ich nicht, wie gut das dann mit einem Rasterinterrupt zusammenarbeitet. Eine Bitmapzeile sind ja immerhin 320 Taktzyklen, was ca. 5 Rasterzeilen (320 / 65) entspricht, in denen die CPU auf einen Rasterirq nicht reagieren kann. Das könnte zu einem Problem werden, wenn man einen Spritemultiplexer einsetzt, der mehrere genau terminierte Rasterinterrupts erfordert, deren jeweiliger Zeilenunterbrechungswert sich von Mal zu Mal ändert, oder liege ich da falsch?:gruebel

    also mit einer zeile meine ich 40 byte. da die reu ja nur byteweise aber nicht bitweise kopieren kann. ich selbst hab das noch nicht probiert.

    das wird dir ivettaB besser beantworten können. ich weiß aber was du meinst, im bezug auf den multiplexer.

    man könnte das eventuell kompensieren, wenn man immer ein komplettes hiresbild aus der reu ins c64 ram kopiert. das ist rein rechnerisch

    schneller als wenn man immer 40 byte kopieren würde.

    genau so ist es. Es ist schneller die 8000 bytes einzukopieren. dann video und das colorram.

    In der Tat war es bei version 1 so, das die DMA Zeit 50 % des Bildes eingenommen hat und ich nur einen kleinen Teil der Graphic sauber scrollen konnte.

    Deshalb sagte ich oben "nach intensiven Nachdenken...." und habe dan wie MJ richtig folgert "in Häppchen" einkopiert während ich softscrolle.

    Das machte dann das Problem das ich eine ganze VIC Bank extra für Double buffering benötigt habe... Leider. Und der Code sich vervierfacht hat um das alles

    zu schaffen.

    Also 10 KB durch 8 geteilt und jede Softscrollzeile werden im 2. buffer $0505 bytes kopiert. Siehe Unten.


    Und ja während DMA laufen SID VIC und CIA munter weiter und ein RasterIRQ kann nicht von der CPU in dieser Zeit beantwortet werden.

    Erst wenn CPU wieder läuft wird der IRQ gelesen, bestätigt und der Code ausgeführt.

    Deshalb muss man D012 fragen ob es eh noch in der Zeile steht wo es sein soll. Und deswegen flackert auch beim Girlsdemo zeitweise der Schirm,da

    der Rasterstrahl ab und zu durchgelaufen ist ohne den IRQCode abgearbeitet zu haben... Der Sprite Multiplexor ist/wird eine herausforderung.

    Aber im Moment habe ich Probleme das der VIC selbst ohne REU innerhalb der Sprites Fehlermacht weil ich nicht schnell genug 07f8 mit neuen Daten fülle weil die Zeit schon mit sta $d00x,y ausgefüllt wird. Deshalb werden die Sprites jetzt auch von der REU in 8 Takten gefüllt und gut ists.

    Code
    1. State machine
    2. 7 anzeigen und d800
    3. 6 8192 0 +1285
    4. 5 9477
    5. 4 10762
    6. 3 12047
    7. 2 13332
    8. 1 14617
    9. 0 15902 +290 bytes (hires fertig)
    10. 0 1000 bytes nach 1024

    Also bei den Bildern aus Post #1 frag ich mich, ob man die nicht doch ähnlich gut per Zeichensatz darstellen kann. Oder evtl. aus zwei Zeichensätzen (per Screen) zusammenbaut, wenn 256 Chars wirklich nicht genug sind. Die Datenmenge wäre kleiner (inkl. Colorram), im besten Fall arbeitet man nur mit 40 Bytes-Fetches, und man könnte leicht scrollen.

    Oder man scrollt gar nicht, sondern hat einfach alle Scroll-Frames einzelnd als Film in der REU, ähnlich hier:)

    ja bei charset hast du aber nur 3 Farben +hintergrund für alle character Bildschirm. Ausser mit 25 RasterIRQs vielleicht pro Videoram Zeile. Meine Girls haben mehr als 4 Farben pro Zeile (wenn man genau schaut).

    Deine Idee habe ich schon getestet und es war außer schnell nicht sonderlich interessant zum anschauen. Auch mit 2 Charsets die per RasterIRQ umgeschaltet werden war es nicht besser - deshalb wollte ich volle Hires Scrollen...