Announcement: there is an English version of this forum on Auch wenn noch nicht alle Funktionen voll ausgetestet sind, gibt es hier
endlich das erste Release des BASIC-Computers mit dem Mega644. Es gibt
jede Menge Neues, allerdings zu Lasten der Abwärtskompatibilität zu
früheren Versionen.
Features:
ls Eingabegerät dient eine normale PS2-Computertastatur, als
Ausgabegerät ein Fernsehgerät mit Scart-Eingang (Farbe) oder BAS-Eingang
(Graustufen) oder auch verschiedene PAL-/NTSC-taugliche TFT-Displays.
- 95 Programmzeilen mit maximal 32 nutzbaren Zeichen, Fullscreen-Editor
- 8 Programme im internen Flash
- Tiny-Basic-Programmiersprache mit Erweiterungen
- Eigene Fehlerbehandlung mit ONERR möglich
- 30x23 Zeichen mit maximal 8 Vorder- und Hintergrundfarben und
- Pseudografik im Textmodus
- 3 Videomodes mit Vollgrafik und Farbpalette
* 168x116 in 2 aus 8 Farben
* 120x76 in 4 aus 8 Farben
* 84x58 in 8 aus 8 Farben
- Punkte, Linien, Rechtecke und Kreise (Ellipsen), auch gefüllt
- PAL/NTSC und Synchronsignale über Jumper einstellbar
- PS2-Tastatur zur Eingabe, Keyboard-Layout ist dauerhaft umschaltbar
- 1-Kanalige Audioausgabe (Noten, Rauschen) mit Hüllkurve
- serielle RS232-Schnittstelle mit 1200 Baud und Ladungspumpe
- parallele Druckerschnittstelle, auch als I/O und Analogeingänge
- optionales Daten-EEPROM (24C64) für Datenlogger etc
- Funktionen für bis zu 8 LM75 Temperatursensoren
- Up/Download von Programmen über die serielle Schnittstelle
- Listingdruck über die Druckerschnittstelle
- automatischer Start des 1. Programmes nach Einschalten über Jumper
- Tastenkombinationen für Abbruch, Neustart, Screenshot
- Monitor mit Variablen- und Stackanzeige, Einzelschrittbetrieb
- Universelle I2C-Ansteuerung
- Einfaches Dateisystem auf ATMEL Dataflash
- Clone-Funktion zum Kopieren der Software auf weitere Controller
Was noch fehlt, sind ein paar Beispiele und der Zeichensatz ist noch
nicht
voll belegt.
Homepage ist in Arbeit, wird aber noch etwas dauern...
Gruß Jörg
Angehängte Dateien:
-
sinus-mode2.png
495 Bytes
Bevor Fragen kommen, die Hardware ist die gleiche wie bei den früheren Versionen, halt nur ein anderer Controller und ein 20MHz Quarz. Die Hardware-Doku ist noch von der alten Version. Anbei noch ein Screenshot in Grafikmode 2 (120x76x4)
1 | PROGRAM 1:Sinus-c |
2 | 01 CLS :VMODE 2 |
3 | 02 DRAW 35,0,35,119,1 |
4 | 03 PLOT 35,0 |
5 | 04 FOR X=0 TO 119 |
6 | 05 W=30*X:V=SIN(W)/10 |
7 | 06 DRAWTO 35-V,X,2 |
8 | 07 NEXT :COLOR 3 |
9 | 08 ? @60,0;"Sinus" |
10 | 09 WKEY Z |
11 | # |
Gruß Jörg
Hallo Joerg, erst einmal vielen Dank - schnell einen Controller besorgen und dann mal sehen, was Du wieder schönes gezaubert hast..... Viele Grüsse Otto
Hallo Jörg, wo hast Du den "ATmega644-20PU" denn her ? Gruss Otto
Ich les den Thread schon seit anfang an (also den alten ;) ). Echt erstaunlich was du da auf die Beine stellst! Wenn ich Zeit habe muss ich mir auch so nen kleinen computer bauen. Und dieser hat den Namen Computer echt verdient!
@Otto Da hatte ich damals meine gekauft: http://stores.ebay.de/AVR-Controller-PAKTEK @Alle In den Transferprogrammen (Perl-Scripten) ist noch ein "Fehler" drin, anstelle 9600 muss es natürlich 1200 bei der Bitraten-Einstellung heissen. Das liegt an meinem IBM T23, wo ich die Bitrate *8 einstellen muss. Die Webseite ist mittlerweise auch online: http://www.jcwolfram.de/projekte/avr/chipbasic2/main.php Gruß Jörg
Mein mega644 ist auch schon unterwegs. "Ich freu mich drauf"^^
@joerg wolfram wieder mal : deep respect !!! echt irre was du alles in so einem controller reinprügelst :-)
Geil wäre das noch mit Forth. Für diese Programmiersprache gibt es echte Compiler welche auf dem AVR selbst laufen. http://sourceforge.net/projects/avrforthlike/ Ist so einer (so weit wie ich weiß). Forth Compiler hätten halt nicht nur den Vorteil, dass die schneller als interpretierte Sprachen sind, nein, es ist sogar eine Entwicklungsumgebung dabei. (läuft dann auch auf dem Zielsystem)
Man MUSS eine Sprache interpretieren, wenn man sie zur laufzeit im AVR programmieren, laden und ausführen will. Also total am Projekt vorbeigeschossen ;)
Hauke Radtki wrote: > Man MUSS eine Sprache interpretieren, wenn man sie zur laufzeit im AVR > programmieren, laden und ausführen will. Also total am Projekt > vorbeigeschossen ;) Nein, wenn der Compiler auf dem AVR selbst läuft, kannst Du das auch so machen. Du kannst ja den Flash des AVRs zur Laufzeit beschreiben. Somit kannst Du sehr wohl die Programme zur Laufzeit programmieren, laden und ausführen.
Also ich hab mir gerade die Homepage angeschaut, das ist wirklich beeindruckend. Ich weiß nicht, wie viele Taktzyklen Du noch in der hsync ISR frei hast, aber ich hätte hier noch etwas Code für FM-Synthese. Ich kann auch im Februar meinen Spielzeugvocoder auf AVR-Assembler portieren. Dann hätte man Sprachsynthese. Wenn ich mal wirklich Zeit habe, dann kann ich auch noch probieren eine simple Spracherkennung zu implementieren.
Ach ja, falls Du aus der Sache etwas 'Profit' schlagen möchtest, 2600 sucht ständig Artikel. Du bekommst dafür ein T-Shirt und ein Jahresabo der Zeitschrift. http://www.2600.com/magazine/
...Geil wäre das noch mit Forth.... leider hast du vergessen, das 90% der teilnehmer hier die sprache forth nicht interpretieren können, geschweige damit etwas zu proggen. ich verfolge sei 20 jahren dieses forth, die anhänger sind rar, die überzeugten noch rarer. es gibt da kein durchstehvermögen. schade...
das gleich wird auch mit diesem basic-computer(644) geschehen. kurzsichtig in einer sprache zusammengestellt, die der geringste teil nachverfolgen kann (linux). warum wird nicht einfach der assembler vom avr-studio genommen. jeder kann dieses programm verfolgen und studieren. in 6 monaten redet keiner mehr über dieses eigentliche geniale produkt. nur noch noch einpaar hardliner und die sind wenig....schade. aber wenn man das nicht anders haben möchte...na...denn...ihr hardliner.
Das Ding ist mit Assembler programmiert. Kannst dir in AVR Studio ansehen und auch compilieren. Du musst halt das gepackte Verzeichnis öffnen, um zu sehen, wie er es gemacht hat. Aber dazu ist ein Windows-Anwender, wie z. B. ich, auch in der Lage...
Habe es vermutet. Aber ich hab einen schlechten Tag und musste mich abreagieren... Ich finde das Teil echt super. Allerdings habe ich noch keine Anwendung für mich gefunden. Gruß Gerd
...Aber ich hab einen schlechten Tag und musste mich abreagieren..... scheisse gelaufen , wenn man straff im arbeitsleben steht, oder? hast du keine frau zum abreagieren ? du bist schon so ein sozialschwacher troll....lol....
...Du musst halt das gepackte Verzeichnis öffnen, um zu sehen, wie er es gemacht hat. .... das ist schomal scheisse, so ein umstand.
Gerd G. wrote: > Ich finde das Teil echt super. Allerdings habe ich noch keine Anwendung > für mich gefunden. > > Gruß Gerd Also was mich im Moment noch ein wenig stört ist der BASIC-Interpreter. Der bestehende ist jedoch anscheinend gut genug um als Sprungbrett für die weitere Entwicklung zu dienen. Also die Anwendung liegt doch auf der Hand. Anstelle eines teueren Aldi-PCs kann man sich jetzt den Rechner selber bauen. Einen Rechner, welchen man wahrscheinlich sogar komplett verstehen kann.
@Christian die ISR ist eigentlich schon übervoll, wenn ein serielles Zeichen und ein Zeichen von der Tastatur in der gleichen Zeile kommen, kann es schon zu Bildstörungen kommen. Aber das ist so selten und tritt nur auf, wenn man es provoziert. Einfacher ist es, einen zweiten Chip über I2C anzusteuern. Ich denke, mit so einem Teil kann man lernen, wie ein Computer funktioniert. Man kann ihn auf einem Steckbrett aufbauen, kann selbt Programme schreiben, messen, steuern, regeln... Einen Compiler mit einzubauen hatte ich zwischenzeitlich auch schon mal vor, halte es aber für unzweckmäßig. In der aktuellen Version wird schon fast alles in Token umgesetzt, auch Zahlen und Funktionen. Wenn man aber zu weit in diese Richtung geht oder gar optimieren will, wird das Rückübersetzen in den urprünglichen Quelltext sehr aufwändig oder gar unmöglich. Und dann hat man Source UND Compilat im Speicher. Auch in der jetzigen Version gibt es ein paar Effekte, z.B.: - aus A=$010 wird nach dem Speichern A=$10, Wert wird als Ein-Byte-Hexvalue gespeichert - aus A=$110 wird nach dem Speichern A=$0110, Wert wird als Zwei-Byte-Hexvalue gespeichert Die "Assemblerproblematik" kommt wahrscheinlich jedes mal wieder neu auf, meiner Meinung nach sind das Leute, die Open Source Entwickler als Dienstleister und sich als König Kunde verstehen. Gruß Jörg
>Die "Assemblerproblematik" kommt wahrscheinlich jedes mal wieder neu >auf, meiner Meinung nach sind das Leute, die Open Source Entwickler als >Dienstleister und sich als König Kunde verstehen. wird es aber wohl leider immer geben :-( ich bin zwar selbst nicht in asm bewandert, aber wenn mich ein algorithmus interessiert der nur in asm existiert und ich diesen verstehen will komme ich eben nicht um asm rum, so einfach ist das. aber mal im ernst : wie lange baust du schon an dem dingen rum ? ich meine alles in asm zu machen, da muß man doch wirklich fit sein, viel zeit haben und einen irre guten überblick ? ich programmiere recht viel (in c) und mir fällt es manchmal schwer den überblick zu behalten, wie machst du das ? (erstaunt ist ....)
Hallo Joerg, ich finde es ganz toll, dass Du uns Dein Projekt kostenlos zur Verfügung stellst - der Sinn desselben ist, in "Basic" zu programmieren und nicht am "Betriebssystem" herumzubasteln. Da aber die "Basic-Fraktion" in die Jahre gekommen ist und alle "Klick-Buntis" meinen, nur noch mit wichtig klingenden Programmiersprachen um sich werfen zu müssen, obwohl sie diese gar nicht beherschen, wird es immer solche posts geben - da ist sicher auch Neid mit bei. Davon abgesehen würde ich durchaus auch einige Euro dafür bezahlen, wenn Du Deine Produkte fix und fertig oder als Bausatz vertreiben würdest - wäre mir der Spass echt wert......und ich würde immer noch nicht darüber "mosern", dass Du unter Linux entwickelst. Gruss Otto
Ich habe nichts gegen Assembler, habe es ja lange genug genutzt. Allerdings möchte ich C und C++ nicht mehr missen. >Also was mich im Moment noch ein wenig stört ist der BASIC-Interpreter. >Der bestehende ist jedoch anscheinend gut genug um als Sprungbrett für >die weitere Entwicklung zu dienen. > >Also die Anwendung liegt doch auf der Hand. Anstelle eines teueren >Aldi-PCs kann man sich jetzt den Rechner selber bauen. Einen Rechner, >welchen man wahrscheinlich sogar komplett verstehen kann. Es ist auf jeden Fall eine gute Grundlage um sich sein eigenes Gerät zusammen zu bauen. Man muss es ja nicht unbedingt mit dem Basic probieren, obwohl ich schwer am überlegen bin, was man da noch herausholen kann. Für Basic ist der AVR gut ausreichend, aber für eine andere Sprache wäre ein ARM angemessener...
TheMason wrote: > ich programmiere recht viel (in c) und mir fällt es manchmal schwer den > überblick zu behalten, wie machst du das ? (erstaunt ist ....) Ich hab ja auch schon mal größere Dinge in Assembler programmiert und kann einfach sagen, Assembler ist wie ein vereinfachtes C. (zumindest auf guten Controllern) Ich habe mir auch schon mal überlegt, etwas in C zu programmieren, nur da scheiterte ich schon an der Variablendefinition. Solche Dinge sind in Assembler viel einfacher. Also es ist im Prinzip nicht schwieriger wie in C. C ist ja auch keine Hochsprache.
Mit den AVRs habe ich im Frühjahr 2006 begonnen, Auf Arbeit hatte ich auch schon vorher mal ein bisschen probiert, bin aber beim MCS51 geblieben. Erstes Projekt und "Stein des Anstosses" war eine kleine Spieldose mit zwei Stimmen und 5 Melodien zum Einschlafen für unseren damals gerade geborenen Sohn. Dabei kam mir die Idee mit der Videoausgabe zum Debuggen und letztendlich die mit dem Einchip-Computer. Bis zur ersten Release Mega16 hat es dann ungefähr ein halbes Jahr gebraucht, die Mega32-Version ist zu großen Teilen während des Jahreswechsels 2006/2007 entstanden, danach kamen dann einige Konzeptionen die ich wieder verworfen habe. Mittlerweile bschränkt sich die für meine Projekte verfügbare Zeit auf die Nachtstunden :) und so geht es etwas schleppender voran. Mikrocontroller programmiere ich eigentlich nur in Assembler, da das für mich einfach übersichtlicher ist. Anstelle vieler Variablen und Funktionen gibt es ein paar Register und Speicher. Damit kann ich Algorithmen im Kopf entwickeln, egal wo ich gerade bin. Dann noch eintippen, Fehler rausmachen und fertig (oder auch nicht ;)... Für große Projekte "bastle" ich einen großen Teil der Zeit an den Konzepten. Wie kann ich die Funktion aufteilen? Was für Schnittstellen brauche ich? Für die mehrfache Verwendbarkeit von Codeteilen habe ich mir azu eine Art "Bibliothekskonzept" ausgearbeitet, welches die erweiterten Makrofunktionen des AVRA-Assemblers benutzt. So wird nur der Code aus der Library mit eingebunden, den ich auch wirklich brauche und das nur durch Aufruf des Makros. Anderen Code als auseinanderzunehmen oder Kompatibilität zu anderen Systemen zu wahren halte ich persönlich für Innovations-hinderlich, weil es das Denken in bekannte Bahne lenkt und somit einschränkt. Und so ist alles (bis auf den Zeichensatz, den ich aus einem alten Buch "abgemalt" habe) auf meinem "eigenen Mist gewachsen". Und noch eine gute Nachricht: Thomas Heldt, der auch die hier vorgestellen AVR-Webserver als Bausatz vertreibt, wird demnächst auch einen BASIC-Computer-Bausatz im Angebot haben. Gruß Jörg
Hallo alle zusammen, nachdem Jörg zugestimmt hat habe ich bereits ein neues Board erstellt und werde im kommenden Monat die Platinen fertigen lassen, es wird dann sowohl Leerplatinen als auch Bausätze geben. Der Preis wird wieder so sein das ich den Bausatz fast zum Selbstkostenpreis im Shop meiner Frau anbieten werde. Allerdings lohnt sich das alles nur wenn wenigstens 10 Bausätze, Preis ca. 34,95 EUR, verkauft werden um die Kosten für die Platinen raus zu holen. Wer also Interesse an einem Bausatz oder einer Leerplatine hat kann sich schon jetzt bei mir melden und wenn dann 10 Bestellungen da sind stelle ich den Bausatz und die Leerplatinen im Shop ein. Die Lieferzeit wird dann ca. 3 Wochen dauern da ich die Platinen dann mit Bestückungsdruck ordern werde, und eine Anleitung will auch geschrieben sein, dazu baue ich dann selber erst einmal ein Board auf um sicher zu gehen das alles funktioniert.
Hi Leute, habe da mal ne Frage was das Nschließen eines VGA Monitors an den Mini-PC angeht. Habe da so einen alten PC-Monitor der bis zuletzt (vor 3 Tagen) einwandfrei funktioniert hat. Weil aber das Bild langsam matschig wurde hab ich gedacht mach ich mal einen Stecker für den Mini-PC dran. Leider funktioniert es nicht. Ich habe VSync und HSync und RGB Kanäle angeschlossen aber es kommt kein Bild. Der Monitor geht aus dem Standby raus und zischt aber sonst nichts. Vlt. habe ich ihn auch schon gschrottet bei den versuchen ihn anzuschließen glaub ich aber nicht. Weiß jemand Antwort? Gruß Robin T.
Hallo Robin, wenn es kein "Multisync" ist, wird er mit dem Signal des BASIC-COMPUTER nicht zurecht kommen. Gruss Otto
Was heißt Multisync? Ich dachte H- und VSync reichen? Viel mehr Anschlüsse sind da ja auch nicht die irgendwie die Bezeichnung Synchronisation tragen.
Robin T. wrote: > Ich dachte H- und VSync reichen? Viel mehr Anschlüsse sind da ja auch > nicht die irgendwie die Bezeichnung Synchronisation tragen. Das Problem ist, welche vertikalen und horizontalen Ablenkfrequenzen Dein Teil kann. Du bräuchtest 15,625 kHz Horizontal und 50 Hz Vertikal. Das kann kaum ein normaler VGA-Monitor.
mmh. Mist. Jörg hat ja gesagt ein NTSC/PAL tauglicher Bidlschirm kann an den Mini-PC angeschlossen werden. Aber ich vermute mal das mein alter Röhrenmonitor das nicht kann oder?
Robin T. wrote: > mmh. Mist. Jörg hat ja gesagt ein NTSC/PAL tauglicher Bidlschirm kann an > den Mini-PC angeschlossen werden. Aber ich vermute mal das mein alter > Röhrenmonitor das nicht kann oder? Tipp mal die Bezeichnung des Monitors in eine Suchmaschine rein. Vielleicht findest Du da was. Also NTSC oder PAL muss er nicht können, nur das Timing muss er unterstützen. Vielleicht kannst Du aber mal probieren, den Controller zu übertakten. Dann kommst Du näher an das VGA Timing dran.
Das sollen angeblich die Daten sein: Horizontaler Frequenzbereich: 30 - 64 kHz Vertikaler Frequenzbereich: 50 - 100 Hz Maximale Auflösung: 1280 x 1024 Ich weiß aber auch nicht was der BASIC-PC raus gibt. Ich werde mal nachmessen
Achso und Die Synchronisationspegel sind TTL TGB ist 0,7V. Die Auflösung ist falsch. Maximal geht 1024X768. Hab das Hanbuch gefunden.
Robin T. wrote: > Das sollen angeblich die Daten sein: da macht er nicht mit: > Horizontaler Frequenzbereich: 30 - 64 kHz Das ginge sogar: > Vertikaler Frequenzbereich: 50 - 100 Hz > Ich weiß aber auch nicht was der BASIC-PC raus gibt. Ich werde mal > nachmessen Der BASIC-PC muss horizontal 15,625 kHz und Vertikal 50 Hz ausgeben. Dein Monitor geht leider horizontal nicht so weit runter.
VGA (über ein CPLD am Videoausgang) hatte ich am Anfang mal mit vorgesehen, die horizontale Austastlücke war aber zu kurz für Sound, Zufallsgenerator, Tastaturabfrage und serielle Schnittstelle. Und so ist es letztendlich beim TV-Out geblieben. Noch etwas anderes. Da die Atmel Dataflash bei den meisten Versendern nicht zu bekommen sind und es sie obendrein nur in SMD gibt, habe ich mir folgendes überlegt: Alternativ (im Config-Menü umschaltbar) soll auch ein I2C EEPROM vom Typ 24C512 (extern oder im nicht mehr genutzten EEPROM-Sockel mit Adresse 0) verwendbar sein. Dort passen zwar nur max. 16 Dateien drauf, aber immerhin besser als gar nix. Gar nix aber eigentlich auch nicht, da der Mega644 auch selbst schon 8 Programme speichert. Die Frage ist nur, ob ich den Code noch irgendwo unterkriege... Gruß Jörg
Hallo Jörg, heute habe ich endlich den Controller bekommen und programmiert - dabei gab es das kleine Problem, dass ich mit dem STK500 nicht exakt auf die Fuse-Werte komme, die Du in der "Liesmich" angegeben hast. Ich komme bei "FUSE LOW" nicht auf "E6", sondern nur auf "E7". Nachdem ich mit dem "Fuse-Calculator" so ziemlich alle halbwegs sinnvollen Einstellungen durchprobiert hatte, habe ich den Chip mit diesen Fuses programmiert - "Versuch macht klug" dachte ich mir. Frage: welche Fuses müssen gesetzte sein? (ich vermute, im wesentlichen: "Quartz Full Swing", "Preserve eeprom", "BOD-Level 4,3V", "Boot....default", "JTAG aus") Der Chip zeigte auf dem Fernseher (SCART) zeigte mit gesetztem "NTSC-Jumper" nach dem Einschalten sofort ein farbiges Bild - so wie auf Deiner Homepage. Dann der erste Versuch mit: 1 CLS 2 Print "Hallo"; 3 GOTO 2 - zunächst alles klar, dann wanderte das Bild. Darauf zog ich den "NTSC-Jumper". Nun ist die Textausgabe durch das Programm stabil. Beim Einschalten "läuft das Bild hoch" - ist erst verzerrt und in falschen Farben, normalisiert sich nach ca. 4 Sekunden. Nachdem ich die Funktionstasten verstanden hatte (Umschaltung mit "CTRL") lud ich dann "meine" Programme und startete das "MAIN"........nichts. Gut - alle Zeilen sind "randvoll" und alle Befehle abgekürzt. Nache einem Blick in Dein Manual zeigte sich, dass die Abkürzungen sich teilweise geändert haben oder nicht mehr existent sind - schade - aber gut - dafür gibt es ja 95 Zeilen. Nach einigen Änderungen, Speichern, Probieren usw. (ca. 1h) und ersten Erfolgen passierte etwas merkwürdiges: Bei Aufruf des Editors wurden zunächst nur viele "X" anstelle der belegten Programme angezeigt, nach ein paar Sekunden Programmfragmente, dann fing der Ton an zu knarren und das Bild verschwand. Nach "Reboot" (CTRL-ALT-DEL) startet der Computer neu. Die kleinen Testprogramme laufen noch und lassen sich editieren. Die 4 grossen (max. Zeilenanzahl der MEGA32-Version) verhalten sich gleich: bei Aufruf des Editors nur "X", dann Fragmente, knarren und aus. Frage: hat eines der Programme beim Speichern evtl. das Flash korumpiert ? Gruss Otto
Hallo Jörg, und noch eine Frage: kann ich ohne Weiteres "BOD-Level" auf 2,7V setzen - bzw. würde Deine SW auch mit 3,3V arbeiten ? Gruss Otto
Hallo Otto, Das niederwertigeste Bit der LOW-Fuse gibt nur an, nach wieviel Oszillatorzyklen der Controller startet. Bei E7 dauert es etwas länger, sollte eigentlich sogar noch besser sein. Ich habe versucht, die bei Dir aufgetretenen Effekte nachzuvollziehen, es ist mir aber nicht gelungen. Lediglich gibt es bei NTSC ein leichtes Kantenflimmern (hauptsächlich in den Grafikmodi), wird aber mit der nächsten Version behoben sein. Kannst Du ein Verify Deines Flash-Inhaltes machen? Die BASIC-Programme liegen im Bereich 0x4800 bis 0x77ff (bzw. 0x9000 bis 0xefff wenn Byteweise gezählt wird) Ausserhalb dieses Bereiches darf sich nichts änderm! Eventuell könntest Du mir auch eines der fraglichen BASIC-Programme schicken, dann würde ich es hier testen. Sicherheitshalber mache ich in die nächste Version eine einfache Prüfsumme mit rein. Es deutet alles auf Flash-Korrumption hin, die könnte aber auch durch Probleme in der Stromversorgung entstehen. Bei der Mega32-er Version hatte ich am Anfang ähnliche Probleme, die sich mit einem zusätzlichen Abblock-Kondensator lösen liessen. Gruß Jörg
Glatt vergessen: bei 3,3V wird der Mega644 die 20MHz wohl nicht schaffen, zumindest wird es nicht zugesichert. Gruß Jörg
Hallo Jörg, ich habe Dir die Basic - Programme und die aus dem Controller ausgelesene Hex-Datei gemailt - ist das Mail angekommen ? Gruss Otto
Leider gab es im ersten Release ein paar Bugs beim Komprimieren und Dekomprimieren von "langen" Zeilen. Außerdem habe ich die Sprite-Routinen neu geschrieben, die Daten können jetzt beliebig im Array liegen und die Anzahl wird auch nur durch die Größe des Arrays begrenzt. Dann gibt es eine Erweiterung bei PRINT, es lassen sich auch nullterminierte Zeichenketten aus dem Array ausgeben. Und ACOPY mit dem Teile des Array umkopiert werden können. Und Zuguterletzt habe ich mich der Audio-Ausgabe etwas angenommen. Es gibt jetzt eine zweite Klangfarbe und, einen Sequenzer der seine Daten aus dem Array holt und komplett im Hintergrund läuft. Das Thema 24C512 als Programmspeicher ist erstmal wieder vom Tisch, da ich den Code nicht mehr komplett in den Controller bekommen habe. Da das Projekt schon recht komplex und für Anfänger wohl eher undurchschaubar ist, würde ich bei Interesse auch die eine oder andere Routine herauslösen und dokumentieren. Ansonsten viel Spaß damit Gruß Jörg
Hallo Jörg, vielen Dank für die neue Version - ich hätte da mal zwei dumme Fragen: 1. Wäre es möglich, Programme unter anderen Nummern (z. B. "Programm 2" unter "Programm 5") zu speichern (Backup) um ggf. bei Programmierfehlern oder Fehlfunktionen das Original wieder "zurückzuholen"? 2. Wäre es möglich, Programme ausserhalb des Editors komplett zu löschen (also z. B. "delete program 2") Gruss Otto
Mal sehen, ob es der Platz im Flash noch erlaubt. Vielleicht als zweite Tastaturebene im Hauptmenü mit "CLEAR" und "COPY". Im Moment steht aber eigentlich erstmal die Überarbeitung der Hardware-Doku an... Gruß Jörg
Hallo alle zusammen, Leerplatinen und Bausätze sind jetzt bei www.it-wns.de verfügbar ;) Schönes Wochenende... Gruß Thomas
@Joerg Hab da mal ne Frage: Kann man bei deiner neuen Masken Funktion von: "out" auch die 8 Ports Binär ansteuern? Bzw. könnte man es implementieren? Gruß Robin T.
Wenn Du meinst, alle Bits anzusteuern, dann geht das so: out $1ff, wert Damit wird die Maske auf %1111111 gesetzt und der LOW-Teil von wert auf die Portleitungen geschrieben. Gruß Jörg
So habe da mal ein Programm geschrieben mit welchem man das Ausgabeformat von "Print !wert "Text", Zahl, Variable" auswählen und anzeigen kann. Man brauchs vlt. nicht unbedingt aber mir persönlich erleichterts die Formatierung vom Text mit Print. Viel Spass damit P.S.: Falls es nicht funktioniert hab ich was beim Compilieren vergessen. Passiert auch mir.
Hallo Robin, vielen Dank für Deine schnelle Reaktion - leider hat sich nichts geändert: Mein PC vermisst "BORLNDMM.DLL" und meint, eine "Neuinstallation der Anwendung" würde helfen..... Viele Grüsse Otto
So habs von jemandem testen lassen. Funktioniert.
Hallo Robin, vielen Dank - funktioniert wunderbar ! Gruss Otto
So, hier kommt die neueste Version. Da ich die Doku in großen Teilen überarbeitet habe, ist das Archiv kräftig gewachsen. Dafür gibts jetzt auch ein paar Beispielprogramme. - Kopieren und Löschen von Programmen aus dem Hauptmenü heraus - Editor springt nach dem Speichern nicht mehr automatisch zum Anfang - SIN() und COS() arbeiten jetzt mit ganzen Grad-Werten - Bugfix bei obigen Funktionen (teilw. falsche Werte im 3.Quadranten) - Checksumme für System-Flash - Kleine Änderungen an der Optik (Versionsanzeige nur bei Info) - diverse kleine Bugfixes Die große Sinus-Tabelle musste leider wegfallen, da es zwischenzeitlich sehr eng im Flash geworden war. Viel Spass damit! Gruss Jörg
Danke für die neue Version. Bin schon ganz aufgeregt sie zu testen! Vorallem die Beispiele. Gruß Robin T.
Hallo Jörg, auch von mir vielen Dank ! Viele Grüsse Otto
Naja, viel weltbewegendes ist noch nicht dabei, ich bin aber am überlegen ob ich nicht so eine Art "Codesammlung" auf meiner Seite aufbaue. Gruß Jörg
Das hatte ich im Mega32 Tread schonmal vorgeschlagen (glaub ich). Das Leute die Programme für den BASIC-PC entwickeln und auf deiner Seite hochladen können. Darauf hatte Otto mir zugestimmt "Damit man das Rad nicht immer neu erfinden muss". Hab ich ein Gedächtnis wow :) Gruß Robin T.
Hallo Jörg, gerade habe ich die Dokumentation aud Deiner Homepage angesehen: alle Achtung ! hallo Jörg und Robin, ja so eine Codesammlung würde ich auch gut finden.... Gruss Otto
Ich hab gerade noch drei Fehler gefunden: - beim UNI-BAS Adapter war das falsche Bild dabei - Die Belegungstabelle für den UNI-Anschluss war unvollständig - im Programm PONG fehlte in Zeile 57 ein "END" naja, nix schlimmes aber ärgerlich ist es trotzdem. Gruß Jörg
Hi, hab da mal ne Frage bezüglich dem Befehl: "ICOMM" Wie kann ich damit das EEProm auslesen? Ich habe es geschafft zu schreiben aber lesen nicht. Ich weiß dass ich da eine 1 an die Adresse hängen muss aber wohin speichert er die Daten bzw. wie gebe ich an wohin er die speichern soll? Danke
Ach und noch was: Ich habe hier seit der Meag 32 Version einen fertig bestücken BASIC-PC es fehlen lediglich die EEPROMS und der Mega32/644. ABER: Ich habe es nie verwendet weil ich die beiden 9-Poligen Buchen/Stecker vertauscht habe. Eigentlich müsste man das 9-Polig->Scart-Kabel nur Spiegelverkehrt herstellen aber dazu habe ich keine Lust. Vlt. kanns ja jemand gebrauchen. Materialkosten wollte ich dann aber doch wieder raus haben (müsst ihr mir lassen^^) 5 Euro. Gruß Robin T.
Für EEPROMs die 2 Adressbytes brauchen (24C16, 24C65...) ist es einfacher, den EEPROM auf Adresse 1 zu setzen und dann XPOKE sowie XPEEK() zu nehmen. In der aktuellen Version geht es bis zum 24C512. Ansonsten braucht man halt das Datenblatt, meist kann man den Adresszeiger im EEPROM durch einen unvollständigen Schreibvorgang setzen. Ausprobiert habe ich es aber noch nicht, da mir die eingebauten Befehle genügt haben. Gruß Jörg
Hallo Jörg, ich hätte mal wieder eine meiner dummen Fragen: ist es möglich, die MEGA32-Version in den MEGA644 Controller zu flashen - falls ja, geht das ohne Änderung der Fuses ? Hintergrund ist, dass ich den Chip der im Fahrzeug eingebauten Platine direkt einlöten möchte, jedoch mit meinem Programm für den 644 noch nicht fertig bin. Gruss Otto (ja - genau der ;-) )
Hallo Otto, leider geht das nicht so einfach, da beim Mega644 einige IO-Register anders liegen und nicht mit IN/OUT angesprochen werden können. Ich werde mir am WE mal abschauen, wie gross der Aufwand wäre. Gruss Jörg
Hallo Jörg, vielen Dank für Deine Rückmeldung - kein Problem, dann löte ich einen MEGA32 ein - es war nur eine Frage - ich wollte Dir keine unnötige Arbeit verschaffen ! Viele Grüsse Otto
Hallo, ich habe mir die ältere Version mit Mega32 nachgebaut und finde den Mini-Computer schon echt klasse. Nun hätte ich mal eine Frage dazu: Wäre es möglich auf die Video Ausgabemöglichkeit zu verzichten und dafür ein LCD 240x128, Controller T6963c da er für diese Auflösung wohl am meisten verwendet wird, zu nutzen ? Die Displays bekommt man inzwischen relativ günstig und man hätte einen Mini-Basic Computer der auch noch ohne weiteres "tragbar" wäre. Sicher Farben gibt es keine mehr aber dafür braucht man auch nicht immer einen Fernseher dafür. Die Auflösung als solche wäre sogar höher. Nur mal so als Gedanke.... Gruß Harry
Dann beibt aber trotzdem noch ein kleines Problem mit der zu grossen Tastatur. Da es auch passende Farb-Displays gibt (das in der Doku angegebene NEC, aber auch diverse PS-Displays sollten gehen) sehe ich keinen großen Bedarf an einer GLCD-Lösung. Vor allen Dingen wüsste ich nichts damit anzufangen... Eine neue Version mit einem kleinem Intro-Screen, ein paar Anpassungen an simpler gestrickte Assembler als den AVRA und SPI aus dem BASIC heraus wird es demnächst geben, eventuell auch eine Version für den Mega8. Dort steht allerdings noch die komplette Dokumentation aus. Und ich überlege mir (mal wieder) ob sich der Aufwand lohnt, den Quelltext für eine Veröffentlichung aufzubereiten. Gruss Jörg
Inzwischen sind leider ein paar Bugs aufgetaucht, die nächste Version kommt aber wahrscheinlich erst nächste Woche, da ich am WE auf dem VCFe bin. 1. Wenn nach einer Funktion ein "-" kommt, wird das was vorher da war gelöscht. SQR(9)-1 ergibt also -1 anstelle von 2 2. Wenn wortweise in das Array geschrieben wird, enthalten beide Bytes im Array das LOW-Byte 3. RND(x) liefert maximal die Hälfte von x zurück anstelle 0...x-1 4. Bei EPOKE wird manchmal nicht ins EEPROM geschrieben 5. Die "Press ESC" Meldung am Ende wird manchmal übersprungen Ansonsten wird es Zugriff auf die SPI-Schnittstelle geben, ein "Scrollfenster" (in 4 Richtungen scrollbar) im Textmodus und einen Intro-Screen. Außerdem habe ich das Timing etwas geändert, auf manchen TV's steht das Bild jetzt wesentlich ruhiger. Und ich habe auf Anfrage ein paar Sachen geändert, damit das Ganze mit dem AVRASM32 etwas "verträglicher" wird. Geplant ist eventuell noch eine Möglichkeit, eigene Assemblerprogramme via Hexcode auszuführen. Wobei sich die Frage stellt, inwieweit soetwas sinnvoll nutzbar ist. Ausserdem will ich noch testen, ob man nicht ein frequenzmoduliertes Signal am seriellen Eingang auswerten kann. Dann wäre es einfach möglich, ein Programm mittels Diskman oder MP3-Player zu laden. Bei der Mega8-Version "kämpfe" ich momentan noch mit der Codegröße, momentan sind noch 18 Bytes frei was eine Portierung auf den Mega88 unmöglich macht. Screenshots habe ich noch keine (geht nur mit Kamera), dafür ein paar Eckdaten: - 23 Zeilen a 30 Zeichen monochrom - Pseudografik mit Punkten, Linien, Rechtecken, Großschrift - 20 Programmzeilen mit je 25 nutzbaren Zeichen - minimales BASIC, arbeitet mit Byte-Werten - Ein Programm im Flash - 1 Audiokanal (Sägezahn mit Hüllkurve) - PS2-Keyboard - seriell IN und OUT mit 1200Bps, Laden und Speichern, Zugriff vom Basic - 4 universell nutzbare IO (IN/Out/ADC) - Fullscreen-Editor - Autorun-Modus über Jumper - Externer Datenspeicher (4 Programme) mit 24C16, Programmauswahlbox Allerdings ist der Sourcecode aus Speicherplatzgründen für Aussenstehende nicht mehr einfach nachvollziehbar, teilweise gibt es bedingte Sprünge aus einer Subroutine zur anderen und zurück, nur um ein paar Bytes zu sparen. Aus diesem Grund und der ganzen "AVR-Studio-Problematik" wird es vorerst aber nur noch Hexfiles davon geben. Gruß Jörg
Boah wie cool!! Bei der sache mit dem ASM32 fang ich fast an zu sabbern vor lauter aufregung. Danke für deine Mühen, bin schon sehr gespannt. Gruß Robin T.
Hi AVR-ChipBasic2-Fans Ich versuche vergeblich ein Programm im Flash zu speichern. Version ist V0.72 mit Atmega644. Ich gehe folgendemaßen vor: Im Hauptmenue rufe ich mit F1 den Editor auf. Der Editor öffnet ein Template mit Programmname und den Basic-Zeilennummern. Mit F1 [Programname] gebe ich einenProrammnamen ein. mit Return springt der Cursor in die erste Basiczeile. Jetzt gebe ich ein PRINT "HALLO" und ein return. Mit F2 [SAVE] erfolgt die Abfrage SAVE Y/N . Mit der EIngabe von Y werden die Basiczeilen gelöscht. Mit ESCAPE gehe ich zurück ins Hauptmenue, aber unter P1 steht kein Programmname. Wie speichert ihr ein Programm ? Was mache ich falsch ? Vielen Dank Gero
Hallo Gero, hast Du evtl. die Fuses zum Sichern des Flash gesetzt ? Otto
Hallo Otto Danke ! Die Fuse war falsch. Im AVR-Studio 4.13 muß EESAVE gesetzt sein ( ein Häckchen haben) Nochmals danke Gero
Angehängte Dateien:
-
racer.png
876 Bytes
So, die aktuelle Version ist jetzt online. Neben einigen Bugfixes gibt es wie angekündigt auch ein paar neue Funktionen (Scrollen, SPI). Und zwei neue Beispielprogramme sind auch mit dabei. Ein kleines "Autorennspiel" une eine Art Oszilloskop mit sagenhaften 50Hz Samplerate und Grafik-Scrolling mittels BCOPY. Um nicht immer die großen Archive zu posten, verweise ich auf meine Webseite: http://www.jcwolfram.de/projekte/avr/chipbasic2/main.php oder zum Download bei Berlios: http://developer.berlios.de/projects/avr-chipbasic Viel Spass damit Gruß Jörg
Vielen Dank für die neue Version! Vorallem mit dem Oszi habe ich schon gespielt ;) Wird immer interessanter damit zu programmieren. Aber die Idee mit dem Assembler Interpreten mach mich "spitz" auf weitere Versionen. Danke Gruß Robin T.
Hi Jörg, aus irgendwelchen Gründen kann ich kein "@" im BASIC-PC schreiben? Wäre nett wenn du mal schaust was das ist. Oder vlt. liegts auch an mir? Gruß Robin T.
Hmmm, schaue ich morgen mal nach, sollte eigentlich gehen. Shift und 3 müsste auch gehen. Gruß Jörg
Hallo Robin Hast Du evtl. im KONFIG die 3.Zeile des Keyboard layout gewählt? Die wollte bei mir auch nicht den Klammeraffen @ ausgeben. Nur die 1.Zeile DE(QWERTZ) gibt den @ aus. Gero
Puh, gute Frage. Werd ich gleich mal überprüfen, danke für den Tipp. Gruß Robin T.
Das wars. Danke nochmal für den Hinweis. Gruß Robin T.
Hab da noch mal ne Frage. Es gibt ja den Jumper mit dem man zwischen PAL und NTSC wechseln kann. Könnte man nicht NTSC wegnehmen und VGA stattdessen einfügen? NTSC haben sicher eh nur die wenigsten. Und das er kein VGA hat ist das einzige was den BASIC-PC für mich noch unportabel macht. Gruß Robin T.
Hallo Robin,
>NTSC haben sicher eh nur die wenigsten.
(fast) jeder, der den Computer an ein PKW-NAVI-Display anschliessen
möchte (so zum Beispiel ich) benötigt NTSC.....
Gruss Otto
VGA geht leider nicht wegen des Timings. Das erste Problem ist der Pixelclock. Für 640x480 und 60Hz brauche ich schon ca. 7MHz um die gleiche Auflösung zu erreichen. So schnell lassen sich aber die Daten nicht ausgeben ohne die SPI-Schnittstelle zu bemühen. Mit einem externen CPLD an der Videoschnittstelle geht´s zwar, ist aber trotzdem nicht praktikabel. Denn aufgrund der höheren Zeilenfrequenz ist die horizontale Austastlücke viel zu kurz um Tastatur, serielle Schnittstelle und Sound zu bedienen. NTSC brauche ich z.B. für mein NEC TFT-Display, auch die meisten LCD-Fernseher haben nur 240 Zeilen und lassen bei PAL einfach Zeilen aus was eine vernünftige Darstellung eigentlich unmöglich macht. Nach der jetzt erschienenen Mega8/88 Version wird es nur noch Bugfixes und kleinere Korrekturen geben, da meiner Meinung nach einfach nicht viel mehr machbar ist. Das nächste Projekt steht aber schon in den Startlöchern... Gruß Jörg
Ok. Dann füge ich mich der Realität ;)
joergwolfram wrote:
>Das nächste Projekt steht aber schon in den Startlöchern...
Ich freu mich drauf :)
Gruß
Robin T.
Hallo Jörg, vielen Dank für die neue Version - ich bin erst jetzt dazu gekommen, diese auszuprobieren. Mit dem "Racer" hast Du meinen lieben Kleinen (19 und 16) eine Riesenfreude bereitet.... Auch die Grafik ist toll! Welchen Befehl muss ich eigentlich nun anstelle "call" verwenden - nach Referenz doch "gos" - oder ? Irgendwie klappt es bei mir mit den Unterprogrammen nicht......wird sicher an mir liegen - werde es schon finden... Am Ende der Zeile wird bei einem (zum Beispiel) "gos 87" ab einer bestimmten Zeilenposition (bei der die "87" aber noch in die Zeile "passt") nach dem "save" das "87" gelöscht. Gruss Otto
GOSUB oder GOS sollten eigentlich beide gehen. Kannst Du mir das fragliche Programm mal mailen dann schaue ich mal nach, woran es liegen könnte. Gruß Jörg
Mir ist noch was eingefallen: Eventuell könnte es daran liegen, wenn in einer Zeile mehrere einstellige Zahlen als Operanden vorkommen und die Zeile bis zum Ende ausgereizt wird. Die Ursache dafür liegt im Tokenizer, der alle Konstanten <256 in Token und ByteValue, also 2 Bytes umwandelt. Die belegen dann im Speicher zwei statt 1 Byte. Als Workaround erstmal solche Situationen vermeiden. Für die nächste Version werde ich den Tokenizer so umschreiben, dass er Konstanten <10 nicht tokenisiert. Der Geschwindigkeitsverlust zur Laufzeit sollte dabei auch nicht so hoch sein wie bei großen Zahlen. Gruß Jörg
Da das nächste offizielle Release wohl noch etwas dauern wird, hier schon mal eine neue Version zum testen. - Bugfix im Tokenizer, der manchmal Zeilenenden abgeschnitten hat - neuer Befehl BORDER n [BO] um die Randfarbe zu setzen - Baudrate kann im Config-Menü auf 2400 umgestellt werden Bei 2400Bps hat die serielle Schnittstelle einen Jitter von +-10%, da die Bitrate aber an sich stimmt, sollte es nur mit den wenigsten geräten Probleme geben. In der Planung ist ein 32K RAM-Modul mit einem kleinen CPLD, welches an den Druckerport angeschlossen werden kann. Neben einer Erweiterung des Arrays sollen auch neue Videomodes dazukommen. Gruß Jörg
Hallo Jörg, das ist ja super - speziell die höhere Baudrate. noch ein paar dumme Fragen für die letze Version, auf die ich trotz intensiver Suche keine Antworten gefunden habe: 1. Gibt es einen Befehl wie "Border", der das "Outputfenster" komplett in einer Farbe füllt (nicht "Color") ? 2. Gibt es nur für die Befehle eine Abkürzung, bei denen dies in der Basic-Referenz auf Deiner Homepage steht ? 3. Ich erhalte überhaupt keine Fehlermeldungen mehr - muss ich diese mit "On Error" selbst auswerten ? Ein Beispiel zu den Fehlermeldungen: ich schreibe in einer Zeile nur "XXXX" und es kommt keine Fehlermeldung. 4. Die Abfrage: "RKEY A:IF A <> 237 GOTO xyz" funktioniert nicht - was hat sich hier geändert ? Viele Grüsse Otto
Hallo Otto, ich versuche mal Deine Fragen kurz zu beantworten: 1. geht nur mit COLOR fg,hg Farbe setzen dann CLS oder CBOX 2. Abkürzungen gibt es nur, wo sie auch in der Doku stehen 3. und 4. sollten in der Version 0.82 funktionieren (gerade getestet) 01 RKEY A:IF A <> 237 GOTO 1 02 03 ? "ESC", 04 RKEY B:IF B > 0 GOTO 4 05 GOTO 1 gibt bei jedem Druck von ESC den Text "ESC" aus. Gruß Jörg
Hallo Jörg, hurra - Du lebst noch - dann werde ich die neueste Version mal testen Vielen Dank Otto
Nun ja, die 0.81 wollte ich Dir eigentlich per mail zum testen schicken, dann hatte ich aber noch einen Fehler gefunden und dann ist mir das mit den 2400Bps eingefallen. Durch die höhere Geschwindigkeit ist jetzt auch ein Bootloader mit Aktualisierungszeiten unter 5 Minuten möglich, mal sehen wie es mit dem Speicherplatz aussieht. Mein nächstes Projekt hat auch teilweise mit ChipBasic zu tun, ich bastle im Moment an einem AVR-Handheld. Mit 128x64 LCD, 6 Tasten, SPI-Slot zum Programmieren und für das Dataflash-Modul und einem 9-pligen Steckverbinder für RS232, Video/Audio (parallel zum LCD möglich), I2C, +5V und Ladeanschluß für den eingebauten Akku. Ein Novum wird aber die Programmierung sein. Die nächste ChipBasic-Version wird dazu einen zusätzlichen Videomode mit 128x64 monochrom bekommen. Der Handheld selbst enthält eine (abgespeckte) Runtime-Version des ChipBasic-Interpreters und kann die Programme vom Dataflash lesen und ausführen. Später sollen dann noch ein Chip8/SChip Interpreter und eine Art grafische Programmierung über Funktionsblöcke dazukommen, aber das ist im Moment noch "Zukunftsmusik". Wenn jemand Ideen dazu hat, vielleicht lässt sich ja die eine oder andere noch berücksichtigen (außer bei der Hardware, die steht eigentlich schon fest, lässt sich aber durch die rausgeführte I2C Schnittstelle relativ leicht erweitern). Gruß Jörg
Joerg Wolfram wrote: > Mein nächstes Projekt hat auch teilweise mit ChipBasic zu tun, ich > bastle im Moment an einem AVR-Handheld. Mit 128x64 LCD, 6 Tasten, > SPI-Slot zum Programmieren und für das Dataflash-Modul und einem > 9-pligen Steckverbinder für RS232, Video/Audio (parallel zum LCD > möglich), I2C, +5V und Ladeanschluß für den eingebauten Akku. Respekt das du nicht aufhörst. Macht richtig Spass deine Projekte abzuwarten und nachzubauen ;)
An Aufhören hatte ich eigentlich noch nie gedacht. Lediglich die Frage, ob Open Source oder Freeware stelle ich mir aufgrund des sehr mageren Feedbacks und diversen "Unverträglichkeiten" mit anderer Software immer wieder. Jörg
Hallo Joerg, also war meine damalige Idee mit den Display (ich meinte damals zwar ein 240x128) doch garnicht soooo schlecht grins Grüße und mit Spannung auf den Handheld warte ;-) Harry
....Mit 128x64 LCD..... klasse, dann braucht man sich nicht mehr um diese fbas-kacke kümmern und man hat mehr spielraum für das basic usw.
@Harry Das war auch damals der Punkt an dem ich angefangen habe, ernsthaft darüber nachzudenken. @neuer Die "fbas-kacke" wird auch in dem neuen Projekt bleiben, es gibt einen Videoausgang und das LCD wird zyklisch aus dem video-RAM im Controller aktualisiert. Allgemein: Das BASIC wird bis auf ein paar Abstriche identisch mit dem des ChipBasic2 sein, damit ich die bestehende Codebasis nutzen kann. Das ganze wird also zunächst nur eine Art "Abspieler" für ChipBasic2-Bytecode sein, was an weiteren Funktionen dazukommt steht zum jetzigen Zeitpunkt noch in den Sternen. 100%ig steht aber fest, dass ChipBasic2 (zumindest von meiner Seite her) wohl die einzige Entwicklungsplattform für das "Mobilteil" sein wird, Programmentwicklung (BASIC) auf dem PC habe ich nicht vorgesehen. In den nächsten Tagen wird es erstmal ein neues ChipBasic2 Release geben, mit der zusätzlichen Auflösung und auch ein Bootloader (X-Modem mit 2400Bps) wird mit dabei sein. Und ein paar böse Bugs muss ich auch noch rausmachen... Bis dahin ein schönes WE Jörg
Frage: Ich möchte gerne RKEY und WKEY "wegrationalisieren", um ein paar Token freizukriegen. Dafür will ich die Funktion KEY() erweitern: KEY(0) - liefert die momentan gedrückte Taste oder 0 zurück KEY(1) - wartet auf Tastendruck und liefert Code zurück KEY(2) - wartet auf Taste losgelassen und liefert letzten Keycode zurück KEY(3) - liefert Status der Shift/Ctrl/Alt-Tasten zurück KEY(4-7) entsprechen dann den bisherigen Key(0-3) Key(16...) Es wir dauf die entsprechende Taste gewartet, anstelle 01 RKEY A:IF A <> 237 GOTO 1 steht dannn A=KEY(237) Mit den freigewordenen Tokencodes will ich eine Art "Eventbehandlung" oder "Multitasking" realisieren. So, und jetzt die eigentliche Frage: Inwieweit würde das bestehende Projekte bei Euch betreffen? Jörg
Bei mir würde es kein Projekt beeinflussen. Allerdings finde ich deinen Vorschlag sehr gut für zukünftige Projekte. Man muss sich nicht mehr soviel Befehle merken. Dann würde es nurnoch Key(..) geben. Gruß Robin T.
Hallo Joerg, die paar Zeilen zu ändern ist kein Drama - ausserdem ist die Zeile mit der Abfrage kürzer :-) Gruss Otto
So, mal wieder ein kleines Hexfile zum Testen. Wie schon angekündigt, habe ich WKEY und RKEY rausgeschmissen und die Funktionalität in die KEY() Funktion verlagert. KEY(0) - liefert die momentan gedrückte Taste oder 0 zurück KEY(1) - wartet auf Tastendruck und liefert Code zurück KEY(2) - wartet auf Taste losgelassen und liefert letzten Keycode zurück KEY(3) - liefert Status der Shift/Ctrl/Alt-Tasten zurück KEY(4-7) entsprechen dann den bisherigen Key(0-3) Key(16...) Es wir dauf die entsprechende Taste gewartet, Der neue Grafikmodus hat die Nummer 5, im Gegensatz zu den anderen Grafikmodi lässt sich hier auch der Monitor benutzen. In allen Grafikmodi kann mit FONT n (0/1) zwischen dem normalen 10x6 Font und einem kleineren 6x4 Font umgeschaltet werden. Neu sind auch die Funktionen RREAD page,(0/1/2) und RWRITE page,(0/1/2) mit denen direkt auf das Dataflash zugegriffen werden kann sowie die Funktion MENU(n) wobei n ein Zeiger auf 60 Zeichen Text im Array ist. Normalerweise werden die ersten 30 Zeichen angezeigt, bei gedrückter linker CTRL-Taste die restlichen 30 Zeichen. Der Returnwert gibt den gewählten Menüeintrag (1-10) an. Auf der Konfigurationsseite können jetzt verschiedene Einstellungen zu den Schnittstellen getätigt werden. Der Handheld nimmt auch langsam Form an, die Hardware und auch ein Teil der Software (Ein/Ausgaberoutinen) sind schon fertig. Wie gewohnt geht es bei der Hardware recht minimalistisch zu, ein Mega644, ein 128x64 Display mit ks0108 Controller, 6 Taster und ein bisschen Kleinkram, bei mir ist noch ein LI-IOnen Akku und Step-up dabei. Als Software wird es neben der ChipBasic2 Runtime noch einige Tools geben: - Stoppuhr mit 1/1000s Auflösung (kann über SDA/SCL getriggert werden) - GPS-Anzeige für die NAVI-S und evtl. andere Module - und was sonst noch reinpasst Stromlaufplan und erste Hexfiles folgen demnächst, allerdings werde ich das Projekt vorerst nur als Freeware veröffentlichen. Jörg
Juhu! Wieder was zum spielen. Dankeschön ;)
mmh. Ich bekomme es leider nicht gebrannt. Er sagt kein gültiges Intel-Hex Format.
hmm, da habe ich heute nacht die falsche Datei erwischt, hole ich aber am Abend nach. Sorry, Jörg
Das sollte jetzt die richtige Datei sein. Mit den Fusebytes LOW 0xe6 HIGH 0xd2 EXT 0xfc sollte auch beim Start (serielles Kabel angesteckt) der Bootloader zu sehen sein. Jörg
Ich habe dieses tolle Projekt nachgebaut, um meinen Kindern mal die "alten Zeiten" zu zeigen - hat großen Anklang gefunden. Jetzt aber zum Problem: mit der Version 0.75 geht alles - wenn ich aber die 0.85 flashe, dann gehen bei mir die F-Tasten nicht mehr und auch die Cursor-Tasten gehen nicht, nur am Ziffernblock, wenn ich vorher NUMlock drücke. Tastatur ist ein Cherry PS/2 Keyboard... Ist das ein Bug in 0.85 oder hat es eine andere Ursache ?
WHerzog wrote: > Ich habe dieses tolle Projekt nachgebaut, um meinen Kindern mal die > "alten Zeiten" zu zeigen - hat großen Anklang gefunden. > > Jetzt aber zum Problem: mit der Version 0.75 geht alles - wenn ich aber > die 0.85 flashe, dann gehen bei mir die F-Tasten nicht mehr und auch die > Cursor-Tasten gehen nicht, nur am Ziffernblock, wenn ich vorher NUMlock > drücke. > Tastatur ist ein Cherry PS/2 Keyboard... > > Ist das ein Bug in 0.85 oder hat es eine andere Ursache ? Das Problem hatte ich auch. Du musst in den Einstellungen auf Deutsche Tastaturbelegung einstellen. Die F-Tasten funktionieren mit Alt-Gr
Ja, das ist leider ein Bug, der Offset für die zweite Tastaturtabelle stimmt leider nicht. Ebenso fehlen ein paar Werte in der Sinustabelle. Danke für den Hinweis, korrigierte Version kommt in den nächsten Tagen. Jörg
Sorry, aber es wird noch ein paar Tage dauern, bis das nächste Release kommt. Das Flash war einfach schon zu voll, und so musste ich einige Sachen erstmal "umorganisieren". Im Ergebnis sind jetzt wieder ca. 3K frei. Da ich parallel dazu den Handheld entwickle (Hardware ist fertig und auch ein Teil der Programme läuft schon), sind aus Kompatibilitätsgründen immer wieder kleinere Anpassungen notwendig. Im BASIC will ich noch EMIT rausstreichen, da das auch über PRINT % geht. Dafür wird es eine Baudratenumschaltung geben. Beim Handheld habe ich folgende Raten vorgesehen: 1200, 2400, 4800, 9600, 19200, 31250 (MIDI), 38400, 57600 Beim Computer mit Mega644 lassen sich nur die Raten 0/1 wählen, beim Handheld und einer möglichen 644P-Variante sind dann alle Raten verfügbar. Da ich den Handheld aus verschiedenen Gründen nicht mehr als Open-Source veröffentlichen werde, stellt sich natürlich die Frage nach einem geeigneten Forum (falls überhaupt interessant), da die Codesammlung eindeutig nicht der richtige Platz dafür ist. Jörg
Joerg Wolfram wrote: > die Frage nach einem > geeigneten Forum (falls überhaupt interessant), da die Codesammlung > eindeutig nicht der richtige Platz dafür ist. Veröffentliche es einfach auf deiner Website und mach in diesem Beitrag hier ein kleinen Link weil mich interessiert der Handheld ziemlich.
Ich habe das Ding gebaut mit ein AT45DB041D Erweiterung. Es funktioniert nicht, weil mit AT45DB041B funktioniert es problemlos. Ich habe eine Frage - warum, in ATmega 644 version, sind die Benutzer-programme nicht mehr in die I2C EEPROMe speichern? Es war eine bessere Lösung, meiner Meinung nach. Ich hoffe dass Sie haben mein Post verstanden, Ich lerne Deutsch :)
Hi Krzysztof, zum AT45DB041D werde ich mir mal das Datenblatt anschauen, inwiefern ich das Programm anpassen kann. Der Hauptgrund, Dataflash anstelle EEPROM einzusetzen, ich habe noch genug davon und sie bieten mehr Speicherkapazität. Jörg
Nach doch etwas längerer Wartepause gibt es wieder eine neue Beta-Version. Neu dazugekommen ist das Senden und Empfangen von Programmen via XMODEM, ausserdem ändert sich das Programmicon, je nach Inhalt. So können die Programme demnächst dann auch nativen AVR-Binärcode enthalten. Bis das API nutzbar ist, wird es aber noch ein paar Tage oder Wochen dauern. Nach längerem Hin-und-herüberlegen wird der AVR-Handheld nun doch auch ein Opensource-Projekt werden. Zentrale Hardware ist ein Mega644 und ein 128x64 Grafikdisplay. Alternativ kann auch ein Fernseher angeschlossen werden. Zusätzlich wird eine DS3232 RTC unterstützt, kann man auch als Sample von Maxim bekommen. UART, I2C und zwei Portpins, die auch am ADC hängen, sind herausgeführt. Folgendes habe ich bereits implementiert: - Bedienoberfläche mit Symbolen - Runtime für Programme 1-4 kompatibel zu ChipBasic2 - Stopp-Uhr mit 1/1000s Auflösung - Wecker (braucht RTC) - Zeitmessung (Pulsdauer, Verzögerung) - Temperaturmessung mit LM75 - 2 Kanal Mini Logikanalysator mit max. 4 MS/s - GPS-Anzeige für Module mit serieller Schnittstelle - 2 Kanal Zähler Wenn Interesse besteht, kann ich auch ein pre-Projekt mit minimaler Dokumentation veröffentlichen. Gruß Jörg
Hallo Jörg, da bin ich ja mal gespannt - sind die Fuses die selben wie immer ? Gruss Otto
Ich freue mich schon wahnsinnig auf den Handheld. Wann wird der voraussichtlich veröffentlicht?
Hallo Joerg, ich habe zwar in letzter Zeit nicht mehr viel geschrieben, aber bin noch mit Spannung dabei. Also das mit dem Handheld ist wirklich super wenn Du es rausbringst. Auch das Du Dich für die Open-Source Variante entschieden hast find ich wirklich klasse. Mein Display liegt schon rum und wartet eingelötet zu werden^^ Da ich Dich aber nicht mit nervigen Fragen nach dem Erscheinungsdatum abhalten will weiter zu machen, warte ich einfach weiter^^ Wir sind ja nicht auf der Flucht... ;-) Schönen Gruß aus dem regnerischen Berlin Harry
Wichtig ist (zumindest für mich), dass zum erstem Release-Zeitpunkt die internen Strukturen (Speicherbelegung, EEPROM) schon festliegen. Und die bin ich gerade am Überarbeiten. Und dann kommt eine neue Idee und alles muss nochmal neu aufgerollt werden... Zum Beispiel hat mich gestört, dass für eine bestimmte Anwendung der externe Steckverbinder auf der anderen Seite besser aufgehoben wäre. Daraufhin habe ich das Programm geändert, dass man die Orientierung des Displays nach dem einschalten um 180 Grad drehen kann, hat auch den Vorteil, dass man es auch als Linkshänder leichter bedienen kann. Sowas zieht aber eben auch neue Bibliotheksfunktionen eine Re-Programmierung der meisten Anwendungen mit sich, um nicht alles doppelt machen zu müssen. Momentan arbeite ich am Filehandling, damit GPS-Log, Temperatur-Log (wird normalerweise im EEPROM gehalten) und Logikanalyzer- / Oszilloskopdaten (1 Kanal, max 20KHz Samplerate, 2000 Samples im RAM) auf das Dataflashmodul geschrieben und von dort wieder gelesen werden können. Außerdem wird auch der datenaustausch via XMODEM möglich sein. Als Veröffentlichungstermin (ohne große Doku) habe ich mir Mitte November vorgenommen, bis dahin sollten die meisten Grundfunktionen vorhanden sein. Platinenlayout wird es aber vorerst nicht geben, da ich das Ganze auf Lochrasterplatte aufgebaut habe und momentan kein weiteres Gerät brauche. Gruß Jörg
Hi Joerg, keine Panik mit dem ich kann warten war wirklich ernst gemeint. Ich kann zwar sicher nicht so gut programmieren aber ich weiß doch was für Arbeit sowas macht. Künstler sollte man niemals stören bei der Arbeit^^ Das mit dem Layout ist doch okay, muß auch nicht so kann man es evtl. als SMD oder eben DIL oder wie auch immer selbst aufbauen. Wieder ne nette Funktion, Display drehen um 180 Grad, find ich gut. Wird immer interessanter. Wünsche noch nen schönen Abend Grüße Harry
Hallo alle zusammen, wer Interesse hat, ich habe noch eine fertig aufgebaute AVR-Chipbasic2 Platine mit ATMEGA644 hier liegen die ich nicht mehr brauche. Würde sie für 20,- EUR inkl. Versand (nur nach D) abgeben. Habe es mal hier gepostet weil einfach besser passt als im Markt. Kontakt: thomas [at] heldt [Punkt] eu
Hmm, ist das Modul für 20,-€ noch zu haben? Ich hätt Interesse! Gruß an alle
Hallo, das Board ist bereits vergeben, sorry.
Angehängte Dateien:
-
mainmenu.png
1 KB
leider fehlt noch der Schaltplan vom Handheld, ich hoffe aber, dass ich den in den nächsten Tagen fertigbekomme. Anbei schonmal ein Screenshot vom Hauptmenü, wenn der Plan fertig ist, werde ich einen neuen Thread aufmachen. Das Programm steht soweit, unvollständige Module habe ich aus der Build-version entfernt. Der Rest der Doku kommt dann nach und nach. Für ChipBasic2 wird es dann als nächstes wieder ein offizielles Release geben, welches u.a. auch die neuen Dateitypen vom Handheld kennen wird. Also bis bald... Jörg
Ist ja echt geil. Freu mich schon drauf. Dann hab ich endlich wieder was zum basteln. Gruß Robin T.
Hallo Joerg, das Bild sieht ja schonmal sehr vielversprechend aus!! Bin ich ja mal gespannt ;-) Liebe Grüße Harry
Zur Abwechslung gibts endlich wieder ein neues Release (V0.87) http://www.jcwolfram.de/projekte/avr/chipbasic2/main.php Download über den Berlios-Link auf der Seite oder direkt: http://developer.berlios.de/projects/avr-chipbasic/ Viel Spaß damit und ein schönes Weihnachtsfest Gruß Jörg
hi Jörg! habe dein wunderbares Projekt nachgebaut, habe aber festgestellt, dass mein Fernseher (Universal) nix anzeigt. Habe daher mal das Signal mit dem Oszi vermessen und bin draufgekommen, dass das Signal nicht normgerecht ist. Falls mein Oszi nicht spinnt, hab ich nämlich bei einem Quarz von 16MHZ eine Zeilenlänge von ca. 79µs = Zeilenwiederholfrequenz von 20MHZ Verwendete Version Chipbasic2 V0.75 ATMEGA644 oder mache ich was falsch? Gruß Stefan
Hallo Stefan, die Mega644 Versionen laufen alle mit 20MHz, das ist der einzigste Unterschied zum Mega16 / Mega32. Ansonsten würde ich Dir zur aktuellen Version raten, da gerade in der V0.75 noch einige Bugs drin waren. Da die meisten wohl zuerst nur das Hexfile zum Flashen benötigen, hänge ich es hier mal mit an. Gruß Jörg
Danke Weihnachten ist schon vorbei, daher wünsche ich einen Guten Rutsch! wie wir in Ö sagen. Stefan
Wieder mal ein neues Update, Hauptsächlich Bugfixes und eine überarbeite Dokumentation, da es doch einige Änderungen gegeben hat. - Bugfix bei ICOMM, I2C hing sich bei fehlendem Slave auf - Array-View im Monitor hinzugefügt - Bugfixe im Zusammenhang mit US-Tastaturen - Beispielprogramme angepasst (KEY Funktion) - Bugfix in der Ein-/Auagabe (Fehlermeldung "IO DISABLED") - Überarbeitete Dokumentation Unterstützung für Binärdateien (AVR-Code) habe ich wieder entfernt, es wird also ein reiner BASIC-Computer bleiben. Gruß Jörg
Hi, irgend wann habe ich mal Zeit übrig und baue das mal aus Spass. Respect Jörg! Wirst du den SoftUart mit max 2400 baud mal durch den zweiten Uart des 644P ablösen? Gruß Rene
Hallo Joerg Wolfram, habe versucht die Quelle unter AVR-Studio 4 für Windows zu assemblieren leider ohne Erfolg es regnet massig Fehler durch doppelt belegte Flash-Bereiche und zutief geschachlete Makro-Aufrufe. Ich hab die Quell mal so grob "überflogen" und festgestellt ohne größere Anpassungen des Quellcodes wirds nicht gehen! (schade) Trozdem Respekt vor dieser Leistung! Klaus
Soviel ich weiss, kann man AVRA auch in das AVR-Studio einbinden. Bei den Versionen für Mega8-32 sollte das den Rückmeldungen nach auch funktionieren. Leider unterstützt AVRA (zumindest in der Version von vor 1 Jahr) den Mega644 nicht, ich habe mir den Code modifiziert und dann neu compiliert. Überlappende Flash-Bereiche gibt es definitiv nicht und auch die Schachtelung von Makros beträgt maximal 2 Stufen. Die extensive Nutzung von Makros ist auch notwendig, um große Programme effizient in Assembler programmieren zu können und dabei den Überblick zu behalten. (Das List-File der aktuellen Version hat hat etwas über 20000 Zeilen). Den zweiten UART des Mega644P zu verwenden ist momentan nicht geplant, weil ich ertens momentan nur Mega644er rumliegen habe und zweitens dafür die Hardware ändern muß. Wenn der Mega1284 aktuell wird, könnte sich das aber durchaus ändern, viel Aufwand ist es nicht. Gruß Jörg
Hi Joerg Wolfram X:\VB60\Chip_Basic\avr_chipbasic2_0.89\src\macros.inc(338): error: .macro: Redefinition of 'libmio_sysconf' X:\VB60\Chip_Basic\avr_chipbasic2_0.89\src\macros.inc(340): error: Unexpected .endm directive X:\VB60\Chip_Basic\avr_chipbasic2_0.89\src\main1.asm(66): error: Overlap in .cseg: addr=0x0 conflicts with 0x0:0x2 FATAL ERROR: Too deeply nested macro calls(16) Assembly failed, 4 errors, 0 warnings Hab mal 4 Errors rauskopiert. Du weist wahrscheinlich am ehesten wo Du hinfassen mußt (willst). Ich finde leider keinen Hinnweis, wie ich den festverdrahten Assembler im AVR Studio austauschen kann. mfg Klaus
... ein weiter "AVR-ChipBasic2" wurde geboren. herzlichen Dank Joerg Wolfram!
Anbei eine kleine Leiterplatte für den Flash. Es wurde ein AT45DB081D eingesetzt und funktioniert. Orginalmaß 15x21 in 600 Dpi.
Hallo Joerg,
das ist kein Gemecker!
hab noch eine kleine und eine große 'Macke' gefunden. (V0.89)
die Kleine: im DFLASH menue wird mir '1 MiByte' angezeigt
~
die Große : >01 ? "Test" 'Kom< führt zum Absturz bis zum Überschreiben
des int. EEPROM (zum Glück gibt es Restore" :)
es liegt offensichtlich am Kommentar inline zur Basiczeile.
Hi Klaus, 1. Bug-reports sind kein Gemecker, sondern für die Fehlerbeseitigung notwendig. 2. MiBytes (Mebi-Bytes) sind 2^20 Bytes, MBytes eigentlich 10^6 Bytes. Ich gebe zu, Binär-Prefixe werden noch recht selten benutzt. 3. Muss ich am WE mal nachschauen. Als "Workaround" einfach einen Doppelpunkt vor den Kommentar setzen, das sollte helfen. Gruß Jörg
Hi Joerg , das ist wieder kein Gemäcker: >CLS< >Getchar A, 0, 0< `möchte Leerzeichen(Dez 32) zurücklesen >? A< ergibt 0 und nicht 32! Du hast wahrscheinlich vergessen, bei der Umschaltung des Video-Modes den Video-RAM entsprechend zu initialisieren. Klaus
Hi Jörg, >VMODE 3< >GETPIX A,0,0< >? A< verabschiedet sich -> hängt! (kein Rücklesen des BildWiederhohlSpeichers möglich) Wurmi 'xxxo' im Text-Modus in 60 Basic-Zeilen implementiert. :) Dieses Spiel setzt bei dem beschränkten Speicher ein Rücklesen des BWS voraus. Würde es gerne im Video-Modus 3 zum Laufen bringen. Ich habe alles Mögliche versucht (alle Video-Modis), offensichtlich hakt es am "GETPIX". Gruß Klaus
Hi Klaus, danke für die Hinweise. Die Probleme sollten jetzt soweit behoben sein, Ursache lag in einem falschen Sprungziel in der Getpixel-Routine im Interpreter. Weiterhin habe ich das Löschzeichen auf 0x32 umgestellt und eine Kommentar-Erkennung in den PRINT-Befehl eingebaut. Doku ist noch unverändert, Gruß Jörg
Hmmm, es scheint immernoch ein Fehler drin zu sein, in den Modi 1,2 und 5 wird die Farbe und nicht der Palettenindex zurückgegeben. Werde ich mir heute abend nochmal anschauen... Gruß Jörg
Hi Jörg, habe Wurmi in "Jörg-Basic" auf 32 Basiczeilen implementiert. Läuft unter Version 0.89. Habe momentan leider keine zwei Tastaturen und kein serielles Kabel zur Verfügung. Werde es aber morgen hier veröffentlichen. Herzlichen Dank Klaus
Hi Jörg, anbei Wurmi als Text. Habe es nicht geschafft, es über die ser. Schnittstelle zu übertragen. (liegt wahrscheinlich an meinem Kabelsalat?) Ich nahm an, daß wenn man im Editor ctrl+F2 drückt auf der ser. wenigstens ein Zeichen gesendet wird. Aber es passiert nichts. Deshalb die harte Tour -> Bildschirm abschreiben :) Das Prog. ist auf Version 0.90 angepasst. Wer es unter 0.89 nutzen möchte, muß die Zeilen 22,28 und 35 anpassen. Dort ist dann die "32" durch "0" zu ersetzen. (ex. fehlerhafte Initialisierung) Da nur wenig Platz für Kommentar war :) eine kleine Prog. Beschreibung: in den Variablen X und Y befindet sich die Position des Kopfes. in Z ist das akt. Kopfzeichen (richtungsabhängig) dazu später mehr. in U und V befindet sich die Position den letzten Körperzeichens (U entspricht X , V->Y) in N wird der Spielstand gespeichert. B dient der Abfrage des Bildschirmes, C und D sind Hilfs-Varis. zum "Auswürfeln" einer neuen Futterposition. Der Trick an dem Programm ist, daß die Richtung des nachfolgenden Körpergliedes unsichtbar im Video-RAM codiert ist. Es wird mit unterschiedlich farbigen Leerzeichen gespielt. :) dh es wird der Video-RAM als Variablen Feld genutzt. viel Spass beim Spielen Gruß aus Chemnitz Klaus
Hi Jörg, dein Sackgänger Klaus, ... hab einen Epson LX-400 (Epson) unter der Fuchtel und wollte mal die par. Schnittstelle (SS) testen (drucken) ... leider musste ich feststellen daß, >? #2 %33< 'sollte eine "3" ausgeben nicht funktioniert (es kommt kein STROB auf Pin 1 der par. SS) ... senden an die ser. SS leider geht leider auch nicht :( >? #1 %33< Aber ich kann wenigsten sehen (Oszi) das Daten gesendet werden. :) Was für ein Kabel ist zu verwenden? (Modem, NullModem, Eigenbau?) ... oder liege ich mit der Syntax daneben, oder was mach ich falsch? Gruß Klaus
Hi Klaus, daß Drucken nicht geht, ist ein Bug. Und zwar kommt der daher, dass ich zwischenzeitlich mit externem Speicher am Parallelport experimentiert hatte. Dazu musste ich aber den Parallelport dekativieren, die Umschaltung wurde im EEPROM gespeichert. Da bei mir das Umschaltbit auf 0 steht, ist der Fehler nicht aufgetreten, wohl aber bei allen bei denen das Bit defaultmäßig auf 1 steht. Werde ich rausmachen, in der library.asm in libmio müssen nur die Zeilen 2535-2537 entfernt werden:
1 | ... |
2 | - lds XH,libmio_sysconf |
3 | - sbrc XH,4 |
4 | - rjmp libmio_ppar_4 |
5 | ... |
Wie herum das serielle Kabel sein muß, weiß ich jetzt nicht aus dem Kopf, kann aber abends mal nachsehen. Wichtig ist auch, dass die Bitrate (1200/2400) auf beiden Seiten übereinstimmt. Gruß Jörg
Danke Joerg, ich hab aber leider nichts womit ich Deine Quelle asseblieren könnte. :( Dem ser. Problem bin auf der Spur. Gruß Klaus
... hab jetzt erstmal ein brauchbares "Kabel" gefunden, aber da ergibt
sich schon wieder eine Frage "Linux/Windows":
Warum "Zeile" + 0x10 ?
.... und nicht "Zeile" + 0x10 + 0x13 'ANSI-conform'
Dein Albtraum :) Klaus
Hi Klaus, da ich privat nur Linix bzw. Solaris nutze und meine Projekte in erster Linie für mich selbst entwickle, ist es bei mir eben nur 0x0a. Aber, da noch etwas Platz auf der Config-Seite und das Bit für die Parallelport-Umschaltung ssowieso frei ist, habe ich eine Umschaltung zwischen CR+LF und LF only eingebaut. Die gilt allerdings für seriellen und parallelen Port gemeinsam. Danke, dass Du das Wurmi-Programm veröffentlicht hast. Allerdings fehlen zwei Dinge: 1. In der ersten Zeile muß "PROGRAM:" und der Programmname stehen 2. In der letzten Zeile (nach dem Programm) muß ein "#" stehen, damit das Ende erkannt wird. Gruß Jörg
hi Joerg, Danke für für das Hex-File. Komme aber heute nicht mehr zum Testen. Trozdem Herzlichen Dank. Klaus
Hi Jörg, das Problem mit der par. SS ist gelöst. :) Aber mit der ser. SS komme ich einfach nicht zurecht. Mit meiner PC Hardware ist alles io auch das Kabel ist io. Getestet mit einer Verbindung zwischen Rx und Tx am Kabelenden zum ChipBasic2. Die neg. Spannung auf Deinem Board wir auch erzeugt. Ich vermute das die etwas knappen Spannungen von -5V und 5V dem RS 232 PC-Chip nicht reichen. Ich werde es mal mit einem anderen PC versuchen. Mit dem Teil zu arbeiten macht meiner Tochter (16) und mir riesigen Spass! Klaus
Hi Jörg, habe Deinen Zeilen - Parser heute auseinander genommen. Hochachtung!!! Da wird ja kein Takt verschwendet!!! Meine Tochter fragt, ob es möglich ist (ohne großen Aufwand)den Befehl Note x in Note x,z zu ändern? Dadurch würde es möglich, mit Deinen Basic - Befehlen auch einfache Midis abzuspielen, z ist dabei die Notenlänge. Wenn es der Speicherplatz und deine Zeit zulässt, wäre es eine große Bereicherung. Gruß Klaus
Hi Klaus, da sie Tonausgabe im Hintergrund erfolgt, ist das nicht ganz so einfach. Denn der Befehl NOTE x wartet nicht bis die Note abgespielt ist, sondern gibt nur den Startbefehl und kehrt dann sofort wieder zurück. Dabei ist es sogar möglich, den gerade laufenden Ton mit einem neuen zu unterbrechen. Das Timing muss man also sowieso selbst realisieren oder den eingebauten Sequenzer (PLAY) bemühen, der auch komplett im Hintergrund läuft. Ich werde mir aber mal überlegen, inwieweit es mit einem zweiten Parameter möglich ist, die Hüllkurve zu ändern. Gruß Jörg
Wenn auch nicht ganz ausgetestet, will ich mal ein neues Feature vorstellen, welches mir vorhin zur "Notemproblematik" eingefallen ist. Was eigentlich noch gefehlt hat: MULTITASKING ;-) Und das gibt es jetzt. mit dem Befehl ONSYNC lässt sich eine Zeilennummer angeben, zu der ein zeitgesteuertes GOSUB ausgeführt wird.
1 | ONSYNC 10 - alle 1/50s (PAL) wird ein GOSUB zur Zeile 10 ausgeführt |
2 | ONSYNC 10,50 - alle Sekunde (PAL) wird eine GOSUB zur Zeile 10 ausgeführt |
3 | ONSYNC 0 - Multitasking wird wieder abgeschaltet |
Der Aufruf erfolgt immer am Ende des sichtbaren Bildbereiches und natürlich nach Abarbeitung des gerade ausgeführten Befehles. Das Ganze funktioniert natürlich nur innerhalb des gerade aktiven Programmes. Außerdem kann man die Scancodes seiner Tastatur anzeigen lassen, wenn im Intro die rechte Shift-Taste gedrückt wird. Abbrechen geht dann nur mit CTRL+ALT+DEL Gruß Jörg
Hi Joerg, mir war micht bewusst, was das mit der Ton-Länge für Kreise zieht! Ich werde Dein ONSYNC mit Freude testen. Da ich zwischendurch Brötchen verdienen muß, wirds erst morgen. Klaus
Hi Jörg, Dein Albtraum ist wieder da. Habe Deine Version 0.91a getestet. Ich weiß nicht, warum Du Dich auf solche Futures einläßt, wobei Du ganz genau weißt, daß das nicht funktionieren kann. Du hast viel zu wenig RAM zur Verfügung, um einen Multitasking zu implementieren. Sei nicht böse, aber es ist glaube ich besser, dies wieder auszubauen. Erklärung hierzu später. Deine neue Funktion ONSYNC: z.B. geht: 01 ONSYNC 4,100 02 GOTO 2 03 04 NO 20 05 RET z.B. geht nicht: 01 ONSYNC 4,1 02 GOTO 2 03 04 NO 20 05 RET Anmerkung: einziger Unterschied::in Zeile 01 die Zahl hinter dem Komma nach der 4! z.B. geht doch: 01 ONSYNC 4,1 02 GOTO 2 03 04 NO 20:RET (einziger Unterschied zur nicht gehenden Version: RET in Zeile 4, getrennt durch Doppelpunkt von Vorbefehl) z.B geht doch nicht: 01 ONSYNC 4,1 02 GOTO 2 03 04 NO 20 : RET (einziger Unterschied zu "geht doch" : in Zeile 4 vor und hinter dem Doppelpunkt, der die zwei Befehle trennt, jeweils ein Leerzeichen) Soviel zu ein Paar Beispielen, die einen Verzweifeln lassen (bevor der AHA-Effekt da) Multitasking: auch wenn Du Dich auf und nieder reckst, Du hast maximal 2 KB im 644 zur Verfügung, davon geht eingehöriger Teil für den BWS drauf. Was ist, wenn Leute auf die Idee kommen, zu schreiben: 01 ONSYNC 10,10 02 ONSYNC 20,20 03 ONSYNC 30,30 ....... dann brauchst Du mindestens den 3-fachen Stack-Platz? Nichts für ungut Klaus
Hallo Klaus, warum sollte das nicht funktionieren. Genaugenommen ist das ja eine Art Timer-Interrupt. Dazu wir einfach nach dem aktuellen Befehl ein GOSUB n eingefügt, wenn ein "Timer-Überlauf" aufgetreten ist. Es wird also nur ein ganz normaler Stack-Eintrag benötigt (der Mega644 hat übrigens 4K RAM). In Deinem letzten Beispiel würde letztendlich alle 0,6 Sekunden zur Zeile 30 gesprungen, da die ersten beiden Einstellungen wieder überschrieben werden. Der (optionale) zweite Parameter gibt den Timer-Faktor an, wobei aber nur die unteren 8 Bits genutzt werden. Damit lassen sich Interrupt-Abstände zwischen 1/50s und ca. 5 Sekunden realisieren. Die Effekte bei einem Timer-Faktor von 1 und dem NOTE Befehl liegen einfach daran, dass sowohl das GOSUB zur Zeile als auch das Setzen der Notenparameter und auch das Abfahren der Hüllkurve im gleichen Frame sehr schnell aufeinander erfolgt. Das Leerzeichen und auch der Sprung in die nächste Zeile können dieses Timing minimal ändern. Aber ich werde das am WE nochmal untersuchen. Gruß Jörg
Hi Joerg, mit dem Stack und der RAM-Größe hast Du natürlich Recht. (mit fällt es immer wieder schwer, mich zu erinnern, daß alle Variablen Global sind! und somit beim Unterprogammaufruf fast kein zusätzlicher RAM verbraucht wird) aber schau Dir bitte noch mal Dein "ONSYNC" an: >01 ONSYNC 10,100< >02 ONSYNC 11,200< >03 ONSYNC 12,300< >06 ? A,B,C< >07 GOTO 6< >10 A=A+1 : RET< >11 B=B+1 : RET< >12 C=C+1 : RET< in diesem Fall zählt nur "C" hoch! Gruß Klaus
Hi Klaus, das ist richtig so, denn es gibt nur ein ONSYNC. Die Einstellungen von Zeile 1 und 2 werden in der jeweils nächsten Zeile überschrieben. (Wobei die 300 der 44 entspricht, da der Zähler nur 8 Bit breit ist) Und damit wird nur die Routine in Zeile 12 knapp alle Sekunde aufgerufen. Allerdings kann man auch ONSYNC in der aufgerufenen Routine verwenden, um z.B. mit ONSYNC 0 weitere Aufrufe zu unterbinden. Gruß Jörg
Hi Jörg, bitte bezeichne nicht einen Hook auf einen Timer als Multitasking. Beschreibe bitte in Deiner Dokumentation, daß dieses Future nur einstufig funktioniert. Dann ist es eine tolle Erweiterung :) Gruß Klaus
Hi Jörg, mich lässt die Idee vom Multitasking nicht los! vieleicht so: 'Einrichten von Tasks: >01 ONSYNC 1,10,100< 'erster Parameter ->Task Nr. >02 ONSYNC 2,11,200< >03 ONSYNC 3,12,300< 'Main Loop >06 ? A,B,C< >07 GOTO 6< >10 A=A+1 : RET< 'Task 1 >11 B=B+1 : RET< 'Task 2 >12 C=C+1 : RET< 'Task 3 'Ausschalten von Task 1 ONSYNC 1,0 Es müssen ja nicht beleibig viele Tasks möglich sein.(zb max 4) Oder 2. Ansatz >01 ONSYNC1 10,100< 'Startet Task 1 >02 ONSYNC2 11,200< 'Startet Task 2 usw. Dann hättest Du zwar 4 neue Schlüsselwörter (bei max 4 Tasks), aber das käm dann einem "echten" Multikasking schon ziemlich nahe. Bitte sag jetzt aber nicht das ich unter Futurrismus leide! :) Gruß Klaus
Hi Jörg, Dein Albtraum schreibt wieder. Ich suche das ganze Wochenende, warum die Kommunikation mit dem PC (RS232) nicht funktioniert. Bin darauf gestoßen, dass Du es mit der Länge des Stopp-Bits nicht so richtig ernst nimmst. Tipp mal bitte ein und verbinde Rx mit Tx auf dem CB2 (Chip-Basic2): >01 SPUT 31< >02 SGET A< >03 ? A< >04 GOTO 1< Bei 1200 Baud funktioniert das vom Feinsten. Aber bei 2400 Baud gehen die Probleme los. Bei 2400 Baud zeigt es mir in regelmäßigen Abständen: 143 -> 0b10001111 und 31 -> 0b00011111 Gruß Klaus
ps. der Sender sollte immer etwas langsamer sein, als der Empfänger, der Zeichen erwartet!. (sonst klappt die asynchron - Übertragung nicht) Gruß Klaus
Hi Klaus, wieso sollte der Sender langsamer sein? Dann würde ja überhaupt nichts mehr stimmen, denn es findet ja keine Re-Synchronisation statt. Die Ursache dafür, dass dein Programm so nicht geht, ist eine ganz andere: Sowohl Senden als auch Empfangen sind state-machines, die mit der Horizontal-Frequenz laufen. Durch SPUT bzw. SGET werden diese angestoßen. Solange kein Zeichen empfangen werden soll, ist die Empfänger-FSM in Warteposition und kümmert sich nicht um den Pegel auf der seriellen Leitung. Erst wenn sie angestoßen ist, wird zuerst auf das Startbit gewartet und dann die Bits in entsprechend zeitlichem Abstand eingelesen. Wenn Du jetzt sendest und das gesendete Zeichen empfängst, beginnt der Sender zu senden, bevor der Empfänger anfängt, auf das Startbit zu warten. Je nachdem wieviel Zeit dazwischen vergeht, klappt es oder auch nicht. Dann wird nämlich das Startbit zu spät erkannt, die Bits sind um eine Stelle nach rechts verschoben und in Bit 7 steht das 1. Stopp-Bit. Wenn Du jetzt vor das SPUT ein SYNC 1 setzt, sollte es klappen, ganz einfach deswegen weil der Code dann in der vertikalen Austastlücke und damit schneller abgearbeitet wird. Bei 1200 Bps klappt es etwas besser, einfach weil dort das Timing nicht so kritisch ist. Auch wenn der Empfänger auf die Startbit-Flanke wartet, lässt sich damit das Problem nicht lösen. Inwieweit sich da was machen lässt, muß ich erstmal sehen, wahrscheinlich aber nicht da ich nicht beliebig viel Code in die horizontale Austastlücke packen kann. Zum Thema Multitasking fehlt es momentan am RAM, welches mittlerweise einfach "voll" ist. Eventuell könnte man das Array auf 512 Bytes verkleinern, aber das muß ich mir nochmal überlegen. Was noch reinkommt ist VPOKE und VBYTE() um direkt auf das Video-RAM zugreifen zu können und ein weiterer Videomodus: - 23 Zeilen a 30 Zeichen - nur 64 verschiedene Zeichen, diese sind alle im RAM definiert - In den Zeichen kann jedes Pixel jede der 8 Farben haben Dann ist auch langsam der Flash voll außer ein bisschen Platz für Bugfixes. Gruß Jörg
Hi Jörg, zitat: >Sowohl Senden als auch Empfangen sind state-machines, die mit der >Horizontal-Frequenz laufen. Durch SPUT bzw. SGET werden diese >... >erstmal sehen, wahrscheinlich aber nicht da ich nicht beliebig >viel Code in die horizontale Austastlücke packen kann. lass es so, wie es ist! Ich habe eine "Krücke" gefunden, mit der ich dieses Problem PC-seitig umgehen kann. kurze Beschreibung: - ein Stopbit kann Senderseitig solang sein, wie es will, aber nicht Emfängerseitig! (wenn nichts gesendet wird, wird einfach Tx auf Stopbit-Pegel gesetzt und so gelassen) - aber jetzt kommt das 2. Byte vom CB2 - der Emfängertreiber erwartet mindestens zwei Stopbits (9600,N,8,2) aber es kommen schon nach 1.2 Bits wieder Flanken, dann erkennt der Treiber es als Frame-Fehler! Lösung: PC erwartet Daten: PC beim Emfangen, die serielle SS auf ein Stopbit initialisieren und dann öffnen. Wenn danach keine Daten mehr erwartet werden, dann schließen. PC sendet Daten: ser. SS auf zwei Stopbit int., öffnen, Daten senden, danach schließen. Geht leider nicht "zeitgleich" bidirektional, ist dem einfachen Aufbau des CB2 geschuldet! Das ist kein Gemecker, sondern ein Lob. :) ____________________________________________________________________ Dass der Sender die Daten langsamer senden muß, als der Emfänger sie verarbeiten kann, ist klar. Du hast das langsamer Senden in dem letzten Post warscheinlich falsch interpretiert! (nicht langsamere Bit-Rate, sondern langsamere Byte-Folge!) :-) ____________________________________________________________________ jetzt aber noch eine ganz große Bitte: folgende Situation: Habe CB2 bis jetzt mit einem Steckerschaltnetzteil 9V über den Festspannungregler on Board bertieben. Da ich eine uralte PS2 Tastatur, die fast 200mA schluckt, betreibe, kommt der Festspannungs- regler schon ganz schön ins Schwitzen. Dachte mir, nimmste ein altes konv. Steckernetzteil mit 6V und genügend großen Ladeelko und probierst es aus -> alles OK. ext. Flash r/w geht, ext EERprom r/w geht, CB2 neu starten geht, meldet sich normal. nun das böse Erwachen -> "Pong" geht nicht mehr, alles andere schon noch! Restore durchgeführt, das gleiche. Zeilenweise die Quelle durchgesehen, alles Ok. "Pong" geht nicht mehr! "Hilfe!!!" Ok CB2 an ISP-Programmer angeschlossen und siehe da, im int. Flash steht was anderes als es sollte. Selbst die Fuses sind verändert!!!!!! Oszi an die Betriebspanung und siehe da, Sie bricht auf 4.35V zusammen! (aber nur bei r/W Zugriffen auf den ext. Flash). daraufhin habe ich im DB mal unter "23.8.11 Preventing Flash Corruption Page 286" nachgelesen: >A Flash program corruption can be caused by two situations ... >... the CPU itself can execute instructions incorrectly, if the supply >voltage for executing instructions is too low. offensichtlich nicht nur, wenn der Bootloader versucht, den Flash neu zu schreiben, sondern auch, wenn der int. EEProm bei Unterspannung beschrieben wird. Kann man das durch ein geeignetes "Burn-out Detection" ausschließen? Ps. Der µC und die Schaltung haben keine Macke! 9V-Schaltnetzteil ran und alles ist gut! (Festspannungregler schließe ich aus) Beschreibe diese beiden Sachen bitte unbedingt in Deiner Doc! Gruß Klaus
Hallo Klaus, die Stopp-Bits senderseitig länger zu machen ist überhaupt kein Problem, werde ich auf jeden Fall noch ändern. Für die Brown-out detection schaue ich mir mal die Fuses an, ob die richtig gesetzt sind. Bis jetzt hatte ich keine Probleme damit, da ich das Ganze aus zwei Li-ION Zellen betrieben habe, deren Elektronik sowieso schon früher abschaltet. Die Doku muss ich sowieso überarbeiten, da die neu hinzugekommenen Videomodes 4 und 6 teilweise nur über vpoke programmiert werden können. Das heisst u.a. den Aufbau des Bildspeichers in allen Modi erklären. Neben dem Mode 4 habe ich jetzt noch einen gänzlich neuen Mode "erfunden", eine Art Vektor-Mode. Damit wird es möglich sein, große ein oder alternierend zweifarbige Bildschirmbereiche sehr schnell in Größe und Gestalt zu ändern. Oben und unten gibt es dazu noch jeweils eine Textzeile, die sich wie die ersten zwei Zeilen im Mode 0 verhalten. Das Ganze wird folgendermaßen aufgebaut sein: - Zwei Zeilen a 30 Zeichen, Vorder- und Hintergrundfarbe für jedes Zeichen - Tabelle mit 105 Einträgen, welche eine der 105 Zeilendefinitionen auswählen - 105 Zeilendefinitionen mit je 12 Einträgen Ein Zeileneintrag besteht aus der Position (111-253) und aus einem Farbbyte. Dabei entspricht das High-Nibble der ersten Farbe und das Low-Nibble dem Wert, mit dem die Farbe im nächsten Schritt XOR verknüpft wird. Dazu kommen noch schnelle BCOPY-Routinen in den Modi 4 und 6. Zuguterletzt habe ich noch ein API mit den wichtigsten Funktionen und eine rudimentäre Binärdatei-Erkennung implementiert. Und damit ist der Flash auch bis auf ca. 96 Words ausgereizt, weitere Funktionen wird es wohl nicht mehr geben. Ach ja, und die Noten habe ich noch etwas geändert, ab Note 128 ist die Hüllkurve länger, dafüe liegt jetzt an Note 63, 127, 191 und 255 Rauschen und der Sequenzer macht bei 127 und nicht mehr bei 254 eine Pause. Hexfile kommt noch, ich will nur die Tabelle für das serial out etwas ändern... Gruß Jörg
>Ach ja, und die Noten habe ich noch etwas >geändert, ab Note 128 ist die Hüllkurve länger, dafür liegt jetzt an >Note 63, 127, 191 und 255 Rauschen und der Sequenzer macht bei 127 und >nicht mehr bei 254 eine Pause. klingt das nach 4 Oktaven? mit 1/4 und 1/2'en Noten? wäre ja absolut toll! Und noch toller mit mit 1/16 Pause? Bin gespannt wie "Flitzebogen"! Damit kann man fast alles spielen!. Gruß Klaus Klaus
Du hast das offensichtlich schon implementiert!: Ton (Frequenz, Länge) Pausen (Länge). Wenn Du Hilfe brauchst, sag was! Klaus
Hi Klaus, es ist so ähnlich... Den Sequenzer habe ich etwas umgebaut, und zwar besteht jetzt jede Note aus 2 Bytes, den eigentlichen Notenwert und die Dauer in "Ticks" bis zur nächsten Note. Eigentlich ist damit die Pause relativ zweckfrei. Dadurch sollte es etwas einfacher werden, da man Noten vom Blatt schnell in entsprechende Daten konvertieren kann. Und, die Tonhöhen sollten den Halbtonschritten entsprechen, damit wären da etwa 5 Oktaven Tonumfang. Los gehts mit C", glaube ich. Mit dem Speed-Parameter gibt man nun die Geschwindigkeit der "Ticks" an. Aber ich muß das noch testen, ob es wirklich so funktioniert :-) Gruß Jörg
Um die Zeit bis zum nächsten Release zu überbrücken, wieder mal eine neue Version zum Testen. Zuerst wird auffallen, dass P8 ein anderes Icon hat. Das liegt daran, dass die aktuelle Version auch Binärdateien unterstützt. Man kann das Programm direkt aufrufen, es geht aber auch vom BASIC aus:
1 | 01 GOSUB 8,0 |
Die 0 ist dabei der Offset in Words. Der Sequencer funktioniert nun so, dass jede Note aus 2 Bytes besteht, der Tonhöhe/Klangfarbe/Hüllurve und der Dauer in Ticks bis zur nächsten Note.
1 | 01 DATA 0,36,2,41,4,45,4,41,4 |
2 | 02 PLAY 0,4,6 |
3 | 03 GOTO 3 |
Der erste Wert bei PLAY gibt die Anfangsadresse im Array an, der zweite die Anzahl der Noten (max. 256) und der dritte die Dauer eines Ticks in Frames (1/50s bei PAL). Durch die Notwendigkeit einer überarbeiteten und stark erweiterten Dokumentation wird sich aber das nächste offizielle Release etwas hinziehen, da ich auch noch parallel an einer englischen Version arbeite. Gruß Jörg
Mist, jetzt habe ich den M644 fertig gemacht und in der Firma liegen lassen. Bis morgen. Klaus
Hi Jörg, der Sequenzer ist ganz großes Kino! (verneige mich) Danke Frage: Auf Programmplatz 8 zeigte es mir ein neues Icon zum Ausführen von Binärdateien nach einem Restore, wo Programmplatz 8 belegt war, wurde dieses durch das alte Basic-Programm überschrieben. War das so geplant? Bitte schreibe mal was zum Aussehen der Binärdateien. Ich kann mir noch nicht so richtig vorstellen, wie das funktionieren soll. Aus deiner spärlichen Beschreibung ist nicht viel rauszulesen. Klaus
Hi Klaus, für die Binärdateien fehlt natürlich noch einiges und es wird bestimmt noch etwas Zeit brauchen. Sie haben einen etwas anderen "Kopf", damit das System weiß, was es damit machen soll. In das P8 habe ich einfach etwas Code reingeschrieben um das Ganze zu testen. Beim Restore ist natürlich ein BASIC-Header drübergeschrieben worden... Die Idee ist folgende: Binärdateien haben nach dem Dateinamen als 13.Zeichen ein "N" (für native) stehen, BASIC-Datein meistens ein 0xff. Von Byte 16 bis Byte 3071 kann AVR-Binärcode stehen, gestartet wird bei Byte 16. Um das Ganze auch aus dem BASIC heraus sinnvoll z.B. für Erweiterungen nutzen zu können, wird beim GOSUB ein Offset (in WORDS) angegeben. Wenn also z.B. GOSUB 8,0 steht, wird zuerst anhand des Headers geprüft, ob das Programm eine Binärdatei ist. Wenn nein, wird es zu einem Fehler kommen da es im BASIC keine Zeile 0 gibt. Im anderen Fall wird ein CALL zum 8. Word (Byte 16) des Binärprogrammes gemacht. Da im Flash ja schon sehr viele nützliche Routinen stehen, wird es eine Art API geben. Das ist ein fester Adressbereich, über den zur Zeit ca. 75 Funktionen angesprungen werden können. Das ist wichtig, da sich nach einer Codeänderung die Adressen der eigentlichen Funktionen ändern können. Zu diesem API wird es einerseits eine komplette Beschreibung und auch eine Include-Datei (ohne Makros!, sollte auch mit anderen Assemblern außer dem AVRA gehen) geben. Damit sollte es möglich sein, sowohl komplette Programme als auch Erweiterungen in Assembler zu schreiben. Aber wie schon gesagt (geschrieben), die Dokumentation wird noch etwas Zeit beanspruchen. Gruß Jörg
Hallo. Ich beobachte avr chipbasic(2) schon länger und habe es auch schon 2x aufgebaut.. funktioniert prima. Die Frage, die mich (und wahrscheinlich auch andere) beschäftigt wäre eine portable Version mit TFT und oder ggf. FBAS/S-Video für die kleinen 7-9" TFT Fernseher.. Das Projekt 'uzebox' verwendet eine ADC725 RGB2NTSC Wandler.. wäre das hier auch zu verwenden..? Dort wurde auch ein RGB-TFT direkt angeschlossen... http://www.dutchtronix.com/UzeboxConsole.htm http://belogic.com/uzebox/ Hier im forum gibts ja auch jede Menge knowhow bezüglich LCD's and deren Anschluß.. Wäre geradezu traumhaft, wenn man das alles kombinieren könnte und letztendlich ein tragbares avr chipbasic Gerät bauen könnte.. Peter
Hallo Peter, natürlich ist das möglich und auch in der aktuellen Dokumentation ist der Anschluß eines NEC TFT beschrieben. Für diesen Zweck gibt es extra den "CSYNC" Jumper, mit dem man HSYNC und VSYNC auftrennen kann. Alternativ geht auch ein RGB->FBAS Wandler, dazu habe ich mir einen mit nem CPLD entwickelt, das Ganze aber etwas einschlafen lassen da ich es selbst nicht (mehr) brauche weil ich mir ein mobiles Teil mit eben dem NEC TFT gebaut habe. Gruß Jörg
Hallo Jörg. CPLD Lösung: http://www.jcwolfram.de/projekte/vhdl/fbas_enc/main.php Korrekt? Nun, da braucht man CPLD Programmer.. 2te Platine.. alles lösbar.. aber aufwendig.. Da gibts doch auch den A520 Externen Modulator von Amiga, der den MC1377 RGB->FBAS Wandler enthält.. hat jemand schon einmal sowas probiert anzuschließen..? NEC Display: ok. Type lat Bild: NEC NL3224AC35-01 Muss mal sehen, wo ich so eins auftreiben kann... Gibts da noch mehr Typen, die gehen sollen..? Gibts Bilder vom Display+AVR Chipbasic..? Danke ersteneinmal.. wieder viel zu googlen ;-) Peter
Hallo Peter Bilder kann ich schon mal machen, allerdings ist die umgebaute Frühstücksdose nicht unbedingt der "Hingucker"... Ich hab mir auch schon überlegt, eine Variante für die hier in einem anderen Thread beschriebenen "Spielzeug-Displays" zu entwickeln, indem ganz einfach die Zeilen, die das Display auslässt verdoppelt. Allerdings sinkt dann die effektive Auflösung und man muß es eventuell immer an das konkrete Display anpassen. Im Moment bin ich aber erstmal dabei, die "normale" Version ein klein wenig weiterzuentwickeln. Erste Tests mit den neuen Videomodi haben doch ganz schnell Grenzen, insbesondere bei der Geschwindigkeit gezeigt. Gruß Jörg
So, nun mal wieder eine "Zwischenversion", in der u.a. einige Bugs beseitigt sind: - bei FOR konnten Funktionsausdrücke "wrong expression" herbeiführen - Wortweises Schreiben ins Array ließ immer zwei Bytes aus - Funktionen gingen bei INPUT nicht Die Dokumentation geht langsam voran, einen zwischenzeitlicher Versuch, anstelle LaTex OpenOffice zu benutzen, habe ich schnell wieder aufgegeben. Außerdem haben momentan leider andere Dinge wie Jobsuche Vorrang. Gruß Jörg
Oh, hi Jörg. Ich wünsche Dir viel Erfolg bei deiner Job suche! Hatte mich schon gewundert das Du in letzter Zeit relativ wenig Aktiv bist. Gerade auch in Bezug z.B. auf dem Handheld.... Aber wie Du schon geschrieben hast, Job suche hat in jedem Fall vorrang! Gruß Harry
Hi Jörg, tausend Dank für Dein Chip-Basic. Setze meine alten "AC1" Quellen Stück für Stück um. zb. DCF77 ... Es gelingt immer besser und schneller. thx klaus ps wenn Du noch ein paar Words hast: Windows: CrLf (0x13,0x10) Linux: LF (0x10) Mac OS Cr (0x13) only.
Nur CR wird es in der nächsten Version auch geben (wie auch die eher zweckfreie Variante, gar kein Zeilenende auszugeben, aber das hat sich so ergeben). Ebenso lässt sich das serielle Interface zwischen meiner Schaltung und einer "Standard"-Schaltung einstellen, um z.B. MAX232 oder FTDI als Schnittstellenwandler nutzen zu können. Da ich dabei die Belegung der Konfigurationsbytes geändert habe, muß ich erst noch ausprobieren, ob alles auch wieder richtig funktioniert. Viele Grüße, Jörg
So, jetzt wieder mal ein neues Update. Das Projekt nähert sich langsam der finalen Version. Schon allein deshalb, weil nur noch ein paar Bytes im Flash übrig sind. Außerdem will ich die Dokumentation in Angriff nehmen. Mittlerweile habe ich die Videomodi ab Modus 4 nochmal umgestrickt, damit gibt es 2 Modi mit user-definiertem Zeichensatz. Die Flash-Speicherroutinen habe ich etwas geändert, das Videosignal wird nicht mehr teilweise abgeschaltet sondern nur noch dunkelgetastet. Außerdem lassen sich nun Programme zur Laufzeit auf dem Dataflash-Modul speichern und auch von dort laden. So sollen Projekte möglich werden, die mehr als 95 Zeilen benötigen. Zusätzlich gibt es die Funktion FFIND(X),X ist ein Zeiger auf das Array, erstes Byte ist der Dateityp (z.B. 16 für Programm und 252 für freien Speicher), zweites die Länge des Suchstrings, danach folgt der Suchstring selbst. Ergebnis ist die Dateinummer oder -1, falls nicht gefunden.
1 | 01 DA 0,252,0:A=FFIND(0) |
2 | 02 DA 0,16,4,"test":B=FFIND(0) |
3 | 03 IF (A<0)#(B<0) THEN END |
4 | 04 SAVEP A,8:LOADP B,8 |
5 | 05 GOSUB 8,1 |
6 | 06 LOADP A,8:FDELETE A |
testet, ob ein leerer Speicherplatz und das Programm "test" vorhanden sind. Wenn ja wird das Programm 8 gesichert und das Programm "test" dorthin geladen. Nach dem Aufruf über GOSUB wird der ursprüngliche Zustand wiederhergestellt. Doku kommt dann als nächstes, wie ich halt Zeit dazu habe. Ansonsten habe ich eine neue Stelle und kann so die Dinge in Ruhe angehen... Gruß Jörg
Hallo Jörg, meinen herzlichen zum neuen Job ;-) Muß auch nun unbedingt mal die neue Version testen. Wünsche ein schönes Wochenende!
Zum Ostern gibts mal wieder eine neue Version, ich hoffe nicht dass es nur ein "Osterei" ist. 1. In der letzten Version war bei der Configpage CR und LF vertauscht 2. Der Videomodus 1 hat sich etwas geändert 3. Der Formelparser sollte bei Funktionsaufrufen wesentlich schneller sein 4. Ein paar neue Funktionen und Bugfixes 5. Wechsel von der GPLV2 zur GPLV3 Doku fehlt leider immernoch :-( bin aber dabei. Bisher war der Videomodus 1 168x116 Pixel "zweifarbig". Das habe ich jetzt etwas erweitern können, ähnlich wie z.B. beim ZX Spectrum lassen sich jetzt für jeweils 8x8 Pixel (am unteren Rand 4x8 Pixel) Vorder- und Hintergrundfarbe festlegen. Allerdings sollte zur Textausgabe die eingestellte Hintergrundfarbe auch der dargestellten entsprechen, andernfalls werden (systembedingt) nur ausgefüllte Rechtecke gezeichnet. Dann gibt es noch ARC und PIE zum Zeichnen von Kreis- oder Ellipsenausschnitten. Bei PIE wird das Segment mittels zweier Linien zum Mittelpunkt geschlossen.
1 | 01 VM 1 |
2 | 02 PIE 50,50,25,25,0,270,3 |
3 | 03 ARC 50,50,40,40,180,450,4 |
zeichnet ein violettes Kreissegment und einen grünen Bogen. Die Parameter sind: Y0,X0,radius y,radius x,anfangswinkel,endwinkel(,farbe) Der Endwinkel sollte größer als der Anfangswinkel sein, ansonsten kann die Funktion recht lange brauchen... Gruß Jörg
Tja, und wieder ein paar Bugfixes... 1. Während des Speicherns wird das Videosignal wieder abgeschaltet. Das ist zwar nicht optimal, aber das teilweise Flackern der Anzeige in der letzten Version hat doch etwas genervt. 2. GOS als Abkürzung von GOSUB hat nicht mehr funktioniert, hing mit den neuen Schlüsselwörtern zusammen 3. Das Mode1-Oszi hat nicht mehr richtig funktioniert, da es durch den neuen Videomode 1 zu Speicherbereichs-Überschneidungen kam. Ein bisschen mehr Feedback würde mich freuen... Gruß Jörg
Angehängte Dateien:
-
oszi_neu.png
634 Bytes
Und hier mal das "alte" Oszi-Programm etwas aufgemöbelt...
1 | 01 'init screen |
2 | 02 COLOR 5,0 :VMODE 1 |
3 | 03 BOX 7,31,108,161:Y=50 |
4 | 04 Q=100-1024/12:DRAW Q,28,Q,31 |
5 | 05 COL 6,0:? @ Q-5,0;" 5V"; |
6 | 06 COL 5,0 |
7 | 07 Q=100-512/12:DRAW Q,28,Q,31 |
8 | 08 COL 6,0:? @ Q-5,0;"2,5V"; |
9 | 09 COL 5,0 |
10 | 10 Q=100-0/12:DRAW Q,28,Q,31 |
11 | 11 COL 6,0:? @ Q-5,0;" 0V"; |
12 | 12 COLOR 4,0:CBOX 1,4,12,19 |
13 | 13 COLOR 4,0 |
14 | 14 'the main loop |
15 | 15 A=100-ADC(0)/12 |
16 | 16 J=J+1: IF J=3600 THEN J=0 |
17 | 17 A=57-SIN(J*2)/13+COS(J*5)/13 |
18 | 18 BCOPY 1,8,33,12,16,8,32 |
19 | 19 DRAW Y,158,A,159:Y=A |
20 | 20 SYNC 1:GOTO 15 |
21 | # |
Angehängte Dateien:
-
eatman3.png
1,1 KB
Und jetzt noch ein PACMAN-Clone als Beispiel. Es demonstriert (recht eindrucksvoll) was mit dem Basic-Computer machbar ist.
1 | 01 BO 0:P=0:GOS 64:DA 64,0,4,32,0 |
2 | 02 ALERT 64:X=AR(1):Y=AR(0):D=21 |
3 | 03 GOSUB 48:FOR F=1 TO 4:A=F*5 |
4 | 04 IF AR(A)<>AR(3) THEN GO 9 |
5 | 05 IF AR(A+1)<>AR(4) THEN GO 9 |
6 | 06 IF G>0 THEN NO 98:P=P+20:GO 35 |
7 | 07 ? @AR(3)+1,AR(4)+4;%250; |
8 | 08 NO 255: BO 2:A=KEY(2):END |
9 | 09 NEXT :F=0:GOSUB 40 |
10 | 10 T=1-T: IF T=0 THEN GOTO 17 |
11 | 11 K=KEY(6):M=KEY(7) |
12 | 12 IF (K=-1) & (L=1) THEN X=X-1 |
13 | 13 IF (K=1) & (R=1) THEN X=X+1 |
14 | 14 IF (M=1) & (U=1) THEN Y=Y-1 |
15 | 15 IF (M=-1) & (D=1) THEN Y=Y+1 |
16 | 16 DA 0,Y,X:GO 32 |
17 | 17 FOR F=1 TO 4:GOSUB 40 |
18 | 18 S=U+D+L+R:M=N |
19 | 19 IF S>2 THEN GOSUB 37 |
20 | 20 IF S=1 THEN N=(N+2)&3:GO 26 |
21 | 21 IF (N=0) & (R=1) THEN GO 26 |
22 | 22 IF (N=2) & (L=1) THEN GO 26 |
23 | 23 IF (N=1) & (D=1) THEN GO 26 |
24 | 24 IF (N=3) & (U=1) THEN GO 26 |
25 | 25 GOSUB 37: GO 18 |
26 | 26 IF N=0 THEN DA A+1,AR(A+1)+1 |
27 | 27 IF N=1 THEN DA A,AR(A)+1 |
28 | 28 IF N=2 THEN DA A+1,AR(A+1)-1 |
29 | 29 IF N=3 THEN DA A,AR(A)-1 |
30 | 30 DA A+2,N:NEXT |
31 | 31 IF G>0 THEN G=G-1 |
32 | 32 COLOR 7,0:? @0,10;"Punkte:";P |
33 | 33 SYNC 3: IF Q=1 THEN GO 35 |
34 | 34 GO 3 |
35 | 35 DA A,10,10:N=1:GO 31 |
36 | 36 GOSUB 64:DA 64,0,4,32,0:GOTO 2 |
37 | 37 Z=RND(3):IF Z=2 THEN Z=3 |
38 | 38 N=(M+Z)&3:RETURN |
39 | 39 'check if figure f can move |
40 | 40 L=0:R=0:U=0:D=0:A=F*5 |
41 | 41 N=AR(A+2):E=100+AR(A)*21+AR(A+1) |
42 | 42 IF AR(E-21)<>49 THEN U=1 |
43 | 43 IF AR(E+21)<>49 THEN D=1 |
44 | 44 IF AR(E-1)<>49 THEN L=1 |
45 | 45 IF AR(E+1)<>49 THEN R=1 |
46 | 46 RETURN |
47 | 47 'draw figures |
48 | 48 FOR W=1 TO 4:A=W*5 |
49 | 49 J=AR(A+3):I=AR(A+4):GOSUB 91 |
50 | 50 J=AR(A+0):I=AR(A+1):COL W+1,0 |
51 | 51 DA A+3,J,I |
52 | 52 IF (G>0)&(G<>7) THEN COL 7,0 |
53 | 53 ? @1+J,4+I;%25;:NEXT |
54 | 54 J=AR(3):I=AR(4):GOS 91:COL 6,0 |
55 | 55 E=100+21*AR(0)+AR(1) |
56 | 56 IF AR(E)=42 THEN GOSUB 61 |
57 | 57 IF AR(E)=46 THEN GOSUB 60 |
58 | 58 DA E,0:? @1+AR(0),4+AR(1);%26; |
59 | 59 DA 3,AR(0),AR(1):RET |
60 | 60 NO 104: P=P+1:Q=Q-1:RET |
61 | 61 NO 120: P=P+10:G=50:RET |
62 | 62 |
63 | 63 'Draw playfield and set data |
64 | 64 DA 0,15,10,1,0,0,10,9,1,0,0 |
65 | 65 DA 10,10,9,1,0,0,10,11,1,0,0 |
66 | 66 DA 20,10,8,1,0,0:M=0 |
67 | 67 DA 100,"111111111111111111111" |
68 | 68 DA 121,"1.....*...1........*1" |
69 | 69 DA 142,"1.11.1111.1.1111.11.1" |
70 | 70 DA 163,"1.11.1111.1.1111.11.1" |
71 | 71 DA 184,"1...................1" |
72 | 72 DA 205,"1.11.1.1111111.1.11.1" |
73 | 73 DA 226,"1.*..1....1....1....1" |
74 | 74 DA 247,"1.11.1111...1111.11.1" |
75 | 75 DA 268,"1..1.1.........1.1..1" |
76 | 76 DA 289,"11.1...111 111...1*11" |
77 | 77 DA 310,"1..1.1.1 1.1.1..1" |
78 | 78 DA 331,"1.11.1.1111111.1.11.1" |
79 | 79 DA 352,"1....1.........1....1" |
80 | 80 DA 373,"1.11.1.1111111.1.11*1" |
81 | 81 DA 394,"1..1.1.1111111.1.1..1" |
82 | 82 DA 415,"11.1....*........1.11" |
83 | 83 DA 436,"11.1.1.1111111.1.1.11" |
84 | 84 DA 457,"1....1....1....1....1" |
85 | 85 DA 478,"1.1111111.1.1111111.1" |
86 | 86 DA 499,"1.*............*....1" |
87 | 87 DA 520,"111111111111111111111" |
88 | 88 FOR J=0 TO 20:FOR I=0 TO 20 |
89 | 89 GOSUB 91:NEXT :NEXT :Q=M:RETURN |
90 | 90 'draw one array element |
91 | 91 C=AR(100+21*J+I):D=0:F=6 |
92 | 92 IF C=49 THEN D=15:F=1 |
93 | 93 IF C=46 THEN D=226:F=6:M=M+1 |
94 | 94 IF C=42 THEN D=235:F=2 |
95 | 95 COLOR F,0:? @1+J,4+I;%D;:RETURN |
96 | # |
Gruß Jörg
Astrein das der BASIC-PC noch weiter entwickelt wird. Ich habe bis jetzt immer jedes Update und Bugfix draufgespielt und getestet. Auch wenn mir langsam die Ideeen ausgehen macht es immernoch Spass das Teil mal an den Fernseher anzuschließen und irgenwas vollkommen Sinnfreies zu proggen :) Dein Pacman allerdings werd ich jetzt mal öfter zocken ;) Gruß Robin T.
Bugfixes wird es bestimmt noch einige geben, neue Features wohl eher nicht. Die Dokumentation der mittlerweise knapp 100 Schlüsellwörter und der neuen Videomodi hat erstmal Vorrang. Außerdem bin ich irgendwo an einer Grenze angelangt, einen "richtigen" Computer bekommt man auf diese Weise nicht hin. Deshalb laufen meine derzeitigen Überlegungen in die etwas andere Richtung, den (oder die) AVR nur noch als Co-Prozessoren für z.B. einen HCS12 mit externen RAM zu verwenden. Gruß Jörg
Noch was zu den zwei Programmbeispielen. Wer Probleme beim Übertragen hat, ich habe leider den Kopf a la
1 | PROGRAMM 1:NAME |
vergessen mit ins Listing zu kopieren. Und beim Oszi muß Zeile 17 auskommentiert werden um wirklich was zu messen. Gruß Jörg
Hallo ! Ich bin vor ein paar Tagen auf dieses Projekt gestoßen und neu in diesem Forum. Respekt, gute Arbeit. Ist schon interessant, was man so mit den neueren Prozessoren von Atmel alles machen kann. Dies Projekt erinnert mich stark an den ZX81, falls den noch jemand kennt ;-). Ich glaube, ich werde mir diesen Mikro mal in leichter Abwandlung als SMD-Variante nachbauen. @ Jörg : Anstatt den Hauptprozessor zu wechseln, wäre es nicht auch möglich den ATmega644 durch andere AVR's, ATmega8 o.ä., in der peripheren Aus- und/oder Eingabe zu entlasten. Würde vielleicht auch einiges an Programmierung sparen. Ein Beispiel für eine VGA-Ausgabe fand ich vor ein paar Tagen hier: http://www.serasidis.gr/circuits/AVR_VGA/avr_vga.htm Gruß Günter
Hallo Jörg, ich habe die 96-Version geflasht und bin positiv über die (neuen?) Features überrascht. Besonders CTRL-C und CTRL-V sind sehr hilfreich. Auch läuft es bisher sehr stabil - trotz umfangreicher Änderungen. Dein PACMAN ist anschliessend immer wieder ein krönender Abschluß.... Viele Grüsse Otto PS: Änderst Du zur Zeit die Beschreibung auf Deiner Homepage?
Hallo, die Doku überarbeite ich gerade, kann aber noch etwas dauern da ich sowohl die Organisation des Bildspeichers in den 8 Videomodi als auch das API möglichst vollständig mit dokumentieren will. Das mit dem Verteilen auf mehrere Controller habe ich auch schon angedacht, aber dann steht wieder die Frage nach einem schnellen Bus, der möglichst wenige Ressourcen bindet. Der S12 hat halt die Vorteile, gerade dazu einfallen würde mir: 1. Ich kenne mich recht gut damit aus 2. Kann Programme aus dem RAM ausführen, auch aus dem externen 3. Lässt sich recht bequem in Assembler programmieren 4. Schnelle Hardware-Division Aber mal sehen, was als nächstes wird. LCD mit 320x240 habe ich bereits daliegen und auch schon die CFL durch 6 LED ersetzt... Gruß Jörg
Hallo Jörg, bestände die Möglichkeit, dass Du bei der Doku auf Deiner HP das aktualisierst, was Du schon fertig hast? Mein Interesse betrifft speziell die Beschreibung des Array, da mir hier einige Punkte nicht ganz klar sind: 1. "Teilen" sich Variablen und Array immer noch den selben Speicher? 2. Welche Adressen sind zulässig (0-1024 und 1024 bis 2047)? 3. Ist der Bytebereich physikalisch der selbe Speicher wie der Wortbereich? 4. Zeigt die Array-Ansicht des Monitors das gesamte Array (mit blättern)? Weiterhin gibt in der Aufteilung scheinbar einen Unterschied zur Mega32-Version (nicht kompatibel). Wo liegt dieser? Das Schreibzugriffe nur noch über DATA erfolgen dürfen, habe ich berücksichtigt. Gibt es Adressen des internen EEPROM, die nicht beschrieben werden können? Viele Grüsse Otto
Ich habe ein Board, wo 2x Atmega32 und 1x Atmega8 drauf ist mit Chinchbuchse(Video) und Tastatursteckbuchse-klein. Alles kann man frei verdrahten wie man möchte. Wie könnte man hier die Arbeit aufteilen für obigen Basiccomputer? mfg
weiter... 1x Sd-Karte ist noch vorhanden, 1x serielle Schnittstelle mit MAX. Die Atmega kann man austauschen. mfg
1. Doku ist in Arbeit aber noch eine große Baustelle und es fehlt halt momentan ein bisschen an der Zeit. Vielleicht am WE, aber versprechen will ich nichts. - Array und Variablen belegen getrennten Speicher, auch wenn das nicht unbedingt die bessere Lösung ist. - Gültige Adressen sind 0-767 (Bytes) und 1024-1407 (Words), der Speicher ist derselbe - In der Array-Ansicht kann man nach unten blättern, allerdings wird nur im Byte-bereich angezeigt 2. Aufteilen geht nicht so einfach, da dafür die Software in großen Teilen wahrscheinlich mehr oder weniger komplett neu geschrieben werden müsste. Ein Mega644 reicht aus, den MAX kann man mit benutzen da in der aktuellen Version das Verhalten des Soft-UART umschaltbar ist. SD-Karte geht nicht, das Dateisystem ist an die Atmel Dataflash angepasst. Man könnte das durchaus auf eine SD-Karte abbilden, aber dann würden alle gleich wieder nach FAT schreien und so tu ich mir das lieber nicht an... Gruß Jörg
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.