HIVE-Project

Hallo Drohnen,
suche für folgendes Problem ne Lösung:
In einem Bildpuffer von 8k für VGA-Auflösung 320xirgendwas wird der Inhalt je "Zeichen" gespiegelt dargestellt. D.h. Je Byte liegen die Bits für die Pixel genau falschherum.
Alle mir bekannten Treiber lesen nun eine long (4Byte) ein, um sie der Videohardware zu übergeben.
Ich müßte nun in der long jeweils in jedem Byte separat die Bits genau vertauschen, also bit7 wird bit1, bit6 wird bit2 usw.
Und da bin ich nun mit meinem PASM-Latein am Ende, nicht wegen der Programmierung an sich, sondern wegen der Schnelligkeit meiner Programmierversuche. Verbrauche zuviel Rechenzeit und damit bleibt dann der Moni dunkel
Hat jemand ne zeitsparende Idee?

Grüße Uwe

Poste doch mal deinen PASM-Code, es reicht ja die innere relevante Schleife.

unick59 hat geschrieben:Ich müßte nun in der long jeweils in jedem Byte separat die Bits genau vertauschen, also bit7 wird bit1, bit6 wird bit2 usw.

Das klingt nach 8x? RAM font. Also warum nicht einfach all bytes in der Fontdefinition spiegeln (font[idx] ><= 8)? Muss ja nicht permanent sein sondern kann gemacht werden bevor Du den Treiber startest.

@drohne 235:
hab den code nicht hier zur Hand, aber vom Prinzip:
1. Einlesen Long aus Bildspeicher,
2. auf Byte (1,2,3,4) zurechtschieben
3. Über Carry nach rechts Bit rausschieben
4. Über Carry nach links in Variable reinholen
5. djnz zu 3.
6 Variable zurechtschieben
7. djnz zu 2.

und das sind halt scheinbar zu viele Taktzyklen, so dass waitvid nicht mehr funzt.
bei drehung eines Bytes reichts.
Hab also grundsätzlich da keine andere Lösungsidee

@kuroneko:
Ist ein Speicher, der auch "vollgrafisch" ggf beschrieben werden soll. Handelt sich dabei konkret um eine Emulation eines alten DDR-Rechners JU+TE-Computer in der letzten Ausbaustufe, sog. ES 4.0.
Könnte durchaus in den Emulationsroutinen, die auf den Grafikspeicher zugreifen die Drehung realisieren - hab ich als Alternative im Auge - aber das verlangsamt natürlich den Emulator.
Weitere Variante wäre: Emulator schreibt lustig in Bildspeicher1, Separate Cog rechnet um und schreibt in Bildspeicher2, Treiber stellt Bildspeicher2 dar. Scheitert aber an den 32k des Prop, da ja halt auch noch anderer Code Platz haben muss.

Kann man eigentlich den internen ROM des Prop umprogrammieren? z.b. das ROM-Image des emulierten Rechners (Z8-Prozessor) anstelle des ROM-Zeichensatzes?

unick59 hat geschrieben:Kann man eigentlich den internen ROM des Prop umprogrammieren? z.b. das ROM-Image des emulierten Rechners (Z8-Prozessor) anstelle des ROM-Zeichensatzes?

nee das geht nich beim ROM.

Da hilft nur eins du baust einen anderen Treiber mit eigenem Zeichensatz ein das kostet natürlich Speicherplatz.
Oder du baust einen original Parallax Treiber ein da gibt es die Drehung nicht.

unick59 hat geschrieben:@kuroneko:
Ist ein Speicher, der auch "vollgrafisch" ggf beschrieben werden soll. Handelt sich dabei konkret um eine Emulation eines alten DDR-Rechners JU+TE-Computer in der letzten Ausbaustufe, sog. ES 4.0.

Aber selbst vollgrafisch heisst fuer mich das bit 0 der linke pixel ist (little-endian bis auf Bit-Level). Falls Du einen Link hast (hab nur ES 4.0 binaries gefunden) lass es mich wissen. Ansonsten, haeng den Code hier an, bisher haben wir immer 'ne Loesung gefunden (320x??? is langsam genug um einen gewissen Freiraum zu haben).

z.B. angenommen 640x480 VGA timing (25.175MHz). Da die Aufloesung aber nur 320 Pixel betraegt, ist der eigentliche Pixeltakt nur halb so gross. 8 Pixel benoetigen daher 8/(25.175MHz/2)*80MHz = 50.8 Takte. Minimum timing fuer die letzten vier Befehle ist 4+4+7+4=19, d.h. das Lesen der eigentlichen Pixeldaten (rdbyte) hat mehr als 30 Takte zur Verfuegung (worst case 23). Wie gesagt, nur ein Beispiel da ich den eigentlichen Code nicht kenne.

für kuroneko!
Dein Codefragment hat mir die Schuppen von den Augen fallen lassen, so dass ich den WeihnachtsBaum im Wald wieder sehen konnte
Der Baum hieß REV!
Problem problemlos gelöst.
Danke!!
Grüße Uwe

Hallo Uwe,

mein Senf zum Thema:
...tauscht alle Bits in einem Long. Wenn Du jetzt, wie in Deinem ursprünglichen Post geschrieben, die Bytes im Long an ihrer Position lassen willst, kannst Du folgendes versuchen (A ist der in-out-Parameter und B eine temp. Variable):
Im Gear ist es mir übrigens nicht gelungen, den Code zu testen. REV arbeitet dort anders als in der Doku beschrieben.

Grüße vom U-Held