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
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)
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
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
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....
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.
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
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 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
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
@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, 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
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
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.
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
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
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
@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.
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
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 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
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
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
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
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
... 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 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
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
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.htmhttp://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
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
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
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
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
Hallo Jörg,
vielen Dank für Deine Antwort - so hatte ich es mir auch zurechtgereimt,
kann aber immer noch nicht erkennen, weshalb das "alte" Programm nicht
auf der 644-Version lief.
Nachdem ich die "Datas" und korrespondierend auch "icomm" in den
Byte-Bereich gelegt hatte, lief das meißte aber.
Mittlerweile funktioniert zum Glück alles und ich freue mich über die
neuen grafischen Möglichkeiten und die vervierfachung des Speichers,
welche es mir ermöglicht, alle Anzeigen zu realisieren......
Viele Grüsse
Otto
PS:
Die Programme haben eine unterschiedliche Zeilenzahl
(1=95, 2=94, 3=92, 4=93)
EPOKE kann nicht mit EP abgekürzt werden
BORDER ist z. Zt. nicht in der Dokumentation
Guten Abend Herr Wolfram,
zu Ihrem kleinen Mega644 Selbstbau- Computer habe ich folgende Fragen:
1. Auf Ihrer HP steht, das nur 95 Programmzeilen erlaubt sind. Ist der
Programmcode auf 95 Zeilen begrennzt? Falls ja, kann man nur
Miniprogramme erstellen...
2. Kann man ggf. den Speicher für den Programmcode vergrößern?
3. Gibt es bereits ein Softwarearchiv für Ihrem Computer? Mir ist die
Basic (Programmier-)Sprache bekannt, allerdings wüsste ich gerne, was
andere Besitzer des Computers bereits in den kleinen Speicher (?) hinein
gepresst haben...
4. Ist im Shop
(https://www.it-wns.de/themes/kategorie/detail.php?artikelid=134&source=2)
auch ein passendes Gehäuse vorhanden?
5. Was benötige ich noch, wenn man den im oben genannten Shop gekauften
Bausatz fertig gelötet hat, um Ihr OS auf dem Computer zu bringen
(Programmerkabel, Softwareumgebung, Hostbetriebssystem) ?
Ich denke, das reicht für das erste...
Vielen dank für Ihre Antworten in voraus, Ronny
@Otto
Freut mich, dass es soweit funktioniert. Allerdings haben bei mir alle
Programme 95 Zeilen.
EP mache ich wieder mit rein, kein Problem und die Doku ist auch fast
fertig wobei ich Sachen wie das API erstmal draussen vor gelassen habe)
@Ronny
1.+2. Die Anzahl der Zeilen ist durch das verfügbare RAM begrenzt. Für
eine RAM-Erweiterung müsste wahrscheinlich sehr viel am Konzept geändert
werden. Der ATMega 128 geht leider nicht, auch wenn man ihn auf 20MHz
übertakten würde. Aber mittels GOSUB P,N kann man den Code auch auf
mehrere Programme verteilen.
3. Gibt es (leider) nicht, ich hatte sowas schonmal angedacht aber
aufgrund des zeitlichen Auwandes zur Pflege des Archives schnell wieder
verworfen.
4. Wahrscheinlich nicht. Allerdings habe ich auch nicht direkt etwas
damit zu tun. Einfach mal nachfragen...
5. Ein Kabel von 9-polig DIN auf Scart, für die Hexfiles einen
funktionierenden Programmer für 10-poligem ISP-Anschluß und ein
Steckernetzteil mit ca. 7-9V. Für den Programmaustausch mit dem PC eine
serielle Schnittstelle und ein Terminalprogramm, Betriebssystem ist
dafür weitestgehend egal.
Gruß Jörg
> Autor: Joerg Wolfram> 1.+2. Die Anzahl der Zeilen ist durch das verfügbare RAM begrenzt. Für> eine RAM-Erweiterung müsste wahrscheinlich sehr viel am Konzept geändert> werden. Der ATMega 128 geht leider nicht, auch wenn man ihn auf 20MHz> übertakten würde. Aber mittels GOSUB P,N kann man den Code auch auf> mehrere Programme verteilen.
ok, das müsste ich mal mit dem atmel emulator testen... eines der guten
alten textadventures, auf dem pc portiert, bracht wohl ein paar
codezeilen mehr...
> 3. Gibt es (leider) nicht, ich hatte sowas schonmal angedacht aber> aufgrund des zeitlichen Auwandes zur Pflege des Archives schnell wieder> verworfen.
du hast aber ein paar codebeispiele online, die beim bauen eigener
programme helfen...
> 4. Wahrscheinlich nicht. Allerdings habe ich auch nicht direkt etwas> damit zu tun. Einfach mal nachfragen...
schon erledigt. antwort sollte auch bald da sein...
> 5. Ein Kabel von 9-polig DIN auf Scart,
ein serielles kabel nach scart zum programmen...?
> für die Hexfiles einen> funktionierenden Programmer für 10-poligem ISP-Anschluß und ein> Steckernetzteil mit ca. 7-9V. Für den Programmaustausch mit dem PC eine> serielle Schnittstelle und ein Terminalprogramm, Betriebssystem ist> dafür weitestgehend egal.
so ein programmer kostet mir 20-40€.. mal schauen, welcher am besten
geeignet ist. ab betriebssystemen steht mir eigendlich alles, was rang
und namen hat, zur verfügung... also, win + linux + mac os + diverse
opensource betriebssysteme (tyndur, deskwork, reactos usw...)
Hallo Ronny,
das Kabel von 9-polig D-Sub auf Scart ist für den Fernseher-Anschluß und
hat nix mit dem Programmieren zu tun. Der von Dir verlinkte Programmer
sollte aber funktionieren.
Code-Beispiele habe ich auf der Homepage, die sind aber auch in der Doku
mit drin. So einen Step-by-step Kurs hatte ich schonmal angefangen, aber
erstmal auf Eis gelegt. Für ein Text-Adventure wäre es vielleicht
sinnvoller, die Daten zu den einzelnen Orten in einer extra Datei auf
dem Dataflash zu halten und nur im BASIC auszuwerten.
Gruß Jörg
So, lange genug hat es ja gedauert, aber jetzt ist die Version 1.00
endlich fertig. Die Dokumentation ist aber leider noch nicht
vollständig, die API-Funktionen sind noch nicht vollständig beschrieben.
Neue Features wird es wohl nicht mehr geben, dazu ist einfach der Flash
zu voll.
Was gibt es neues?
Zuerst einmal, mit 4 (bei RGB reichen auch 3) Widerständen lässt sich
der Computer auf 16 Farben "aufrüsten". Dafür ist der Autostart-Jumper
einer "intelligenteren" Lösung gewichen.
Dann noch 8 Videomodi, davon 2 mit benutzerdefinierten Zeichen. Bei
Videomodus 1 kann für jeweils 8x8 Pixel Vorder- und Hintergrundfarbe
festgelegt werden. Unterstützung für Binärprogramme (bis 3KBytes), diese
können auch Routinen enthalten, die vom BASIC aufrufbar sind.
Dateitransfer vom Hauptmenü aus über X-Modem, REPEAT-UNTIL Schleifen,
Lautstärkesteuerung...
Die Doku habe ich auch erweitert, allerdings sind die Beispielbilder aus
der BASIC-Referenz rausgeflogen. Dafür wird es wahrscheinlich demnächst
eine Art kleinen "Programmierkurs" geben.
Viel Spaß damit, wer Fehler findet, bitte melden.
Gruß Jörg
Hallo Jörg,
vielen Dank für die neue Version - leider habe ich es jetzt erst
gesehen.
Auf jeden Fall werde ich heute mit Spannung die Dokumentation lesen.
Aber so weis ich auf jeden Fall, was ich am nächsten Wochenende tue....
Viele Grüsse
Otto
Ein Update nimmt schon langsam Gestalt an, auch werde ich entgegen
meiner Ankündigung noch neue Features einbauen. Leider ist das Feedback
derzeit praktisch Null, ein paar Bugfixes werden aber auch dabei sein.
Was mich in letzter Zeit geärgert hat, ist die starre Abhängigkeit von
den Zeilennummern. Jedesmal wenn man eine Zeile einfügt oder löscht
passen die Ganzen GOTO und GOSUB Werte zur Hälfte nicht mehr. Die
nächste Version enthält dafür zwei neue Befehle VSET und ASET, mit denen
die aktuelle Zeilennummer in eine Variable oder ein Array-Element
geschrieben werden kann. Der Programmtext:
1
ASET 300: GOTO AR(300)
wird damit in jeder beliebigen Zeile eine Endlosschleife erzeugen.
Das API wird auch noch ein bisschen erweitert und die
Konfigurationsseite werde ich etwas aufräumen (Auswahl per
Cursor-Tasten).
Veröffentlichungstermin wird am WE oder eher nächste Woche sein, je nach
dem, was mir noch einfällt...
Gruß Jörg
Insgesamt ein total tolles Projekt ;)
Werd mir mal den Bausatz zum Sommerurlaub bestellen g
Vielleicht bekomm ich ja meine Kinder dazu auch ein wenig zu spielen :)
Gruß Anselm
Hallo,
es gibt wieder eine "Zwischenversion" als Hexfile zum Testen.
1. Den Ansatz mit VSET und ASET habe ich wieder fallen lassen, ganz
einfach deswegen, weil mir eine bessere Idee gekommen ist,
Sytemvariablen!
Diese bestehen aus der Tilde (~) und einem Buchstaben, und können wie
Konstanten benutzt werden.
~P ist das aktuelle Programm (1-8)
~L ist die aktuell abgearbeitete Programmzeile (1-95)
~S gibt die gerade aktive Bildschirmzeile zurück
~V gibt an, aus wieviel Bildschirmzeilen ein Halbbild besteht (263/313)
~X Anzahl der Pixel in horizontaler Orientierung
~Y Anzahl der Pixel in Vertikaler Orientierung
~X und ~Y hängen dabei vom gerade aktiven Videomode ab.
2. EPEEK(N) liefert ab N=3072 die Programmbytes für die Programme 1-8
wobei gilt: N=3072*Programmnummer(1..8), ab N=6144 stehen z.B. 12 bytes
für den Programm-Namen von Programm 2
3. Nachdem eine Realisierung im BASIC einfach zu umständlich und zu
kompliziert , die Funktionalität aber notwendig war, gibt es einen neuen
Befehl: SCALE
1
SCALE Variable,Y1,Y2,X1,X,X2
Die angegebene Variable anthält nach dem Aufruf den Wert Y, der relativ
gesehen so zwischen Y1 und Y2 liegt wie X zwischen X1 und X2. Damit das
Ergebnis hinreichend genau ist, wird dabei intern teilweise mit 32 Bit
gerechnet. Um z.B. einen 10 Bit ADC-Wert in Prozent-Angaben zwischen
-100% und +100% umzurechen ist nur folgendes notwendig:
1
10 A=ADC(0);
2
11 SCALE R,-100,100,0,A,1023
3
12 ? R
4. Ich habe die Config-Seite umgebaut, da die Bedienung über die
Funktionstasten einfach zu unübersichtlich geworden ist und ein Abbruch
ohne Reboot nicht mehr möglich war. Jetzt geht es so:
- Mit den Cursor Tasten (nach unten/nach oben) wird die zu ändernde
Einstellung ausgewählt. Dabei ist der aktuelle Wert invers dargestellt.
- ESC bricht ab, ohne die Konfiguration zu speichern
- Mit F1 wird der Wert geändert
- mit F2 werden die aktullen Einstellungen gespeichert und ein Reboot
ausgelöst.
- Mit F4 kann das Sytem, wie gehabt, geclont werden.
Viel Spaß damit,
Jörg
Endlich ist mit der Version 1.02 auch die API-Dokumentation der
mittlerweile etwas über 100 Funktionen abgeschlossen. Ein paar Bugfixes
sind auch noch dabei:
- GOSUB-RETURN innerhalb von FOR-NEXT Schleifen führte zu
Fehlermeldungen
- Nach dem Update via Bootloader funktionierte die Konfigurationsseite
nicht mehr richtig
Die LaTex und XFig Dateien für die Dokumentation werde ich auch über
Berlios bereitstellen, Homepage wird nachher noch aktualisiert.
Gruß Jörg
@Bernd
Das geht leider nicht so einfach, denn die Zeilennummern existieren ja
im Programm selbst gar nicht. Da jede Zeile, gleich welchem Inhalts,
immer 32 Bytes groß ist, wird bei einem GOTO 5 die Abarbeitung einfach
bei Adresse 128 weitergeführt.
Gruß Jörg
Im API bis Version 1.02 gibt es einen Fehler, api_dataptr lieferte
leider eine falsche Adresse zurück. Außerdem wird es noch zwei
zusätzliche API-Routinen geben die CCHAR im Basic entsprechen. Momentan
gibt es nur das aktuelle BIN File, welches via XMODEM über den
Bootloader geflasht werden kann.
Jörg
Die aktuelle Version 1.03 muß letztendlich doch geflasht werden, da es
auch im oberen Speicherbereich eine Änderung gab.
- Bugfix in api_dataptr (siehe letzten post von mir)
- API-Funktionen um BASIC-Routinen erweitert
- Oszi-Beispielprogramm aktualisiert
Programme, deren Namen mit einem Unterstrich beginnt, werden beim
Speichern
nicht mehr tokenisiert und können auch nicht mehr gestartet werden.
Damit kann man den Editor (eingeschränkt) auch als Texteditor verwenden.
Jörg
Hi Joerg,
find ich gut das du immernoch so engagiert an dem BASIC-PC arbeitest.
Ich flashe nach wie vor jede neue Version darauf und es macht auch
immernoch Spaß damit zu proggen ;)
Gruß
Robin T.
Hallo Jörg,
seit ungefähr einem Jahr verfolge ich die Entwicklung des Chipbasic
Computers, Hut ab vor dem was Du da auf die Beine gestellt hast.
Schon lange war ich auf der Suche nach so etwas womit man mal schnell
was steuern oder regeln kann. Dein Projekt zielt wahrscheinlich nicht
primär auf MSR, was die zahlreichen Möglichkeiten der
Videoprogrammierung erklärt.
Das ist jedoch nicht weiter schlimm, man kann sich eben mit den
vorhandenen I/O Befehlen helfen. Nun zu meiner Frage:
Ich habe mir den Rechner auf Lochraster aufgebaut und um einige I2C
Bausteine für spezielle Aufgaben ergänzt. Die generische I2C Rautine
klappt auch soweit, ich habe jedoch bei über Kabel angeschlossenen
Bausteinen wie dem von Dir mit der temp() funktion supporteten LM 75 das
Problem das dieser aufgrund von Störpegeln bzw. der hohen Taktfrequenz
von mindestens 100khz auf dem Bus bei einer schon relativ kurzen
Kabellänge von unter einem Meter austeigt und einen I2C Error bringt
oder das System sich aufhängt.
Gibt es eine Möglichkeit vielleicht durch einen Poke in eine
Speicherstelle die Taktfrequenz auf dem Bus rapide herabzusetzen,
vielleicht so auf 1khz um eine höhere Kabellänge zu den Sensoren zu
realisieren?
Roger
erstmal btt:
der chipbasic2 ist garnicht mal so uninterissant. man braucht, zum
bausatz. noch ein programmerkabel für den atmel. ich hab mich bishher
eher nur für den propeller mcu interissiert. eigendlich komme ich aber
eher aus der programmierer szene. zuletzt hatte ich, bevor ich mir ein
hive-computer gebaut habe, vor 10 jahren mal herum gelötet... nun suche
ich seit monaten eigendlich nach kleinen elektronik projekten, wo ich
wieder etwas in die technik herein finde.
zum chipbasic2: der computer hat einen einfachen aufbau, wie ich ihm vom
c=64 und anderen homecomputern kenne. was mich an den pc stört, ist
einzig und allein die begrenzung auf 95 zeilen und dem damit
verbundenen, sehr kleinen programmspeicher. es gibt zwar ein eeprom mit
8 plätzen, dieser ist aber schnell belegt, wenn ich darauf ein paar
zeilen basic tippe. ich denke da an das eine oder andere textadventure
(i love him), oder einen kleinen sidescroller. 95 zeilen hören sich viel
an, aber wenn man mehr als 1 level bauen will, dann wirds da schnell
eng... von daher...:
ich hab mit den "computer", den hansi hier vorstellte einmal angesehen.
an sich ist der computer eine gute creation. im shop gibt es aber keine
platinen. diese muss man sich selbst anfertigen. man kann das ganze auf
lochraster nachbauen, oder die platinen selbst fertigen, bzw. fertigen
lassen. letzteres jedoch nicht beim betreiber der homepage...
ich persönlich habe ein hive ( mehr dazu hier:
Beitrag "Projekt: HIVE - retro style computer" oder auch auf
http://www.hive-project.de ). ich bin auch im forum team (nickname:
borgkönig) aktiv.
fazit: der chipbasic ist eigendlich gut durchdacht. es gibt, in meinem
augen, nur eine schwachstelle: man kann nur 95 zeilen/ programm
eingeben. der basic interpreter sollte soviele zeilen schlucken, wie
realer ram verfügbar ist...
@hobby-coder:
Dafür kostet das Hive auch gleich um einiges mehr.
Minimalstbeschaltung des AVR-ChipBasic lässt sich mit Bauteilen für ~5
Euro machen, zieh einen guten Euro ab wenn du einen PC mit USB als 5
Volt Steckdose missbrauchst.
Und genau darum geht es hierbei, mit geringsten Mitteln einen voll
funktionsfähigen Computer bauen welcher am Fernseher angeschlossen
werden kann und eine Tastatur besitzt.
Und ich schätze mal wenn man ein paar Chinesen für dieses Teil
begeistern könnte, könnte man den ChipBasic in Vollausstattung, fertig
gelötet im Gehäuse, für maximal 10 Euro kaufen.
Mein Beetle ist irgendwie das Zwischending vom ChipBasic und dem Hive.
Durch das modulare Konzept vom Beetle kann man das System noch massiv
erweitern. Die Zeilengrenze vom ChipBasic gibt es bei mir auch nicht.
Erst einmal stehen 64 kB RAM zur Verfügung und durch den Chain-Befehl
sind theoretisch unendlich große Programme möglich.
Erweiterungsmodule und Programme werden laufend entwickelt. Auch
Lehrgänge wird es immer weitere geben. Habe gerade erst mit der
Entwicklung eines weiteren größeren Programmes und einer
Hardwareerweiterung begonnen. Das Preview werde ich wohl Anfang nächster
Woche auf meiner Seite (www.DieProjektseite.de) vorstellen können.
@Roger
die demnächst kommende Version 1.10 wird (zumindest Byteweise) lesenden
und schreibenden Zugriff auf alle I/O Register haben. Mittels Datenblatt
lassen sich dann leicht andere Werte für TWBR und TWSR einstellen.
@hobby-coder
etwas hast Du da durcheinandergewürfelt. Die 8 Programme sind alle im
internen Flash, internes und externes EEPROM kann nur noch zur
Speicherung von Daten benutzt werden. Zusätzlich gibt es ein externes
Dateisystem auf Dataflash. Die Dateien können bis zu 32K groß werden und
seitenweise in das Array eingelesen werden. Für ein Textadventure müsste
man nur die Engine in BASIC schreiben, die die Daten blockweise in das
Array nachlädt.
Die nächste Version wird auch eine Änderung enthalten, die eventuell
bestehende Programme betreffen kann. Und zwar habe ich GOSUB mit ein und
zwei Parametern wieder in GOSUB und CALL getrennt. Dafür können dann bis
zu 5 Parameter übergeben werden, mit RETURN N auch ein Rückgabewert. Für
reine BADIC-Programme ist das nicht unbedingt notwendig, aber das
Schreiben von externen Assembler-Routinen wird um einiges leichter.
Jörg
@Joerg:
Wie führst du AVR Assembler aus?
Flasht du jedes mal den AVR neu?
Oder kann Chipbasic jetzt auch mit dem AVR-FPGA umgehen und doch nativen
AVR Code ausm Arbeitsspeicher ausführen?
Die Programme werden in das Flash geschrieben, z.B. beim Laden vom
Dataflash-Modul. BASIC-Programme werden beim Speichern auch in Tokencode
übersetzt und dann in das Flash geschrieben. Das mit dem Asseblercode
stimmt nicht ganz, der muß natürlich vorher auf einem PC in
Maschinencode übersetzt werden...
Um das Programmieren zu erleichtern, gibt es ein API mit über 100
Funktionen, die in eigene Programme eingebunden werden können.
Jörg
Hi
ich hab mir den Bausatz organisiert, aufgebaut und ausprobiert.
Beim PONG Startet das Spiel nicht
und eine Fehlermeldung RETURN ohne GOSUB in Zeile 49 erscheint.
Hat jemand eine Idee?
Chipbasic V1.0 ist in Verwendung
Grüße
PS Jörg: Wahnsinns Projekt !
So, ich hoffe, dass nicht allzuviele neue Fehler reingekommen sind...
Folgendes hat sich geändert:
- Aufspaltung von GOSUB in GOSUB und CALL
- bis zu 5 Parameter könen übergeben werden ~(1)...~(5)
- Anzahl der übergebenen Parameter mit ~N
- RETURN kann einen Rückgabewert erhalten ~R
Die Funktionsparameter und der Rückgabewert existieren nur einmal, das
ist insbesondere bei verschachtelten GOSUB-Aufrufen zu beachten.
- IN und OUT im Adressbereich $4xx greifen nun direkt auf die I/O
Register des Mega644 zu
Und schließlich noch ein paar Bugfixes und Erweiterungen im API, um z.B.
aus nativen AVR-Programmen auf die Funktionsparameter zuzugreifen.
Jörg
Hallo zusammen,
eigentlich möchte ich Jörg hier nur meine Anerkennung aussprechen. Dein
Projekt Chipbasic ist schon klasse! Ich habe meine Erfahrung und
Begeisterung
mit dem Chipbasic2 auf meiner Homepage niedergeschrieben.
Schaut doch mal rein http://www.dh2faa.de dann Projekte und aus der
Liste
den Eintrag 15 anklicken.
Eine kleine frage hätte ich noch: Welche EEPromtypen werden unterstützt?
Danke und Gruß
Heiko
@ Joerg Wolfram: Mich stört am gesammten Projekt eigendlich nur die 95
Zeilen Begrenzung. Im großem ganzem ist Dein Projekt einfach klasse. Ein
OS + IDE + Keyboard + Grafik in ein MCU zu packen, ist eine große
Leistung.
Mich würde mal interissieren, wie man das Problem, das man nur 95 Zeilen
pro "Seite" hat, umgehen kann ohne externe Dateien verwenden zu
müssen... Zu C=64 Zeiten hatte man ja auch oftmals sein Programm in eine
Datei gesteckt...
Zum Dataflash Modul: Gibt es dafür ein Bausatz? Wenn nein, wie hoch ist
der Aufwand, einen solches auf einer Lochraster Platine nach zu bauen?
Und, welche Bauteile braucht man dafür, neben dem Flash Chip?
@ jörg wolfram: vielen Dank für die Implementation des direkten
Zugriffs, ich habe es gestern ausprobiert und die Bitrate reduziert, man
kann so die mögliche Leitungslänge der Sensoren erheblich steigern.
Gruss Roger
@Heiko
EEPROMS gehen eigentlich alle 24xx mit zwei Adressbytes, also 24C32 bis
24C512.
Beim 24C16 gibt es verschiedene Varianten, manche adressieren mit 3 Bits
im
ersten Byte und 8 Bits im zweiten, diese funktionieren nicht.
@Roger
freut mich, dass es so geklappt hat.
@Ronny
Die 95 Zeilen sind systembedingt und lassen sich auch nicht so schnell
erweitern. Die wesentlichste Einschränkung kommt vom Fullscreen-Editor
und dem verfügbaren RAM.
Und natürlich aus dem Umstand, dass jede Zeile genau 32Bytes groß ist,
egal ob leer oder vollgeschrieben. An diesem system werde ich auch
nichts mehr ändern, zumindest bei diesem Projekt.
Das DataFlash-Modul ist sowohl in der Doku als auch auf meiner Webseite
beschrieben, neben dem Flash-Chip braucht es nur noch einen 3K3
Widerstand, einen 10µF keramischen Kondensator und eine LED mit ca. 1,8V
Flußspannung.
Jörg
Joerg Wolfram schrieb:
> @Ronny> Die 95 Zeilen sind systembedingt und lassen sich auch nicht so schnell> erweitern. Die wesentlichste Einschränkung kommt vom Fullscreen-Editor> und dem verfügbaren RAM.
Kann man das Ram Problem umgehen, wenn man größere EEProm's verwendet?
Natürlich vorausgesetzt, das man kompartible EEProms verwendet...
> Und natürlich aus dem Umstand, dass jede Zeile genau 32Bytes groß ist,> egal ob leer oder vollgeschrieben. An diesem system werde ich auch> nichts mehr ändern, zumindest bei diesem Projekt.
Das klingt so, als ob Du an einem Nachfolger bastelst...?!
>> Das DataFlash-Modul ist sowohl in der Doku als auch auf meiner Webseite> beschrieben, neben dem Flash-Chip braucht es nur noch einen 3K3> Widerstand, einen 10µF keramischen Kondensator und eine LED mit ca. 1,8V> Flußspannung.>> Jörg
Ich denke mal, dass man das auf ein Stück Lochrasterplatine nachbauen
kann... Ich probiere das einfach mal aus...
BTW...: Sind die Sourcen zu den ChipBasic Computern (Atmega 8 - Atmega
644, bzw. ChipBasic1 - ChipBasic2) Open Source...?
Ronny
@Ronny
Das RAM Problem kann man so einfach nicht umgehen, außer mit mehr (z.B.
externem) RAM. EEPROM ist definitiv zu langsam, eine Zeile einfügen oder
löschen würde dann ein paar Sekunden dauern. Es werden ja keine
Zeilennummern mit abgespeichert, sondern die Adresse einer Zeile im
Speicher lässt sich einfach ausrechnen:
Basis + (Zeilennummer-1) *32
Das ist zwar etwas Speicherplatzverschwendung, hat aber gerade aufgrund
des deterministischen Zeitverhaltens auch einige Vorteile.
Es wäre auch kein Problem, Programme bis zu 255 Zeilen (bei kleinen
Änderungen bis zu 32767) aus einem externen EEPROM abzuarbeiten, nur
editieren könnte man sie nicht mehr. Dazu könnte man (in ASM) einen
kleinen Zeilenlader in eins der 8 Programme schreiben, der die gewählte
Zeile aus dem externen Speicher in den Buffer lädt und mit api_basrun
ausführen lässt.
Zu Nachfolgeprojekten gibt es derzeit nur ein paar Konzeptionen, aber
nichts konkretes.
Deine letzte Frage verstehe ich nicht ganz, bei allen Projekten steht
sowohl auf meiner Homepage als auch in den Dateiarchiven (die auch den
Source-Code enthalten), dass die Projekte unter der GPL stehen.
Jörg
Die gesamten
O.k. Danke für Deine Infos. Wie sehen Deine Konzepte zur Zeit aus...?
Letzteres hat sich von selsbt erledigt. Ich habe die Hinweise auf die
GPL Linzens übersehen...
@Joerg:
Wie sähe es eigentlich mit einer AVR32 Portierung aus?
Die Dinger werden ja auch immer billiger und einen einsamen SMD Chip
löten sollte selbst der größte Lötkolbenlegasteniker hinbekommen.
Das Problem ist halt, so einen AVR32 baut man nicht schnell mal auf
Lochraster oder nem Steckbrett auf. Und damit steigt meiner Meinung nach
ganz einfach die Hemmschwelle, so etwas einfach mal aus Spaß
nachzubauen.
Auch denke ich, dass in dem Projekt noch wesentlich mehr Möglichkeiten
stecken.
Konkret arbeite ich derzeit ein einer BCD-Arithmetik-Bibliothek, die
einfach auf einen der 8 Programmplätze geladen werden kann. Über CALL
mit den entsprechenden Parametern kann man dann die einzelnen Funktionen
abrufen. Ein-/Ausgabe sowie die Grundrechenarten sind schon fertig,
müssen aber noch optimiert werden.
Nachdem das Operieren mit Binärzahlen bei der Ausgabe einfach "seltsame"
Ergebnisse ausgegeben hatte, bin ich jetzt bei BCD Festkomma mit 8
Vorkomma- und 8 Nachkommastellen angelangt. Aber das muß nicht der
Weisheit letzter Schluß sein...
In punkto Hardware gibt es ein paar Ideen, aber nichts konkretes.
Jörg
Der Mega1284p wäre schon interessant, wenn es ihn denn zu kaufen gäbe.
Besonders, da man so die vorhandene Hardware weiternutzen kann.
Allerdings ist das dann wieder eine neue "Baustelle", die gepflegt sein
will. Und dazu habe ich momentan weder Zeit noch Lust.
Da der AVR halt nur Code aus dem Flash ausführen kann, sind die
Möglichkeiten, einen "richtigen" Computer damit zu bauen, eher begrenzt.
Und bevor ich dasselbe Konzept auf einen anderen Controller portiere,
lasse ich mir lieber was neues einfallen.
Jörg
Gibt ja immer noch diesen AVR FPGA, wenn ich mich recht entsinne sogar
als PLCC, also Rasterbrett tauglich.
Ansonsten könnte man sich auch überlegen das ganze auf Z80 zu portieren,
die Dinger wirds wohl auch noch in 9001 Jahren geben...
Meine Überlegungen würden dann eher Richtung S12X gehen. Den gibts bis
zu 32K RAM und 40MHz Bustakt, lässt sich auch schön in ASM
programmieren. Die Videoausgabe könnte dann der XGATE übernehmen.
Jörg
Hallo, mal ein kurzes Update.
Für die nächste Version habe ich vorgesehen, den bisher eingebauten
Videomodus 7 wieder zu entfernen. Dafür wird es einen "Mechanismus"
geben, mit dem eigene Videotreiber auf Programmplatz 7 installiert
werden können. Die müssen nicht unbedingt Video ausgeben, sondern können
z.B. auch ein Text-LCD am Parallelport ansteuern.
Die erste BCD-Bibliothek ist in Grundzügen fertig, aber noch zu langsam
und zu unflexibel. So komme ich auf etwa 8ms für eine Division mit 6
Vorkomma- und 6 Nachkommastellen, eine Multiplikation braucht ca. 3ms.
Momentan experimentiere ich mit einer flexiblen
Binär-Festkommaarithmetik mit 7...247 Bit, mal sehen was dabei
herauskommt...
Auch ein etwaiges Nachfolgeprojekt nimmt langsam konkrete Züge an. Ein
Mega8515 plus ein kleines CPLD und 64K RAM liefern 320x240 Vollgrafik in
s/w an wahlweise VGA/TV/LCD (umschaltbar).
Schnittstellen sind PS2-Tastatur, SPI (Dataflash, Datenaustausch) und
ein
paralleler I/O Bus. Auf dem Controller selbst läuft ein minimales BS,
die Anwenderprogramme werden von einer virtuellen Maschine aus dem
RAM ausgeführt.
Jörg
Bernd schrieb:
> Ui!> Wenn du es schaffst einen Z80 als VM zu bauen könnte man damit Sinclair> BASIC laufen lassen. :)
So einen hab ich hier auch noch :)
Leider ist die Tastatur kaputt :(
Eine Z80 Emulation hatte ich auch schon mit ins Auge gefasst, allerdings
ist ein realitätsgetreues Timing mit meinem Konzept nicht möglich.
Außerdem lässt sich die Geschwindigkeit der VM steigern, wenn der AVR
bestimmte Operationen nativ bewältigen kann (z.B. Multiplikationen). Und
kompatibel zu irgendetwas muss sie meiner Meinung auch nicht sein.
Jörg
Zumindest in der letzten Version (1.10) ist ein Bug bei ACOPY drin, der
das System abstürzen lassen kann. Update kommt so bald als möglich,
zusätzlich werde ich noch Shift-Operationen für schnelle
Multiplikationen/Divisionen mit Potenzen von 2 einbauen.
Jörg
Die neue Version gibt es vorerst nur als Hexfile, sobald die Doku fertig
ist auch wieder ein komplettes Paket.
Die zusätzlichen Befehle sind:
LSHIFT variable,anzahl
und
ASHIFT variable,anzahl
L steht für logisch und A für arithmetisch, die Anzahl ist positiv für
linksschieben und negativ für rechtsschieben.
LFIND variable,code
dieser Befehl ist für das Auffinden von Assemblerbibliotheken gedacht.
Jede Bibliothek hat eine (hoffentlich) eindeutige Kennung, über die sie
gesucht werden kann. In der Variable steht dann der erste gefundene
Programmspeicherplatz oder 0 für nicht gefunden.
Die erste Bibliothek ist auch in einem fortgeschittenen Stadium, auch
die Geschwindigkeit ist recht akzeptabel geworden. Bis zum Release wird
es aber noch etwas dauern.
Jörg
Hier schon mal ein "Ausblick" auf die kommende Version 1.22 und die
Festkomma-Bibliothek. Letztere kann zur Laufzeit auf 2-32 Vorkomma- und
0-30 Nachkommastellen konfiguriert werden. Realisiert sind
Eingabe/Ausgabe über Text, Import/Export von 16Bit Integer-Werten,
Addition, Subtraktion, Multiplikation und Division, Multiplikation und
Division mit 2, Absolutbetrag etc. In der Testphase ist noch eine
Scripting-Engine, mit der sich relativ einfach weitere mathematische
Funktionen realisieren lassen. Die Beispielbilder sind aber noch "Zu
Fuß" mittels CALL Befehle aus dem BASIC heraus berechnet, allerdings war
die Bildausgabe währen der Berechnungen abgeschaltet.
Release-Termin für das Paket wird wohl frühestens so Mitte Dezember
sein, da die Dokumentation auch noch überarbeitet und erweitert werden
muß.
Jörg
Joerg Wolfram:
"Auch ein etwaiges Nachfolgeprojekt nimmt langsam konkrete Züge an. Ein
Mega8515 plus ein kleines CPLD und 64K RAM liefern 320x240 Vollgrafik in
s/w an wahlweise VGA/TV/LCD (umschaltbar).
Schnittstellen sind PS2-Tastatur, SPI (Dataflash, Datenaustausch) und
ein paralleler I/O Bus. "
Wäre da nichtr ein Board per 'ATxmega128A1' und ggf. Verwendung einer
Adapterplatine wie
http://shop.embedded-projects.net/product_info.php/info/p173_ATxmega128A1-TQFP-100-auf-einer-DIP-Adapterplatine.html
sinnvoller ?
Der könnte per 512k SRAM und DMA locker auch eine 320*240 8 Bit
Farbgrafik selbst generieren (wohl nicht VGA) und hat schon 4* I2C
onboard ?!
Auch sind die 32 MHz für obige Grafikfeatures natürlich auch sinnvoll.
den ATXMEGA hatte ich eigentlich eine Zeit lang als Nachfolger im
Visier, das Ganze ist aber wieder vom Tisch und auch mein Demoboard habe
ich wieder verkauft. ARM lässt sich meiner Meinung nach nicht besonders
schön in ASM programmieren (hatte mal mit nem Cortex M3 angefangen) und
sind deswegen auch keine Alternative. Gut, man könnte auch in C
programmieren, aber das sollen dann die Leute machen, die Lust dazu
haben. Beim HCS12 ist halt leider die allgemeine Verfügbarkeit für
"Privatmenschen" sehr eingeschränkt und nicht jeder hat ein passendes
BDM-Interface zuhause rumliegen.
Also ist es für mich momentan das sinnvollste, das Projekt
weiterzuentwickeln und ich denke, dass da noch viel mehr Potenzial drin
steckt. Natürlich hat es irgendwo seine Grenzen, aber die gilt es
erstmal herauszufinden...
Jörg
Joerg Wolfram schrieb:
> den ATXMEGA hatte ich eigentlich eine Zeit lang als Nachfolger im> Visier, das Ganze ist aber wieder vom Tisch und auch mein Demoboard habe> ich wieder verkauft.
warum eigentlich ?
Hauptgrund war das geänderte Programmierinterface. Davon abgesehen, dass
man den XMEGA auf dem XPLAIN Board nicht über den darauf befindlichen
USB-Anschluß programmieren kann, braucht man in den meisten Fällen einen
neuen Programmer und die Clone-Funktion lässt sich auch nicht mehr so
einfach realisieren. Alles in Allem ist es (für mich) den Aufwand nicht
wert, da das Projekt OpenSource ist, kann sich ja jeder selbst mit einer
Portierung versuchen.
Jörg
Hallo Jörg,
ich bin grad am überlegen, ob ich meinem Sohn einen Experimentier-
computer mit Deinem Basic zu Weihnachten bauen soll, und bin beim
Suchen über das gestolpert:
http://home.arcor.de/wehrsdorf/Oled-Display-Recycling.html
Ich hab mir so ein Teil besorgt.
Meinst Du, dass man Dein Basic einfach an diese Platine anpassen könnte?
Der Mega 168 ist zwar etwas knapp, aber den könnte man ja gegen einen
328 austauschen.
Ein mobiler Basic Computer mit Grafik Display wäre schon nett.
Evtl. könnte man auch eine Tastatur über die Infrarot Schnittstelle
anschliessen.
Gruß
Karl
möglich wäre es schon, z.B. die Mega32 Version an einen Mega328
anzupassen. Notwendig wäre hauptsächlich ein neuer Videotreiber, der
z.B. die Umgebung des Cursors auf dem OLED darstellt.
Ich hatte mal etwas ähnliches konzipiert (AVR-Handheld), die Entwicklung
aber wieder eingestellt, da es mir zuviel Aufwand war, die abgespeckte
BASIC-Runtime mit der des ChipBasic2 zu synchronisieren.
Deshalb kann die nächste Version vom ChipBasic2 auch alternative Treiber
laden, die z.B. LCDs über den Parallelport ansteuern. Im Moment habe ich
aber nur den originalen "Vektortreiber" und einen TILE/SPRITE Treiber
mit "Finescrolling" realisiert.
Außerdem wird es endlich Unterstützung für den zweiten USART des
Mega644P geben, wobei die Transfer-Operationen weiter über den
Software-System-UART laufen werden. Allerdings wird sich die Doku noch
etwas hinziehen, bei Bedarf kann ich aber wieder Hexfiles hier
reinstellen.
Jörg
Hallo Jörg
Ich habe den AVR Basiccomputer nachgebaut. Er funktionierte fast auf
Anhieb.Jetzt meine Frage, könnte man auch ein Farbdisplay(SHARP LQ
9D01L) mit 640x 480 Pixel anschließen? Das lag bei mir so in der
Bastelkiste rum!Meine zweite Frage ist, ich möchte statt des Flashs eine
Speicherkarte anschließen. Das müßte doch ohne größeren Aufwand möglich
sein, den in den Speicherkarten stecken doch sicher auch nur
Flashbausteine.
Rudolf
Hallo Rudolf,
1. Das von Dir genannte Display ist nicht anschließbar, da es einen ganz
anderen Grafikcontroller braucht.
2. Theoretisch ist es machbar, allerdings ist das Dateisystem speziell
auf die Dataflash-Bausteine zugeschnitten. Man könnte das fast 1:1 auf
eine SD-Karte übertragen, indem man dort nur 264 Bytes je Sektor nutzt.
So ließen sich 256 Dateien mit jeweils maximal 32K unterbringen, was
einem Speicherbedarf von effektiv 16MiBytes auf der Karte entspricht.
Die Nutzung irgendwelcher PC-Dateisysteme wird allerdings wohl am
fehlenden Programmspeicherplatz im Mikrocontroller scheitern. Und, auch
wenn etwas schwerer beschaffbar sind die Dataflash-Bausteine günstiger
als neue SD-Karten.
Jörg
Hallo Jörg
Das das LCD so nicht gehen wird das konnte ich mir auch denken. Meine
Frage war falsch formuliert. Deshalb noch einmal neu: Könnte man den
Atmel dazu bringen das LCD anzusteuern.Ich könnte mir vorstellen, das es
zu zeitkritisch wird und wohl deshalb nichts daraus wird. Möglicherweise
könnte man die Signalaubereitung Pixcelclock, hsync, vsync extern
aufbereiten und dann mit der Datenausgabe verbinden. Ich hatte da
irgendwo gelesen das es einen IC von Maxim, denk ich,gibt, der das kann.
Das mit den SD Karten kann ich nicht nachvollziehen. Die Karten werden
einem schon fast hinterhergeschmissen.Die Fassungen dafür gibts im
Elektronikversand auch für wenig Geld. Selbst wenn viel Speicherplatz
auf der Karte verschenkt wird,was vielleicht sogar ganz gut ist, den
dann werden die Speicherzellen nicht so oft beschrieben und halten
länger. Würde es Dir viel Arbeit machen das Teil in den Basiccomputer
mit zu integrieren? Das wäre echt Spitze. Ansonsten ist Dein Projekt
echt gut, wenn man bedenkt was alles in den einen Chip passt, und was an
Gehirnschmalz darin steckt! Ach so noch eins. Der Comp reagiert sehr
unwillig auf das Niederdrücken der Tasten auf der Tastatur. Die
Pfeiletasten werden sofort erkannt und man kann damit im Menüe hin und
her fahren. Auf die ESC Taste und die vier Funktionstasten reagiert der
Computer nur sehr unwillig wenn überhaubt.Ich habe schon mehrere
Tastaturen ausprobiert, manche gehen gar nicht, wie Du das schon
vorausgesagt hast, und die ps2 Tastatur funzt gleich nicht, da bricht
der ganze comp zusammen. Rudolf
Ach so was ich noch vergessen habe. MEINE Tastatur ist eine AT.
Angeschlossen wird sie über einen industrieellen Adapter an den ps2
Eingang des Computers. Nur damit gehts! Rudolf
>Und, auch wenn etwas schwerer beschaffbar sind die Dataflash-Bausteine >günstiger
als neue SD-Karten.
TME.eu hat massenweise und verschiedene Bauformen und Speichergößen der
DataFlashs.
CSD-electronics hat auch die wichtigsten und liefert an privat.
Hallo Jörg,
kannst Du das mit den ladbaren Displaytreibern etwas näher erklären?
Wie wird das praktisch aussehen?
Vielleicht kann ich mit dem Treiber für das Oled zur Hand gehen.
Dieses spezielle Display hat den Vorteil, dass das komplette Gerät
(inclusive Spannungswandler und ATMega16) für 5-6 Euro zu haben ist,
was ein ziemlich unschlagbarer Preis ist.
Da überlegt man isch schon, was man mit dem Ding alles anfangen könnte.
--Karl
@Rudolf
Ich denke, um ein solches Display vernünftig anzusteuern braucht man
schon einen Displaycontroller oder etwas vergleichbares.
So, wie Du das mit den Tastaturen beschreibst, würde ich eher auf ein
elektrisches Problem schließen. Eventuell mal 3K3 Pullups an die Daten-
und Taktleitung hängen. Während des Startbildschirmes kann man übrigens
auch mit der rechten Shift-Taste in den "Keyboard-Debug-Modus" wechseln,
in dem die von der Tastatur gelieferten Scancodes angezeigt werden.
Ich selbst sehe in SD-Karten anstelle von Dataflash-Bausteinen keinerlei
Vorteil, außer dass man sie halt an jeder Ecke zu kaufen bekommt. Wobei
das langsam aber auch nicht mehr stimmt, denn meistens sind das ja
neuerdings SDHC-Karten, die dann von der Ansteuerung her wieder nicht
mehr kompatibel sind.
Den Aufwand würde ich nicht allzu hoch schätzen, solange die
Dateisystemstruktur beibehalten wird und jemand schon genügend Erfahrung
damit hat. Dann könnte man einfach die Libdfl ersetzen, wobei dann
allerdings die Möglichkeit, Dataflash Bausteine anzusteuern
verlorenginge.
Alternativ könnte man "Programm von SD laden" und "Programm auf SD
speichern" in ein ladbares Binärprogramm packen und darüber ausführen.
Dieser Weg steht auf jeden Fall offen, die Frage ist nur, ob sich jemand
der Scahe annimmt...
Jörg
@Karl
Das geht aber nur beim ChipBasic2, bei der Mega32-Version wäre es
theoretisch auch mögich allerdings sind die beiden Systeme nicht
zueinander kompatibel.
Aussehen wird es so, dass man den Treiber einfach auf Programmplatz 8
lädt und über VMODE 7 aktivieren kann. Nach dem Aufruf der
Initialisierungsroutine im Treiber werden sowohl die Bildausgaberoutine
als auch die Ausgabefunktionen (PRINT, PLOT...) auf diesen Treiber
umgeleitet.
Wird wieder zu einem anderen Video-Modus zurückgewechselt, wird eine
Shutdown-Routine im Treiber aufgerufen und danach alle Ausgaben wieder
auf die internen Treiber umgestellt. Mit 2 Konfigurationsbits im Treiber
kann man die Ausgaben zum Parallelport unterbinden und externe I/O (z.B.
über I2C) ab Adresse 0x500 aktivieren. Dazu wird es wahrscheinlich
später einen Mega 16/32 als IO-Erweiterung geben.
Jörg
@Jörg
Hast du dir für ein Nachfolgeprojekt eigentlich auch mal den Parallax
Propeller Chip angeschaut? Das ist der ideale Chip für ein solches
Projekt.
- mehrere parallele Prozessoren
- Video Generator mit Farbe möglich (Hardware 3 Widerstände)
- VGA und controllerlose LCDs ansteuerbar
- SD Treiber (auch SDHC mit FAT32), PS/2 und so weiter schon als
einbindbare Objekte verfügbar.
- Im DIP40 erhältlich, per serielle Schnittstelle programmierbar
>> Ich selbst sehe in SD-Karten anstelle von Dataflash-Bausteinen keinerlei
Vorteil, außer dass man sie halt an jeder Ecke zu kaufen bekommt
Das liegt dann wohl daran dass du den ~ 1000 mal grösseren Speicher
nicht nutzen kannst. Mit dem Propeller kann man z.B WAV-Dateien spielen,
was sehr schnell nach etwas mehr Speicher verlangt...
Andi
@ Andi
> Das liegt dann wohl daran dass du den ~ 1000 mal grösseren Speicher> nicht nutzen kannst. Mit dem Propeller kann man z.B WAV-Dateien spielen,> was sehr schnell nach etwas mehr Speicher verlangt...>
Nein, ich WILL den größeren Speicher nicht nutzen. Denn dann wird das
Ganze irgendwann derart aufgeblasen, dass man sich auch gleich ein
kleines ITX Board kaufen kann...
Für den Propeller gibt es ja bereits HYDRA als Spielkonsole und den
HIVE. Dem muß man meiner Meinung nach nicht unbedingt noch ein drittes
ähnlich gelagertes Projekt hinzufügen. Da ist dann ein S12 oder S12X
(für mich) schon eine interessantere Herausforderung, abgesehen davon
dass ich zum Programmieren des Propellers Dinge benutzen müsste, die ich
ganz einfach nicht benutzen möchte.
Jörg
OK, wenn du natürlich nicht nach einer einfachen, leistungsfähigeren
Lösung suchst, sondern nach einer Herausforderung, dann ist jeder Tipp
überflüssig.
Denn nur du kannst wissen, was dich herausfordert.
> Für den Propeller gibt es ja bereits HYDRA als Spielkonsole und den> HIVE.
Hydra ist zu teuer und nicht offen, Hive ist zu kompliziert und niemand
programmiert was dafür. Aber da gibt es noch viel mehr
Hardwareplattformen mit dem Propeller. Die Herausforderung wäre halt die
Software.
> ... zum Programmieren des Propellers Dinge benutzen müsste, die ich> ganz einfach nicht benutzen möchte.
Wenn du damit Windows meinst - es gibt alternative IDEs für Linux und
MacOS.
Wenn du Spin meinst - Es gibt auch C, und Assembler geht immer.
Andere Hindernisse fallen mir gerade nicht ein.
Andi
Andi, kannst du bitte einen Link mit C-Compiler und/oder IDE für den
Propeller posten? Ich kenne nur das da
http://propeller.wikispaces.com/Linux+Development und das ist nicht
grad' was ich mir vorstelle.
> Hydra ist zu teuer und nicht offen,
Für die interissiere ich mich auch, aber ca. 250€ für ein paar
elektronische Bauteile...? Nein danke. Da nehm ich lieber dieses Ding
hier: http://www.microcontroller-starterkits.de/propeller.html> Hive ist zu kompliziert und niemand> programmiert was dafür. Aber da gibt es noch viel mehr> Hardwareplattformen mit dem Propeller. Die Herausforderung wäre halt die> Software.
Für den Hive wird Programmiert. Die meisten Projektbeteiligten, dazu
gehöre auch ich, sind aber eher die Bastler... Auf der Projekt Homepage
wird das HiveOS vorgestellt. Einige haben sich das IOS näher angesehen
und dieses etwas angepasst. Es gibt Hacks für den Grafiktreiber. Dann
gibt es ein Hack/ Workaround für die Signalstörung zum TDA7050
Verstärker-IC und, es gibt bereits einen - noch in der Entwicklung
befindlichen - Rom- Switcher.
Programmiert wird für den Hive natürlich auch. Meistens sind es aber nur
Kleinigkeiten. Es gibt schnelle Ports einiger Spiele, die auf dem
Propeller MCU portiert worden waren.
Ausserdem hatte ich begonnen, ein E-Mag für den Hive zu schreiben.
Entsprechendes kann man im Forum lesen...
Einige Links:
Projekt Homepage -> http://hive-project.de/
Forum -> http://hive-project.de/board/
Wiki -> http://hive-project.de/wiki/
So, nun aber wieder BTT :)
Ich muss Jörg recht geben.
Ich weiß nicht recht, wofür der Propeller Chip gut sein soll.
Das ist ein typisches Nerd Produkt. Er hat zwar einen interessanten
Videogenerator, aber viel zu wenig RAM, um ihn sinnvoll zu nutzen.
Die aktuellen Projekte benutzen umständliche Tricks, die nie so
vorgesehen
waren, um Code nachzuladen und externen Speicher zu benutzen, was aber
die
Ausführung so langsam macht, dass der Propeller seine Vorteile nicht
mehr ausspielen kann.
Wenn man viel Zeit hat, kann man mit dem Propeller Sachen machen, die
andere Controller von Hause aus können (meistens besser und billiger),
und sich Tools selbst schreiben, die es anderswo kostenlos dazu gibt
(z.B. C-Compiler, Debugger). Man kann's aber auch bleiben lassen.
Da kauf ich mir lieber für das selbe Geld ein ARM oder Mips Board.
Schaut euch mal an, was man für 50 Euro schon alles bekommt:
Ein ARM Board mit 16MB RAM, 4MB Flash, WLAN, Ethernet, USB Host, RS232,
JTAG, mit Ethernet Bootloader und kompletter Linux Distribution.
Auch Router genannt.
Das Chipbasic ist deshalb cool, weil es auf einem einzelnen AVR ohne
viel
drumherum läuft, und weil die Entwicklung auf dem Gerät selbst läuft,
ohne PC mit Toolchain.
Hallo Jörg!
Ich habe die zwei Pullupps an die beiden Leitungen gehangen. Funzt
einwandfrei.Die beiden Widerstände solltest du gleich mit auf der
platine integrieren. Ich habe auch zusätzlich noch einen kleinen
Resettaster auf die Platine gesetzt, um nicht immer das Steckernetzteil
ziehen zu müssen, wenn ein Neustart sein muß. Jetzt noch eine Frage zum
Übertragen von Dateien vom PC zum AVR. Bis jetzt kommt immer nur Schrott
oder nichts auf dem AVR an. Ich kann machen was ich will alle
Einstellungen die möglich sind, habe ich ausprobiert. Gibts noch etwas
was ich nicht beachtet haben könnte? Manchmal bricht auch der AVR völlig
zusammen, das Bild ist weg und es geht garnichts mehr, auch kein Reset.
Dagegen hilft nur den seriellen SUB rauszuziehen, dann startet der AVR
wieder allein. Rudolf
Hallo Jörg!
Hat sich erledigt. Habs auf die Reihe bekommen.Programme lassen sich
laden und starten.Die Einstellung ist `simple` in AVR Config,2400 Baud,2
Stopbits ,Parität keine.Eins ist aber immernoch:wenn ich einen Kaltstart
mache mit meinem Resetknopf, stürtzt der AVR ab. Erst das Abziehen des
Steckers von der Seriellen Schnitstelle bringt wieder Leben in das Teil.
Rudolf
@Rudolf
Welche Version benutzt Du, wie sind die Fuses gesetzt?
Mit den Fusebytes
LOW 0xe6
HIGH 0xd1
EXT 0xfc
wird der Bootloader abgeschaltet, mit
LOW 0xe6
HIGH 0xd2
EXT 0xfc
ist er aktiv und sollte auch beim Kalt-Start (serielles Kabel
angesteckt) der Bootloader (oben eine grüne Textzeile) kurz zu sehen
sein.
Anstelle von RESET sollte CTRL+ALT+DELETE für einen Warmstart eigentlich
immer gehen.
@Klima
Im Moment ist nicht mal die deutsche Doku vollständig, ob es jemals eine
englische von mir geben wird, ist bei meinem derzeitigen Zeitbudget eher
fraglich.
Und weil ich gerade dabei bin, die nächste Version wird es wohl erst im
neuen Jahr geben. Hauptgrund ist ein erweitertes Treiberkonzept mit
definierten Schnittstellen.
Jörg
Hallo Jörg!
Ich benutze die Version 1.20 .Warum der AVR abstürtzt ist mir jetzt auch
klar geworden. Die grüne Zeile nach dem Einschalten ist nicht zu sehen.
Der AVR springt sofort auf den blauen Bildschirm mit dem symbolischen
Chip drauf.Ich denke die Grüne Zeile müßte eigendlich zu sehen sein,
selbst wenn die fusebits verkehrt sind, da diese ja nur den
Speicherbereich gegen überschreiben schützen und der Bootlader als
Programm ja vorhanden ist,oder liege ich da verkehrt?. Rudolf
Hallo Jörg!
Alles klar habs auf die Reihe bekommen. Alles funzt wie es sein soll.
Die Erweiterung bau ich demnächst auf, sobald der IC eingetroffen ist.
Frohe Weihnacht und einen guten Rutsch ins neue Jahr wünscht Rudolf
Hallo Jörg!
Erstmal beste Neujahrswünsche an alle.Ich habe schon wieder ein Problem.
Nachdem der AT Flash bei mir eingetroffen war hab ich das Modul
zusammengebaut. Es ist aber kein AT45DB08 an Bord sondern ein
AT45DB161.Der Baustein wird aber vom AVR nicht erkannt wie es aussieht.
Weil ich dachte, ich hätte mich bei der Bestellung geirrt ließ ich
nochmal einen AT 45DB08 kommen. Wieder hat man den 161 ersatztweise
reingepackt. Er unterscheidet sich nur in der Größe der Pageseiten
nämlich mit 528 Bytes, statt beim 08 der nur 264 Bytes hat. Natürlich
sind die S-Ram Data Buffers auch größer. Wie läuft eigendlich die
Erkennung des Flashmodules? Welche Parameter werden abgefragt? Läßt sich
der AVR nicht so umstellen, daß auch diese Flashbausteine erkannt
werden? Rudolf
Hallo,
auch von mir Neujahrsgrüße an alle. Der Flash-Typ wird über die
Device-ID bestimmt. Ich werde mal schauen ob man den Treiber an den 161
anpassen kann, allerdings wird er dann als 81-er behandelt. Ansonsten
müsste man einen neuen Dateisystemtreiber schreiben.
Wenn wir gerade bei den Treibern sind, die kommende Version wird da
wesentlich flexibler sein. Z.B. 4- und 8-Kanal Soft PWM (ca. 60Hz) am
Parallelport wobei nur noch die ersten 24 Zeichen je Zeile dargestellt
werden habe ich bereits realisiert. Grafik- und Text LCD Treiber sind
ebenso geplant wie LED Multiplex Treiber.
Die Clone-Funktion habe ich wieder entfernt, dafür gibt es jetzt ein
ladbares Programm, mit dem man auch die Konfiguration des zu clonenden
Controllers einstellen kann. Ebenso wird es nur noch eine
Tastaturtabelle geben, die aber via Binärprogramm änderbar ist.
Jörg
Hallo,
erstmal Glückwunsch zu diesem ebenso simplen wie tollen Projekt!
Ich habe über die Feiertage auch endlich meine Platine zusammengelötet
und werde damit meine ersten Spielereien machen. Damit rutscht man ja
fast wieder in die Zeit der alten Heimcomputer - nur mit mehr
Rechenpower.
Womit wir beim Thema sind: Die Beispielcodes sind zum ersten Testen ja
sehr schön, aber hat von Euch vielleicht jemand auch noch eigene Tools,
Spiele, Demos geschrieben und im Internet zur Verfügung gestellt? Ich
selbst habe z.B. noch viele alte "Happy Computer" usw. mit vielen
kleinen Listings für diverse Heimcomputer. Damals habe ich die schon
z.B. von ZX Spectrum auf ATARI XL portiert. Das könnte man teilweise
auch mal für das Board ausprobieren. Ein digitaler Joystick sollte sich
ja an den Parallelport anschließen lassen (kann man den per Basic
einlesen?). Wenn das funktioniert, würde ich die Sourcen auch irgendwo
ablegen.
Gruß, Rene
@Rudolf
Support für den 45DB161 und den 45DB321 sollte in der nächsten Version
mit drin sein, allerdings muss ich noch testen, ob das auch so
funktioniert. Wichtig ist aber auch, dass diese (zumindest laut meinem
Datenblatt keine 5V an den Eingängen vertragen wie der 45DB081. Hier ist
also auf jeden Fall eine Pegelanpassung notwendig.
@Rene
Digitaler Joystick sollte kein Problem sein, einfach die Schalter
zwischen I/O und Masse. Gelesen wird dann mittels IN(n). An Pin16
(/INIT) der paralellen Schnittstelle kann man getrost auch +5V nach
aussen führen, ohne dass ein angeschlossener Drucker Probleme macht.
Das wird auch in der nächsten Doku mit drin sein. Und das mit der
Programmsammlung wäre eine feine Sache, ich habe aber ehrlichgesagt
momentan weder Zeit noch Lust, so etwas zu pflegen.
Support für den Mega644P ist fast fertig, dazu kann der Input-Pin der
seriellen System-Schnittstelle (also der immer vorhandenen) per
Konfiguration zwischen PD1 und PD3 gewählt werden. Der Controllertyp
wird automatisch beim Systemstart erkannt und auch angezeigt. Beim
Editor gibt es ein paar kleine Änderungen, insbesondere werden die
Cursorpositionen beim Verlassen des Editors im EEPROM gespeichert. LCD-
bzw. DUAL-Treiber (die Anzeige ist parallel auch über den TV-Ausgang
verfügbar) habe ich für 1x16 und 2x20 Zeichen Displays fertig, andere
habe ich z.Zt. nicht rumliegen. Allerdings fehlt hier noch die Doku
komplett.
Release-Zeitpunkt wird wohl am WE sein, wahrscheinlich aber nur für das
"Hauptpaket".
Jörg
Mit einem AT45DB321 habe ich es gestern getestet und es funktioniert.
Der AT45DB161 müsste eigentlich auch gehen.
Wichtig ist, zuallererst in die Config-Seite zu gehen, und den Input-Pin
für die serielle Schnittstelle auf "PD3" zu stellen da er bei der
bisherigen Schaltung dort liegt.
Jörg
Hallo Jörg!
Mit der neuen Software hat der AVR das Flashmodul sofort erkannt. Das
Abspeichern der Programme scheint auch zu funzen. Ein Problem scheint es
beim Lesen zu geben, denn es werden nur Fragmente der Dateien
ausgelesen. Könnte das möglicherweise eine Signalpegelunterschied der
Leseleitung zwischen dem AVR und dem AT 45DB161 sein, oder habe ich den
Flash schon geschrottet?. Im Moment habe ich keine Zeit weiter nach
Ursachen zu forschen. Bis auf weiteres. Rudolf
Hallo Rudolf,
bei mir hatte es eigentlich funktioniert. 3 Dinge fallen mir dazu ein:
1. Wie erzeugst Du die 3,3V? Nachgemessen?
2. Bei der Schaltung mit LED eventuell den Abblockkondensator vergrößern
3. SPI-Takt probeweise auf 156 KHz stellen
Bis zum nächsten Release wird es noch ein klein bisschen dauern, da ein
paar generelle Dinge zu Binärprogrammen noch konkret definiert werden
müssen.
Jörg
Ich habe gestern festgestellt, dass durch die Änderung im
DataFlash-Treiber Dateien tatsächlich nicht richtig geschrieben werden.
Das Problem lässt sich allerdings nicht so einfach lösen und deswegen
habe ich die Unterstützung für den AT45DB161 und den AT45DB321 erstmal
wieder entfernt.
Jörg
So, endlich geschafft! Die aktuelle Version hat mittlerweile die Nummer
1.27
und jede Menge Neues zu bieten.
Neben Bugfixes und Erweiterungen im BASIC habe ich vor allen Dingen das
Bibliotheks- und Treiberkonzept stark überarbeitet. So lassen sich jetzt
verschiedene Text und Grafik LCDs an den Parallelport anschließen oder
der Parallelport als 4 oder 8 Kanal PWM nutzen.
Zur Spieleprogrammierung gibt es einen Tile/Sprite Treiber mit
horizontalem und vertikalem Fine-Scrolling und den ehemaligen
Videomode7-Treiber. Über einen seriellen Lader kann das Ganze auch
ferngesteuert mit neuen Programmen versehen werden, ein passendes
Terminalprogramm ist auch dabei.
Da die Datenmenge wieder etwas angewachsen ist und nicht jeder alles
benötigt, habe ich das Ganze auf 3 Pakete verteilt.
Viel Spaß damit,
Jörg
Was ich übrigens sehr interessant fand, dass es auf meine vagen
Projektankündigungen recht viele Beiträge gab, zum eigentlichen Projekt
eher weniger...
In der Doku sind leider ein paar Bilder verkehrt, da muss ich mir zum WE
das Build-Script nochmal ansehen. Dann wird auch die Homepage wieder
aktualisiert.
Jörg
Homepage ist jetzt aktualisiert, es hat sich leider auch noch ein Fehler
ins Programm eingeschlichen. Durch die Umstellung auf das Mega644p
Includefile hatte der Wert von SPDR0 plötzlich den Wert Null, ohne dass
der Assembler etwas anmeckern konnte. Die SPI() Funktion hing sich
deswegen auf und auch im Clone-Programm bestand das Problem. Da ich bis
vor kurzem mit einer modifizierten Include-Datei gearbeitet hatte, ist
mir das beim testen gar nicht aufgefallen...
Mit der aktuellen Version 1.28 sollte das Problem behoben sein. Um den
Server hier nicht allzusehr zu strapazieren, verweise ich auf meine
Webseite bzw. die BERLIOS Downloadseite:
http://developer.berlios.de/projects/avr-chipbasic
Der treiber für 128x64 GLCD ist leider noch nicht fertig, wird aber als
nächstes in Angriff genommen.
Jörg
Hallo Jörg,
da ich in der Röhrenzeit meine ersten Elektronikerfahrungen gemacht
habe, und Basic der Einstieg in die Computerei war, bin ich begeistert,
was ein Chip alles kann. Großes Lob für das fundierte Projekt.
Mit dem angegebenen Universal-Layout und der V.1.26 habe ich den
Basic-Computer in Betrieb genommen. Display ein LC-TFT Monitor TM-70003A
mit Video-Eingang. SW-Bild mit BAS-Signal ist ok, aber das Bild rollt
langsam über den Bildschirm. Messung der Bildfrequenz ergab 15735,9 Hz
(63,55us) statt 15625 Hz. Die Quarzfrequenz liegt bei direkter Messung
mit einem Tastkopf einige 100 Hz tiefer. Gibt es eine Möglichkeit die
geteilte Frequenz am Prozessor zu messen?
Hat jemand zu meinem Problem einen Tipp?
Karl-Anton
Hallo Karl-Anton,
die 15735,9 Hz sehen mir sehr nach NTSC aus. Und wenn das Bild langsam
durchläuft, könnte das an HSYNC statt CSYNC liegen. Kontrolliere deshalb
bitte, dass keiner der beiden Jumper J2/J3 geschlossen ist und die
beiden Pull-Ups an PC2 und PC3 dran sind.
Jörg
Hallo Jörg,
ohne Prozessor habe ich die Schaltung um die Video-Ausgabe nochmal mit
dem Ohmmeter durchgemessen - alles ok. Nach dem Einschalten und ESC
steht auf dem Startbildschirm: MCU:644, VID:NTSC, KBD:DE.
Die gemessene Spannung an PC2 und PC3 beträgt aber 4.94V bei 5.00V
Betriebsspannung. Der Monitor (Pollin) kann angeblich PAL und NTSC, eine
Möglichkeit zum manuellen Umschalten habe ich aber noch nicht gefunden.
Kann man über eine falsch programmierte Fuse diesen Effekt erreichen?
Karl-Anton
Hallo Karl-Anton,
ich habe es jetzt nochmal sowohl mit einem Mega644 als auch einem
Meg644P versucht, beide zeigen PAL an, wenn kein Jumper gesetzt ist.
Wichtig sind auf jeden Fall die beiden externen Pull-Ups, vielleicht mal
auf z.B. 2K2 verringern.
Und hole Dir bitte auf jeden Fall die aktuelle Version (1.28).
@ alle
Die .SYS Datei im Binärpaket ist die, über die man mit dem Bootloader
ein Update machen kann.
Gruß Jörg
Hallo Jörg,
habe mit Erfolg Deinen PWM Treiber ausprobiert, er funktioniert sehr
gut.
Um jedoch ein RC Servo anzusteuern reicht die Auflösung von 8 Bit jedoch
nicht aus. Bei der geforderten Impulsbreite von 1-2ms habe ich gerade
mal 16 Einstellmöglichkeiten, was etwas wenig ist.
Da das sicherlich für viele hier interessant wäre Modellbauservos
anzusteuern möchte ich Dich fragen ob Du hier eine Möglichkeit siehst,
eventuell mit einer Erweiterung des PWM Treibers.
Gruss
Roger
Hallo Roger,
dazu müsste man einen neuen Treiber schreiben. Grund ist, dass bei dem
eingesetzten Prinzip die Auflösung durch die Horizontalfrequenz
vorgegeben wird. Man könnte nun die Pulserzeugung in die nicht
sichtbaren Zeilen 270 bis 302 verlegen (geht nur mit PAL) oder nur 20
Text-Zeilen darstellen und dafür 32 Bildzeilen für die Pulserzeugung
verwenden. Eine Pause zwischen den Impulsen von ca. 20ms sollte ja
eigentlich nichts ausmachen.
Möglich wäre es also schon, aber eben nur mit einem neuen Treiber...
Jörg
Ich habe das mal mit den Taktzyklen durchgerechnet, das Ganze ist nicht
ganz trivial. Letztendlich komme ich auf ca. 64 Einstellmöglichkeiten
ohne Beeinträchtigung der anderen Funktionen (insbesondere Keyboard und
seriell). Und dann wahlweise 4 oder 8 Kanäle. Für den Modellbau wären
vielleicht auch Kombinationen interessant. Z.B. 2xServo out, 2xPWM wie
beim jetzigen PWM Treiber und 6 I/O (wenn man BUSY und STROBE mit
hinzunimmt) oder halt eine andere Kombination.
Vielleicht gibt es ja noch mehr Anregungen, dann könnte ich mich mal
drüber machen...
Jörg
Hallo Jörg,
das Scrollen ist weg! Trotz Versuchen mit der Hardware und Programmieren
eines neuen 644P blieb der Effekt unverändert. Zufällig fand ich beim
Stöbern in der readme bei den binaries die richtigen Fuse-Einstellungen
und damit läuft alles prima. Vorschlag: In der Dokumentation
"chipbasic2_1.28_doc" die Fuse-Einstellungen als eigene PDF für die
Leute mit viereckigen Augen angeben.
Unter Windows hatte ich Probleme beim Programmieren des 644P mit dem
aktuellen PonyProg2000 - V. 2.07c Beta Jan 6 2008. Die P-Version des
Prozessors 644 wird nur mit der alten Version 2.06g Beta Apr 25 2007
unterstützt!?
Zur Anzeige dient mir neben dem TV ein LCD-Display mit 480x234
Bildpunkten. Dabei zappeln die Buchstaben wegen den nur 234 Zeilen
teilweise zwischen den Zeilen hin und her. Gibt es dafür einen besseren
Modus als 1?
Hallo Karl-Anton,
das mit den Fuse-Einstellungen werde ich beim nächsten Update in die
Doku mit reinschreiben, wahrscheinlich bei der Hardware.
Ich selbst nutze zum Programmieren Avrdude (unter Linux), die von Dir
geschilderten Probleme mit Ponyprog halte ich trotzdem für etwas
seltsam.
Die meisten kleinen LCD-Monitore lassen bei PAL einfach Zeilen aus. Bei
manchen ist das statisch, bei anderen scheint das aber zu wechseln. Wenn
man den Computer mit gesetztem NTSC-Jumper startet, sollte aber ein
ruhiges Bild zu sehen sein. Sämtliche Auflösungen (außer dem ladbaren
24x40 Treiber) haben weniger als 234 sichtbare Zeilen.
Gruß,
Jörg
Hallo Jörg,
vielen Dank für Deine Überlegungen bezüglich der Servoansteuerung.
Ich denke dass eine Kombination wie von Dir vorgeschlagen insbesondere
für diejenigen die etwas steuern wollen das richtige wäre. Vielleicht
bekommst Du ja bei dem Kombitreiber wenigstens einen PWM Ausgang mit 14
oder 16 Bit hin, evtl. unter Verzicht auf einen Teil der
Bildschirmausgabe....
Die Frequenz von ca. 61Hz passt ja, den Rest (Trimmung des Servo) kann
man sich ja dann in Basic programmmieren.
Gruss
Roger
Hallo Roger,
die Timer 2 PWM hat nur 8 Bit. Bei 50Hz Wiederholfrequenz hätte man eine
zeitliche Auflösung von ca. 78 Mikrosekunden, Was im Zeitbereich von 1-2
ms ungefähr 13 Einstellungen erlaubt.
Eine Lösung wären 64 Einstellmöglichkeiten über einen Videotreiber mit
20 Text Zeilen und das ganze mit relativ wenig Aufwand.
Die zweite Möglichkeit wäre, den Interrupt über mehrere Zeilen
auszudehnen und das Timing für diese Zeit "von Hand" im Treiber zu
machen. Das ist aber nicht ganz einfach, dafür sollten im Bereich 1-2ms
aber 256 oder gar 1024 Schritte drin sein.
Jörg
Hallo Jörg,
im Prinzip reichen 64 Einstellmöglichkeiten wahrscheinlich in den
meisten Fällen, jedoch bekommt man das Servo dann bestimmt nicht mehr
getrimmt ohne auf etliche Einstellmöglichkeiten zu verzichten wenn man
die Endlagen genau einstellen will.
Ich denke um eine Steuerung zu realisieren kommt man auch mit einem
relativ abgespeckten Videotreiber aus, der Anzeigebedarf ist meist
geringer, man könnte auch mit weniger als 20 Zeilen auskommen...
Der vorhandene 4xPWM Treiber +4x IO ist schon gut und praktikabel, wenn
ein oder 2 PWM Kanäle von der Auflösung her für Servos geeignet sind
wäre das super.
Gruss Roger
Hallo Jörg,
mit NTSC-Treiber macht der Mini-BASIC-Computer richtig Spaß. Inzwischen
habe ich auch mit KiCAD ein neues Layout mit zweiter Sub-D Buchse,
zusätzlichem Hohlstecker, Chinch-Buchse und 16-Farb-Erweiterung
fertiggestellt. Wichtig waren mir auch die 4 Befestigungslöcher an den
Ecken. Die einseitige Platine im 1/2 Europaformat mit 15 Brücken auf der
Bestückungsseite ist jetzt voll. Das Foto zeigt die V2.0, Erfahrungen
beim Aufbau sind in die aktuelle V2.1 eingeflossen. Wenn gewünscht, lade
ich die PDF's von Schaltplan, Layout und Bestückung und die Stückliste
gerne hoch.
Hallo Karl-Anton,
ich habe es nur kurz "überflogen", dabei ist mir etwas aufgefallen:
die zweite Schnittstelle beim Mega644P sollte mit der Schaltung wie bei
der ersten nicht funktionieren, da dafür das Eingangssignal invertiert
werden muß. ein NPN-Transistor sollte eigentlich ausreichen.
Jörg
Hallo Jörg,
danke für den Hinweis. Einleuchtend, da der MAX232 die Signale
invertiert. Die beim Zusammenlöten gemachten Erfahrungen habe ich in ein
neues Layout V2.2 einfließen lassen, dieses habe aber noch nicht
aufgebaut. Anbei Schaltplan, Layout, Bestückung, Stückliste und etwas
Kommentar dazu als ZIP. Wer beim Schaltplan oder Layout Probleme sieht,
bitte melden. Wenn sinnvoll, kann ich dann ja noch eine V2.3 erstellen.
Karl-Anton
Hallo Jörg,
eben habe ich mit dem Mode1-Oszi gepielt. Dabei fiel mir auf, dass die
binary und die doc-Version nicht übereinstimmen und der Messbereich nur
2,5V statt 5V ist.
Meine eigentliche Frage: kann man von der Basic-Oberfläche die
Referenzspannung zwischen 1,1/2,5 und AVCC umschalten oder muss man
direkt die Register poken? Gleiches gilt für die zuschaltbare
Vorverstärkung.
Hallo Jörg,
bei der 2. seriellen Schnittstelle sind in der Doku die folgenden
Baudraten angegeben.
n Bitrate (Bps)
0 1200
1 2400
2 4800
3 9600 (default)
4 19200
5 31250 (MIDI)
6 38400
7 57600
beim Senden zum PC mit ESPUT A (A=65 bis 89) und Einstellen der Baudrade
mit EBAUD (2 Stoppbits) funktionieren die folgenden Werte:
1 1200
2 2400
3 4800
4 9600
6 19200
Höhere Baudraten fand ich keine. Sind diese noch nicht implementiert
oder soll ich meine Hardware mal genauer untersuchen?
Karl-Anton
Hallo Karl-Anton,
anbei eine neue "Zwischenversion". Mit dem ADC hast Du recht, im
Demoprogramm werden falsche Werte angezeigt. Die Standardeinstellung
werde ich aber so lassen wie sie ist, da dann die bereits vorhandenen
Programme unter Umständen nicht mehr richtig funktionieren.
Aber ich habe die Funktion ein wenig erweitert, mit Werten von $100 bis
$1FF kann nun das ADMUX Register direkt gesetzt werden.
Die Baudraten sind wohl alle halb so groß wie beabsichtigt geraten. Das
U2X1 Bit war nicht gesetzt. Allerdings habe ich momentan keine HW da,
bei der ich das mal schnell ausprobieren kann.
Jörg
Hallo Jörg,
danke für die schnelle Antwort. Was mir noch gefallen würde, wäre eine
Echtzeituhr mit Einbindug in Basic:
z.B. DS1307 mit 3V Li-Bat. IC und Quarz hätten statt einem der beiden
24C512 noch Platz auf dem Board. Mit der Batterie wird es etwas eng.
Lieferant Reichelt, passender Quarz mit 10 pF Lastkapazität lieferbar
(+Trimmer 5pF) , IC z.Zt. nur als 8-pol SMD statt 8-pol DIL lieferbar.
Karl-Anton
Hallo Karl-Anton,
dafür brauchst Du Dir nur eine kleine Bibliothek zu schreiben und
fertig. Das geht auch einfach in BASIC.
Zum einem ist im RAM kein Platz mehr für die Systemzeit, zum anderen hat
bei den RTC jeder seine Vorlieben, ich benutze meist die DS3232, die ist
sehr genau und hat Temperatur- und Alterungskompensation und braucht
keinen externen Quarz. Ist allerdings auch ein bisschen teurer, aber für
Outdoor-Geräte optimal.
@Roger
Treiber habe ich angefangen, braucht aber noch ein bisschen Zeit,
Auflösung wird wahrscheinlich bei ca. 300 Schritten im Bereich von 1-2ms
liegen. Problem ist momentan die beiden anderen PWM Kanäle einigermassen
jitterfrei zu halten und auch noch die serielle Schnittstelle zu
bedienen, dazu muß das Timing auf den Takt genau stimmen und
letztendlich noch in 3K reinpassen. Möglich sollte es aber sein...
jörg
Hallo Jörg,
beim Versuch, die auf dem Bildschirm angezeigten Werte im Sekundentakt
zusätzlich über sie serielle Schnittstelle 1 auszugeben, habe ich ein
Problem. Möglicherweise ein Formatierungsproblem, aber ich habe in der
Referenz kein Beispiel gefunden. Kannst Du bitte mein angefangenes
Programm mal anschauen?
Karl-Anton
Hallo Karl-Anton,
vielen Dank, ja, das liegt nicht an Deinem Programm, es war schlicht
noch ein Fehler im System. Und zwar kam der durch die Erweiterung um
Kanal 4 für die zweite serielle Schnittstelle, da ist das XL-Register
nach dem POP nochmal benutzt worden.
Also gibt es mal wieder eine neue Version...
Jörg
Hallo Jörg,
danke für die V1.30. Die Serielle Ausgabe läuft jetzt auf Anhieb. Mit
dem anhängenden Programm läßt sich ein Temperaturprofil steuern. Die
Datenpaare enthalten immer Zeit,Temperatur. In längeren Zeitabschnitten
gibt es Probleme mit dem Integer-Zahlenbereich in Zeile 38. Bei
Änderungen der Anzahl Datenpaare am Programmanfang auch in Zeile 54 die
Zahl 10 anpassen. Für Erweiterungen sind noch 40 Zeilen frei.
Karl-Anton
Hallo Jörg,
beim Abspeichern des Programms auf dem PC über Seriell 1 wird die
12.Stelle vom Namen nicht übertragen - ist kein aktuelles Problem.
Bei der Gelegenheit die weitere Programmvariante V1.2 + Doku. Der
Schaltpunkt erfolgt jetzt durch Vergleich der Temperaturwerte (0-250)
und nicht mehr der Kurvenpunkte.
Noch eine generelle Frage: Gibt es weitere Anwendungsprogramme oder
beschäftigt sich dieses Forum überwiegend mit der Systemprogrammierung?
Karl-Anton
Hallo Karl-Anton,
ich kann mir denken, woran das liegt. Irgendwann habe ich das Senden
dahingehend geändert, dass die Programmnummer nicht mit übertragen wird.
Der danach folgende Doppelpunkt und der Programm-Name sind aber 13
Zeichen... Werde ich mir heute abend mal ansehen.
Zu Deiner Frage bezüglich Anwendungsprogrammen. Im Forum hier geht es
mehr um den AVR-Code, in diesem Fall das, was Du als
Systemprogrammierung bezeichnest. Für Anwenderprogramme, Bibliotheken
etc. gibt es keine eigene Plattform und auch hier im Thread ist nur
wenig davon zu lesen. Obwohl das Projekt gerade durch das erst in
letzter Zeit neu hinzugekommene Treiber- und Bibliothekskonzept sehr
viel Potenzial für verschiedenste Anwemdungen hat.
Es gab schon mal Vorschläge für eine "Programmsammlung", herausgekommen
ist aber dabei nichts, mir selbst ist der Aufwand dafür aber einfach zu
hoch. Ich hab ehrlichgesagt keine Lust jeden Tag nach irgendwelcher
Potenztablettenwerbung zu suchen um diese zu löschen, aus diesem Grunde
gibt es auf meiner HP auch kein Gästebuch mehr.
Jörg
Hallo Jörg,
seit 10 Jahren betreibe ich zu meinem Vergnügen die Homepage von meinem
Heimatdorf, so ist mir das SPAM-Problem leider auch bekannt.
Ich stimme Dir zu, dass der 644P-Basic-Rechner eine interessante Basis
für Steueraufgaben in der realen Welt bildet. Zum Spielen bietet mein
alter Commodore mehr Möglichkeiten. Bis Widerspruch kommt, werde ich das
eine oder andere an Hardware oder Programmen posten.
Zum AVR-Code: Eine vorhandenes Netzgerät würde ich gerne mit einem dual
12-Bit DAC with SPI (MCP4922-E/P) ansteuern. Macht es viel Aufwand,
einen Basic-Befehl (ähnlich TEMP() oder XPOKE X,Y) zu erfinden, um ein
16-bit-word über das 2-wire Serial Interface zu senden?
Karl-Anton
Ich weiß zwar nicht ob das nicht vieleicht Zweckentfremdung ist aber
könnte man nicht den SVN-Server von dem Forum benutzen um
BASIC-Programme von User für User hochzuladen?
Hallo,
passend zu meinem 644P-Basic-Board (s.o.) hier eine universelle
einseitige Erweiterungskarte V1.0 im halben Europaformat mit Steckern
und freier Lochrasterfläche. Einzelheiten siehe ZIP-File.
Karl-Anton
Hallo Karl-Anton,
SPI über das TWI geht zumindest hardwaremäßig nicht. Dazu müsste man das
TWI abschalten und die Portpins PC0 und PC1 per Software steuern.
I2C-Bausteine lassen sich dann aber nicht mehr nutzen. Besser wäre es,
auch den SPI/ISP-Anschluß mit auf das Zusatzboard zu bringen, dann
könnte man das mit der Funktion SPI() erledigen. Z.B:
1
10 OUT $200,$10
2
11 A=SPI(HI(C))*256+SPI(LO(C))
3
12 OUT $200,$FF
gibt den Inhalt der Variable C mit msb zuerst auf die SPI-Schnittstelle
aus.
In Zeile 10 wird die Schnittstelle konfiguriert und SS auf LOW gezogen,
in Zeile 11 findet der Datenaustausch statt (A=gelesener Wert) und in
Zeile 12 wird SS wieder auf "1" gesetzt.
Eine weitere Möglichkeit wäre ein "Soft-SPI-Treiber" für die parallele
Schnittstelle.
Jörg
Hallo Jörg,
danke für die ausführliche Antwort. Da bin ich wohl den Abkürzungen zum
Opfer gefallen. Die I2C=TWI(bei AVR) Schnittstelle habe ich für das beim
IC MCP4922 angegebene SPI-Interface gehalten!?
Mit einem Pfostenstecker im Lochrasterfeld kann ich die
SPI-Schnittstelle problemlos auf das AddOn Board bringen und dank Deines
Beispiels den DA-Wandler verwenden.
Karl-Anton
Hallo Jörg,
nochmal ein Versuch, Schnittstellen zu ergänzen. Bei Reichelt gibt es
den 18Bit AD-Wandler MCP 3421A0T-E/CH mit I2C-Interface für gut 2€.
Obwohl im 6-Pin SOT23-6, sollten sich die 2x3 Beinchen im 0,95mm Raster
noch von Hand löten lassen. Macht es Sinn, dieses IC mit einem eigenen
Basic-Befehl einzubinden?
Karl-Anton
Hallo Karl-Anton,
ich denke nicht, dass das sinnvoll ist. Die "TEMP()" Funktion für den
LM75 ist eigentlich auch nur noch aus Kompatibilitätsgründen zu den
Vorgängerversionen drin.
Am System selbst will ich eigentlich auch nicht mehr als unbedingt
notwendig ändern, Bugfixes sind da natürlich die Ausnahme. Die
Gesamtanzahl aktueller Downloads und somit Nutzer hält sich in Grenzen
und für mich reicht die Funktionalität bei weitem aus. Weitere Treiber
und Bibliotheken wird es aber noch geben, auch wenn sich die
Entwicklungsgeschwindigkeit zugunsten neuer Konzepte verlangsamen wird.
Jörg
Hallo Jörg,
schade, aber ich kann Deine Argumente verstehen. In der Doku zu V1.28
habe ich zum Thema Schnittstellen und Assembler nachgelesen. Dazu zwei
Fragen:
1. In "interna.doc" unter "2.7 Adressbereich für I/O-Erweiterungen" sehe
ich die Möglichkeit, mittels Binärprogramm weitere Schnittstellen
einzubinden. Hast Du dazu weitere Infos (Beispiel?), denn so bin ich
ziemlich ratlos.
2. Für die Erstellung von Binärprogrammen in der Windows-Welt mit
Assemler/C bietet sich AVR-Studio 4 von Atmel an. Gesucht wir ein Profi,
der ein Beispiel mit zugehörigem make-file für die Binärdatei mit 3072
Bytes und der erforderlichen Datenstruktur als Grundlage für eigene
Applikationen zur Verfügung stellt.
Genug der Wünsche! Danke Jörg für das tolle Projekt.
Karl-Anton
Das is ja mal ein geniales Projekt ;)
Ich würd gern Screenshots sehen, falls es jemand zufällig demnächst an
einer Fernsehkarte angeschlossen hat..
Der Handheld interessietr mich auch sehr, bin gespannt, was draus wird
;)
@ Karl-Anton,
die I/O Erweiterung läuft über einen Treiber auf Programmplatz 8. Hierzu
gibt es zwei Einsprungadressen für IN() und OUT. Alle IN() und OUT
Befehle mit Adressen ab 0x800 greifen auf diese Routinen zu, bei
Adressbereichen die nicht bedient werden muß einfach nur das
Fehlerregister auf 40 (NO IO DRIVER) gesetzt werden. Was man
letztendlich mit den Befehlen realisieren will bleibt einem selbst
überlassen, die Adressen für die 4 Erweiterungsmodule habe ich einfach
erstmal willkürlich festgelegt. Eine Möglichkeit wäre z.B. ein über I2C
angeschlossener Mega16, der dann weitere I/O zur Verfügung stellt.
Anwendungsprogramme in C zu schreiben wird wahrscheinlich schwierig
werden, mit einer C-Library die auf das API zurückgreift aber vielleicht
nicht unmöglich. Beim AVR-Assembler muss man wohl die normale
API-Include (ohne Makros) nehmen. Das build-bin Script lässt sich ja
vielleicht durch eine passende Batch-Datei ersetzen.
Da bei der Übertragung mittels X-Modem nur 3072 Bytes empfangen werden,
sollte es auch möglich sein, im Assembler-Programm 3K Nullbytes an den
Code hintenranzuhängen. Die Übertragung der dann vllt. 5K großen
Binärdatei wird halt vach 3K vom ChipBasic2 abgebrochen.
@ Chris
Screenshots mit einer Fernsehkarte sind aber nur s/w, da kein
Composite-Signal erzeugt wird.
Der Handheld existiert schon (es gibt auch einen Thread dazu) wird aber
von mir weder weiterentwickelt noch dokumentiert. Deshalb ist er auch
auf meiner Homepage nicht zu finden.
@ Roger
Treiber ist in Arbeit, es ist aber nicht ganz einfach da ich den Code
für Sound, Keyboard und Seriell in kleine Stücke "hacken" muss.
Auflösung sollte etwa 250 Schritte im Bereich von 1-2ms sein.
Jörg
Den Treiber habe ich heute testen können, er funktioniert auch soweit.
Es gibt lediglich einen kleinen Jitter um ca +- 3 Taktzyklen aber damit
müsste man leben können. Auflösung bei den beiden Pulskanälen ist 4µs
(0-2240µs), dazu gibt es noch zwei PWM-Kanäle (wie bei den anderen
PWM-Treibern) und 6 normale I/O. Den Code muss ich noch ein bisschen
aufräumen und die Doku fertig machen.
Ich kann ihn im Laufe der Woche vorab veröffentlichen, ansonsten ist er
beim nächsten Release mit drin.
Jörg
Hallo Jörg,
vielen Dank für deine Mühe und Zeit die Du in diesen Treiber gesteckt
hast, ich bin schon sehr gespannt ihn mit einem Servo auszuprobieren.
Ich werde dann hier berichten.
herzlichen Dank
Roger
Hier ist mal die aktuelle Version zum Test, sollte auch mit der Version
1.28 gehen. Hinter der Funktionsbeschreibung stehen immer die I/O
Adressen für OUT und IN()
1
D0-D3 als I/O nutzbar (0x800-0x803 Daten, 0x810-0x813 Datenrichtung)
2
D4 Pulsausgang 0 (0x900)
3
D5 Pulsausgang 1 (0x901)
4
D6 PWM-Ausgang 0 (0x902)
5
D7 PWM-Ausgang 0 (0x903)
6
STROBE als I/O nutzbar (0x808 Daten, 0x818 Datenrichtung)
7
BUSY als I/O nutzbar (0x809 Daten, 0x819 Datenrichtung)
Die PWM-Kanäle gehen, wie bei den anderen PWM Treibern von 0-255, die
Pulsausgänge von 0-559 bei einer Auflösung von 4µs.
Bildschirmausgabe entspricht dem Mode 0, allerdings sind nur 20 Zeilen
je
28 Zeichen sichtbar.
Jörg
Wie ich gelesen habe, gibt es bei AVRA einen neuen Projekt-Admin. Damit
sollte auch bald der auch ATmega644(P) von der offiziellen Version
unterstützt werden.
Da sich niemand über den Treiber beschwert hat nehme ich mal an dass er
so funktioniert. Das nächste Release wird wohl noch ein bisschen
brauchen, da insbesondre die Doku überarbeitet und erweitert werden
muss.
Das System unterstützt jetzt bis zu 8MB externes RAM am Parallelport,
realisiert habe ich aber nur ein 64K-Modul mit zwei SRAM und einem CPLD.
Letzteres ist notwendig, um bei nur 10 Leitungen (D0-D7, Strobe und
Busy) einen vernünftigen Speicherdurchsatz zu ermöglichen. Damit sind
dann sogar 320x240 Pixel in 16 Farben möglich, allerdings bei derzeit
saumäßiger Performance.
Momentan arbeite ich auch noch an einem 8080 Emulator, um vielleicht den
CP/M Emulator aus
Beitrag "CP/M auf ATmega88"
auch auf dem ChipBasic2 System ans Laufen zu bekommen. Hier schon mal
ein paar vielversprechende Benchmark-Resultate, die sich auf die im o.g.
Thread bezogene Tests beziehen. Getestet habe ich mit abgeschaltetem
Video (VID 0), im Videomode 0 (PAL) und in einem neuen monochromen
Textmode mit 24 Zeilen zu je 60 Zeichen.
Halloe.
Erstmal natürlich gratz zu so einem tollen Projekt. Wirklich mal was
nettes zum Nachbauen und experiementieren.
Nun aber auch gleich zu meinen "dummen" Frage. Hat von euch schonmal
jemand den UNI- Video zu SCART Adapter nachgebaut ? Ich wundere mich
gerade über die Belegung des Steckers. Wenn man in der Tabelle schaut
müssten die Pins 1-3 erst Blau, dann Rot und zum schluss auf Pin 3 grün
als Farbe haben. Wenn ich nun aber in der Wickipedie nach SCART suche,
finde ich für den Scart anschluss eine belegung, nach der die Kanäle Rot
und Grün in der Abbildung des Scart adapters vertauscht zu sein
scheinen.
Siehe hier
http://de.wikipedia.org/wiki/SCART
bzw. hier
http://www.jcwolfram.de/projekte/avr/chipbasic2/hard.php
Ist da evtl. in Wolframs abbildung ein Fehler drinn, oder irrt sich der
Wikipedia eintrag ?
Ich kann das ganze leider nicht mal so eben ausprobieren, ohne gleich ne
Stange Geld in die Hand zu nehmen. Ich habe aus den Vorlagen eine neue
Platine designt, auf der unter anderem die SCART- Buchse gleich mit
drauf ist. Und es wäre echt schade, wenn ich da eine Platine praktisch
umsonst mache nur weil die SCART- Belegung evtl. einen Fehler hat.
Freundliche Grüße
Frank
Halloe.
Um meinen Eigenentwurf mal auszuprobioeren habe ich den SCART-
Anschluss, einen BAS-Anschluss (Chinch) und den Keyboardanschluss mal
auf einer Laborkarte zum Test aufgebaut. Über den Chichausgang bekomme
ich auf einem alten 1084S Monitor ein sauberes Graustufenbild zu sehen.
Die BAS- Signalgenerierung scheint also zu klappen.
Wenn ich aber versuche die Schaltung an meinen Philips- Röhren-Fernseher
(Model 28PT440801) über SCART anzuschließen sehe ich zwar das er
versucht ein Farbsignal auszugeben. Jedoch scheint sich das TV nicht auf
das BAS- Signal zu synchronisieren. Es flackert alles wild hin un her.
Mein Controller ist ein 644 (nicht P) und die Softwareversion 1.30 hier
aus dem Forum.
Vorgegangen beim Nachbau bin ich praktisch 1:1 nach dem Schematas auf
der Homepage zum UNI-Video-Anschluss. Zum Test habe ich auch mal den Rot
und den Grünkanal getauscht, was jedoch für den SYNC keine verbesserung
brachte. Hatte die hoffnung das der Controller SYNC-ON-GREEN evtl. mit
unterstützt und nur wie oben beschrieben ein Fehler in der Beschreibung
des SCART-UNIVIDEO Adapters drinn ist. ( p.s. Wenn man das Schema des
UNI-Adapter mit dem Schema des direkten Scart anschlusses genau
vergleicht kommat man darauf das Rot und Grün in beiden Abbildungen
vertauscht sind.)
Habt ihr vieleicht einen Tip für mich, wie ich das ganze doch noch ans
laufen unter PHILIPS-RGB-SCART bekomme ?
Grüße
Frank
Hallo Frank,
im Schaltplan sind offenbar Ein- und Ausgänge vertauscht (das allerdings
konsequent ;) ) Lt. Wikipedia ist der FBAS-Ausgang Pin 19 (und nicht
20). Für RGB sind Ein- und Ausgang jeweils derselbe Pin, deswegen kommt
die Farbe wohl durch.
Also einmal Pin tauschen, gucken - und berichten.
Gruß, DetlevT
Detlev T. schrieb:> im Schaltplan sind offenbar Ein- und Ausgänge vertauscht (das allerdings> konsequent ;) ) Lt. Wikipedia ist der FBAS-Ausgang Pin 19 (und nicht> 20). Für RGB sind Ein- und Ausgang jeweils derselbe Pin, deswegen kommt> die Farbe wohl durch.
Hm, das klingt irgendwie komisch.
So wie ich das aus der WIKI beschreibung heraus gelesen habe ist der
PIN20 schon ok. Der AVR sendet über die RGB- Kanäle sie
"Farbinformationen" an den Fernseher. Da aber für RGB keine eigenen
SYNC- Kanäle vorhanden sind, zieht sich der Fernseher den SYNC aus dem
FBAS- Signal das man zusätzlich an PIN 20 anlegen muss.
Zitat aus dem Wiki:
1
Da auf den RGB-Leitungen 7, 11 und 15 keinerlei Impulse zur Bildsynchronisation mitgesendet werden
2
(außer beim sogenannten „Sync-on-Green“-Modus, der bei einigen Geräten aktiviert werden kann [s. Manual]),
3
bedient sich der Empfänger zur Synchronisation im RGB-Modus (also bei angelegter RGB-Schaltspannung (Pin 16))
4
des zusätzlich mitübertragenen Signals am Videoeingang (Pin 20).
5
6
In den meisten Fällen werden dort nicht nur die benötigten Synchronimpulse, sondern ein vollwertiges FBAS-Signal übertragen,
7
so dass auch Geräte, die kein RGB annehmen können (vor allem Videorecorder), problemlos arbeiten können.
Hier ist eine etwas andere Schaltung, bei der auch PIN20 als SYNC
eingang genutzt wird. Beitrag "einfache Grafikkarte mit 256x252 und 256 Farben für AVR"
In dieser Schaltung wird jedoch nicht das komplette FBAS- Signal erzeugt
sondern nur ein Composite-SYNC (HSYNC+YSYNC).
Meine aktuelle Vermutung liegt darin, das der Philips evtl. nicht
richtig synchronisiert, weil er im RGB- Modus entwerder den Sync auf dem
Grünen Kanal erwartet und FBAS gar nicht auswertet. Oder er verlangt im
RGB- Modus nach einem composite- Sync Signal auf dem FBAS- Eingang und
nicht das vollständige Signal. Mangels detailieter technischer
Anleitungen zu dem Fernseher konnte ich diese vermutungen jedoch noch
nicht bestätigen.
RGB an sich solte der Fernseher können, den mein DVB-T Receiver läuft
derzeit auf dem Fernseher im RGB- Modus. Und wenn ich den auf RGB
umstelle merkt man auch deutlich ne Bildverbesserung. Da sollte alos nix
defekt sein denke ich.
Ich deneke auch nicht, das es am Kabel liegt. Das hat alle 21 Pole
beschaltet und ist nicht übermäßg lang.
Grüße
Frank
Hallo.
Detlev's anmerkung war doch nicht so falsch, wie ich angenommen habe.
Ich habe sebst beim recherchieren gerade rasu bekommen, das ich wohl
evtl. einem kleinen Fehler zum opfer gefallen bin.
Die Beschreibungen auf Joergs Homepage gehen davon aus, das man sich ein
SCART- Kabel basteln möchte. Ich habe jedoch eine Scart- Buchse
angeschlossen und ein handelsübliches Scart Kabel daran angeschlossen.
Was ich bis eben nicht wusste ist, das bei diesen Kabeln üblicherweise
intern die Pins 19 und 20 über Kreuz verbunden sind. Daher kommen meine
SYNC- Signale wohl beim Fernseher am falschen PIN an.
Werde das heute abend mal Prüfen, aber ich denke das wird bei meinem
Aufbau das Problem gewesen sein.
Freundliche Grüße und Danke für den Tip
Frank
Frank Zoll schrieb:> Hallo.>> Detlev's anmerkung war doch nicht so falsch, wie ich angenommen habe.> Ich habe sebst beim recherchieren gerade rasu bekommen, das ich wohl> evtl. einem kleinen Fehler zum opfer gefallen bin.
Halloe.
Es war genau so wie gedacht. Wenn man nicht, wie von Jörg beschrieben,
ein Scart- Kabel machen möchte, sondern eine Scart Buchse, muss man das
BAS- Signal der Schaltung nicht auf PIN 20 sondern auf PIN 19 aufbringen
!
Nach einer kleinen Änderung an meiner Testplatine habe ich nun ein
einwandfreies Bild.
Freundliche Grüße
Frank
Er läuft.
Nachdem ich nun nicht nur die Videoleitungen auf die richtigen Pins der
SCART- Buchse gebracht habe, sondern auch noch die Audio Leitungen auf
die richtigen Pins umgelegt habe, läuft alles wie es sollte.
Anbei mal ein Foto meiner Version der Platine. Wie man sieht, habe ich
nicht nur die Scart und Chinch Buchsen für Video und Audio gleich mit
drauf gebracht, sondern das ganze auch noch ein klein wenig erweitert.
Zusätzlich zu finden sind.
- Ein kleines "Netzteil" für die 5 Volt Spannungsversorgung.
- Eine Echtzeituhr auf dem I2C Buss ( Chip ist der DS1307 )
- Ein einfacher Mono- NF- Verstärker für einen Kopfhöreranschluss.
Im momment schreibe ich herade ein kleines Demoprogramm für die
Echtzeituhr. Dabei hab ich jedoch noch ein Problem. Der Befehl ASK V,n
tut irgendwie nicht so, wie er sollte. Den Parameter n scheint er völlig
zu ignorieren. Egal was ich für n angebe er fängt immer an Arraypostion
0 an. Und nach der Anzeige der Abfragebox kommt bei mir immer ein
Syntaxfehler.
Was ich auch sehh merkwürdig finde ist das Verhalten bei Berechnungen.
B = B& $03 Funktioniert wie erwartet.
B = B & $03 Meldet einen Syntaxfehler.
B = B * 10 ebenso einen Syntaxfehler.
Ist das so normal für den Interpreter ?
Bei der von mir verwendeten Firmware handelt es sich um die Version 1.30
hier aus dem Forum. Die älteren Versionen hab ich noch nicth getestet,
wollte gleich mit der aktullen anfangen.
Freundliche Grüße
Frank
Hallo Frank,
mit der aktuellen Version (Hexfile im Anhang) sollten die Probleme
behoben sein. Das Ganze ist wohl bei der letzten "Code-Spar-Aktion"
passiert.
Eine neue Version ist eigentlich fertig, allerdings müssen noch ein paar
Dinge im Dateisystem an das Nachfolge-System angepasst werden. Wenn ich
nächste Woche aus dem Urlaub zurück bin gibt es auch das vollständige
Release mit Source.
Jörg
Ich habe die neue Version mal kurz angetestet. Der ASK- Befehl tut nun
wieder was er sollte, ohne Syntaxfehler. Auch einfache Rechenoperationen
laufen wieder. A = A * 10 geht nun wieder.
Es scheinen aber leider neue Folgefehler aufgetaucht zu sein.
Das Programm Racer bricht in Zeile 12 mit der Fehlermeldung "WRONG
EXPRESSION" ab.
12 Q=Q+1:IF Q=3 D=1-RND(3):Q=0
Das Programm Pong V0.2 bricht in Zeile 9 ebenfalls mit dem Fehler
"WWRONG EXPRESSION" ab.
09 IF (Y=0)#(Y=22= NO 20:F=F-F:y=Y+F
Ich würd sagen, schaus Dir einfach nach deinem Urlaub mal in Ruhe an,
das ganze hat ja keine Eile.
Freundliche Grüße
Frank
Hallo Frank,
das ist leider eine logische Folge, wenn Leerzeichen in Ausdrücken
erlaubt sind. Beim Pong kommt noch hinzu, dass der Fehler eigentlich in
Zeile 8 steckt, aber die fehlgeschlagene IF Anweisung den Zeiger schon
auf die nächste Zeile gesetzt hat. Abhilfe ist, nach dem IF folgenden
Ausdruck ein THEN oder einen Doppelpunkt zu setzen. Wenn der
Expressions-Parser nicht bei einem Leerzeichen abbricht, versucht er bei
1
IF C>10 C=10
aus dem gesamten nachfolgenden Text einen Wert zu berechnen, was
natürlich keinen Sinn ergibt. Erst ein neues Schlüsselwort, Doppelpunkt,
Komma, Semikolon oder das Zeilenende signalisieren das Ende des
Ausdrucks. Also einfach in Zeile 12 bzw. 8 nach dem Audruck in der IF
Anweisung einen Doppelpunkt setzen und die Programme sollten wieder
funktionieren.
Jörg
Da die Doku noch nicht ganz fertig ist, es gibt jetzt auch eine einfache
Suchfunktion im Editor, die man mit (linkes) CTRL+F aufrufen kann. Mit
ENTER gelangt man zur nächsten Fundstelle, mit ESC wird die Suche
abgebrochen.
Für das "Nachfolgeprojekt" existiert mittlerweise schon ein Prototyp.
Das Ein-Chip-Konzept habe ich dabei aufgeben müssen. Verbaut sind ein
ATMega1284P mit 20MHz, ein ATMega328P mit 16MHz und ein XC9572 CPLD.
Ausgabe kann wahlweise auf gängige monochrome 320x240 LCDs ohne eigenen
Controller (8 Graustufen, ca. 130Hz Frame-Frequenz), VGA und TV (8/16
Farben) erfolgen. Insgesamt wird es nur 4 Videomodi geben:
- 20 Zeilen a 40 Zeichen Text (Font 8x12 Pixel im RAM)
- 24 Zeilen a 40 Zeichen Text (Font 8x10 Pixel im RAM)
- 320x240 Grafikmodus, Vorder-/Hintergrundfarbe für jeweils 8x6 Pixel
- 160x120 Grafikmodus, 16 Farben je Pixel
Die rechnerisch ermittelte "effektive Taktfrequenz" liegt bei allen Modi
über 5 MHz, Sound und zusätzliche I/O werden auf den zweiten Controller
ausgelagert, der über I2C angeschlossen ist.
Jörg
Wieso nimmst du nicht einfach einen kleinen <10€ FPGA als Grafikchip?
Dann kann man DIL zwar gänzlich vergessen, dafür hat man aber nur noch
einen µc und kann gänzlich auf 3.3 Volt setzen.
Und das ganze könnte sogar Farbe per FBAS. ;)
Hallo Bernd,
die Gründe, es nicht so zu machen: Bei den meisten Dingen wo ich das
ChipBasic einsetze läuft das "Drumherum" auch mit 5V. Außerdem mache ich
meine Leiterplatten selbst und da ist zweilagig einfach ein Krampf. Es
gibt ja schon eine
Grafikkartenlösung mit FPGA, allerdings ist da auch nichts mit "<10€".
Da das Projekt Open Source ist, kann sich ja jeder das modifizieren wie
er möchte.
Die zuletzt von mir beschriebene Lösung habe ich zwar aufgebaut aber
mittlerweise wieder verworfen und favorisiere einen anderen Weg. Dazu
vielleicht später mehr.
Jörg
Hallo,
nach langer Zeit ist es endlich soweit, das nächste offizielle Release
ist da:
http://www.jcwolfram.de/projekte/avr/chipbasic2/main.php
Neben Bugfixes, neuen Funktionen und Treibern habe ich die
Schnittstellen für Bibliotheken und Treiber angepasst, so können jetzt
zuätzliches RAM sowie eigene BASIC Befehlserweiterungen eingebunden
werden.
Als Binär-Programm ist u.a. auch ein Chip8-Interpreter mit dabei.
# Die Shift-Befehle teilweise durch Shift-Operatoren (<<, >>) ersetzt
# XOR-Operator ^
# Unterstützung von bis zu 64 KBytes externen Speicher am Parallelport
# bei den PWM-Treibern lassen sich BUSY und STROBE als I/O nutzen
# neue Videotreiber
# Monitor aus allen Videomodi heraus aufrufbar (eingeschränkt)
# Erweiterbarkeit des BASIC um zusätzliche Befehle
# erweitertes ADC-Setting über den Parameterbereich 0x100 ...0x1ff
# erweitertes Bitraten-Setting für die zweite serielle Schnittstelle
# Korrekturen und Erweiterungen in der Dokumentation
# Beispiel-Programme überarbeitet
# erweitertes API
Bei den UI-Befehlen (ALERT,ASK) hat sich die Syntax etwas geändert, die
Beispielprogramme sind entsprechend angepasst.
Jörg
Leider sind mir im Build-Script für die Dokumentation und im
Upload-Script je ein Fehler unterlaufen. Zum Ersten war beim Punkt
"Library" die Fixlib zweimal hintereinander vertreten und zum Zweiten
wurden die Bilder auf der Webseite nicht aktualisiert.
Da ich aus Lizenzgründen keine Chip8-Programme mit in die Packages
aufnehmen kann, hier schon mal das CAR-Programm zum Screenshot aus dem
vorigen Post. Benötigt werden:
- Das aktuelle System v1.36
- Der Chip8-Interpreter auf Programmplatz 2
- ein IRAM2-Treiber auf Programmplatz 8
Gesteuert wird mit den Cursor-Tasten.
Jörg
@sepp
Was sind für Dich "normale" LCD Displays? Für Text- und einfache
Grafikdisplays (128x64 und 320x240) gibt es ja bereits Treiber. Wenn Du
Laptop-Displays meinst, da ist der AVR einfach überfordert.
Der "Nachfolger" (so er denn noch veröffentlicht wird) kann auch VGA und
besteht aus einem kleinen Daughterboard mit ATMega1284P und einem CPLD
und wird einfach in den Sockel des ChipBasic Computers gesteckt.
Das Thema SD-Karte ist zwar interessant, aber ich sehe keinen besonderen
Vorteil darin. Vom Preis her ist ein Dataflash Baustein doch ein Stück
günstiger. Außerdem könnte man die Karte nur schwerlich zum
Datenaustausch mit dem PC nutzen, denn für ein FAT Dateisystem sind die
inneren Strukturen des ChipBasic Computers nicht ausgelegt. Über eine
BASIC-Erweiterung in einer Bibliothek könnte man aber das zumindest für
Userdaten nachrüsten, sofern knapp 3K ausreichen und jemand sich findet,
der das macht.
Jörg
Joerg Wolfram schrieb:> Was sind für Dich "normale" LCD Displays? Für Text- und einfache> Grafikdisplays (128x64 und 320x240) gibt es ja bereits Treiber.
Ja, ich meinte die 0815 Billig-GLCD.
Dass es dafür Treiber gibt hatte ich überlesen.
Joerg Wolfram schrieb:> Das Thema SD-Karte ist zwar interessant, aber ich sehe keinen besonderen> Vorteil darin. Vom Preis her ist ein Dataflash Baustein doch ein Stück> günstiger.
Wenn man Euro pro Byte vergleicht, sind normalerweise die SD-Karten
günstiger und vor allem leichter zu bekommen.
Man kann aber auch mit einem AVR einen kleinen SD-UART, SD-I2C oder
SD-SPI Adapter bauen.
Was mich interesiert ist, inwieweit die Programme/ Software vom
AVR-ChipBasic2 und AVR-Handheld kompatibel sind.
Die Treiber überarbeite ich gerade, damit man noch zusätzlich Tasten
anschließen kann, ohne die restlichen 4 Portpins benutzen zu müssen. Aus
diesem Grund wird es auch einen neuen (zusätzlichen) Treiber für die
128x64 GLCD geben, der auch nur die oberen 4 Pins von Port A benutzt.
Mit den Euro pro Byte ist die SD-Karte auf jeden Fall günstiger, da
Massenprodukt. Allerdings könnte mein Dateisystem nur einen Bruchteil
der verfügbaren Kapazität nutzen. Aber als Option werde ich es für einen
eventuellen Nachfolger in Betracht ziehen, wobei ich am Dateisystem
selbst nichts ändern werde sondern nur das physische Medium wählbar. Für
einen Umbau der internen Strukturen auf MINIX/EXT/FAT/sonstnochwas sehe
ich derzeit keinen Grund, der den Aufwand rechtfertigen würde.
Un nun zum Handheld. Das Teil ist weder zum aktuellen BASIC kompatibel
noch wird es weiterentwickelt. Damit ist das Thema aber noch nicht
erledigt. Ich habe eine Bibliothek in Arbeit, mit der man mit dem
"normalen" CB2 einen in etwa vergleichbaren Handheld bauen kann. Wobei
die Programme auch auf dem ChipBasic2 laufen können. Aber das braucht
noch etwas...
Joerg Wolfram schrieb:> Die Treiber überarbeite ich gerade, damit man noch zusätzlich Tasten> anschließen kann, ohne die restlichen 4 Portpins benutzen zu müssen. Aus> diesem Grund wird es auch einen neuen (zusätzlichen) Treiber für die> 128x64 GLCD geben, der auch nur die oberen 4 Pins von Port A benutzt.
Dass sind gute Informationen
Joerg Wolfram schrieb:> Mit den Euro pro Byte ist die SD-Karte auf jeden Fall günstiger, da> Massenprodukt. Allerdings könnte mein Dateisystem nur einen Bruchteil> der verfügbaren Kapazität nutzen. Aber als Option werde ich es für einen> eventuellen Nachfolger in Betracht ziehen, wobei ich am Dateisystem> selbst nichts ändern werde sondern nur das physische Medium wählbar. Für> einen Umbau der internen Strukturen auf MINIX/EXT/FAT/sonstnochwas sehe> ich derzeit keinen Grund, der den Aufwand rechtfertigen würde.
Wie währe es, wenn man die SD-Karte auf dem PC "formatiert"?
Also Ordner / Dateien mit einer festen Größe an einer bestimmten
Position im Speicher anlegt und dann mit dem AVR direkt auf die SD Karte
schreibt.
Somit hätte man einen Speicher für extrem umfangreiche Programme bzw.
viele kleine Programme zur Verfügung ohne sich mit dem FAT-Dateisystem
befassen zu müssen. Und zusätzlich kann man die Karte direkt am PC
verwenden.
Oder müsste man für soetwas zu viel am System ändern?
Joerg Wolfram schrieb:> Un nun zum Handheld. Das Teil ist weder zum aktuellen BASIC kompatibel> noch wird es weiterentwickelt. Damit ist das Thema aber noch nicht> erledigt. Ich habe eine Bibliothek in Arbeit, mit der man mit dem> "normalen" CB2 einen in etwa vergleichbaren Handheld bauen kann. Wobei> die Programme auch auf dem ChipBasic2 laufen können. Aber das braucht> noch etwas...
Genau sowas suche ich schon die ganze Zeit.
Denn ich brauche einen kleinen Handheld um unterwegs die verschiedensten
Bussysteme / Schnittstellen überprüfen und ansprechen zu können.
Möglich wäre das schon, allerdings sehr aufwändig. Dazu könnte man 256
Dateien mit der maximalen Dateigröße von 128 +1 Pages anlegen, wobei man
von den 512 Bytes einer SD-Page nur 256 nutzen kann. Einfach deswegen
weil die interne Pagegröße auf 256 Bytes festgelegt ist und auch FREAD
und FWRITE damit arbeiten. Lesen ginge ja noch, aber zum Schreiben
müsste man zumindest eine Hälfte der zu schreibenden 512-Bytes Page
irgendwo zwischenspeichern. Da aber keine 256 Bytes mehr frei sind,
müsste man z.B. temporär Teile des Bildschirmspeichers nutzen. Oder man
nimmt halt eine Fragmentierung auf der SD-Karte in Kauf.
Ein weiteres Beispiel wäre z.B. das Inhaltsverzeichnis. So etwas gibt es
beim ChipBasic Dateisystem überhaupt nicht. Der Dateiname mit 12 Zeichen
steht am Anfang der Datei. Alles in Allem ein großer Aufwand mit
fraglichem Nutzen (zumindest für mich). Für USER-Dateien steht, wie oben
schon angedeutet, die Möglichkeit einer Realisierung über eine
Binärbibliothek offen.
Jörg
In der nächsten Version werden die grundlegenden Funktionen des
Dateisystems (Page lesen/schreiben...) auch in Bibliotheken auslagerbar
sein. An der Struktur des Dateisystems selbst wird es allerdings keine
Änderungen geben, unter anderem wegen der Kompatibilität zu den
bestehenden Systemen, die teilweise den DataFlash aufgelötet haben. Dann
könnte man das Dateisystem z.B. in eine große Datei auf einer wie auch
immer formatierten SD-Karte packen. Bei 256 Dateien a max. 32KBytes und
nur halber Ausnutzung der SD-Pages käme man dann auf 32MByte/Datei.
Über eine Art "Dateimanager", der die Pages wieder richtig zusammensetzt
könnte man dann auch auf dem PC recht bequem mit den Daten arbeiten. Bei
dem momentan recht niedigem Interesse an dem Projekt halte ich es aber
eher für unwahrscheinlich, dass jemand eine ChipBasic Bibliothek und ein
passendes Programm für Windows schreibt.
Damit man nicht immer umstecken muss und auch noch andere
SPI-Gerätschaften anschliessen kann, wird es einen "SPI-Extender" mit
maximal 8 Select-Leitungen geben, den man auch aus dem BASIC heraus
ansprechen kann. Damit wären dann auch z.B. CAN oder Ethernet möglich.
Dafür wird aber der Bootloader rausfliegen, aber eventuell bekomme ich
den noch in das Loader-Programm wieder mit hinein. Mit abgeschaltetem
Video-Interrupt sollten dann auch höhere Bitraten für das System-Update
möglich sein.
Jörg
Dass ist wirklich interessant.
Wird sich etwas an der maximalen UART-Geschwindigkeit ändern?
Denn die meißten Module, die ich mit dem AVR-ChipBasic2 auswerten würde,
haben eine fixe Bitrate von 9600bps
Bei "System-UART" lässt sich die Geschwindigkeit nicht erhöhen, da als
Zeitbasis die Zeilenfrequenz dient. Allerdings kann man den UART1 des
Mega644P verwenden (EBAUD,ESPUT,ESGET). Dafür muss aber der RX-Pin der
System-Schnittstelle anstelle ursprünglich PD3 auf PD1 gelegt werden
(sowohl physisch als auch in der Config-Page).
Jörg
Hallo,
nach längerer Ruhepause gibt es mal wieder ein neues Update. Den
angekündigten "SPI-Extender" habe ich letztendlich nicht mehr
realisiert, die Schnittstelle für andere Dateisysteme ist vorhanden aber
nur im Sourcecode dokumentiert.
Neben Aufräumarbeiten bei den Treibern gibt es eine neue Bibliothek, mit
der auf recht einfache Weise z.B. ein R-D-C-L Meter aufgebaut werden
kann.
Ein 8080 Emulator ist auch dabei, allerdings noch nicht vollständig
getestet.
Da Berlios am Ende des Jahres schließt, wird es in Zukunft nur noch
Downloads über meine Homepage geben.
http://www.jcwolfram.de/projekte/avr/chipbasic2/main.php
Viel Spaß damit,
Jörg
Hallo Jörg,
Ich habe Deinen AVR-Basic_Computer nachgebaut.
Das ist ein tolles Projekt. Danke.
Es läuft nur die serielle Schnittstelle nicht. Es kommen Zeichen an,
aber nicht lesbar. Einstellung:
2400 8N2.
Ist auch eine SD-Karte als Datenspeicher vorgesehen ?
Gruß
Manfred
Hallo Manfred,
schau mal, ob bei den Einstellungen (Config-Menü) die Serielle
Schnittstelle auf "simple" steht wenn Du die angegebene Schaltung
benutzt. Die Einstellung "standard" ist für den Anschluß vom MAX232 oder
USB-TTL Wandlern gedacht.
SD-Karte ist nicht vorgesehen, allerdings gibt es intern Schnittstellen
um eigene (ladbare) Dateisystemtreiber zu einzubinden. Ob sich da aber
jemals jemand die Mühe macht, wage ich zu bezweifeln.
Gruß Jörg
Im Config-Menü muss die I2C Adresse des EEPROMS eingestellt werden, im
BASIC geht es dann mit XPOKE / XPEEK() für externe und EPOKE / EPEEK()
für das interne EEPROM
Gruß Jörg
Hallo Jörg,
Ich habe die Comm-Schnittstelle noch einmal auf verschiedenen PC
getestet. Com mit USB-Seriall_Adapter und richtige Com. Auch mal andere
Einstellungen getestet. Es kommt immer beim Starten des Serial-Loaders
der selbe String. siehe Bild. Ich denke mit den Zeiten stimm etwas
nicht.
Kannst Du bitte noch mal schauen. Oder hast Du ein Testprogramm ?
Gruß
Manfred
Da sich wahrscheinlich niemand daran gemacht hat oder machen wird, ein
Dateisystem für SD-Karten für den BASIC-Computer zu entwickeln (ich
sowieso nicht), werde ich in der nächsten Version die Schnittstelle aus
Platzgründen wieder entfernen. Dafür wird es dann einen SCOMM (analog zu
ICOMM) Befehl geben.
Gruß Jörg
Hallo, welche Schnittstelle meinst du jetzt ?
Frage: Kann man die ASM nicht so umgestalten , das sie auch mit dem
avrasm32.exe funktionieren ? Wäre eine gross Hilfe.
Die ZX81-ASM funktionieren nach Umgestaltung mit dem avrasm32.exe, dank
der Hilfereichen arbeit.
Danke.
gruss
Die Schnittstelle ist nur im Code (spärlich) dokumentiert, in der Datei
libdef.asm sind die Eintrittspunkte im Treiber definiert, die Aufrufe
finden in der Datei filesys.asm statt. Damit könnte man einen ladbaren
Dateisystemtreiber realisieren, den internen Dataflash Treiber zu
ersetzen ist nicht vorgesehen.
Eine Umgestaltung der Sourcen kommt für mich nicht in Frage, durch
Verzicht auf die ganzen Makro- und anderen Fähigkeiten von Avra würde
ich mir damit ja selbst ins Bein schießen. Beim AX81 musste ich schon
eine ganze Menge umschreiben, damit der veröffentlichte Code auch auf
einem ungepatchten AVRA läuft da ich für mich den Code u.a. insoweit
modifiziert habe, dass Labels in Makros auch ausserhalb sichtbar sind.
Ich kann aber am WE eine RAWSOURCE Datei erstellen, allerdings hat sich
dort inzwischen das Format der Kommentare ein bisschen geändert.
Gruß Jörg
Hallo, habe heute das Projekt gesehen, echt interessantes "Teil", gibt
es vieleicht eine zusammengeschriebene Teileliste, oder gar die Reichelt
Bestellnummern dazu? Gruß Andreas
Von meiner Seite her gibt es so etwas nicht, denn die müsste ich von
Hand schreiben. Das liegt auch an meinem "Workflow", der sich von dem
Anderer wahrscheinlich stark unterscheinden wird:
- Idee, theoretische Vorüberlegungen
- Software-Grobentwurf
- Pinbelegung vom Controller ausdrucken und Funtionen skizzieren
- Leiterplattenlayout mit GEDA-PCB "malen" oder vorhandene BG nutzen
- Baugruppe au- bzw. umfbauen, ggf. Layout korrigieren
- Software fertigstellen
- Stromlaufplan mittels XFig zeichnen
Aber dafür diese oder nächste Woche ein Bugfix-Update.
Gruß Jörg
So, die aktuelle Version (1.42) steht zum Download auf meiner Seite
bereit. Wichtig ist bei Binärprogrammen, dass sie gegen das aktuelle API
"gelinkt" sein müssen, andernfalls kann es Abstürzen kommen. Das
betrifft insbesondre Treiber und Bibliotheken, da sich die Header-Flags
geändert haben.
Gruß Jörg
Es gibt wieder einmal ein neues Release, da sich in die letzte Version
ein Bug eingeschlichen hat.
http://www.jcwolfram.de/projekte/avr/chipbasic2/main.php
Und zwar funktionierte der DIR Befehl nicht mehr und hat mit einem
Syntax Error abgebrochen. Ursache war die fehlerhafte Abfrage, ob der
Port durch einen Treiber belegt ist. In der Abfrageroutinen wurde der
Programmpointer (Z-Register) benutzt und am Ende nicht
wiederhergestellt. Außerdem wird der I/O bzw. Druckerport bei einem
Neustart jetzt auf INPUT mit PullUp zurückgestellt.
Jörg
Hallo Jörg,
ich plane gerade ein kleines Redesign meiner letzten Version deines
super Projektes. Nun würde ich gern die 64K Ram Erwieterung gleich mit
auf meine neue Paltine bauen. Ich konnte aber leider am Schema der
Erweiterung nicht erkennen, welche PIN's des CPLD's mit welchen
Busleitungen zu versehen sind. Auch würde ich gern den Ramtyp ändern.
Ich habe hier noch eine ganze Menge an alten Cache- Bausteinen mit
10-15ns und >64KB pro Stück liegen, da würde ich gern einen von nehmen
statt wie in deinem Vorschlag 2 kleine zu verbauen.
Könntest Du hier die Xilinx- Sourcefiles und eine Liste der
Pinbelegungen zur Verfügung stellen, so das ich mir daraus eine neue
RAM- Erweiterung zusammen stellen kann ?
Ich stelle mein neues Board mit KiCad zusammen und lasse das dann
günstig in China fertigen. Bei interesse würde ich die KiCad Sources
hier zur auch wieder zur Verfügung stellen.
Freundliche Grüße
Frank
Hallo Frank,
in der aktuellen Version 1.43 sind die Sourcen leider nicht mit dabei,
da ich sie im Gegensatz zu den AVR-Sourcen "von Hand" mit in die Archive
packen muss (und das bei der 1.43er wohl vergessen habe). Aber in der
1.42 sind sie mit drin und haben sich auch seitdem nicht geändert.
Gruß Jörg
Ah, vielen Dank.
Ich habe die Sourcen für den CPLD gestern gleich gefunden und mein
Layout entsprechend anpassen können.
Im moment denke ich gerade darüber nach, wie man den Dataflash, einen
SD-Card-Port und ggf. auch noch einen Ethernetport mit an den SPI- Port
anschließen könnte, ohne die Kompatibilität zu deinem Layout, den
bestehenden Programmen und den ISP- Anschluss zu verlieren.
Eine Idee wäres es die verbleibenden Anschlüsse des CPLD's evtl. als
"Chipselekt"- Signale zu missbrauchen und den CPLD- Source entsprechend
anzupassen. Beim ersten Signal an den CPLD wo nur Read/Write
umgeschaltet wird, könnte man die noch ungenutzten Bit's evtl. für die
Umschaltung der Pheripherie hernehmen. Aber so ganz zu frieden mit dem
ganzen bin ich noch nicht, mal sehn ob mir noch was besseres einfällt.
Die Platine die ich hier gerad bastle hat ca. 20*20cm. Da möchte ich
möglichst viel an Extras und kleinen Gimmicks gleich mit drauf packen.
An sich verschwende ich derzeit schon eine Menge an platz, weil ich
alles sehr Übersichtlich in "Funktionsblöcken" anordne und auf der
Paltine auch gleich schön mit gedruckten Rahmen und kurzen Infotexten
versehe. Das ist aber auch absicht, weil die Platinen die ich mache als
Experiementier und Lehrnplatform für ein paar Kinder gedacht sind. Denn
ich finde dieses einfache Design einfach ideal geeignet, um das
Programmieren und das Experiementieren mit Elektronik zu vermitteln.
Hier braucht man nicht erst hunderte Zeilen von C oder Java- Code zu
schreiben nur um ein leeres Fenster zu öffnen. Ein paar einfache Basic-
Kommandos reichen und man hat sehr schnell ein sichtbares
"Erfolgserlebniss".
Grüße
Frank
Ich hatte in einer Testversion einen SPI-Selektor drin, aber dann aus
Platzgründen wieder entfernt. Konkret war das ein Schieberegister,
welches bei /CS=1 (SPI unselektiert) die Daten von MOSI seriell empfängt
und dann mittels /CS am /OE und Pull-Ups einen von 8 SPI-Slaves
adressiert. Dadurch war die Lösung auch zur bestehenden Hardware
kompatibel. Wenn Bedarf besteht, könnte ich versuchen, das wieder (etwas
platzsparender) zu implementieren.
Jörg
Eine genrelle Lösung, für einen SPI- Select welcher auch ohne die Ram-
Erweiterung funktioniert währe natürlich genial. Wenn das noch in den
644er zu quetschen ist ohne das dafür wichtige andere Dinge rausfliegen
würden, dann währe das zu bevorzugen.
Ich habe auch schon darüber nachgegrübelt, selber den Versuch zu starten
deine Sourcecodes an den Atmega1284 anzupassen. Selbiger ist ja
mitlerweile sehr einfach und günstig zu beziehen. Das würde die Enge
beim Hauptspeicher und beim Flashspeicher deutlich reduzieren. Dann
hätten ggf. auch die Routinen für SD_Card und Ethernet-Port direkt als
Basic-Erweiterung im Kerninterpreter platz und belegen dann keinen der 8
wertvollen Programmspeicherblöcke. Auch die 512 Byte Pufferblöcke für
den Dateizugriff auf FAT- Formatierte SD-Cards währen dann besser
machbar.
Grüße
Frank
Ich hatte auch schon einmal mit einem "Nachfolgeprojekt" mit dem
Mega1284P angefangen, es gibt sogar einen Prototypen. Und zwar in Form
eines DIL-Zwischenadapters mit einem XC9536. Damit gingen dann 40x24
Zeichen / 320x240 und 160x120 sowohl bei TV ais auch VGA ohne die
(ChipBasic-) Hardware zu ändern. Das habe ich aber erstmal eingemottet,
da ich keinen großen Bedarf für eine derartige Lösung sehe. Eine
Bibliothek für den ENC (ARP, ICMP und UDP) hatte ich auch schon einmal
angefangen, aber in ASM ist das nicht unbedingt eine sehr erquickliche
Aufgabe. Gleiches gilt für SD-Karten, wenn FAT mit ins Spiel kommt... da
ist mir meine Zeit momentan zu schade dafür.
Jörg
Vom Code her habe ich die Multiselect-Erweiterung wieder eingebaut, wenn
ich dazukomme mache ich am WE einen Probeaufbau um die Funktion zu
testen. Insgesamt kann man dann 8 SPI-Geräte anschließen wobei eines für
den Dataflash reserviert sein wird. Ohne Erweiterung wird immer das
angeschlossene Gerät selektiert, dadurch sollte es keine
Kompatibilitätsprobleme geben. Der SPISEL Befehl bekommt aber eine etwas
andere Funktion, was den Parameter anbetrifft.
Jörg
Patrick M. schrieb:> Hallo Jörg ,ich hätte da noch ma eine Frage,welche Bezeichnung die> beiden Sram Bausteine genau haben. ansonsten echt tolles Projekt!>> Gruss Patrick
Hm, da müssten wenn ich mich nicht irre all die alten Cache Bausteine
aus der 386er/486er Area laufen. Alles was in der Richtung 32KB mit 8
Datenleitungen und ca. 10-15ns geht müsste laufen.
Beispiele aus meiner "Sammlung alter Cache Chips mit 32KB*8" wären:
UM61256AK-15
MS62256H-15NC
EM51256-15PL
W24257AK-15
AS7C256-15PC von Alliance
Ich selbst würde es als erstes mit dem UM61256AK-15 probieren. Den hab
ich schon erfolgreich eingesetzt :-)
Grüße
Frank
Ich habe in den letzten Tagen weiter an meiner "großen" Experimentiert
und Lehrnversion der Platine gearbeitet. Das ganze sieht noch recht
Unfertig aus. Ist es auch :-) Im moment fehlt mir noch der Part mit dem
SPI- Selektor. Auch will ich den Dataflash mit auf die Platine bringen
und wenn ichs noch drauf kriege kommt auch noch ein einfacher
Ethernet-Port mit drauf.
Was bisher schon drauf ist:
- Alles was Joergs Grundplatine auch drauf hat :-)
- Ein 5 Volt und ein 3,3 Volt Low-Drop Linearregler mit genügend Power
für kleine Addons.
- Die 64KB Ram Erweiterung
- Scart Buchse und Chinc- Buchsen für Video und Audio
- Ein einfacher NF- Verstärker für Kopfhörer.
- 2 Seriele Ports über MAX232 Treiberchip.
- Wahlweise kann der 2. serielle Port welcher vom 644P in Hardware
unterstützt wird auf einen FT232RL- USB Anschluss umgejumpert werden.
- Ein SD- Kartensockel am SPI-Bus ( Chipselekt fehlt noch )
- Ein 8 BIT IO Chip (PCF8574) am I2C Bus.
- Eine Bateriegepufferte Echtzeituhr am I2C Bus. (DS1307).
Ich hab einfach mal ein kleines Bild angehängt, das das ungefähre Layout
wiedergibt. Das ganze wird ca. 20*20cm groß werden.
Wenn ich das Board fertig Aufgeräumt und Layoutet habe, werde ich es
wohl bei ITEAD-Studio in Auftrag geben. In der Größe bekommt man dort 5
Stück für knapp 38 Dollar. ( Zuzüglich Versand und Zollgebüren! ).
Freundliche Grüße
Frank
Hallo Jörg wollte noch ein Bug melden,und zwar hängt CBTerm mini
(V0.10 ),(Chipbasic version 1.43) sich manchmal auf,besonders im
dialog-modus wenn man den Text mit CLEAR löscht
sind keine Eingaben mehr möglich,so das das System komplett neu
gestartet werden muss.
Gruss Patrick
Ich habe jetzt die Version 1.44 released, die das SPI Multiselect
unterstützt. Ausserdem habe ich bei der 1.43er Version die fehlenden
Sourcen hinzugefügt.
http://www.jcwolfram.de/downloads/main.php#chipbasic2
Im Moment bin ich mir nicht sicher, ob ich die "nächste Generation" noch
in Angriff nehme. Das Daughterboard mit Mega1284P und XC9536 habe ich
bereits gebaut und getestet, es routet auch gleich die serielle
Schnittstelle des Chipbasic Boards auf den UART1, damit sind höhere
Baudraten möglich und es werden Takte gespart. Bis auf die 16-Farb
Erweiterung und die Nutzung des 2.UART ist es mit allen anderen
Hardware-Erweiterungen kompatibel, die Software müsste aber in großen
Teilen neu geschrieben werden.
Jörg
cooooool Jörg! Danke!!
Kannst du das mit dem Multiselect noch dokumentieren?
das wäre super!
Ne andere Frage:
Warum kann man Programme nicht direkt vom Dataflash laden? Müssen diese
technisch erst in den Controller geladen werden?
Gruß
Dominik
Toll,
hab mir grad den 2. Computer aufgebaut auf Lochraster!
Komischerweise ist die Farbe Cyan nun Lila, Grün ist Rot, etc.! Habe
auch keinen Sound!!
Woran kann das liegen?
Scart wurde genauso angeschlossen wie beim ersten Computer! Und da hat
alles funktioniert! :(
Da ist bei Dir sicher rot mit grün vertauscht:
CYAN = blau + grün
MAGENTA = blau + rot
Beim Sound müsste man einfach mal an PD7 messen, ob das PWM Signal
anliegt. Mit einem Multiimeter sollten am Pin ca. 2,5V anliegen (50%
PWM). Wenn das OK ist, würde ich weiter die Verdrahtung überprüfen.
Jörg
Hi Jörg,
ok... da muss ich mal schauen!
habe die Leitungen alle überprüft bis zum Scart... eventuell hab ich nen
Fehler bei den Widerständen gemacht!
Werde das mal prüfen!
Joar mit dem Sound ist schon kurios!
Werde das auch mal prüfen!
Oh man!
Wenn man dank 4 Kinder beim löten keine Ruhe hat!
die Verbindung der Soundleitung war nicht geschlossen!
Sound müsste demnach jetzt funktionieren!
Zu den farben:
Habe wohl den 6K8 Widerstand von E nach A der farberweiterung
vergessen... kann es auch daran liegen???
gruß
Dominik
Ich wieder...
also, Jörg du hattest Recht.. rot und grün war vertauscht! Komisch, ich
war der meinung alles wäre richtig angeklemmt.
So, nächste Problem: Der DataFlash!
Gestern habe ich alle meine Spiele auf den Flash gesichert. Eben guck
ich nach, alles ok... das nächste spiel abgespeichert und die Meldung
kommnt: "Data flash not formated"
????
Ich kann nicht mehr zugreifen!! Er erkennt ihn zwar aber meint er wäre
nicht formatiert. Ok, formatiere ich dann aber.... das problem
bleibt!!!!!!
Er wird erkannt, aber ich kann nicht mehr drauf zugreifen! Was ist das??
HILFE... alle spiele weg :(((
Hallo KILO hast du bei deinem Dataflash die Stromversorgung stabil, und
welche version hast du drauf? ,hatte anfangs änliche Probleme,da ich den
Abblockkondensator vergessen hatte.
Gruss Patrick
Hab gerade mein chipbasic2 auf die version 1.44 geupdatet!
Hab Das selbe Problem wie Kilo,
das das dateisystem auf dem Dataflash beim speichern Zerstört wird.
da hat die 1.44 er wohl noch einen schweren Bug drin.
Patrick
Wenn Programme verloren gegangen sind, tut es mir leid aber so etwas
kann schon mal passieren. Auf meinem 1.44er Testsystem funktioniert es,
wenn ich aber das Release draufspiele, habe ich das gleiche Problem.
Also muss ich mal schauen, bis zu welcher Version es ging und mir dann
die Änderungen auflisten. Die 1.44 ist ja nur die "Major-Number", danach
geht es intern mit Buchstaben weiter. Zwischen Programm Schreiben und
Testen liegen schonmal ein paar Tage, da die meiste "Entwicklung"
inzwischen morgens und abends in der S-Bahn stattfindet. Und dann dauert
es wieder, bis die Doku überarbeitet und das Release zusammengestellt
wird.
Inzwischen muss man halt mit der Version 1.43 vorlieb nehmen, denn ab
dem nächsten Release will ich auch die Unterversionen mit anzeigen
lassen um so schneller Fehler zu finden. Und das kann halt etwas
dauern...
Jörg
Hallo zusammen,
also, hab jetzt die 1.43 Version wieder drauf. Im Moment läuft alles
stabil! Hoffe das bleibt auch so, ist echt ärgerlich wenn plötzlich
alles weg ist!
Naja Jörg, ist nicht schlimm!
Kenne sowas noch aus alten C64 Zeiten... da haste grad 1000 Zeilen
abgetippt und dann fällt der Strom aus! :)))
Werde halt alles nochmal neu programmieren! Hab viele alte Retro Games
portiert... naja... auf ein neues!
PS: Danke nochmal Jörg das du weiter machst mit dem Projekt! Meine Jungs
sind total begeistert was alles möglich ist!
PPS: Ob du nochmal darüber nachdenken wirst Grafik und Sound auszulagern
in einem 2. oder 3. MCU?
Wahrscheinlich hab ich schon den "Übeltäter" gefunden, beim Senden der
SPI-Selektion wird "tempreg1" nicht gesichert. Aber das muss ich noch
etwas ausgiebiger testen.
Zum Auslagern gibt es zumindest für Grafik schon ein (noch
unveröffentlichtes) Projekt. Mit einem Mega644(20MHz) + 128K SRAM +
74CHT374 + ein paar Widerständen geht 320x240 bei 256 Farben auf TV oder
VGA. Auch ein Modus mit 160x120 und 4 Screens von denen man 2 als
Z-Buffer nutzen kann ist schon integriert. Angesteuert wird seriell mit
max. 250Kbit/s, jede Menge 2D und auch einige 3D-Funktionen sind schon
integriert. Aber das ruht momentan...
Jörg
ohhh Jörg,
2D, 3D, VGA, 256 farben.... das ist wie Honig in meinen Ohren :)))
Wow, hoffentlich ruht es nicht sooo lange!! :))
Ähm, aber:
Wenn ich den SRAM nutze, dann ist doch der Parallelport für andere
Anwendungen nicht mehr nutzbar, richtig??
Das wäre doof, da ich an diesem port mein gamepad angeschlossen habe! :(
Somit kann ich michnur entscheiden zwischen:
Spiele mit Tastatur spielen oder mit gamepad aber dafür gibts kein SRAM
und anscheinend auch nicht die Grafikauslagerungen welche noch ruht!
ahhhh... teufelskreis!
Das hast Du jetzt nicht richtig verstanden. Die "Grafikkarte" ist ein
standalone Projekt bei dem der AVR einzig und allein für die Grafik
verantwortlich ist. Angeschlossen wird er an den UART des
"Zentralprozessors". Das sollte mal ein modulares Nachfolgekonzept zum
ChipBasic werden, mit getrennten Controllern für Grafik, Sound, Netzwerk
und Massenspeicher. Zentralprozessor mit RAM hätte einen eigenen
Steckplatz und wäre somit beliebig austauschbar. Letztendlich habe ich
das Projekt aber aus verschiedenen Gründen (z.B. Zeit) wieder verworfen.
Jörg
Ah ok! Jetzt hab ich es verstanden!
Schade, ich glaube damit wäre nicht nur ich glücklich gewesen! :)
Besteht die Möglichkeit mit einem am Parallelport angeschlossenem
"Joystick" sich durch das menü zu klicken?
Somit bräuchte man die Tastatur nur zum editieren von programmen!
Das soll jetzt kein Aufruf werden eine Spielekonsole zu entwickeln...
Hi Jörg,
wie sind im Assembler die Farben definiert?
Warum hast du einmal 0x0c für Gelb auf Schwarz benutzt und danach kommt
0x60 für schwarz auf gelb? Schwarz ist die 0 aber warum ist gelb einmal
c und einmal 6?
Blicke da nicht ganz durch!
Hi patrick,
muss wie gesagt erstmal alles neu schreiben, ging ja alles verloren beim
DFLASH Problem!
Aber ich hatte:
- PONG one (Einzelspieler Pong gegen den AVR mit Auswahl von 3
Schwierigkeitsstufen)
- SPACE INVADERS
- PACMAN (Jörgs Beispiel auf 2 Programme verteilt, mehr "Levels")
- TENNIS
- SQUASH
- ASTEROIDS
- SUBMARINE
- SNAKE (Beispiel von Klaus, jedoch mehr levels)
Alle Spiele waren mit Startbildschirm (Credits), Auswahloption für
levels, Schwierigkeit, Player, spielbar mit umgebauten SNES Gamepad,
etc. sowie der Highscore Speicherung im externen Eeprom
Gruß
Dominik
Hi Jörg,
ONSYNC steht ja außerhalb einer Programmschleife, richtig?
So... wenn ich jetzt mit ONSYNC 20,50 jede Sekunde die zeile 20 aufrufe,
ich aber nach einiger zeit, zum Beispiel ab einer bestimmten Punktzahl,
die Zeit ändern will, wie kann ich da wieder auf das ONSYNC zugreifen.
ich will dem Intervall von ONSYNC eine variable zuweisen!
Und erklär doch bitte mal kurz wie sich das mit Assembler und den farben
(green on black, x0e, etc.) verhält!
Gruß
Dominik
Hallo Dominik,
1. ONSYNC L,N kann auch Variablen verwenden, bei jedem Aufruf wird dann
das Ganze neu gesetzt. Wenn L (die Zeilennnummer) 0 ist, wird der
zyklische Aufruf abgeschaltet. Was nicht geht, ist nur die Variable zu
ändern.
2. Im Bildspeicher liegen die Bits so: GRBIgrbi, beim Aufruf von
Setcolor wird das entsprechend umgerechnet, da hier die Bits so liegen:
IRGB. Durch die Umrechnung bleibt die Komatibilität von 8 und 16 Farben
gewahrt. Teilweise habe ich, um Code zu sparen die Umrechnung umgangen
und gleich die "Bildspeicherwerte" genommen statt vorher umzurechnen.
3. In den Videomodi 4 und 6 lassen sich eigene Zeichen definieren. Bei
Mode 4 sind es 127 Zeichen Äquivalent zu Mode 0, bei Mode 6 gibt es 63
Zeichen, bei denen die Farbe jedes Punkes definiert werden kann. Zudem
wäre auch der Tiles/Sprites Treiber eine weitere Möglichkeit.
Jörg
Hallo Jörg,
danke für die Antwort!
zum Onsync: Muss ich mal probieren! Ein erneuter Aufruf! Ok, aber Onsync
in eine Schleife setzen zum Beispiel geht nicht!?
Zu den farben: Puh... Ich glaub das versteht nur der Entwickler :) Naja,
ich kann es ja mal versuchen und mich drangeben!
Zum Charset: Nunja, wie kriege ich denn den Tile Treiber geladen?? Ich
such natürlich nach einer Lösung die wenig zeilen beansprucht. Wenn ich
jetzt im Sourcecode den zeichensatz schon anpassen könnte, wäre das
natürlich perfekt! Zum Beispiel das Smiley (%27).. kann man das im
Zeichensatz, im Sourcecode ändern? Zum beispiel das es böse guckt?
Ich meine Änderungen am zeichensatz die nicht zur Laufzeit des ganzesn
Systems geschehen!
Gruß
Dominik
Hallo Dominik,
zum Tiletreiber gibt es auch ein Beispiel, man muss ihn einfach nur via
XMODEM auf einen beliebigen Programmplatz übertragen und mit VMODE 7
aktivieren.
Den Onsync kann man aufrufen wenn man will, selbst in der aufgerufenen
Subroutine. In einer Schleife sollte es natürlich auch gehen.
Wenn man den System-Zeichensatz ändern will, muss man das im Sourcecode
(libmio/generator) tun. Dazu kann man die ctab_f0.dat abändern und
danach das Script generate_chartable.pl starten sowie das Projekt neu
assemblieren.
Ich habe eine neue V1.44 erstellt und im Download-Bereich ausgetauscht.
Bei mir hat es mit dem Speichern geklappt aber trotzdem ist es ratsam
vorher die Daten zu sichern da ich sicher nicht alle Konstellationen
getestet habe.
jörg
Ahaaaaaa, da versteckt sich der zeichensatz also :)))
Danke Jörg!!!
So, also mittlerweile habe ich zig Anwendungsbereich für den Mini
Computer gefunden! Es ist sooo geil!!!
Onsync funktioniert nicht so wie ich will.. komisch! Ich muss nochmal
testen und bescheid geben!
Ha! Hab jetzt die Tetris Musik emuliert! genial! leider leider ist es
nicht so einfach unter eine melodie zum beispiel eine "Bass" oder
"Drum"-Spur als einzelne Note zu legen, da der Sequencer wirklich seeehr
mager ist!
Jörg, ist iiiiirgendwas noch möglich was den Sound betrifft?
ich bleibe erstmal bei der 1.43er bis ich alles an Software fertig habe!
Gruß
Dominik
PS: Hab einen Super mario Klon so gut wie fertig! Wenn alles soweit
fertig ist werde ich mal ein listing veröffentlichen! Hinzu kommen noch
Textverarbeitungsprogramme sowie Steuerprogramme für SPS, etc
Argh,
kriege mit avra.exe den code nicht kompiliert!
Irgendwie macht die M644Pdef.inc probleme...
es kommen fehlermeldung das #pragma ist unbekannt... etc.
also die 32er version funktioniert einwandfrei... aber die 64er 1.43
bekomme ich nicht kompliliert, was kann das sein??
So... es lag an avra.exe
mit avrasm2.exe gehts!
Aber nun bekomme ich folgende fehlermeldungen:
zig redefinitions fehler und: too deeply nested macro(16)
waruuuuum??
Mit dem letzten AVRA (1.3.0) sollte es eigentlich gehen, zur Not kann
man auch das def.inc kopieren und die mit # bginnenden Zeilen
rauslöschen. Über Probleme mit dem avrasm.exe und Makros ist auch hier
im Thread weiter oben zu lesen, das ist wohl eher ein aussichtsloses
Unterfangen.
Jörg
Hi Jörg,
danke für die Antwort!
Stimmt, habs oben schon gelesen! Aber eine Lösung wurde nicht gepostet,
da Klaus es ja anscheinend hinbekommen hat!
mist... irgendwie muss es doch gehen!!
Jörg, kannst du das SOURCE Verzeichnis mal aktualisiern und alle Dateien
reinschmeissne die man braucht?
Libdef.asm fehlt zum beispiel!
geht alles nicht...
weder AVRA, noch AVRASM2 noch AVRASM32...
alle melden Worng Device M644Pdef.inc
und danach kommen zig Fehlermeldungen... ahhhh ich verzweifel!
Hallo Dominik,
ich hab mir mal die Quellen vom "aktuellen" AVRA angesehen, da fehlen
u.a. der ATMega644, 644P und 1284P. Bis jetzt hat sich noch niemand in
der Hinsicht gemeldet, so dass das nicht aufgefallen ist. Dass der
AVRASM mit dem Makros nicht klarkommt "ist halt so", mehr als zur
Kenntnis nehmen kann ich da auch nicht. Eine Möglichkeit wäre noch der
avr-as (vom AVR-GCC) aber der kommt leider auch nicht mit dem Source
klar.
Ich hab mal ein erweitertes device.c File angehängt, wenn man den AVRA
damit compiliert sollte es eigentlich gehen.
Jörg
Hi Jörg,
danke schön!
Kann leider den Avra nicht kompilieren, bin auf eine .exe angewiesen :(
Versuche jetzt noch den tavrasm .. hab gehört das der auch funktionieren
soll.. mal schauen!
Ansonsten:
Kannst du vlt die Sourcen aktualisieren auf deiner Seite und vlt auch
einen kompilierten Avra mit anbieten?
Ich werde eine neue Version bereitstellen, bei der dann hoffentlich alle
Source-Dateien dabei sind. Die aus /usr/local/include/chipbasic2 fehlen
ja leider in den aktuellen Archiven. Das AVRA-Binary (dazu müsste ich ja
auch noch den Sourcecode mit anbieten) würde Dir aber auch nichts
nutzen, da es lediglich unter Linux und vielleicht noch BSD lauffähig
ist.
Jörg
Hallo Jörg,
sind wir eigentlich nur noch die Einzigen die hier schreiben? :-)
Es war doch mal so viel los hier!
Also mit dem kompilieren muss ich mir mal was einfallen lassen!
Bis dahin fummel ich die ganze Zeit am 32er rum!
Mh.. habe zum beispiel mal versucht im Menü anstelle des Pfeils, die
Auswahl zu invertieren, genau wie beim 644er...
Dachte eigentlich das geht ganz easy mit SWAP und der Farbe aber....
naja... Assembler ist immer noch nicht mein Freund :)
Gruß Dominik
Hallo Dominik,
wie hieß es so schön in einem Lied "Jedes Ding hat seine
Halbwertszeit..."? ChipBasic2 ist immerhin schon fast 5 Jahre alt.
Das mit dem selber compilieren ist z.B. ein Grund oder auch die recht
hohe Komplexität der Programme. Und das es die Transferprogramme nicht
als exe gibt. Da ich aber meine Projekte in erster Linie für mich selbst
entwickle, sehe ich darin kein Problem wenn es fast niemenden
interessiert (wie z.B. beim AX82). Und manchmal überlege ich, ob bei
neuen Projekten ein Hinweis im Bereich "Mikrocontroller" nicht
ausreicht.
Für die Erstellung von Programen in Assembler gibt es ja die
API-Funktionen, wobei die halt nicht alle in der Dokumentation stehen.
Jörg
Hey Jörg,
also ich, wir, er, Sie, Es kann ja froh sein das du das Ganze überhaupt
veröffentlichst und auch noch unter GPL stellst.. von daher!
Naja, ich bin jemand, ich muss wissen was ich da gebaut habe! Ich schaue
mir den Source an und versuche ihn zu verstehen!
ich lasse da auch nicht locker! :)
Wie gesagt, den 32er Code kann ich kompilieren und da bastel ich gerade
viel rum.
Wenn ich zum beispiel die Zeilenanzahl von 51 auf 52 erhöhe stürzt der
Editor ab... warum weiß ich nicht, aber das sind so sachen die ich eben
rausfinden will!
Gruß
Dominik
Nein, es muss niemand froh darüber sein. Ich betreibe das als Hobby und
aus Spaß und muss damit weder reich noch berühmt werden. Dass der AVRA
seit längerem nicht mehr weiterentwickelt wird (der Feature-Request für
den Mega644 ist schon seit über einem Jahr offen), dafür kann ich
nichts. Dafür dass Quelldateien im Projekt fehlen, schon. Und das werde
ich auch mit dem nächsten Update beheben. Wie ich gelesen habe, ist der
TAVRASM seit 2004 nicht mehr weiterentwickelt worden und von daher wohl
auch keine Alternative.
Am einfachsten wäre es, wenn jemand den AVRA mit der geänderten Datei
unter Windows übersetzen und dann den anderen das Binary zur Verfügung
stellen könnte. Für Linux könnte ich das übernehmen.
Wenn Du die Anzahl der Zeilen auf 52 erhöhst, kann es natürlich sein
dass die 52.Zeile z.B. schon den Stack im RAM überschreibt. Da während
des Editierens das gesamte Programm im RAM gehalten werden muss, ist die
Anzahl der möglichen Zeilen durch den freien Speicher limitiert.
Jörg
Hi Jörg,
ahaaa.. ok!
Weißt du, ich bin gelernter Scharfschütze, Panzerkommandant und
Verwaltungsfachangestellter! Elektronik hab ich mir selber angeeignet
und damit sogar einen Arbeitsplatz in einer Firma für Labortechnik
bekommen!
Also ich lerne!!! ;)
Ok... ich werde mich mal schau machen ob das unter windows jemand kann!
Dann dürfte der rest kein problem sein!
Gruß
Dominik
Ein bisschen länger hat es dann doch gedauert, da ich mir erst einmal
einen originalen CB2 "zurückbauen" musste. Ich hoffe, jetzt sind alle
Quelldateien mit dabei, ein bisschen habe ich auch den Verzeichnisbaum
umgebaut.
http://www.jcwolfram.de/downloads/main.php#chipbasic2
Jörg
PS: Da sich beim AVRA scheinbar nichts mehr tut bin ich am Überlegen,
meine gepatchte Version als Fork zu veröffentlichen.
Danke Jörg!
Wollte dich mal fragen,ob ich demnächst
Einen wikipediaartikel über dieses tolle Projekt Machen darf,
unter der Kategorie 8bit Rechner
Gruss Patrick
Hallo Jörg,
wie Dir sch per Mail mitgeteilt, hab ich mal eine Schaltung getestet
welche aus einem RGB H+V - Signal ein FBAS - Signal macht.
Mit Erfolg. Diesen Erfolg will ich gern hier im Forum teilen.
Ich habe die entsprechenden Dateien als *.GIF angehängt.
Wer gern die Orignale Target.3001 Datei hätte, soll sich bei mir melden.
Kernstück ist ein MC1377 von Motoro. Sind leicht zu bekommen.
Habe mir gleich drei für 10Euro zu gelegt.
Die 1nF Kondensatoren sind im Wert unbedingt einzu halten.
Bei längeren Kabelverbindungen, ist es sinnvoll die 68Ohm Widerstände
gegen 75Ohm zu tauschen. Wegen des Wellenwiderstandes von Videokabeln
(75Ohm).
Ich war noch nicht zu Ende,
wenn beim INP - Befehl zu viele Zeichen eingegeben werden, startet der
Controller neu. Dieser Fehler wird nicht sinnvoll abgefangen.
Ebenso wenn ausversehen die Pfeiltasten benutzt werden.
Zu einer Deutschen Tastatur gehören auch die Umlaute und das ß.
Gruß Ralf
Hallo Ralf,
Das mit den zuvielen Zeichen und den Pfeiltasten werde ich mir bei
Gelegenheit mal ansehen. Wenn noch ein bisschen Flash frei ist, könnte
man vllt. eine zusätzliche Abfrage einbauen.
>Zu einer Deutschen Tastatur gehören auch die Umlaute und das ß.
Das mag zwar sein, ist aber nicht vorgesehen und kann auch nicht
nachräglich ergänzt werden. Einfach deswegen, weil alle Bytes ausserhalb
des ASCII-Zeichensatzes als Token interpretiert werden. Im Zeichensatz
selbst sind sie vorhanden, allerdings höchstwahrscheinlich nicht
kompatibel zu irgendwelchen Windows-Codepages.
Jörg
Hallo Joerg
Unglaublich, was Du da entwickelt hast. Und das mit einem Mega644.
Sogar ein Moinitor kann man anschliessen!!!
Den muss ich mir einfach nachbauen.
Dieser Basic Computer schlägt selbst meinen C64 und den Amiga 500!
Gruss
Ferenc
Hm... meine Antwort wurde gar nicht angezeigt... also nochmal:
Frohes Neues jahr Jörg :))
Den Atmega644 Source bekomme ich immer noch nicht compiliert! Aber
egal..
Jörg,
Hast du nochmal darüber nachgedacht video und sound in einerm 2. Atmega
auszulagern? Ich bekomme es leider nicht hin alleine, mit dem Code...
Aber das wäre endlich mal was geniales. Mehr Platz im Flash und mehr
Möglichkeiten!!!!
Gruß
Dominik
Hallo Dominik,
gesundes Neues Jahr wünsche ich ebenfalls.
Mit dem AVRA sollte sich der Code aber übersetzen lassen. Mit einem
anderen Assembler kann es durchaus schwierig werden, insbesondere mit
dem avrasm. Da ich in letzter Zeit mehr mit anderen Controllern mache
(Freescale, Renesas, MSP430) und dort durchgängig den ASL benutze habe
ich schon versucht, einzelne AVR-Projekte dorthin zu portieren.
Letztendlich war es aber einfacher, den AVRA weiter zu benutzen und für
neue Controller einfach selbst zu patchen.
Was die Modularisierung anbetrifft, genau das Gegenteil war das Ziel vom
ChipBasic. Alles in einen Controller und minimale Hardware außenrum. Es
gibt zwar einen Prototypen von einem Nachfolger, der eine
CPU-Adapterplatine mit Mega1284P und CPLD auf dem original Board nutzt
und auch VGA bei 320x240 kann, letztendlich wird aber die Zahl der
Interessenten eher verschwindend klein sein.
Natürlich reizt es mich, einen Computer zu bauen, den man auch für
"ernsthafte Dinge" einsetzen kann. Aber dazu sind meiner Meinung nach
noch einige "Zwischenschritte" notwendig. Vor allen Dingen muß man
Applikationen in C schreiben können, die vom externen Datenträger in das
RAM geladen und ausgeführt werden.
Jörg
Hallo Jörg,
Klar ist der Computer mit einem Chip einzigartig!
In den 80ern wärst du wahrscheinlich Millionär damit geworden :)
Mich stören halt nur etwas die 95 Zeilen die man zur Verfügung hat!
Spiele und Programme können ja in den Dataflash abgelegt werden.
Aber max. 256 Farben und ein guter Sound wäre schon was geniales!!
Siehe Uzebox...
ich nochmal...
Du hast mal geschrieben:
Digitaler Joystick sollte kein Problem sein, einfach die Schalter
zwischen I/O und Masse. Gelesen wird dann mittels IN(n).
Muss dafür nicht der I/O Port auf High liegen?
Denn wenn er LOW ist, dann muss ich die Schalter ja gegen 5 Volt ziehen!
ich kann ja in Basic die Ausgänge High setzen, aber dann doch nicht mehr
per In lesen oder?
So,
ich hab dann auch mal ein layout erstellt, welches ich vermutlich
demnächst auch ätzen lasse.
Schnittstellen und Peripherie:
- Scart
- Chinch Video und Audio
- PS/2 Anschluss
- Serielle RS232
- USB an 2. serielle Schnittstelle
- 9 pol. parallel (Joystick, Belegung wie Atari, C64, etc.)
- Stiftleiste parallel I/O
- I²C
- 10 pol. und 6 pol. ISP
Bauteile:
- 2 x EEPROM
- Dataflash auf Platine
- FT232RL USB Modul
- MAX232 für die serielle
Hoffe das mit den Schnittstellen funktioniert.
Habe jetzt nochmal versucht die Version 1.45 zu compilieren mit AVRA und
AVRASM2 und AVRASM32.... keine Chance... immer wieder unterschiedliche
Fehlermeldungen :(((((
Kannst Du mal die Fehlermeldungen von AVRA posten? Welche Version
benutzt Du? Mit den anderen beiden Assemblern kann ich nichts anfangen,
da ich kein Windows habe.
Zum Joystick: man kann über OUT die internen Pullups einschalten und muß
dann halt z.B.
IF IN(0)=0 THEN ...
zur Abfrage verwenden. Alternativ kann man natürlich auch Pull-Downs in
den Joystick-Adapter einbauen, dann entfällt die Invertierung.
Jörg
Mit dem PLAY-Befehl kann man auch Noten im Hintergrund abspielen lassen.
Wie es bei der Uzebox geht kann ich nicht sagen, da ich mich nie damit
beschäftigt habe. Machen lässt sich bestimmt noch einiges, z.B. den
Wellenformspeicher in das Array legen um beliebige Wellenformen zu
kreieren. Dazu müsste man eine "Weiche" einbauen, mit der die Daten
wahlweise aus dem Flash oder dem RAM geholt werden. Für eine zweite
Stimme sind horizontal nicht in allen Modes genügend Takte übrig.
Für mich ist das Projekt allerdings abgeschlossen, mehr als Bugfixes ist
nicht drin.
Jörg
Oha... das klingt zu kompliziert! :(
Bin ja auch nicht so bewandert was Assembler angeht!
Zeichensatz ändern ist nicht das Problem. Die Farben hab ich mir auch
schon angepasst auf C64 Style :))
Die Cursorsteuerung im menü ist mir noch nicht so klar. Wollte
eigentlich ein weiteres Icon neben dem Info legen und dort die
Statuszeile ablegen! Aber da blicke ich noch nicht ganz durch!
Genauso wie mit dem Sound.
Ich habe in den Sourcen nur das perl script gefunden um den soundtable
zu erstellen!
LG
Dominik
PS: Habe vor die Basic Referenzen was aufzupeppeln sowie ein paar
listings zu erstellen von meinen ganzen Spielen!
Vlt noch ein kleines handbuch dazu, mal schauen!
Die Menü-Routinen liegen in "modules/menu.asm", dort gibt es auch
Routinen zum Zeichnen der Symbole (z.B. "menu_cfgicon"). Eine solche
brauchst Du auch für das eigene Icon. Nach "menu_main_11" müsste dann
noch die Abfrage für das zusätzliche Icon und Aufruf der zugehörigen
Funktion integriert werden. Ob dafür aber noch Platz im Flash ist, wage
ich zu bezeifeln.
Die Soundausgabe läuft fast komplett im Video-Interrupt, zu finden im
File "libmio/vint_o.asm". Dort nach "calculate sound" suchen.
Für das Assemblieren und Übertragen kann man sich auch ein Script
basteln:
1. main.hex löschen
2. avra main.asm
3. wenn main.hex existiert, per Programmer an den Controller übertragen
Bei einem Assemblierungsfehler wird die main.hex nicht erzeugt und der
gesamte Vorgang abgebrochen.
Jörg
Hallo Jörg,
danke für deine Antwort!
Wie sich das mit draw_icon, etc. verhält habe ich bereits rausgefunden!
Ganz blicke ich noch nicht durch mit der Cursorsteuerung. Denn DOWN
funktioniert ja nur wenn ich mit dem Cursor in der ersten Zeile bin und
unter mir entweder das FLASH Symbol, Config oder Info ist. tricky...
Ich speicher die einzelnen .asm Dateien immer und compiliere
anschließend alles mit deinem AVREL.exe. Dadurch sehe ich leider nicht
wieviel Platz ich noch frei habe!
Ok, wenn du sagst es hat keinen Sinn irgendetwas neues hinzuzufügen,
dann lasse ich es natürlich!
Ich könnte es natürlich auch versuchen und schauen ob es beim
compilieren ein Fehler gibt.
Eventuell werde ich die Statusleiste mit MCU, VID und KBD in die INFO
verlagern.
Gruß
Dominik
PS: OT: Dadurch das es hier nur 1 Seite gibt bei dem Thema stürzt
ständig die Seite bei mir beim Antworten ab wegen Skriptfehler etc.
Gibts da ne Lösung?
Kilo schrieb:> PS: OT: Dadurch das es hier nur 1 Seite gibt bei dem Thema stürzt> ständig die Seite bei mir beim Antworten ab wegen Skriptfehler etc.> Gibts da ne Lösung?
Da hilft im Forum anmelden und Seitenaufteilung einschalten. Oder halt
einen gscheiten Browser nehmen, beim FF sürzt bei mir nichts ab.
Jörg
Mal ne andere Frage.
Angenommen ich würde Unterprogramme oder ähnliches rausnehmen die ich
nicht brauche...
könnte ich damit alleine die Zeilenanzahl im Editor erhöhen, sprich den
Flash oder reicht das alleine nicht aus?
Sorry wenn ich nerve... (Bin ja eh der Einzige momentan)
1. Wo wird das Loader Icon erstellt?
Alle Icons werden in menu.asm erstellt und angezeigt. Das Loader Icon
finde ich nicht.. will es löschen. Bzw. hab es gelöscht aaaaaber: Da ich
ja jetzt einen blauen Hintergrund habe, ist der Hintergrund bei dem das
Loader Icon war immer noch schwarz!
2. Im Menü wird ja der Fensterrahmen angezeigt. Über der Statuszeile ist
eine Leiste. Die Box habe ich wegbekommen. Die Zeile in der die Leiste
angezeigt wird finde ich nicht. Ich meine den Balken der die Icons von
der Statuszeile trennt.
Hallo Dominik,
der Loader ist ein quasi vorinstalliertes Binärprogramm. Das lässt sich
auch einfach löschen. Bei Nicht-BASIC-Programmen steht die
Icon-Definition im Programmheader. Dafür gibt es im Bereich "Interna"
den Abschnitt "Das API für Binärprogramme".
Wenn Du den Loader nicht brauchst, dann einfach in der main.asm einfach
bei 0x6000 das include rausschmeißen und durch einen leeren Block z.B.
vom Programm darüber ersetzen.
Der Code für die Zwischenzeile geht in der menu.asm ab Zeile 45 los.
Dort werden 0xf8, 28 x 0xf1 und abschließend 0xf9 in die entsprechenden
Bildschirmspeicherzellen geschrieben.
Die Anzahl der Zeilen wird in erster Linie durch das RAM limitiert, da
während des Editierens der gesamte Quelltext im RAM liegen muß. Beim
Flash könnte man einfach für eine höhere Zeilenanzahl die Zahl der
Programme verringern. Man kann aber Subroutinen in andere Programme
auslagern. Wenn das nicht reicht, könnte man einen ATMega1284P nehmen
und den Code entsprechend umschreiben.
Jörg
Hallo Jörg,
danke schön...
ach bin ich blöd! Dass ich das nicht gesehen habe!! :(
Klaro geht das bei den Programmen auch mit CALL.
Pacman zum Beispiel. Dem habe ich einen Startbildschirm und
Joysticksteuerung verpasst. Dazu brauchte ich natürlich einen 2.
Programmplatz. Ist halt immer nur blöd beim laden...
Obwohl warte mal...
Theoretisch könnte man doch z.b. auf P1 ein Programm schreiben mit einer
Liste von Spielen. Suche ich mir dort eins aus, dann läd der computer
dieses Spiel aus dem DFlash in den Mega und startet es.
Wäre es dein ein großer Aufwand den Code bei einem ATMega1284P
umzuschreiben?
Gruß Dominik
PS: Ich bin immer noch total begeistert von deinem Computer! :-)
Hallo Patrick,
Ich habe an meinem Parallelport einen Schmitt Trigger hängen. Jetzt kann
ich perfekt meinen digitalen Joystick dran hängen.
Spiele habe ich auch schon ein paar aber ehrlich gesagt die serielle
Schnittstelle noch nicht getestet. Von daher müsste ich alles abtippen
und dafür war ich bislang zu faul.
@Jörg
Kabel an die serielle, CTRL+P und schon wird ein screenshot an meinen pc
gesendet? als Bild??
ah ok aber vllt kannst du den bildschirm abfotrogafieren, mit den
listings,dann kann ich mir das von den pics selbst abtippen ,
vielen Dank im Vorraus
gruss Patrick
Jörg,
bei deinem Mega16 Projekt konnte man den Zeichensatz mehrfahrbig
darstellen! Das war natürlich genial!!!
Geht das beim aktuellen 644 Projekt nicht???
Ich meine in der .dat Datei... jetzt bestehen die Zeichen aus ... und
xxx
im 16er war durch einen Buchstaben die Farbe angegeben!
1. zum Senden der Listings über die serielle Schnittstelle: Im Editor
CTRL +F2, steht auch in der Anleitung
2. Man kann für jedes Zeichen Vordergrund- und Hintergrundfarbe
festlegen, warum sollte das dann auch noch in den Zeichensatz. Der
Mega16 hatte nicht genügend RAM für extra Attribut-Bytes
Jörg
Hi Jörg,
nein.. hast mich falsch verstanden...
Im Zeichensatz der 16er Version war z.B. die Kugel für Pong mit einem
weißen Schatten.
Der Smily war gelb und hatte rote Augen! Das war bereits im Zeichensatz
festgelegt...
Beispiel:
644:
.....
.xxx.
xxxxx
.xxx.
.....
.....
Ergebnis: Ein einfarbiger Ball
16er:
.....
.YYY.
YYBYY
.YYY
.....
Ergebnis: Ein gelber Ball mit blauem Punkt in der Mitte.
Im aktuellen Zeichensatz nehmen die "Öffnungen" der Augen eines Smilies
ja die farbe des Hintergrundes auf. Wenn ich jedoch im Zeichensatz
anstelle eine X ein R für rot eingeben könnte, dann würden die Augen rot
sein und die Kopf farbe kann ich in BASIC wählen.
Dafür gibt es (mit Einschränkungen) den Videomode 6 oder den Tile/Sprite
Treiber. Theoretisch könnte man auch die Ansteuerung wie beim Mega16 in
einen ladbaren Treiber packen.
Jörg
Wenn man einen schnelleren Algorithmus findet, die Pixel auszugeben oder
den Controller übertaktet oder die Ausgabe der Pixel in externe hardware
(CPLD) auslagert ... theoretisch schon.
Allerdings müssten die Speicheraufteilung (zu Lasten der Array-Größe)
sowie jede Menge anderer Dinge, die sich auf die 30 Zeichen je Zeile
beziehen, überarbeitet werden.
Jörg
So,
hier nun eins meiner Spiele!
Es ist ein kleines Jump'n'run.
gesteuert wird mit Joystick, links, rechts und hoch!
Die Belegung muss sich natürlich jeder selber einstellen:
Zeile 11 => Joystick rechts
Zeile 12 => Joystick links
Zeile 13 und 85 => Joystick hoch
In den einzelnen levels stehen Bäume am Boden, logisch, welche von level
zu Level mehr werden. Ihr dürft diese Bäume nicht berühren sonst
verliert ihr Leben!
Die gelben Münzen bringen Punkte. Ab 10 Punkten könnt ihr sogar höher
springen!
Wenn ihr gegen den grünen Block springt, erscheint an irgendeiner Stelle
eine lila Glocke. Springt auch gegen diese und ihr erhaltet ein
zusätzliches Leben.
Ab einem bestimmten Level gibt es diese Glocken nicht mehr und es ist
nur noch eine Frage der Zeit wie lange ihr durchhaltet!
Gruß
Dominik
PS: Als nächstes werd eich hier mal Pong One veröffentlichen. Ein
One-Player Pong mit 3 Schwierigkeitsstufen!
Im Moment versuche ich mich an einem etwas flexibleren Konzept. Die
meisten BASIC-Dialekte sind halt nicht miteinander kompatibel und das
schreckt ab. Außerdem fehlt, wie Du schon bemerkt hast, ein
Simulator/Emulator.
Meine Idee ist es daher, dass man seine Programme in C schreiben kann
und diese im RAM des Controllers ausgeführt werden. Die ganzen
Bibliotheken liegen aber im Flash, so dass der Code recht kompakt
bleibt. Das schließt den AVR natürlich aus, da der keinen Code aus dem
RAM ausführen kann. Nun, es gibt ja auch noch andere Controller, zur
Zeit verwende ich einen MC9S12XD128 von Freescale in einem "Nachfolger"
von meinem AVR-Handheld. Aber das gehört jetzt eigentlich nicht mehr in
diesen Thread...
Jörg
Ach Jörg,
ich glaube das würde dann schon wieder zu weit gehen!
Für die Uzebox programmiere ich auch Spiele am PC in C und compiliere
sie dann auf SD Karte... Du hast natürlich viel mehr Möglichkeiten aber
das Flair das dein Computer hat ist dann weg!
Ich habe den Dataflash fest auf meiner Platine. Mehr braucht man gar
nicht. Spiele programmieren, auf den Flash speichern und du kannst
jederzeit das System neu machen ohne das die Programme weg sind.
man könnte auch nen Bootloader in den Avr schmeißen und alles von SD
Karte oder Flash lesen lassen.. aber dann hast du wieder eine
Spielekonsole a la Uzebox!
Das sind erstmal nur Tests, später soll schon ein "richtiger" Computer
folgen. Nur dass man seine Anwendungen dort in C und nicht mehr in BASIC
erstellt. In einen größeren Controller (die S12XE gehen bis 1MB Flash)
sollte dann auch ein einfacher C-Compiler nebst Editor und Assembler mit
reinpassen.
Jörg
Och, wenn du einen dicken MC auspackst kannst du doch sicherlich ein
TinyBASIC mit einbauen. Das wäre dann sogar kompatibel zu den ganzen
alten Spielebüchern und wäre sehr nah am "Industriestandard" MSBASIC
2.0, würde halt nur das Fließkommazeugs fehlen. :)
So, bin grad an Breakout (Arkanoid) dran.
Das blöde ist die Ball Physik... will den Abprallwinkel ja abhängig von
der Paddlebewegung machen!
Das Paddel besteht aus 3 Zeichen. Ich könnte quasi wenn der Ball das
mittlere Zeichen trifft den Winkel so lassen, wie bei Pong.
Und dann abhängig ob die linke oder rechte Seite des Paddle getroffen
wird den Winkel vergrößern... aber wie? Leider kann ich nur mit ganzen
Zahlen arbeiten.
hi Dominik wie kommt man bei deinem ballE game wieder auf dem
Startbildschirm? er wurde mir nur einmal angezeigt ,wo ich das erste mal
das Spiel gestartet hab ? sonst echt super Spiel !!
Hi,
Danke :)
Wenn du Game Over bist, dann gelangst du wieder zurück...
Ansonsten musst du abbrechen mit CTRL+C
Im Moment sind halt nur die 4 Himmelsrichtungen sowie 1 Feuerknopf in
Verwendung!
Greetings Kilo
Can i purchase one of these boards, I have the original chipbasic2 board
with Atmega1284 insitu. I primarily use it with the AX81 configuration!
regards
Frank
Kilo schrieb:> So,> ich hab dann auch mal ein layout erstellt, welches ich vermutlich> demnächst auch ätzen lasse.>> Schnittstellen und Peripherie:> - Scart> - Chinch Video und Audio> - PS/2 Anschluss> - Serielle RS232> - USB an 2. serielle Schnittstelle> - 9 pol. parallel (Joystick, Belegung wie Atari, C64, etc.)> - Stiftleiste parallel I/O> - I²C> - 10 pol. und 6 pol. ISP>> Bauteile:> - 2 x EEPROM> - Dataflash auf Platine> - FT232RL USB Modul> - MAX232 für die serielle>> Hoffe das mit den Schnittstellen funktioniert.>> Habe jetzt nochmal versucht die Version 1.45 zu compilieren mit AVRA und> AVRASM2 und AVRASM32.... keine Chance... immer wieder unterschiedliche> Fehlermeldungen :(((((
Hi Frank,
I don't really sell the boards!
First I have to let produce them first but I'm still not satisfied with
the layout. I will change some of the hardware like USB, Sound, and so
on.
****
Bin noch in der Bastelphase... Zur zeit mache ich ein paar neue Spiele
und bastel noch was am Board. Teste ein wenig mit dem FT232RL Baustein.
Vielleicht wäre es dann sinnoll, die schnellere Hardware-Schnitstelle
des 644P als Systemschnittstelle zu nutzen. Der Aufwand dazu sollte sich
in Grenzen halten, da die Kommunikation über die libmio läuft. Die
ursprüngliche (Software-) Systemschnittstelle könnte dann entfallen,
dafür würde dann auch noch ein bisschen Flash frei.
Jörg
Hi Jörg,
ach das wäre ja super!!
geht das Pinmäßig auch mit dem ATMega1284P?
Wenn ja müsste man dann nur die def.inc ändern damit der AVREL.exe damit
umgehen kann oder? Weil ich hab zur Zeit nur den ATMega1284P rumfliegen,
keinen 644P
Hallo Dominik,
theoretisch sollte der Mega1284P auch mit dem "normalen" Hexfile gehen
und als Mega644P in der Statuszeile erscheinen. Ansonsten halt mit
anderem Include-File assemblieren.
Jörg
Ah ok...
das wäre ja noch besser!
Ich werde es mal ausprobieren! Danke :)
Würdest du die libmio denn anpassen an die 644P/1284P Version?
Dann baue ich das mal mit dem USB auf!
Hi Jörg,
kannst du mal kurz anreissen wie das mit dem Sound funzt?
Wie hast du das soundtable erstellt, auf welcher Grundlage?
Wären theoretisch 2 Kanäle machbar?
Wie funktioniert der Sound allgemein?
Gruß
Dominik
PS: bei diesem projekt bereue ich kein Assembler zu können!
So,
im Moment bastel ich an Breakout (Arkanoid)... Hab momentan schon 3
Level! Klappt super!!!
Anbei auch mal mein aktuelles Menü-layout im C64 Style :)
Und den aktuellen Zeichensatz. Hab ihn erweitert um Spielerelevante
Zeichen wie Hubschrauber, Motorrad, Raumschiff, Herz, Karo, pik und
Kreuz und und und... bin aber noch nicht fertig!
Auch am Sound habe ich was gearbeitet. die Noten mit langer Hüllkurve
klingen zur Zeit etwas elektronisch verzerrt. Bei Musik nicht schlecht.
Aber gefällt mir noch nicht ganz! Ich will ein etwas polyphoneren Ton
haben und etwas verzerrter!!
Auch das Platinenlayout wird sich wieder ändern. Bin mir aber nicht ganz
sicher ob ich das System modular aufbauen soll oder alles auf eine
Platine schmeißen soll. PCB würde mich momentan 39 € kosten :(
Hallo Jörg,
sag mal... wo sind denn die Farbeinstellungen der Zeilen im Editor?
Finde nur den Hintergrund.. also Border..
aber da wo die Zeilennummern stehen ist es immer noch schwarz :(
Ehrlichgesagt, dazu müsste ich auch erst den Sourcecode "durchkämmen",
aber das habe ich eigentlich nicht vor. Gleiches betrifft auch die
serielle Schnittstelle. Wenn ich in der offiziellen Version die
Schnittstelle permanent umstelle, würde ich mich selbst aussperren da
ich immer noch die RS232 nutze. Und andere vielleicht auch. Von daher
ist das für mich keine Option.
Jörg
Ich hab noch einmal drüber nachgedacht, vielleicht ließe sich die
Umschaltung des seriellen Interfaces über die Baudratenumschaltung
realisieren. Auf die 1200 Baud kann ich durchaus verzichten, dafür
könnte man dann 38400 Baud an der zweiten Schnittstelle nehmen. Da ich
zum Probieren keinen FTDI rumliegen hab, dafür aber einen AVR-CDC wäre
das die höchstmögliche Baudrate. Und Kompatibilität wäre immer noch da.
Allerdings zieht das weitere Kreise als nur Änderungen in der libio.
Wenn das OK wäre, würde ich mich im Laufe der Woche mal dransetzen.
Jörg
Hallo Jörg,
also ICH habe nichts dagegen :)
Musste übrigens den Dataflash baustein von der Platine schmeißen. Beim
Flashen des AVR wird dieser gelöscht. Das heißt er muss steckbar sein
und darf nicht parallel zum ISP liegen :(
Bislang habe ich es nur geschafft ein bißchen Zeichencode und Farben zu
ändern. Naja bis auf den Editor, da finde ich keine Farbinformationen
der einzelnen Zeilen.
Ich schaffe es einfach nicht mich durch die Bytes zu arbeiten um zum
Beispiel mehr Zeilen im Editor hinzukriegen. Also ich kriege schon eine
96. zeile hin, aber dann gibts nur Systemkomplikationen :)
Gruß
Dominik
PS: An der Auflösung im Textmodus lässt sich nichts mehr ändern so
einfach oder?
Hallo Dominik,
es sollte reichen, den /RESET Pin des Dataflash mit dem des ATMega zu
verbinden. Dann beibt der DF während der ISP im idle und es sollte
nichts überschrieben werden. Bei "Erweiterungen" ist das auch so
dargestellt.
Ich glaube nicht dass es möglich ist, an Auflösung oder Zeilenanzahl
noch groß zu optimieren ohne andere Dinge in Mitleidenschaft zu ziehen.
Weil meiner Meinung nach ganz einfach der Controller schon fast bis auf
das letzte Bit ausgereizt ist.
Die Farbe für die Editorzeilen findet sich übrigens in der Datei
libmio_tvm.asm (Videoausgabe für den editor) ca. bei Zeile 232 und nicht
im Editor selbst:
ldi YL,0x0e ;1 dark white on black
Jörg
Danke Jörg!!!
Ach herrjeh... da steckt die Zeile also... :))
ich dachte auch eher an den 128P als Controller...
weniger Arbeit bei mehr Flash!
Das mit dem reset Pin verstehe ich nicht ganz!
Um den DF im Betrieb zu beschreiben, muss dieser doch zwangsläufig mit
allen Pins verbunden werden laut "Erweiterungen"
Wenn ich nun parallel dazu den Flash des Atmegas beschreibe also eine
neue Hex reinflashe, bekommt der DF alles mit ab! Welche Pins müsste ich
denn dann physikalisch trennen durch Jumper?
Während des Flashens über ISP wird der ATMega im Reset gehalten (=LOW),
bei einer Verbindung zum Dataflash befindet sich dieser damit auch im
Reset und sollte nicht auf Kommandos reagieren. Ebenso könnte man dem
CS-Signal noch einen Pull-Up spendieren.
Getestet habe ich das aber nicht, da sich bei meinem Aufbau
(Dataflash-Module) ISP und Dataflash gleichzeitig rein mechanisch
ausschließen ;-)
Beim Mega1284P sollten sich mittels eines entsprechenden IRAM-Treibers
zumindest 12K RAM als Array-Erweiterung nutzen lassen. Alles andere ist
wohl mit größerem Aufwand, tiefgreifenderen Änderungen im System und
Verlust der Komatibilität zum Mega644(P) verbunden.
Jörg
Mh, ich werde mal schauen was ich mache. Schön ist natürlich so eine
kleine "Festplatte" mit an Board zu haben. Naja, der Dataflash wollte
nach dem flashen des Atmegas neu formatiert werden. Von daher hat er
sich beim flashen irgendwie daneben benommen. Soll ich also mal CS und
Reset einen Pullup am DF spendieren?
Das ist natürlich schade mit dem Aufwand. Wenn ich Assembler genauso gut
könnte wie Deutsch, dann würde ich mich da ransetzen :(
Nichts für ungut Jörg, der Chipbasic Compi ist genial, das steht außer
Frage... Aber mehr Platz für Basiczeilen, eine bessere Auflösung und VGA
wären natürlich das Optimum mit nur einem Chip!
Mensch, VGA hat doch beim ZX auch funktioniert... :(
Hallo!
Am Wochenende war endlich mal Zeit sich Jörgs 1A "homecomputer" selbst
aufzubauen um damit aus dem Schatten der "nur Mitleser" zu treten..
Nachdem die Schlatung auf einer Experimentierplatine aufgebaut war
(siehe Bilder 644LPunten/oben) den 644 mit dem hex file aus dem Paket
von Jörgs Seite programmiert und schon ging es los.
Ich bin echt begeistert was der 644 leistet im Vergleich zum seeligen
ZX81. Die Limitierung auf 90 code Zeilen war nur auf den ersten Blick
eine denn Unterprogramme lassen sich ja zur Laufzeit nachladen - sehr
schlaues Konzept!!
Der Spaß ließ dann nach einer Weile nach weil das Bild ein Geisterbild
verunziert... siehe Bilder "Bildausgabe"..
Es sieht so aus als ob der Takt des 644 instabil ist also 20MHz Quarz
eingelötet und die SMD Kondensatoren durch bedrahtete ausgetauscht.
Leider keine Änderung.
Die Bilder sind mit einer Wandlerbox FBAS - VGA von einem LCD Monitor
aufgenommen, das Problem bleibt aber auch mit anderem Kabel, an einem
analogen Fernseher gleich.
Die 5V Versorgungsspannung sind auch nicht Quelle der Störungen
Ich früchte damit sind die Hardwaremäsigen Fehlermöglichkeiten
abgeklappert oder fällt jemandem noch etwas ein?
So wie ich Jörgs Konzept verstehe, wie das Bild erzeugt wird, bleibt da
kaum eine Möglichkeit für einen "jitter", richtig?
Bleibt die Frage ob der hex-file ne Macke haben kann und ich mir selbst
einen hex-file erstelle. Jörg kann das sein?
Die fuse settings sind dreimal geprüft und sind so gesetzt wie sie
sollen.
Sachdienliche Hinweise zur Ergreifung des Übeltäters nehm ich gerne
entgegen!
Vielen Dank auf jeden Fall für das schöne Wochenendprojekt und einen 1A
homecomputer!!
Alex
Beim AX81 war das Ganze monochrom, und soviel höher war die Auflösung
auch nicht. Von daher eher keine sinnvolle Alternative.
Ohne externe Hardware wird auch nicht viel mehr zu schaffen sein. Mit
externem 128K RAM + Video-Register (HC374) komme ich bei 20MHz AVR-Takt
(Mega644) auf maximal 320x240 bei 256 (festen) Farben für TV und VGA.
Das ist zwar nicht schlecht und auch recht schnell, aber 320x240 ist
halt für ernsthaftere Anwendungen als Spiele zuwenig. Jetzt bin ich am
überlegen, den HC374 durch ein kleines CPLD zu ersetzen. Dann sollten
wenigstens auch 640x480 bei 4 Farben (aus 16) möglich sein.
Jörg
@ Alexander
tritt das Phänomen auch bei RGB auf? Eventuell hilft es, den
Videoausgang auf der Leiterplatte mit 100-150 Ohm "abzuschließen". Auf
das Hexfile als Ursache würde ich nicht tippen. Das Ausfransen des
Borders in Bild 2 ist normal (gilt auch für das Border-Ende am rechten
Bildrand), da hier keine aufwändige Synchronisation auf den Timer
gemacht wird.
Bei den den Geräten, mit denen ich getestet habe liegt das aber
außerhalb des Sichtbereiches.
Jörg
@ Jörg
mhhh, das klingt natürlich sehr verlockend! Und hey, wenn wir jetzt
schon tolle Spiele programmieren können, was wäre dann erst mit 320x240
bei 256 farben möglich??? Das ist doch ausreichend!!!!
Aaaaaaber: Mein problem ist, der Parallelport! Da hängt natürlich ne
Joystickbuchse dran! Sprich: Ich habe 6 der I/O pins belegt. Da würde
kein externer RAM mehr dranpassen... Nur was nützt die neue Auflösung
und die 256 farben wenn man die Spiele nicht mehr mit Joystick spielen
kann? :(((
Heul... ist das tricky..
Nein, mit der ChipBasic Hardware funktioniert das überhaupt nicht, das
war ein eigenes Projekt, eine Art "Grafikkarte", die seriell angesteuert
wird. Außer den beiden seriellen Portleitungen war auch kein weiterer
Pin mehr am Controller frei ;-)
Das Projekt ist eigentlich schon aus dem Jahr 2011, wegen Zeitmangels
für die Doku habe ich es aber nie veröffentlicht. Ohne Doku ist es aber
mehr oder weniger nutzlos, da es glaube ich knapp 100 verschiedene
Funktionen bis hin zum (rudimentären) 3D-Rendering gab und dazu noch
jede Menge Parameter.
Mit der bestehenden Hardware und einem Mega1284P wären bei VGA grob
gerechnet 200x150 Pixel (16 Farben je Pixel) möglich, wenn man die
unterschiedliche Pixelbreite (3 / 2 Takte) akzeptiert. Das VRAM benötigt
dann aber schon 15K, da beleibt für den Rest nicht mehr viel übrig.
Jörg
Mh.. naja ich vermisse halt die Textauflösung wie sie beim C64 z.B. war
oder bei anderen AVR Computer Projekten.
naja ok, theoretisch sollte man den nötigen Platz für das VRAM ja schon
kriegen, wenn man Sachen rausschmeißt die man nicht unbedingt braucht.
Vor allen Dingen musst Du Dir ein schnelleres Timing einfallen lassen,
um die Zeichen auszugeben. Momentan braucht es 30 Takte je Zeichen, 5 je
Pixel. Um 40 Zeichen darzustellen musst Du das auf 4 Takte je Pixel
reduzieren, also 6 Takte je Zeichen einsparen. Durch Aufrollen der
Schleife, verlagern der Zeichentabelle in das RAM und geschickte
Registernutzung lässt sich das sicher hinbiegen. Dann kommt aber noch
der ganze "Rattenschwanz" an funktionalen Änderungen dazu (z.B. Menüs).
Irgendwann ist es einfacher, das Ganze komplett neu zu entwickeln.
Monochrom geht es auf jeden Fall schneller, siehe 60-Zeichen Treiber.
Jörg
Hallo Jörg!
Danke für Deine Tips!
Der erste Tip, nach einer Fehlanpassung des Videoausgangs in Richtung
zur FBAS-VGA Wandlerbox zu suchen hat keine Änderung gebracht.
Der zweite Tip, Deine Erklärung zu dem "ausgefransten" linken Bildrand
hat jetzt wohl auch die Erklärung für meine Schatten behaftete Ausgabe
gegeben.
Mein Videosignal hat mit dem Scope gemessen die gleiche zeitliche
Unsicherheit (siehe Bild) und wird damit der Grund für die Macke in der
Bildausgabe sein -> also erstmal "working as designed".
Bei nächster Gelegenheit probiert ich den Tip aus den Fernseher per RGB
- Scart mit einem Signal zu versorgen und werde dann wieder berichten.
Es war doch mal einer hier im threat der die RGB Bildausgabe mit einem
IC auf FBAS gewandelt hat.
War das Bild dort so scharf und ruhig wie man es sich wünscht?
Bzw. hat noch wer anders die gleichen Anzeigeprobleme gesehen?
Danke wieder für eure Hilfe!
Alexdander
Hallo Alexander,
ich kann jetzt die Messung nicht nachvollziehen, aber der Beginn der
Bildinformation (nicht des farbigen Randes) sollte sich bezüglich zum
horizontalen Synchronimpuls nicht ändern. Ansonsten wäre ja das ganze
Bild ausgefranst. Eventuell könntest Du das Oszi im "Normalmodus" (nicht
Video) betreiben und auf die steigende Flanke vom HSYNC triggern.
@Dominik
Ich habe die Änderungen bezüglich seriell fertig, muss sie aber noch
testen. Vielleicht komme ich am WE dazu.
Jörg
Hi Jörg,
ui.... das klingt ja klasse!
Bin mal gespannt und freue mich :)
Ach man... bei Pollin gibts wieder tolle kleine PAL TFT's.. könnte man
nen super Laptop bauen aber dafür ist die Bildausgabe per Bas s/w und
das ist blöd :(
Ich werde jetzt mal einen Computer aufbauen und in ein altes
Modemgehäuse einpflanzen + der FBAS Schaltung weiter oben von Ralf -
Rainer Ratke!
Die Modemgehäuse eignen sich perfekt, zumal Aussparungen für die
wichtigesten Anschlüsse vorhanden sind.
Momentan weiß ich noch nicht genau wie ich mit dem Parallelport umgehen
soll. Entweder mit einem Schmitt-Trigger als Joystickport oder als I/O.
Oder kombinieren, dann hab ich aber nur einen Input Port mit passiven
Schaltern die auf Masse gezogen werden. Steuern und regeln hat sich dann
erledigt! :(
@Ralf - Rainer Ratke
Woher hast du die Motorrola IC's denn bezogen? Ich habe sie nur bei Ebay
gefunden und dort auch nicht wirklich massig!!
Gruß
Dominik
Kurzer Zwischenstatus: die Änderungen sind leider noch nicht fehlerfrei,
manchmal hängt das System beim seriellen Loader und start sich laufend
neu. Da muss ich jetzt die nächsten Tage mal drüberschauen.
Zu den FBAS-Schaltungen habe ich keine Erfahrungen, lediglich für den
CPLD-FBAS-Encoder, den ich ursprünglich für den ChipBasic Computer
entwickelt hatte. Und den konne man einfach an den unveränderten "UNI"-
Videoport anstecken.
Jörg
Hallo Jörg,
nungut, ich baue die FBAS Schaltung mit dem Motorrola mal zu Ende und
hänge sie an den Videoport. Mal schauen was passiert!
Bei Pollin gibts übrigens für 14 Euro ein kleines LCD mit FBAS Anschluss
PAL/NTSC... perfekt
Außerdem eine kleine Platine auf der man die Flashbausteine auflöten
kann und mit Stiftleisten versehen kann... Noch perfekter.
@ Dominik
Die Wiederstände für den SCART Ausgang brauchst Du auch für das
converter IC.
Über die unterschiedlichen Spannungspegel die auf den Ausgängen Rot,
Grün, Blau ausgegeben werden wird die aktuelle Farbe des Bildpunktes
"gemsicht".
Die eigentliche Funktion des converter ICs ist die 3 Spanungspegel
zusammen zu fassen, damit die Farbe des Bildpunkts ermitteln und diesen
Wert in eine
Frequenz umzuwandeln - fertig ist das FBAS Signal... in der groben
Übersicht!
Das Pollin Display habe ich auch schon gesehen, kam mir aber aber etwas
klein vor und wenn ich es richtig gelesen haben zeigt es 16:9 an womit
die
Darstellung in der Breite verzerrt ist. Leider habe ich in den
Pollinunterlagen nichts gefunden ob man auf 4:3 umschalten kann.
Berichte mal von Deinen Erfahrungen wenn Du es Dir kaufen solltest.
Übrigens auch ohne das converter IC sollte ein Bild zu sehen sein, halt
nur in Schwarz/Weiß.
@ Jörg
Du hast das Scopebild genau richtig interpretiert!
Das Scope triggert auf den Vertikalimpuls und so kommt es daß die h-sync
Impluse "zittern" wenn ich eine einzelne Zeilen anzeigen lasse.
Trigger ich auf den h-sync steht das Signal wie eine 1 genau so wie Du
es vermutet hast!
Die zeitliche Unsicherheit am linken Rand fällt bei dieser Anzeige nicht
auf. Ich seh in dieser Ansicht auch absolut keine Störungen die mein
Schattenbild erklären könnten. Auch unterschiedliche Abschlußwiderstände
ändern an dem sehr sauberen Signal nichts, lediglich an der Amplitude
(wie erwartet).
@Alex
Na das man auch so ein Bild sieht ist mir klar... aber ich will ja eben
kein s/w sondern in farbe und bunt! :))
ich muss nochmal nachgucken.. wenn das wirklich 16:9 ist, dann ist das
ein bißchen blöd!
Egal.. mal testen!
Sooo... FBas Schaltung gebaut, drangehängt, kein Signal! :(
Das Signal am Scope gefällt mir auch irgendwie nicht.. mh!
Jetzt beginnt die Fehlersuche...
Halloe.
Ich habe da seit einiger Zeit ein Problem, eine SPI-Erweiterung über das
Kommando SPISEL und SPI() ans laufen zu kriegen und komme einfach nicht
weiter. Ich habe eine nette kleine Platine gebastelt und wollte an den
SPI- Bus eine Multiselekt-Erweiterung anbauen, da ich mehrere SPI Geräte
steuern wollte.
Das ganze liegt nu schön länger auf meinem Tisch und will einfach net
laufen. Nun hab ich mir letzte Woche endlich mal einen 10 Euro
Logikanalyser gekauft und bin dem Problem näher auf den Grund gegangen.
Ich verwende die Version 1.45 von ChipBasic auf meinem 644p(er) Board.
Das angehängte Bild zeigt einen Scann der Kommunikation mit folgenden
Befehlen:
SPISEL 0
A = SPI ( 85 )
SPISEL $FF
A = SPI ( 15 )
Was mich wundert ist, das die ChipSelekt- Leitung mit Signal (SS) auf
Pin5 ihren zustand nicht wie beschrieben ändert, sie bleibt die ganze
Zeit auf LOW. Ich hätte erwartet, das sie bei dem Commando SPISEL 0 auf
HIGH wechselt.
Ich hab inzwischen auch schon selbst im Sourcecode rumgesucht, konnte
den Fehler aber nicht wirklich finden. Eigentlich wird der Port wie in
der Anleitng beschrieben umgeschatet, aber irgendwie scheint der Port
nicht auf Ausgabe zu stehen obwolh das im Init-Block am Anfang
eigentlich richtig gesetzt wird, oder ich habe sonst noch was übersehen.
Hat schon jemand erfolgreich eine MultiSelekt Erweiterung ans laufen
bekommen und wie sah eure Schaltung aus ?
Freundliche Grüße
Frank
hallo,
Ich will Chip-8-Programme laden und der Autor sagt: "Der
Chip8-Interpreter Braucht sterben daten in Einem bestimmten Format, und
Zwar Einem 4 KBytes grossem Speicherabbild zusatzlich Sind Verzögerung
und sterben Tastenbelegung hinterlegt..
Wann & DaZu sterben Programm Aus dem Internet heruntergeladen und Werden
mittels der Programme im TOOL-Ordner Konvertiert Werden. "
Wo ist das Programm, um Chip-8-Dateien konvertieren??
Tut mir leid, mein Deutsch, aber sie sind von google translate.
@Frank
da scheint sich wirklich noch ein Fehler eingeschlichen zu haben der
dazu führt, dass immer nur das DatanFlash angesprochen wird. Einen Fix
habe ich schon, muss ihn aber noch testen
@711LAB
The tool for converting chip8 programs is currently missing in the
archive (like the examples). You will find it in the 1.43 package.
Jörg
Thanks! Ich hatte das Programm von Cygwin auf WindowsXP ausführen, wird
es ok. Ich habe alle chip8 Spiele, die ich im Internet finden umwandeln
und Getestet habe ich sie auf der Chip-8 Emulator, funktioniert es ok.
Wissen Sie, wie die EMU-8080 funktioniert? In welcher Position ich es
laden und muss ich laden zusätzliche Bibliothek?
711LAB .. schrieb:> Hallo, ich habe dieses Problem auf 16 Farben SCART. Das Monitorbild ist> sehr schlecht. Was ist das Problem?
Hm, für mich sicht es so aus als ob der Fernseher den SYNC- Impuls nicht
bekommt und damit den Anfang des Bildes nicht erkennen kann. Ich würde
mal schauen, ob da nicht ggf. ein Fehler im Layout ist.
Bei den Scart- Bildern in der DOKU sollte man unbedingt darauf achten,
das die Bilder davon ausgehen das man sich ein Kabel löten will um den 9
poligen Ausgang der "Universalplatine" an einen Scart Stecker anzulöten.
Wenn man statt dessen eine Buchse auf seiner Platine einbauen möchte,
muss man dabei berücksichtigen, das einige Adern im Scart- Kabel "über
Kreuz" laufen und dann muss man die an der Buchse dann an anderer Stelle
anlöten. Für die richige Belegung haben mir "damals" die Wiki Seiten zum
Thema Scart sehr weiter geholfen.
Grüße
Frank
Lange genug hat es ja gedauert, die aktuelle Version (V1.48) ist ab
sofort verfügbar:
http://www.jcwolfram.de/downloads/main.php#chipbasic2
- Bugfix bei SPISEL (zumindest im LA scheint es jetzt zu passen)
- Bugfix: Cursortasten bei INPUT konnten zum Absturz führen
- Die System-Schnittstelle geht jetzt auch wahlweise über 38,4K / USART1
- IRAM-Treiber für Mega1284P (experimentell)
Jörg
Hallo Patrick,
das sollte ohne Probleme möglich sein. Den IRAM12-Treiber habe ich auch
damit entwickelt und getestet, wenn auch nicht mit der finalen Version.
Jörg
Hallo Jörg , ich kann mit dem 1284 leider keine Programme laden, weder
vom d-flash noch aus dem editor, er atmega speichert sie nicht ab weder
unter der 1,48 noch einer älteren version (zum Test die 1,43
Aufgespielt) wenn ich im editor ein Programm schreibe bleibt der nach
dem speichern der Cursor jn der position, so wie es sein soll aber das
Textfeld ist dann leer
Hast du eine Idee , woran das liegen kann? Vielen Dank
Patrick
Hallo Patrick,
erst musste ich auch überlegen, warum das so ist. Letztendlich ist mir
dann doch wieder eingefallen, dass beim Mega1284P eine minimale Änderung
notwendig ist, die aber zum Mega644(P) inkompatibel ist.
Neben einem anderen Include-File für den Mega1284P, welches auch mit dem
Mega644(P) funktioniert, müssen in der main.asm die letzten 3 ORG
Anweisungen geändert werden:
Hallo Jörg,danke dachte schon der neue ATmega wäre kaputt
leider klappt das kompilieren nicht unter Windows
,bringst du evtl. noch eine passende HEX für den mega1284
raus, das wäre echt super weil der Computer macht echt
viel Spass!
nochmals vielen Dank!
gruss Patrick
Ich habe jetzt eine neue Version (v1.49) hochgeladen, bei der auch ein
Binary für den Mega1284P mit dabei ist. Fuses sind die gleichen wie beim
Mega644(P). Zusätzlich gibt es zwei neue Befehle für Textlänge bestimmen
(TLEN), rudimentäre Suche in Texten (TFIND) und einen Bugfix bei CTEXT
(hier wurden teilweise zuviele Bytes in das Array kopiert)
http://www.jcwolfram.de/projekte/avr/chipbasic2/main.php
Jörg
Frank Zoll schrieb:> Hm, für mich sicht es so aus als ob der Fernseher den SYNC- Impuls nicht> bekommt und damit den Anfang des Bildes nicht erkennen kann. Ich würde> mal schauen, ob da nicht ggf. ein Fehler im Layout ist.>> Bei den Scart- Bildern in der DOKU sollte man unbedingt darauf achten,> das die Bilder davon ausgehen das man sich ein Kabel löten will um den 9> poligen Ausgang der "Universalplatine" an einen Scart Stecker anzulöten.>> Wenn man statt dessen eine Buchse auf seiner Platine einbauen möchte,> muss man dabei berücksichtigen, das einige Adern im Scart- Kabel "über> Kreuz" laufen und dann muss man die an der Buchse dann an anderer Stelle> anlöten. Für die richige Belegung haben mir "damals" die Wiki Seiten zum> Thema Scart sehr weiter geholfen.
hallo, es funktioniert immer noch nicht. Zuerst müssen Sie sagen, dass
die 180r mit Pin 18 verbunden werden, aber es ist Pin 16, 18 nicht.
Zweiten, zwei der Farbstifte müssen getauscht werden. whe ich tauschen
sie die richtigen Farben. Aber noch kein Sync.
Wie kann kein Sync getan werden? es gibt keine Sync Pins in den
Scart-Anschluss.
sv3ora schrieb:>> hallo, es funktioniert immer noch nicht. Zuerst müssen Sie sagen, dass> die 180r mit Pin 18 verbunden werden, aber es ist Pin 16, 18 nicht.> Zweiten, zwei der Farbstifte müssen getauscht werden. whe ich tauschen> sie die richtigen Farben. Aber noch kein Sync.> Wie kann kein Sync getan werden? es gibt keine Sync Pins in den> Scart-Anschluss.sv3ora schrieb:> Frank Zoll schrieb:>> Hm, für mich sicht es so aus als ob der Fernseher den SYNC- Impuls nicht>> bekommt und damit den Anfang des Bildes nicht erkennen kann. Ich würde>> mal schauen, ob da nicht ggf. ein Fehler im Layout ist.>>>> Bei den Scart- Bildern in der DOKU sollte man unbedingt darauf achten,>> das die Bilder davon ausgehen das man sich ein Kabel löten will um den 9>> poligen Ausgang der "Universalplatine" an einen Scart Stecker anzulöten.>>>> Wenn man statt dessen eine Buchse auf seiner Platine einbauen möchte,>> muss man dabei berücksichtigen, das einige Adern im Scart- Kabel "über>> Kreuz" laufen und dann muss man die an der Buchse dann an anderer Stelle>> anlöten. Für die richige Belegung haben mir "damals" die Wiki Seiten zum>> Thema Scart sehr weiter geholfen.>> hallo, es funktioniert immer noch nicht. Zuerst müssen Sie sagen, dass> die 180r mit Pin 18 verbunden werden, aber es ist Pin 16, 18 nicht.> Zweiten, zwei der Farbstifte müssen getauscht werden. whe ich tauschen> sie die richtigen Farben. Aber noch kein Sync.> Wie kann kein Sync getan werden? es gibt keine Sync Pins in den> Scart-Anschluss.
Ich überprüfte die hsync VSync r g b-Signale auf einem
Oszilloskop, scheinen sie von einem ersten Blick in Ordnung. aber wie
wird das RGB synchronisiert, wenn kein Sync-Signal wird durch sie
hindurch an den Fernseher?
Das Sync kommt über das Composite Video Signal an Pin 20 der Scart
Buchse. Dort muss das normale (s/w) BAS Signal ankommen, dazu muss J2
offen sein (CSYNC). VSYNC wird bei Scart und BAS nicht gebraucht, nur
beim TFT. Das BAS-Signal von Pin 20 der (Scart) kann man mittels
Cinch-Stecker am Fernseher testen. Nur RGB zum Scart zu führen, reicht
nicht aus.
Jörg
Ja Stift 20 verbunden und ich kann das BAS-Signal (B & W) im Fernsehen
von diesem Stift zu sehen. Jedoch kann das Farbvideosignal nicht
stabilisieren. Ich habe dies auf 2 Röhrenfernseher und 2 LCD-Fernseher
getestet. Die LCD-Fernseher nicht jedes Bild an allen zu zeigen! Ich
weiß nicht, was falsch ist. Hat jemand versucht, den Computer ohne die
Leiterplatte zu bauen, wie ich es tat?
Nachdem durch das Fehlen der Farbe enttäuscht, bin ich den Aufbau einer
minimalistischen Version der Computer, nur mit B & W.
Diese Version hat einen eingebetteten Programmierer und ein
Null-Modem-Verbindung, also kann es so programmiert werden und laden die
Programme ohne spezielle Kabel. Nur die notwendigen Komponenten sind
enthalten.
Es ist sehr schwer, mich auf Deutsch zu schreiben, über Google zu
übersetzen ...
Halloe.
Ich habe mitlerweile erfolgreich eine eigene Platine erstellt und dabei
keine Probleme mit dem Sync oder den Farben. Ich habe hier mal meinen
aktuellen Entwicklungsstand als ZIP- File drann gehängt.
Wobei ich von den 3 Platinen an denen ich arbeite nur die Hauptplatine
angehängt habe. Auf den Fotos sieht man noch die SPI I2C RS232
Erweiterungsplantine. An dieser debugge ich noch, da ich da mit der SPI-
Selekt- Logik probleme habe. (p.s. Konnte die aktuelle Version der
Firmware aus Zeitgünden noch nicht testen...).
Von Links kommt das Kabel von der Netzteilplatine rein, welche ich für
dieses Projekt ebenfalls selbst erstellt habe.
Ich habe das ganze mit KiCad entwickelt und dann mal beim Chinaman je 10
Platinen in Auftrag gegeben. Bisher habe ich nur einen Satz platinen
wirklich bestückt. Ich bin noch dabei alle Funktionen durchzutesten.
Aber der Scrat- Anschluss an dem hier interesse besteht, funktioniert
bei mir Problemlos mit 2 verschiedenen Fernsehern. Für die, die kein
KiCad installieren möchten, habe ich den entscheidenen Ausschnitt aus
dem Schaltplan als JPG extrahiert.
Wie man sieht habe ich das Composite- Signal nicht auf Pin 20 sondern
auf Pin 19 der Buchse gebracht. Auch das ist beim Scart- Kabel über
Kreuz und ich hab lange rumgesucht bei meinem ersten Verauch um das raus
zu bekommen :-) Dachte immer, ich hätte bei meiner ersten, noch selbst
geätzten Platine irgendwo einen anderen Bug...
Hoffe ich konnte helfen.
Grüße
Frank
Haben Sie bemerkt, dass die Scart-Schaltplan in Jörgs Website ist
falsch? zwei der Farben müssen getauscht werden. Also das schematische
funktionierte gut für Sie?
Ich muss Kuppel haben einige Fehler auf mir, denn ich kann es nicht
laufen Farbe auf den Scart.
Ich habe noch mal nachgeschaut, im Schaltplan "Uni auf Scart" sind
wirklich Rot und Grün vertauscht. Das werde ich in den nächsten Tagen
korrigieren. Ursache dafür ist, dass ich den Uni-Anschluss damals erst
anders geplant hatte. Der Schaltplan mit Scart direkt, den wohl die
meisten Nachbauer benutzen, hat diesen Fehler nicht.
Läuft der Scart-Anschluss mit dem BAS-Signal stabil in S/W (Ohne
Austast-Signal an Stift 16 des Scart)?
Jörg
Wenn ich richtig verstehe Ihre Frage (Google Translate), Die B &
W-Signal funktioniert ok durch den Scart-Anschluss. Es ist nur das
Farbsignal, das nicht funktioniert (vertikal und horizontal sync
Verlust).
Wenn ich einen RGB zu Composite-Video-Chip von außen (wie der AD724),
dann färben Composite-Video kommt aus ok.
Aber die AD724 kommt RGB als auch H-Sync und V-Sync-Signale als Eingabe.
Es scheint irgendwie, dass es ein Problem mit dem Fernseher, um die
H-Sync und V-Sync-Signale auf den Scart-Version ohne den AD724 zu
erkennen.
Es gab seinerzeit mindestens 2 Leute die sich daran versucht haben,
ChipBasic nach C zu portieren. Aber wahrscheinlich sind sie daran
gescheitert, würde mich auch nicht wundern. Es fängt schon damit an,
dass ich bestimmte Register als Konstanten benutze (const_0,const_1)
oder aus Geschwindigkeitsgründen für die Videoausgabe reserviere
(vline_l/vline_h). Außerdem wimmelt es von Stack-Manipulationen, um
Codegröße zu sparen. Ohne diese und andere "Tricks" würde das Ganze auch
in ASM nicht in das Flash passen. Ich stecke jetzt nicht soweit drin,
aber ob der Compiler erkennt, dass an anderer Stelle die Register in der
gleichen Reihenfolge vom Stack geholt werden und bei zeitunkritischen
Stellen einfach dorthin gesprungen wird anstelle dieselbe POP-Orgie
wieder zu veranstalten.
Auch beim "Nachfolgerprojekt" (mit anderem Controller) bin ich nach
einem kurzen Ausflug nach C (das nutze ich praktisch nur auf dem PC)
wieder zu ASM zurückgekehrt. Allerdings wird es da Systemschnittstellen
geben, über die man Anwendungen problemlos auch in C schreiben kann.
Jörg
Hi Jörg,
ich kann da echt nur den Hut vor ziehen!
In C würde das mit Sicherheit nicht in den µC passen!
Aber ich finde es schade das ich den ASM Code nicht so gut lesen kann
wie eben C Code...
Es hapert ja wie gesagt schon an den Farben!
Beispiel 1:
Ich habe die Zeilen im Editor blau gemacht.
Der Hintergrund ist aber trotzdem schwarz. Und zwar so, dass zwischen
den Blauen Zeilen im Editor immer noch schwarze Striche zu erkennen
sind. Blöd, wenn man alles blau haben will, man aber nicht die Farbe des
Hintegrund findet.
Beispiel 2: ich finde nirgends die Farbinformationen der Leiste mit den
Funktionstasten (EXIT, LOAD, SAVE, etc.)
Ähm, wie verhält sich das eigentlich mit dem Bibliotheken?
Wenn ich jetzt den Tile/Sprite nutzen will, sagt er mir, die Bibliothek
ist nicht vorhanden! Wie geht denn das?
Hallo Dominik,
1. Während der Zeilenzwischenräume (linien 10 und 11) wird kein Video
ausgegeben, daher beliben die Zwischenräume schwarz. Um das zu ändern,
müsste man das Video-out an der richtigen Position auf blau schalten und
dann auch wieder an der richtigen Position am Zeilenende auf schwarz.
2. Die Farben für die Menüs sind in libmio/library.asm ab dem Label
libmio_menu_at fest codiert.
3. Viedotreiber funktionieren generell nur auf Programmplatz 8, da die
Einsprungadressen fix sind. Um den Tilemode zu nutzen, muß
*tilemode.bin* an Programmplatz 8 geladen werden. Dann sollte es auch
klappen.
Jörg
Hi Jörg,
danke schön!
Das mit den Farben hab ich jetzt gefunden!
Jetzt hab ich aber noch andere Grundsatzfragen zum Thema asm:
1. Farben
Woran sehe ich, welche Farbe 0x80 das ist? oder das: 0x2e
2. Api
In der Doku sind die Api beschrieben. Wie werden diese denn benutzt?
3. Seriell
Kann ich, den CB Computer an einen PC anklemmen und ohne TV mit diesem
kommunizieren? In der Doku steht was mit dem seriellen Lader... press
space to start... etc. wo erscheint das dann?
Hallo Dominik,
1. Da die RGB(I)-Ausgänge an PORTC.4-PORTC.7 liegen, haben die Bits
folgende Bedeutung:
1
7 Hintergrund grün
2
6 Hintergrund rot
3
5 Hintergrund blau
4
4 Hintergrund Intensität (nur mit 16-Farb-Erweiterung)
5
3 Vordergrund grün
6
2 Vordergrund rot
7
1 Vordergrund blau
8
0 Vordergrund Intensität (nur mit 16-Farb-Erweiterung)
0x80 ist demnach schwarz auf grün und 0x2e weiß auf rot (beide Male ohne
Intensity)
2. Man muss halt die api.inc oder api_macros.inc mit includen. Steht
auch mit kleinem Beispiel in der Dokumentation (Interna). Wichtig dabei
ist auch, dass der Header (Icon, Flags) richtig konfiguriert ist.
3. Das erscheint dann auf dem PC, falls Du dort gerade ein
Terminalprogramm am Laufen hast.
Hallo Jörg,
danke für die Info!
Ja mit dem seriellen lader... das klappt irgendwie nicht, oder ich habe
irgendwas vergessen.
Chipbasic an die serielle, Terminal am PC einrichten, Chipbasic
starten... nix passiert! Muss ich den seriellen Lader auf Autostart
stellen?
ich bastel gerade hardwaremäßig ein wenig an einem Tongenerator bzw.
Synthesizer, der hinter der Soundausgabe liegt.
ich möchte versuchen den Soundkanal etwas polyphoner klingen zu lassen
und verzerrter. Erste Versuche zeigten das ich auf dem richtigen weg bin
:)
So,
ich werde jetzt mal ein Spiel programmieren und das wie folgt machen:
Titel, Sound, Grafik, Levels, etc. auslagern auf verschiedene
Programmplätze, dann ins Dataflash speichern. Auf P1 einen Gameloader
programmieren der das Spiel, bzw. seine Elemente auf die verschiedenen
Plätze legt.
Dadurch ist das ganze Spiel auf dem DF und es ist möglich viiiiel mehr
als 95 Zeilen zu nutzen.
Jörg:
Kann man noch was am Sound machen? Vlt 2 stimmig?
So ich nochmal...
Multisync ist ja nicht gleich Multisync oder?
Gibt es überhaupt einen TFT Monitor, und ich meine nicht so ein
Einbaudisplay, das die Zeilenfrequenz des CB2 kann????
Huhu?
Hier ist ja nix mehr los :((
Frage:
ich bräuchte arrays, und zwar wie folgt:
array1 = "Test"
array2 = "Test2"
...
? @2,2;array1
Wie geeeeeeht das??? :(
Blöd ist, ich kann kein Array wie folgt definieren: array(1)$=".."
mache ich es mit Data 0,"Test",0
Und schreibe Ar(0) dann wird mir nur das "T" ausgegeben.
Ich kann das Array aber nicht in eine Schleife setzen, weil mit
irgendwann die variablen ausgehen bei mehreren Arrays...
Hilfe :(
Da das Projekt von mir kaum noch aktiv weiterentwickelt wird, schaue ich
auch nur von Zeit zu Zeit hier rein.
1. Der Lader muß nur da sein, allerdings habe ich ihn mit den 38,4K an
der zweiten seriellen Schnittstelle nie getestet. Kannst Du Listings aus
dem Editor über Deine serielle Schnittstelle senden?
2. Eine zweite Stimme wird wahrscheinlich am Platz im Flash und an der
verfügbaren Zeit in der horizontalen Austastlücke scheitern.
3. Es gibt das NEC-Display (NL3224AC35-01, mittlerweise relativ teuer),
eventuell gehen die Displays aus elektronischen Rückfahrspiegeln.
4. Du kannst ja an den Anfang des Arrays eine Tabelle legen, in der die
Positionen der "Teilarrays" hinterlegt sind. Ausgabe geht nur in einer
Loop, da es kein explizites Stringhandling gibt. So in der Art (ohne
Gewähr):
Hallo Jörg,
danke für deine Antwort.
Puh... das wird hart! Es geht sich um die Portierung von "Manager" eines
Bundesligamanagers vom C64.
Da liegen natürlich alle Mannschaften als Array vor die dann abgerufen
werden um die Spielpaarungen zu generieren. Ich glaube das wird für
Chipbasic zu kompliziert und komplex... schade :(
Man müsste wirklich irgendwie sowas anlegen können wie beim C64 a la
DATA und READ und per Read den String auslesen bzw. die Konstanten...
schade!
Ich hab mir auch schon überlegt anstatt das Menü zu Beginn einen
Bildschirm a la C64 darzustellen, sprich direkt den Editor. Aber ohne
zeilennummern, die müsste man selber eintragen. Gespeichert wird dann
"per hand" auf die 8 "unsichtbaren" Plätze... etc etc etc.
Nur wäre das wieder zu umfangreich umzubauen!
Nochwas: Wovon hängt die Auflösung im textmodus ab? Könnte man nicht auf
40 Zeichen pro Zeile kommen?
Eine andere Möglichkeit wäre, das Array vom Anfang her auf 0-bytes zu
durchsuchen, ist halt etwas langsamer. Und natürlich gehen auch 50 oder
60 Zeichen/Zeile, allerdings dann nur noch monochrom (siehe
Video-Treiber). Es sei denn, Du findest eine effizientere Methode zum
Pixel ausgeben oder änderst das Timing und übertaktest den Controller
auf 25MHz. Für einen "Nachfolger" hatte ich eine Zwischenplatine mit
CPLD und einen Mega1284P verwendet, das Projekt habe ich aber inzwischen
zugunsten eines neuen Konzepts mit dem S12XE aufgegeben.
Jörg
Hi Jörg,
mal zum Verständnis:
Hätte ich 40 Zeichen pro Zeile, dann würde die effektive Zeile im Editor
auch länger oder? Dem Parser ist es doch egal wie lang die Zeile ist
oder?
Wo finde ich die Zeilenanzahl? Also es wird wohl kaum im Source stehen:
Zeilen = 32
:-)))
Das heißt, wenn ich den µC übertakte, reicht das schon aus?
Sorry wenn ich so nerve aber ich seh da im Moment ne menge potenzial und
leider kann ich nicht so gut asm.
Naja, ganz so einfach ist es leider nicht. Denn beim Speichern im Editor
werden die Zeilen schon "vorcompiliert", d.h. Schlüsselworte zu Token
und auch Zahlen werden schon in Binärform gespeichert. Hauptgrund ist
natürlich die Ausführungsgeschwindigkeit. Beim Zurücklesen in den Editor
wird das Ganze Zeile für Zeile wieder in Text gewandelt. Die
Konvertierungen erfolgen zwischen zwei 40 Byte großen Puffern, wobei
aber nur jeweils 32 Bytes genutzt werden (können). Der gleiche Parser
übernimmt aber auch teilweise das Auswerten von INPUT.
Wenn Du den Controller übertakten möchtest, um mehr Zeichen je Zeile zu
bekommen, reicht es natürlich nicht, nur einen Meg1284P und einen
anderen Quarz zu nehmen.
- Video-Timing muss angepasst werden (libmio/definitions.asm)
- Die Videoausgaberoutinen müssen angepasst werden
- Das Video-RAM muß vergrößert werden (Adressen verschieben sich)
- Die Runtime ist auf 32 Bytes lange Zeilen ausgelegt
Mehr Zeichen bedeuten entweder weniger Zeilen oder längere Programme,
was dann natürlich auch Änderungen in weiteren Teilen (Load/Save) nach
sich zieht. Außerdem wird hinterher keiner der Videotreiber mehr richtig
funktionieren, es sei denn, man passt die auch alle an.
Das ist alles irgendwie machbar. Aber schon freie Zeilennummer-Eingabe
ist mit dem von mir entwickelten Konzept unverträglich. Denn
Zeilennummern existieren nicht als solche, sondern geben nur an, die
wievielte Zeile gemeint ist. Ein GOTO 7 bedeutet halt nur, dass die
Programmabarbeitung ab dem 224.Byte des Programmes fortgesetzt wird.
Denn eine leere Zeile wird trotzdem als 32 Bytes mit Zeilenende-Token im
ersten Byte gespeichert.
Von daher wirst Du Dein Ziel auch mit ASM-Kenntnissen ohne ein
grundsätzliches Re-Design nur sehr schwer erreichen.
Jörg
Also kurz gesagt:
Ich will aus einem Fiat Panda einen BMW X5 bauen und das am besten ohne
das Chassis zu verändern?
Ok, habs verstanden... :)
Schade! Da sind halt ein paar Sachen die nicht so einfach zu ändern
sind. Leider. Mit dem Array ist schon blöd.. Wollte einen Fußballmanager
programmiern :(
Auch blöd ist: Wenn ich Linien zeichne, welche unterschiedliche Farben
haben sollen, diese sich aber berühren oder nur dicht beieinander
liegen, so vermischen sich die Farben. Ich glaube das liegt eher an der
Blockgröße 6x8 die bestehen bleibt selbst wenn ich per PLOT ein Pixel
setze oder?
Also:
1
10 PLOT 2,2,1
2
20 PLOT 2,3,2
beide Pixel werden rot anstatt einer blau und einer rot...
hallo,
Wenn Sie die Schaltpläne und das PCB in dieser Seite sehen
http://www.jcwolfram.de/projekte/avr/chipbasic2/hard.php sie stimmen
nicht überein. Bitte auf die 15, 16, 17, 18 Pins des Mikrocontrollers
beziehen. Die Sende- und Empfangssignale nicht übereinstimmen die
Leiterplatte. Welcher Weg ist der richtige, dem Schaltplan oder die
Leiterplatte?
Es gibt jetzt eine neue Version (1.50), hauptsächlich gibt es jetzt
wieder die 1200 Bps als Baudrate, daneben noch einen Bugfix bei den
Screenshots. Aus Platzgründen musste dafür die Prüfsummenberechnung auf
der Konfigurationsseite entfallen.
Jörg
- Das mit den Pixeln ist normal bei Modus 0 und 1, wenn jedes Pixel
seine eigene Farbe haben soll, gehen nur die Videomodi 2 und 3. Denn
wenn ein Attribut-Byte für mehrere Pixel zusändig ist (2x2
Pseudografikpixel im Modus 0 bzw. 8x8 Pixel im Modus 1), bleibt ja gar
nichts anderes möglich.
Hallo Jörg ist das technisch möglich über ein ladbares Binär Programm
ein Update der chipbasic2 Firmware über serial zu flashen,das man nicht
immer an den isp rann muss(so wie der damalige Bootloader)?
Vielen Dank
Patrick
Hallo Patrick,
Ja, das geht. Und zwar über die API-Funktion api_wpage. Die RAM-Adresse
ist nicht mehr in in der API-Beschreibung im Y-Register, sondern liegt
fest bei Array-zelle 512. Je Aufruf werden 256 Bytes ab dem Z-Register
gelöscht und beschrieben. Während dieser Zeit werden keine Interrupts
bedient. Zu beachten ist dabei, dass es gegenüber dem alten Bootloader
damit möglich ist, das System komplett zu "zerschießen".
Jörg
Ich habe mal eine frage zu der FBAS Schaltung. Ich habe sie jetzt
mittlerweile zum 2. Mal aufgebaut und ich bekomme einfach kein signal.
Der fernseher erkennt zwar etwas und schaltet um auf schwarz aber es
kommt kein bild.
Wenn ichnkurioser weise die masseverbindung trenne dann erkenne ich ein
flackerndes buntes bild. Mehr nicht.
Wo kann hier der fehler sein? IC kaputt? Quarz kaputt?
Am Scope erkenne ich zwar ein signal aber es sieht alles andere als ein
fbas signal aus.
Hiiiilfe
Ich muss dazu sagen, dass ich das ganze per scart adapter an den
fernseher angeschlossen habe. Kann das fbas so gar nicht funktionieren?
Bas jedoch schon?
Hallo Dominik,
es wird kein FBAS-Sinal erzeugt, sondern BAS+RGB. Ich würde folgende
Vorgehensweise vorschlagen:
Wenn Du Pin16 des Scart-Steckers nicht beschaltest (oder den 180 Ohm
Widerstand entfernst), solltes Du ein Graustufenbild sehen. Wenn nicht,
Aufbau kontrollieren, insbesondere die verschiedenen Masseanschlüsse.
Wenn das Graustufenbild OK ist, Verbindung zu Pin16 herstellen. Wenn die
RGB-Signale richtig verdrahtet sind, sollte jetzt ein Farbbild auf dem
TV zu sehen sein.
Bei allen mir bekannten TVs muss man exlizit auf AV umschalten, damit
man ein Farbbild bekommt. Da liegt daran, dass die Spannung für die
AV-Umschaltung fehlt. Bei manchen schaltet die RGB-Umschaltung auch ohne
AV um, dann entstehen oft irgendwelche "Flackereffekte".
Jörg
Hallo Jörg,
schön das du auch noch da bist!! :)
Du hast mich falsch verstanden. Ich habe mir die FBAS Schaltung
nachgebaut mit dem MC1377 IC. Die wurde ja hier von Ralf - Rainer Ratke
vorgestellt.
Zuerst habe ich den Computer per BAS an den fernseher gesteckt. Also:
BAS -> Cinch/Scart Adapter -> Fernseher.
Funktioniert. Ich habe ein s/w Bild.
Jetzt habe ich das FBAS Signal aus der Wandlerschaltung genauso
angeklemmt.
Der TV erkennt zwar etwas, schaltet auf schwarz aber es kommt kein
Bild!!!
Gruß
Dominik
Sooo.... habe annäherend das gleiche problem wie Alex ganz oben gehabt.
Schwarzer linker rand auf dem bild. Nachdem ich die gemeinsame masse
getrennt habe. Anscheinend benötigt die fbas schaltung eine seperate
Versorgung. Na ganz toll. Dabei wollte ich sie mit auf dem Board haben.
Hätte nicjt gedacht, dass das sl kompliziert wird. Schade das der Ralf
sich hier nicht mehr meldet.
Hi Jörg,
ich bin ja immer noch am überlegen ob man nicht irgendwie ein GLCD
einbinden kann als TV Ersatz.
Was wäre der Computer ein Hammer, wenn er autark laufen würde und ich
den Editor auf einem GLCD laufen lassen könnte.
Würde das theoretisch gehen? Da ja ein GLCD eben als solches fungiert
und eigentlich keine Strings verarbeiten kann oder würde es eher mit
einem LCD funktionieren?
Gruß
Dominik
Moin,
habe gestern spaßeshalber mal den Computer per YPbPr an den TV
geklemmt. Also Bild war zu sehen! Sehr scharf sogar! Aber dennoch in s/w
und es flackerte!
Könnte man da was am Timing machen Jörg?
ich suche nach Lösungen für Farbdarstellung ohne Scart nutzen zu müssen.
Habe jetzt mittlerweile meinen 5. oder 6. Computer aufgebaut ohne das es
langweilig wird. Diesmal mit Onboard-Sound! Genial!
Hallo Dominik,
als LCD hatte ich damals das NEC NL3224AC35 getestet, das braucht
einfach RGB und Sync. Eine spätere (nie veröffentlichte) Variante des
BASIC-Computers mit Daughterboard (Mega1284P + CPLD) konnte auch u.a.
320x240 Displays mit 8 Graustufen ansteuern, das Projekt hatte ich aber
in einem frühen Stadium zugunsten des AX81 aufgegeben.
Wenn das Bild flackert und einen sehr starken Kontrast zeigt, kannst Du
probieren, einen 75 Ohm Widerstand zwischen Videosignal und Masse zu
schalten.
Am Timing kann man schon noch einiges machen, insbesondere lässt es sich
so verstellen, dass hinterher gar nicht mehr geht ;-) Aber hier würde
ich auch nicht zuerst den Fehler suchen, denn selbst mit meinem simplen
CPLD-FBAS-Encoder hat das mit zwei verschiedenen TVs ohne Probleme
geklappt.
Jörg
Hi Jörg,
ja die Frage ist ob meine FBAS Schaltung eine getrennte
Spannungsversorgung braucht. Denn erst wenn ich die Masseverbindung
auftrenne sehe ich immerhin ein Bild. Das ist komisch! Solange aber
keiner der Verantwortlichen der FBAS Schaltung hier antwortet sehe ich
keine Chance auf eine Lösung :)
Zum Thema flacken: ich habe nur rot grün und blau an den TV
angeschlossen als YPbPr Signal. Ohne Videosignal, das wird nicht
gebraucht. Das funktionierte!! Bis eben auf das flacken und s/w.
Und wie sieht es mit einem furznormalen GLCD aus a la DIP128-6 mit dem
beliebten KS controller?
ich meine jetzt nicht die Verwendund als handheld, sondern die
Darstellung des Editors auf diesem GLCD.
> ich habe nur rot grün und blau an den TV> angeschlossen als YPbPr Signal. Ohne Videosignal ...
Und woher soll dann die Synchronisation kommen? Irgendwelches Geflacker
auf dem Bildschirm würde ich jetzt nicht unbedingt mit "funktioniert"
betiteln.
Der Editor hat 23 Zeilen zu je 35 Zeichen. Wie soll das mit einem 128x64
LCD gehen? Mit Braille-Schrift um 90 Grad gedreht käme man auf
theoretische 21 Zeilen zu je 32 Zeichen, lesbar ist das aber nicht ;-)
Jörg
Bei YPbPr brauchst du kein extra Signal mehr! Es reichen drei
Leitungen! Aber es war eh nur zum Spaß gedacht. Ich glaube dafür müsste
man das Timing in der Software ändern! Jedenfalls war die Bildschärfe um
einiges besser!!
Ja ok, Thema GLCD kann man abhaken :) Naja man hätte die Editorzeilen ja
scrollen können! :) Zumal du dann auch keine probleme mehr mit den
ganzen TV Timing Sachen hast!
Hi Jörg,
Hab ne frage zum ADC.
Wenn ich das Oszi aufrufe zeigt es mir standardmäßig 5volt an obwohl nix
anliegt. Port A liegt aber die ganze zeit auf high. Warum? Schreibe ich
bei programmbeginn ein out 0,0 dahin dann beginnt liegt der port auf low
und die linie liegt bei 0 volt.
Aber: lege ich jetzt 2,56 volt an dann zeigt er mir 5 volt an.
Wie bekomme ich es hin, dass bei angelegten 2.56 volt auch nur ein adc
wert von 512 angezeigt wird und nicht 1023???
Hallo Jörg ,gibt es eine Möglichkeit die xmem 64 Erweiterung mit
Standard TTL ICS Aufzubauen, bzw hast du evtl einen Schaltplan?
Leider komm ich an den xillinx Baustein nicht ran geschweige hab ich die
Möglichkeit die Platine zu ätzen
Vielen Dank
Gruß Patrick
@Dominik
welchen Controller verwendest Du und funktionert die Anzeige zwischen 0
und 2,56V richtig? Evtl. stimmt die eingestellte Referenz nicht, hab im
Moment keinen "freien" CB2, um das zu verifizieren. Vllt. komme ich im
Laufe der Woche dazu.
@Patrick
Möglich wäre es schon, dafür müsste man den VHDL-Code in eine Schaltung
"übersetzen". Eine Schaltung an sich gibt es nicht, da die Logik in VHDL
geschrieben ist.
Jörg
Hallo Jörg,
das wäre super!!
Ich habe den 644er. Mich wundert es halt, dass der Port A ständig auf
high steht und ich erst mit dem DIR Befehl ihn auf Eingang setzen muss
bevor ich das Oszi verwenden kann.
zwischen 0 und 2,56 V habe ich noch nicht getestet.
Danke Jörg dann werde ich mal versuchen den Code umzusetzen,
Dann hab ich noch eine Frage ,wie kann ich eine RTC am besten
einbinden,hab noch eine pcf8583
Aus einen alten Videorecorder ,mit icomm hat das leider nicht
funktioniert
Gruß Patrick
Also Jörg...
2.56 volt am adc entsprechen 1023.
Das ist in meinem fall mies. Hab einen temp sensor angeklemmt und 12
volt spannungsüberwachung per spannungsteiler sowie ein poti. Adc0-2
Wie bekomme ich nun 5 volt referenzspannung anstelle der 2.56
momentan???
Hiiiiilfe
Nabend,
so, ich habe immer noch Probleme mit der blöden FBAS Schaltung. Immer
noch kein Bild! Kann denn hier niemand helfen???? Wo ist denn der
Entwickler der Schaltung? Muss man den CSYNC/HSYNC Jumper schließen??
Hiiilfe...
@Jörg
Hast du nicht noch zufällig eine FBAS Schaltung von dir rumfliegen??
Wenn Du Composite Sync brauchst, muss J2 offen sein, bei HSYNC
geschlossen. Bei CSYNC enthält das Saignal ein Gemisch aus horizontalem
und vertikalem Sync.
An eigenen Projekten kann ich nur das Folgende anzubieten, habe aber
selbst seit Jahren nichts mehr damit gemacht...
http://www.jcwolfram.de/projekte/vhdl/fbas_enc/main.php
Jörg
Mal ne andere Frage Jörg...
Ich will 12 volt messen. Bzw. 10-15 volt und habe einen spannungsteiler
genommen. 20k und 3,3k.
Normalerweise würde ich so rechnen:
ADCWert × 5 / 1024 × spannungsteilerverhältnis
Leider kann der computer ja keine kommazahlen.
Nutze ich aber das format !22 oder !44 oder was auch immer, dann kommt
nicht der richtige wert raus. Ich müsste meine zahlen so stark ändern
das zwar ein annähernd richtiges ergebnis kommt, der wert sicj aber
nicht im verhältnis zur soannung ändert.
Wenn ich folgendes eingebe:
ADCWert × 5 / 102 × 71 / 10
Dann wird mir ca. 12 volt angezeigt aber wie gesagt der wert ändert sich
kaum.
Wie kann ich das vernünftig machen???
Für solche Aufgaben gibt es den SCALE Befehl, der rechnet intern mit 32
Bit.
1
SCALE Variable,Y0,Y1,X0,X,X1
Bei 3,3K und 20K liegen bei 15 Volt Eingangsspannung 2,12V am ADC-Pin
an. Bei 2,56V Referenzspannung und 10Bit sollte das einen ADC-Wert von
850 ergeben. Das Ganze könnte dann so aussehen
Moin Jörg,
Ah ok danke...
Ja ich hab den ADMUX aus 5 volt referenz eingestellt. Ich rechne in
meinen C Projekten immer mit 5 volt ref.
Was mir halt wichtig ist wäre eine dezimale Ausgabe: 12,4 volt
Zum beispiel. Ich teste das mal.
Hi Jörg,
funktioniert!!
Hatte mich zwar vertan, Spannungsteiler ist 22k und 3,3k aber egal...
das wäre dann anstatt 850, 401
Auf jeden Fall funktioniert es! Danke.
hab an SCALE gar nicht gedacht!
Mahlzeit,
ich möchte Euch mal den Stand der Dinge zeigen. Ich habe etwas an der
Hardware und der Software geschraubt. Bin aber noch lange nicht fertig.
Kompakt und modular aufgebaut lässt sich der Computer perfekt im mobilen
Einsatz als Regel- und Steuercomputer einsetzen.
Hardwaremäßig wurden alle Schnittstellen nach außen geführt und sind
direkt erreichbar. Ein LED Treiber sowie ein LED Baustein stellen die
parallele Schnittstelle visuell dar.
Der Sound lässt sich per Jumper auf Intern oder Extern stellen. Einen
Port Expander sowie eine Relaiskarte habe ich aufgebaut und erfolgreich
getestet.
Softwaremäßig habe ich die Farben für den Schwarz/Weiß Betrieb angepasst
und die Menüs etwas überarbeitet, da es ohne Farben zu überladen und
unübersichtlich wirkt. Anstelle bunter Felder für die Funktionstasten
gibts nun deutliche Bezeichnungen wie "F1=Edit".
Gruß
Dominik
@Jörg
Nur mit dem seriellen Loader funktioniert bei mir irgendwie nicht.
Ich kann Programme über die serielle empfangen und senden aber der
Loader meldet sich jedenfalls nicht.
och, hier ist ja nichts mehr los!
Jörg, lebst du noch?
So langsam wird es eng, was die Beschaffung der dataflash angeht.
Mittlerweile gibt es dir 81 und 41er nicht mehr. Und die erhältlichen
liefen ja nicht erfolgreich mit dem Computer.
Was kann man jetzt tun?
Ich hatte das Glück mein Dataflash aus einer simens gigaset-basisstation
mit Anrufbeantworter ausschlachten zu können. Vieleicht gibt es da noch
möglichkeiten.
Patrick
Die Frage ist ob die neuen Typen unterstützt werden. Naja wie auch
immer. Ich hab ja noch 2 rumfliegen.
Ich habe jetzt auch endlich erfolgreich die FBAS Schaltung aufgebaut.
Jetzt gibt es Farbe über den Bas Anschluss.
Naja, das Projekt ist mittlerweise 7 Jahre alt. Wenn die neuen Typen
nicht funktionieren (hat das jemand ausprobiert) ließe sich das Programm
sicher anpassen. Es ist ja Open Source. Wichtig ist auf jeden Fall, dass
der AT45DB081E scheinbar nicht mehr 5V-tolerante Eingänge hat. Also
braucht man entsprechende Pegelwandlung, z.B. durch Spannungsteiler.
Jörg
Hallo Jörg,
Schön das du noch da bist. Der C64 ist auch uralt und trotzdem gibts ihn
noch. :)
Ich werde mir mal einen neuen flashbaustein bestellen und mal schauen
was sich machen lässt. Wäre schade wenn es nicht gehen würde.
Kurze frage: die color funktion kann ja 2 parameter haben. Die farben
wiederholen sich ja sobald man die Zahl 16 überschreitet. Wo ist das
festgelegt?
Jetzt habe ich noch ein merkwürdiges Verhalten festgestellt.
Ich habe einen 10 pol und eine 6 pol Wannenstecker auf dem Board für die
ISP. Auf der 6 Pol sitzt mein MySmart USB AVR Programmer.
Auf der 10 pol ist der Dataflash verbunden. Mit einem Flachbandkabel.
Der DF wird erkannt, kann aber nicht lesen und schreiben. Das gibt nur
Fehler. Klare Sache: Der Programmer muss dafür ab und darf nicht
parallel angeschlossen sein.
Jetzt wird der DF nicht mehr erkannt. Erst wenn ich ihn direkt auf das
Board stecke. Das heißt: Das Kabel ist zu lang! Kann das sein? Ist die
ISP/SPI so anfällig bei langen Datenstrecken?
Man ey...
10 cm kabel am Dataflash und er gibt eine Fehlermeldung aus. Dataflash
direkt auf das Board gesteckt und alles funktioniert. Das kann doch
nicht wahr sein.
Ich muss dazu sagen, denselben DF hatte ich mal an einem anderen CB2
Computer mit 20cm kabel und es funktionierte. Irgendwie stimmen die
Pegel nicht.
Hab den Atmega1284 drauf mit der include von AVR und in der main die
.org Anweisungen geändert bzw. Die neue main.asm version 1.50 genommen.
So... bräuchte echt mal Hilfe!
Ich habe festgestellt, dass aus dem MOSI Pin am Atmega nix rauskommt. Da
liegen 0 Volt. Kann ja dann gar nicht funktionieren.
Stecke ich einen Atmega644 mit der CB2 Software drauf und messe, dann
liegen an allen Pins 5 Volt. Auch an dem MOSI.
Versuche ich aber vom Dataflash zu laden, kommt die Fehlermeldung und
der Mosi Pin ist wieder bei 0 Volt!
Auf meinem 2. CB Board funktioniert es tadellos! Also muss doch
irgendwas an der Schaltung verkehrt sein. Ich weiß aber nicht was.
Wonach soll ich gucken??
Moin,
ich wieder...
Also:
mit einem kurzen, 5cm Kabel funktioniert es.
Bei meinem anderen Basic Computer funktioniert es aber auch mit einem
20cm langen kabel.
Das heißt, auf dem jetzigen Board scheinen sich die Pegel irgendwo im
Kabel zu verlieren. Sprich beim lesen/schreiben.
Warum ist das so?
Software ist die Gleiche. Hardware auch. Das flashen vom µC funktioniert
ja auch.
Irgendwo muss sich eine Spaßbremse versteckt haben. ich weiß aber nicht
wo!
So, Kommando zurück!
ich habe jetzt soviele Posts geschrieben, dass ich nach jedem nochmal
nachgeguckt habe auf meinem Board.
Ich hatte eine schlechte Masseverbindung. Die ISP Wannenstecker waren
nur an das gehäuse einer der 9 pol Buchsen angeschlossen. Die lagen zwar
auch an Masse aber als ich die ISP/SPI dann direkt an die Masse geklemmt
habe ging alles wieder!
Puh...
Schade das hier dennoch so wenig los ist
@Jörg
falls du noch da bist:
ich würde gerne der SPI eine weitere Geschwindigkeit zuweisen können in
der Configpage.
Laut asm wird hier glaube ich nur getoggled bei der Auswahl, da ich ja
nur 2 Einträge auswählen kann(5MHz und 128kHz).
Wie bekomme ich einen weiteren Eintrag rein, der mit ausgewählt werden
kann?
Was muss ich in der library.asm unter set config for I2C and SPI ändern?
Dazu brauchst Du ein freies Config-Bit (GPIOR1,3 oder GPIOR1,7 sollten
gehen). Dann in der library.asm unter libmio_setconf: die SPI abhängig
von diesem Bit konfigurieren. Und zum Schluss noch in der configpage.asm
die Auswahl mit Tasten und die Ausgabe der gewählten Geschwindigkeit
hinzufügen.
Das sollte reichen.
Jörg
Danke Jörg,
so ähnlich habe ich mir das auch schon gedacht.
Kann ich denn irgendwie dieses Bit hochzählen bei jedem tastendruck und
abhängig vom Wert im Bit die unterschiedlichen SPI Geschwindigkeiten
anzeigen lassen?
Und wenn ich speicher dann sehe ich welcher Wert gerade das Bit hat und
setze dementsprechend die SPI?!
Bin noch nicht so asm bewandert.
Hi Jörg,
Noch eine Frage:
Ich wollte eine zusätzliche Infoseite einbauen. Kopie von infopage.asm.
und include dieser datei.
Da hat er aber gemeckert wegen den .org Anweisungen.
Ich habe dann den inhalt als weitere sprungmarke auf die bestehende
infopage eingefügt. Da hat er auch gemeckert.
Sind den seiten spezielle größen zugeordnet? Wie ändere ich das, damit
ich noch eine seite einfügen kann? Wenn ich die orgs erhöhe dann habe
icj probleme mit der tastatur.
Ich habe jetzt das Problem mit dem Dataflash gelöst. Es lag wohl doch
nicht an der Masse!
Da ich auf dem Board ebenfalls die RGB->FBAS Schaltung drauf habe,
welche mit 12 Volt läuft, giong ich von Problemen bei der
Spannungsversorgung aus.
Auf meinem Board arbeitete erst ein 5V Schaltregler mit 500mA.
Aufgefallen ist mir, dass der Dataflash gefunden wurde, wenn ich ein 9
Volt Steckernetzteil mit 600mA nutzte. Nur leider konnte man dann wenig
sehen auf dem Monitor, da die FBAS Schaltung ja 12 Volt benötigt.
Mit einem 12V Steckernetzteil und 800mA lief dann das Bild wieder aber
der Dataflash wurde nicht gefunden.
Ich habe dann den Schaltregler gegen einen Linearregler mit 1A
ausgetauscht. Das Verhalten wurde besser. Zusätzlich habe ich der
Dataflash Spannungsversorgung einen eigenen Schaltregler spendiert und
siehe da: Jetzt gibt es keine Kommunikationsprobleme mehr. Selbst mit
den geforderten 12V.
Ich frage mich natürlich inwiefern der Dataflash nun abhängig ist von
einem 9V, 600mA netzteil und einem 12V, 800mA Netzteil, obwohl er seine
Spannungsversorgung aus einem 5V regler bezieht. Und ob der nun 500mA
kann oder 1A... soviel braucht der Dataflash doch gar nicht.
****************
Zum .org Problem:
Ich habe testweise das XModem mal rausgeschmissen und dadurch in dem Org
Bereich Platz bekommen für ein zusätzliches Menüicon + dazugehöriger
Seite.
Spaßeshalber habe ich die Benutzeroberfläche mal dem guten alten Windows
2 angepasst :)
Im Moment bastel ich noch weiter, sofern meine extrem geringen asm
Kentnisse mich lassen!
@Jörg
Gibt es eine Möglichkeit das externe EEProm ähnlich wie den Dataflash
aus dem menü heraus anzusprechen um zu sehen wieviel belegt ist?
Bezüglich SPI Geschwindigkeit ändern...
die SPI holt sich ja den Wert vom dritten Bit von r18.
ich habe testweise r18 mal raufzählen lassen und konnte so mehrere
Geschwindigkeiten anzeigen. Es haben sich aber auch andere Werte in der
Config geändert da ja alle über das r18 arbeiten.
ich weiß nicht was du mit GPIOR1,3 meinst? Ich habe die Version 1.45
drauf. Für die SPI benötige ich aber kein Bit weil ich ja nicht togglen
will sondern mindestens 4 Werte anzeigen lassen will. Theoretisch weiß
ich wie es geht. Also in C. Ich würde einfach eine Variable nehmen und
die hochzählen lassen. Und davon abhängig ist die SPI Geschwindigkeit.
Nur leider habe ich keine Ahnung wie ich das in asm übertragen soll.
Welches Register wäre denn dafür frei??
Mit den .org Direktiven werden meistens Tabellen auf durch 256 teilbare
Adressen gelegt. Das ist dann meist mit weniger Code und mehr
Geschwindigkeit verbunden, da u.U. das Addieren wegfällt. In den Lücken
zwischen den Tabellen ist dann der Code drin. Das Ganze ist halt recht
voll, in der 1.50er Version sind insgesamt gerade mal 368 Bytes (das
sind rund 0,56%) frei. Das ist halt im Laufe der Zeit so "gewachsen". Um
neue Funktionen einzubauen muss man alte entfernen oder bezüglich Platz
optimieren oder einen größeren Controller nehmen.
Auf dem EEPROM gibt es ja keine Dateien, wie soll da die
Belegungsanzeige aussehen? Platz dafür wäre wahrscheinlich sowieso
keiner. Aber Dich hält niemand davon ab, das in BASIC zu realisieren und
auf einen der freien Programmplätze zu legen.
So in der Art Videomode 1 + Rechteck + farbige Punkte für Werte <> 0xFF
Zum Thema SPI-Konfiguration könntest Du zwei benachbarte Bits aus dem
dritten Config-Byte (PCMSK0/tempreg3) verwenden. r18 ist ja nur der
temporäre Wert während die Config-Page angezeigt wird, ansonsten ist der
Wert über GPIOR0 verfügbar. Allerdings sind hier alle Bits belegt. Das
zweite Config-Byte liegt in r19/GPIOR1, hier sind m.W. noch Bit 3 und
Bit 7 frei. Bit 0-2 ist die EEPROM-Adresse und Bit 4-6 das gewählte
Autostart-Programm. Vom dritten Config-Byte (tempreg3/PCMSK0) ist nur
Bit 0 belegt mit der Erweiterung der seriellen Geschwindigkeiten.
Jörg
Danke Jörg,
Ja da liegt noch Arbeit vor mir.
Ich habe nun noch ein Schmankerl eingefügt. Sobald man ein Programm als
Textdatei speichert ändert sich dementsprechend auch das Icon.
Dabei habe ich mal wieder festgestellt wie wenig Platz noch im Flash ist
:)
Musste leider die apis dafür rausschmeißen.
Gruß
Dominik
Schade... wenn ich den Border im Editor auf blau setze, gehen die
einzelnen Programmzeilen trotzdem nach rechts bis zum Bildschirmrand und
überlappen die Borderfarbe.
Warum ist das so?
Moin,
eben den AT45DB081E getestet. Funktioniert nicht. Wird nicht erkannt!
Laut Datenblatt sehe ich aber nicht, dass die nicht 5V tolerant sein
sollen. Die In/Out's laufen mit LOW Vcc*0.3 bis HIGH Vcc+-0.6
Also das sollte funktionieren! Wobei das E in der bezeichnung auch nur
die Revision ist.
Hilfe Jörg!!!
Nochmal zum Editor:
Trotz anderer Hintergrundfarbe der Editorzeilen und Border, ist der
rechte Randbereich unangetastet dessen. Immer noch schwarz hinterlegt.
wieso?
Hilfe Jörg die Zweite!!
ext. Eeproms:
Ist es viel Aufwand eine Funktion einzubinden, die 1 oder 2 oder mehr
Programme wieder in das externe Eeprom schreiben kann?
*****
Ich habe jetzt 3 verschiedene Programmicons implementiert.
- Leeres Blatt = Kein Programm
- beschriebenes Blatt = Textdatei
- blauer Computer = BAS Programm
Außerdem lässt sich nun auf der Configpage zwischen 2 verschiedenen
Farbschmemas umschalten. Dark und Bright. Dark ist das original Design
und Bright das vom Screenshot. Genial :)
Wenn noch jemand Flash übrig hat, bitte her damit! :)
1. Was ist bei Dir Vcc+0,6V? Die maximale Versorgungsspannung liegt bei
3,6V und damit käme man höchstens auf 4,2V. Oder betreibst Du den
DataFlash direkt an 5V? In meiner Schaltung habe ich eine grüne LED
dazwischengeschaltet, um ca 3-3,3V am Flash-Baustein zu haben. Bei den
"alten" steht im Datenblatt explizit drin, dass die Eingänge 5V tolerant
sind, das betrifft aber nicht die Versorgungsspannung.
2. Am Ende der Editorzeilen wird das Videosignal auf 0 gesetzt
(vidm_tvm.asm Zeile 311-> out PORT_C,const_0). Das kann man schon
ändern, halt ein passendes Register vor der Videosausgabe mit dem
Border-Wert laden und dann ausgeben. Die Editorzeilen werden aber nicht
genau die gleiche Länge wie der "Rest" haben.
3. Ja, es ist viel Aufwand. Man braucht ein Auswahlmenü für mehrere
Programmplätze, eine "Weiche" für DataFlash und EEPROM, ggf.
unterschiedliche Bereiche für Programmsopeicher und XPOKE...
Da wäre es wahrscheinlich einfacher, auf SD-Karten umzustellen (Pages
nur zur Hälfte beschreiben und ggf. das Wear-Levelling für den DataFlash
rausschmeißen).
Jörg
Hi Jörg,
stimmt du hast Recht. Das Datenblatt vom "alten" Flash zeigt nur die
Minimalwerte an den Aus und Eingängen.
Beim neuen Typ ist bei maximal Vcc+0.6 V als Highpegel Schluss... ach
verdammt! :(
Also eine SD Karte wäre schon was tolles. Man hätte viel mehr
Möglichkeiten der "Datensicherung" da man eher SD Karten bekommt als den
Flash.
Wieviel Aufwand wäre der Umbau? Unterscheiden sich die beiden Flasharten
SD/DF sehr oder könnte man ggf. in der Config aussuchen ob DF oder SD?
Das wäre natürlich der Luxus!
Hi Jörg,
wenn du mir sagst, wie man die libdfl anpassen muss für SD Karten, dann
versuche ich das!! SD Karte wäre soooooooo genial!!
Anbei nochmal ein paar Fotos...
Na wer kennt noch das Spiel OEL vom C64? Oder Bundesliga Manager? :)
Da ich es jetzt geschafft habe Stringarrays vernünftig zu verarbeiten,
kann ich solche Spiele nun mühelos portieren. Ok, 95 Zeilen werden nicht
reichen aber selbst das Problem bekommt man ja gelöst.
Außerdem noch 2 Fotos vom aktuellen Menü mit 3 verschiedenen Icons.
Und der Editor im Expertenmodus (lässt sich umschalten) Original und
Expert. Da kommt ein wenig C64 Flair auf und man hat eine bessere
Übersicht.
Aktueller Stand... alles auf Atmega1284 Basis
Rausgeflogen sind:
- screenshot Funktion
- api Funktionen
- Speicherung der Cursorposition im Editor
- XModem
- Keyboard Testfunktion im Intro
Hinzugekommen sind:
- 3 versch. Programmicons (.bas Programm, leeres Projekt, Texdateien)
- Systempage (Keyboardlayout, Videosignal, freier speicherplatz DF,
etc.)
- Editormodus wählbar (standart, expert)
- Menü im Windows 2 Look
Ich will und werde noch ein paar neue sachen hinzufügen die meiner
Meinung nach das Gesamtkonzept verbessern. Dafür musste ich eben ein
paar Sachen rauswerfen die ICH jedenfalls nicht nutze.
Schön wäre jetzt nur noch eine SD karten Unterstützung.
Wenn Interesse besteht lade ich natürlich auch die Sourcen mal hoch mit
Doku.
Vlt wäre ein neuer Thread a la Atmega1284 dafür geeignet wenn Jörg
nichts dagegen hat?
Natürlich kannst Du einen neuen Thread aufmachen, der hier ist eh schon
recht lang. Denn ich werde an dem Projekt (außer Fehlerbereinigung)
sowieso nichts mehr machen. Aber ich hätte noch 8 DataFlash-Bausteine
AT45DB081B-RC (OVP im Gurtabschnitt) übrig, bei Interesse bitte PMail an
mich.
Jörg
Und das API brauchst Du auch. Denn die Binärprogramme nutzen auch
Systemroutinen. Da sich die Position dieser aber bei Änderungen
verschieben kann, gibt es das API. Das liegt an einer festen Stelle und
enthält Sprünge zu den eigentlichen Systemroutinen. Dass es ein bisschen
"durcheinander" aussieht liegt daran, dass neue Funktionen
logischerweise nur ans Ende gestellt werden dürfen.
PS: Ich habe gemerkt, dass beim Source-Archiv der aktuellen Version die
Sources für die Treiber/Binärprogramme fehlen. Das werde ich in den
nächsten Tagen korrigieren.
Jörg
Mhh okay,
Dann schaue ich mal ob das Api noch passt mach meinen ganzen Änderungen.
Ansonsten lasse ich die binär und Bibliothekssachen erstmal raus und
überlege mir was anderes.
Hi Jörg,
kurze asm Verständnisfrage:
Ich habe im "fileman.asm", im Infobereich unter den Blöcken und Files
eine weitere Zeile hinzugefügt, die mir anzeigt wieviele Dateien auf dem
DF sind. (Wollte erst den freien Platz in Prozent anzeigen lassen aber
so fit bin ich noch nicht.)
Es funktioniert soweit! Aber wenn ich nun ESC drücke um das Infofeld
auszublenden, bleibt es stehen und im oberen Bereich taucht die
Statuszeile vom Editor auf in der ich gefragt werde ob ich verlassen
will ohne zu speichern.
Was ist hier passiert?
1. hängt es mit dem tempreg1 zusammen welches ich nochmals benutze?
2. wird das RETURN beim Tastendruck nicht richtig ausgeführt, weil ich
nochmals einen CALL (call fsys_maxpage) Befehl gesetzt habe?
3. was ganz anderes?
Ich weiß, um asm zu lernen sollte man klein anfangen! :) Aber ich bin
schon stolz, dass ich es geschafft habe mit 2 Werten zu rechnen.
1
libmio_thistext
2
.db 14,3,"Used: ",0 ;show message
3
ldi ctrl,0x0c ;set format
4
call fsys_free
5
push YH ;save free pages
6
push YL
7
movw XL,ZL ;copy free files
8
call fsys_maxpage
9
mov XL,tempreg1
10
ldi XH,0x00
11
sub XL,ZL ;maxpage-free
12
adiw XL,1 ;+1
13
libmio_outdez ;show files on DF
14
libmio_thistext
15
.db 255," ",0
16
17
18
fman_info_4: ldi XL,0x06 ;color scheme (inv. black on yellow)
Habs hinbekommen :)
Edit:
oder auch nicht :((
Entweder stimmt das Ergebnis nicht, weil ich irgendeine Zeile
auskommentiert habe aber ich kann wieder zurück springen
oder das Ergebnis stimmt aber sobald ich eine taste drücke spinnt der
Computer :(
Noch ne Frage bezüglich Seriellen Loader:
Ich habe jetzt die Version 1.50 auf mein 2. Board gespielt. Dort ist der
seriel loader ja drauf und es wird nach dem Intro danach gesucht.
Schließe ich das Board jetzt an den PC an und starte mein
terminalprogramm müsste doch eigentlich "Press Space to start"
erscheinen oder?
Es kommt aber nichts!!
Muss ich im Configmenü irgendwas einstellen? Habe jetzt hier auf der
Arbeit keinen Monitor um es zu testen. Dachte eigentlich das alles
werksseitig eingestellt ist und ich nur im Terminalprogramm alles
richtig setzen muss. Aber keine Chance. Der Loader meldet sich nicht.
Hilfe!
Hab auch das hinbekommen.
Eine verbindung auf der platine war unsauber.
Serielle Verbindung funktioniert jetzt. Aber der serielle loader funzt
trotzdem nicht. Im terminal steht zwar press space to start aber egal
auf welcher tastatur ich space drücke, er springt nichr in das menü vom
loader...
Ich bekomme es nicht hin Daten zu empfangen!
Ein basic Programm zum PC senden geht einwandfrei!!
Wenn ich eins empfangen will kommt nichts an.
Bei wem klappt das denn??
Und wie muss die Datei auf dem PC liegen, ist das egal? Also welches
Format. Hilfe... das kann doch nicht wahr sein! :(
@Jörg
In Basic gabs ja immer die DIM x(y) Anweisungen. Wie würde das denn bei
dir im gegenzug aussehen?
Grund ist: Es gibt zig alte Retro Spiele die ich gerne umsetzen möchte.
Viele nutzen aber die Arrays eben in diesem typischen Basicformat.
Das mit dem Loader werde ich mir bei Gelegenheit mal anschauen. Das
1.50er Release ist jetzt über zwei Jahre alt und bis jetzt hat sich
niemand beschwert. Wahrscheinlich nutzt es einfach (fast) niemand.
Mit dem DIM wird es etwas schwieriger, da es nur ein Array mit fester
Größe gibt. Deswegen lassen sich verschiedene Arrays nur über Pointer
auf verschiedene Bereiche im Array realisieren.
Jörg
Super Jörg, mach das bitte mal...
ich habe auch immer noch probleme beim Empfangen vom PC.
Auf dem RX liegen nur 0,8 Volt an... das wundert mich. Beim senden zeigt
mein Terminal programm auch Fehler im Programmcode. Wirre Zeichen. Ziehe
ich das serielle kabel ab liegen 5 Volt an und beim senden sind die
Zeichen im terminal wieder normal.
Wie gesagt: Senden vom AVR zum PC funktioniert einwandfrei!! Nur
empfangen nicht. Da weiß ich nicht mehr weiter.
ES FUNKTIONIERT!!!!!
Ich habe nun in der Schaltung auf der RS232 Buchse Pin 2 und 3
getauscht!
ich glaube da ist im Schaltplan etwas durcheinander geraten!
Am PC ist Pin2 Eingang (Rx) und Pin3 Ausgang (Tx)
In deinem Schaltplan hast du das aber vertauscht. So wie es bei den
Video Anschlüssen auch war (Scart). Der DSub Anschluss im Schaltplan ist
demnach der 9 polige MALE Stecker vom PC und nicht eine FEMALE Buchse
die man auf die Platine lötet.
Dadurch, das der PC nämlich auf dem Pin3 sendet, muss das Signal am AVR
auf Pin2 der 9poligen Buchse ankommen.
Das da noch kein anderer gemeckert hat wundert mich!
Egal, es läuft!! Jetzt müsste der Serielle Loader auch funktionieren!
EDIT:
SL funktioniert.. aber die Zeichen die ankommen sind nicht lesbar!!
komisch!
Und ich wieder...
Die "neuen" Dataflash mit der Bezeichnung AT45DB081E (Revision E)
funktionieren einwandfrei!!!!
Einzige Änderung: den MOSI vom AVR kommend auf 3,3 Volt herabsenken. Das
reicht. ich habe es testweise ebenfalls mit einer grünen LED gemacht und
es klappt. Der DF wird erkannt, es lässt sich speichern und laden!
****************
Serieller Loader zeigt immer noch wirre Zeichen an. Alle Einstellungen
stimmen aber. Bevor ich Pin 2 und 3 der seriellen Schnittstelle
getauscht hatte, konnte man noch PRESS SPACE TO START lesen. Jetzt nach
der tauschaktion nicht mehr. Jedoch funktioniert nun der serielle
Austausch in beide Richtungen. Kurios!
***************
Habe nun mehrere Vintage Basic Spiele portieren können und es ist total
genial! Vielleicht erstelle ich mal ein Verzeichnis mit Listings falls
Interesse besteht.
***************
habe mir einen günstigen Video to VGA Konverter gekauft. Einfach weil
ich mal testen wollte ob es funktioniert. Immerhin war er günstiger als
ein 7 Zoll TFT.
Bild erscheint, wenn aber auch nur in schwarz weiß (Ich habe einen FBAS
Konverter dazwischen). In manchen Kundenrezessionen konnte man lesen,
dass alle mit einem Atari oder Commodore 64 dieses Problem haben. Bild
wird in s/w dargestellt. Das liegt dann leider am Chipbasic und nicht am
Konverter. Ich denke mal die Syncro macht hier nicht ganz mit. Schade!
***************
Anbei auch mal mein aktuelles Board mit FBAS Konverter
BAM.... hab jetzt einen FT232 drauf und kann per Jumper zwischen RS232
und USB wählen.
Mit USB funktioniert auch der serielle Lader einwandfrei! HA! :)
Cool, die ganzen probleme die ich hier immer schreibe, löse ich ein paar
tage später selber!
Ist aber auch ruhig geworden hier! Wo sind denn die ganzen Abos??
Moin zusammen,
anbei hänge ich mal ein paar Listings von Programmen und Spielen.
In der .zip sind ein paar Chipbasic-Programme als Textdatei sowie eine
.pdf die ich angefangen habe. Die soll später als eine Art Katalog
dienen für Listings. Einfach mal reinschauen.
Muss dazu sagen: Einige Sachen sind natürlich WIP. Und bei anderen
müsste man die Eingaben wie IN(1)=1 etc. gegen Tasturabfragen ändern
wenn man keinen Joystick am Parallelport hat.
Außerdem noch der Schaltplan für den FBAS Konverter. Total simpel und
schnell aufgebaut.
Joar, ob ich jetzt die Sourcen von dem Chipbasic mal hochladen soll
welches ich etwas umgebaut habe weiß ich nicht. Anscheinend interessiert
es keinen :) Sind auch eigentlich nur optische Änderungen sowie ein paar
Features. Mehr ist leider nicht möglich wegen Platzmangel.
***
Der FT232 ist übrigens ein fertig aufgebauter Adapter von Ebay (3,50 €)
der sich perfekt in das System integrieren lässt. Wie gesagt, SL läuft
jetzt.
Außer: Egal ob RS232 der USB, ich kann keine Programme per XMODEM in das
System laden. Der PC sendet zwar und der AVR flackert auch aber am Ende
ist nichts angekommen außer wirre Zeichen auf dem Programmplatz.
Version 1.50!!! Vlt ein Bug? Oder ich bin zu doof. Wäre dann auch ein
Bug :)
Wäre wirklich cool wenn sich nochmal welche hier melden würden.
Damals sind ja recht viele BASIC Projekte entstanden!!
Also mich interessiert dieses Projekt
Auf jeden Fall noch!
Ich versuche ja noch die rtc pcf8583
Irgendwie einzubinden das klappt nur noch nicht so ganz :(
was funktioniert denn nicht?
ich werde mal die DS1302 testen demnächst!
Ja das Projekt muss am Leben erhalten werden. Ich hab schon so viele
alte Basic Programme portiert. Ist echt klasse.
Ich habe jetzt das Paket nochmal hochgeladen und hoffe, dass jetzt alles
dabei ist. Die neue Versionsnummer kommt daher, dass ich die Releases
praktisch komplett automatisch erzeuge und nicht die alte Version
überschreiben wollte.
Bei mir ist ein DSUB9-Stecker am Basic-Computer und ich nehme ein
Nullmodem-Kabel, bei dem ja RX und TX gekreuzt sind. Damit funktioniert
bei mir jeglicher Transfer bei 1200 und 2400 ohne Probleme (für die
andere Schnittstelle müsste ich erst Hardware zusammenbauen).
XMODEM ist NUR für Binärprogramme geeignet, Quelltext muss man via
Loader oder Editor im normalen ASCII-Modus übertragen. Binärprogramme
sind auch die "compilierten" BASIC-Programme, also so, wie sie im
Speicher vorliegen.
Für die Weiterentwicklung ist es vielleicht sinnvoller, komplett auf den
Mega1284P zu setzen, dann erübrigt sich erst mal das Thema Platz im
Flash und im RAM.
Jörg
Der thread ist zwar alt, aber vielleicht kommt hier noch jemand vorbei
und kann mir eine frage beantworten:
Wie schreibe ich mit print zeichen nacheinander in ein Array?
Ich habe versucht:
For x=0 to 32
esge z:? @0,x;#3;z;
next
Es wird nur ein Zeichen in das Array geschrieben.
Für ein Hilfestellung wäre ich dankbar.
Der Print-Befehl arbeitet die Zeile von links nach rechts ab. Setze erst
den Kanal, bevor Du die Position festlegst. In Deinem Beispiel wird die
Bildschirmposition auf 0,x gesetzt und dann auf Array-Ausgabe
umgeschaltet, wobei die Default-Position erstmal 0 ist.
Jörg
Hallo,
ich habe mir einen Chipbasic2 mit AtMega644 gebaut.
Leider bekomme ich kein Bild, nur wirre Streifen. Es sieht aus, als wenn
er nicht synced.
Nun bin ich AVR Noob und mir fehlen vermutlich ein paar Grundlagen.
Vielleicht kann mir jemand Starthilfe geben.
Ich weiß nicht genau, ob ich richtig vorgehe:
- Ich nutze Atmel Studio 7 zur Programmierung mit einem STK500
- Ich nehmen das Hex File aus dem Ordner System (120KB groß). Der Flash
beim 644er hat ja nur 64KB. Ist das in Ordnung?
- Ich flashe den AVR, klappt auch aber dann kommen eben nur die wirren
Bildstreifen. Grundsätzlich scheint das System zu laufen, den er
reagiert auf Tastendruck; (die Streifen verändern sich). Ich nutze nur
BAS Videosignal.
Nun habe ich gelernt, dass auch die Fuses eine Role spielen. Dann hab
ich die Fuse Einstellungen für Low, high, und ext, auf die in der Readme
angegebenen Werte gestellt. Nun kann ich den AVR aber nicht mehr
ansprechen. Es gab auch eine Warnung, die ich einfach übergangen habe
(irgendwas mit JTAGen geht nicht mehr, wenn Du das tust).
Habe ich den Chip jetzt kaputt geflashed?
Kann mich jemand unterstützen? Habe noch weitere AVRs, will die aber
nicht auch noch unbrauchbar machen.
Hi vergisst es,
Hatte Probleme mit dem Netzteil, deswegen hat der Quarz Probleme beim an
schwingen. Außerdem Zahlendreher bei den Fuses.
Zum Glück kann mein Prommer AVR Fuses programmieren.
Läuft alles. Super Ding!!
Nein ich hab nicht alles gelesen ... trotzdem: Respekt!
Schon mal an einen XMega384A3U gedacht? Meine 256er der Serie laufen
alle stabil mit 64MHz und Flash gäbe es reichlich.
> Schon mal an einen XMega384A3U gedacht?
Ja, an die Xmega hatte ich schon gedacht, aber letztendlich die Idee
wieder verworfen. Ich hatte auch schon eine Lösung mit Mega1284P und
XC9536 auf einem Daughterboard, welche dann höhere Auflösungen und auch
VGA konnte. Das hätte aber ein komplettes Re-Design der Software
bedeutet. Für mich ist das Projekt abgeschlossen, aber die Sourcen sind
ja verfügbar...
Karl M. schrieb:> Andy schrieb:>> Zum Glück kann mein Prommer AVR Fuses programmieren.>> Wieso ?>> Das geht doch immer mit allen ISP Programmieradaptern!
Ja, aber nicht wenn Du auf externen Oszillator stellt und dieser nicht
schwingt :)
Das hab ich nicht gerafft und hab deswegen die Fuses mit meinen Prommer
wieder auf inter gestellt.
Ich sag, ja Bin AVR Noob, aber es geht aufwärts:)
Mache mir jetzt noch ein Custom Layout und will versuchen irgendwie
einen seriell <-> USB Wandlermodul und eine USB Tastatur dranzutackern.
Hallo Jörg,
Frohes Neues Jahr!
Ich habe die menu.asm ja so angepasst, dass beim speichern eines Basic
Programms oder Textdatei unterschiedliche Icons angelegt werden.
Was jedoch nicht klappt ist die Definierung des Typs auf dem Dataflash.
Da wird jede Datei als BAS abgespeichert. Obwohl für die Textdateien
doch andere Bezeichnungen angelegt sind.
Wie kann ich das ändern damit abhängig vom Programmnamen auch auf dem
Dataflash der richtige Typ steht?
Wenn Du mit SAVE speicherst, werden immer BAS (Typ 0x10) Dateien
geschrieben. Außer Byte 12 im Header ist ein "N", dann wird eine native
AVR-Datei geschrieben (Typ 0x18). Mehr hatte ich damals nicht
vorgesehen, andere Dateitypen lassen sich nur mittels FCREATE erzeugen.
Wenn Du beim Speichern mehr Typen unterscheiden willst, musst Du das
selbst implementieren. Die Funktionen zum Schreiben (fysys_bsave,
fsys_bover) liegen in der modules/filesys.asm
Jörg
Danke Jörg!
Ah okay... ich dachte es wird noch unterschieden ob beim speichern ein
Unterstrich im Programmname ist. Wenn ja wird es als native oder text
angegeben.
Wie was wo muss ein N im header stehen?
Schau mal Jörg,
ich habe das Dataflashmenü etwas angepasst und folgenden Code
hinzugefügt:
1
libmio_thistext
2
.db 14,4,"Saved: ",0 ;show message
3
ldi ctrl,0x0c ;set format
4
call fsys_maxpage
5
mov XL,tempreg1
6
ldi XH,0x00
7
adiw XL,1
8
call fsys_free
9
push YH ;save free pages
10
push YL
11
12
sub XL,ZL
13
libmio_outdez
14
libmio_thistext
15
.db 14,14,"File(s)",0
Jetzt kann ich mir anzeigen lassen wie viele Dateien ich auf dem
Dataflash gespeichert habe.
Aber: Wenn ich jetzt eine Taste drücke, startet der Computer neu anstatt
zurück zum Menü zu gehen-
Warum?
Ich habe wie gesagt nur den oben gezeigten Code eingefügt!
Gruß
Dominik
Das ist nicht verwunderlich. Und zwar deswegen, weil das Y-Register auf
den Stack gesichert aber nicht wieder abgeholt wird (pop).
Von daher stimmt die Rücksprungadresse nicht mehr und bei einem ret
springt der Programm-Counter irgendwohin.
Die zwei Zeilen:
1
push YH ;save free pages
2
push YL
sind wohl vom Kopieren übriggeblieben und müssen raus.
Hallo Jörg,
ah okay! Wieder was gelernt! :)
Naja ich hab halt alles kopiert ab "call fsys_free" weil ich dachte es
gehört mit dazu.
Weil beim Aufruf zuvor wird ja ebenfalls YH und YL auf den Stack gelegt
und nicht durch pop abgeholt!?
Ich teste das heute Abend mal! Immerhin habe ich eine Subtraktion
hinbekommen :)
fsys_save_00: rcall fsys_check ;check for dataflash
6
cpi tempreg1,0x00 ;no valid FS
7
breq fsys_save_e
8
9
rcall fsys_fselbox4
10
ldi XL,0x10 ;BASIC
11
sts bas_partab+4,XL ;set file type
12
libmio_thistext
13
...
0x10 ist das BAS Programm. 0x18 steht für AVR native Programme. Änder
ich zum testen mal XL,0x10 in XL,0x18 wird dennoch als BAS gespeichert.
Zum anderen weiß ich auch gar nicht wie ich unterscheiden soll beim
speichern. Es muss ja abhängig sein vom Programmnamen als was
gespeichert wird.
Naja egal.. das ist dann doch etwas zu hoch für mich
Das Problem mit dem Neustart ist behoben.
Es lag tatsächlich an Y Register auf dem Stack :)
Was mir aufhegallen ist, auf einem DF habe ich 28 Dateien. Mir wird aber
284 angezeigt.
Hab dann mal auf einem leeren DF eine nach der anderen Datei angelegt.
Bei 10 Dateien zeigt er mir plötzlich 11 an.
Hab ich was verkehrt gemacht in meiner Rechnung?
Dazu müsste ich mich wieder "einlesen", denn das ist schon ein paar
Jahre her. Das habe ich aber nicht vor, für mich ist das Projekt
abgeschlossen.
In der Dateiverwaltung war Vieles vorgesehen, aber nur das Nötigste
umgesetzt.
Jörg
Hi Jörg,
Nicht schlimm... ich finde den Fehler bestimmt noch.
Hab mal mit SD Karten experimentert, bekomme es aber leider nicht hin,
dass sie wenigstens erkannt werden.
So... Fehler gefunden!
Jetzt zeigt er exakt die Anzahl der gespeichteren Dateien auf dem
Dataflash an. :)
Jetzt mal schauen was ich mit dem restlichen freien Platz im Flash noch
anstellen kann.
Hallo Jörg,
kurze Frage:
ich habe in der Keytavle.inc bei den entsprechenden Kaycodes die Zeichen
ä,ö und ü eingetragen. Diese sind auch im Zeichensatz mit drin!
Tastatur ist deutsch! Dennoch funktioniert die Eingabe nicht nach dem
kompilieren!
Einzig das 'ä' löst einen "Pfeil nach oben" Tastendruck aus.
Ich weiß zwar nicht, was Du alles geändert hast, aber das wird generell
nicht funktionieren. Die Umlaute im Charset lassen sich nur PRINT %...
ausgeben. Alles unter 0x20 und über 0x7F sind BASIC-Token, von daher
könnte man die Umlaute gar nicht als Zeichen im BASIC speichern.
Jörg
Ah okay...
danke Jörg! Dann kann das ja gar nicht funktionieren!
Ich dachte nur warum sind die im keytable nicht hinterlegt wenn sie doch
auch im Zeichensatz sind.
Aber macht natürlich Sinn.
Hier mal mein aktueller Computer als tragbare Version!
Hardware:
- Alle(!) Schnittstellen nach außen geführt.
- FBAS Konverter auf Platine
- Video per Schalter zwischen Farbe und Monochrom umschaltbar
Software:
- Optische Anlehnung an Windows 2
- 3 verschiedene Programm Icons (Leer, Textdatei, BASIC Programm)
- Anzeige der Anzahl von gespeicherten Dateien auf Dataflash
- Extra Seite mit Infos zum System (CPU, Keyboard, Speicher, etc.)
Neue Programme:
- Kalender
- Mondphasenrechner
- Pferderennen
- Submarine
- Lunar Lander
Gibt es hier noch Leute, die sich ebenfalls noch mit dem Computer
beschäftigen??
Hi Jörg,
Da ich den 1284P nutze würde die Serial Pin Einstellung in der
Configpage wegfallen.
Hätte dann Platz für eine andere Option.
Der Pin wird durch das 5. Bit der libmio_sysconf beeinflusst.
Leider finde ich nirgends die Abfrage dazu. Also wo finde ich den
Eintrag wo sich die serielle Schnittstelle den Wert holt?
Das Einzige was ich gefunden habe ist in der library die Abfrage des 5.
Bit bezüglich der 2. Seriellen Schnittstelle.
Ich will einfach nur dauerhaft auf PinD1 stellen.
Naja ok... Dann nicht.
Vielleicht bekomme ich ja hierbei Hilfe:
XModem klappt immer noch nicht!
Ich versuche die Measlib.asm zu übertragen aber jedes Mal bei 22,9% ist
Schluss und der Transfer wird abgebrochen!
Jeglicher Transfer über die Schnittstelle funktioniert, ob senden oder
empfangen von Quelltext aus dem Editor.
Auch kann ich zum Beispiel den Loader per XModem an den PC senden, auch
wenn die Zieldatei nicht wirklich lesbar ist.
Aber ein Transfer per XModem zum AVR funktioniert nicht!
Ich nutze noch die XModem Sourcen der 1.49 Version!
Korrigiere... geht doch.
Nur wie du schon sagtest, ohne Api laufen die Bibliotheken nicht.
Hab dann versucht die Api Verweise der Bibliothek häbdisch einzufügen
aber die Bibliothek stürzt dennoch ab und zu ab beim Aufruf des Beispiel
Messprogramms. Bzw. Das programm friert ein.
Schade...
Die Bedeutung der Bits in den Config-Bytes müsste ich auch erst wieder
aus dem Code "herauslesen", das meiste steht aber in der configpage.asm.
Meine "Papierunterlagen" habe ich irgendwann entsorgt, als ich das
Projekt bei mir geschlossen habe.
Die originale Measlib sollte aber mit der V1.49 OS Version
funktionieren. Als erst mal die Binaries aus den Archiven testen und
dann schrittweise austauschen. Warum fügst Du die API-Bibliothek
händisch ein? Das geschieht doch normalerweise via Includes. Ich habe
mal das Script angehängt, mit dem ich die Bibliotheken gebaut habe.
Jörg
Hallo Jörg,
schön das du da bist :)
Danke für das build bin. Perl? Werde ich mal testen!
Ich hatte doch eine zusätzliche Infoseite im Hauptmenü eingebaut. Und 3
unterschiedliche Programmicons eingefügt.
Dadurch flog bei mir die API und das XModem aus dem Include.
Problem ist halt der .org Platz zwischen Anfang und 0x4000
Xmodem passte zwar wieder rein aber die API's nicht. deshalb habe ich
alle Api Sprünge in der Measlib händisch zu den libmio_... Sachen
geändert. Brachte aber nichts außer Abstürze.
Ich überlege jetzt, wie ich am besten die API's wieder mit an Bord
bringe UND meine zusätzlichen Icons und Infoseite beibehalten kann.
Kann man an den Org Sachen in der main noch irgendwas tricksen??
PS:
Bezüglich den Configbits:
Ja, es sind alle Bits soweit beschrieben, bis auf Bit 5 für den
seriellen Pin Input!
In der libmio/library.asm finde ich alle Config Bits und deren Abfrage.
Jedoch nicht das 5. Bit für den Input Pin. Außer für die Konfiguration
der 2. Schnittstelle. Da fragt er nur das 5. Bit ab ob gesetzt, wenn ja,
dann aktiviere 2. Schnittstelle.
Aber von der Systemschnittstelle ist nichts zu finden!
PPS:
Die Unterlagen entsorgt??? :-O
Jörg, das wäre eine schöne Bettlektüre für mich gewesen!! :)
Nochmal eine ganz blöde Frage:
im Systemordner liegen:
- api.asm
- api.inc
- api_macros.inc
In der MAIN wird aber nur api.asm eingebunden. Ist das richtig? Werden
die anderen Dateien irgendwo anders included oder braucht man die gar
nicht?
Die beiden .inc Dateien braucht man für das System nicht, wohl aber für
die Programmierung von Binärprogrammen, Treibern oder Bibliotheken.
Welches der beiden Includes man nimmt, hängt vom eigenen Gusto ab. Die
Dateien werden nicht von Hand erstellt, dafür gibt es auch ein Script,
welches die Adressen aus dem Listfile ermittelt.
Jörg
Super...danke Jörg!
Habe jetzt ein paar Videmoded rausgeworfen und schon passeb die Apis
wieder rein :)
Teste nachher mal die Measlib mit dem LCD Treiber und deinem
Beispielprogramm.
Wie machst du das mit den .org Sachen in der Main? Weißt du aus dem Koof
raus wie viel Platz die einzelnen Sachen brauchen oder siehst du das
irgendwie? Wie gesgt, eine zusätzliche Seite im Menp UND Apis war
zuviel.
Ohne Videomode 3,4,5
stürzt mein Editor ab. Toll... also alles wieder rückgängig und gucken
wo ich Platz herbekomme in den Org Directiven.
Was anderes:
Ich habe das ominöse 5. Bit der libmio_sysconfig gefunden!!!
Zufällig!
Es wird in der "vint_o.asm" abgefragt! Dort wird dann entschieden, ob
PD1 oder PD3 genutzt wird! Juhuuu
Also die libraries laufen alle wunderbar Jörg.
Hab auf die 1.50er gewechselt und dort mein Menü soweit wieder angepasst
wie ich es hatte.
Musste dafür jetzt leider auf meine Extraseite verzichten weil der Platz
so eng ist und ich beim compilieren Fehlermeldungen bezüglich .org
bekomme.
Bis auf die Screenshotfunktion kann ich so auch nichts mehr
rausschmeißen sonst laufen die libs nicht mehr.
Schade... ein paar kb mehr Speicher wäre super.
Oder nochmal die Frage: kann man bei den Org Anweisungen noch was ändern
was den Speicher betrifft?
Zur Measlib:
ich habe mir die Bibliothek auf einen Programmplatz gelegt und
zusätzlich wie gefordert einen LCD Treiber (1x16).
Bei folgender Zeile im Beispielcode von MESS4:
1
92 OUT $A00+I,AR(J):NEXT
bekomme ich einen Syntax Error angezeigt!
Habe die Zeile dann auskommentiert und das NEXT verschoben, jetzt läuft
das Programm.
Widerstände werden exakt gemessen. Bei Kondensatoren gibt es
Abweichungen.
Warum die Zeile 92 einen Syntax Error ausgibt kann ich nicht
nachvollziehen. Hoffe die Zeile ist nur für das LCD relevant?!
Ansonsten stelle ich jetzt erst fest wie komplex der Computer doch sein
kann wenn man anfängt sich mit den binär Sachen zu beschäftigen!
Mir ist aufgefallen, dass die V1.50 größer ist als die 1.45. Warum?
Außer Bugfixes wurde doch nichts weiter gemacht oder? Den ATmega1284P
hatte ich bereits mit der 1.45 eingebunden.
Mir fehlt immer noch etwas Speicher für meine Zusatzseite! Mache mich
jetzt auf die Suche ob noch irgendwas weg kann. In der Api zum Beispiel
die XMEM Sachen brauche ich ja auch nicht.
Die .org Anweisungen sind dazu da, dass Tabellen immer an 256-Byte
Grenzen im Flash liegen. so lassen sie sich einfacher und schneller
indizieren. Wenn z.B. schon in ZL der Index liegt, braucht man nur ZH
mit dem Tabellenstart zu laden und ein lpm ZL,Z zu machen.
> Außer Bugfixes wurde doch nichts weiter gemacht oder?
Für solche Zwecke wurde vor langer Zeit das Changelog erfunden ;-)
Selbiges befindet sich übrigens am Ende der Haupt-Doku. Außerdem können
auch "einfache" Bugfixes größere Veränderungen am Code nach sich ziehen.
Wenn man das Projekt erweitern will, kommt man um einen Mega1284P und
großflächiges "Entwirren" nicht herum. Aus Platzgründen gibt es
teilweise Sprünge anstatt ret am Ende von Subroutinen. Das Sprungziel
befindet sich dann in einer anderen Subroutine, die dann den "Rest" des
Codes abarbeitet. Damals war das notwendig, damit alles noch in den
Mega644 passt.
Jörg
Moin Jörg,
die Changelog kenne ich. :)
Leider fehlen die Änderungen von der 1.50 zur 1.51 Version. Aber egal!
Ja mit den Sprüngen habe ich gesehen. Ich blicke so langsam mehr und
mehr durch den Code. Auch wenn vieles trotzdem noch sehr undurchsichtig
scheint.
Ist ein Return nicht besser um einen Sprung abzuschließen, anstatt einen
neuen Sprung zu machen??
Kannst du was zu dem Syntax Error sagen den ich bekomme bei dem
Messprogramm?
> die Changelog kenne ich. :)> Leider fehlen die Änderungen von der 1.50 zur 1.51 Version. Aber egal!
Du hattest aber explizit nach den Änderungen zwischen V1.50 und V1.45
gefragt.
> Ist ein Return nicht besser um einen Sprung abzuschließen, anstatt einen> neuen Sprung zu machen??
Wenn am Ende z.B. Ergebnisse an eine bestimmte Stelle geschrieben und
Register vom Stack geholt werden müssen und das am Ende einer anderen
Routine bereits gemacht wird, kann man direkt dorthin springen und damit
Code einsparen. Gut, man erkauft sich das mit 2-3 Takten mehr, aber wie
Du selbst gerade siehst, ist fehlender Platz oft das größere Problem.
> Kannst du was zu dem Syntax Error sagen den ich bekomme bei dem> Messprogramm?
Nein. Denn das ist das /funktionierende) Programm, welches ich vom CB2
auf den Computer übertragen habe. Tritt er auch mit originalem
OS+Measlib auf?
Die Ungenauigkeiten bei der C-Messung muss man halt über die
entsprechenden Array-Werte korrigieren. Die Messung nutzt den Komparator
und die interne Referenz, die zwischen 1 und 1,2V liegen kann. Der
dadurch entstehende Messfehler wird noch größer sein, da die
Entladekurve bei ca. U/5 schon relativ flach ist.
Jörg
Ja, der Fehler tritt auch bei original OS auf.
Deswegen hatte ich mich gewundert! Aber wie gesagt, das Programm läuft
wenn ich die Zeile auskommentiere!
Meine Extra-Systemseite hab ich nun auch wieder in den Flash bekommen!
:-)
Ich werde zu Hause mal versuchen eine .hex in eine .bin umzuwandeln. Das
ist das nächste wichtigte Ziel!
Hallo Jörg,
So....
1. cbterm.asm genommen, die includes angepasst und mit AVRA kompiliert.
Hat geklappt!
2. cbterm.hex mit hex2bin umgeandelt. CBTERM.BIN (55kB) ist entstanden!
3. CBTERM.BIN geöffnet und alle bis zum Programmstart gelöscht, dann aus
einer bereits existierenden CBTERM.BIN die Leerzeichen hinte dem
Programm kopiert und eingefügt sodass meine .bin exakt 3072 Bytes groß
ist.
4. Per XMODEM auf den CB2 übertragen. Hat funktioniert, Icon wurde
erstellt.
5. Starten geht nicht, AVR stürzt ab, es gibt Bildstörungen, wie beim
Empfang per XMODEM.
Was könnte ich falsch gemacht haben? Die .bin sieht mit dem Texteditor
exakt genauso aus wie die original .bin. Habe nichts geändert! Größe
passt auch. Dennoch startet sie nicht!
> Was könnte ich falsch gemacht haben?
Du hast nicht richtig verstanden, wie die Binaries erstellt werden und
versuchst, das irgendwie unter Windows hinzubekommen. Spätestens wenn
die "rohe" Binärdatei größer als 3K ist, müssten die Alarmglocken
klingeln. Wenn ich cbterm.asm übersetze, ist das Hexfile 3450 Bytes groß
und das Binary 1216 Bytes. Der Rest wird dann bis 3K mit Nullen
aufgefüllt. Wahrscheinlich füllt Dein hex2bin von 0x0000 bis 0x6C00 auf
und du musst 55296 Bytes vorne abschneiden.
> Die .bin sieht mit dem Texteditor> exakt genauso aus wie die original .bin.
Das ist aber jetzt nicht Dein Ernst...
Wenn Deine Datei identisch wäre, würde sie ja genauso wie das Original
funktionieren.
Jörg
Ja was soll ich denn machen?
Klar ist das mein Ernst!
Ich hab AVRA.exe und HEX2BIN.exe
Und bin so vorgegangen wie du es beschrieben hast!
Ich weiß ja nicht warum hex2bin bis 0x6C00 auffüllt. Die cbterm.asm bzw.
.hex ist die Originale!
Wenn ich natürlich Linux brauche, einen Ingenieurstitel und der Jupiter
im Orion stehen muss dann kann das natürlich nicht funktionieren.
Immerhin bin ich der Erste seit Projektbeginn der sich mit den binaries
mal auseinandersetzt.
> CBTERM.BIN (55kB) ist entstanden!
Und das ist Dir nicht komisch vorgekommen?
> Wenn ich natürlich Linux brauche, einen Ingenieurstitel und der Jupiter> im Orion stehen muss dann kann das natürlich nicht funktionieren.> Immerhin bin ich der Erste seit Projektbeginn der sich mit den binaries> mal auseinandersetzt.
Ich denke, ab diesem Punkt können wir uns jede weitere Diskussion
sparen.
Ich entwickle meine Projekte unter Linux und hin und wieder stelle ich
welche davon der Allgemeinheit als OpenSource zur Verfügung. Ob das
Einer nutzt, Millionen oder gar keiner, ist mir eigentlich egal. Aus
diesem Grund habe ich auch vor längerer Zeit die Zugriffszähler von
meiner Homepage entfernt. Das schürt nur unnötige Eitelkeiten.
Wer lieber Windows benutzt, mag das gerne tun. Unterstützung dafür wird
es aber von mir nicht geben. Zumindest nicht in diesem Leben...
Jörg
Na das hat ja auch keiner verlangt.
Wer den Thread von Anfang an verfolgt hat, der weiß das auch. Hab ja
auch nie gemeckert deswegen. Im Gegenteil.
Natürlich kam mir das komisch vor mit der .bin
Ich ging aber davon aus, wenn ich in der bin alles bis zum eigentlichen
Inhalt lösche und dann dahinter auffülle bis 3072 bytes sollte es
reichen.
Aber allein dadurch, dass hex2bin die Datei anders erstellt als bei dir
ist schon komisch. Ich weiß halt nur nicht warum.
Siehe da...
ich habe jetzt 5 verschiedene Versionen von HEX2BIN gefunden.
Und bei der 5. hat es dann funktioniert.
Die erstellte BIN ist um die 2000 Bytes groß. Den Rest mit Nullen
aufgefüllt.
Startet trotzdem nicht.
Eine fertige BIN aus deinen Sourcen läuft einwandfrei.
Kopiere ich den Inhalt der Bin in die von mir erstellte läufts auch
nicht.
Nullen habe ich aufgefüllt bis 3072 Bytes.
Mh... bin wohl doch zu doof dafür :(
HEUREKA!
Doch nicht zu doof!!
Es funktioniert!!!!
Musste mir natürlich alles auf Windows Ebene zurechtklamüsern!
Jetzt funktioniert alles und ich kann mir eine Batch schreiben.
Für die die es interessiert unter Windows:
1. Test.asm mit AVRA kompilieren
2. Test.hex mit HEX2BIN umwandeln
3. Mittels "fsutil file createnew" unter Eingabeaufforderung eine Dummy
Datei erstellen. Größe der Datei = 3072 Bytes - Größe der .bin
4. Mittels "type DummyDatei >> Test.bin" die Dummy Datei anhängen
Es läääääuft!!!
Danke Jörg!
Hier für alle Windows-Benutzer folgende Dateien, damit man eine .bin
Datei erstellen kann:
- HEX2BIN.exe (in den Ordner kopieren wo die .asm Datei liegt)
- AVREL.exe (auch in den Ordner mit der .asm Datei)
- BUILDBIN.bat (Aufruf: Buildbin [Datei])
Aus der .asm Datei wird eine .bin erstellt welche direkt auf den CB2 per
XModem übertragen werden kann!
Das Script löscht dann alle erstellten Dateien wieder bis auf die .bin
Datei.
Passend zum Retro Computer habe ich mit Visual Basic ein kleines
Programm geschrieben mit dem man die .bin Dateien etwas komfortabler
erstellen kann.
Außerdem habe ich ein kleines Terminal eingebaut und einen Editor. Dort
kann man BASIC Programme senden und empfangen und diese dann am PC
bearbeiten. Mit automatischer farbiger Einfärbung von BASIC-Befehlen,
Überwachung der Zeichen pro Zeile und und und... Soll aber kein Emulator
werden!
Übrigens, hier mal eine kleine Übersicht wo ich einen AVR Chipbasic2
einsetze bzw eingesetzt habe:
- Im Cabrio als Dachsteuermodul, etc,
- Als Wetterdaten Empfangsstation
- Für MSR Aufgaben
- Home- und Spielecomputer
Gerade im Auto und als MSR Rechner bieten sich die kleinen TFT
Bildschirme an, da sie perfekt in Tischgehäuse passen.
Erinnert leicht an den Commodore-SX 64
Gruß
Dominik
PS: Ich hoffe es gibt noch ein paar CB2 Junkies hier??
Hello,
Here is the complete schematic I have re-drawn for the AVR chipbasic2
with the atmega644p.
I have included everything into a single schematic, no need for
adaptors.
I have corrected some errors from the schematics of Joerg (I2C bus
errors, 16 color extension errors, Serial port errors, SCART port
error). R13 is still to be checked against B/W BAS or else it's position
must be changed at the bottom of R14.
My additions to the schematic:
1. An embedded MCU programmer, so you do not need to buy a programmer.
Tested with Ponyprog.
2. Jumper switches select either programmer or flash in the ICSP.
3. Jumper switches select between null-modem or ordinary serial cable in
the serial port. So if you do not have a null-modem you can use an
ordinary serial cable.
4. Scart port as well as Audio and Video RCA included.
5. HSYNC/VSYNC/CLK signals available in a pin-row.
6. Second serial port available into this pin-row.
7. PSU added, which can be fed from 220VAC, or 8-35VDC, or 8-35VAC. AC
is automatically disabled with internal J1 switch. So you can use any
PSU available at home, no matter AC or DC.
Enjoy!
de sv3ora http://qrp.gr
PS. Dominik, please email me (find my email at the end of my site) so
that maybe we could exchange ideas about the computer.
Sorry I do not know German :(
> Habe nun mehrere Vintage Basic Spiele portieren können und es ist total> genial! Vielleicht erstelle ich mal ein Verzeichnis mit Listings falls> Interesse besteht.
Hallo, ich interessiere mich für diese Spiele. Können Sie eine ZIP-Datei
erstellen und sie hier veröffentlichen, damit ich sie herunterladen
kann?
Hallo, zusammen!
Gäbe es die Möglichkeit, etwas Hardware an diesen kleinen Computer
anzuschließen? Wie das früher möglich war, zum Beispiel über einen
8-Bit-Port, oder eine I2C-Schnittstelle. Und mittels Peek- und
Poke-Befehlen zu verwenden oder sogar über echte BASIC-Befehle?
Leider kann ich das nicht selber machen; aber es wäre eine feine Sache.
Auf jeden Fall ein toller Computer!
Horst.
Horst schrieb:> Hallo, zusammen!>> Gäbe es die Möglichkeit, etwas Hardware an diesen kleinen Computer> anzuschließen? Wie das früher möglich war, zum Beispiel über einen> 8-Bit-Port, oder eine I2C-Schnittstelle. Und mittels Peek- und> Poke-Befehlen zu verwenden oder sogar über echte BASIC-Befehle?>> Leider kann ich das nicht selber machen; aber es wäre eine feine Sache.>> Auf jeden Fall ein toller Computer!> Horst.
Bitte sehen Sie sich den Schaltplan an, den ich im vorherigen Beitrag
gepostet habe. Sie können alle von Joerg beschriebenen Schnittstellen in
einem einzigen Schaltplan sehen. Ich arbeite derzeit auch an einer
eingebetteten PS / 2-Tastatur und einer VGA-Schnittstelle, ohne weitere
Chips hinzuzufügen.
Ich habe eine Facebook-Gruppe für dieses wundervolle Projekt erstellt.
Ich weiß nicht, ob ich es hier posten darf, aber dies ist die URL, wenn
jemand interessiert ist.
Https://www.facebook.com/groups/529571947566185/
Ich und andere werden dort unsere Arbeit zur Weiterentwicklung des
Projekts veröffentlichen. Ich werde versuchen, auch dieses Forum mit den
neuesten Nachrichten auf dem neuesten Stand zu halten, aber das
Schreiben in deutscher Sprache von Google translate ist unbequem!
The new page I have built for the computer
http://qrp.gr/cb2/
There are also hardware extensions and the English translated manual
there.
Thanks so much Joerg for this nice computer!
Enjoy!
Hi,
In that page http://qrp.gr/cb2/ I have released a "minimal version" of
the hardware for the impatient. This requires the least wiring and the
absolutely minimum effort required for a working computer. The extra
options (LPT,I2C, ext-flash, ICSP) can be added later on if one wishes
so. But they are not required if you want to have a BASIC computer to
make programs on.
I have built and tested this CB2 hardware "clone" and it works great in
every aspect.
Enjoy!
Hi,
In that page http://qrp.gr/cb2/ I have designed a universal modem for
the CB2, under the "modem" link.
The modem is a 1200 baud CCITT V23 FSK modem, that communicates directly
with the CB2 through the TTL level pins of the ATMEGA644P. The modem can
be used for transferring data through CBterm, BASIC editor, or BASIC
programs. The data can be transferred through the telephone lines (with
the help of a telephone device for dialing and call-answering), and
through HAM radio transceivers (automatic PTT enabled). The modem also
allows for program storage and loading from audio recorders, so now you
can store your programs on simple audio recorders (and cassette
recorders if you like the vintage feeling) like it was done on 80s
micros.
Enjoy!
De sv3ora
sv3ora schrieb:> Hi,> In that page http://qrp.gr/cb2/ I have released a "minimal version" of> the hardware for the impatient. This requires the least wiring and the> absolutely minimum effort required for a working computer. The extra> options (LPT,I2C, ext-flash, ICSP) can be added later on if one wishes> so. But they are not required if you want to have a BASIC computer to> make programs on.> I have built and tested this CB2 hardware "clone" and it works great in> every aspect.> Enjoy!
Here is the picture of the CB2 clone.
is a simple BBS written to run on the "minimal version" CB2. It requires
a serial dial-up modem (external "smart" modem) to be connected on the
RS-232 port of the CB2. microBBS handles the modem auto-answer and all
the communications after the establishment of the dialup connection.
With microBBS callers can write their own public messages and preview
the list of public messages. They can also view information about the
system. The program stores the messages in the internal EEPROM of the
MCU, which is limited, so keep messages short. microBBS is designed to
display the information correctly aligned on the CBterm of other CB2
clients. On connection of a client from a PC, you may need to alter the
printed messages spaces, to line up the information better on the PC
terminal. If you want to run your own BBS, you may need to change the
name of the BBS as well as the system information messages, to suit your
needs.
sv3ora schrieb:> is a simple BBS written to run on the "minimal version" CB2. It requires> a serial dial-up modem (external "smart" modem) to be connected on the> RS-232 port of the CB2. microBBS handles the modem auto-answer and all> the communications after the establishment of the dialup connection.> With microBBS callers can write their own public messages and preview> the list of public messages. They can also view information about the> system. The program stores the messages in the internal EEPROM of the> MCU, which is limited, so keep messages short. microBBS is designed to> display the information correctly aligned on the CBterm of other CB2> clients. On connection of a client from a PC, you may need to alter the> printed messages spaces, to line up the information better on the PC> terminal. If you want to run your own BBS, you may need to change the> name of the BBS as well as the system information messages, to suit your> needs.
Sorry, I have just been visited your site. Great! Really good work.
I like it how you represent the games and the other stuff with pictures
and small descriptions.
After a long time a turned on my CB2 today and I'm ready to make some
more stuff.
Did you get the calendar and the moon phase programs?
Max B. schrieb:> Sorry, I have just been visited your site. Great! Really good work.> I like it how you represent the games and the other stuff with pictures> and small descriptions.>> After a long time a turned on my CB2 today and I'm ready to make some> more stuff.> Did you get the calendar and the moon phase programs?
Not I did not! Can you email them to me please? The email is on my site
http://cb2.qrp.gr
Hi,
Respekt, nettes Projekt zum rumspielen! Was die relativ kurzen Basic
Programme leisten beeindruckt mich.
Wo findet man denn die aktuellen Quellen? Ich will mir mal anschauen,
wie das ein oder andere umgsetzt/realisiert wurde.
Hallo,
ich habe mir den Chip-Basic2 in der Universalvariante (mit 9-poliger
Buchse für Audio und Video) nachgebaut und er funktioniert tadellos.
Als Monitor nehme ich das (nicht mehr lieferbare) 4,3" Displayset von
Pollin. Es hat jeweils einen Cinch-Audio und FBAS-Eingang.
Nun mein Problem:
Die normale Ausgabe über BAS (Pin 8 der D-Sub-Buchse) liefert ein
tadelloses schwarz/weißes Bild.
Da ich zufällig einen CXA1645P in meinem Bestand habe, dachte ich mir,
es mit FBAS zu versuchen. Von den Daten her müsste dieser doch ähnlich
wie der in diesem Thread von manchen verwendete MC1377P sein - und das
schöne daran, er läuft sogar mit 5 V.
Anhand der Sony-Applikationsschaltung (siehe Anhang) habe ich mir also
den Encoder auf Lochraster nachgebaut, doch leider liefert er überhaupt
kein Bild (nicht mal ein Flackern ist zu erkennen).
Im Gegensatz zum MC1377P kann nicht direkt ein Quarz angeschlossen,
sondern es muss an Pin6 ein Sinussignal mit der PAL-Frequenz angelegt
werden.
Provisorisch habe ich 4,43619 MHz von meinem Netzwerktester (NWT1) an
diesen Pin eingespeist (2,3 Vss) - später soll ein Quarzgenerator
folgen.
Nach mehrmaligem Durchmessen der Schaltung konnte ich keinen Fehler
finden und auch die Stromaufnahme ist im Sollbereich (ca. 40 mA).
Daraufhin habe ich wie in der MC1377-Applikation die RGB-Eingänge mit 75
Ohm nach GND abgeschlossen und HSYNC über eine Diode und Csync über 10k
jeweils zusammengeführt und über 68 Ohm an GND gelegt.
Einzig und allein die RGB-Eingangs-Koppelkondensatoren habe ich auf
100nF belassen und bin von dort direkt an die Pins 1, 2, und 3 der
DSUB-Buchse gegangen.
Leider findet man kaum Hinweise zu diesem Chip; vielleicht haj jemand
eine Idee was ich noch überprüfen könnte?
Gruß
Franz
Hallo, ich habe dieses Projekt aus einem Atmega644P erstellt (mein
Atmega1284P funktioniert nicht, die Verbindung ist die gleiche wie beim
644?) Ansonsten funktioniert alles einwandfrei.
Ich wollte die serielle Programmübertragung versuchen, da ich kein
RS232-Kabel zur Hand habe. Ich habe ein Arduino Uno verwendet, um die
Verbindung herzustellen (mit gekreuztem TX und RX), und am Ende bekam
ich Auf HyperTerminal die Meldung "Press Space to Start", habe ich es
geschafft, BASIC-Programme von Atmega zu senden, aber Binärprogramme wie
Textprogramme werden nicht vom Computer gesendet. Hat jemand eine Idee?
Mit der ExtraPutty-Software konnte ich etwas über Xmodem senden, aber
das Senden scheint nicht zu enden und ich habe seltsame Zeichen im
Programmsymbol. Außerdem wird das Programm "Serial Loader" nicht
geöffnet, es soll geöffnet werden ?
EEPROM funktionieren auch nicht oder ich weiß nicht, wie ich sie
verwenden soll ...
Habe das Problem gelöst.
Pin 10 (Sync) vom CXA1645 muss direkt mit HSYNC (Pin 5 auf Sub-D)
verbunden werden. Vsync ist ohne Bedeutung.
Außerdem war mein Testkabel zu lang - das BAS-Signal kam noch
einigermaßen durch (Pin 8 auf Sub-D), aber die R,G,B-Daten und vor allem
die HSYNC waren total verrauscht (habe es auf dem Oszi beobachtet).
Habe parallel noch eine Version mit AD724 aufgebaut. Hier muss der VSYNC
vom AD724 auf +5V gelegt werden, der HSYNC geht wieder direkt auf Pin5.
Beide Versionen laufen mit 5V.
Subjektiv kommt mir das Bild mit dem AD724 schärfer vor, es kann aber
auch an meinen provisorischen Leitungen liegen.
Frohes Neues Jahr zusammen,
2 Jahre später und immer noch aktuell.
Zur Zeit nutze ich die Atmega8 Version für kleinere Schaltaufgaben zu
Hause.
Die 1284p Version habe ich mir jetzt nochmal aufgebaut aber diesmal mit
Universal Video Buchse damit ich flexibler bin.
@Franz
Das ist interessant.
Ich nutze immer noch erfolgreich den MC1377. Aber gut zu wissen, dass es
noch Alternativen gibt.
@Jörg
Gibt es noch Ideen, Features, etc. für die Zukunft?
> Gibt es noch Ideen, Features, etc. für die Zukunft?
Nein, da kommt nichts mehr. Zumindest nicht von mir, aber der Quellcode
ist ja Open Source. Ich habe einfach keine Verwendung mehr dafür. Wer
setzt sich mit einer Tastatur vor einen 40" Flatscreen? Für VGA, was ja
heute auch mehr und mehr obsolet wird hätte man zusätzliche Hardware
benötigt. Vor fast genau 14 Jahren war das vielleicht eine tolle Sache,
aber die Welt ist in der Zwischenzeit nicht stehen geblieben...
Jörg
Ach Jörg...
Die Welt vielleicht nicht aber wir Retro Junkies :)
Ich bin froh noch einen kleinen Flat-TV mit Scart im Keller stehen zu
haben für solche Geschichten. Selbst alte Konsolen sind über RGB einfach
ein Muss.
Und ja, wenn ich den Chipbasic auspacke dann sitze ich da mit der alten,
klobigen, vergilbten Tastatur.
Der Chipbasic ist eine tolle Sache und wird immer noch genutzt.
Es gibt hier einen User aus Griechenland der dem CB eine Webseite
gewidmet hat. Samt Bibliothek sämtlicher Programme und Spiele dafür.
Also es wird immer noch fleißig damit programmiert.
Ich würde das Projekt nicht so unterbewerten. Was du dir da aus dem Kopf
gedrückt hast ist schon einzigartig.
Ja, es ist Open Source. Aber du hast wirklich jede noch so kleine
Kleinigkeit erfolgreich implementiert.
Bis auf ein paar Verschönerungen am Layout und ein paar Änderungen am
Menü habe ich auch nicht wirklich was gemacht.
Moin zusammen,
für alle Interessierten kann ich nur nochmal Werbung für die Seite von
Kostas machen:
http://cb2.qrp.gr
Er und ein paar Andere haben dort alle möglichen Programme und Spiele
(Ja, es gibt neue Spiele) mit Screenshot und Quellcode angelegt.
Es gibt also tatsächlich noch welche, die den Computer nutzen und dafür
programmieren. Spiele wie Tic Tac Toe, Mastermind, Reversi, etc. sind
wirklich klasse gelungen für das System.
Demnächst erscheint dort auch der Urvater der Wirtschaftssimulationen.
Ich habe erfolgreich das Spiel HAMURABI umgesetzt.
Zur Zeit bin ich dabei KAISER vom C64 auf den CB2 zu portieren. Leider
mit ein paar Einschränkungen.
Übrigens, ich nutze sogar noch den Atmega8 Chipbasic, eingebaut in ein
kleines Gehäuse mit Mini-TFT schaltet und regelt er ein paar Sachen bei
mir zu Hause :)
Eben gefunden:
https://www.youtube.com/watch?v=or0Cev_Ziag
Hier hat jemand die 32er Basis vom Chipbasic genommen und in einen
ATMega328 gepackt. Zwar alles auf russisch aber was mir besonders gut
gefällt sind die verschiedenen Chartables die er zur Laufzeit nutzt.
Besonders im Editor. Dort sind jetzt farbliche Syntax Hervorhebungen :)
Sehr cool!