MS-DOS Speicheroptimierung auf dem Monotech NuXT Turbo PC

Veröffentlicht am von
Antworten

Vor gut zwei Jahren hatte ich meinen Monotech NuXT Turbo PC vorgestellt. Ein Design für einen Turbo XT aus dem Jahr 2019 nach aktueller ATX-Spezifikation mit wahlweise Intel 8088 oder NEC V20 CPU, Intel 8087 FPU, eingebauten XT-IDE Controller, und und und! Ausgestattet ist es aber auch mit 832 KiB RAM aufgeteilt auf zwei ICs in DIP-Gehäuse.

englischdeutsch
UMAUpper Memory Areaoberer Speicherbereich
HMAHigh Memory Areahoher Speicherbereich
Vollständige Nutzung des konventionellen Speichers

In der Zeit bis jetzt hatte ich den PC unter MS-DOS ausschließlich mit den 640 KiB konventionellen Speicher genutzt, was bedeutete, dass das gesamte DOS-Betriebssystem, sowie alle aktiven Treiber nur diesen verwendeten und im Zweifel für Anwendungsprogramme, beziehungsweise für Spiele nicht mehr ausreichend RAM zur Verfügung steht. Jetzt habe ich mich aber mal hingesetzt und den noch zur Verfügung stehenden, sogenannten Upper Memory Area (kurz UMA, deutsch: ‚oberen Speicherbereich‘) aktiviert, konfiguriert, sowie versucht zu optimieren, damit mehr konventioneller Speicher für Programme und Spiele zur Verfügung steht. Schließlich hat Monotech Vintage PCs auf der mit MS-DOS vorinstallierten, sowie mitgelieferten CompactFlash-Karte auch gleich die passenden Treiber und Tools wie USE!UMB und DOSMAX beigefügt.
Abzüglich der 640 KiB konventionellen Speicher stehen mir also von den physischen 832 KiB grundsätzlich noch 192 KiB Upper Memory Area zur Verfügung. Dieser ist wiederum in sechs 32 KiB große Upper Memory Blocks (UMB) aufgeteilt. Über den auf dem NuXT Mainboard aufgelöteten 6-fach Dip-Switch lassen sich die einzelnen Blöcke stufenweise aktivieren. Allerdings muss ich hier beachten, dass es Erweiterungskarten für den ISA-Bus gibt, die auch den oberen Speicherbereich nutzen. Das wären neben Speichererweiterungskarten, Netzwerkkarten mit oder ohne Boot ROM, Karten mit eigenen Option ROMs wie HDD-/FDD-Controller auch EGA und VGA Grafikkarten wie die auch bei Monotech Vintage PCs mitgelieferte ‚Onboard PC/104 VGA Card‘. Das heißt, dass ich den ersten 32 KiB Block UMB nicht aktivieren kann, da es sonst zu einem Konflikt kommt und ich keine Grafikausgabe bekomme. So bleiben mir also effektiv nur fünf Blöcke mit zusammen 160 KiB als oberen Speicherbereich. Wirklich mehr als genug um die ersten 640 KiB konventionellen Speicher zu entlasten.
Dank der kurzen Anleitung im ‚NuXT Turbo PC‘ Handbuch, den originalen Dateiversionen der autoexec.bat und config.ays, sowie etwas Selbstoptimierung habe ich den verfügbaren Speicher für ausführbare Programme nun von 548 auf 625 KiB erhöht. Dies habe ich erreicht, in dem ich erst einmal überhaupt mit dem USE!UMBS.SYS Treiber den oberen Speicherbereich für MS-DOS zur Verfügung gestellt habe. In diesen wurden dann bereits einige Teile vom MS-DOS Betriebssystem, der Teriber für den USB2ISA Adapter und der Maus SYS-Treiber verschoben.

Systemteile und Treiber wurden in hohen und oberen Speicherbereich verlagert

Neben dem oberen Speicherbereich (UMA) kann in der config.sys auch noch der hohe Speicherbereich (HMA = High Memory Area) aktiviert werden. Das Programm DOSMAX sorgt dafür, dass weitere Teile des MS-DOS Betriebssystems nun in den zusätzlich zur Verfügung stehenden hohen Speicherbereich geladen werden. DOSMAX selber wurde natürlich zuvor in den oberen Speicherbereich geladen. Für den hohen Speicherbereich wird anscheinend aber wieder ein Teil des oberen Speicherbereichs genutzt. Zumindest werden mir mit dem Programm mem.exe wieder nur 123 KiB gesamt UMA angezeigt, der HMA wird leider nicht aufgezeigt.
Bei immer noch so viel zur Verfügung stehenden oberen Speicher habe ich mir auch mal das MS-DOS eigene Programm doskey.exe gegönnt und in die Startkonfiguration hinzugefügt. doskey.exe ist ein kleines Programm, welches eine Commandline-History für die aktuelle DOS-Sitzung seit Systemstart bietet.

Seit Aktivierung der Upper Memory Area zeigt das DOS-Programm mem.exe als insgesamt zur Verfügung stehenden Speicher nun 1024 KiB an. Dies stimmt insofern, als DOS mit dem entsprechenden aktivierten Speicherbereich die Menge auch verwalten und nutzen kann, allerdings kommuniziert DOS – zumindest beim NuXT – nicht mit dem BIOS, sodass der Wert nicht mit dem physisch zur Verfügung stehenden Speicher korrespondiert. Es geht stattdessen nur davon aus, dass 1024 KiB RAM zur Verfügung steht. Sieht man sich das Board Layout des NuXTs unter Verwendung des Handbuchs an, so scheint der physisch zur Verfügung stehende Arbeitsspeicher aus zwei 512 KiB D-RAM Speicherbausteine zu bestehen. – Was in Summe 1024 KiB sind. Da aber über die DIP-Schalter nur bis zu sechs UMBs à 32 KiB zusätzlich zu dem konventionellen Speicher zugeschaltet werden können, können praktisch auch nur maximal 832 KiB Gesamspeicher genutzt werden. Das ist MS-DOS hier nicht in der Lage exakt zu prüfen. Außerdem werden laut dem NuXT Handbuch noch Teile des UMAs für den Video-RAM (MDA, CGA, EGA oder VGA), für das XT-IDE Universal BIOS, sowie für das System BIOS genutzt. Der Power On Self Test zählt unabhängig davon trotzdem nach wie vor nur den gesamten konventionellen Speicher von 640 KiB hoch. Der zusätzlich konfigurierte hohe, sowie obere Speicherbereich – sprich die gesamten 832 KiB – sieht das BIOS anscheinend gar nicht.

Aufschlüsselung, welche Programme im konventionellen, sowie oberen Speicherbereich liegen.

Links:

Lagacy Workarounds für Dateisysteme unter macOS

Veröffentlicht am von
Antworten

Software entwickelt sich mit der Zeit weiter und oft werden auch Komponenten, Funktionen oder auch alte Kompatibilitäten entfernt. So unterstützt Apples Festplattendienstprogramm (englisch: Disk Utility) seit einigen Jahren nicht mehr das im Jahr 1980 eingeführte Dateisystem FAT12, sowie das 1984 eingeführte Dateisystem FAT16. Für mich als Retro-Computer-User, der mit Wechseldatenträger wie 3,5″ Disketten und USB-Sticks über entsprechende Seriel-Controller unter (MS-) DOS Systemen hantiert sehr ärgerlich. Obwohl das grafische Festplattendienstprogramm und auch das entsprechende Kommandozeilenprogramm diskutil einem suggeriert, dass es mit der Option FAT (MS-DOS), beziehungsweise mit dem Parameter MS-DOS FAT16 ein Medium zu formatieren, ist es am Ende doch das modernere FAT32. Ganz zu schweigen von FAT12 für Disketten. Einziger Wermutstropfen ist, dass im derzeitig aktuellen macOS immer noch das alte Kommandozeilenprogramm newfs_msdos enthalten ist. Und so müssen der Formatierungsprozess auf zwei Programmbefehle inzwischen aufgeteilt werden.

Als Beispiel sei ein USB-Stick genommen, auf dem die FAT16 Partition erstellt werden soll. Mit dem Befehl diskutil list wurde herausgefunden, dass es sich um das physische Geräte /dev/disk2 handelt. Zuvor wurde mit diskutil list die physische Datenträgernummer ermittelt.

sommteck@MacBook-Pro ~ % diskutil list
/dev/disk0 (internal, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *500.3 GB   disk0
   1:                        EFI EFI                     314.6 MB   disk0s1
   2:                 Apple_APFS Container disk1         500.0 GB   disk0s2

/dev/disk1 (synthesized):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      APFS Container Scheme -                      +500.0 GB   disk1
                                 Physical Store disk0s2
   1:                APFS Volume Macintosh HD - Data     154.9 GB   disk1s1
   2:                APFS Volume Macintosh HD            11.2 GB    disk1s2
   3:              APFS Snapshot com.apple.os.update-... 11.2 GB    disk1s2s1
   4:                APFS Volume Preboot                 2.4 GB     disk1s3
   5:                APFS Volume Recovery                1.3 GB     disk1s4
   6:                APFS Volume VM                      1.1 GB     disk1s5

/dev/disk2 (external, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:     FDisk_partition_scheme                        *4.1 GB     disk2
   1:                 DOS_FAT_32 USB-DRIVE               4.1 GB     disk2s1

Mit diskutil muss trotzdem erst einmal Partitionsschema erstellt werden.:

sommteck@MacBook-Pro ~ % diskutil partitionDisk /dev/disk2 1 MBR MS-DOS FAT16-USB 1G

Mit newfs_mnsdos wird dann die Partition formatiert.:

sommteck@MacBook-Pro ~ % sudo newfs_msdos -F 16 -v "FAT16-USB" -c 32 /dev/disk2s1

Am Ende ist bei einer Cluster-Größe von 32 Sektoren eine etwa 1 Gigabyte große FAT16 entstanden. Der Parameter für die Cluster-Größe ist prinzipiell optional, aber muss ein realistischer Wert angegeben werden, wie physische Speicherkapazität des Mediums größer als die maximal unterstützte Größe des zu verwendeten Dateisystems ist. Mit dem Befehl diskutil /dev/disk2s1 info lässt sich das Ergebnis noch überprüfen.

Ein anderes Problem, welches ich mit einem USB-Stick neulich hatte, war, dass das darauf enthaltene Dateisystem FAT32 scheinbar korrupt war und macOS sich weigerte das Medium einzubinden. Der Trick ist, den Mount-Prozess unter macOS manuell durchzuführen. Im Verzeichnis /Volumes werden in macOS alle interne Datenträger, sowie die Wechseldatenträger eingebunden. Der problematische USB-Stick bekam also erst sein eigenes Unterverzeichnis und mit dem alten Unix-Programm mount_msdos wurde es händisch eingebunden. – Auch wurde zuvor mit diskutil list die physische Datenträgernummer ermittelt.

sommteck@MacBook-Pro ~ % mkdir /Volumes/Testvolume
sommteck@MacBook-Pro ~ % sudo mount_msdos /dev/disk2s1 /Volumes/Testvolume

Danach konnten die Dateien von dem inkonsistenten USB-Stick herunter kopiert und anschließend das Medium erst einmal neu formatiert werden.

Links:

Team QuickSnap – erste Ergebnisse

Veröffentlicht am von
Antworten

Im Frühling 2017 hatte ich ja das Projekt ‚Team QuickSnap‘ ins Leben gerufen und die 2er-Packung mit Einweg-Kamera QuickSnap von Fujifilm gekauft. Hintergrund war das Erstellen von Schnappschüssen im Alltag, den belichteten Film lange nach dem empfohlenem Datum entwickeln zu lassen, um dann zu sehen, welche Farben entstehen, weil sich die Chemie des alternden Films verändert. In meinem Blogbeitrag von Mai 2017 hatte ich bereits über diese Intention geschrieben.

Im vergangenen Juni war nun die erste Einwegkamera der 2er-Packung voll geknipst und ich habe den Film dieser neulich über ein professionelles Fotolabor entwickeln, sowie auch Abzüge erstellen lassen.
Mit dem Ergebnis bin ich jetzt allerdings nicht zufrieden, weil die Bilder und deren Farben von den Abzügen nicht so unerwartet anders ausgefallen sind als erhofft.
Von den auf der Kamera versprochenen 27 Bildern wurden nur 21 tatsächlich entwickelt und auch Abzüge erstellt. Hat hier das beauftragte Fotolabor etwa bereits eine Vorauswahl erstellt, und die Bilder, die so schlecht oder erst gar nicht belichtet wurden, bereits in der weiteren Bearbeitung weggelassen? Die Körnigkeit der Bilder im 35 Millimeter Kleinbildformat ist deutlich zu sehen. Auf einigen Abzügen sind auch Lichtschäden erkennbar. Dennoch sind die Farben im Wesentlichen noch im realistischen Bereich, sodass die Motive auf den Abzügen immer noch natürlich wirken.
Eine bekannte Person von mir meinte, nachdem ich ihr meine Intension mit der analogen Kleinbildfotografie geschildert habe, dass ein belichteter Film vor dem Entwickeln deutlich mehr als zehn Jahre nach dem Ablaufen des Verfallsdatums erst liegen muss, bis sich auch an den Farben durch die veränderte Chemie etwas sichtbar verändert. Das erste Foto auf der ersten QuickSnap entstand vor acht Jahren direkt nach dem Kauf der Einwegkamera, wenige Wochen oder Monate vor Ablauf des Mindesthaltbarkeitsdatums.
Die zweite QuickSnap werde ich wohl am besten, nachdem das letzte Bild belichtet wurde, nach Ablauf des Haltbarkeitsdatums wenigstens zwölf bis fünfzehn Jahre – besser noch länger – vor dem Entwickeln liegen lassen.

Womit ich mich aber mit den Ergebnissen der ersten QuickSnap deutlich schwergetan habe, ist die Frage, mit welchen Einstellungen ich die Abzüge wieder digitalisiere? Mein Flachbettscanner bietet nativ eine maximale Auflösung von 600 x 600 dpi, sowie 1200 x 1200 dpi interpoliert. Bei den Abzügen im Kleinbildformat mit sichtbarer Körnung wären die 600 x 600 dpi mehr als ausreichend gewesen, aber ich war dann der Meinumg: Viel hilft viel! So waren dann auch mit jedem gescannten Abzug eine circa 60 Megabyte großes TIFF entstanden, weil ich kann mir ja dann erst einmal in aller Ruhe überlegen, in welche finale Auflösung, sowie Pixeldichte ich die Scans für das Archiv herunterskaliere. Und so lagen dann auch die unkomprimierten TIFF-Dateien ein dreiviertel Jahr auf meinem Computer. Schließlich hatte ich mir diese Woche dann doch den Ruck gegeben, weil im CCC-Ffm das Thema Analogfotografie aufkam, die Bilder auf etwas Erträgliches herunterzuskalieren. Da man glaube ich, bei der Körnung sowieso nicht in ein Bild so weit hineinzoomen möchte und ich persönlich nicht sehr auf große Monitore stehe, gebe ich mich nun mit einer Auflösung im Full-HD Bereich bei 300 dpi zufrieden. Die JPEGs haben nun eine Größe zwischen 600 Kilobyte und einem Megabyte. Sollten diese für genauere Betrachtungen zu grob-pixelig sein, können die Abzüge ja auch erneut eingescannt werden.

Links:

Internationaler Tag des offenen Hackspace am 29. März

Veröffentlicht am von
Antworten

Am Samstag, dem 29. März 2025 – also Übermorgen – findet wieder der Internationale Tag des Hackerspaces statt. Nachdem der Chaos Computer Club Frankfurt e.V. wegen des Auszugs aus den alten Vereinsräumen in der Häuser Gasse an der Teilnahme aussetzen musste, ladet er in diesem Jahr wieder dazu ein, in der Zeit zwischen 13:37 und 20:42 Uhr im neuen Hackquarter vorbei und den Hackern über die Schulter zu schauen.

Auf dem Programm stehen unter anderen:

  • ein Löt-Workshop
  • das Erlernen wie ein 3D-Drucker funktioniert
  • Vorstellung und Workshop des OpenBikeSensors für Fahrräder unter Beteiligung des ADFCs Frankfurt/Main & Bad Nauheim/Friedberg
  • ein Linux Showcase zum Installieren, Ausprobieren, sowie Herumspielen der freien Betriebssystemalternative
  • Das beim CCC-FFM allseits beliebte Mzltiplayer-Spiel NewtonWars, rund um Planeten und Gravitation

Ich werde mit der Vorstellung meines persönlichen Hardware-Projekts, der Restauration und Weiterinbetriebnahme eines IBM PC XTs aus den frühen 1980er Jahren, wieder vertreten sein. Ein Oldtimer die ständige Pflege und Reparaturen benötigt.

Weitere Informationen zu der lokalen Veranstaltung des CCC-FFMs gibt es im Blog zum Verein.

Weitere Informationen zu weiteren teilnehmenden Hackerspaces gibt es unter https://wiki.hackerspaces.org/International_Open_Hackerspace_Day_2025

Links:

Eröffnung HQ4

Veröffentlicht am von
Antworten

Nachdem das alte Hackquarter (HQ3) in Bockenheim zu klein geworden ist, war es nach fast einem Jahr Suche und Ausbau so weit. Der Chaos Computer Club Frankfurt e.V. (kurz: CCC-FFM) hat am Donnerstag, den 13. März ab 15:00 Uhr mit einer feierlichen Eröffnung seine Türen für die Öffentlichkeit geöffnet.

Die neuen Räumlichkeiten in der ‚Neuen Teefabrik‘ befinden in zentraler Lage zwischen Frankfurter Hauptbahnhof und Skyline Plaza und bieten deutlich mehr Platz für Projekte, Vorträge, sowie den Besuchenden. Neben den Offenen Abenden soll es aber auch wieder vermehrt Vorträge, Workshops sowie Kooperationen mit anderen Vereinen und mehr geben.

Neben der offiziellen Eröffnungsveranstaltung, bei der auch Pressevertreter eingeladen waren, fand vergangenen Samstagabend noch die dazugehörige Einweihungsparty für die überregionale CCC-Community statt.

Adresse und Zugang

Hohenstaufenstraße 8
60327 Frankfurt am Main

Der Eingang befindet sich im Hinterhof auf der linken Seite bei der überdachten Treppe.

Link zur Adresse auf OpenStreetMap

Links: