mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Pac Man mit dem ATmega8


Autor: kryon2000 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Da mein Testbild ect. nun funzt, dachte ich mir das man nun auch mal ein
Spiel entwickeln könnte. Immerhin muss man dies blöde Pong mit dem
scheiss PIC ja endlich mal zeigen wo der Hammer hängt :-)


http://mitglied.lycos.de/polyxos/tv12.jpg
http://mitglied.lycos.de/polyxos/tv13.jpg

Autor: Andi K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi!

Habe Deinen Thread und auch den externen beobachtet und Du hast das
Testbild im Main-Prog mit Warteschleifen gemacht!
Meinen gehörigen Respeckt dafür aber hast Du das mittlerweile per
Timer-Interrupt umgestellt?
Das würde die "Einbindung" des Spieles in das Programm vereinfachen
da ja schon ein paar Dinge wie Figurensteuerung, Tastenabfrage,
Kollisionstest (Figurpositionen) etc. noch hinzukommen.
Hatte einen anderen Thread mit nen Mega32 gesehen wo die TV-Ausgabe
über den Timer-ISR funxionierte.

MfG
Andi

Autor: kryon2000 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das mit dem Timer kann man wohl vergessen, da man die Unterroutinen
nicht exakt bestimmen kann und der Timer gnadenlos zuschlagen könnte.
Desweiteren wüsst ich nicht wozu der Timer da sein sollte (Hsync) ?

Ich mach es einfach so, Ich habe für alles kleine Unterroutinen
geschrieben welche in einem Hauptfenster aufgerufen werden können. Also
308 Zeilen.ich habe pro Zeile sogesehen immer 824 Takte zur freien
verfügung.

Also mach ich in Zeilen wo nichts kommt einfach meine Unterroutinen
rein. Z.B. Steuerung, Punktewertung, Kollesionsabfrage ect.... Durch
verzerrungen im Bild sehe ich dann schon ob die Routinen perfekt getimt
sind.

Wenn jetzt der Hsync vom Timer kommen würde, wüsst ich ja nie ob eine
Unterroutine wirklich schon abgearbeitet wurde ect. Und ein teiler bei
16MHz zu finden für 52µs ist glaube ich nicht möglich....

Autor: Andi K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dann benutze doch einen anderen Quarz wie z. B. 18,irgendwas.
Irgend einer müßte doch zu finden sein.
Vom Ablauf her dachte ich an Main-Prog mit dem Spiel und abfrage von
V-Sync für das "Neuzeichnen" der Ausgabegrafik etc.
Die Timer-ISR soll dann immer eine ganze Grafikzeile ausgeben (mittels
Zeilenzähler) und wenn die Zeile ausgegeben ist, den Strahl auf 0
stellen und dann raus aus dem Timer.
In dieser Dunkelphase läuft das Main-Prog weiter und kann dann
verschiedene Berechnungen machen.
In 820 Takten je Zeile läßt sich ja einiges machen.
Das interne V-Sync kann die Timer-ISR liefern wenn die letzte Zeile
ausgegeben wurde.
Das Main-Prog erzeugt die Grafik im internen SRAM des AVR (Mega32 mit
2KB) wobei die Auflösung leider nicht sehr hoch sein kann (128x96, 1
Bit).
Man kann ja noch externen SRAM anbinden und vielleicht in Farbe
senden.

MfG
Andi

Autor: kryon2000 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Na wenn ich nur die Dunkelphase nutzen soll für das Hauptprogramm,
bleibt ja gar nichts mehr über. Da nutze ich doch lieber komplette
Dunkelzeilen um meine Routinen da unter zu bekommen. Zumal es dann
schön nach einem Baukastenprinzip aufgebaut ist und man die Module
wechseln kann ohne probleme.

Autor: Andi K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das habe ich doch beschrieben.
Jedes mal, nach dem eine Zeile im Timer ausgegeben wurde, kann das
Main-Prog weiter arbeiten.
Also nicht nur im V-Sync.
Mit einem internen V-Sync nach Ausgabe der letzten Zeile läßt sich vom
Main feststellen, wann das neue Bild (1/50el) beginnt und die Grafik im
SRAM neu setzen, oder nur Teilbereiche.
Die Zeilenausgabe ist doch sehr Zeitkritisch und mit nen Timer wird
sichergestellt, das jede Zeile im richtigen Moment ausgegeben wird.
Im Main-Prog kann dann sein was will und man braucht keine Takte im
Main abzuzählen.
Es sollte ja nur ein Wink sein um es geschickter zu machen.

MfG
Andi

Autor: kryon2000 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gibts da schon realiesierte Projekte ?

Link ?

Autor: Andi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ist das Problem des IRQs nicht das, dass er unterschiedlich lang
braucht, um aufgerufen zu werden? Abhängig vom gerade bearbeiteten
Befehl?

Autor: Andi K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@kryon2000: Ja, es gibt schon was reallisiertes.
Habe hier vor Monaten mal was gesehen, such mal nach mega32 und TV oder
so was.

@Andi: Klar, wenn der Timer bei einen Befehl mit 2 Takten nach dem 1.
Tackt kommt verschiebt es das natürlich bei 16MHz um 0,062µS. Ob das
was aus macht, weis ich nicht, denke aber nicht.

MfG
Andi

Autor: kryon2000 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also alle Links die ich bis jetzt dazu gesehen habe waren eher
lächerlich. Die kamen nie auf die Grafikpower die dieses Projekt
besitzt. Aber wenn es doch was dazu gibt bin ich für jeden Link
dankbar.....


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Klar, wenn der Timer bei einen Befehl mit 2 Takten nach dem 1.
Tackt kommt verschiebt es das natürlich bei 16MHz um 0,062µS. Ob das
was aus macht, weis ich nicht, denke aber nicht.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Oha.....hast du eine Ahnung was selbst 1 Takt für eine Auswirkung hat.

siehe hier:

http://mitglied.lycos.de/polyxos/tv2.jpg

Das sollten normal nur rechtecke sein, ein Takt verkehrt und das kommt
dabei raus ;)

Autor: kryon2000 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
PS:

Also die hauptroutine bei mein Pacman sieht z.Z. so aus:

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
video:

vid2:
;----start Videosignalerzeugung------------------------------------
  rcall  vsync

  ldi    r18, 0x8a           ;416 takte ( halbe Zeile)
sh21:  dec    r18
  brne   sh21
  nop
  nop
  rcall  hsync
;-------------------------------------------------------






;------------  Bildaufbau ------------------------------
  ldi  r17, 0x03
pau1:  dec  r17
  brne  pau1
  ldi  r18, 0x30
  rcall  linecl

  nop
  nop
  nop
  rcall  pacman

  nop  ;-------------------------- 0x12
  ldi  YH, High(logo * 2)
  ldi  YL, LOW(logo * 2)
  rcall    textfeld


  nop
  nop
  ldi  r18, 0x0e
  rcall  linecl

  nop
  ldi  YH, 0x04
  ldi  YL, 0x00
  rcall  ghost

  nop
  ldi  YH, 0x04
  ldi  YL, 0x08
  rcall  ghost

  nop
  ldi  YH, 0x04
  ldi  YL, 0x10
  rcall  ghost

  nop
  ldi  YH, 0x04
  ldi  YL, 0x18
  rcall  ghost

  nop  ;-------------------------- 0x80
  ldi  YH, 0x02
  ldi  YL, 0x00
  rcall    spielfeld

  nop
  nop
  ldi  r18, 0x10
  rcall  linecl

  nop  ;-------------------------- 0xb
  ldi  YH, 0x00
  ldi  YL, 0x60
  rcall    ktextfeld

  nop
  nop
  ldi  r18, 0x4
  rcall  linecl

  nop
  nop
  nop
  rcall  time

  nop  ;-------------------------- 0xb
  ldi  YH, 0x00
  ldi  YL, 0x80
  rcall    ktextfeld

  nop
  nop
  ldi  r18, 0x35
  rcall  linecl

  rjmp  video
;-------------------------------------------------------



~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


Also schön in seine Module aufgeteilt.

linecl = leere zeilen (r18=anzahl)

ktextfeld = Ausgabe einer 32 Zeichen Zeile YH YL = adresse im RAM

textfeld = Ausgabe einer 32 Zeichen doppelte höhe Zeile YH YL = adresse
im Flash

spielfeld = Ausgabe des 128x128 pixel Spielfeldes

ghost = Bewegung des geistes YH YL = Speicher der Koordinaten der
geister

pacman = abfrage der steuerung und setzen von Pacman

Autor: Andi K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Na ja, läßt sich theoretisch geschickt per Software ausgleichen in dem
man in der Timer-ISR vor Ausgabe einer Zeile den Timer-Wert ausliest.
Z. B. wenn der Timer mit dem µC-Takt mit läuft den Timer auf
verschiedene Werte prüfen und, im Sinne der max.
Timer-Aufruf-Verzögerung, je nach Timer-Wert 1, 2 NOP´s einfügen oder
keins.

MfG
Andi

Autor: Marius Schmidt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
aber verschwendet man durch den check dann nicht auch wertvolle zeit in
der man vielleicht schon was zeichnen sollte? :)

Autor: kryon2000 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Zumal anhand welcher werte soll der Timer wissen ob er nun genau richtig
unterbrochen hat oder ein paar takte später ? Dies könne er nur durch
ein 2 Timer der wiederum werte irgendwo rein schreibt überprüfen, und
auch dieser weiss nicht ob er genau richtig unterbrochen hat usw
usw.....


Ein link zu solch einem Projekt würde klarheit verschaffen, aber
anscheinend existiert sowas ja nicht ;-)

Naja, was solls, anstatt hier darüber zu Phillosophieren ob Timer ja
oder nein, nähert sich mein Pacman dem Ende zu.

Noch ein paar Bugs beheben und dann ist es fertig :-))))))

Autor: Benedikt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hier gibt es hunderte an Projekten, alle mit einem AVR und einem TV als
Ausgabe. Die fertigen Ausgabe Routinen in Assembler gibt es hier, der
Rest des Programms lässt sich in C schreiben.

http://instruct1.cit.cornell.edu/courses/ee476/Fin...

Autor: kryon2000 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Naja, allsamt baut es auf den

Cornell University
Electrical Engineering 476
Video Generation


Code auf. Was soll man davon halten. Desweiteren sind diese Games
unsauber Programmiert. Wenn man sich die Videos anschaut kommt es bei
Screenwechsel zu Sync ausfall. Sowas sollte man ja nun auf jedenfall
vermeiden.

Autor: Andi K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn Du meinst, Du schaffst es, einen Spielablauf zusammen mit der
Zeilenausgabe zu mischen, dann nur zu.
In einem vom Benutzer steuerbaren Programm (Spiel) gibt es X-Beliebig
verschiedene Situationen die dann beachtet werden müssen.
Zum einen muss immer ein Teil des Spielfeldes ausgegeben werden welches
sich auch verändert.
Mal ist ein Punkt an einer Stelle, mal ist keiner (Weggefressen vom
PacMan).
Mal ist in einer Zeile nur der PacMan, mal ist noch 1 Geist auf
gleicher Höhe und mal vielleicht sogar alle 4 und der PacMan.
Du mußt dann alle verschiedenen Möglichkeiten bei jeder Ausgabezeile
mit einbeziehen und dabei darf es keinen Takt zuviel oder zuwenig
werden.
Die Steuerung kommt auch noch dazu wobei das in der V-Sync-Phase
behandelt werden kann.
Wenn Du das ohne irgend einem Interrupt hinbekommst und dann noch in 8
Graustufen, RESPEKT!
Vielleicht noch mit Sound-Ausgabe mit der Zeilenfrequenz?

MfG
Andi

Autor: Willi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
das Problem beim Timing von Interupts beim AVR ist,
das der beim Interupt gerade laufende Befehl noch zu Ende
abgearbeitet wird. Das kann dann 1, 2 oder 3 Takte dauern.
Das habe ich in einem Video-Projekt mal folgendermassen gelöst.

Man kann die Timerinterupts auf zwei Arten betreiben:
Einmal so, das der Int ausgelöst wird, wenn der Timer
bis max gezählt hat und überläuft (Timer OVF),
und einmal so, das der Int auslöst wenn der Timer einen
bestimmten Wert erreicht hat(Timer Compare Match).
Dafür gibt es zwei unterschiedliche Int-Service Adressen.


Das habe ich kombiniert.
Um z.B exact 52us zu bekommen, setze ich den Timer zunächst so,
das er nach 46us überläuft und einen "Vor-Int" auslöst. (OVF-INT)
Der reisst den AVR asyncron aus dem Hauptprogramm, der Timer läuft
inzwischen weiter über Null hinaus vorwärts weiter.
In der Int-Service Routine schalte ich die Timer Betriebsart um, so das
noch ein Int ausgelöst wird, beim Erreichen des Wertes, der 52us
entspricht. (Comp-Match-Int)
Dann gebe ich die Interupts wieder frei und laufe in eine Kette aus
NOPs, die alle genau einen Takt lang sind. (kein reti!!)
Bei 52us wird diese Kette unterbrochen, und es wird die andere Timer
Int-Routinte aufgerufen.
Diese muss jetzt den Timer wieder neu setzen und umschalten und
- ganz wichtig - die "falsche" INT-Rücksprungadresse vom Stack
"poppen", damit die erste "richtige" Rücksprungadresse wieder
wirksam wird.

Der "Trick" beruht darauf, das der Timer weiterläuft, egal ob der
"Vor-Int" nach 1 2 oder 3 Takten ausgelöst wird,
und das der zweite INT aus der NOP-Kette immer zum nächsten Takt
ausgelöst wird.

Ich hoffe, das ist einigermassen verständlich.

Mfg Willi

Autor: kryon2000 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@andi

Lass dich überraschen ;) Das Spiel läuft schon super sauber und das
beste, egal wieviele Geister ich hinzaubere (kann man nacher bei jedem
level selber deffenieren) ist kein einziger verzug zu sehen. Alles ist
perfekt getimt. Dank der Modularen bauweise. Kommt ein geist hinzu,
wird eben eine Zeile weg genommen (linecl) und mit dem Modul GHOST
belegt.

Ich kämpfe jetzt nur noch mit dem Problem des Spielablaufs. Wie z.B.
Schwirigkeitsgrad. Ich wollte es erst per Regelwiederstand lösen, so
dass man wärend des Spiels den Grad erhöhen oder erniedrigen kann,
jedoch werde ich dies wohl wieder verwerfen.

Nebenbei, Ich nehme keine Graustufen, es wird also nur ein Pixelwert
geben. Die Graustufen sind nur für den Modus TESTBILD.


@Willi
Gute Lösung, respekt. Jedoch werde ich sowas nie nutzen, da ich bei
einem Screenwechsel keine Sync Unterbrechung haben will, und bei Hsync
über Timer wird es wohl darauf hinauslaufen denke ich.

Autor: Andi K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi kryon2000!
Na dann viel Erfolg mit Deinem Spiel.
Ich hoffe, Du machst es gleich gescheit, also die Figuren als so ne Art
Sprites bzw. Shapes welche Pixelweise über den Screen bewegt werden.

MfG
Andi

Autor: leo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@kryon2000: Auch von mir höchsten Respekt vor dieser Leistung, ich
beschäftige mich auch ein wenig mit dieser Thematik, allerdings nur für
ein OSD-Display mit etwa 24 Zeilen zu 40 Zeichen und "abgedunkeltem"
Hintergrundbild. Von daher trau ich mich abzuschätzen welch Aufwand
hinter deinem Projekt steht und wie "lahm" die avrs sind ;-)

@willi: Dein Ansatz ist schon fast perfekt, die Unsauberkeit mit den
verdrehten Rücksprungadressen hast du ja selbst erwähnt. Ich habe das
Problem dadurch gelöst dass ich den avr kurz (ca. 1us) vor dem nächsten
Zeilenbeginn schlafen schicke, damit kommt der nächste Int. bzw.
Syncbeginn mit einer konstanten Verzögerung.

@all: weiter oben wurde in Frage gestellt ob man die unterschiedlichen
Int.Aufrufzeiten im Videobild sieht? -> Ja, die 62.5ns sind auf einem
mittelgroßen Monitor fast ein halber Millimeter Pixelbreite.

Grüße leo9

Autor: kryon2000 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@andi

Na das mit den Sprites war doch wohl eher ein Witz. Immerhin reden wir
hier von einem kleinen Mikrocontroller und nicht von einem Homecomputer
;-). Die Spielfläche ist zwar 128x128 pixel gross, aber denoch werden
die Figuren des spieles wegen bei mir in 16x16 ASCII RAM gespeichert.

@leo
Bei den OSD Geschichten gibt es einen ganz grossen Vorteil, diese haben
einen internen Speicher und man kann deshalb seine Routinen
Zeitunkritisch gestalten und muss sich nicht noch auf die Bildausgabe
konzentrieren.


@all

Also wenn einer hier dabei ist und sich die Schaltung auch gebaut hat
(kosten ca. 10,-€) den kann ich ja mal ne BETA Version zukommen lassen.

Autor: Andi K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das mit den "Sprites" war völlig ernst gemeint.
Man müßte halt eine "Sprite-Line" eines Register in 3 Zellen/Register
aufteilen und je nach Y-Position eine von 16 verschiedenen Laden, also
jedes Ghost-Objekt wäre dann 16 mal vorhanden.
Immerhin war es mir damals möglich, mehrere 16x16 Pixel Sprites auf nen
AtariST darzstellen und zu steuern. Der MC68000 war zwar ein 32-Bitter
lief dort aber auch nur mit 8MHz und die kleinste Ausführungszeit eines
Befehles waren 2 Takte.
Es sollte ja auch nur ein Anreiz sein.

MfG
Andi

Autor: Andi K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sorry, meinte natürlich, das jedes "Ghost-Objekt" 8 mal vorhanden sein
müsste für eine Pixelweise-Verschiebung in der Horizontalen ohne
großartige Bitschiebereien.
Ach ja, mir ist schon klar, das beim damaligen AtariST die Bildausgabe
was anderes übernommen hatte.

MfG
Andi

Autor: kryon2000 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
genau ;-)

Autor: leo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>> Bei den OSD Geschichten gibt es einen ganz grossen Vorteil
.. da hast du mich falsch verstanden, ich verwende den avr für die
gesamte Videogenerierung. OSD ist "nur" meine Anwendung, ich gebe
halt Text und keine Testbilder, Spielflächen aus.

Einen weiteren Vorteil des interrupt gesteuerten Timings ist die
(relativ) einfache Syncronisierbarkeit auf externe Videosignale. Ist
aber auch nur bei der OSD-Applikationen relevant. Spiele und Testbilder
werden wohl meist freilaufend verwendet.

grüße leo9

Autor: Andi K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
kryon2000, überlege Dir trotzdem mal das mit den Sprites!
So lahm sind 16MHz nun auch wieder nicht.

MfG

Autor: kryon2000 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@leo

Achso, ich dachte du parkst die Sachen extern irgendwo ;)
40x24 Zeichen ist echt super. Sind die Zeichen bei dir auch 5x7 Pixel ?
Oder doch nur 3x5 ? Meine Zeichen sind alle 5x7 und da könnte ich glaube
ich nicht auf 40 Zeichen pro Zeile kommen. Ich habe da nur 32 Zeichen.
Siehe hier:

http://mitglied.lycos.de/polyxos/tv7.jpg

Das ganze Projekt dazu ist hier:

http://mitglied.lycos.de/polyxos/video.htm

Aber bei OSD mit ext. Sync Signalen ist es ja auch einfacher, man kann
da ja jede Zeile auslaufen lassen und fängt einfach bei dem neuen sync
Takt an. Sogesehen ext. Interrupt. OSD würde mich in dieser form auch
mal interresieren. Hast du da eine Seite ???

Autor: Christian Zietz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Andi K.: Beim Atari ST musste die CPU ja auch schließlich nicht das
Timing für das Videosignal generieren.

Autor: Andi K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Klar, hab ich doch nachträglich geschrieben!

MfG
Andi

Autor: kryon2000 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So, nun kann es mit der ersten BETA mal los gehen, schnell noch den
Steuerknüppel anlöten und dann mal testen.

Da sitzt man immer stundenlang vor einem Problem und sieht den Wald vor
lauter Bäumen nicht. Ich habe mich immer gewundert das nach einer
Kollesion mit einem Geist das Rücksetzen der Figuren nie klappte. Und
siehe da, mein häufigster Fehler den ich anscheinend immer wieder mache
war es.

ld  r17, Z

anstatt

lpm r17, Z

benutzt. Ich bekomme es wohl nie auf der Reihe zwischen Flash und RAM
zu unterscheiden :-)))))))

Habt ihr auch immer solche Standartfehler die ihr unbewusst immer
wieder mal macht ?

Autor: fran2y (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo kryon2000,

Ich habe ein paar Fragen an dich:

Hast du deine Seite per "Hand" geschrieben oder Hast du ein Programm
dazu benutzt, wenn ja welches?

Warum täuscht du vor, dass du auf deiner Seite mit einem Script eine
.HEX-Datei erstellen kannst?

cu

Autor: Andi K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nein, nein, er täuscht nix vor.
Hier ein Ausschnitt aus dem Java-Script zum einbinden der Laufschrift
und berechnen der Checksumme:

document.bestellung.card.value+=":100A6000000013E01A950000E9F746DD2A9531 
F001\n";
document.bestellung.card.value+=":0E0A700013E01A95F1F700000000E1CF0895A1 
\n";


for(rrr=0;rrr<60;rrr++){
a=0;document.bestellung.card.value+=":";
for(i=(rrr*20);i<(rrr*20+20);i++){dechex(i1key[i]);a+=i1key[i];document. 
bestellung.card.value+=hexddd}
a&=0xFF;a=0x100-a;dechex(a);document.bestellung.card.value+=hexddd+"\n";
}

for(rrr=0;rrr<16;rrr++){
a=0;document.bestellung.card.value+=":";
for(i=(rrr*20);i<(rrr*20+20);i++){dechex(llauf[i]);a+=llauf[i];document. 
bestellung.card.value+=hexddd}
a&=0xFF;a=0x100-a;dechex(a);document.bestellung.card.value+=hexddd+"\n";
}

document.bestellung.card.value+=":101E0000000000000000000020202020200020 
0012\n";
document.bestellung.card.value+=":101E100050500000000000000050F85050F850 
00F2\n";
document.bestellung.card.value+=":101E20002070A0702870200000881020408800 
00DA\n";
document.bestellung.card.value+=":101E30006090A040A890680010200000000000 
0002\n";
document.bestellung.card.value+=":101E4000182040404020180060100808081060 
006A\n";
document.bestellung.card.value+=":101E500000A870F870A800000010107C101000 
009E\n";
document.bestellung.card.value+=":101E60000000000010102000000000F8000000 
003A\n";
document.bestellung.card.value+=":101E7000000000000000200000081020408000 
004A\n";
document.bestellung.card.value+=":101E8000708898A8C888700020602020202070 
00EA\n";
document.bestellung.card.value+=":101E9000708808304080F80070880830088870 
002A\n";
document.bestellung.card.value+=":101EA00080809090F8101000F880F008088870 
008A\n";

MfG
Andi

Autor: kryon2000 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@fran2i

Für meine HTML Seite benutze ich das kostenlose Programm NOTEPAD. Damit
erstelle ich sowohl meine HTML, PHP und ASM Programme ;-)

Ich täuche dort auch nichts vor, die Texte müssen ja in das HEX File
rein und deshalb müssen die ASCII ersteinmal in ASCII-HEX gewandelt
werden um dann in das HEX File integriert werden zu können. Und die HEX
Files verlangen am ende eine Checksumme. Auch dies muss durch das Java
Script generiert werden. Der erste und letzte Teil ist natürlich schon
vordeffeniert und wird einfach ausgegeben.

Autor: dave (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich hab da ne kleine Frage ;)
Gibst du den Quelltext noch frei? Will das auch mal ausprobiern.

Autor: kryon2000 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Naja, ob dir mein Quelltext was bringt ??? Es stehen kaum kommentare
drinn, eigentlich nur Takte hinter jedem Befehl....

Wie z.B:

;######### wandele Pointer Hex -> ASCII########################
pointer_ha:
  lds  temp2, 0x00a0  ;2
  lds  temp1, 0x00a1  ;2
  rcall  bin16    ;424

  ldi  YH, 0x00  ;1
  ldi  YL, 0x16  ;1
  ldi  XH, 0x00  ;1

  ldi  XL, 0x67  ;1---
ti4:  ld  r0, -Y    ;2
  st  X+, r0    ;2   35
  cpi  XL, 0x6C  ;1
  brne  ti4    ;2---

  ldi  r17, 0x77  ;--------------
ti3:  dec  r17    ;          pause 358
  brne  ti3
  nop      ;1------------

  rcall  hsync    ;75
  nop      ;1
  nop      ;1
  nop      ;1
  ret
;##################################################################


Ob du da draus schlau wirst ?

So, nun ist die BETA fertig:

http://mitglied.lycos.de/polyxos/tv15.jpg
http://mitglied.lycos.de/polyxos/tv14.jpg

Jetzt muss ich noch ein paar Levels erstellen. Ein Level brauch 0x44
(68) Byte. Ich denke mal das ich 20 Level dort einbauen werde. Aber
ersteinmal werde ich auch Sound einbinden. Das sollte ja einfach sein.

Autor: kryon2000 (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hier im Anhang ist mal der Schaltplan und das HEX zur BETA.

Autor: Freak5 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kannst du mal ein Video drehen?
Eine eigene Konsole gebaut haben sicher nicht soo viele. :-)

P.S.: Zum Speed-> Kann man die AVRs oder wenigstens einige davon nicht
auch bei 20Mhz laufen lassen?

Bei deiner Programmierung wäre das Portieren auf einen schnelleren AVR
etwas schwierig, oder?

Autor: kryon2000 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hier mal ein Video:

http://mitglied.lycos.de/polyxos/pacman.avi

RECHTSKLICK....ZIEL SPEICHERN UNTER.... (sonst kommt lycos Error Page
!!!)

Natürlich kann man es auch mit 20MHz machen. Gibt ja AVR's die das
können. Man muss nur die Routine dann anpassen.

Autor: thkais (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Und da ist doch genau der Haken an Deiner Methode.
Nicht, daß ich Dein Erfolgserlebnis schmälern möchte, ist schon
interessant, was Du da auf die Beine stellst.
Aber bei Deiner Methode mußt Du den Code komplett durchackern, mit
allen Fehlerquellen, die dabei entstehen, bei der Timermethode muß
(theoretisch) nur der Timer umprogrammiert werden. Solange man
schneller wird, machts kein Problem.

Mal was anderes: Warum bei Farbe das komplizierte FBAS-Signal
verwenden? Bei ebay gibts TFT-Monitore teilweise schon für 100 Euro -
soviel zahlt man bereits für ein 240x128 s/w LCD... RGB sollte ja nicht
das große Thema sein, da gibts schon einige Projekte, die das
verwirklicht haben. Ist nur die Frage, welche Auflösung man schafft
bzw. ob die 1024x768 Panels 512*384 sauber runterrechnen. Mit zwei Bit
pro Farbe kriegt man auch schon eine ansehnliche Farbpalette.

Autor: kryon2000 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@thkais

Zuerst mal was zu den Timer bzw. taktfrequenz. Ich brauch sogesehen nur
1 Routine dafür ändern. Die HSYNC !!!! Mehr nicht !!!!!! Und wo ist das
Problem ?

Hier mal die HSYNC:

;#####( Horizontale Synchronimpuls 189
takte)############################
; 4µs sync low    (4*16 = 64  takte bei 16 MHz)
; 8µs Blackscreen (8*16 = 128 takte bei 16 MHz)
; +3 vom rcall
; +4 vom return
; +192 vom programm
hsync:  cbi    PORTB, sync  ;2  ;sync
  cbi    PORTD, pixel  ;2
  ldi    r17, 0x15  ;63
hs:  dec    r17
  brne   hs
  nop        ;1
  sbi    PORTB, sync  ;2

  ldi    r17, 0x29  ;123  ;blackscreen
hs3:  dec    r17
  brne   hs3

  ret      ;4
;#######################################################################


Wird es nun 20MHz kommt vorne und hinten jeweils eine kleine Schleife
rein. Fertig ist es. Genau so als würde ich es auf NTSC umstellen, da
wird die Hsync geändert und ein paar Leerzeilen verschwinden und fertig
ist man damit.

zu den Fehlerquellen
---------------------

Wenn eine Unterroutine ersteinmal fertig ist braucht man diese nacher
nicht mehr checken ob sich da ein fehler eingeschlichen hat. Man
arbeitet sich sogesehen Modul für Modul durch. Die Fehlereingrenzung
ist somit auf Modulebene begrenzt. Man muss also nicht mehr das ganze
Programm durchhacken ;-)





Zu deinem Vorschlag mit der Farbe
---------------------------------

Hallo, wir wollten billig bleiben !!! Wenn ich mir jetzt noch ein TFT
holen müsste kann ich mir gleich ein PC hinstellen und dort PacMan
drauf programmieren ? Wo ist da der Sinn ? Ein TV besitzt jeder. Also
baue ich doch nur ein Modul welches man dann an jedes GÄNGIGE Gerät
anschliessen kann. Sollte ich jetzt so ein TFT Modul kaufen müsste
jeder das selbe zulegen, damit es mit den Protokollen ect. überein
stimmt.

Autor: Michi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
RGB hat doch jeder Fernseher, wo ist das Problem?

Autor: ERDI - Soft (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@kryon2000:

Ich verstehe deine Aversion gegen Timer nicht.
Du verschwendest Rechenzeit pur, wenn du keinen Timer benutzt.
Es sagt zwar keiner, dass es mit nem Timer einfacher ist als mit deiner
Lösung, aber du hast wesentlich mehr Zeit, um andere Dinge zu berechnen.
(Klar kann es die Programmiererei etwas komplexer machen, aber wir sind
ja alle gute Denker. :) )
Mit Timer solle auch ein Graustufen-PacMan drin sein.

Autor: kryon2000 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Na dann zeigt doch mal eure Lösungen mit Timer, dass was ich bis jetzt
gesehen habe ist der Misst von:

http://instruct1.cit.cornell.edu/courses/ee476/Fin...

Cornell University
Electrical Engineering 476
Video Generation

Solche Low Grafik ist ja nun echt nicht der Hit. Bevor ihr euch auf
Timer ect. festlegt und Graustufen, solltet ihr ersteinmal selber
versuchen eine Grafik auf dem TV dar zu stellen, dann erst werdet ihr
merken welche Probleme sich da so auftun. Wer will kann ja mal den Kurs
besuchen den ich gerade dafür halte:

http://www.4freeboard.to/board/thread.php?threadid...

Aber wie gesagt, ich bin über eure Lösungen betreffs Timer immer sehr
dankbar, stellt doch mal eure Lösungen dazu hier rein (Screenshots,
video ect...)

Autor: kryon2000 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Michi

Klar haben EINIGE TV's den Euroscart auch mit RGB belegt, aber nicht
alle. Gerade billige TV's haben dies nicht, desweiteren kann man sein
Signal nicht per HF raus geben, da die HF Module leider nur Composit
als input haben wollen. Ein billiges RGB -> PAL Modul könnte da abhilfe
schaffen, jedoch existieren solche billigen IC's nicht. Mein Projekt
beruht auf dem Motto, EINFACH und BILLIG.

Autor: Willi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>>EINFACH und BILLIG

JA, bleib dabei, das macht es ja interessant.
Mit genug techn. Aufwand kann man ja gleich
'ne Playstation nachzubauen versuchen.

Sinnlos ist das Ganze ja allemal,
wer braucht ein Pacman-Game auf TV?

Der Zweck liegt doch darin , ASM zu lernen,
und darzustellen was mit einem simplen AVR so möglich ist.

Ich hab vor einigen Monaten in einem anderen Forum ein
AVR-Videoterminal programmiert.
Mit einem Atmega8 mit 8 MHz und zwei Widerständen.
Nix weiter. Nicht mal ein Quarz.
Komplett Interruptgesteuert, übrigens.
Da ging es mir auch darum,
das so einfach wie möglich zu machen,
und meine Kenntnisse in ASM auf AVR zu verbessern.

Also mach weiter so - EINFACH und BILLIG
Ich verfolge das mit Interesse.
Allerdings, den Source-Code solltest du schon kommentieren
und hier einstellen,
damit auch andere davon lernen können.
Finde ich.

Mfg Willi

Autor: Michi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"Ich hab vor einigen Monaten in einem anderen Forum ein
AVR-Videoterminal programmiert. "

Wo denn?

Autor: Tom (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nicht billig, sondern günstig. ;-)

Autor: Willi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"Wo denn?"

www.roboternetz.de

MfG Willi

Autor: dave (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hast du noch Quellen, wie das ganze eigentlich mit FBAS etc
funktioniert?
Oder nen paar Stichwörter zum googeln.
Kann man da überhaupt Farbe integrieren, bei der Anschlussart?
VGA hat doch 3 Farben und HSYNC+VSYNC..

Autor: Markus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@dave:
Hier sind ein paar Links zu finden:
http://www.mikrocontroller.net/articles/TV-out

Autor: kryon2000 (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
@willi

Ohne externen Quarz ? So wie ich es feststellen musste, sind die
internen 8MHz nicht sehr stabil. Bei mir schwam das Bild dann immer.

@all
Da ich 20 levels einbauen will und auch gerne eure Ideen da einbauen
möchte könnt ihr mir ja ein paar Vorschläge zusenden. Oben im Anhang
ist so ein Beispiel. Macht einfach mal ein 16x16 pixel grosses Bild wo
ihr das Feld einzeichnet. Platziert dann mit grün die Startposition der
Geister (1 bis max. 4) und mit rot die Startposition vom PacMan.

Autor: Willi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"Ohne externen Quarz ? So wie ich es feststellen musste, sind die
internen 8MHz nicht sehr stabil. Bei mir schwam das Bild dann immer."

Nee, kein Problem, das Bild steht wie eine Eins.
Kannst die das Programm ja im Roboternetz-Downloadbereich
unter AVR-Codeschnipsel runterladen und ausprobieren.

Für die Bildstabilität ist ja auch nur die Frequenzstabilität
in einem kurzen Zeitraum wichtig.
Wenn der RC-Oscillator z.B. wegen Temperaturänderung
langsam wegdriftet, so bleib das TV-Bild trotzdem stabil.

Die absolute Genauigkeit ist beim TV-Signal
sowieso nicht so wichtig.
Die Bildzeile z.B. muss nicht genau 64us lang sein.
63us oder 65us geht auch.
Aber jede Zeile muss genau gleich lang sein, das ist wichtig.
Bei Schwankungen gibts hässliche Verzerrungen.

MfG Willi

Autor: kryon2000 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
GEISTESBLITZ

+++++++++++++++++++++++++++++++

Ich glaube ich weiss nun wie wir das mit der FARBE hin bekommen
könnten. Zuerst bauen wir uns ein Quarzoszilator mit den berühmten
4,4....MHz (aus alten TV ausbauen) Diesen werden wir dann über einen
Port vom Atmel entweder zuschalten oder auch nicht. Und da 16MHz
überhaupt nicht durch 4,4 teilbar sind müssten wir schöne
farbverschiebungen hin bekommen. leider weiss ich nun im Vorraus nicht
welche farben da entstehen, jedoch irgendwie BUNT wird es schon werden
(glaube ich).

also benötigen wir als zusätzl. Hardware ein Quarz (4,4...MHz) ein NAND
Gatter (74xx00) als Generator und ein Wiederstand.

Möge mich jetzt noch einer schnell berichtigen ansonsten baue ich den
scheiss gleich mal.....

Autor: thkais (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@kryon2000:
Der Grund, weshalb ich mit einem TFT arbeiten möchte, ist folgender:
Ich arbeite gerade an einem Projekt, in dem ich viele Werte und einige
Grafiken visualisieren will. Momentan benutze ich ein 240x128 LCD.
Durch Dein Projekt bekam ich den Anstoß, es auf eine andere Art zu
realisieren. PC fällt von vornherein aus (braucht viel zu viel Strom
für eine 24/7 - Anwendung). Vom Preis/Leistungs-Verhältnis her ist ein
TFT nicht schlecht. Und dann noch bunt... und mit exakt vorhersehbaren
farben ;)

Autor: Markus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@thkais:
Dafür gibts bessere Lösungen, z.B. die von www.ulrichradig.de
(Startseite->CPLD->Graka).

Markus

Autor: Rufus T. Firefly (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@thkais: Du solltest Dir mal den Beitrag von Benedikt aus der
Codesammlung ansehen - der steuert dort ein schwarzweißes STN-Display
mit VGA-Auflösung an. Das ist zwar kein TFT, aber einige Grundkonzepte
ließen sich auch auf ein TFT übertragen.
http://www.mikrocontroller.net/forum/read-4-160854.html#new

Autor: thkais (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Habe ich eigentlich schon erwähnt, daß es mir um das Feature Farbe
geht ?
Mit CLPDs kann ich nicht viel anfangen.
Mal sehen, wenn eines meiner 1000 anderen Projekte endlich mal fertig
wird, gehe ich das mal an. (Nur noch 28 Jahre bis zur Rente g)

Autor: kryon2000 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So, habe nun eben meine Bastelkiste nach Quarzen abgesucht. Und was soll
ich sagen. TV ausschlachten hat sich wohl gelohnt. Ich habe 2 17,73447
MHz Quarze gefunden.

Jetzt meine Idee

Ein 4er Teiler kommt bei den 17 MHz dran der durch den atmel geresetet
werden kann. Somit haben wir nach dem BURST eine genaue grundlage um
den Teiler zu reseten. Da 16MHz und 4,433 MHz keinen Teiler besitzen
können wir durch ausgewähle resets am Teiler eine deffenierte
Phasenverschiebung zum BURST durchführen. Jetzt muss ich mal nach einem
teiler suchen...das war doch so ein 74xx194 oder.....

Autor: kryon2000 (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Im Anhang mal ne Skize von meiner kranken Idee.....

Autor: kryon2000 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also, ein wenig Bunt wurde es:

http://mitglied.lycos.de/polyxos/tv16.jpg

50:50 war das Resultat. Das lag im grossen und ganzen daran, das ich
den BURST nie Phasenverschoben hatte. Also er war in jeder Zeile
gleich.

Jetzt weiss ich nicht wie die Phasenverschiebung sein müsste, 90° oder
180°. Überall liesst man was anderes.

Autor: Freak5 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So nebenbei-> Besorge dir mal anderen Space. Wie www.cybton.de oder so.
Irgendwas, wo man die Bilder auch sehen kann. Das mit lycos ist nämlich
etwas lästig...
Als Ersatz ist es sicher gut, aber sonst. Es gibt sicher noch viel
besseren, welcher auch kostenlos ist, aber mir fällt nichts ein.

Autor: Freak5 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ich meinte www.cybton.com

Autor: kryon2000 (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
So, habe noch etwas rumgespelt an der V-Sync und versucht ein wenig
Sound dort rein zu bringen.

Sieht nun so aus:

http://mitglied.lycos.de/polyxos/tv17.jpg

Und diese Punktzahl gilt es zu schlagen ;)

http://mitglied.lycos.de/polyxos/tv18.jpg

Im Anhang das Schaltbild + HEX File....


Mit dem Drehregler lässt sich die Spielgeschwindigkeit einstellen, je
schneller um so mehr Punkte bekommt man auch für einen Keks ;).

Autor: kryon2000 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hier nochmal ein AVI (11 MB gros)

http://www.volkssturm.net/TMS_rang/pac.avi

Autor: Malte (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>http://www.volkssturm.net/TMS_rang/pac.avi
Such mal nach anderem Speicherplatz - 3,5KB/s macht bei 11MB keinen
Spaß. :-(

Autor: Malte (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
aber die ersten 900KB des Videos sehen trotzdem gut aus :-)

Autor: kryon2000 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Na dann testet den mal:

http://kryon2000.cybton.com/pac.avi

Autor: kryon2000 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ups....geht so nicht, dann eben so....

http://kryon2000.cybton.com

Autor: Hannibal (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ik würd mal was in den Raum werfen. man könnte doch "Gamedisks" mit 2
oder 3 EEproms nehmen, 1 mit spielablauf, 1 mit Grafik und eins mit
Sound. es gibt dann halt 2 Atmels, einer Grafik, einer Spielablauf und
Ton, welche die EEProms auslesen. So wären, da der Grafikchip wirklich
nur die grafik machen müsste auch super-farben und klarer stereosound
möglich.

Autor: Malte (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Hannibal:
Bevor ich anfangen würde EEProms an einen AVR zu packen, würde ich
erstmal einen AVR mit mehr Flash nehmen. Zumal entweder serielle
EEProms zu langsam wären oder aber parallele EEProms wegen den vielen
Pins bereits größere AVRs benötigen würden.
Zwei AVRs zusammen wären aber durchaus interessant.

Autor: Freak5 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Zur Kommunikation wäre dann aber ein Speicher gut, in dem das Bild 2x
hineinpasst und welcher gleichzeitig gelesen und beschrieben werden
kann.
Das führt dann dazu, dass man doublebuffering hat und dass sich ein AVR
nur um das Malen kümmern kann und dass der andere den kompletten Ablauf
übernehmen kann.

Autor: Weihnachtsmann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dualport-RAM wäre gut nur viel zu teuer.
Oder ein sehr schnelles SRAM das man multiplext.

Autor: Hannibal (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
1. naja ich meinte, dass die Games auf EEproms gespeichert werden, zu
beginn in den RAM geladen werden und dann gestartet wird. so wäre es
möglich mehrere Games an der "Konsole" zum laufen zu kriegen. Während
des Ladens könnte ja ein Logo eingeblendet werden oder an einer
Festgelegten position auf dem EEProm ist ein wird geladenbild was als
erstes geladen und während des Ladevorganges angezeigt wird.

2. Desweiterenm könnte man ja auch 2 Rams nehmen. Der hauptchip
schreibt auch den ext. RAM1 während der Grafikchip von RAM2 liest.
Danach wird geswitcht. (Dat meinest du doch mit muliplex oder?)

3. Wenn man dasb so mit den EEProms macht, müsste man am besten noch
ein SDK rausbringen mit dem Leute gaaannz einfach Games machen können.
vielleicht sogar Click`n`Play.(SDK für Basic & C)

Mfg Lukes Vader

Autor: Malte (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Hannibal:
Dein Vorschlag ist mit AVRs unmöglich, da Programme nur aus dem Flash
ausgeführt werden könne. Also könnten nur Daten von einem EEProm
geladen werden oder es muss ein (lahmer) Interpreter geschrieben
werden.
Alternative: Kein AVR verwenden.

Autor: Freak5 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Hannibal: Das ist prinzipiell das gleiche :-) Man braucht nur eine
Steuerleitung, welche im Richtigen Moment umschaltet.

Woher bekommt man solchen Ram? Ich würde 2x 500kb nehmen. Das reicht
auch, wenn man irgendwann was schnelleres machen kann mit voller
auflösung und 8bit.

Autor: Freak5 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
http://www.reichelt.de/inhalt.html?SID=14QAl30dS4A...

Wie groß ist dieser Baustein? Ist der 1MB groß oder 128KB?

Autor: Freak5 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich persönlich würde vielleicht doch einen 64Kb baustein nehmen. Die
warscheinlichkeit, dass man irgendeinen superchip als Grafikeinheit
nimmt ist doch sehr gering.

Autor: Freak5 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe noch eine Frage: Kann man den externen Ram eigentlich irgendwie
auf den internen Ram mappen, damit man sich die zusätzlichen LESE und
SCHREIB-Routinen sparen kann?

Autor: Hannibal (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
also isch hab noch nie mit Atmels gearbeitet(bitte haut mich nich) aber
viel in Foren gelesen.
Eigentlich müsste ja nur der Hauptchip Programme laden können da Grafik
u. Sound eine Firmware haben könnten. Und für standart berechnungen
reichen doch 10mhz. Bei Reichelt ham sie solche komischen Prozis. Und
sonst nimmt man nen 486;-)
Und nochwas. Ich hab mehrere Ramriegel rumliegen. PS/2 oder so. Könnte
man die Chips davon fürs Grafikspeichern nehmen. Würde auch welche
verschenke(gegen Porto)

Autor: Malte (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Hannibal:
Ok, da du es nicht weißt, AVRs können Architektur bedingt keine
Programme aus dem RAM ausführen. ARM, oder MSP würden es aber können.

@Freak5:
Externen RAM in den internen RAM mappen geht nur bei manchen AVRs. Der
ATMEGA8 kanns nicht (würde auch zu viele Pins benötigen). AT90S8515,
ATMEGA64, ATMEGA128 fallen mir gerade ein, die es können. Genaueres
erzählt dir das Datenblatt.

Autor: Hannibal (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das mit dem Ausführen wusste ich schon. Mit Prozis meinte ich keine
Atmels sondern solche ZiLOG oder Ähnliche.

Autor: Hannibal (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das mit dem Ausführen wusste ich schon. Mit Prozis meinte ich keine
Atmels sondern solche ZiLOG oder Ähnliche. Und ich finde für
Hauptarbeit(Kollision, Dialoge usw.) usw. würden auch Interpreter
reichen. Ich weiß das das langsamer is aber für kleinere Berechnungen
reicht es, da die Grafik ja das Schlimmste ist.

Autor: Hannibal (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ups sry fürs doppelpost

Autor: Hannibal (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
so hab noch eine! frage kann man programme vom flash ausführen, denn
dann kann man ja mit bootloader EEProminhalt auf flash kopieren. und
dann von der Stelle ausführen.

mfg Lukes Vader

Autor: Malte (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Theoretisch könnte ein Bootloader erstmal ein Programm aus einem
externen EEProm in den Flash kopieren. Aber: Flash ist nur begrenzt neu
beschreibbar. ATMEL garantiert bei den ATMEGA 10000 mal. Das mag zwar
reichen, aber ich würde andere Lösungen vorziehen.

PS: Bastel mir selber gerade eine "Spielebox" mit nem ATMEGA32 und
LED Display.

Autor: Freak5 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Malte:
AT90S8515 der ist nicht Pinkompitabel zu den ATmegas wie ATmega16 usw.

Kann man den denn mit dem ISP programmieren???

P.S.: Für dieses einmappen des externen Rams, was ist der Fachbegriff
dafür(ich möchte mal wissen, ob die Atmegas im Dil - Gehäuse wie Atmega
16 und ATmega32 das auch nicht können)

Autor: Malte (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der AT90S8515 ist nicht mit den ATMEGA16/32 Pin-kompatibel. Kompatibel
wäre der AT90S8535, der aber keinen externen RAM unterstützt.
Beim ATMEGA128 heißt es "External Memory Interface", hab ich aber
noch nicht mit gearbeitet (kommt noch),

Autor: Weihnachtsmann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die Idee mit 2 AVRs finde ich nicht so schlecht wenn andere auch das
Gegenteil behaupten.

Ein externes SRAM als Videospeicher darauf greifen 2 AVR.
Eine liest aus und erzeugt das Bild und der andere baut das Bild auf
und schreibt es ins SRAM.

Ist die Idee blöd?

Autor: Hannibal (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ganau!

Bloß eine Frage, wie kann man mit wenig mitteln Programme laden ohne
meine Flash-idee.

Autor: Andi K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Na ja, der eine AVR muß ja nur Daten lesen und ausgeben und sollte nicht
dabei gestört werden.
Der 2. AVR muß zum Grafikaufbau nicht nur schreiben, sondern bei
Bitverknüpfungen (OR, AND) für einzelne zu setzende Pixel, auch mal vom
SRAM lesen.
Ansonsten kann man keine gescheite Grafiken erzeugen wie Pixelweises
Scrolling, verknüpfen von mehreren Objekten teilweise übereinander
etc.
Mit Klötzchengrafik braucht man sich gar nicht erst die Mühe machen.

MfG
Andi

Autor: Weihnachtsmann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke Hannibal !!!

Autor: Hannibal (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
1. Ahm Weinachtsmann. Hast du mich letztes mal vergessen gehabt. Ich
warte immer noch auf Geschenke =).

2. Ich meinte 2 RAMS wobei sich die 2 Chips immer abwechseln.

Schritt 1)
1.liest auf RAM1
2.schreibt auf RAM2

Schritt 2)
1. liest von RAM2
2. schreibt auf RAM1

Schritt 2)
...

mfg Lukes Vader

Autor: Weihnachtsmann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Hannibal

Habe wohl dieses Jahr den Sack voll AVR für dich vergessen, aber
vielleicht dieses Jahr wenn du nett bist.

Mit 2 RAMs könnte man es sicher machen.

Aber dachte an eine andere Herausforderung indem man nur 1 RAM nimmt
aber abwechslungsweise beschreibt und liesst. Das muss natürlich sehr
schnell geschehen  und auch das Timing muss stimmen. Aber die Schalung
wäre einfacher.

Autor: Hannibal (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ja schon aber 2 RAMs sind einfacher und unkritischer vom Timing her. Ich
werd mir jetz erstmal ein paar AVRs bestellen. Alte RAMs hab ich ja noch
da. Muss mal gucken was sich machen lässt. Also wenn ich mal was
vorschlagen darf. Ich find das man es Ähnlich einem N64 mit den Modulen
machen kann. Um Sound werd ich mich dann mal kümmern und vielleicht mach
ich dann noch nen Interpreter.

Autor: Freak5 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also arbeitet ihr jetzt nicht mit den AVRs, welche den externen Ram
einmappen können?

Autor: crazy horse (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mein Gott - habe nicht alles gelesen - aber wer hat denn soviel Zeit zu
vertun? Das Ergebnis bleibt doch letztendlich unbrauchbar, vor 20
Jahren hätte man damit was reissen können, aber heute?? Nur um zu
beweisen, dass es irgendwie geht, und das eine schlechte Lösung besser
ist als eine ganz schlechte?

Autor: TravelRec. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@crazy horse:

Nu laß sie doch, letztenendes kommen dabei auch kreative Ideen heraus,
von denen wir alle etwas haben, so als Denkanstoß für künftige
Projekte...

Autor: Weihnachtsmann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ob es Sinn oder kein Sinn mache ist ein anderes Thema.
Ich glaube nich dass einer damit das grosse Geschäft machen will.
Sondern einfach selber was umsetzen und Erfahrungen sammeln.
Das macht Spass deshalb finde ich das Projekt interessant.

Autor: kryon2000 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

Na da habt ihr das Thema wieder mal von ganz unten hoch geholt ;-).

In diesem Forum wird richtig dran gearbeitet:

http://www.4freeboard.to/board/thread.php?postid=165963

farbe ist z.Z. angesagt.

Autor: Weihnachtsmann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Na ja mit der Aussage

"ich mach jetzt erst mal Urlaub"

glaub ich nicht dass da so "richtig" daran gearbeitet wird :-)

Autor: Martin S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@CrazyHorse
"Mein Gott - habe nicht alles gelesen - aber wer hat denn soviel Zeit
zu vertun? "

Nun ja, es gibt auch Bastler, welche sich die Mühe machen, aus einem
AVR chip einen MP3 Player zu bauen. Auch da kann man argumentieren: Geh
in den nächsten Elektronikmarkt, und kauf dir einen fertigen Player für
15 EUR ..

Aber auch da ist "der Weg das Ziel", und nicht, einen neuen MP3
Player gebaut zu haben, der mehr oder besser funktioniert alles alles
was derzeit im Laden zu kaufen ist.


Ich finde die Idee sehr pfiffig, den AVR quasi als Videocontroller zu
nutzen. Mein Lob und Hochachtung an MasterCrd (Krypon 2000/ mister_crd)
für seine fachlichen Kenntnisse und Fähigkeiten, und sein Engagement in
der Sache. Wenn ich eine Stelle in der Elektronik-Entwicklung
anzubieten hätte würde ich sie ihm gene geben. Der Mann keann sich in
Dinge ziemlich tief reinfressen...

Autor: Benedikt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich lese schon eine ganze Zeitlang diesen Thread, da ich auch viel mit
Videobildern und AVR machen, und eins kann ich sagen:
Die Idee mit den 2 SRAMs ist zwar machbar, nur viel zu aufwendig.
Wie wollt ihr die SRAMs umschalten ?
Dazu muss man 8bit Daten und mindestens 16bit Adressen umschalten, dann
noch die Steuerleitungen. Macht insgesamt 24bit und das sind pro SRAM 4x
74HC245, also insgesamt 8x 74HC245. Viel Spaß beim Aufbauen...

Die einzige realistische Idee ist ein schnelles SRAM und ein CPLD, der
schnell genug zwischen beiden AVRs umschaltet, also ein Pseudo Dualport
RAM.

Autor: crazy horse (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es gibt doch sicher sinnvollere zeitkritische Anwendungen, an denen man
sich so richtig auslassen kann. Den Igor-Plug beispielsweise finde ich
Klasse, das war sicher auch nicht gerade ein Kinderspiel.
Für mich wäre es jedenfalls kein Einstellungsargument, dass sich jemand
100e von Stunden in ein Projekt reinhängen kann, bei dem man schon im
Vorfeld erkennen kann, dass es nichts Sinnvolles ergibt. Eine
Vorabbetrachtung gehört zwingend dazu, und da kann man leicht erkennen,
dass ein MC dieser Grössenklasse nicht das geeignete Mittel ist, ein
Videospiel zu realisieren. Unabhängig davon, ob man es irgendwie und
mehr schlecht als recht doch hinbekommt.

Autor: Freak5 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@crazy horse:
Hast du noch nie etwas von den 256b Demos gehört? Das hier ist
sozusagen, die Extremversion davon. :-)

Autor: crazy horse (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nö - klär mich auf. Was ist das?

Autor: Benedikt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@crazy horse

Was ist an dem Igor-Plug sinnvoll ?
Man nimmt den FT232, hat eine hohe Baudrate und kann den AVR für was
sinnvollen einsetzen...

Autor: crazy horse (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"Was ist an dem Igor-Plug sinnvoll?"
Man kann tatsächlich damit was machen, und ein FT232 kostet um die
6Euro...

Autor: Freak5 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@crazy horse:
Ich habe mal für dich gesucht. Gefunden habe ich das hier. Recht
beeindruckend eine unter XP laufende Demo zu programmieren mit 3D und
nur 256bytes
http://www.256b.com/download/381
Und hier ist die Addresse:
http://www.256b.com/demo/374
Der Name der Demo, dessen Direktlink ich gepostet habe ist übrigens
GridRunner.

Ich finde das beeindruckend :-)
In diesem Fall ist so eine Art zu Proggen ja sogar nötig. Ihr könnt
doch auch mal so ein "3D" mit dem ATmega erzeugen :-)

Autor: Freak5 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
http://www.256b.com/demo/138
Die ist auch gut. Dabei muss ich sagen, dass ich die eine oder andere
Demo selbst leicht übertreffen könnte. Damit meine ich die, wo nur ein
einziger Punkt gezeigt wird g

Aber einige sind verdammt genial

Autor: Apostolos Chatziapostolou (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo thkais,

wenn schwarzweiss genügt und dir eine Ein-Chip-Lösung
(DIL 28) nicht zu aufwändig ist, dann schau mal hier:

http://www.tvterminal.de/index.html#TVT-MBKD

Habe die Farbversion (incl. Evaluation Board) auf der
diesjährigen HAM RADIO gekauft und bin sehr zufrieden.

achatz

Autor: Hannibal (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also, ich hatte auch überlegt. Ein Chip liest Bilder von EEProm in RAM.
Anderer AVR sendet Befehl mit Bildnummer u. Position an GrafikAVR.
GrafikAVR fügt Bild ein und zeigt an.


Bsp. Befehl:
1011010-111111-101010-1
BildNR.-Pos.X -Pos.Y -Tranzparenz?

Autor: Weihnachtsmann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Apostolos Chatziapostolou


Was ist denn das für ein Chip auf diesem Bausatz?

Autor: Hannibal (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
bin erstmal in dat Urlaub.

Autor: kryon2000 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Was das für ein Chip ist ? Na dann schaut euch mal die Anschlussbelegung
an. Ich tippe mal auf den ATmega8 oder den ATmega168.

Autor: Apostolos Chatziapostolou (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Auf dem Chip steht: TVT-MBKD-11.
Von der Belegung der Anschlüsse tippe ich auch auf einen ATMEGA.
Fliege heute abend endlich in den ersehnten Urlaub :)

Viele Grüsse

achatz

Autor: kryon2000 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich bin gerade dabei dieses feature für unsere Schaltung zu übernemen.
Aber ein wenig mehr RAM würde dabei echt nicht schaden.

Autor: Dirk Milewski (avr-nix)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
abo

Autor: kryon2000 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: Thomas Kropf (thomas_k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
auch abo
und:

kryon2000:
Ich find das ja echt eine super Leistung und bin wirklich begeistert
was du zustande gebracht hast
ABER wieso machst du nicht eine gescheite Seite wo dein Projekt Schritt
für Schritt erklärt wird anstatt von einem Forum ins Andere zu hüpfen?

Das würde, so finde ich, dann auch an Seriosität gewinnen.

Autor: kryon2000 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ganz einfach, es ist ja kein Projekt in dem Sinne, sondern eigentlich
nur eine Lektion damit andere was lernen. Ich gehe ja im anderen Board
auf die Fragen und Wünsche der einzelnen Teilnemer ein. Deshalb ist es
eben keine eigenständige Seite. Hier habe ich nur so aus Just for Info
gepostet, da es ja ein tolles Nachschlagewerk für alle MC Bastler ist.

Autor: kryon2000 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So langsam glaube ich das die Jungs hier:

http://www.tvterminal.de/index.html#TVT-MBKD

die Käufer bescheissen. Das es sich bei dem Chip um ein ATmega8, 48, 88
oder 168 handeln muss ist klar, jedoch besitzen alle nur 1024 Byte SRAM.
Damit ist es deffenitiev nicht möglich alle Daten im SRAM zu speichern.
Entweder die speichern alles ins Flash (was die Lebenszeit sehr stark
beeinträchtigt) oder die haben ein eigenen Chip in Auftrag gegeben. Was
natürlich die Frage aufwirft, ab welcher Stückzahl produziert eigentlich
ATMEL ein Chip mit mehr SRAM. Und was kostet sowas ? Ich glaube
letzteres haben die nicht gemacht.

So ein Flash ist ja nur bis 10 000 mal beschreibbar. Wer hat den schon
alles bei den sowas bestellt ? Läuft der "TV-Chip" immer noch ?

Autor: Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
.
   "Das es sich bei dem Chip um ein ATmega8, 48, 88
    oder 168 handeln muss ist klar,"

Frage: Woran machst Du das fest?

Autor: kryon2000 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
PINBELEGUNG !

Autor: kryon2000 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es sei denn du kannst mir ein anderen Chip zeigen wo XTAL, GND Vcc AVcc
PORTx0 in einem DIL28 genau so angeordnet sind.

Autor: Someguy (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Habe sowas schonmal auf ner amerikanischen seite gesehen, die haben
sowas mit nem mega128 glaube ich gemacht, und auch bilder darstellen
können (bitmaps)

Autor: Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hmm. Das kann natürlich sein.
Warum glaubst Du, daß das mit 1 KByte RAM nicht hinzubekommen ist?

50*18 = 900 Bytes "Bildschirmspeicher"; nirgendwo wird behauptet, daß
das Teil einen vollständigen 8-Bit-Zeichensatz benutzt. Also lässt sich
das eine Attributbit (Grau statt weiß) auch im "Bildschirmspeicher"
unterbringen.

Diese Balkengraphik ist ja keine frei programmierbare Graphik, sondern
ausschließlich Balkengraphik, die wird also nicht so sonderlich viel
RAM benötigen.

Hab' ich irgendwas übersehen?

Autor: kryon2000 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja , hast du.

50*18 Zeichen sind genau 900 Byte. Um eine Zeile mit 50 Zeichen in
einer Zeile mit 8 Linien auf den TV zu bringen müssen 50 * 8 Bytes
verbraucht werden. Das mach allem in allem genau 1300 Byte. Viel kürzen
kann man dabei auch nicht, da alles sehr schnell berechnet werden muss.

Das mit grau und weiss als Vorzeichen für eine Zeile lassen wir ruhig
dabei mal ausser acht. Deffenitiev muss 400 Byte für Videoram
reserviert werden im SRAM. Nun kann man sich überlegen wo er den
Bildschirm-ASCII Cash (50*18) speichert......

Ach ja, und ganze 1024 Bytes hat er ja auch nicht zur Verfügung, ziehen
wir nochmal 4 Bytes für den Stack ab.

Autor: kryon2000 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Und falls du es nicht glaubst, dann schau doch mal im Board nach wo ich
den Source Code für die 50*12 Ausgabe abgelegt habe. Wenn du es noch
effektiver hin bekommst dann poste es mal. Würde mich interresieren.

Autor: Jan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
Ich glaube auch, das das geht.
Es handelt sich hier um einen 5*7 Zeichensatz,
also nur 5 Bytes/Zeichen macht 250 Bytes Bildspeicher für eine Zeile.
Wenn die 50*18 6-Bit-ASCII-Zeichen sind, und mit 6 Bit pro Zeichen
gespeichert werden, dann sind das 675 Bytes als Zeichenspeicher.
Mach bis jetzt insgesamt 925 Bytes.
Das Attribut "hell"/"grau" funktioniert offensichtlich nur
Zeilenweise.
dafür braucht man also max. 18 Bits oder drei Bytes.
Wo Balkengrafik ist, braucht man keinen Platz im Zeichenspeicher.
Also, da ist noch jede Menge Luft, und ein Mega8 mit 16MHz
leistet mehr als man denkt, effektive Programmierung vorausgesetzt.
Mein ASCII-Terminal mit 28*24 Zeichen läuft auf einem Mega-8 mit 8Mhz.

Gruß Jan

Autor: Markus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mußt Du alle 8 Bildschirmzeilen einer Textzeile auf einmal
zwischenspeichern? Reicht die Zeit nicht, um immer nur eine
Bildschirmzeile vorzubereiten?

Autor: Markus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Jan: Das mit dem 6Bit-Alphabet kann eigentlich nicht sein, da im
Beispiel Groß- und Kleinbuchstaben (mit Umlauten), Ziffern und ein paar
Sonderzeichen zu sehen sind. Das macht 29*2+10+x=68+x Zeichen. Wenn man
davon ausgeht, daß die Balkengrafik auch aus Zeichen besteht, dann sind
es sogar noch mehr Zeichen.

Autor: Jan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
>>Mußt Du alle 8 Bildschirmzeilen einer Textzeile auf einmal
>>zwischenspeichern? Reicht die Zeit nicht, um immer nur eine
>>Bildschirmzeile vorzubereiten?

Es sind 7 Zeilen. :-)
Nee, das ist zu knapp, glaube ich, bei 50 Zeichen pro Zeile allemal.
Das würde ich mit meinem jetzigen Kenntnisstand nicht hinkriegen.
Aber bestimmt gibt es noch ein paar Tricks, auf die ich noch nicht
gekommen bin...
Kennst du einen ??

Gruß Jan

Autor: Jan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>>Das macht 29*2+10+x=68+x Zeichen.
Jou, da hast du recht, dann wird das eng.
Aber bestimmt kann man noch irgendwo sparen,
wenn man sich richtig damit beschäftigt.
Vielleicht hat der Programmierer es ja auch geschafft
nur eine Bildschirmzeile als Bildspeicher zu halten,
wie Markus es vorgeschlagen hat. Wer weiss.
Da spart man gleich 200 Bytes.
Hier hat sich bestimmt jemand richtig Mühe gegeben
und alles aus dem Mega8 rausgequetscht.

Und jetzt will er das gern verkaufen, und ein paar Euro damit machen.
Ist doch Okay. Und der Preis ist auch moderat.
Verkauft allerdings nur Bausätze, keine Fertigteile.
Jaja, die Produkthaftung, CE, EMV undwasweisichnochalles...

Gruß Jan

Autor: Philipp Sªsse (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vorneweg: nein, ich habe das leider weder selbst aufgebaut noch kann ich
ein entsprechendes Programm vorweisen, bin also auch nur ein Theoretiker
in dieser Sache und muß mir ggf. ein "dann mach es doch!" anhören.

Trotzdem riskiere ich meinen Ansatz: keinen Zeilenpuffer, nicht einmal
für eine einzelne Zeile. Für jede Spalte haben wir rund 1 µs Zeit, bei
18 MHz und 6 Pixeln Spaltenbreite (5 Zeichenbreite + 1 Pixel Abstand)
sind das also 3 Takte pro Pixel. In der Lücke soll jeweils das nächste
Bitmuster geladen werden.

Wenn ich davon ausgehe, daß ich am Anfang des Zeichens in einem
Register die 5 horizontalen Bits für dieses Zeichen stehen habe, mache
ich also 5 mal z.B. OUT, LSL, NOP. Beim fünften Pixel höre ich nach dem
OUT auf und lade mit einem LD rd,X+ das nächste Zeichen der Zeile ins
Z-Register. Das sind zwei Takte, ersetzt also genau das LSL+NOP. Dann
kommt ein OUT von einem leeren Register, damit die Lücke schwarz wird.
Mit einem LPM hole ich mir jetzt die Bitmap der entsprechenden Zeile
des Zeichens in ein Register, dann geht es wie oben weiter.

Das heißt dann, daß die Lücke 4 statt 3 Takte dauert, aber das darf ja
eigentlich nichts ausmachen, oder? Das gesamte Zeichen kommt auf 19
Takte, also muß man den den µC doch etwas schneller takten, sonst
verschwindet das letzte Zeichen am rechten Bildschirmrand.

Müßte das nicht gehen?

Autor: Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich glaube, daß genau hier

   "und lade mit einem LD rd,X+ das nächste Zeichen der Zeile"

ein Problem liegt. Was Du so lädst, ist ja darzustellende Zeichen,
nicht aber das dieses Zeichen repräsentierende Bitmuster ...

oder meinst Du, daß in der Austastlücke ausreichend Zeit ist, um alle
Bitmusterzeilen der einzelnen darzustellenden Zeichen in einen
Pixelzeilenpuffer geladen werden können?
Dazu muss für jedes Zeichen in der Zeichendefinitionstabelle an der
durch die Scanzeile vorgegebenen Position ein Wert extrahiert werden;
diese Operation muss folglich 50mal erfolgen.

In C-Notation:

  for (i = 0; i < 50; i++)
  {
    Pixelzeilenpuffer[i] = Zeichentabelle[(Zeilenpuffer[i] * 8) +
Zeilenoffset];
  }

  (die 8 sei die Höhe der Zeichenmatrix)

Reicht dafür die zur Verfügung stehende Zeit aus?

Autor: Markus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich würde die Daten hier etwas anders anordnen: Erst die 1. Zeile aller
Zeichen, dann die 2. Zeile aller Zeichen usw. usf.
Damit muß man pro Zeile nur einmal die Zeile auswählen (ins ZH) und
kann dann den ASCII-Wert direkt ins ZL schreiben. Das Problem ist aber
wohl, daß der lpm volle 3 Takte braucht, man im HSync aber nur etwa 4
Takte pro Pixel zur Verfügung hat (bei 16MHz).  Man kann damit die 50
Zeichen sicher nicht aus dem ROM holen.

Markus

Autor: Markus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sollte "4 Takte pro Zeichen" heißen.
Der HSync hat 12µs = 192 Takte
200Take / 50 Zeichen = 4 Takte/Zeichen

Autor: kryon2000 (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Schaut euch mein Sourcecode an, der ist nun wirklich Zeitoptimiert und
deshalb sehr lang, Man kann die Bitmuster nicht wärend einer Ausgabe
erst berechnen und laden. Das muss vorher geschehen. Bei der
Zeilenausgabe muss jedes Pixel im RAM vorliegen damit es sehr schnell
raus gehen kann.

Und noch mal für alle, schaut euch die Screenshots von diesem CHIP an,
ES SIND 8 ZEILEN, am besten zu sehen bei q p y und Komma ect.

Bei 7 Zeilen würde ich ja auch 50 Byte SRAM für Videocash sparen.

Hier im Anhang ist nochmal der ASM code für meine Routine, falls ihr
den link weiter oben nicht gefunden habt.

http://www.4freeboard.to/board/thread.php?goto=las...


Ach ja, und es sind 6 Pixel breite Spalten, zu sehen an der
durchgezogene Linie im Textfeld. Und nochmal für die Theoretiker unter
uns, Wenn ich 300 Pixel (50*6) raus jagen will pro Zeilenehm ich pro
Pixel 2 Takte und nach jedem Zeichen einen zusätzlichen, somit habe ich
650 Takte. Im sichtbaren Bildschirmbereich würden ca. 750 Takte
angezeigt werden können.

Und Phillip, wir haben hier 16MHz, das macht pro 1µs = 16 takte ;-).
Ein Pixel demzufolge 2 Takte = 0,125µs oder 125ns.

Und der Zeichenvorrat bei ihm wird wohl auch 64 Zeichen betragen.

Autor: kryon2000 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Marcus
bei dieser Anordnung verschenkst du doch sau viel Flash speicherplatz.

Autor: Markus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@kryon:
Klar braucht die Methode viel Speicher, aber solange man nicht auch
noch Bilder darstellen will sollte das kein Problem sein.

Wie ich oben vorgerechnet habe, ist sein Zeichensatz wohl größer als 64
Zeichen.

bye
  Markus (mit "k")

Autor: Philipp Sªsse (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Rufus:
Da habe ich mich wohl undeutlich ausgedrückt. Wie Markus schon richtig
interpretiert hat, lade ich den ASCII-Wert des Zeichens aus dem RAM ins
ZL, um dann das Bitmuster über LPM zu laden (am Anfang der Zeile muß
also das ZH auf einen von acht Werten gesetzt werden, entsprechend der
Zeile innerhalb des Zeichens).

Und nein: ich will ausdrücklich keinen Puffer, auch nicht für eine
Zeile. Der beschriebene Ablauf erfolgt für jedes Zeichen:
LD ZL,X+      ;2
OUT Nullreg   ;1  Takt 3 Lückenbit
LPM r16, (Z)  ;3
OUT r16       ;1  Takt 7 1. Bit
LSL r16       ;1
NOP           ;1
OUT r16       ;1  Takt 10 2. Bit
LSL r16       ;1
NOP           ;1
OUT r16       ;1  Takt 13 3. Bit
...usw.

Also drei Takte pro Pixel, nur die Lücke hat vier.

Beim Zeilenwechsel können also andere Sachen gemacht werden.

@Kryon:
Um das Bitmuster zu laden brauchst Du zwei Takte für das LD und drei
für das LPM anstatt eines Shift-Befehls. Also vier zusätzliche Takte.
Ich meine, die kann man zumutbar in der Lücke zwischen zwei Zeichen
unterbringen.

In den 300 Pixeln sind bei mir die Lücken schon drin (5 Pixel
zeichenbreite + 1 Pixel Zwischenraum). Und ich schrieb selbst, daß 18
MHz für 50 zeichen knapp nicht ausreichen. Wenn man die NOPs wegläßt,
geht es natürlich schon, aber dann wird der letzte Pixel eines Zeichens
leicht breiter (was evtl. blöd aussieht) und der Abstand zwischen zwei
Zeichen breiter (was wohl weniger stört). Wir haben dann 15 Takte pro
Zeichen, dann geht es auch mit 16 MHz. Und das würde selbst mit 256
Zeichen funktionieren.

Im Flash geht man tatsächlich großzügig mit dem Platz um: in einem Byte
werden nur fünf Bits benutzt. Da ist dann entscheidend, wie viel Code
man insgesamt unterbringen muß.


Noch eine andere Idee: kann man über eine synchrone serielle etwas mit
halbem µC-Takt rausschieben lassen? Dann wäre dazwischen reichlich Luft
zum Laden!

Autor: Axel Viebig (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich wurde von einem Anwender von TV-Terminal auf dieses Forum
aufmerksam gemacht.

Um irgendwelchen Gerüchten den Boden zu enziehen: Beim TV-Terminal
werden alle dynamischen Daten ausschliesslich in einen beliebig oft
beschreibbaren SRAM-Speicher geschrieben und nicht etwa in Flash- oder
EEPROM-Speicher.

Die auf der Seite www.tvterminal.de herunterladbaren Videos entsprechen
dem abgefilmten Bildschirminhalt. Es wurde nichts herausgeschnitten oder
sonst irgendwie getrickst. Dass sich solche Manöver von selbst
verbieten, sollte klar sein.

Das TV-Terminal ist ein stabiles und ausgereiftes Produkt, kein
schneller Hack. Sein Design und seine Realisierung sind das Ergebnis
der Umsetzung einer Vielzahl eigener Ideen.

Mit freundlichen Grüssen

Axel Viebig

Autor: kryon2000 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Einen kleinen Denkfehler gibt es da schon, wir haben 128 Zeichen. Wenn
wir also ein High Byte für die Zeile nehmen, haben wir nur 256 Byte für
die Zeichenmatrix. 256/8 = 32 Zeichen. Das langt wohl nicht.

Autor: Markus K. (markus-)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Kryon:
Wie ich oben schrieb:
Man legt alle ersten Zeilen aller Zeichen hintereinander, dann erst
alle zweiten Zeilen aller Zeichen usw. usf.
Also z.B.
Zeile 1: $2100-21ff
Zeile 2: $2200-22ff
Zeile 3: $2300-23ff
usw. usf.

Man braucht damit natürlich 2KB Speicher für den gesamten Zeichensatz
(bei 8Zeilen hohen Zeichen), der dabei zwangsläufig 256 Zeichen
umfasst.

Markus

Autor: kryon2000 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ups...sorry...Gedankenfehler ;-)

Hier mal mit Input:

http://www.4freeboard.to/board/thread.php?threadid=26409

Ok, dann haben die eben den ATmega168 genommen, mit 16K Flash ist alles
drinn. Ich werde wohl dazu übergehen nur 7 Zeilen zu benutzen, die 8.
Zeile bemerkt man eh nie.

Autor: kryon2000 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Axel Viebig

Bitte schreib doch mal welchen Atmel du nun dafür benutzt hast.

Autor: Bob (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
meint ihr es wäre möglich ein farbsignal rein rechnerisch, ohne externe
schieber etc zu erzeugen, wenn man sich auf weiss/blau und schwarz
beschränkt!?

Autor: Max (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
wie kommst du denn auf diese Idee ?

Autor: Bob (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
wiss nicht? es gibt ja auch osd chips die das können. die kommen mit 4x
farbträger aus. also mit 16 oder 20 mhz ist doch ausreichend spiel,
wenn man sich auf eins zwei farben festlegt, oder?

Autor: Bob (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
gibt es was neues was pac man und evtl farbe angeht?? interessiert sei

Autor: Peter Sieg (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo. Ich bin relativ jungfräulich, was AVR's angeht ;-)
habe das Pollin Eval.Board 2.0 aufgebaut, ein paar Bascom Progrämmchen
geschrieben und alles funktioniert sogar..

Ich möchte das Pacman - ATmega8 Projekt jetzt gerne bauen und habe ein 
paar, wahrscheinlich blöde Fragen:

Was für ein Videosignal/Ausgang ist das, bzw. was kann/muss ich da 
anschließen? BAS-Monitor? Scart-Anschluß?

Zum aller ersten Test (Einschaltbild/Intro-Screen), dürfte es reichen:

1. das HEX-File mit PonyProg in den ATmega8 zu flaschen.
2. die Fuse-bits so zu setzen, das der externe 16MHz Quartz genutzt 
wird.
3. die beiden Widerstände und das Videokabel abzuschließen.

Die 'Joystick-Schalter' kann ich, nachdem ich ersteinmal ein Bild habe, 
ja immer noch nachrüsten..

Ist das so korrekt?

Danke für die Hilfe,
Peter

Autor: Peter Sieg (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hurra!!!
Siehe hier:
http://puppylinux.abcde.biz/c/?AVR:Pacman_mit_ATmega8

Um vernünftigen Credit für die Entwiklung zu geben, bitte ich den 
Authoren von AVR Pacmania, sich mit mir in Verbindung zu setzen!

Vielen Dank!! Super Sachen!!

Peter

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.