Announcement: there is an English version of this forum on 
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:
1 | .macro calculate_cursor_pointer |
2 | LDS tvt_temp1,tvt_cursory |
3 | LDI tvt_temp2,XSize |
4 | MUL tvt_temp1,tvt_temp2 |
5 | LDI Xl,low(ddram) |
6 | LDI xh,high(ddram) |
7 | ADD Xl,r0 |
8 | ADC Xh,r1 |
9 | LDS tvt_temp1,tvt_cursorx |
10 | LDI tvt_temp2,0 |
11 | ADD Xl,tvt_temp1 |
12 | ADC xh,tvt_temp2 ; <= Da stand vorher add |
13 | .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.....
Angehängte Dateien:
-
P1100282i.jpg
12,6 KB
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
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.
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.
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.
@ 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.
Angehängte Dateien:
-
amforth_screen.jpg
294 KB -
amforth_LR.jpg
318 KB
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
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?
Nö, das Bild ist schon in Ordnung.
Thread beobachten
Seitenaufteilung abschalten