The Siemens S65 132x176, 65536 color display with AVR

Hallo,
da ich die Programmiersprache C  nicht beherrsche, habe ich mit Hilfe
der Beschreibung von Christian Kranz ein Bascom- Programm für das
LS020XXX  geschrieben und damit das Display zum laufen gebracht. (Siehe
Bild)
Hier ein paar Punkte die mir beim Arbeiten aufgefallen sind:
1. Init: die 7 ms nach Init2 dürfen auch länger sein !
   (100 ms funktionieren bei mir auch !!!)
2 .Zwischen Init3 und Init4 darf ich kein delay einfügen !?
3. Locate(X,Y)  =  0x6YS, 0x7XS
4. PMEMWRX: (X-direction)  =  X mit Y vertauscht!
                            Arbeitet bei mir so richtig;
                            0xEF90,  0x0504,  0x08Y1,  0x09Y2,
                            0x0AX1,  0x0BX2

5. Pin 1V8 hat bei mir den Anschein als ob es NC ist !!!  (not
connected) (bin aber nicht absolut sicher !) Kann auch keinen Strom
messen.

Seltsames:
- Wenn ich eine blaue Linie oder Box zeichne werden die anderen
  Farben merklich blasser, nachdem das Zeichnen beendet ist.
  Zeichne ich danach z.B.  eine schwarze Linie  sind die Farben
  wieder kräftiger.

- Der Kontrast ist bei senkrechter Betrachtung schlechter als wenn
  ich etwas von Rechts auf das Display schaue !
  (Direction: Lange Seite Unten)
  Ist dies bei euren Displays auch so ?

Frage:
- Ich habe gelesen, dass das L2F50.... bei einigen auch
  funktioniert.
  Kann aber keine Beschreibung der Steuerparameter finden.
  Könnte jemand die bekannten Steuer Befehle für das L2F50...
  senden ?

Hallo SuperUser,

* Wegen X/Y Vertauschung: Beziehst du dich auf das Bild auf der
Web-Seite? ...
-> Ja Direction Lange Seite unten. (0x0504)

* Für das L2F50 kannst du dir die Init-Sequenzen ebenfalls von
superkranz runterladen (in C). Allerdings gibt es keine so detailierte
Beschreibung wie für das LS020...
-> Problem ist nur, dass  mir C sehr suspect ist!!!
(Programiere in Turbo-Pascal, Nili-Pascal, Delphi, etwas Assembler und
Basic, aber C liegt mir absolut nicht!)
Bräuchte die Befehle und das Init hald extrahiert!
Für jemand der C versteht sollte dies doch mit wenig Aufwand möglich
sein...

Gruß Bernd

@Mike

Hallo Mike,
nein SPI bei Bascom hab ich mal kurz versucht funktionierte bei mir
aber nicht.
Ich verwende den ShiftOut Befehl.

Hier ein Beispiel:
*********************************************************
Rs Alias PortD.3          'Register Select (Command/Data)
Cs Alias PortD.2
Sclk Alias PortD.1
Sdata Alias PortD.0
LCDReset Alias PortD.5

Const Kommando = 1
Const Parameter = 0

Dim Ausgabe As Word

'---------------------------------------------------
'--- LCD_Send = Send Data to Display        --------
'---------------------------------------------------
LCD_Send:
  CS = 0
  Shiftout Sdata , Sclk , Ausgabe , 0                       'Msbl
  CS = 1
Return
'--------------------------------------------------------

'--------------------------------------------------------
'-- PSet = Set Pixel(X,Y,Color)                  --------
'--------------------------------------------------------
Sub PSet(byval Lx1 As Byte , Ly1 As Byte , Color As Word)
   Rs = Kommando
   '------- Locate ------
   Ausgabe = &H0600 + LY1                                   'Y
   Gosub Lcd_send
   Ausgabe = &H0700 + LX1                                   'X
   Gosub Lcd_send
   '---------------------
   Rs = Parameter
   CS = 0
   Shiftout Sdata , Sclk , Color , 0                        'Msbl
   CS = 1
End Sub
'-----------------------------------------------------------

'ENDE ENDE ENDE
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX


Nun noch eine Frage an alle die C- können.....
Ich versuche gerade ASM-Routinen in Bascom mit einzubinden und dann
noch mal den SPI-Anschluß zu testen.
Probleme machen mir aber die C-Teile im ASM Code !!!

    ; setup serial data interface
    ; select clock phase positive going in middle of data
    ; master mode
    ; enable SPI
    ; speed is CPUclock/2

    ldi     r24,(1<<MSTR) | (1<<SPE); | (1<<SPR0);  ; Master Mode,

*** Welcher Wert wird hier in R24 geladen ?


    Enable SPI, fCPU/16 clock

*** Wie wird das in ASM umgesetzt ?

Vielleicht kann das ja jemand beantworten......

Gruß
Bernd

Hallo!

Im PDF und hier im Thread steht, daß als Spannungsregler ein
IRU1205CLTR in Frage kommt. Hat ihr einen justierbaren genommen und auf
2,9V eingestellt, oder die Fetsspannungsversion mit 2,8V gewählt?

Gruß
         Daniel

Die Shiftout Funktion von Bascom ist fuer dieses Display leider nicht
wirklich geeignet. Man hat mit einem AVR so schon zu knabbern, eine
brauchbare Geschwindigkeit hinzubekommen und macht sich mit dieser
Funktion alles kaputt (am besten einfach mal den Disassemler
drueberjagen, dann sieht man, was ich meine).


Ich hatte eine Erstatzfunktion geschrieben, die nur das noetigste
enthielt, aber die scheint mir beim Umstieg auf HW-SPI leider verloren
gegangen zu sein. Also hier noch einige Schnipsel fuer Bascom bei
Benutzung des HW-SPI und eines LS020 Controllers (mehr moechte ich
ungern veroeffentlichen).

Es handelt sich um Schnipsel, nicht um kompletten Code. Wer etwas damit
anzufangen weiss, sollte aber dennoch klarkommen ;).

Die 3 Init-Sequenzen wurden in eine Einzige verpackt, die Aufteilung
erfolgt durch das Programm selbst (platzsparender).

Besten Dank uebrigens noch an alle, die die Benutzung dieser Displays
ueberhaupt ermoeglicht haben :).

Beste Gruesse,
André

den DisassemBler meinte ich natuerlich :)

@Andre K:
Ich probiere gerade aus was deine Routinen bringen. habe bei der
Compilierung folegenden unklaren Fehler gefunden:


Getinitbytes:
   !nextbyte3:
   lpm r26, z+
   lpm r27, z+

   sts {a+1}, r27
   Sts {a} , R26
Shout
   subi r20,1
   sbis sreg,sreg_z   <-- ? Was für ein Wert?
   rjmp nextbyte3
ret


bei sreg_z bekomme ich ne Fehlermeldung, was muss da eigentlich
stehen.

Error :illigal Character - wie ist sreg_z declariert?
Ich bin mal gespannt wie deine Routine Funktionieren werden :-)

Grüsse

Sreg_Z ist in m168.def als 1 definiert und bezeichnet das Zero-Flag in
Sreg. Bei anderen, aelteren regfiles steht das nicht drin, hast recht.
Sofern Z also Bit1 ist (wenn ich mich nicht irre, bei allen AVRs), dann
einfach 1 hinschreiben.

Beste Gruesse

@Andre K:

So habe deine Routinen mal ausprobiert , allerdings ohne erfolg :-(
Könntest du mal das Listing anschauen ob da noch was fehlt.

Das Display macht nichts, es sollte blau werden (CBlue)

ich arbeite mit einen ATMEGA16L mit 8MHz das Display LS020... wird
direkt angeschlossen.

Habe mit den Codeschnipsel von Martin K und Bernd_XXX
paar Routinen geschrieben, allerdings habe ich folgende Probleme:

1)
Buchstabe wird nicht an die Position gezeichnet und die
Hintergrundfarbe ist schwarz, obwohl eine andere angegeben wurde.

2)
Buchstaben werden mit grossen versatz geschrieben bzw garnicht.

3)
Und es wird nicht immer die Farbe ausgegeben die angegeben wurde.

Vielleicht habe ich da was übersehen?
Könntet Ihr mal schauen wo ein  fehler vorliegt,
bzw besser gemacht werden kann?

Hardware Mega16L Display L020.. direkt am A Port dran bei 2,9V.

thx.
AVRNix

Welche HEXwerte meinst du ? Die können Speicherstellen sein ( Display )
oder 16 Bit Farbwerte in RGB 5-6-5 format.
Die werden dann über SPI zum S65 übergeben.

Hallo AVRNix,

ich kann keinen Fehler finden, das sollte so eigentlich funktionieren
(tuts zumindest auf meinem atmega168).

Schaltest du die Hintergrundbeleuchtung zeitig genug ein? Ich habe die
Erfahrung gemacht, dass sich das Display ohne diese Spannung manchmal
nicht initialisieren laesst.

Beste Gruesse

keine Ahung sind von Christian K. analysiert worden.
Da es kein datenblatt gab.

@Andre:

Wozu dienen die Routinen Defpartxyxyh und Defpartxyxy und welche
Parameter werden dort eingetragen?

Kann das sein das es ein Ausgabebereich def. wird?

Hi,

genau. (x1;y1) =  linke untere ecke. (x2;y2) = obere ecke.

Mit defpartxyxy kannst du logischerweise beide eckpunkte des Rechtecks
angeben. Bei Defpartxwyh hingegen gibst du nur einen Eckpunkt, sowie
Hoehe und Breite des Rechtecks an. Man kann eigentlich einfach eines
ins andere umrechnen, aber ich habs eben getrennt gemacht. Hast du das
nun inzwischen ans Laufen bekommen?

Beste Gruesse,
André

nein - mache ich morgen, ich habe das Backlight direkt an einer anderen
Stromversorgung dran. Nur komisch das, das Display nicht anspringt :-(

Hast du mal mein Programm auf dem M168 laufen gelassen ?

bis dann

@Andre:

So habe es ausprobiert, nichts zu sehen auf dem Display.
Das Display bleibt mit Bunten Pixel und wird nicht Blau eingefärbt.

Hat es schon einer zum laufen gebracht und auf welchen Mega?

Habe es mit M16L und M32 probiert, nicht zusehen von der Blauen Farbe
schneit mit Hard-SPI nicht zu klappen :-(

Merkwuerdig, sollte bei den AtmegaX8ern irgendetwas anders sein, das ich
uebersehen habe? Bei mir laeuft es zumindest einwandfrei, getestet mit
12 LS020 Displays.

Beste Gruesse,
André

@Kay: hast du die Hard SPI gegen Shiftout getauscht(Programm aus "S65
mit SPI" )?
kannst du dann mal das Programm posten?

Koennte bei Interesse evtl. neue anbieten. Bei Interesse Mail (27780 ätt
newdsl punkt de).

Warum mein Code nicht funktioniert, kann ich euch leider immer noch
nicht sagen. Ich kann keinen Fehler entdecken.

Beste Gruesse,
André

@Andre: wie hoch ist der (unter Option/Enviroment/Compilier) HWSTACK
SoftStack unf Framesize ?

Und hast du den Code mal auf einen M16 ausprobiert?

AvrNix:
Stell einfach alles mal auf 60 (reicht dicke fuer so ziemlich alles
aus). Ich hab dort meist ueberall 40 drin.

Ich hab momentan leider nur Atmega88s und 168s hier, weil ich in
letzter Zeit nichts anderes verwendet hab.

Beste Gruesse,
André

@Klappt auch nicht :-(

Hat jemand mal das
http://www.mikrocontroller.net/attachment.php/420053/S65+mit+SPI.txt

ausprobiert?

Und was ist das ergebnis?

Merkwuerdig. der einzige Unterschied zu meinem Aufbau duerfte darin
liegen, dass ich auch die LED-Spannung vom µC erzeugen lasse
(PWM+100µH+Transi), die ich eben vor der Init noch einschalte.
Ansonsten kann ich mir wirklich nur noch vorstellen, dass bei diesen
Atmegas beim HW-SPI irgendetwas anders laeuft (es wurden bei den *8 ja
einige Register umbenannt, evtl. greift der ASM-Teil nun auf die
falschen Register zu?! Muesste man mal ueberpruefen.

Beste Gruesse

Hallo alle zusammen!

Ich hab mal ne kleine Interfaceschaltung entwickelt, die ich demnächst
bauen werde. Die LED-Hintergrundbeleuchtung soll durch einen
LED-Treiber (gtaktete Stromquelle angesteuert werden). Nun die Frage:

Leuchten die LEDs sofort bei angeschlossener Spannung an den Pins, oder
muß man intern nochwas einschalten?

Wenns das der Fall ist, habe ich Bedenken, daß die Stromquelle bei
ausgeschalteter Hintergrundbeleuchtung eine zu hohe Spannung auf das
Display drückt und es dadurch einen Schaden geben könnte.

Gruß

Hehe und schon einen Fehler im Schaltplan entdeckt...

Hallo avr / lcd - freaks !

Habe die Diskussion schon längere Zeit verfolgt - interessant.
Da ich selbst "stolzer" Besitzer eines D062x-Moduls (132*132) von
Display3000 bin, mich aber von Anfang an die Benutzung von "BASCOM"
gestört hat, habe ich nach Alternativen gesucht.

Also erst mal WinAVR - kostenlos, praktisch -> gut !
Dann hat mich der Code von Hagen R. (glcd11) (www dot apetech dot de)
zum Nachdenken angeregt...

Was dabei rausgekommen ist, ist eine neue (C-) Bibliothek, die alle
Funktionen der GLCD11 enthält. Ich hoffe Hagen R. hat nichts dagegen
:-)

Was ich aber nicht weiss, ist, wie sich Hr. Küsters zu einer
Veröffentlichung dieser Bibliothek verhält; in seinen FAQs kann man
folgendes lesen:

F: Muss ich auf die Software Lizenzgebühren zahlen, wenn ich sie selber
in kommerzielle Produkte einbauen möchte?
A: Wir haben das Copyright auf unsere Software und die Dokumentation.
Sie dürfen die Software jedoch in Ihre eigenen Projekte nach Belieben
integrieren und verkaufen - ohne jegliche weitere Zahlung an uns. Die
einzige Einschränkung: Ihre Applikation muss kompiliert sein. Es ist
nicht gestattet, einen lesbaren Source-Code weiterzugeben. Die
Dokumentation über die Ansteuerung des Displays dürfen Sie nicht
weitergeben (auch nicht auszugsweise).

Is ja'n Ding...

Wenn ich also eine Bibliothek - wohlgemerkt OHNE seinen Basic-Code -
weitergebe, dann habe ich also ein Problem ? Oder wie ??

Aber vielleicht hat ja jemand Interesse ...

Nachtrag:

Als ich mir die Beschreibung des "Neuen" Moduls D073 laden wollte
(den link hat mir Display3000 als Kunden geschickt) lese ich
(sinngemäß)folgendes:

Ein böser, böser Mensch (ts, ts, ts) hat den Link zum Datenblatt
veröffentlicht. Deshalb bekommt das Datenblatt nur, wer ein eMail an
Hr. Küsters schickt.

(sicherlich muss er vorher eine Geheimhaltungserklärung abgeben ...)


Ich habe nichts dagegen, wenn man mit seiner Arbeit Geld verdienen will
bzw. muss. Ich habe ja auch für das Modul bezahlt. Aber als
(potentieller) Kunde habe ich doch wohl das Recht, mir die Datenblätter
- NICHT DIE KONSTRUKTIONSUNTERLAGEN - an- bzw. einzusehen.

Meinungen  ??

Danke für die Antwort.

Ich sehe das genauso.

Werde also versuchen, aus meiner "Bibliothek" eine echte "Lib" zu
machen, dann handelt es sich um binar-Code und dem Willen von Herrn
Küsters ist genüge getan ...

"Also erst mal WinAVR - kostenlos, praktisch -> gut !
Dann hat mich der Code von Hagen R. (glcd11) (www dot apetech dot de)
zum Nachdenken angeregt...

Was dabei rausgekommen ist, ist eine neue (C-) Bibliothek, die alle
Funktionen der GLCD11 enthält. Ich hoffe Hagen R. hat nichts dagegen
:-)

Was ich aber nicht weiss, ist, wie sich Hr. Küsters zu einer
Veröffentlichung dieser Bibliothek verhält; in seinen FAQs kann man
folgendes lesen:"

Ich muß mich nun doch dazu äußern.

1.) wir stellen mal die Frage wie eigentlich eine solche GLCD fürs
Nokia  entstehen konnte. Die Antwort ist sehr einfach, einige Leute
haben das Nokia reverse engineered und dann herausgefunden welche
Kontroller benutzt wurden, dann aufwendig deren Datenblätter gesucht
und anschließend eine GLCD dafür programmiert. Ich persönlich bin zb.
erst zu einem Zeitpunkt dazu gestoßen als Ape schon längst eine Lib
programiert hatte. Entscheidend ist aber der Fakt das die Leute hier im
Forum hauptsächlich diese Informationen + Ansteuerung erarbeitet haben,
und allen interessieten Lesern auch frei zur Verfügung gestellt haben,
ohne Profit damit machen zu wollen.

Wichtig bei diesen Erläuterung ist aber der Punkt das erst viel später
die Angebote von Display3000 erschienen. Ich möchte hier keine
Unterstellungen machen aber Display3000 hat defakto die Ansteuerungen
die hier im Forum entwickelt wurden zu Geld gemacht. Das Recht dazu hat
jeder der clever genug ist, das ist meine Meinung.

Sehr interesant ist der Fakt das zb. einige der ScreenShots auf
Display3000 definitiv von Software stammt die mit meiner GLCD
entstanden sein müssen !! Denn soweit wie ich es weis unterstützt nur
meine Lib für das Nokia auch proportionale und mehrfarbige Fonts.

2.) wenn du eine neue Software Ansteuerung für eine Hardware
entwickelst was interressieren dich dann irgendwelche Lizensansprüche
des Hardware Herstellers ? Ich meine Display3000 hat keinerlei
juristische Möglichkeiten dir zu verbieten deinen Source zu
veröffentlichen. Display3000 hat keinerlei Rechte an deiner Software
und kann auch nicht irgendwelche Rechte nur auf Grund der gekauften
Hardware an deiner Software implizieren.

3.) da deine Lib auf einem OpenSource und freien Source basiert,
nämlich meiner Library, sieht es eher so aus das allerhöchsten Ape oder
ich, irgenwelche Urheberrechte haben könnten.

4.) ich kann einige EMails vorweisen in denen Käufer bei Display3000
mich fragten was sie denn an meiner GCLD anpassen müssten damit sie auf
deren Boards läuft. Ich fragte natürlich nach woher sie denn meine
Addresse hätten und sie von der GLCD wüsste. Die Antworten sind
ziemlich interessant verwiesen sie doch auf Display3000.

5.) Ich für meinen Teil bestehe darauf das du deine Software
veröffentlichst (ist aber deine Entscheidung ;) Denn du kannst damit
der Community auch was zurückgeben, die ja erst diese GLCD ermöglicht
hat. Gerade dieser Community Gedanke, der Gedanke nicht immer aus allem
Profit machen zu wollen, womöglich noch Ideen klauen, ist es gewesen
warum ich zb. meine GLCD sofort als OpenSource veröffentlicht habe.

Davon mal abgesehen gibts noch einige andere Portierungen der GLCD, zb.
eben auch fürs S65 Display.

Eines weis ich aber mit Gewissheit: sollte ich jemals nochmal so eine
GLCD coden dann wird sie wieder OpenSource sein aber dieses mal mit dem
Lizensvermerk das kommerzielle Wiederverkäufer einen Obolus an zb.
dieses Forum entrichten müssen ;)

Gruß Hagen

PS: ich habe eigentlich nichts dagegen das man Profit machen möchte und
als Nebeneffekt so auch ungeübte Bastler an preiswerte Boards rankommen.
Aber man sollte doch wenigstens auch die Urheber, die das nötige
Knownledge erarbeitet haben, erwähnen.
Suche einfach hier in der Codelib und du wirst sehr lange Threads
finden die diesen "Engineering-Prozess" der Leute hier wiedergeben.

Um das also mal klarer auszudrücken:

Die Ansteuerung des LCDs, das Knowhow wurde zuerst, nämlich mindestens
2 Jahre vor Display3000, hier in diesem Forum entwickelt !

Aber! da gibts ein klitzekleines Problem, denn im Grunde fällt die
Ansteuerungslogik der Nokia/Siemens Displays in den Rechtsbereich der
Hersteller dieser Displays, denn die zugehörigen Datenblätter zb vom
Display oder auch Handy (aus den Service-Datenblättern wurden nämlich
wichtige Informationen ermittelt) stehen nur unter NDA beim Hersteller
zur Verfügung. Wenn also irgendjemand Rechte daran hat dann die
Hersteller wie Nokia, Siemens usw.

Gruß Hagen

Also wenn man auf Wikipedia unter
http://de.wikipedia.org/wiki/Reverse_Engineering schaut findet man
folgendes:

Viele Firmen untersagen das Reverse Engineering ihrer Produkte durch
entsprechende Lizenzbedingungen. Die Analyse von Protokollen ist davon
rechtlich nicht betroffen, weil dabei die Software selbst gar nicht
Gegenstand der Untersuchung ist.

und

Benutzt man das Ergebnis des Reverse Engineerings zum gewerblichen
Nachbau, so wird man sich mit der großen Menge der gewerblichen
Schutzrechte (z. B. Plagiat) in ähnlicher Weise konfrontiert sehen, so
wie es auch bei Ergebnissen der ganz normalen eigenständigen Forschung
und Entwicklung der Fall sein kann (z. B. Patent).

Da hier im Prinzip auch nur ein Protokoll duch abhoeren und testen
untersucht wurde duerfte das(zumindest fuer nicht kommerzielle Zwecke)
legal sein.(Soweit der Wikipedia-Artikel korrekt ist)

Gruss Tobias

Um nochmal auf meine Frage (weiter oben) zurückzukommen. 49 Downloads
und keiner weis eine Antwort??

@SuperUser:
Also, das Problem an der ganzen Sache ist, daß ich bei meinem Interface
keine Spannungs-, sonder eine STROMQUELLE an die Hintergrundbelechtung
anschließe. Ich weis jetzt nicht genau ob die Hintergrundbeleuchtung
sofort leuchtet, wenn man da was anschließt, oder ob sie noch per
Software eingeschaltet werden muß. Wenn der zweite Fall vorliegt, habe
ich die Sorge, daß die Stromquelle eine unzulässig hohe Spannung am
Sisplay erzeugt, wenn intern der Trompfad der Hintergrundbeleuchtung
nicht durchgeschaltet ist.

Gruß

Danke; für den ersten Test will ich die Hintergrundbeleuchtung einfach
anlassen. Die Schaltung ist nur dafür gedacht, das Display
auszuprobieren.


Gruß

Mir ist bei 3,6V ein LS020.. in Popo gegangen, als ich es ein zweites
mal anschiessen wollte. Ob jetzt an der Spannung gelegen hat oder weil
die Folie kaputt gegangen ist. Kann ich nicht sagen.

@MC_bernd: gehts auch bei 3,3V mit deinen GLCD ?

Kann das sein ( hier beim LS020.. ) wenn die Hintergrundspannung für die
 LEDs so hoch ist das der Effekt der Spannungsabhänigen Verfärbung
auftritt? So sind die Spannungen bei mir im Bereich 2,9V für I/O bei
10V-11V Hintergrundspannung.

zu 13MHz: gar nicht, das SPI läuft dann mit 8MHz.

Was ist ein pn2? (neugestartet und es geht??)

lol
ich denke unten die ist auch recht schwer zu verstehen..

Der Takt ist nach untenhin sehr offen, bei SPI zumindest, bei einem 
RS232 Signal, hast du ja keine Taktleitung, und darum muss ein sehr 
genauer Takt eingehalten werden.

Bei SPI hast du eine eigene CLOCK Leitung, welche sagt, wann Daten 
geschrieben werden können bzw gelesen

Der Takt is bei dem Display uberhaupt kein Problem nach unten hin ^^ Ich 
hatte den  Takt vom STK500 ma auf 32kHz ... ist schon lustig zu sehen, 
wie sich die Pixel aufbauen :>

Hallo bwd,

du meinst vmtl. die Grösse des glcdlib.a files? Das ist noch lange nicht 
die Grösse des fertig gelinkten Codes. Compilier doch einfach mal das 
beiliegende test Program.

Weil die glcd in Assembler geschrieben ist, ist sie nämlich ziemlich 
klein....

@bwd:

werden nur Basisfunktionen der GLCD benutzt so benötigt sie maximal 800 
Bytes FLASH. Werden alle Funktionen benutzt, besonders Clipping etc. 
dann sind es 2800 Bytes Flash. Das gleiche in reinem WinAVR GCC C würde 
dann 4800 Bytes verbrauchen. Bedenkt man was die GLCD schon mit 800 
Bytes leistest -> Transparenz, Linien, Rechtecke, Füllungen, Mehrfarben 
und eben proportionale komprimierte Fonts, dann sind 800 Bytes wirklich 
nicht viel.

Wenn du weist das eine Bibliothek wie die GLCD eine echte 
Link-Bibliothek ist so wüsstest du auch das dadurch die binäre Größe der 
Linklib. stärker anwachsen muß als bei einer normalen Library. Das liegt 
eben daran das in diesem File noch viele zusätzliche Informationen 
gespeichert sein müssen damit später der Linker überhaupt in der Lage 
ist nicht benutzte Funktionen aus der Lib weg zu optimieren. Dh. der 
Linker linkt nur diejenigen Funktonen aus der GLCD in dein fertiges HEX 
die du in deinem Source benutzt hast. Das ist keineswegs eine Normalität 
wenn du 3'rd party Libraries benutzt.

Gruß Hagen

Mike Bird - läuft es bei dir mit BASCOM über Hard SPI ?
Wenn ja wie hast du das angestellt?

@  Mike Bird.

Ich bin gerade dabei sowas zu basteln, bin aber noch nicht ganz fertig. 
Jetzt fahr ich erst mal in den Urlaub. In 10 Tagen bin ich wieder da, 
dann werd ich weiter machen.

@ KennyOswald

könntest Du die Firmware für 18F4550 posten, ich bekomme das Display 
nicht initialisiert?

MfG Andi

@ Mike Bird: Gibts Fortschritte mit der Hard-SPI ?

@ Avr Nix:
Nein, leider noch nicht, da ich momentan viel auf Achse bin, komme ich 
zur Zeit doch nicht dazu.
Da bei mir das Display-Timing in dem Projekt nicht so extrem wichtig 
ist, sind natuerlich auch erstmal andere Prioritaeten gesetzt. 
(Ablaufsteuerung)
Trotzdem reizt es mich natuerlich auch fuer zukuenftige Projekte, das 
Timing zu optimieren, um Ressourcen fuer andere Dinge freizuhalten.
Also denke ich mal, dass ich in meinem Urlaub, in 3 Wochen, spaetestens 
dazu kommen werde, mich weiter dem Teilchen zu widmen.
Denn momentan laeuft es nur als Farbige Analoguhr, und schaut zumindest 
schonmal gut aus (wenn auch voellig Sinnlos...lol).
Halt ein Abfallprodukt der Routinenschreiberei :o)

Gruss Mike

Hallo,

mich liess momentan das Problem der Konvertierung keine Ruhe, auch wenn 
ich heut wieder Frueh raus muss....*grummel*
Bin dann erst am Freitag (Nachts) wieder da.
Habe also kurz mal nen BMP 24Bit zu RGB565 Exporter geschrieben,
moechte ihn aber noch nicht veroeffentlichen....kommt am Wochenende !
Nun habe ich nur das Problem, dass Bascom es wohl irgendwie nicht auf 
die Reihe bekommt, groessere Datenmengen per Restore / Read, 
nacheinander zu lesen. Irgendwie ueberschlaegt sich da wohl ein Pointer.

Das angehaengte File ist ein Testfile, welches ich mit dem Exporter 
erstellt habe. Die ersten beiden Daten sind die Bildgroesse (x,y),
dann folgen die Farbdaten, sequentiell.

Habe versucht das Bild mit folgender Routine darzustellen, aber nach ci 
20% kommt nur noch Muell an. Vielleicht kann sich da ja jemand die Tage 
dran versuchen?

Folgende Routine nutzte ich als Darstellungsroutine:

Restore Bildname
Read X
Read Y
X = X - 1
Y = Y - 1
For Y1 = 0 To Y
For X1 = 0 To X
Read Z
Gosub Lcd_pset '(Subroutine setzt einen Pixel an X1,Y1 mit der Farbe Z)
Next X1
Next Y1

Gruss Mike

@Mike

Einige Bascom Versionen haben wohl einen Bug, was große Bereiche mit
DATA Zeilen angeht.
Es hilft, wenn man ca. alle 3 KB eine leere Sprungmarke einfügt

DATA xx,xx,xx,xx
marke1:
DATA xx,xx,xx,xx

Ich kann aber im Moment nicht testen obs hilft.

Gruss,
Ralf

Sodele..

@Keine Ahnung:
Mail mir einfach! Oder registriere hier im Forum.

@Ralf: Vielen lieben Dank, der Tipp von Dir mit den Einsprungmarken hat 
funktioniert. Habe es auch gleich letzte Nacht in mein BMP2DATA 
converter mit eingebaut. (setzt alle 3kb eine blinde Einsprungsmarke mit 
einem aus Uhrzeit, Datum und einem Zaehler, gewonnenen Namen. Somit 
schliesse ich irgendwelche doppelten Marken nahezu aus)

Und nun an alle, die Interesse an dem Konverter Tool haben:
Ich haette dies ja gerne hier mit angehaengt, nur irgendwie funktioniert 
es nicht. Daher mailt mir bitte, wenn Ihr dies Tool haben wollt,
ich maile es dann so schnell es geht zu.

Momentan kann es nur .BMP Dateien mit 24Bit konvertieren, da ich noch 
keine Palettenbehandlung implementiert habe. Es sollte aber kein Problem 
darstellen, ein 8Bit .BMP zuvor mit z.Bsp. Paint, als 24Bit umzuwandeln, 
und dann mit dem Tool umrechnen zu lassen.

Das Tool kann ueberall hinkopiert werden, es benoetigt keine 
Registrierung, oder Installation.
Nach dem Start waehlt man das File, welches man konvertieren moechte, 
mit den Cursortasten aus und mit Enter wird dann die Konvertierung in 
ein Textfile mit dem Namen des Quellfiles +.txt Endung im selben 
Verzeichnis der Quelle, durchgefuehrt.

Man braucht dann nur noch den Inhalt des Textfiles ins Bascom File zu 
kopieren, die Einsprungsmarke am Anfang auf den gewuenschten Namen 
umzuaendern, und das wars.

Bitte Mailt mir, wenn Ihr noch Aenderungsvorschlaege habt, oder Fehler 
findet. (ist eh noch nicht ganz fertig)

Viel Spass beim Experimentieren!

Gruss Mike

Hier noch mal ein kleines Bildchen von meinem "Abfallprodukt" in 
Funktion.
Nun auch mit "Kaffee" als Hintergrund :o)

Auszug aus Language fundamentals:

The index must be a numeric constant, a byte, an integer, word or long.
The maximum number of elements is 65535.
The first element of an array is always one. This means that elements 
are 1-based.

Oh, ich dachte du nutzt immer noch (?) Bascom. Sorry.

Beste Gruesse

Hier nochmal etwas zu meinem Bitmap Converter (ehemals BMP2DATA).

Dieser kann nun dank AVRNix auf seinem Board heruntergeladen werden 
(falls der Anhang hier mal wieder nicht klappen sollte).
http://www.comwebnet.de/zip-dateien/Bascom_Picture_Converter11a.rar

Momentan ist er so optimiert, dass auch mit aelteren Bascom-Versionen,
die Bilder nahezu problemlos dargestellt werden koennen.
Daher befinden sich in den Ausgabe-Dateien, alle 3kb eine 
Ghost-Einsprungsmarke, da sonst die aelteren Bascom-Versionen nicht in 
der Lage sind, solch Datenmengen per Read, am Stueck zu lesen.

Bei Fragen und Verbesserungsvorschlaegen zu dem Tool, mailt mir bitte!!

Gruss Mike

Hallo allerseits!

Ich habe nochmal eine Frage zum Beispielprogramm. Wenn ich das Programm 
mit dem mitgeliefertem Makefile compiliere, dann wird noch ein 
EEpromfile erzeugt. Wenn ich dieses File mit AVR-Studio programmieren 
möchte, dann bekomme ich eine Fehlermeldung. Allerdings funktioniert das 
Programm auch ohne das EEpromfile. Irgendwie habe ich sowieso 
festgestellt, daß bei meinem AVR-Studio das EEprom nur mit Hex-files 
gefüttert werden kann; Eep-Files haben eine Fehlermeldung zur Folge. Ich 
hoffe, daß mir jemand weiterhelfen kann.

Gruß

Hallo miteinander,

ich habe mir einen kleinen Bitmapkonverter programmiert.
er wandelt ein 24bit Bitmap in ein 16bit Bitmap (5-6-5) passend fürs
Display um. Bei mir funktionierts bestens wobei ich Fehler nicht
ausschließen will.
als Zieldatei wird die Datei S65.h erzeugt welche für die Einbindung in
Assembler-Quellcode formatiert ist.
viel Spaß damit

Mfg Steff

Hallo Patrick,

hast du den kompletten Dateinamen also inclusive der Endung .bmp 
eingegeben?

MfG Steff

Hallo Steff,

ich habe mir kurz mal ein Resultat von Deinem Konverter angesehen.
In welcher Reihenfolge sind die Werte ?
ist der erste Wert das High-Byte oder Low-Byte?
Wuerde sonst die Ausgabemoeglichkeit auch in meinen Konverter mit 
einbauen, somit waere es dann fuer Bascom und Assembler nuetzlich.
Und welche Direction hast Du ? Erster Wert oben links ?
Ich weiss, ich koennte auch ein paar Testbilder durchlaufen lassen und 
vergleichen, aber momentan fehlt ein wenig die Zeit dazu.
Nur die Aenderung des Ausgabeformates ist kein Beinbruch in meinem 
Proggy.
Wollte eh noch ein Down-Scale, sowie BMP Konvertierung mit 
Farbpalettenauswertung einbinden (dann muessen es keine 24Bit BMP mehr 
sein)

Gruss Mike

Hallo Mike,

also erster Wert ist der oben links
und es wird wie du schon vermutet hast zuerst das High-Byte geschrieben.
es wär natürlich eine klasse Sache wenn du so ein all in one Programm 
bereitstellen würdest also mach dich ran.

MfG Steff

hmmm email ohne adresse super idee :P naja pn tuts ja auch ;)

Hallo,

etwas neues zur Adressierung des LS020 Display RAMs:

http://www.superkranz.de/christian/S65_Display/DisplayRamAccess.html

@Christian K.
Danke für die neuen infos.

@ALL
Das PDF-Update ist natürlich auch schon fertig.


~ gruß Lightning

Hallo,
welche Funktionalität bräuchtest du denn?
evtl. kann ich dir ja weiterhelfen.
MfG Steff

Hallo Lötnix,

momentan kannst Du Dir ja damit weiterhelfen, indem Du mit sonstigen
Gfx-Proggys vorweg Dein Bild in ein 24Bit Bitmap umwandelst.
Da ich in den letzten Wochen leider noch nicht weiter dazu gekommen bin, 
an meinem Converter herumzubasteln, ist noch keine neue Version mit 
Assembler konformen Ausgaben verfuegbar.
Ich hatte allerdings in einer nicht veroeffentlichen Version schon 
einmal ein wenig mit RLE Kompressionen herumprobiert, da ich aber 
hauptsaechlich die Ausgaben fuer Bascom Programme verwende, ist die 
Decompression dabei doch sehr zeitraubend. Werde dies aber dann doch 
nochmal mit implementieren.
Die Einbindung der Konvertierung von "nicht 24-Bit bmp" ist schon etwas 
Umfangreicher, da hierbei mit Farbpaletten gearbeitet wird und nicht mit 
direkten Farbanteilen fuer jedes Pixel.
Daher war die Funktionalitaet erstmal nur auf das Minimum begrenzt,
also die Konvertierung verschieden grosser (max. 176x132) 24Bit Bitmaps 
in ein Data-Format, welches sich ohne Probleme im Bascom verarbeiten 
liess.

Also sobald ich wieder ein wenig Zeit habe, werden Stueck fuer Stueck 
folgende Funktionen mit eingebaut: (nach Prioritaet absteigend)
-Assembler-Quellcode konforme Ausgabe waehlbar
-bmp Konvertierung von nicht 24Bit Dateien
-RLE Kompression waehlbar
-Up/Downscale der Bildgroesse

Die Versionen werden dann wieder hier, sowie auf den Seiten von AVRNix 
zur Verfuegung stehen.

Ein vorweihnachtlicher Gruss aus dem hohen Norden
Mike

Anbei eine Beta meines Konverters.

Vorerst müsste das Exportieren in das RAW Format ausreichend sein. Dazu 
einfach die Checkbox "RAM Data" anhacken und es wird eine C Header Datei 
gespeichert in der die Pixel mit 16Bit Farbwerten codiert sind.

Für die anderen 3 Datenformate die ich verwende kann ich noch 
Erklärungen und Beispielcode in C nachliefern, wenn gewünscht. Vorerst 
nur mal par Stichpunkte was drinnen ist:

- 1 Farb Bitmaps, das sind nichts anderes als mit einer Farbe 
ausgefüllte Rechtecke, quasi leere Bitmaps mit einer Hintergrundfarbe

- 16 Bit Bitmaps, das sind unkomprimierte Bitmaps in voller Farbe, 
meistens weil eine Komprimierung nichts bringt

- Monochrome Bitmaps (2 Farben) mit Komprimierung. Die Daten sind per 
RLE komprimiert und man erreicht ca. 2000-3000% Packungsrate im 
Vergleich zu RAW

- 2 Bit bis 15 Bit Farbbitmaps, also von 3 Farben bis 32765 Farben. Die 
Daten sind komprimiert und benutzen eine Farbtabelle. Die 
Komprimierungsrate ist fast immer besser als bei PNG Bildern. Wichtig 
ist das man nur durchschnittlich 16 AVR Takte pro Datenbyte in den 
Zeichenroutinen benötigt für diese Dekomprimierung. Man erreicht also 
defakto den maximalen Datendurchsatz bei 8Mhz SPI auf einem 16Mhz AVR, 
direkt aus dem FLASH ohne zusätzlichen SRAM zu verbrauchen.


Die Software selber kann
- PNG, BMP, WMF, EMF, ICO, JPEG laden
- in beliebigem Farbformat
- in beliebiger Größe
- das Bild wird runter skaliert auf maximal 176x132 Pixeln wenn nötig, 
Seitenverhältnis wird beibehalten
- die Farbpalette/-anzahl kann reduziert werden
- das Bild kann in 90 Gradschritte rotiert, und gespiegelt werden


Gruß Hagen

Ausschnitt meines bisherigen Codes für meine S65-GLCD des LPH88xxx 
Display (Philips HD66773R Controller).

1

#include "glcd.h"

2

3

uint16_t colormasks[14] PROGMEM = {0x0006, 0x000E, 0x001E, 0x003E, 0x007E, 0x00FE, 0x01FE, 0x03FE, 0x07FE, 0x0FFE, 0x1FFE, 0x3FFE, 0x7FFE, 0xFFFE};

4

5

void glcdDrawBitmap(glcdCoord_t x, glcdCoord_t y, const prog_char* bitmap, uint8_t flags) {

6

7

8

#define GLCD_LOAD_BITS(data0, data2, databits, addr, bitsmul) \

9

   asm volatile(                            \

10

    "cpi   %2, lo8(16)"         "\n\t"  \

11

        "brsh  .%=2"                "\n\t"  \

12

        "movw  r30, %A3"            "\n\t"  \

13

        "lpm   r0, Z+"              "\n\t"  \

14

        "mul   r0, %4"              "\n\t"  \

15

        "cpi   %2, lo8(8)"          "\n\t"  \

16

        "brsh  .%=1"                "\n\t"  \

17

        "or    %A0, r0"             "\n\t"  \

18

        "or    %B0, r1"             "\n\t"  \

19

        "subi  %2, lo8(-(8))"       "\n\t"  \

20

        "lpm   r0, Z+"              "\n\t"  \

21

        "mul   r0, %4"              "\n\t"  \

22

".%=1:"                             "\n\t"  \

23

        "or    %B0, r0"             "\n\t"  \

24

        "or    %1, r1"              "\n\t"  \

25

        "subi  %2, lo8(-(8))"       "\n\t"  \

26

        "movw  %A3, r30"            "\n\t"  \

27

".%=2:"                             "\n\t"  \

28

        "clr   r1"                  "\n\t"  \

29

      : "=r" (data0),                     \

30

        "=r" (data2),                     \

31

        "=a" (databits),                  \

32

        "=r" (addr),                      \

33

        "=r" (bitsmul)                    \

34

      : "r" (data0),                      \

35

        "r" (data2),                      \

36

        "a" (databits),                   \

37

        "r" (addr),                       \

38

        "r" (bitsmul)                     \

39

        : "r0", "r1", "r30", "r31"          \

40

     );

41

42

#define GLCD_LOAD_COLOR(data0, data2, databits, colortable, colormask, bpp, bitsmul, bkcolor) \

43

   asm volatile(                            \

44

        "movw  r30, %A0"            "\n\t"  \

45

        "lsr   %1"                  "\n\t"  \

46

        "ror   %B0"                 "\n\t"  \

47

        "ror   %A0"                 "\n\t"  \

48

        "brcs  .%=0"                "\n\t"  \

49

        "dec   %2"                  "\n\t"  \

50

        "lsr   %6"                  "\n\t"  \

51

        "brne  .%=3"                "\n\t"  \

52

        "ori   %6, lo8(0x80)"       "\n\t"  \

53

        "rjmp  .%=3"                "\n\t"  \

54

".%=0:"                             "\n\t"  \

55

        "and   r30, %A4"            "\n\t"  \

56

        "and   r31, %B4"            "\n\t"  \

57

        "add   r30, %A3"            "\n\t"  \

58

        "adc   r31, %B3"            "\n\t"  \

59

        "lpm   %A7, Z+"             "\n\t"  \

60

        "lpm   %B7, Z"              "\n\t"  \

61

        "mov   r30, %5"             "\n\t"  \

62

        "cpi   r30, lo8(8)"         "\n\t"  \

63

        "brlo  .%=1"                "\n\t"  \

64

        "mov   %A0, %B0"            "\n\t"  \

65

        "mov   %B0, %1"             "\n\t"  \

66

        "clr   %1"                  "\n\t"  \

67

        "andi  r30, lo8(0x07)"      "\n\t"  \

68

        "breq  .%=2"                "\n\t"  \

69

".%=1:"                             "\n\t"  \

70

        "lsr   %1"                  "\n\t"  \

71

        "ror   %B0"                 "\n\t"  \

72

        "ror   %A0"                 "\n\t"  \

73

        "dec   r30"                 "\n\t"  \

74

        "brne  .%=1"                "\n\t"  \

75

".%=2:"                             "\n\t"  \

76

        "sub   %2, %5"              "\n\t"  \

77

        "dec   %2"                  "\n\t"  \

78

        "mov   r30, %2"             "\n\t"  \

79

        "andi  r30, lo8(0x07)"      "\n\t"  \

80

        "clr   r31"                 "\n\t"  \

81

        "subi  r30, lo8(-(powerof2))"   "\n\t"  \

82

        "sbci  r31, hi8(-(powerof2))"   "\n\t"  \

83

        "lpm   %6, Z"               "\n\t"  \

84

".%=3:"                             "\n\t"  \

85

      : "=r" (data0),                     \

86

        "=r" (data2),                     \

87

        "=a" (databits),                  \

88

        "=r" (colortable),                \

89

        "=r" (colormask),                 \

90

        "=r" (bpp),                       \

91

        "=r" (bitsmul),                   \

92

        "=r" (bkcolor)                    \

93

      : "r" (data0),                      \

94

        "r" (data2),                      \

95

        "a" (databits),                   \

96

        "r" (colortable),                 \

97

        "r" (colormask),                  \

98

        "r" (bpp),                        \

99

        "r" (bitsmul),                    \

100

        "r" (bkcolor)                     \

101

        : "r30", "r31"                      \

102

     );

103

104

105

    if (!(bitmap)) return;

106

    uint8_t w = pgm_read_byte_inc(bitmap);

107

    if (!(w)) return;

108

    uint8_t h = pgm_read_byte_inc(bitmap);

109

    if (!(h)) return;

110

    uint8_t bpp = pgm_read_byte_inc(bitmap);

111

    uint16_t bkcolor = pgm_read_word_inc(bitmap);

112

    if (flags & GLCD_BMP_USECOLORS) bkcolor = glcd.Colors[0];

113

    if (bpp == 0) {

114

      glcdFillRect(x, y, x + w -1, y + h -1, bkcolor);

115

      return;

116

    }

117

    GLCD_CS_ON();

118

    GLCD_SETADDR(x, y);

119

    GLCD_WINDOW(x, y, x + w -1, y + h -1);

120

    if (flags & GLCD_BMP_TRANSPARENT) {

121

      GLCD_SETMODE(0x38 | GLCD_ROP_WNE);

122

      GLCD_SETCOMPARE(bkcolor);

123

    } else {

124

      GLCD_SETMODE(0x38);

125

    }

126

    GLCD_STARTDATA();

127

    if (bpp == 1) {// monochrome

128

      uint16_t pixelcount = w * h;

129

      uint16_t fgcolor = pgm_read_word_inc(bitmap);

130

      if (flags & GLCD_BMP_USECOLORS) fgcolor = glcd.Colors[1];

131

      uint16_t color = bkcolor;

132

      if (flags & GLCD_BMP_SWAPCOLORS) {

133

        bkcolor = fgcolor;

134

        fgcolor = color;

135

        color   = bkcolor;

136

      }

137

      uint8_t data = pgm_read_byte_inc(bitmap);

138

      uint8_t pixelbits = ((data >> 4) +1) << 2;

139

      data &= 0x0F;

140

      uint8_t temp = data << 4;

141

      data |= temp;

142

      do {

143

        GLCD_WAIT();

144

        GLCD_OUT(H8(color));

145

        if (!(--pixelbits)) {

146

          data = pgm_read_byte_inc(bitmap);

147

          pixelbits = ((data >> 4) +1) << 2;

148

          data &= 0x0F;

149

          uint8_t temp = data << 4;

150

          data |= temp;

151

        }

152

        GLCD_WAIT();

153

        GLCD_OUT(L8(color));

154

        ROL(data);                                // rotate data, data = (data << 1) | (data >> 7);

155

        color = bkcolor;

156

        if (data & 0x01) color = fgcolor;

157

      } while (--pixelcount);

158

    } else if (bpp == 16) { // full color

159

      uint16_t pixelcount = w * h;

160

      while (pixelcount) {

161

        GLCD_WAIT();

162

        GLCD_OUT(H8(bkcolor));

163

        pixelcount--;

164

        GLCD_WAIT();

165

        GLCD_OUT(L8(bkcolor));

166

        bkcolor = pgm_read_word_inc(bitmap);

167

      }

168

    } else {// color, 2 upto 15 BPP

169

      uint16_t colortablesize = pgm_read_word_inc(bitmap);

170

      uint8_t* colortable = (uint8_t*)bitmap;

171

      bitmap += colortablesize;

172

      uint16_t colormask = pgm_read_word(&colormasks[bpp -2]);

173

      uint8_t databits = 0, data2 = 0, bitsmul = 1;

174

      uint16_t data0 = 0;

175

//      uint32_t data = 0;

176

      uint16_t pixelcount = w * h;

177

      do {

178

        GLCD_WAIT();

179

        GLCD_OUT(H8(bkcolor));

180

        pixelcount--;

181

        GLCD_LOAD_BITS(data0, data2, databits, bitmap, bitsmul);

182

183

//        while (databits < 16) {

184

//          uint16_t t = pgm_read_byte_inc(bitmap) * bitsmul;

185

//          if (databits >= 8) data |= (uint32_t)t << 8;

186

//            else data |= t;

187

//          databits += 8;

188

//        }

189

190

        GLCD_WAIT();

191

        GLCD_OUT(L8(bkcolor));

192

193

        GLCD_LOAD_COLOR(data0, data2, databits, colortable, colormask, bpp, bitsmul, bkcolor);

194

195

//        if (LL8(data) & 0x01) {

196

//          bkcolor = pgm_read_word(colortable + (L16(data) & colormask));

197

//          data >>= bpp;

198

//          databits -= bpp;

199

//          bitsmul = pgm_read_byte(&powerof2[databits & 0x07]);

200

//        }

201

//        bitsmul >>= 1;

202

//        if (!(bitsmul)) bitsmul |= 0x80;

203

//        data >>= 1;

204

//        databits--;

205

      } while (pixelcount);

206

    }

207

    GLCD_WAIT();

208

    GLCD_CS_PULSE();

209

    GLCD_SETMODE(0x30);

210

    GLCD_CS_OFF();

211

}

Hello,

i've tried to connect my l2f50...  to PIC 18f2550(18f4550) from 
Microchip (using sources from Mark de Jong), but my display is silent.
Can somebody consult me about connection and sources?

I uses 3.0 power supply for both (cpu and display) units, without 
resistors and diodes (direct connection)


PS: to power the backlight I uses the MAX232 chip, powered by 5 volt - 
the output to rsr232 line lets 9.4 volts. It is enought to switch on the 
led.

Hallo,

nun doch noch in diesem Jahr bin ich dazu gekommen,
mich ein wenig weiter mit meinem Konverter zu beschaeftigen.
Sprich, ich hab mal wieder die letzte Nacht zum Tag gemacht.

Folgende Aenderungen sind nun im Tool vorgenommen worden:
- Etliche Bugs im Filebrowser behoben
- Dabei auch ein wenig an der Optik und Struktur gefeilt
- als Ausgabeformat fuer Bascom unterstuetzt er nun:
  1. Bascom 16Bit Raw Data (wie zuvor auch)
  2. Bascom 8Bit Raw Data (direkte Ausgabe HiByte/LoByte)
  3. Bascom 8Bit RLE Data (wie oben, nur mit einfacher RLE Compression)
  Alle 3 Formate erhalten einen anderen Ausgabenamen,
  daher auch ist es auch Problemlos moeglich, nacheinander
  alle 3 Codierungen durchlaufen zu lassen, und zu vergleichen.
  (Eben halt ob die RLE Kompression in dem jeweiligen Fall etwas bringt)
  Zudem wird auch nach der Konvertierung die Anzahl der benoetigten
  Data Bytes angezeigt.

Die Assembler Source Ausgabe ist gerade in Arbeit, und wird vielleicht
schon morgen als Version 1.6 hier zu finden sein.

Wer Verbesserungsvorschlaege hat, bitte mailt mir (PN) oder einfach hier 
ins Board schreiben.

Bis dahin erstmal liebe Gruesse aus dem hohen Norden
Mike

Tja, manchmal gehts schneller als man denkt.....
Schiebe hier nochmal schnell die Version 1.6 nach.
Hab kurz die Assembler Hex Sourcecode Ausgabe mit eingebunden.

Achja, der Name des Tools hat sich noch geringfuegig geaendert,
da es ja nun nicht mehr fuer Bascom alleine da ist.

Viel Spass damit

Gruss Mike

Hello, Mark,

> Here is the latest library, perhaps there where some errors in the other
> library.
> This one is test and work with my target (C164, C165 and C167)

Thank You, very much.

But I've still having problem - nothing appears on screen.

When I tries to remove cpu from slot, the "garbage" is appears on the 
display or, (offtenly) display becomes black; but when I drops CPU back 
and switch on the device - screen keeps white. After InitDisplay the 
FillScreen (with RED color) calls, but nothing happens.

Can You, please, help me to understand the problem?
May be, i have not L2F50? (but it seems like L2F50 from Kranz site).

@Kay,

das sollte doch eigentlich einleuchtend sein.
Nochmals anhand der alten Routine, wenn Dein Bild Beispielsweise 96x32 
gross ist:
------------------------------------------------------------------------ 
--
X2= 40            <- Hier kannst Du Deine horizontale Verschiebung 
angeben
Y2= 30            <- Hier kannst Du Deine vertikale Verschiebung angeben

Restore Bildname
Read X            <- liest hierbei 96, als Bildbreite
Read Y            <- liest hierbei 32, als Bildhoehe
X = X - 1         <- korrigiert X um -1 da 0-95 = 96 Bildpunkte ergibt
Y = Y - 1         <- korrigiert Y um -1 da 0-31 = 32 Bildpunkte ergibt

For Y1 = Y2 To Y+Y2   <- wuerde dann bedeuten Y1 zaehlt von 30 bis 61
For X1 = X2 To X+X2   <- wuerde dann bedeuten X1 zaehlt von 40 bis 135
Read Z

Gosub Lcd_pset '(Subroutine setzt einen Pixel an X1,Y1 mit der Farbe Z)

Next X1
Next Y1
------------------------------------------------------------------------ 
--
Nun setzt er Dir Deine Bildpixel an zwischen 40,30 (x,y) und 135,61.

Du solltest Dich vielleicht erstmal ein wenig mit Basic vertraut machen, 
und Dich fragen, was wohl in den jeweiligen Zeilen passiert.
Probiere es einfach aus, veraendere Variablen oder schaue in die Hilfe 
vom Bascom.
Nur so kann man als Anfaenger verstehen, was man eigentlich macht.
Auch wenn fuer Dich dann zu Anfang die Programme mehr einer "Was 
Passiert Dann ?" Maschine gleicht.
Anders habe ich damals (1981) mit meinem ZX81 auch nicht dessen Basic 
gelernt.

Liebe Gruesse
Mike

P.S.: wenn Du Dich hier anmeldest, kannst Du mich auch gerne per PM 
kontaktieren.

@Kay
Meld Dich doch kurz hier an, dann brauchen wir nicht das Forum 
dichtzuschreiben (PN / E-Mail)

Gruss Mike

Hello everybody,

in attachment You can see the datasheet for mysterious L2F50.

I hope, it can be helpful.

PS: unfortunately, this is draft, but man who hat sent me this file says 
that all commands are correct.