Hallo
Multicolor-Graphik am C64 war bisher nicht so mein Ding - hat's ja echt in sich...
Ich bastel(te) grade einen kleinen Scanner für den C64, der soweit auch läuft.
Ich kann derweil 'Bilder' mit 40x25 - Auflösung im Textmodus anzeigen lassen.
Jetzt sollen natürlich 160x200 her :o)
Da ich mit 4 Farben komplett auskomme (Grau eben) ist mir Farbtrickserei egal.
Der Scankopf ist auf einen Drucker montiert, so dass die Routine möglichst schnell sein muss. 40 Daten zu verabeiten während der Druckkopf über eine Zeile fährt ist kein Problem. Bei 160 bin ich mir nicht SO sicher, vor allem scheinen mir einige Rechnereien nötig zu sein, um
ein Koala-Bild Zeilenweisen und NICHT Blockweise aufzubauen. Und ich stelle mir das etwas kompliziert vor mit den Bits rumzutüdeln.
Hat das schonmal jemand hier gemacht, oder weiss wo ich etwas derartiges finden könnte? Vielleicht hat ja jemand mal ein Koala-Malprogramm geschrieben?
Dir Druckersteuerung läuft derweil noch in Basic erstmal. Ich habe recht viel Platz - macht es Sinn die Daten erstmal irgendwo in den Speicher zu setzen und dann hinterher in Koalazeilen umzurechnen? Lieber wäre mir ein direkter Weg natütrlich.
Ich wäre für jede Hilfe dankbar!!
Wenn die Steuersoftware läuft , ist das ganze übrigens sehr leicht nachzubauen
Danke schonmal & Gruss aus Hamburg,
enthusi
letzter Beitrag von enigma am
KOALA - Graphik Zeilenweise?
- enthusi
- Erledigt
-
-
Hallo enthusi
ZitatOriginally posted by enthusi
Hallo
...
Bei 160 bin ich mir nicht SO sicher, vor allem scheinen mir einige Rechnereien nötig zu sein, um
ein Koala-Bild Zeilenweisen und NICHT Blockweise aufzubauen. Und ich stelle mir das etwas kompliziert vor mit den Bits rumzutüdeln.
Hat das schonmal jemand hier gemacht, oder weiss wo ich etwas derartiges finden könnte? Vielleicht hat ja jemand mal ein Koala-Malprogramm geschrieben?
...Der Zeilenweise aufbau sollte nicht so schwierig sein.
0. Zeile: Pixel 0-3 in Byte 0, Pixel 4-8 in Byte 8, Pixel 9-12 in Byte 16 ...
1. Zeile: Pixel 0-3 in Byte 1, Pixel 4-8 in Byte 9, Pixel 9-12 in Byte 17 ...
.
.
.
8. Zeile: Pixel 0-3 in Byte 320, Pixel 4-8 in Byte 328, Pixel 9-12 in Byte 336 ...usw.
Aufbau eines Bytes:
pixel0 - 3 : Farbe des Pixels: entweder %00000000 oder %00000001 oder %00000010 oder %00000011
Alles anzeigenGruß Thomas
-
Wie kommen denn die Intensitaetsinformationen in den C64?
Da kann man doch sicher mit Hilfe einer Tabelle die Umsetzung der Rohdaten zu den Pixelwerten sehr beschleunigen u.U. sogar die ganzen ASLs einsparen und 4 Tabellenwerte pro Pixelfarb/position vorhalten, so dass man es nur ORA en muss.
Ciao...
...Micha -
Hallo & Danke schonmal
Ich lese die Daten über den A/D-Wandler des SID ein, also direkt an EINER Adresse.
Da kommt dann 00-ff and und ich mache eine Fallunterscheidung alacmp #$40
bcc $set_pixel_col=1cmp #$80
bcc $set_pixel_col=2jmp $set_pixel_col=3
...
;$set_pixel_col=3
lda #$03
rts (zum Programmteil wie ihn Thomas beschrieben hat)alles nicht so optimal - aber bisher auch nur so im Kopf zurechtgetüdelt
bzw. so ähnlich - nagelt mich nicht auf den Werten fest,..
Das Prob dabei wird sein möglichst jeden Pixel schnell genug und vor allem aber gleich schnell einzulesen so dass ich keine Schlieren in den Scan bekomme.
Deine Idee mit ORA etc. hab ich noch nicht ganz durchschaut...
Magst Du's nochmal langsamer versuchen?
Danke & Gruss,
Martin -
Also ich habe mal zum SID geschaut:
Der Umsetzungsprozess hängt von der Kapazitaet ab, die an Pin24 (POTX) nach GND geschaltet ist. R*C = 0,00047 muss erfuellt sein und die empfohlenen Werte sind: C= 1000 pF und R = 470 kOhm.
Intern laeuft die A/D wandlung wohl ueber Zeitmessung der Ladekurve des Kondensators ab.
lt. Datenblatt wird Register $19 alle 512 Takte erneuert.512 Takte sind ne recht lange Zeit, ich denke das ist recht easy ueber nen CIA1 Timer Interrupt realisierbar. Dadurch kommt die Abfrage auch sehr gleichmaessig.
Mal angenommen du hast eine einfache Helligkeitsdiode, die Werte zwischen $00 und $ff liefert, wobei $00 schwarz und $ff weiss ist.
Dann machste nen Counter, der die pIxel pro Byte waagerecht von 3-0 durchzaehlt fuer jeden gesampleten wert, also 3,2,1,0,3,2,1,0 usw.
dann in etwa so:
dec Counter
bcc .keinunderflow
lda #3
sta Counter
lda Bitmappos_Low ; Das ist nen Zeropagepointer
clc
adc #8
sta Bitmappos_Low
bcc .keinunderflow
inc Bitmappos_High
.keinunderflow
lda POTX
rol
rol
rol
and #%00000011
tax
ldx Counter
beq .Goon
.schieb
asl
asl
dex
bne .schieb
.Goon
ldy #0
ora (Bitmappos_Low),Y
sta (Bitmappos_Low),Yok so mal aus dem Kopf.
Fuer das ORA sollte entweder der Bitmapbereich vorher geloescht sein, oder du laedst ne 0 vor, wenn Counter auf 3 ist.
Das sollte alles easy in den 512 Zyklen ablaufen.
Was noch dazukommt ist die Druckkopfsteuerung und die Pausen zum zurueckfahren.
Wenn du keine homogene Helligkeitskurve hast, dann nimm die lsr raus und lade die entsprechenden Werte aus einer Tabelle von 256 Bytes.
Ich weiss nicht wie du sampelst, aber waehrend der Druckerkopf sich bewegt den Scanner abzufragen koennte recht ungenau sein, ggf immer zu hell oder zu dunkel, weil der Komparator uU schon eher anspringt.Interessant wird es, wenn du Sensoren fuer bestimmte Frequenzen hast und aus helligkeitswerten auf die 16 C= Farben umsetzt.
Vielleicht hilfts...
Ciao...
...Michaedit: bloedcode im posting gewesen