HIVE-Project

Dieser neue Teil des Forums beschäftigt sich mit dem Colour Maximite 2, einem neuen Retro-Style Computer.

Details und Spezifikation:

• https://geoffg.net/CMM2_Description.html
  - 32-bit ARM Cortex-M7 at 400MHz or 480MHz with 2MB of flash. 1MB on-chip RAM plus 8MB off-chip RAM for BASIC

Projekt-Website:

• https://geoffg.net/maximite.html
  - Projekt Website des Entwicklers

• http://mmbasic.com/
  - Projekt Website des MMBASIC

Hilfe und Dokumentation

• https://www.c-com.com.au/mmhelp/
  - Wiki / Online-Handbuch

• http://www.thebackshed.com/forum/Microcontrollers
  - englischsprachiges Forum mit großem Unterbereich für den CMM2

Bezugsquellen:

• https://sklep.pslabs.pl/Maximite-c91/s_lang/en
  - Deluxe Version mit WLAN, USB-Mausport und einigen Erweiterungen
  - Versand aus Polen, schnell, professionell und unkompliziert

• https://micromite.org/
  - Originalversion vom Entwickler
  - Versand aus England/UK, mehrer Wochen Wartezeit

Bilder:

Ist MMBASIC noch immer so schräg lizensiert, daß Du dessen Quelltext zwar bekommen kannst, aber nur alleine im Klo eingeschlossen lesen darfst?
...oder so ähnlich...

Was heißt schräge Lizenz? Ist halt sein Werk, er lässt dich reinschauen und du darfst es für deine Zwecke verändern, aber nur er will es vertreiben bzw. anbieten können. Gewährleistet zumindest keinen Wildwuchs und du kannst dich drauf verlassen, dass nicht nach und nach viele Versionen mit kleinen Inkompatibilitäten auftauchen. Das wäre für ein Betriebssystem bzw. die Plattform an sich der Supergau, weil du dich nicht mehr drauf verlassen könntest, dass dein Programm auch auf jedem Maximite läuft. Finde ich jetzt nicht so verwerflich.

MMBasic is written in standard ANSI C and the source is available to individuals and organisations subject to licensing terms.
The source code to MMBasic is Copyright 2011 - 2020 Geoff Graham and in some cases also Copyright 2016 - 2020 Peter Mather. It may be used for an individual's personal use under the following terms:

• The files may not be distributed or made available to others without specific written permission.

• Object files (ie, .o, .exe, .hex files) generated using one or more of the source files (modified or not) are for personal use only and may not be distributed without written permission.

• The files are provided without any warranty; without even the implied warranty of merchantability or fitness for a particular purpose.

Wenn ich den MMBASIC-Sourcecode zuhause rumliegen hätte, müsste ich den also vor Dritten schützen. Ganz closed Source und nur das API veröffentlichen, damit andere nachladbare Module produzieren können, oder ganz offen fänd ich viel gradliniger und pflegeleichter. Das fühlt sich für mich an wie ein halbes Bit und ich meine hier nicht das Bier! Sowas wie NDAs passen für mich einfach nicht in die Hobbywelt. Und ich werd doch wohl noch das Recht haben, diese seltsame Zwischenstufe zwischen diesen beiden mir gradlinig erscheinenden Zuständen als schräg zu empfinden!

Nur mal so dahingeworfen. Ich hab mir den Sourcecode der Maxi- und Mikromite Varianten mal geben lasse, da ich gerade mit einem Mikromite Plus experimentiere, hab auch Entwicklungs IDE und Compiler installiert (bei Microchip sind ältere Versionen verfügbar, die auch funktionieren sollen) aber sauber compiliert bekommt man den Code nicht, es gibt ständig Fehlerausgaben zu falschen Konversionen und andere Meldungen. Wollte den Code der Plus-oder Standardvariante für eigene Zwecke anpassen und vielleicht sogar neue Funktionen einbauen aber denkste.
Nun bin ich aber auch kein C Nerd und übersehe vielleicht etwas elementares. Aus meinem Verständnis sollte eine beigefügte Projektdatei ein lauffähiges Compilat erstellen,dem ist aber nicht so. Also sollte man die freizügige Bereitstellung der Sourcen nicht überbewerten.
Ich bleibe aber dran und versuche mein bestes.

! https://micromite.org und https://pslabs.pl sind down !

Ich hab mir selbst zum Geburtstag einen Color Maximite II (Generation 2 Version 2) gegönnt.
https://www.rictech.nz/products/31/COLOUR-MAXIMITE-2 zum Shop sind es ca 18,000 Km Luft linie
(Mit online Tracking konnte ich verfolgen, dass das Teil mit 6 Flugzeugen pünktlich zum Geburtstag sein Ziel erreicht hat.)




Die komplette Firmware (inkl. HAL Treiber für USB, SDCARD, VGA, RAM, SOUND etc.) und das MMBasic selbst
ließ sich nur mit einer älteren ARM Tool Chain und FW Version mit STMCubeIDE erfolgreich kompilieren.

Aktuelle Toolchain und FW findet viele Fehler z.B. doppelt deklarierte Variablen in *.h und *.c Files.
Natürlich sollte man Speicher für struct's/var's nur in *.c Files belegen und kann dann in mehreren *.h Files mit "EXTERN" auf diesen
extern belegten Speicher verweisen.

Aber selbst wenn ich alle 400 Übeltäter die der Linker meldet gefunden und behoben hatte, macht die Firmware für die SD Card einen Fehler.
Load "myprog.bas" liest den Quellcode aber umbricht die einzelnen Zeilen nicht was dann in ein "line to long" Fehler enden muss.

Habe aber keine weitere Zeit in die Fehlersuche investiert
da das mit alten Tools erstellte FLASH Image problemlos auf dem tollen CMM2 läuft.

NO RISC NO FUN:
Natürlich ist ein eigenes OS ganz ohne MMBasic für diese schöne feine Maschine in der Mache !
Wen man für jedes Bit selbst verantwortlich ist (no HAL drivers pure ARM Assembler) dann ist das
Studium vom Schaltplan und sämtlicher Datenblätter der verbauten Komponenten keine Kür, sondern Pflicht.

Im Prinzip fängt man mit einer langen Sprungtabelle an die am Anfang nur auf Dummy Interrupt und Error Händler zeigt.
Nur der Reset Händler (POWER ON Vektor) wird mit der Adresse der eigen main(){} belegt und das Abenteuer kann beginnen.

Will man auf sein eigenen OS ohne zusätzlich PC programmieren benötigt man als Minimum einen DIY ARM Assembler
der auch das Instructionset TUMB I/II versteht und in Bytes umsetzt.
Ein echtes Einsteigerproblem stell der Speicher da. Normalerweise kümmert sich der Linker einer ARM Toolchain darum
das die verschiedenen Code/Data Section's genau an den Adressen landen, wo sie hingehören.

Die Cortex-7 Achitektur trennt Code und Daten von einander aber ein FLASH Loader lädt zunächst das erstellte Image
in das Flasch RAM die eigene main( ) muss dann vom Flash den/die R/W Bereiche selbst in den SRAM bereich verschieben.
Das wird aber nichts wenn man vergisst z.B. auch den Stackbereich im R/W RAM einzurichten.

Man muss es mögen sonnst ist es eine Qual (am Anfang).
Bin vorzeitig in Rente und habe Zeit für so einen Blödsinn im Alter

Happy coding

Joshy

Nachtrag:
Warum ich überhaupt auf dem Color Maximite II (gen. 2) gestoßen bin.

Ich saß an meinem 40 Jahre altem C64 (mit den original Kondensatoren)
und hatte via CAN Bus das Märklin MFX Protokoll bei seiner Arbeit beobachtet.

Dann habe ich mir aktuelle STM32 Mikrocontroller auf diversen China Börsen angeschaut
und ausgerechnet was mich alle Bauteile/Gehäuse/Platine in kleiner Stückzahl kosten würde
und da ich meinen alten aber treuen Augen den SMD Kram beim Löten nicht mehr antun möchte,
muss die eigene Platine auch vom PCB Hersteller noch bestückt werden.

Da die Mindeststückzahl 5 ist und nur ein grober Fehler im Layout reicht, um eine Menge Elektromüll zu produzieren
habe ich nach meinem Favoriten den STM32H743IIT6 mit 480MHz und 176 Pinnen (Unmenge an GPIOs) gegoogelt.

Da war schnell klar für den Preis ein komplettes "funktionierendes" Gerät ist unschlagbar.
So adoptierte ich einen New Zealand'er.
Und sie lebten glücklich bis ans Ende ihrer Tage (bla bla bla)

PS. Das Teil hängt mit einem 3€ VGA Adapter an meinem großem HDMI Monitor und alle 16 Video Modis von MMBasic funktionieren perfekt inklusive aller 16:9 Auflösungen einschließlich 1920 x 1080 x 24 Bit.

Man kann auch sagen das die 3$ China VGA HDMI Adapter alle Modis mit (60/75Hz) ordentlich als HDMI signal umsetzen
und ein eingeschleiftes Audio Stereo Signal mit 48KHz und 16Bit Sampeln ins HDMI Signal kodieren.

Hier mal mein Adapter von eBay: https://www.ebay.de/itm/155892436378

Ich hatte wirklich damit gerechgnet das so ein "billig" Wandler maximal die Standard Auflösungen "versteht"
aber selbst die ganzen merkwürdigen Retro Modis von MMBasic sind kein Problem.

Sind ja einige auf Youtube die Ihre Retro DIY 8-Bit Komputer 650x/680x/Z80 etc. mit VGA ausstatten
und so kann man selbst auf dem Breadboard erzeugtes VGA auf dem heimischen HDMI Screen "günstig" anschauen.

Hi Joshy,

ja, der Maximite ist ein richtig schönes Stück Hardware, hat mir viel Spaß gemacht. Aber nach einer Weile hats mich sehr gestört, dass man nur das MMbasic hat und es gar keinen Weg gibt andere Compiler zu benutzen. Gerade wenn du eine App mit GUI schreiben möchtest, dann ist das MMBasic trotz seinem genialen Speed etwas zu träge und das Ganze fühlt sich laggy an.
Ein alternatives OS wäre super, aber da bin ich raus, da fehlen mir einfach alle nötigen Grundlagen.

Aber ich bin gespannt auf das was es noch zu sehen gibt.
Viel Erfolg!

digger hat geschrieben: ↑Di 5. Nov 2024, 09:45 ja, der Maximite ist ein richtig schönes Stück Hardware, hat mir viel Spaß gemacht. Aber nach einer Weile hats mich sehr gestört, dass man nur das MMbasic hat und es gar keinen Weg gibt andere Compiler zu benutzen.

Ich hab 'n paar Duinomites (entspricht etwa den ersten Maximites) hier und damals konnte ich anderes dafür mit GCC (für PIC32) basteln, aber das hat sich damals auf RetroBSD kompilieren und installieren beschränkt.

MMBASIC, egal für welche *-Mites, ist auch durch irgendwelche Kompiler gegangen, es muß sie also geben.

Sicherlich geht es, aber ob ich es könnte steht auf einem anderen Blatt. Diese MMBasic Umgebung nach dem Start finde ich schon gut, aber dann müsste das MMbasic um die Funktion erweitert werden auch kompilierte Binärdatein zu laden und zu starten. Die Quellen kann man wohl noch vom Entwickler beziehen, aber wie dann weiter? Ich habe nie was mit systemnaher Programmierung in C zu tun gehabt ... naja, alles macht man irgendwann zum ersten mal, aber ich befürchte dass Arbeit, Familie und Garten heftige Gegner für so ein Unterfangen sind.