Noch ein Taschenrechner auf ATMega Basis

[Gero D. (srswift)]

Was noch auf der "Zu-Tun_Liste" steht:
- Index-Funktion (damit Boris5 vollständig von-Neumann-kompatibel ist 
:-))
  Ausserdem brauchen es einige meiner alten Programme)
- Pause-Kommando (kann ja anstelle des herausgeflogenen DIMM-Kommandos 
hineinkommen)
- Anpassung des Compilers / Decompilers an die neuen Codes
- Testen
- Gehäuse

Es bleibt spannend ...

[Gero D. (srswift)]

Übrigens: Rechnende Speicher und die Loop-Befehle machen das 
Programmieren einfacher und die Programme schneller.

000 CX
001 STO 01
002 RCL 07
003 STO+ 01
004 LOOP7 002
005 RCL 01
006 HALT

Das ist die boris-5 . Variante des Gauss-Programms von oben. In Speicher 
07 steht am Anfang die 100. Nach 7 Sekunden ist das Ergebnis da....

[Gero D. (srswift)]

Ich hab die "C"-Varianten des Compilers / Decompilers an die geänderten 
Codes von boris5 angepasst.

Zu finden unter

https://github.com/Feinmechaniker/UPN/tree/master/C

[Gero D. (srswift)]

Der Softwarestand hat jetzt einen Zustand erreicht, den man durchaus auf 
die Menschheit loslassen könnte. Für die (aktuell) 40 Tasten hat sich 
eine Belegung gefunden, die recht gut funktioniert.

Funktional sind hinzugekommen:
- Eine Pause-Funktion für 1 Sekunde
- Ein Displaymodus "Hex"
- Eine Indexfunktion beim Speicherzugriff, z.B. STO Idx 5 bedeutet 
Speichern in den Speicher, dessen Adresse im Speicher 5 steht. Das ist 
allgemein für alle Speicher-, Loop und Sprungbefehle möglich.

Die Software füllt den ATmega 328 bis oben aus. Die Anzahl der 
Zahlenspeicher kann voreingestellt werden. Die Obergrenze liegt bei 64, 
dann ist der EEPROM voll. Programmschritte 255. Da liegt auch eine 
Einschränkung für die Weiterentwicklung. Die Adressen werden in einem 
Byte gespeichert...

Ich hab mal ein paar Fotos vom Display gemacht, v.o.n.u
Displaymodus 0 = normal, oben die Statuszeile, Grad/rad Einstellung, 
Programmspeicherzeiger, Displaymodus.
Darunter Y und X - Register.

Dann der Hex-Modus.

Dann die Anzeige bei der Programmausführung. Im Status ganz rechts die 
Steckebene.

Ganz unten die Anzeige im Programmiermodus. Die mittlere Zeile kann 
editiert werden.

Mir gefällt die Lösung, ich überlege, mir für den Boris5 ein Gehäuse zu 
bauen und das Gerät praktisch einzusetzen.

Die BASCOM-Sourcen sind aktualisiert.

[Josef G. (bome)]

Gero D. schrieb:
> - Ein Displaymodus "Hex"

Du schreibst hier Displaymodus-Hex und nicht einfach Hex-Modus.
Heisst das, dass du auch nichtganze Zahlen in hex anzeigen
kannst? Auf dem Foto sieht man nur ganze Zahlen.

Falls nein: Könntest du das nicht realisieren?
Auch wenn es derzeit kaum eine Anwendung dafür gibt,
hätte dein Rechner dadurch ein Alleinstellungsmerkmal.

Beitrag "Re: 8bit-Computing mit FPGA"

[Gero D. (srswift)]

Josef G. schrieb:

>
> Du schreibst hier Displaymodus-Hex und nicht einfach Hex-Modus.
> Heisst das, dass du auch nichtganze Zahlen in hex anzeigen
> kannst? Auf dem Foto sieht man nur ganze Zahlen.
>
> Falls nein: Könntest du das nicht realisieren?
> Auch wenn es derzeit kaum eine Anwendung dafür gibt,
> hätte dein Rechner dadurch ein Alleinstellungsmerkmal.
>

Da hatte ich auch dran gedacht, und auch ein wenig damit experimentiert. 
Ist aber aus Platzgründen erst mal nicht realisiert. Der Flash ist bis 
auf wenige Bytes voll.

Dem Voyager würde diese Funktion gut zu Gesicht stehen, da sollte 
genügend Platz im Flash sein, schaun wir mal!

[Uhu U. (uhu)]

Gero D. schrieb:
> Da hatte ich auch dran gedacht, und auch ein wenig damit experimentiert.

Aber nimmt dich in Acht, nicht dass der liebe Josef die Debatte von 
Beitrag "Vorschlag zu Hex-Ziffern auf 7-Segment-Anzeigen" hier fortführt. Das 
hätte dein schönes Projekt nicht verdient ;-)

[Joe G. (feinmechaniker)]

Ich habe Boris Voyger heute zum Leben erweckt :-)
Prozessor, USB, FRAM und Stromversorgung laufen. Weiterhin gibt es einen 
Bootloader der nur einmalig geflasht werden muss. Alle 
Programmänderungen können anschließend über die USB-Schnittstelle 
eingespielt werden (115200 Baud). Das geht jetzt richtig fix. Nun 
beginnt die Softwareanpassung deiner ATmega328 Software an die neue 
Hardware. Bootloaderquellen und HEX-Daten sowie Fuseeinstellungen wieder 
unter Github zu finden.

[Gero D. (srswift)]

Auch ich hab ein wenig von dem Voyager jetzt am laufen. Zwar noch nicht 
auf der Leiterplatte, aber auf dem Experimentierbord. Er rechnet schon. 
Ein paar Kleinigkeiten am Display sind gefixt, mit der Tastatur 
(besonders den "C"-Ports bin ich noch nicht zufrieden. Update der Source 
im GitHub später heute Abend.

[Joe G. (feinmechaniker)]

Gero D. schrieb:
> Auch ich hab ein wenig von dem Voyager jetzt am laufen. Zwar noch nicht
> auf der Leiterplatte, aber auf dem Experimentierbord. Er rechnet schon.

Klasse!

Im GitHub findest du unter "Query_keypad.bas" meine Routine zur 
Tastaturabfrage. Sie gibt die Tastennummer vom Keypad zurück (siehe PDF) 
wobei die Taste mit der Nummer 40 nicht in der Matrix existiert, da sie 
ja die ON/OFF Taste über den Interrupt realisiert. Die Abfrage ist aus 
meiner Sicht recht schnell (ca. 225us)

[Gero D. (srswift)]

Ich hab die Query_keypad-Funktion eingebunden, sie funktioniert genauso 
gut wie meine, ist aber besser zu lesen. Mit einzelnen Flash-Bytes 
brauchen wir ja nicht mehr zu geizen.

Das konkrete Mapping auf die 5x8-Tastatur muss noch in der Funktion 
Key2kdo() angepasst werden. Der Voyager hat jetzt die gleiche 
Funktionalität wie der boris5. Ist natürlich durch den höheren Takt 
10mal schneller :-)

Der Code enthält auch noch die 5V-Initialisierung fürs Display (solange 
ich noch auf dem Steckbrett bin)

Was noch zu tun ist:

- Anschließen des Speicherchips und Umstellen von EEPROM auf den NFRAM
- Anschluss des SD-Card-Readers und erstellen entsprechender 
LOAD/SAVE-Funktionen
- Anpassen von Compiler/decompiler/BorisCommander

Was man dann noch überlegen könnte:
- Erweitern des logischen Programmspeichers, zur Zeit ist bei 255 
schluss (1 Byte-Adresse)
- Erweitern des Zahlenspeichers auf 99 ist kein Problem (einfach den 
entsprechenden Const hochstehen), darüber hinaus ist aufwändiger 
(2stellige Adresse)
- ...

[Claudia C. (Gast)]

schade, das kein Coprozessor vorhanden ist, dann wäre ich auch daran 
interessiert.
Da ich immer sehr viel rechne und arg schnell tippe, nervt die 
Rechendauer schon erheblich, mit einem CoPro könnte ich wesentlich 
früher Feierabend machen

[Gero D. (srswift)]

Ein wenig Testerei hat einen Bug im Tastenmapping im Hex-Modus zutage 
gefördert. Ist behoben.

Als nächstes ist die SD-Karte dran. Ich hab mir überlegt, daß der 
Voyager seinen Compiler / Decompiler gleich mit eingebaut bekommt, beim 
Abspeichern entsteht also eine (menschen-) Lesbare Datei, kein 
Binärfile.

Vorgesehen sind erst einmal:
SFILE X - Speichert das Programm ab dem aktuellen PC in die Datei 
PROG_X.b5m
          auf die SD. Gespeichert wird bis zur Programmzeile mit dem
          END - Befehl oder bis zum Ende des Speichers
LFILE X - Lädt die Datei PROG_X.b5m in den Speicher ab dem aktuellen PC
OFILE_X - öffnet die Datei DATA_X.b5d zum Datenlesen
CFILE_X - schliesst die Datei DATA_X.b5d
RFILE - Liest die nächste Zeile aus der geöffneten Datei und 
interpretiert
           diese in das X-Register
WFILE - Fügt den Inhalt des X-Registers an die geöffnete Datei als Zeile 
an

Meinungen? Vorschläge? Kommentare?

[Joe G. (feinmechaniker)]

Gero D. schrieb:
> Ich hab mir überlegt, daß der
> Voyager seinen Compiler / Decompiler gleich mit eingebaut bekommt...

Ein sehr guter Vorschlag! Das verbessert die Lesbarkeit ungemein und der 
AVR hat ja in der neuen Version genug Speicher.

> Meinungen? Vorschläge? Kommentare?

Der Befehlssatz kling zunächst recht plausibel. Wie hast du dir den 
Dateinamen vorgestellt? Da es ja keine Buchstaben gibt, könnte man die 
Datei nur über eine Nummer adressieren.

Nachdem meine Platine nun einen passablen Testzustand erreicht hat, gibt 
es schon erste Entwürfe zu einem Gehäuse.

[GEKU (Gast)]

Gero D. schrieb:
> Ein Gehäuse, da muß ich mir noch etwas gutaussehendes ausdenken.

Wie sieht es mit der Tastatur aus?

Kommt eine bedruckte Folie über die Tasten?

Oder werden "*nur*"  Löcher ins Gehäuse gebohrt?

[Joe G. (feinmechaniker)]

Auf die Tasten kommen Tastenkappen (8mm x 8mm) und darüber eine 
transparente Kappe. Dazwischen kann die Beschriftung erfolgen. Die 
Tasten hatte ich schon mal hier [1] vorgestellt.

[1] Beitrag "Re: Noch ein Taschenrechner auf ATMega Basis"

[GEKU (Gast)]

GEKU schrieb:
> Wie sieht es mit der Tastatur aus?
>
> Kommt eine bedruckte Folie über die Tasten?
>
> Oder werden "*nur*"  Löcher ins Gehäuse gebohrt?

Nachdem ich den kompletten Thread gelesen habe, erübrigt sich meine 
Frage.

Tipp für die Beschriftung der Tasten:

Wir haben Kurzhubtasten mit einer durchgehenden, beschrifteten Folie 
eingesetzt.

Die Kurzhubtasten ragen durch das Gehäuse und schließen mit der 
Außenfläche plan ab.
Die Bohrungen sind um 2 bis 3mm größer als der Durchmesser der Tasten 
und können auch wie eine Senkbohrung ausgeführt sein.

Vorteil:

- dicht gegen eindringen von Flüssigkeiten
- sicherer gegen ESD
- keine zusätzlichen mechanischen Teile wie Tastenkappen,
- weniger  Probleme mit Fertigungstoleranzen (Tasten klemmen nicht)

Wenn das Display ebenfalls plan mit der Gehäuseoberfläche abschließt, 
kann die Folie mit einem Klarsichtfenster darüber gehen und sich über 
die gesamte Gehäuseoberfläche erstrecken. Die Folie kann zusätzlich auch 
im Gehäuse eingelassen werden.

Wenn ich mich richtig erinnere war der Hersteller:

https://www.forster.at/industrieller-siebdruck/dekor-und-frontfolien/

Es gibt auch jede Menge anderer Hersteller.

PS: finde das Projekt super

Eine zusätzliche LED Zeile mit dem am Stack davor liegenden Wert wäre 
eine große Aufwertung. Man sieht auf einen Blick auf welche Operanden 
der Operator wirkt.

[GEKU (Gast)]

GEKU schrieb:
> Es gibt auch jede Menge anderer Hersteller.

https://www.heinig-tastaturen.de/produkte/frontfolien.html

http://www.kohlstaedt.de/technologien/frontfolien.html

https://www.folientastaturen.de/de/produkte/frontfolien/

Ich kann mir vorstellen, dass sich die Preise im Bereich einer 
Leiterplatte liegen wenn man komplette Fertigungsunterlagen  liefert 
(ähnlich wie bei Leiterplatten mit den einzelnen Layern)

[Joe G. (feinmechaniker)]

Ziel des Taschenrechners ist - ihn tatsächlich auch zu benutzen.
Dazu ist aus meiner Sicht eine extrem zuverlässige, leichtgängige, mit 
definiertem Druckpunkt versehene Tastatur notwendig. Nichts ist 
schlimmer, als sich ständig mit fehlerhaften Eingaben rumzuärgern. 
Schaut man sich mal auf dem Markt um, so existieren keine ernsthaften 
Modelle mit Folientastatur.  Ich denke, das hat seinen Grund.

[Crazy Harry (crazy_h)]

Ich lese immer wieder gerne in diesem Thread und schaue mir auch gerne 
die neuesten Bilder dazu an. Respekt!

Falls es mal jemand langweilig wird, hätte ich noch ein paar 
Erweiterungsideen:
- grafisches Display z.B. DOGXL240 zum Darstellen von Funktionsgraphen
- XMega256 oder 384 @ 60 oder 64 MHz (60 ist zulässig, 64 laufen bei mir 
problemlos)
- USB-Tastaturinterface
- ADC-Eingänge die in einem Programm verwendet und berechnet werden 
können (Datenlogger? Messgerät?). Die Ergebnisse/den Log können auf der 
SD-Karte gespeichert werden.
- Binär-Modus bzw. einen Modus, bei dem die Ein-/Ausgabe parallel in 
allen Modi (Dez/Hex/Bin) erfolgt

Gruss & macht weiter so :-)
Harry

[Gero D. (srswift)]

So, hier ein Bild von meinem Prototypen (ist aber noch der boris5-drin, 
noch nicht der Voyager.

Meine Tastatur ist fast wie beim boris4, also die Taster auf der 
Leiterplatte, unter der Leiterplatte eine schmale Leiste zum Abstützen.
Die Tastenköpfe (diesmal keine Einzeltasten wegen des Klapperns) liegen 
mit 1-2/10mm Toleranz auf den Tasten auf. Die Beweglichkeit ist in 
diesem Fall nur durch die Flexibilität des Grundmaterials gegeben, rund 
um die Taste selbst (an den Seiten und unten) ist ein Spalt. Ein 
flexibles Scharnier.

Das funktioniert mit dem ersten Versuch schon ganz ordentlich, die 
mittleren Tasten in der oberen Zeile machen aber noch ein wenig 
Probleme. Ich muss wahrscheinlich noch ein wenig mit den Spaltbreiten 
und Materialstärken experimentieren.

Zu den Dateinamen: Das X in meiner Funktionsbeschreibung oben steht für 
eine Ziffer, das bedeutet zum Beispiel:

SFILE 5 - Speichert das Programm ab dem aktuellen PC in die Datei
PROG_5.b5m

Damit hätten wir 10 Programmfiles und 10 Datenfiles auf einer Karte 
möglich.

Möglich wäre alternativ auch SFILE XX also 100 Files. Aber das ist 
(glaub ich) dann schnell unübersichtlich.

Stay tuned.

[GEKU (Gast)]

Joe G. schrieb:
> so existieren keine ernsthaften
> Modelle mit Folientastatur

Ich meinte keine Folientastatur (Tastenkontakt in der Folie 
integriert). Viel zu teuer und schlecht zu bedienen.

Ich meinte eine Folie über die schon jetzt verwendeten Kurzhubtasten.
Es gibt Folien mit einer speziellen Prägung für Kurzhubtasten, bei der 
das "Druckgefühl" weitgehend erhalten bleibt.
Man kann mit unbedruckte Musterfolien experimentieren.

[Gero D. (srswift)]

So, die erste Version die halbwegs brauchbar mit dem SD-Card-Interface 
klarkommt liegt auf Github. Das Zusammenwirken mit dem Display ist jetzt 
fehlerfrei.

Hat noch einige Schwächen wie z.B.
- Fehlerbehandlung ist noch rudimentär
- die Initialisierung bei jeder Schreib/Leseaktion gefällt mir noch 
nicht, vor allem der Reset im Fehlerfall
- Die Zuordnung zu einer gescheiten Taste ist erstmal nur provisorisch 
zum Testen
- Die Namengenerierung ist noch nicht mit drin, zur Zeit sind die 
Dateinamen hartkodiert.
- Die Anzeige beim Schreiben ist schon OL, die beim Lesen einer Datei 
kann noch verbessert werden. Aber es ist erst einmal ein Stand, mit dem 
man experimentieren kann.

[Joe G. (feinmechaniker)]

Danke!
Dann werde ich mal ausgiebig Testen :-)

[Gero D. (srswift)]

Oje, da hatten sich doch einige Käfer eingeschummelt. Ich hab die 
Dateilesefunktion repariert (die hatte nur jede 10.Zeile in den EEPROM 
geschrieben) und die Dateinamensgenerierung fertiggestellt. Beim 
Dateilesen rollt der Programminhalt jetzt durch die Anzeige. Hier und da 
noch eine Kleinigkeit. Zu finden auf Github.

[Gero D. (srswift)]

Ich hab die Initialisierung der SD-Karte ein wenig brauchbarer gemacht 
(Retry wenn keine Karte im Schacht) und die Fehleranzeige bei den 
DOS-Funktionen überarbeitet. Die Software liegt wieder auf Github...

https://github.com/Feinmechaniker/UPN/blob/master/Bascom/Boris_Voyager.bas

[Thomas N. (tonevi)]

Mein Nachbau der LED Version mit leicht modifizierter Platine 
funktioniert sehr gut. Tolles Projekt! Eine Frage hierzu: Kann ich den 
Quelltext von Firmware 2.17 so konfigurieren, dass eine Verbindung zu 
BorisCommander hergestellt wird? Mit 2.16 funktioniert es noch, aber auf 
Github konnte ich den BASCOM-Code v2.16 nicht finden, wie von Gero am 
25.03. angegeben, um z.B. die U821 Darstellung zu deaktivieren.

[Joe G. (feinmechaniker)]

Die Versionsnummer im Dateinamen haben wir mit dem Umzug nach Github 
aufgegeben. Die aktuelle Version der ursprünglichen Hardwarevariante 
heißt immer „rpn_boris_A328.bas“. Diese Version beinhaltet sowohl das 
Protokoll für den BorisCommander als auch die blockorientierte 
Kommunikation. Umgestellt wird mit dem Compilerschalter 
„Block_communication“.

[Gero D. (srswift)]

Schaut gut aus, Dein boris!

Thomas N. schrieb:
Mit 2.16 funktioniert es noch, aber auf
> Github konnte ich den BASCOM-Code v2.16 nicht finden, wie von Gero am
> 25.03. angegeben, um z.B. die U821 Darstellung zu deaktivieren.

Joe G hat ja schon geantwortet, die 2.x Software findest Du auf Github 
hier:

https://github.com/Feinmechaniker/UPN/commits/321ee2086fe3e40fd65acbae8bc2855246a3c2b2/Bascom/rpn_boris_A328.bas

[Gero D. (srswift)]

Meine Tests mit dem Voyager gehen weiter, ich bin ganz zufrieden mit der 
aktuellen Version. Ein paar Waits könnten noch raus.

Was noch zu tun ist:

- Tastaturbelegung. Bisher hab ich meinen Aufbau nur auf dem 
Experimentierbord und da sind nur 32 Tasten. Die "richtige" 
Voyager-Belegung sollte jemand machen, der auch ein Voyager-Board aktiv 
hat. Inclusive der Entscheidung, wohin die neuen Funktionen kommen.

- Fehlerbehandlung beim Lesen von der SD-Karte. Syntaxfehler und falsche 
Adressen werden bisher nicht erkannt, wenn Unsinn gelesen wird, steht 
dann NOP im Speicher. Das geht besser, beim Lesefehler sollte eine 
entsprechende Fehlermeldung mit Verweis auf die fehlerhafte Zeile 
kommen. Ist in Arbeit.

- Lesen und Schreiben von Datenfiles. Am einfachsten könnte man da die 
schon existierenden Eingabe/Ausgabefunktionen benutzen. Dabei fällt mir 
aber ein "Schuldschein" aus der Vergangenheit auf die Füße. Bisher gibt 
es noch keine Eingabemöglichkeit für das "E" (1.234E21). Bisher hab ich 
mich davor gedrückt, und das bis heute keiner gemerkt. Wenn ich aber 
eine Zahl aus dem X-Register in eine Datei schreibe, möchte ich genau 
die auch lesen können. Daher ist die "Eex"-Taste nun unumgänglich. Kein 
großes Ding, muss aber gemacht werden. Erst dann sind die 
Dateifunktionen für den Zahlenspeicher sinnvoll.

- Verwendung des NFRAM anstelle des EEprom.

- ...

Stay tuned.

[Thomas N. (tonevi)]

Für beide Definitionen von „Block_communication“ gelingt die RS232 PC 
Kommunikation nicht mit BC V0.5. Bei Block_communication = 1 kommt 
bereits bei UART/Open die Meldung "Unable to open com port (Error: 1)". 
Bei Block_communication = 0 wird UART Open noch verarbeitet, bei Connect 
erscheint dann die Meldung "Boris antwortet nicht!" Anbei die beiden 
Varianten im Quelltext und neu compiliert als Binärfiles.

Danke an Gero, ich habe den 2.16 Code auf Github gefunden und für meine 
Zwecke konfiguriert - hier gelingt die UART Verbindung zum PC 
problemlos.

[Gero D. (srswift)]

Ich hab es mir gerade noch einmal angeschaut, die 2.16 und 2.17 
unterscheiden sich im wesentlichen durch die "Block-Befehle" auf der 
seriellen Schnittstelle. Die Blockbefehle werden auch nicht vom BC 
unterstützt, sondern nur von dem Programm "terminal" aus deb Bereich der 
"C"-Programme.

Was mir noch auffällt ist die Kalibrierung des RC-Oszillators, da stehen 
bei den beiden Versionen im Github unterschiedliche Werte drin, die 
sollten aber eh mit dem aktuellen Chip optimiert werden. Vielleicht ist 
das ja die Ursache, warum die 2.17 bei Dir nicht funzt?

Bei mir funktionieren beide Versionen einwandfrei.

Osccal = 95  <->  OSCCAL = 86

[Thomas N. (tonevi)]

Das war der entscheidende Hinweis. Ich habe den OSCTest laufen lassen, 
der in meinem Fall den Wert 70 für OSCCAL lieferte. Damit funktioniert 
es nun.

[Joe G. (feinmechaniker)]

Gero D. schrieb:
> - Tastaturbelegung. Bisher hab ich meinen Aufbau nur auf dem
> Experimentierbord und da sind nur 32 Tasten. Die "richtige"
> Voyager-Belegung sollte jemand machen, der auch ein Voyager-Board aktiv
> hat. Inclusive der Entscheidung, wohin die neuen Funktionen kommen.

Ich schwanke noch zwischen dem HP-11C und dem HP-15C Layout, wobei ich 
auch Interessenten für das HP-16C Layout (Programmierer) hätte. 
Wahrscheinlich gestalte ich es einfach austauschbar, wobei die 
Grundfunktionen ja in der HP-Voyager Serie immer an der gleichen Stelle 
liegen. Die EEX-Taste gibt es dann übrigens auch ;-)

[Joe G. (feinmechaniker)]

Hier mal ein erster Layoutvorschlag.

[Gero D. (srswift)]

Der Vorschlag hat was. Aber er erfordert eine zweite "Funktionstaste 
<g>", die dann ganz schön was im Code nach sich ziehen würde. Ich würde 
favorisieren, mit einer Funktionstaste "F" auszukommen zu versuchen :-)

Ich hab inzwischen den zweiten Punkt meiner Schuldenliste behoben, jetzt 
bleibt die Dateileseroutine bei einem Syntaxfehler in der fehlerhaften 
Zeile mit einer entsprechenden Fehlermeldung stehen.

Wie immer auf Github.

[Joe G. (feinmechaniker)]

Ich würde die Zweit- bzw. die Drittebene (f und g) einfach mit einem 
spezifischen Scancode auswerten, d.h. jede Tastenkombination erzeugt 
zunächst einen Code welcher erst dann ausgewertet wird. Wenn dieser Code 
in einer Tabelle abgelegt wird, kann die Tastaturanordnung jederzeit 
sehr einfach individuell angepasst werden.

Bsp.:
„2“ Scancode  „Code 1“ -> entsprechende Bearbeitung
„f 2“ Scancode „Code 2“ -> Umrechnung X-Register in Stunden, Minuten, 
Sekunden
„g 2“ Scancode „Code 3“ -> Umrechnung in Dezimal

[Gero D. (srswift)]

Der ungeliebte "E-"-Modus in der Eingabe ist jetzt auch mit unterstützt, 
man kann jetzt solche Sachen wie 123.456E-21 eingeben. Damit sind wir 
ein weiteres Stückchen HP-Kompatibler.
Außer im HEX-Modus, da verzichte ich vorerst auf diesen Luxus.

Die Source sind, wie gewohnt, auf Github.

Hier und da mag sich noch ein Problemchen verstecken, wer eins findet, 
kann es gern hier melden!

[Joe G. (feinmechaniker)]

Der erste Gehäusedruck. Es sind noch Kleinigkeiten zu verbessern, 
prinzipiell paßt es schon mal :-)

[srswift (Gast)]

Sieht gut aus! Ich mach mich mal an die Tastaturzuordnung.

[Gero D. (srswift)]

So, ich hab mal eine V0.1 der 8x5 Tastenbelegung eingebaut. Orientiert 
sich ein wenig an Deinem Vorschlag, aber nur mit 2-fach belegten Tasten. 
Mein Layout als Skizze angefügt. Ich hab es mit meinem Experimentierbord 
leider nicht testen können, also bitte Feedback!

Source auf Github.

P.S. Die zweitbelegungen (Lstx, Rdn, ABS, FRAC, INT u.s.w. sind wie beim 
Boris4...

[Joe G. (feinmechaniker)]

Dein Vorschlag ist eine gute Diskussionsgrundlage. Der Test war 
erfolgreich :-) Kleine Änderungsvorschläge hätte ich jedoch dazu. Mein 
Vorschlag kommt heute Abend. Die Funktion x^y ist ungünstig gelöst. So 
muss erst der Exponent und dann die Basis eingegeben werden. Ich habe es 
mal im Quelltext auf y^x geändert (erst Basis dann Exponent). So machen 
es auch die HP's

[Joe G. (feinmechaniker)]

Anbei mal mein Layoutvorschlag mit nur einer „Zweitfunktion“. Er 
orientiert sich sehr nah an den Original HP’s. Jedoch ohne die 
„Drittfunktionstaste“. Nun hätte ich es fast schon in den Code 
implementiert (die KeytoKdo Funktion ist ja übersichtlich) doch bei den 
Kommandocodes (Const K_xxx) rechnest du recht viel und ich befürchte 
einige Abhängigkeiten dabei zu übersehen ;-)
Neben all den von dir implementierten Funktionen habe ich noch die 
beiden Funktionen PGM und REG als Vorschlag eingefügt. F+PGM löscht den 
Programspeicher und F+REG löscht die Variablenspeicher.

Nachtrag: Nun habe ich selber X^Y geschrieben :-( Es soll natürlich Y^X 
heißen.

[Gero D. (srswift)]

Gefällt mir ganz gut. Ich würde aber die der Einheitlichkeit willen die 
X<Y, X=y und x>y Funktionen auf die Tasten 1-3 legen.

Meine Loop-Funktionen (Loop7...Loop9) sind auf Deiner Tastatur nicht mit 
drauf? Sind beim Programmieren echt praktisch (Schleife solange bis 
Register7..9 negativ wird). Auch der Index-Knopf fehlt, den hab ich 
bisher nur einmal gebraucht, da war er aber sehr nützlich.

Das x^y oder y^x ist Ansichtssache. Man könnte ja beides verwenden (y^x 
und als Zweitbelegung F x^y

[Joe G. (feinmechaniker)]

Gero D. schrieb:
> Gefällt mir ganz gut. Ich würde aber die der Einheitlichkeit willen die
> X<Y, X=y und x>y Funktionen auf die Tasten 1-3 legen.

Ja, klingt sinnvoll. Damit wird Platz für Loop x. Das Indexregister 
liegt eigentlich auf TAN als "Drittfunktion" Ich habe es einfach eine 
Position nach oben verschoben.

Gero D. schrieb:
> Das x^y oder y^x ist Ansichtssache.

Ich glaube das folgt der Logik wie bei e^x und 10^x, also immer erst die 
Basis und dann der Exponent.

[Joe G. (feinmechaniker)]

Im Anhang noch die Routine um über die ON/OFF Taste den Taschenrechner 
Ein- bzw. Auszuschalten. Du kannst sie ja bei Bedarf mal übernehmen. 
Tatsächlich wird er nicht ausgeschaltet, sondern nur in den Power Down 
Modus versetzt. Das Einschalten löst INT0 aus und weckt ihn wider auf.

[Stefan F. (Gast)]

Ich bin gespannt, wie du die Tastatur zuende baust. Solche mechanischen 
Sachen allen mir besonders schwer.

[Joe G. (feinmechaniker)]

Das Problem ist eigentlich schon gelöst. Die Beschriftung kann mit einem 
Drucker gemacht werden und wird dann zwischen die weiße Taste und die 
durchsichtige Kappe gelegt.

[Stefan F. (Gast)]

Joe G. schrieb:
> Das Problem ist eigentlich schon gelöst.

Schick! Selbst gemacht oder kann man diese Kappen irgendwo kaufen (will 
auch haben).

[Gero D. (srswift)]

Joe G. schrieb:
> Gero D. schrieb:
>> Gefällt mir ganz gut. Ich würde aber die der Einheitlichkeit willen die
>> X<Y, X=y und x>y Funktionen auf die Tasten 1-3 legen.
>
> Ja, klingt sinnvoll. Damit wird Platz für Loop x. Das Indexregister
> liegt eigentlich auf TAN als "Drittfunktion" Ich habe es einfach eine
> Position nach oben verschoben.
>


Es konvergiert langsam.

Die Loop-Funktionen würden mir auf den Tasten 7-9 besser gefallen, weil 
sie ja einen Bezug zum Speicher 7..9 haben.

Die On-Funktion baue ich gelegentlich mit ein.

Die Index-Taste macht mir noch Kopfschmerzen, die Müsste in die erste 
Ebene. Weil sie sich auf die Sprung und Speicherbefehle bezieht. Also 
z.B.  STO Index 22 oder STO + Index 34 oder GOSUB index 03. Da ist ein 
"F" dazwischen vergleichsweise ungünstig. Vielleicht könnte man dem F 
als Zweitbelegung die Indexfunktion geben. Das wäre von der Bedienlogik 
einleuchtend. Ob es von der Programmlogik gehen würde, muß ich noch 
prüfen.

Die Funktionen zum Speichern von Registerinhalten auf die SD-Karte 
bräuchten dann auch noch ein Plätzchen.

[Joe G. (feinmechaniker)]

Gero D. schrieb:
> Die Loop-Funktionen würden mir auf den Tasten 7-9 besser gefallen, weil...

Die Loop-Funktionen habe ich gegen FIX und DEG getauscht. Für die 
Indextaste könnte man auch die Position von LST X nehmen. Diese Funktion 
muss ja nicht unbedingt in die Erstbelegung. Bei HP liegt LST X auf der 
ENTER Taste. Für die Speicherfunktionen auf der SD-Card sind dann noch 
die Zweitbelegungen in der unteren Ziffernreihe frei.

Stefanus F. schrieb:
> Schick! Selbst gemacht oder kann man diese Kappen irgendwo kaufen (will
> auch haben).

Ja, kann man kaufen. Sogar recht preiswert :-)

https://de.aliexpress.com/item/32527071767.html?storeId=1952980&spm=a2g0x.12010612.8148356.5.5b6d4518VIYZF3

https://de.aliexpress.com/item/32534955696.html?storeId=1952980

[Gero D. (srswift)]

Die Variante gefällt mir, ich werd sie heute Abend so implementieren.

[Stefan F. (Gast)]

Joe G. schrieb:
> Ja, kann man kaufen. Sogar recht preiswert :-)

Kauf ich mir, so etwas gehört auf jeden Fall in die Vorratskiste.

[Gero D. (srswift)]

So, ich hab die Tastaturbelegung (mit kleinen Abweichungen) 
implementiert. Der Index-Key ist anstelle des Ist-X in die erste Ebene 
gekommen, y^x ist in der ersten Ebene (der Original-Boris und alle seine 
Abkömmlinge hatte ein x^y, das ist als Zweitbelegung auf der gleichen 
Taste, damit brauch ich meine alten Programme nicht zu ändern).
Die noch fehlenden Funktionen (10^x, log(x) ...) sind jetzt auch mit 
drin. Meine Tests waren ganz brauchbar.

Der Quelltest liegt auf Github. 
https://github.com/Feinmechaniker/UPN/blob/master/Bascom/Boris_Voyager.bas

Dann hab ich mal den aktuellen Befehlssatz dokumentiert. Leider haben 
sich einige Codes geändert, der BC muss also angepasst werden :-( Die 
Zusammenfassung findet man hier:
https://github.com/Feinmechaniker/UPN/blob/master/Doc/Befehlssatz_boris_voyager.pdf

Zum Einschalter: Die Lösung mit dem Sleep funktioniert soweit, wenn 
zusätzlich auch das Display in den Schlafmodus geschickt wird (und nicht 
nur die Hintergrundbeleuchtung ausgeschaltet wird) geht die 
Stromaufnahme bei mir auf etwa 0.12 mA zurück. Das ist ganz ordentlich, 
aber zuzelt einen normalen Akku aber auch innerhalb ein paar Wochen 
leer. Das gefällt mir noch nicht. Muss ich noch mal nachdenken.

Wie immer: Wer Fehler findet: immer her damit!

[Joe G. (feinmechaniker)]

Super!
Mein Test stimmt mit der Tastenbelegung überein - tolle Arbeit! Da es 
jetzt (fast) HP Voyager kompatibel ist, kann ich den Boris nun wieder 
blind bedienen :-) Macht richtig Spaß.

Ich denke wir nähern uns bezüglich der Belegung einem stabilen Zustand, 
so dass ich den BC daruf anpassen werden. Er bekommt dann nur noch eine 
Taste zum Umschalten auf die alte Version.

Sleep geht noch nicht, ist aber, soweit ich es übesehe, auch noch nicht 
im Quelltext.

Anmerkung für potentielle Nachnutzer:
Die neue Hardwareversion läuft auf 3.3V, so dass der Schalter Const 
Dog_5v_comp = 0 zu setzen ist! Das erspart ärgerliche Fehlersuche ;-)

Nachtrag: Das erste Layoutbild war nicht vollständig.

[Gero D. (srswift)]

Der Ein/Aus-Schalter auf Taste Nr. 40 ist jetzt auch aktiv. Ich hab die 
Routinen ein kleinwenig modifiziert, bei mir tun sie klaglos ihren 
Dienst. Das Display und die Hintergrundbeleuchtung werden um des 
optischen Effekts willen gestaffelt geschaltet. Die Anzeige "Power OFF" 
ist so gemacht, daß die ursprünglichen Anzeigenhalte erhalten bleiben.

Dann noch ein paar Kleinigkeiten, z.B. ein Kommentarzeichen für die 
Programmdateien. Alle Zeilen, die in der ersten Position ein # haben, 
werden ignoriert.

Mich würde interessieren, wieviel Strom die vollständig bestückte 
Leiterplatte im "AUS"-Modus nimmt. Kann das mal bitte jemand messen?

[Joe G. (feinmechaniker)]

Gero D. schrieb:
> Der Ein/Aus-Schalter auf Taste Nr. 40 ist jetzt auch aktiv.

läuft...

Stromaufnahme im 3.3V Betrieb (5V Input):
82,6 mA    Prozessor, LCD, LCD Beleuchtung, SD-Card
7,8 mA     Prozessor, LCD, SD-Card
7,6 mA     Prozessor, LCD
324 uA     Prozessor Power Down, LCD Power Down

[Stefan F. (Gast)]

Wenn das Tastenfeld komplett fertig ist, dann mach bitte detaillierte 
Fotos von der Tastatur. Darüber würde ich mich freuen.

[Gero D. (srswift)]

Joe G. schrieb:

> Stromaufnahme im 3.3V Betrieb (5V Input):

> 324 uA     Prozessor Power Down, LCD Power Down

Das ist eine Menge. Ich nehme mal an, da ist keine SD-Card dabei, aber 
sowohl der UART/USB-Chip als auch der NFRAM aktiv mit dabei?

Meine Zahlen vom Experimentierbord sind deutlich niedriger, aber sicher 
nicht repräsentativ.

Spannend ist die Frage, mit welchem Aufwand man noch mehr abschalten 
könnte, aber das wäre dann eine Hardwareänderung. Bleibt also 
wahrscheinlich nur, einen dickeren Akku zu nehmen. Meine Boris haben 
jeweils nur einen 120 mAh - Akku. Der würde halbgeladen dann eine gute 
Woche im Power-Down-Modus durchhalten...

Ich bin gerade beim Anpassen von Compiler und Decompiler für den Boris 
Voyager. Die beiden Mnemoniken "C Reg" und "C Prg" würde ich gern aus 
Einheitlichkeitsgründen noch mal Ändern (das Leerzeichen raus).
Einwände?

[Gero D. (srswift)]

Die beiden Mnemonics sind geändert und die 3.3V Displaymode ist jetzt 
voreingestellt.
Dann hab ich noch den Compiler und Decompiler (die C-Tools) für den 
Voyager zurecht gemacht. Die sind für den Voyager nicht mehr gar zu 
wichtig, weil die Files auf der SD-Karte ja Quelltest enthalten und 
nicht mehr den Speicherinhalt.
Da der Aufbau der Zeilen doch einige zusätzliche Bedingungen mit sich 
bringt, ich aber den Compiler für den kleinen Boris4 (mit der 
LED-Anzeige) auch benutzen können möchte, sind im C-Teil doch einige 
if() hinzugekommen. Nicht schön, aber es tut.

Der code liegt wie gehabt auf Github. Achtung, das pdf mit der 
Codeübersicht ist noch nicht korrigiert.

[Gero D. (srswift)]

Ein paar kleine Korrekturen in der Fehlerbehandlung bei den Lese- und 
Schreibroutinen der SD-Karte sind hinzugekommen ...

[Gero D. (srswift)]

Die I2C-Unterstützung (NFRAM = FM24CL64B) ist in Arbeit, wird aber noch 
ein paar Tage brauchen. Ich habe das ganze per Compileswitch schaltbar 
gemacht. Also alternativ interner EEPROM für Programm- und 
Zahlenspeicher oder I2C-Speicher. Das kann dann wahlweise externer 
EEPROM oder F-RAM sein. Aber, wie schon erwähnt, das dauert noch ein 
wenig.

[Gero D. (srswift)]

Auf https://thimet.de/CalcCollection/CalcPerformance.html gibt es eine 
hübsche Übersicht über die Rechengeschwindigkeit verschiedener 
Taschenrechner. Der "Ur-Boris", oder besser einer seiner Abkömmlinge 
(Elektronika MK-61) steht ganz oben in der Liste (er braucht für das 
Beispielsprogramm am längsten). Da das Beispielsprogramm recht einfach 
ist, war es geschwind für meinen boris4 und den Boris-Voyager angepasst 
und siehe da, die Eigenbauten schlagen sich wacker. Boris4 mit 1MHZ Takt 
kommt mit 26s auf einen Index von 13 und liegt gleichauf mit dem HP-42S. 
Boris-Voyager kommt mit 10.2s auf einen Index von 33 in etwa beim 
HP-32S. Da kann man ein wenig stolz drauf sein.

Anbei die Programme:
bench4.b4s - Quelltext für boris4
bench4.bor - Ladbares Programm für boris4
PROG_3.B5M - Quelltext / lidbares Programm für boris voyager

[Jens G. (jensg)]

Gero D. schrieb:
> geht die
> Stromaufnahme bei mir auf etwa 0.12 mA zurück. Das ist ganz ordentlich

Es könnte am Längsregler liegen. Dieser Strom fließt nach Ground ab. Ein 
LDO Typ für 3.3V zum Beispiel der TS9011SCY oder der HT7333-A ist da gut 
(wenige µA nach Ground). Von letzterem habe ich einige - biete ich zum 
verschenken an - bitte private Nachricht an mich.

[Gero D. (srswift)]

Jens G. schrieb:

> Es könnte am Längsregler liegen. Dieser Strom fließt nach Ground ab. Ein
> LDO Typ für 3.3V zum Beispiel der TS9011SCY oder der HT7333-A ist da gut
> (wenige µA nach Ground). Von letzterem habe ich einige - biete ich zum
> verschenken an - bitte private Nachricht an mich.

Das kann gut sein. Laut Datenblatt können es beim LP2950 3.3, der bei 
mir verbaut ist, schon einige mA sein. da ist der HT7333-A eine ganz 
andere Sache. Gute Idee!

Was mir noch aufgefallen ist. Im Power-Down-Modus ist die SD-Karte der 
größte Stromfresser. 2mA, da ist der Akku ganz schnell leer. Also, vor 
dem Ausschalten die Karte ziehen!

[Joe G. (feinmechaniker)]

Da ich im Urlaub war, erst jetzt die Antwort.

Ich hatte den LP2950 3.3 nach der Dropout Spannung ausgesucht (150 mV 
bei 50 mA). Der TS9011 hat laut Datenblatt 400 mV. Mein Ziel war den 
Akku möglichst optimal nutzen zu können. Bei einem Redesign würde ich 
die komplette Stromversorgung mit einem Mosfet hat abschalten.

[Jens G. (jensg)]

Joe G. schrieb:
> Ich hatte den LP2950 3.3 nach der Dropout Spannung ausgesucht (150 mV
> bei 50 mA).

Beim HT7333-A sind es bei 40mA etwa 90mV Spannungsabfall. Es sollten 
also bei 50mA nicht mehr als 115mV sein.

https://github.com/JensGrabner/snc98_Slash-Number-Calculator/blob/master/Hardware/Pdf/snc98_main_cpu_sch.pdf
.. auf Seite 3 schalte ich mit M4 die Schaltung gegen Ground "Ein" und 
"Aus".

[Joe G. (feinmechaniker)]

Jens G. schrieb:
> .. auf Seite 3 schalte ich mit M4 die Schaltung gegen Ground "Ein" und
> "Aus".

Danke! Das war auch meine Idee dazu. Eine überarbeitete Version bekommt 
diese Änderung. Auch der Einsatz eines HT7333-A lohnt sich dann.

[Gero D. (srswift)]

So, der vorläufig letzte Punkt auf der Schuldenliste, der externe RAM. 
Gestaltet sich mit BASCOM und den entsprechenden Libs angenehm einfach. 
Ich hab es mit einem 24C512 getestet, bei mir tut es anstandslos. Und 
wenn sich der FRAM  FM 24C64B-G nicht irgendwie zickig tut, sollte er 
auch funktionieren.

Source auf Github 
https://github.com/Feinmechaniker/UPN/blob/master/Bascom/Boris_Voyager.bas

Fehlermeldungen und Kritik bitte hier.

[Jens G. (jensg)]

Für das FRAM ist das hier vielleicht nützlich: 
https://github.com/adafruit/Adafruit_FRAM_I2C

[Alexander T. (loeschen)]

Was ein geiles Projekt!
Super gemacht!

[Gero D. (srswift)]

Mein Verhältnis zur SMD-Löterei hat sich nur wenig verbessert. Um aber 
trotzdem von all den Verbesserungen, die "boris" in den letzten Monaten 
erfahren hat, teilhaben zu können, entstand eine "Special-Edition". Oder 
besser: ist am entstehen. Auf den FRAM hab ich verzichtet, die 
USB-Schnittstelle macht ein MCP2221. Der Sleep-Einschalter ist nur 
optional, die Akkuladeelektronik ist nicht mit auf dem Mainboard. Die 
Leiterplatte ist in Prozessorteil und Tastatur aufgeteilt, es gibt die 
volle 8x5-Tastenmatrix. Der Takt kommt aus dem internen RC-Oscillator 
des ATmega 1284.

Das ganze ist softwaremäßig zum Voyager kompatibel, der BASCOM-code aus 
dem Github wird 1-zu-1 verwendet. Und funktioniert (einschließlich USB, 
SD-Karte, Sleep-Modus ...) einwandfrei.

Als Gehäuse schwebt mir ein "Mini-Laptop" vor, die ersten Teile passen 
ganz gut, ein wenig Fein-Tuning ist aber noch erforderlich. Die 
Grundfläche ist kleiner als beim Voyager, die Dicke ist natürlich nicht 
so schön. Schaumerma.

Eagle-Dateien und Ultimaker-gcode kommt in ein paar Tagen (auf Wunsch)

[Joe G. (feinmechaniker)]

Nette Idee mit dem Mini-Laptop :-) Auch der THT Aufbau schafft Raum für 
SMD-Verweigerer bzw. senkt die Hürde für einen Einsteiger.

Mein Gehäuse ist jetzt ausgereift und ich stelle die STL-Daten auch auf 
die Projektseite.

[GEKU (Gast)]

Gero D. schrieb:
> Also, vor dem Ausschalten die Karte ziehen!

Warum gerade vor dem Ausschalten?

Wäre es nicht sicherer nach dem sauberen Herunterfahren der Software?

[Gero D. (srswift)]

GEKU schrieb:
> Gero D. schrieb:
>> Also, vor dem Ausschalten die Karte ziehen!
>
> Warum gerade vor dem Ausschalten?
>
> Wäre es nicht sicherer nach dem sauberen Herunterfahren der Software?

Beim Testen hab ich es nicht geschafft, kaputte Dateien auf die SD-Karte 
zu schreiben. Solange man die Karte nicht zieht, solange geschrieben 
wird (und das sieht man ja am Display) ist alles gut. Aus 
Stromverbrauchsgründen sollte aber die Karte draußen sein, während der 
Rechner "schläft".

[Stefan F. (Gast)]

Gero D. schrieb:
> Aus
> Stromverbrauchsgründen sollte aber die Karte draußen sein, während der
> Rechner "schläft".

Das würde ich automatisieren. Nicht den Auswurf, sondern die Abschaltung 
der Karte. Das kann man vielleicht elegant mit einem abschaltbaren 3V 
Spannungsregler hinbekommen. Dessen Strombnegrenzung würde zugleich den 
Rest der Schaltung vor Einbruch der Versorgungsspannung wegen hoher 
Strom-Spitzen beim Einstecken/Einschalten beschützen.

[Joe G. (feinmechaniker)]

Stefanus F. schrieb:
> Das würde ich automatisieren. Nicht den Auswurf, sondern die Abschaltung
> der Karte.

Beitrag "Re: Noch ein Taschenrechner auf ATMega Basis"

[Gero D. (srswift)]

"Grau, teurer Freund, ist alle Theorie und grün des Lebens goldner 
Baum." heissts im Faust. Und deshalb sollte die Praxis am Ende über die 
ganze Borisfamilie urteilen. Ich hab einige Varianten bebaut, und ein 
paar davon haben sich tatsächlich in der Praxis bewährt.

Die erste Variante "boris4" gefällt mir durch die riesengroße Anzeige. 
Das Gerät selbst ist kompakt genug, in die Hemdtasche zu passen. Der 
Akku hält hinreichend lange. Die Alblesbarkeit der Anzeige in hellem 
Sonnenlicht ist aber mangelhaft, die rote Streufolie verbessert es zwar 
deutlich, aber für den Flugplatz ist es nichts.

Der "boris5", eigentlich nur ein Zwischenschritt zum "Voyager" schlägt 
sich in der Praxis wacker. Das Display ist auch in hellem Sonnenlicht 
(mit und ohne Displaybeleuchtung) gut abzulesen. Die transflexiblen EA 
DOG-M Displays (FSTN) sind da unglaublich leistungsfähig.
Die Erweiterte Funktionalität (z.B. Hex-Modus) ist ein echter Zugewinn. 
Das Gehäuse ist nur wenig größer und passt gerade noch in die 
Hemdtasche. Die Serielle Schnittstelle ist ein echtes Plus.

An den SMD-Voyager hab ich leider immer noch nicht herangetraut, meine 
Spezial-Voyager-Version ohne SMD ist eher nicht so praktisch. Das 
Gehäuse ist einfach zu klobig. Ob ich mich da noch mal an eine 
Verbesserung heranmache, weiß ich noch nicht.

Der "Zwischenboris" gefällt mir so gut, daß ich ihm demnächst eine 
gescheite Tastenbeschriftung (Wasserschiebenbilder, wie weiter oben 
schon mal beschrieben) verpassen werde.

[Uhu U. (uhu)]

Gero D. schrieb:
> An den SMD-Voyager hab ich leider immer noch nicht herangetraut

SMD-Technik ist nicht so wild. 0805 lässt sich manuell gut verarbeiten, 
0603 geht auch noch. Sogar mit selbstgeätzten Platinen ohne 
Lötstoppmaske.

[Gero D. (srswift)]

Hier noch einmal ein Größenvergleich der Familienmitglieder ...

[Gero D. (srswift)]

Auf Github gibt es ein paar kleine Korrekturen. Vor allem für die 
Behandlung der Hintergrundbeleuchtung während der Programmausführung. 
Wenn boris rechnet, schickt er die LED jetzt auch nach ein paar Sekunden 
in den Ruhemodus. Bei Stop, Fehler oder Pause (oder Programmende) geht 
das Licht dann wieder an.
Die Kontrastwerte für die FSTN-Variante der EA-DOG-Displays habe ich mir 
auch herausexperimentiert, die stehen als Kommentar mit im Code.

Und zwei kleine Programme für den Boris5/Voyager. Die Klassische 
Fingerübung von Mittelwert uns Streuung einer Meßreihe. Und dann gleich 
mal den (Pseudo-)Zufallszahlengenerator damit untersucht...

hier findet sich der BASCOM code für boris5 und Voyager: 
https://github.com/Feinmechaniker/UPN/tree/master/Bascom

und dort die Taschenrechner-Programme:
https://github.com/Feinmechaniker/UPN/tree/master/Programme

Viel Vergnügen!

[Gero D. (srswift)]

Hyperbel- und Arenafunktionen, jeder Taschenrechner, der was auf sich 
hält hat die rätselhaften "Hyperbolicus"-Tasten, obwohl kaum einer weiß, 
wofür die gebraucht werden. Der Ur-Boris hatte sie nicht. Irgendwann 
während des Studiums brauchte ich sie dann doch und es war keine große 
Sache, sie zu programmieren.

100 ENTER ; sinh(x)
    E^X
    X<->Y
    /-/
    E^X
    -
    2
    /
    RETURN

Dieses Programm läuft natürlich auch auf den aktuellen Borisen. Klar 
könnte man es in die Firmware einbauen. Aber beim kleinen boris4 und 
meinem Lieblingsboris(5) sind keine Tasten mehr frei. Und so häufig 
braucht man es nun wirklich nicht.

Beim Experimentieren mit den, als Unterprogramm geschriebenen 
Funktionen, entstand eine kleine Funktionserweiterung, die für alle 3 
Ausführungen (4,5 und Voyager) jetzt auch auf Github liegt: Wenn man 
interaktiv den GOSUB - Befehl aufruft, wird das Unterprogramm 
automatisch gestartet und nach dem RETURN wird angehalten. 
Unterprogramme innerhalb der Funktionen funktionieren wie gewohnt. Die 
sinh() - Funktion beispielsweise kann also einfach mit GOSUB 100 
gestartet werden, und Sekundenbruchteile später steht das Ergebnis im 
X-Register. Ich find's praktisch.

Das Boris-Programm und die aktualisierten Firmwares wie immer auf 
Github.
https://github.com/Feinmechaniker/UPN

[Gero D. (srswift)]

Die letzten tage boten etwas Zeit zum Experimentieren mit Boris. Wozu 
benötigt man Lineare Regression, die Simpson-Regel oder das 
Newton-Verfahren? Praktisch wahrscheinlich nur dazu, programmieren in 
altmodischer Weise zu lernen. Heutzutage steigt bestimmt kein mensch 
mehr über diesen Seiteneingang in die Softwareentwicklung ein. Trotzdem 
ist das Netz voll von solchen mathematischen Fingerübungen. Und jetzt 
gibt es diese auch für boris (4,5,Voyager). Natürlich auf 
https://github.com/Feinmechaniker/UPN/tree/master/Programme

Nebenbei haben sich einige Kleinigkeiten angefunden, die ich verbessert 
hab. Die nervigen Schwanznullen im Floatmodus sind dem Weihnachtsurlaub 
zum Opfer gefallen. Und ein paar weitere Kleinigkeiten auch noch.

So, ich denk mal, damit ist Boris nun fertig...

[Gero D. (srswift)]

Coronas Ausgangssperre sei dank, ich hab den Programme-Bereich auf 
Github https://github.com/Feinmechaniker/UPN/tree/master/Programme mal 
mit allerlei mehr oder weniger nützlichen Boris-Programmen gefüllt. Die 
meisten davon gibt es dreimal, als 200 Byte große binäre *.bor-Datei für 
den Boris4, die per BC über die Serielle Schnittstelle (oder das 
USB-Kabel direkt an der UART) hochgeladen werden kann, als 
*.bs4-Quelltext zum Eintippen (und zum Verstehen, was da so abgeht) 
sowie als *.B6M Datei, die als ausführbarer Quelltest per SD-Karte in 
den Boris Voyager geladen werden kann.

Sogar die unvermeidliche Mondlandung ist dabei.

Viel Spaß beim Ausprobieren.

gero

[Joe G. (feinmechaniker)]

Bei Pollin gibt es gerade das DOGM163S-A, 3x16 Zeichen Display mit 
Hintergrundbeleuchtung für 0,95€ das Stück :-) Kostet sonst über 10€. 
Wer es für den Boris in schwarz mag oder anderweitig nutzen möchte ...
https://www.pollin.de/p/lc-display-electronic-assembly-dogm163s-a-3x16-zeichen-gelb-gruen-121770

[Gero D. (srswift)]

Das ist echt verlockend. Ich spiel mit dem Gedanken, mit den Erfahrungen 
und Verbesserungen aus diesem Projekt eine neue Leiterplatte zu 
entwerfen. So klein wie der erste boris hier im Thread, mit dem 
Dreizeil-Display und einem optimiertem Funktionsumfang. Schau mer mal, 
wie lange wir noch im Homeoffice stecken ...

Meine Praxiserfahrungen sind:
- Geschwindigkeit, Genauigkeit völlig ausreichend
- Bedienung (Tastenqualität) ist gut
- Akku hält ausreichend lange
- 99 Zahlenspeicher sind mehr als genug, die Hälfte würde es auch tun.
- 255 Programmschritte reichen aus, mein größtes Programm hatte bisher 
etwa 220
- Programmierung erfolgt fast ausschließlich auf dem PC, die 
Programmierfunktionen auf dem Taschenrechner werden fast nicht benutzt
- USB-Interface ist sehr nützlich, die SD-Variante ist weniger praktisch 
(Nichtsprechende Dateinamen, Einstecken / Auswerfen der Karte beim 
Entwickeln und Testen ist lästig)
- der Hex-Modus und vor allem der Stunden-Modus sind sehr praktisch
- Der Einzelschritt-Modus (boris5) funktioniert zum debuggen sehr gut.
- Der Compiler (auf dem PC) ist inzwischen erwachsen (z.B. symbolische 
Labels), könnte aber auch noch einige Erweiterungen vertragen.

Wünsche:
- Permanente Speicherung mehrer Programme auf dem boris, von denen dann 
eins ausgewählt und aktiviert werden kann. Die Programme müssten dann 
"Anzeigenfähige" Namen haben. Damit könnte man dann z.B. ein 
Statistikpaket oder ein Navigationspaket zusammenstellen und ohne 
Externaktionen verwenden. Dazu bietet sich der I2C-EEPROM oder NFRAM an, 
der für den Voyager verwendet wurde
- Mehr Display-Modi (Integer, Fix 4 ...)
- Ein "Setup-Menue" welches zum Beispiel durch Drücken einer Taste beim 
Einschalten aufgerufen wird und die Einstellung von Kontrast u.s.w und 
des OSCAL-Wertes ermöglicht. Damit wäre eine Kalibrierung ohne Neuflach 
möglich.

Soweit erst mal meine Ideen. Sieht so aus, als ob die Boris-Geschichte 
doch noch nicht zu Ende ist. Vielleicht hat ja auch noch jemand anders 
gute Ideen?

gero

[Asko B. (dg2brs)]

Gero D. schrieb:
> Schau mer mal, > wie lange wir noch im Homeoffice stecken ...

Hallo,

... und da hat man ja etwas mehr Zeit mal etwas weiter zu scrollen.
Ich fand ein Bild/Link und hatte das Gefühl: "Sowas haste doch schon
mal irgendwo gesehen".

https://www.amazon.de/KKmoon-Taschenrechner-elektronischen-Mehrzweck-elektronische/dp/B07BGTV7ZM

Das sieht Eurem auf dem ersten Blick sehr ähnlich.

Ich wollte Euch das nicht vorenthalten, aber eventuell kennt
Ihr das schon. (Auf jeden Fall kamen mir die Tasten so bekannt vor)

;-

Gruss Asko

[Stefan F. (Gast)]

Asko B. schrieb:
> 
https://www.amazon.de/KKmoon-Taschenrechner-elektronischen-Mehrzweck-elektronische/dp/B07BGTV7ZM
>
> Das sieht Eurem auf dem ersten Blick sehr ähnlich.

Optisch ja, aber was ist mit der Software. Nach den Erfahrungen, die ich 
bisher mit Produkten und dem Support von KKmoon gemacht habe, befürchte 
ich, dass das Ding falsch rechnet.

[Asko B. (dg2brs)]

Stefan ⛄ F. schrieb:
> Optisch ja, aber was ist mit der Software. Nach den Erfahrungen, die ich
> bisher mit Produkten und dem Support von KKmoon gemacht habe, befürchte
> ich, dass das Ding falsch rechnet.

Ich meinte wirklich, es sieht Eurem sehr ÄHNLICH.
Umgekehrt Polnische Notation beherrscht das Ding auch nicht.
Fühlt Euch doch geehrt.....


Gruss Asko

[Gero D. (srswift)]

Hallo,
so, einige Zeit ist ins Land gegangen. Und die Geschichte ist ein wenig 
weiter gegangen. Auslöser war das schon genannte Sonderangebot der 
Dreizeilendisplays. Und ein paar Verbesserungswünsche.
Herausgekommen ist ein neuer boris. Mit folgenden Änderungen:
- 27 Tasten, kleineres Format 73*100 mm
- Serielle Schnittstelle zum Laden von Programmen vom PC
- Die Praxis hat gezeigt: Programmieren auf dem Taschenrechner ist nicht 
der Weisheit letzter Schluß, das geht auf dem PC besser. Die 
Programmiertasten auf den Taschenrechner sind also entfallen
- Ein I2C-EEPORM kann 8 solche Programme speichern
- Die Taschenrechnerprogramme sind komfortabler geworden, die Eingaben 
und Ausgaben können jetzt Zeichenketten enthalten. Siehe im Bild das 
kleine Programm zur Berechnung von Sonnenauf- und Untergangszeit.
- Der Compiler auf dem PC ist auch ein wenig erweitert worden, 
Symbolische Adressen und Variablennamen sowie die schon erwähnten 
Zeichenketten sind dazugekommen.
All das passt auf eine doppelseitige Leiterplatte, der ATMega328 ist 
damit randvoll. Wie auch schon die anderen Borisse: keine SMDs, und nur 
der interne RC-Oszillator mit 8MHz. Eine Lipo-Zelle kommt als Akku zum 
Einsatz.

Die Platine kann in den Varianten Mit und Ohne USB-Schnittstelle sowie 
mit und ohne I2C-EEPROM bestückt werden.

Auf Wunsch kommen Schaltplan, Platine und BASCOM-Code in den nächsten 
Tagen. Gehäuse muss noch.

[Gero D. (srswift)]

So, hier der BASCOM-code und der Schaltplan. Der Code benötigt noch ein 
wenig liebevolle Zuwendung, er tut aber, was er soll. Die 
Taschenrechnerfunktion ist unverändert, die Funktionen für das Editieren 
des Programms auf dem Gerät, Codeanzeige und das Herunterladen des 
Programms auf den PC sind entfernt (aus Platzgründen), dafür sind die 
I2C-Routinen (Inspiriert vom R.Walter-Buch) hinzugekommen.

[Joe G. (feinmechaniker)]

Gero D. schrieb:
> Auf Wunsch kommen Schaltplan, Platine und BASCOM-Code in den nächsten
> Tagen. Gehäuse muss noch.

Die neue Version sieht gut aus und ist wie immer von dir im wirklich 
nachbausicherem Design :-) Ja bitte, die Unterlagen zur Nachnutzung 
bereitstellen.

Nachtrag: Da haben sich unsere Beiträge gerade überschnitten :-)

[Gero D. (srswift)]

Hier noch als Beispiel das Programm für die Berechnung von Sonnenauf- 
und untergang. Die Kommentare erklären ein wenig. Neu sind:

- Symbolische Variablennamen (Zeile 40-62)
- Variablenvorbelegung durch den Compiler (Z. 50-62) das spart 
Programmspeicher
- Symbolische Sprungadressen (keine mauelle Korrektur erforderlich, wenn 
mal Zeilen hinzukommen)
- Zeichenketten, die bei "HALT" in der Statuszeile ausgegeben werden. 
(Z. 72, 165)

Damit verringert sich die Programmgröße im Speicher auf die Hälfte.
Den Compiler gibt es für Linux und Windows...

[Stefan F. (Gast)]

Schön, saubere Arbeit!

[Thomas G. (Firma: Frickelhauptquartier) (taximan)]

Auf welche Genauigkeit kommst du bei SA / SU? Bin auch an sowas dran, 
nur länger  nicht mehr dazu gekommen.

[Gero D. (srswift)]

Thomas G. schrieb:
> Auf welche Genauigkeit kommst du bei SA / SU? Bin auch an sowas dran,
> nur länger  nicht mehr dazu gekommen.

bei SA/SU musst Du mir auf die Sprünge helfen. Die verwendete 
Double-Arithmetik ist für meine Zwecke völlig ausreichend.

12-(sqrt(12)*sqrt(12)) ergibt 1.7763 E-15 und das ist bei einer 
16stelligen Anzeige absolut OK.

[Thomas G. (Firma: Frickelhauptquartier) (taximan)]

Sonnenauf- und Untergang. Ich komme mit float auf ca 1 min Genauigkeit

[Gero D. (srswift)]

Thomas G. schrieb:
> Sonnenauf- und Untergang. Ich komme mit float auf ca 1 min Genauigkeit

Pardon, betriebsblind. Ja, meine Genauigkeit ist auch in dem Bereich. 
1Minute+-. Im Quellcode sieht man ja, ich verwende da auch eher Float 
als Double. Ein wenig könnte man noch rausholen. Aber für meine 
praktische Anwendung ist es ausreichend.

[Gero D. (srswift)]

So hier noch ein paar Bilder vom ultimativ neusten boris. Viel kleiner 
ist er nicht geworden, die Restriktion der 80*100-Leiterplatte erzwingt 
ein wenig unvorteilhafte Proportionen. Der EEPROM kann bis zu 64 
boris-Programme speichern. Neben Sunrise-sunset und ein paar 
Fliegertools sind das vor allem Spiele. Man glaubt gar nicht, was da in 
den 80ern alles für UPN-Taschenrechner programmiert worden ist. 
Dankenswerterweise gibt es davon einige Bücher. Und Spaß macht es 
allemal.

Die Unterlagen zum Nachbau (Leiterplattenfiles, Bascom-Code, 3D-Modelle 
sowie ein paar der genannten Programme ...) gibt es auf Wunsch natürlich 
auch zum Download.

Alles Gute fürs neue Jahr!