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!

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

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

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

Gruß Jörg

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.

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.

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.

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

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

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

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.

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 !!!

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.

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.

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 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 wrote:

> Die Änderung hängt hier dran.

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

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.....

....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.

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.....