Forth-Computer mit ATMega 32 und Videoausgabe

[Christian Berger (casandro)]

Servus,

hier ist ein kleines AMForth-System welches gleich die Videoausgabe 
übernimmt.

Wie üblich hat OC1B das Sync und MOSI das Video. Sync über etwa 1k mit 
dem BAS Videoausgang verbinden und MOSI mit 330 Ohm mit dem Videoausgang 
verbinden. Den Videoausgang gegen Masse mit etwa 100 Ohm legen.
Wichtig, entweder die Schaltung mit einem Gatter entkoppeln, oder 
während des Brennens abklemmen.

Die Leitungen Clock und Data der Tastatur über Widerstände hochziehen 
und Clock an XCK sowie Data auf RX legen.

Fuses setzen, so dass der Quarz angesprochen wird (lfuse:0x7f 
hfuse:0x99).

Wenn alles funktioniert sollte auf dem Bildschirm die Startmeldung von 
amforth mit Versionsnummer da stehen.

Zum Forth-System findet man mehr Infos in den PDF-Dateien im Archiv.

Ansonsten ist aber alles relativ intuitiv:
2 3 + .
Gibt zum Beispiel 5 aus, wie man auch erwarten würde.

: quadrat dup * ;
definiert ein neues Wort namens quadrat, welches den Wert auf dem Stack 
quadriert.
Und mit
5 quadrat .
berechnet man das Quadrat von 5.

Ich möchte hierbei einigen Leuten und Teams danken.
Zunächst einmal dem amforth-Team welche das Forth-System gemacht haben, 
nur dadurch wäre so ein schönes interaktives System möglich.
Dann natürlich auch noch an Benedikt mit seinen tollen Fernsehroutinen, 
die ich allerdings hier nicht verwendet, sondern nur nachempfunden habe.

Wenn ich Lust und Zeit habe, programmier ich noch Tonausgaberoutinen 
dazu. Die Zeit misst das Gerät ja schon. (ungetestet)

Viel Spaß damit!

[Interessierter (Gast)]

läuft das auch auf der Hardware für den Basic-Computer?

http://www.jcwolfram.de/projekte/avr/chipbasic2/main.php

[Joerg Wolfram (joergwolfram)]

Nicht ohne Modifizierungen, da ich bei meinen Projekten die Videosignale 
ohne SPI erzeuge.

Gruß Jörg

[Christian Berger (casandro)]

Interessierter wrote:
> läuft das auch auf der Hardware für den Basic-Computer?
>
> http://www.jcwolfram.de/projekte/avr/chipbasic2/main.php

Soweit ich das überblicken kann, müsstest Du den Quarz gegen einen 16 
MHz austauschen und von Pin zum Ausgang einen 330Ohm Widerstand. (am 
besten schaltbar) legen.

Im Prinzip könnte man auch die Ausgaberoutine auf die andere Plattform 
portieren. Eventuell kommt aber Dein Monitor auch ohne anderen Quartz 
aus. Der hat dann halt ein Bild mit einer Zeilenfrequenz von 19,5 kHz 
und einer Bildwechselfrequenz von 62,5Hz. Und die Uhr läuft schneller.

[Frank Jonischkies (frajo)]

Servus Christian,

Habe mir auf einem Steckbrett den FORTH Rechner aufgebaut und er 
funktioniert super. Aber wie komme ich an das @ Zeichen? Habe schon 
verschiedene Tastaturen probiert.

Gruß Frank.

[Christian Berger (casandro)]

Frank Jonischkies wrote:
> Servus Christian,
>
> Habe mir auf einem Steckbrett den FORTH Rechner aufgebaut und er
> funktioniert super. Aber wie komme ich an das @ Zeichen? Habe schon
> verschiedene Tastaturen probiert.
>
> Gruß Frank.

Ähm.... gar nicht. Die Alt-Gr Umschaltebene ist noch nicht vorgesehen. 
Das muss ich mal besser machen. Das AMForth-Team hat in ihrem CVS 
sowieso eine potentiell bessere Variante. Ich muss die mal testen und 
gegebenenfalls noch weiter verbessern.

Was Du zwischenzeitlich machen kannst ist in der Datei keyboard.inc ein 
Zeichen umdefinieren welches Du nicht brauchst. Beispielsweise eine der 
F-Tasten wie kf7.

[Frank Jonischkies (frajo)]

Ja. Die keyboard.inc hatte ich mir schon angesehen. Sonst habe ich mich 
aber noch nicht mit dem Quellcode beschäftigt. Habe hier noch eine 
QWERTY Tastatur. Da ist @ auf SHIFT 2. Muß mal suchen, ob irgendwo die 
Belegung für QWERTY Tastaturen zu finden ist. Stammt die keyboard.inc 
von dir? Im amforth wird ja immer nur von einer seriellen vt100 
Anbindung gesprochen.

Gruß Frank

[Christian Berger (casandro)]

Frank Jonischkies wrote:
> Muß mal suchen, ob irgendwo die
> Belegung für QWERTY Tastaturen zu finden ist. Stammt die keyboard.inc
> von dir? Im amforth wird ja immer nur von einer seriellen vt100
> Anbindung gesprochen.

Ja, die keyboard.inc stammt von mir. da wird einfach der Keycode von der 
Tastatur genommen, und das ASCII-Zeichen nachgeschlagen. Das sind 2 
Tabellen, jeweils prinzipiell 256 Byte groß. Ich würde einfach erst 
einmal auf Papier alle Codes eintragen, und dann das in den Rechner 
übertragen. Bedenke, der Compiler mag viele Sonderzeichen nicht.

> Gruß Frank

Servus
  Casandro

[roboter (Gast)]

gute sache mit dem forth.

wie kann man dieses jetzt selber neu compilieren?
ist das der normale assembler von atmel der im avrstudio vorhanden ist?

mfg

[Christian Berger (casandro)]

roboter wrote:
> gute sache mit dem forth.
>
> wie kann man dieses jetzt selber neu compilieren?
> ist das der normale assembler von atmel der im avrstudio vorhanden ist?
>
> mfg

Also ich habe es mit dem normalen avra assembliert.

[Alexander Hauck (Gast)]

Hallo !!

Ich habe das jetzt auch getestet... :-)

Funktioniert wirklich toll (wäre gut, wenn du das mit der "@" Taste
noch irgendwie hinkriegst.

Hast Du mal einen Dauertest gemacht ?? - Bei meiner Routine (Die welche 
noch im Trunk-Verz. bei source-forge liegt) hatte ich nämlich das 
Problem, dass sicvh der AVR irgendwann resettet hat. Ich habe nie 
herausgefunden - wieso...
Deswegen habe ich da auch nicht mehr weiter gearbeitet...

TOLLE SACHE !!!

[Christian Berger (casandro)]

Alexander Hauck wrote:
> Hallo !!
>
> Ich habe das jetzt auch getestet... :-)
>
> Funktioniert wirklich toll (wäre gut, wenn du das mit der "@" Taste
> noch irgendwie hinkriegst.

OK, zur Zeit habe ich wenig Zeit. Die optimale Lösung wäre wohl gleich 
die Unterstützung beliebiger Tastaturebenen zu implementieren.

> Hast Du mal einen Dauertest gemacht ?? - Bei meiner Routine (Die welche
> noch im Trunk-Verz. bei source-forge liegt) hatte ich nämlich das
> Problem, dass sicvh der AVR irgendwann resettet hat. Ich habe nie
> herausgefunden - wieso...

Meinst Du die Video-Routinen? Ich hab mir die leider nur mal grob 
angeschaut. Eine potentielle Fehlerquelle sehe ich darin, wenn Du 
Benedikts Videocode unverändert übernommen hast. Der kann zwar X 
Taktzyklen Jitter durch Befehle ausgleichen. Wird jedoch die Ausführung 
der Unterbrechungsdienstroutine länger verzögert (z.Bsp durch 
Flash-Schreibzugriffe) so ist das Ergebnis suboptimal. Da hab ich in 
meinem Programm ein besseres Stück drin. Das berechnet die Differenz und 
dividiert das Modulo 16. Damit hab ich zwar beim oben genannten Problem 
eine Bildstörung, aber sonst ist das erträglich.

> Deswegen habe ich da auch nicht mehr weiter gearbeitet...
>
> TOLLE SACHE !!!

Danke! Was ich persönlich noch gerne machen würde, wäre die Auflösung 
auf 64x16 zu verändern, damit das genau in einen Block passt. Dann 
könnte man den Massenspeicherzugriff impementieren. Dann könnte man das 
Teil wirklich zum Entwickeln verwenden. Leider müsste man dafür wirklich 
dann den AtMega644 verwenden. Ich bräuchte da aller mindestens etwa 17 
MHz. Mit 20 MHz sollten die Zeichen sogar erträglich ausschauen. Die 2 
Kilobyte RAM werden auch da etwas zu wenig.

[Christian Berger (casandro)]

Ich glaube, da ist bei mir auch noch ein Fehler in der Routine drin, 
welche die Zeichen in den Zeichenspeicher schreibt. Manchmal kommen die 
Zeichen an eine falsche Position.

[Christian Berger (casandro)]

Alexander Hauck wrote:
> Hallo !!
>
> Ich habe das jetzt auch getestet... :-)
>
> Funktioniert wirklich toll (wäre gut, wenn du das mit der "@" Taste
> noch irgendwie hinkriegst.

Die Änderung hängt hier dran.

[Christian Berger (casandro)]

Christian Berger wrote:
> Ich glaube, da ist bei mir auch noch ein Fehler in der Routine drin,
> welche die Zeichen in den Zeichenspeicher schreibt. Manchmal kommen die
> Zeichen an eine falsche Position.

Ahh, gefunden!
tvtext_neu.inc:

.macro calculate_cursor_pointer LDS tvt_temp1,tvt_cursory LDI tvt_temp2,XSize MUL tvt_temp1,tvt_temp2 LDI Xl,low(ddram) LDI xh,high(ddram) ADD Xl,r0 ADC Xh,r1 LDS tvt_temp1,tvt_cursorx LDI tvt_temp2,0 ADD Xl,tvt_temp1 ADC xh,tvt_temp2 ; <= Da stand vorher add .endmacro

Ich kann es leider im Moment nicht testen.

[Christian Berger (casandro)]

Christian Berger wrote:

> Die Änderung hängt hier dran.

Ach ja, die neue Version braucht keine Pullups mehr an der 
Tastaturschnittstelle.

[Alexander Hauck (Gast)]

Hallo !

Warum muss eigentlich ein Forth Block unbedingt 1024 Bytes haben ??
Benutze doch einfach 512B Blöcke und eine Auflösung von 32x16 (oder noch 
kleiner) dann hast du auch bei avr's mit wenig Ram noch Platz.

Hast du eigentlich vor deine Video- und Tastatur-Routinen (Wenn sie 
stabil laufen) wieder in AMForth 2.x einfliessen zu lassen ?? Es wäre 
nämlich cool, wenn man in AMForth einfach eine Opion für bedingte 
Compilierung im configfile hätte. Der AVR sollte natürlich mind.2KB Ram 
haben...

P.S. wäre es sehr schwer die Video-Ausgabe für 16x16 Zeichen - 
Bildschirm füllend - umzuschreiben? Also jedes Zeichen doppelt hoch und 
breit ?
Ich denke mal die doppelte Höhe wäre das grösste Problem...
Tschüss, Alex.....

[neuer (Gast)]

....Warum muss eigentlich ein Forth Block unbedingt 1024 Bytes haben 
??...

weil das der textseitenstandart ist. jede seite hat 1024 byte. stammt 
aus den jahren , wo das forth mal erschaffen wurde. hat sich nicht 
geändert.
wenn es 1024 byte hätte wäre das ein vermurkstes forth.

[Christian Berger (casandro)]

Alexander Hauck wrote:
> Hallo !
>
> Warum muss eigentlich ein Forth Block unbedingt 1024 Bytes haben ??
> Benutze doch einfach 512B Blöcke und eine Auflösung von 32x16 (oder noch
> kleiner) dann hast du auch bei avr's mit wenig Ram noch Platz.

Naja, erstmal weiche ich dann vom Standard ab, und zweitens reicht 32x16 
nicht aus, um einen Brief oder so was zu schreiben. Die Vision ist ja, 
dass man damit einen Rechner hat, mit dem man arbeiten kann.

> Hast du eigentlich vor deine Video- und Tastatur-Routinen (Wenn sie
> stabil laufen) wieder in AMForth 2.x einfliessen zu lassen ?? Es wäre
> nämlich cool, wenn man in AMForth einfach eine Opion für bedingte
> Compilierung im configfile hätte. Der AVR sollte natürlich mind.2KB Ram
> haben...

Im Moment ist das Projekt mehr oder weniger ein Fork, ich habe aber 
überhaupt nichts dageben, wenn die das übernehmen. Nur im Moment ist es 
noch nicht gut genug.

> P.S. wäre es sehr schwer die Video-Ausgabe für 16x16 Zeichen -
> Bildschirm füllend - umzuschreiben? Also jedes Zeichen doppelt hoch und
> breit ?

Das hängt von Deinen Qualitätsanforderungen ab. Einfach die Schrift zu 
skalieren sollte folgende Anderungen nach sich ziehen:
1. Konstanten für Bildgröße ändern
2. Konstanten für Bildlage ändern
3. SPI mit halben Takt laufen lassen (da gibts ein Bit dafür)
4. Zeilenzähler vor Berrechnung der ROM-Adresse durch 2 teilen oder auf 
16 Zeilen-Zeichensatz umbauen.

> Ich denke mal die doppelte Höhe wäre das grösste Problem...
> Tschüss, Alex.....

[Vadim Yatlov (Gast)]

Hallo alle!

Ich möchte erneut Interesse an der Forth-System
und vorschlagen, um es ...

Lubos Pekny, mFC - modular Forth Computer
www.forth.cz/Download/MFC/mFC.html

[Christian Berger (casandro)]

Vadim Yatlov wrote:
> Hallo alle!
>
> Ich möchte erneut Interesse an der Forth-System
> und vorschlagen, um es ...

Ahh, interessant.
Leider habe ich ein kleines Problem mit amforth. Es ist für mich zu 
statisch. Man kann beispielsweise den Speicher nicht dynamisch 
verwalten. Somit ist es leider nicht möglich, den Rechner wie einen 
normalen Computer zu verwenden.
Ich denke da im Moment über ein neues Projekt nach. Es wäre ein 
Dateisystem im Flash. Man könnte Dateien speichern und die dann sogar 
direkt ausführen. In so einem System könnte man dann auch 
Quellcodedateien speichern und diese auf dem Chip selbst zu nativen Code 
compilieren.

> Lubos Pekny, mFC - modular Forth Computer
> www.forth.cz/Download/mFC/mFC.html <= Da war ein Tippfehler

Sehr interessant.

[Charly B. (charly)]

abo

[Takka Tukka (Gast)]

Funktioniert das "abo" eigentlich noch ?

[Reisender (Gast)]

Muss mal dumm fragen:

Im ersten Post steht ja:

>Wie üblich hat OC1B das Sync und MOSI das Video. Sync über etwa 1k mit
>dem BAS Videoausgang verbinden und MOSI mit 330 Ohm mit dem Videoausgang
>verbinden. Den Videoausgang gegen Masse mit etwa 100 Ohm legen.

Dem kann ich noch folgen, aber hier:

>Wichtig, entweder die Schaltung mit einem Gatter entkoppeln, oder
>während des Brennens abklemmen.

werde ich dann doch unsicher.

In dem ZIP ist leider kein Schaltplan, aber da "wie üblich" dasteht, 
kann mir vielleicht einer einen Link auf das "Übliche" hier posten.

Das wäre nett.

[Christian Berger (casandro)]

Reisender wrote:

>>Wichtig, entweder die Schaltung mit einem Gatter entkoppeln, oder
>>während des Brennens abklemmen.
>
> werde ich dann doch unsicher.

Naja, das Problem ist, dass die Pins, welche die Videoausgabe machen, 
auch für die Programmierung zuständig sind. Wenn Du jetzt die 
Videoschaltung (die mit den Widerständen) drann lässt, so belastest Du 
Deinen Programmierer zu stark und die Spannung bricht zu weit zusammen 
um ein Bild zu bekommen.

Du kannst das vermeiden, in dem Du entweder die Schaltung beim 
programmieren abklemmst, oder einen Buffer aus, zum Beispiel, einem 
ODER-Gatter pro Port machst. Dabei schließt Du die beiden Eingänge des 
ODER-Gatters parallel und Du erhältst einen "digitalen Verstärker", der 
das entkoppelt.

[Reisender (Gast)]

@ Christian

Vielen Dank für die Erklärung. Ich habe mich missverständlich 
ausgedrückt. Ich hätte ganz gerne einen Link auf einen Schaltplan.

Da ich sowas überhaupt noch nie gebastelt habe, habe ich keine 
Erfahrungen und weiss demnach auch nicht was "üblich" ist. Auch wenn 
dann in der Schaltung (deren Link ich hoffentlich hier bekomme) das 
Gatter fehlt, wäre das trotzdem schon hilfreich.

Ich sehe z.B. das in der Beschreibung einmal der Ausdruck "Videoausgang" 
und einmal der Ausdruck "BAS Videoausgang" verwendet wird. Ein 
BAS-Ausgang mag immer ein Videoausgang sein, aber es gibt als 
Videoausgang auch S-Video, RGB+Sync uswusf. Das soll jetzt keine Kritik 
sein, sondern nur meine vorsichtige Nachfrage nach einem Schaltplan 
begründen.

Ich hoffe Du/Ihr versteht das.

[Peter Sieg (petersieg)]

Ich weiß.. 6J her.. funktioniert trotzdem prima!
Von dem AVR-Test-Brett wird nur der AVR+16MHz Quarz, Strom und die 
Video+PS/2 Buchse links unten benötigt.

Peter

avrdude:
avrdude -c usbtiny -p m32 -e -U flash:w:main.hex -U 
eeprom:w:main.eep.hex
avrdude -c usbtiny -p m32 -U lfuse:w:0x7f:m -U hfuse:w:0x99:m

[Wolfgang (Gast)]

Peter Sieg schrieb:
> amforth_screen.jpg

An der Bild-"Qualität" sind hoffentlich deine Canon PowerShot A70 und 
Wackelei bei der Aufnahme schuld oder kommen die Signale so verzerrt aus 
der Elektronik raus?

[Christian Berger (casandro)]

Nö, das Bild ist schon in Ordnung.