EASY MINT in ROM flashen?

[SHO2017]

Hallo,

vielleicht einige naive Fragen:

1, Ist es eigentlich möglich ein MINT (evtl. mit Terra Desktop) in ein ROM zu flashen um es im Falcon verwenden zu können?
2. Wenn ja, gehen auch unterschiedliche ROM`s via "Umschalter?"  -> Größenbegrenzung
3. Macht das ganze Sinn (monetär und aufwandstechnisch)? Oder ist es besser mit z.B. xboot zu arbeiten.
4. Was würde man dafür benötigen bzw. gibt es dazu vielleicht eine Anleitung?

[yalsi]

Hallo

Da sehe ich schwarz. EasyMINT ist UNIX und das ist ein Datenträger-orientiertes Dateisystem und kein Firmware.

Den MINT Kernel könnte man vielleicht noch in ein ROM kriegen (wenn das von der Größe her passt usw.), dann wird's aber schwierig. Der Kernel sucht seinen init-Prozess im Root-Filesystem und nicht im ROM und alle nachfolgenden Programme auch. Das würde also nur klappen, wenn das ROM als Filesystem zu mounten wäre. Und dann geht's schnell nicht weiter, weil einige Verzeichnisse im Root-Filesystem beschreibbar sein müssen und eben nicht "read only".

Rein prinzipiell könnte "man"  EasyMINT so umstricken, das es als Firmware läuft- aber wer würde sich so einen Berg Arbeit aufhalsen wollen. Und wieso?

Gruß- Georg B. aus N.

[SHO2017]

Ja, danke!


Hab ich mir fast gedacht. Hatte heute auf Ebay einen ST2 gesehen, der MagiC im Rom hatte.


Daher die Nachfrage...

[SolderGirl]

Ich könnte mir vorstellen, das es in Kombination mit der PAK/2 einen Geschwindigkeitsvorteil bringen könnte, wenn man einen (evtl. angepassten) Kernel direkt ins ROM packt. Weil der 68020 dann mit 32 bit darauf zugreifen könnte.
Und man würde auch etwas RAM und Bootzeit sparen, weil der Kernel nicht erst ins RAM geladen werden müsste. Der Rest müsste natürlich trotzdem von Platte kommen.

[gh-baden]

Hallo

Da sehe ich schwarz. EasyMINT ist UNIX und das ist ein Datenträger-orientiertes Dateisystem und kein Firmware.

Den MINT Kernel könnte man vielleicht noch in ein ROM kriegen (wenn das von der Größe her passt usw.), dann wird's aber schwierig. Der Kernel sucht seinen init-Prozess im Root-Filesystem und nicht im ROM und alle nachfolgenden Programme auch. Das würde also nur klappen, wenn das ROM als Filesystem zu mounten wäre. Und dann geht's schnell nicht weiter, weil einige Verzeichnisse im Root-Filesystem beschreibbar sein müssen und eben nicht "read only".

Rein prinzipiell könnte "man"  EasyMINT so umstricken, das es als Firmware läuft- aber wer würde sich so einen Berg Arbeit aufhalsen wollen. Und wieso?

Ich sach nur: wo anders geht das durchaus, mit ROMfs.

https://www.bigmessowires.com/68-katy/

[1ST1]

Oder man schaue sich Risc-OS auf dem Acorn Archimedes an. Komplettes grafisches (kooperatives) multitasking fähige Betriebssystem mit grafischer Shell, Textshell und (rasend schnellem) Basic-Interpreter (mit Inline-Assembler) im ROM, inklusive ein paar Grundprogramme (Editor, Pixelgrafik- und Vektorgrafik-Editor und noch ein bischem mehr in einem ROM-Dateisystem. Wenn man eine Systemdiskette beim EInschalten einlegt, oder eine Festplatte entsprechend vorbereitet, werden weitere Systembestandteile von dort nachgeladen. Aber im Grunde kann man den Archi ohne Disk booten und hat schon ein paar Anwendungen und das BASIC parat.

Übrigens beherrscht Risc-OS "Dokumentenorientiertheit", ein Feature was ich mir schon immer gewünscht habe: Jede installierte Anwendung meldet ans OS. welche Dateitypen es bearbeiten kann, und wenn man so eine Datei anklickt, fragt Risc-OS, mit welcher der dafür angemeldeten Anwendungen man das öffnen will. Das geht zwar in TOS und Windows auch, aber nur nach Datei-Endung, bei Risc-OS ist das ein unsichtbares Dateiattribut, und unter Risc-OS können sich für jede Dateiart beliebig viele Anwendungen gleichzeitig registrieren, nicht nur eine. Erst unter Windows 10 gibts auch einen Dialog nach Anklicken einer Datei, der fragt, mit welcher (Metro-)App die Datei geöffnet werden soll, wenn mehrere damit umgehen können. Das konnte der Archi schon 1989.

(Momentan warte ich noch auf ein funktionierendes DIskettenlaufwerk für meinen A410, um dann auch mal die Platte einrichten zu können. Aber mit dem A3000 Tastaturcomputer kann ich jetzt schon ein bischen rumspielen.)

[gh-baden]

Übrigens beherrscht Risc-OS "Dokumentenorientiertheit", ein Feature was ich mir schon immer gewünscht habe: Jede installierte Anwendung meldet ans OS. welche Dateitypen es bearbeiten kann, und wenn man so eine Datei anklickt, fragt Risc-OS, mit welcher der dafür angemeldeten Anwendungen man das öffnen will. Das geht zwar in TOS und Windows auch, aber nur nach Datei-Endung, bei Risc-OS ist das ein unsichtbares Dateiattribut, und unter Risc-OS können sich für jede Dateiart beliebig viele Anwendungen gleichzeitig registrieren, nicht nur eine. […] Das konnte der Archi schon 1989.

Und der Mac seit 1984. Bis etwa 2006.

[1ST1]

Ok, mit dem Mac kenne ich mich nicht aus, schön, dass er das erfunden hat.

[ari.tao]

Und mittels xMENUE kriegt man das ganz ähnlich auch auf dem Atari hin.

[mfro]

Ein ROM-Dateisystem ist aber ja nun was anderes, als wenn ein Programm im ROM läuft.

Der PAK brächte das ROM-Dateisystem z.B. nix (weil der Code nur vom ROM geladen, aber im RAM ausgeführt wird).

[1ST1]

Stell dir aber mal vor, beim Falcon oder TT wäre ein Programm im ROM-Dateisystem, mit dem man das NVRAM setzen kann, oder mit dem man die Festplatte einrichten könnte, oder schonmal ein XControl mit den wesentlich wichtigsten CPX-Modulen... Beim Archimedes ist genau das der Fall.

[ari.tao]

Alles, was in´s ROM gepackt wird, bedeutet eine Beschleunigung des alltäglichen Bootings - aber eine Behinderung & Verzögerung, wenn ein Update fällig wird. Folglich sollten fertige, ausgereifte, vollendete Prge. & OS-Teile in´s ROM, jedoch offene Baustellen besser nicht.
Aktuelles MiNT ist immer noch eine Baustelle: Die eingangs dieses Threads gestellten Fragen sollten daher imho verneint werden. Aber könnte vielleicht eine ´reife Zwischenstufe´ von MiNT, etwa der Kernal von 1.15.9, in´s ROM gepackt werden? Er müßte wohl, ähnlich wie die AES (aber vor diesen), nach Abarbeitung des AUTO\ initialisiert werden.
Für häufig gebrauchte Apps. wie Editor, Basic, Accs, &c. war doch mal der ROMport gedacht?

[mfro]

Es hat zwar kein Mensch nach dem Archimedes gefragt, aber ich stell' mir das trotzdem mal vor. Dann stell' ich mir gleich noch vor, daß es doch toll wäre, wenn ich das ROM-Dateisystem noch - je nachdem, was ich gerade mit dem Rechner machen will - auch noch tauschen könnte, damit immer die passenden Utilities parat sind (abgesehen davon, daß Software meist Fehler hat und ich vielleicht ein Upgrade dranstecken will).

Genau deshalb hat Atari am ST den ROM-Port hingebaut. Trotzdem hat keiner entsprechende Module gebaut (bzw. die wenigen, die's gab, wurden nicht gekauft).

Warum? Weil's Geld kostete.

Wie im Archimedes übrigens auch. Der kleinste hat - soweit ich weiß - 2 MB ROM und damit genau das gegenteilige Problem wie Atari: die Acorn-Jungs wußten, daß ihr RISC-OS mit der ersten ARM-Generation ziemlich viel Platz braucht und haben beim Rechnerdesign deshalb reichlich Reserve gelassen (und sich wahrscheinlich anschließend erst überlegt, was man da wohl noch reintun könnte). Bei Atari war's genau andersrum.

[simonsunnyboy]

RISC OS 3 ist schon so gut, daß man eher kein Upgrade mehr braucht Eine so durchdachte und zügige Systemzusammensetzung habe ich nie wieder erlebt, allenfalls mit meinem Chromebook hier (das aber viele Eigenschaften wiederum auch nicht hat)

Mint aus einer ROM Disk heraus fände ich übrigens eine gute Idee. Ich tausche nicht im Tagestakt auf meinem Falcon die Software aus. Da kann das OS und seine zentralen Komponenten gerne von einer ROMDisk kommen und nicht austauschbar sein, wenn ich dafür Zeit und Mühe spare, die Installation und Wartung machen.

Am Atari liefen Programme früher immer ohne Konfiguration direkt von ihrer Diskette. Es ist mir schleihaft, warum das von Festplatte nicht mehr gehen soll. Und Mint arbeitet da IMHo lieder auch in die schlechtere Richtung.

[gh-baden]

BTW: Bei Big Mess o’ Wires gibt es Tausch-ROM-SIMMs für 68k Macs (vom 68000 bis 68040) zu kaufen, mit dem man nicht nur das ursprüngliche (ggfs. gepatchte) ROM reinbekommt, sondern noch so ~7 MB Platz hat für eine ROM-Disk, von der man booten kann. Darin dann ein installiertes System, mit Netzwerk"treibern", und ein paar kleinen Tools (Packer, Editor …):

http://www.bigmessowires.com/mac-rom-inator-ii/

Den passenden ROM-Beschreiber gibt’s da auch …

[ari.tao]

Wenn Du , Sunny, auf mint.CNF abzielst: Das möchte ich lieber nicht durch eine PatchArea im Prg. ersetzt sehen, denn ich habe davon sehr viele verschiedene Exemplare. Aber das könnte ja wie bisher neben anderen Konf.-Dateien (wie zB. assign.SYS, newdesk.INF, gem.CNF ...) liegen.
Wäre es also möglich, einen MiNT-Kern in eine Cartridge für den RomPort zu packen - und hätte das Vorteile ggü. einem MiNT im AUTO\ ? Falls es aus der Cartridge dann doch in´s RAM geladen werden muß, dann doch wohl eher nicht. Dito für eine ROM-Disk.

[simonsunnyboy]

Konfigurationsfiles liegen natürlich immernoch auf irgendeiner Platte, die der Nutzer individuell konfigurieren kann. Statt C:\MINT hat man halt ein R:\MINT im ROM, von dem man Kerneltreiber und Programme laden kann (nicht muss), Nachladen von Platte soll nicht ausgehebtl werden, aber halt nur dann wenn man es wirklich braucht.

funktioniert wie schon obig angesprochen unter RISC OS problemlos.