Ich wage zu behaupten dass Grafikspeicher in 32-bit Compilern zugreifen immernoch einfacher ist als EMS und XMS zu jonglieren in 16-bit Compilern. Mit 32-bit Compilern spart man sich die Mühe, überhaupt EMS oder XMS zu benötigen 
Beiträge von mceric
-
-
Da kann ich dir überhaupt nicht zustimmen. Letztendlich bleibt C immer C. Weder DJGPP noch Watcom machen total verrückte Sachen. Gewöhnungsbedürftig ist wie gesagt der Zugriff auf den Grafikspeicher, aber das copy pastest du dir halt einmal von einer vorhandenen Lösung und gut. Welche Alptraum-Details assoziierst du mit den beiden Compilern, bzw. was gefällt dir an deinem bisherigen Compiler (oder mehreren?) besser?
-
Ich möchte mehr Texturen nutzen können, wie der Speicher momentan hergibt.Alles anzeigen
Mit XMS / EMS kann man maximal gleichzeitig auf 64kb zugreifen wenn ich das richtig verstanden habe?!
Ich schätze das ich ca. 4MB für Texturen gleichzeitig laden können muss.
Womit könnte man am schnellsten auf relativ viel Speicher zugreifen.
Wie schnell kann man bei EMS/XMS zwischen den Speicherbereichen wechseln und wie schnell ist das abrufen von 1024bit Blöcken?
Verhält sich das ähnlich wie beim restlichen Speicher oder ist das viel langsamer.
Hat da wer Praxiserfahrung oder gute quellen für Infos?
Also 4 MB ist eindeutig mehr als bisher
Die einfachste Methode wäre, einen 32-bit Compiler zu verwenden, zum Beispiel DJGPP oder OpenWatcom (OW kann sowohl 16 als auch 32). Damit sind alle Texturen immer direkt zugänglich.Wenn du XMS verwendest, kannst du dir bequem einzelne Texturen irgendwohin kopieren lassen. Zum Beispiel könntest du einen Speicherbereich (also wie bisher diese Felder oder Arrays mit jeweils maximal 64 kB, wegen besserer Performance) nehmen, in dem du dann kreuz und quer aus verschiedenen XMS Bereichen schnell alle Texturen für den aktuellen Level zusammen kopieren kannst wenn der Level anfängt.
Bei EMS kopierst du nicht, sondern lässt Blöcke von fester Grösse (EMS 3: 16 kB, EMS 4: 4 kB) an einem festen Ort (EMS 3: Eines von vier Vierteln deines 64 kB Page Frame, EMS 4: Beliebige Vielfache von 4 kB im ersten 1 MB RAM) "auftauchen". Das kann sinnvoll sein, wenn du nicht vorher weisst, welche Texturen du wann brauchst: Du lässt dann jeweils den passenden Bereich "auftauchen", ohne ihn erst kopieren lassen zu müssen.
Der Zwang, immer mit Vielfachen von 4 oder 16 kB zu arbeiten, macht es in der Praxis teilweise ziemlich umständlich. Insbesondere kannst du nicht nach Herzenslust 50 Texturen aus 50 verschiedenen Orten in einen 50 kB Speicherbereich deines Spiels zusammenkopieren lassen wie bei XMS, sondern bist immer daran gebunden, wie die Texturen sich auf die vorgegebenen z.B. 16 kB Blöcke verteilen können, von denen du dann z.B. nur maximal vier (!) gleichzeitig sichtbar machen kannst.
Wie gesagt, ich würde einen protected mode 32-bit Compiler nehmen. Dann braucht das Spiel mindestens 386. Zweite Wahl wäre XMS, erfordert 286 oder neuer, und EMS würde ich eher vermeiden. EMS hast du ab 386 oder wenn du eine EMS-Hardware (nur EMS 3) hast sogar schon ab 8086, aber dein Spiel würde auf 8086 sowieso sehr langsam laufen.
Bei 32-bit Compiler können ganz einfach deine Felder, Matritzen, Arrays etc. so gross sein wie RAM im Computer vorhanden ist. Also sofortige Lösung sämtlicher Speicherplatzprobleme und keinerlei Umstand mit EMS, XMS, Nachladen von Daten von der Platte und so weiter
Allerdings musst du etwas umdenken, was den Zugriff auf Bereiche mit fester Adresse betrifft, in deinem Fall der VGA Grafikspeicher. Muss man aber nur einmal verstehen und kann dann geniessen -
Alles anzeigen
Wenn ich 32-pin Flash im Netz suche, wird 27C512 erwähnt. Das wäre ein 64 kilobyte EPROM, nur mit UV löschbar. Wenn man von dort weitersucht, sagt das Netz AT28C512 wäre ein vergleichbares wiederbeschreibbares EEPROM, z.B. https://www.onsemi.com/pdf/datasheet/cat28c513-d.pdf
27C512 in DIP Bauform ist aber 28pin Bausteine.
Wenn man 27C512-kompatible DIP EEPROM haben will -> Windbond W27EE512 mit 28 polige DIP Gehause.Oder meinst du PLCC Gehause-Version ? PLCC Version ist auch nicht miteinander austauschbar.
ST 27C512 ... CAT28F512/513Also das Teil im von mir verlinkten Datenblatt ist 32-pin DIL, wie das Teil im Foto. Allerdings sind 64 kB auch nur für einen bestimmten Zeitraum typisch, irgendwann später hatten BIOS Chips dann sehr viel mehr Kapazität und was man in den letzten 64k des ersten 1MB Speicher sehen konnte, war nur ein Ausschnitt daraus. Aufkleber abmachen war halt schade um den Aufkleber
H.EXE hat die Frage ja schon weitgehend beantwortet und sogar das Datenblatt für den aktuellen 128 kB Chip verlinkt. Das Schreibmuster für Schreibfreigabe laut Seite 6 vom Datenblatt ist, in DEBUG, wenn der Chip auf F000:0 liegt. Könnte auch E000:0 sein, weil 128 kB? Dann entsprechend ändern.
Code
Alles anzeigenrds f000 eds:5555 aa eds:2aaa 55 eds:5555 80 eds:5555 aa eds:2aaa 55 eds:5555 20 qOb das tatsächlich so funktioniert, weiss ich nicht. Vielleicht muss man die Sequenz auch über ein Flash-Tool senden.
Auf Seite 7 ist auch eine magische Sequenz, mit der sich der komplette Chip innerhalb von 50 ms löscht. Sowas wäre damals gefundenes Fressen für Viren gewesen, in der Praxis gab es das aber sehr selten. Trotzdem ärgert es mich, dass Hersteller zu geizig für Schreibschutz-Jumper sind. Auch für Festplatten-Passwörter wäre sowas sicher nicht verkehrt.
-
Wenn ich 32-pin Flash im Netz suche, wird 27C512 erwähnt. Das wäre ein 64 kilobyte EPROM, nur mit UV löschbar. Wenn man von dort weitersucht, sagt das Netz AT28C512 wäre ein vergleichbares wiederbeschreibbares EEPROM, z.B. https://www.onsemi.com/pdf/datasheet/cat28c513-d.pdf
-
Kann man eigentlich bei Win98 die "swappiness" wie bei Linux regulieren? Also Windows dazu bringen, zögerlich mit Swap umzugehen? Das würde die Speicherkarte schonen und durch die niedrigen IOPS vieler Speicherkarten wäre Swap auf Karte sonst wohl auch eine ziemliche Spassbremse. Gleichzeitig wäre Windows weniger eingeschränkt als wenn man Swap ganz weglässt.
-
Danke. Berücksichtige ich bei der nächsten Revision. Ich habe absichtlich die Versorgung komplett auf die untere Seite gebracht. Die Frequenzen sind da nicht so hoch, dass man PCB extrem Schirmen muss. Gutes Kabel ist viel wichtiger. Ich bin kein Freund von Overengineering, wie man sieht
Gerne. Erinnere mich daran, mal eine 4-lagige overengineered SMD Version zu basteln
-
PS: Ich kann gerne die Layout-Ideen mit einer Beispieldatei illustrieren, aber ich habe KiCad 5 und die Datei auf github benötigt KiCad 18 :-o
Ohne die 5 GB 3d Modelle hat es für KiCad 7 gereicht, damit konnte ich es bearbeiten
Hier ein Vorschlag für die Platine:In dieser Version sind keine Leiterbahnen mehr auf der Rückseite und die Platine ist ein wenig mit Masse-Vias bestreut um die Abschirmung zu verbessern
-
PS: Ich kann gerne die Layout-Ideen mit einer Beispieldatei illustrieren, aber ich habe KiCad 5 und die Datei auf github benötigt KiCad 18 :-o
-
Stromversorgung über Eingänge hatte ich schon wegen der 75 Ohm Eingangsimpedanz laut matt wieder durchgestrichen.
Das mit den Schaltern nehme ich dann auch mal zurück, hatte für "Farbe oder MDA" auch schon eine automatische Erkennung vermutet
Ideen zum Layout: Wenn man R1 verschiebt / dreht, könnte man 1 der wenigen Leiterbahnen, die noch die Unterseite brauchen, nach oben legen.
Von D1 zum +5V Header geht auch obenrum.
Die Leiterbahn vom USB zum GAL könnte oben laufen, wenn J2 zwischen Widerstände und GAL verschoben wird. Wäre dann zwar näher an den Widerständen, aber dafür wäre die Massefläche unten komplett lückenlos.
-
Ich habe an diesem Projekt vor einiger Zeit Mal wieder herum gespielt und möchte gerne die Verbesserungen mit der Welt teilen. Nun kann es den EGA Mode automatisch erkennen, Monochrom bekam Amber Mode dazu und ich habe die Farbgebung etwas verbessert.
Externer Inhalt youtu.beInhalte von externen Seiten werden ohne Ihre Zustimmung nicht automatisch geladen und angezeigt.Durch die Aktivierung der externen Inhalte erklären Sie sich damit einverstanden, dass personenbezogene Daten an Drittplattformen übermittelt werden. Mehr Informationen dazu haben wir in unserer Datenschutzerklärung zur Verfügung gestellt.Praktische Automatik-Erweiterungen sind das!
Jetzt wo nur noch drei Stellungen für die beiden übrigen Schalter existieren, könnte man EINEN Schalter mit 3 Stellungen nehmen: Pull down, pull high und offen, wenn sich eine Möglichkeit ergibt, das mit der Logik entsprechend als White, Amber, Green auszuwerten Welche Stellung dabei welche Farbe ist, wäre nicht so wichtig. Vielleicht passt sogar ein stabiler und ergonomischer on-off-on Kippschalter statt fummeligem DIP?Zusätzlicher Gedanke: Welche Impedanz haben eigentlich VGA-Monitore? Wenn die Ausgänge nicht stark belastet werden, könnte man den ganzen Adapter von den MDA, CGA oder EGA Signalen versorgen? Wobei programmierbare Logik wahrscheinlich nicht sehr stromsparend ist, aber wer weiss? -
Zu Machbarkeitsstudie fällt mir ein: 1. Die ganzen Legacy Sachen bzw. Multi I/O Chip waren eine Weile gerne über LPC (?) Bus angebunden und 2. Ein Retro-Bastler hat halbwegs erfolgreich einen ISA-Slot für eine Soundkarte an einen geeigneten seriellen Bus am TPM-Header gehängt, mit entsprechender Hardware dazwischen, ohne zusätzliche Treiber zu brauchen. 3. War es nicht unüblich, BIOS-Erweiterungen über ISA oder PCI anzuhängen. Allerdings könnte der Chipsatz das BIOS im BIOS Chip erwarten und für den Speicherbereich gleich gar nicht auf ISA oder PCI gucken?
-
Gibt bei vielen Boards auch die Möglichkeit mit einer der USB-Ports das BIOS zu flashen, und das ohne CPU. Wie das gehen soll, ist mir zwar selbst schleierhaft, aber wenn man danach googlet, findet man dazu Artikel und/oder Beiträge. Vielleicht hilft das, um es wieder flott zu kriegen. Bei Gigabyte z.B. nennt sich das Q-Flash.
Es gibt BIOS Versionen mit einem Menü für Backup und Restore auf USB FAT16 und ggf. FAT32 Laufwerke und/oder auf Disketten. Teilweise mit Hotkey davor. Und teilweise ging sowas auch noch, wenn das eigentliche BIOS nicht mehr ging, oder hat automatisch nur noch Restore gemacht, wenn es gemerkt hat, dass das BIOS ansonsten kaputt war. Da musste man dann wohl blind nach dem Boot längere Zeit warten, bis das Restore fertig war. Oder vielleicht beim Boot einen Hotkey gedrückt halten? Wahrscheinlich war auch der Dateiname vom BIOS Image auf dem USB Laufwerk wichtig, ohne passende Doku also wenig nützlich?
-
Alles anzeigen
Jap Alladin läuft nur bis 32MB oder weniger RAM.
Primitiv aber effektiv, nicht nur dafür:
EATXMS will do just that--eat up a
specified amount of XMS memory, which can be useful for games that won't
run on machines with more than 16 MB of RAM.Damit könnt ihr auch mal testen, ob weniger RAM irgendeinen Unterschied bei euch unter DOS macht.
Beim in FreeDOS verwendeten HIMEM gibt es eine /X2MAX32 Option, damit weniger als 32 MB XMS 2 gemeldet werden. Manche Spiele betrachten die Anzahl Kilobytes als vorzeichenbehafteten 16-bit Wert und kommen nicht mit 32 MB oder mehr klar.
Bei JEMMEX (ein "EMM386 und HIMEM in einem" Treiber) gibt es eine X2MAX=n Option, dort kann man frei wählen, wieviel kB XMS 2 man gemeldet haben will.
Ich glaube es gab auch Software, die ein Problem damit hatte, auf welcher Seite des Endes der ersten 16 MB Adressraum Speicherbereiche waren, oder die Grenze nicht kreuzen konnten?
-
Apropos SoftICE, https://github.com/sudleyplace/386SWAT ist übrigens inzwischen open source
-
So eine Art RAM VU-Meter als Aussteuerungsanzeige für den Speicher?
-
Kann man da irgendwie die Kohlen wechseln? :-o
-
mceric Wie wird das umgesetzt? Auf moderner Hardware nehme ich jetzt mal an?
Es verwendet PAE, damit kann man z.B. ab Athlon64 oder PentiumPro 32-bit Prozessen 32-bit Speicherbereiche innerhalb von mehr als 4 GB insgesamt vorhandenem Speicher geben. Und es erweitert die XMS Schnittstelle. Die angedachte FAT32 RAMDISK könnte mehrere Bereiche von je 4 GB reservieren, um insgesamt mehr als 4 GB Kapazität zu erreichen.
Physical Address Extension – Wikipedia
Experimente mit 64-bit DOS Extendern finden in der entsprechenden "Szene" auch schon statt. Soweit ich mich erinnere, ist aber die Umschalterei zwischen 16-bit BIOS und 64-bit Anwendungen viel umständlicher und langsamer und man kann nicht beide Funktionen gleichzeitig aktiv halten?
Bei 32-bit Prozessoren ab 386 ging das ja mit Protected Mode sehr elegant, man konnte die alten 16-bit Sachen in einen VM86 Task stecken, der sich fast wie eine Umgebung ohne Protected Mode verhält und trotzdem in anderen Tasks 32-bit Dinge tun. Nur Aktionen, die die Illusion stören würden oder zu viel direkten Einfluss auf die Hardware haben, sind in VM86 Tasks entweder ganz blockiert oder können auf Wunsch der Protected Mode Verwaltungssoftware blockiert werden.
Was blockiert ist, kann dann je nach Geschmack teilweise wieder durch Simulationen ersetzt werden. Auch EMM386 und Windows 3, insbesondere im 386enh Modus (und WfW 3.11, wenn man es nicht in seiner Variante des Safe Mode laufen lässt?) ist eine Protected Mode Verwaltungssoftware. Darum müssen EMM386 und DOS auch extra Anstrengungen unternehmen, um Windows-kompatibel zu sein. Es schnappt sich dann den EMM386 Zustand und ersetzt EMM386 on the fly durch von Windows selbst implementierten Ersatz und verkapselt DOS so, dass man mehrere DOS Fenster gleichzeitig offen haben kann. Alles etwas obskur und darum auch damals teilweise vor Gericht wegen schlechter Doku und ungenügender Kooperation für Kompatibilität mit konkurrierenden EMM386 und DOS Marken.
-
Nachdem tatsächlich wer RAMDISK > 4 GB mit XMS 3.51 interessant findet, hier noch der Link
GitHub - Baron-von-Riedesel/HimemSX: eXtended Memory Manager (XMM) that can manage memory beyond the 4 GB barrier, up to 1 terabyte.eXtended Memory Manager (XMM) that can manage memory beyond the 4 GB barrier, up to 1 terabyte. - GitHub - Baron-von-Riedesel/HimemSX: eXtended Memory Manager…github.comDer Treiber bietet eine API Erweiterung für über 4 GB XMS mit PSE-36 neuerer Generation bis 40 Bit Adressen und 1 TB RAM. Man kann es wohl auch mit JEMM386 als EMM386 benutzen.
Zum Testen ist ein RDISK Patch für die RAMDISK inkl. gepatcheder Version dabei.
Und ein Patch für SMARTDRV von Win98, die irgendwie auch über ein extra MOVZX bei Funktion ...9 einen DOS/16M und DOS/4G Crash vermeidet wenn Adressen über 16 MB sind?
Eine angepasste SHSURDRV RAMDISK ist auch dabei.
Soweit ich das verstehe, haben die Beispiele trotzdem noch das Limit von 4 GB pro Treiber, ein Ticket über eine geplante FAT32 RAMDISK scheint etwas halbfertig liegengeblieben zu sein?
HIMEMSX support for FAT32 RAMdrive · Issue #2 · Baron-von-Riedesel/HimemSX@_Japheth Further to a personal message I sent you recently, and which you replied (relevant quote from you below):- Well, the XMS block move function in…github.com -
Falsch, du warst der King wenn dein swapfile in ner Ramdisk lag!
Das erinnert mich jetzt daran dass Windows 3.x (mit oder ohne for Workgroups) einen Überlauf bekommen hat wenn du über einer gewissen Menge RAM hattest, weil es per Default einen Faktor davon im Adressraum für Swap vorgesehen hat. Nur den Swap kleiner konfigurieren reichte nicht, man musste den Faktor kleiner stellen. Bei Win9x wäre das wohl ein typischer Fall für Regedit gewesen, bei Win3 waren es noch INI Dateien.
Tatsächlich haben einige DOS-Zauberer inzwischen mit selbstgebauten Speichertreibern für > 32 bit Adressraum für "super extended XMS" oder so als proof of concept eine RAMDISK gebastelt, die mehr als 4 GB sein kann
