Announcement: there is an English version of this forum on Mit einem GA B85M Board, welches noch einen internen LPT1-Port bereitstellt, versuche ich unter WIN-XP und DOSBox 0.74-3 einen ALL07 zu betreiben. Da der ALL07 nur auf uralten, langsamen Rechnern lief, habe ich 'cycles=500' eingestellt. DOS-Programme werden deutlich ausgebremst, aber der ALL07 ist unter keiner LPT-Adresse ansprechbar. Betreibt jemand erfolgreich einen ALL07 unter ähnlichen Bedingungen oder hat diesbezüglich das 'Handtuch geworfen'?
Matthieu Benoit hat eine ganze Seite dem ALL-07 gewidmet: http://matthieu.benoit.free.fr/hilosystem_all-07_universal_programmer.htm Ich habe mal in den 80ern den ALL-03 benutzt, auch am Parallelport: http://matthieu.benoit.free.fr/120.htm oder war es der ALL-01? http://matthieu.benoit.free.fr/hilo_all-01.htm
:
Bearbeitet durch User
Vielen Dank dafür. Mich interessiert zunächst, ob DOSBox gehen würde, da es für mich die einfachste Möglichkeit wäre, ein altes DOS-Notebook nachzubilden. Ein altes HP OmniBook XE3 mit WIN98 war dem All07 (V 9.05) schon zu schnell.
Für WinXP gibt es einen speziellen Treiber, der den direkten Zugriff auf die PC-Hardware ermöglicht. Damit kann man z.B. den LPT-Port 'freischalten'. Such mal nach: winxp giveIO Ich habe auch gelesen, der Zugriff würde dann aus der DOSBox funktionieren. Aber möglicherweise ist das eine modifizierte Version der DOSBox. Den giveIO-Treiber braucht man aber auf jeden Fall!
Beitrag "[Anleitung] DOS-Parallelport-EPROMer unter Windows 8.1 (x64)" Das dort beschriebene gilt auch für neuere Windows-Versionen als 8.1
Danke, die Beschreibung klingt wie 'cracking'. Da werde ich mich mal durch die Links hangeln, ob noch alles verfügbar ist. Versuche hatte ich mit VMware gemacht, wo die 64-Bit Version nicht angenommen wurde. Mit 'giveio.sys' gab es eine Fehlermeldung mit "Service ...". Das aktuelle Mainboard mit W98 zu bespielen, wird wegen unpassender Treiber wohl nicht klappen - daran kann ich mich dunkel erinnern. Schon klar, für ca. 50 Euro kann man sich freikaufen (USB-Prommer). Aber das kann ja jeder ;-)
Mi N. schrieb: > Da werde ich mich mal durch die Links hangeln, ob noch alles verfügbar > ist. Dann berichte mal über Erfolg/Misserfolg.
Kannst du deine DosBox aktualisieren/anpassen? Der Dosbox-X Fork enthält extra einige Optimierungen für Bitbanging auf den LPT-IO-Registern. Im Config-File unter parallel lässt sich der simulierte LPT (mit den alten ISA-Registern) entweder auf eine passendes device (/dev/parport0 unter Linux) oder auf die echte Hardware durchreichen. Das auch mit Offset, z.B. weil der PCI-Parallel-Port auf einem ganz anderem IO-Bereich liegt. [parallel] parallel1=reallpt realbase 1234... (Dosbox braucht am Host natürlich trotzdem Zugriff auf das device/die Ports)
:
Bearbeitet durch User
Harald K. schrieb: > Dann berichte mal über Erfolg/Misserfolg. Voller Erfolg! Was an DOSBox für mich vorteilhaft ist, ich kann drei Laufwerke, die in einem Unterverzeichnis irgendwo als Sicherung versteckt sind, eines alten Rechners C:, D: und E: 'mounten', AUTOEXEC.BAT starten und habe ein Umfeld wie vor ewigen Zeiten. Was ich beispielsweise noch nicht weiter verfolgt habe sind Meldungen 'falsche DOS-Version' an einigen Stellen, 'MODE' liefert nichts und 'touch' von Turbo-C macht auch nichts. ALL07 läuft und das war mir wichtig. Danke an Alle für die Tipps!
Εrnst B. schrieb: > Das auch mit Offset, z.B. weil der PCI-Parallel-Port auf einem ganz > anderem IO-Bereich liegt. Das ist nicht notwendigerweise der Fall. Es gab definitiv zumindest PCI-LPT-Karten, bei denen die Portadressen auf die Standard-IO-Adressen von LPT1..3 gemapped sind (oder zumindest gemapped werden konnten). Allerdings bin ich nicht ganz sicher, ob das auf Hardware-Ebene oder auf Treiber-Ebene passierte. Habe leider auch aktuell keine solche Karte mehr verfügbar, um nachschauen zu können. So weit ich mich erinnere, funktionierte das aber auch, wenn man (nach der Konfiguration der Sache) pures DOS gebootet hat, sollte sich also auf Hardware-Ebene abgespielt haben. Das Hilfsprogramm zu Konfiguration der Karte lief allerdings nur unter Windows. Und natürlich war die Voraussetzung dafür, dass es Erfolg gemeldet hat, die Abwesenheit von ISA- oder OnBoard-LPTs auf den zu belegenden Adressen.
Ich habe einen ALL-11, der hat allerdings einen seriellen port. Der läuft wider Erwarten mit einem billigen HAMA-USB/V.24-Kabel unter VMware 16 entweder unter DOS oder antikem Windows. (vergessen, was genau) Unter modernem Windows verweigert der All-11 die Installation. Ich habe jedenfalls irgendwo eine DOS5-Maschine die unter VMware läuft. Ich habe sie u.a. gebraucht um eine neue Boot-Diskette für meinen SNA-33 Spectrum Analzer zu basteln. "Falsche DOS-Version" bekommt man u.a. wenn command.com oder irgendwelche .sys von einer anderen Version stammen als die, die installiert ist. Gruß, Gerhard
:
Bearbeitet durch User
Gerhard H. schrieb: > Unter modernem Windows verweigert der > All-11 die Installation. Wird daran liegen, daß x86_64 keinen 16-Bit-Code mehr ausführt, und alte Windows-Programme aus der vorderen Altsteinzeit genau so etwas waren. 32-Bit-Windows konnte das noch, und das war bis einschließlich XP der Standard; Windows 10 gab es vor einigen Jahren auch noch in einer 32-Bit-Version, aber das ist jetzt wohl Geschichte. Und damit ist eben auch der 16-Bit-Code tot. Manche frühen 32-Bit-Programme (die also eigentlich auch unter x86_64 laufen sollten, lassen sich nur nicht installieren, weil das Installationsprogramm (gerne sowas wie InstallShield oder Wise ...) selbst noch 16-Bit-Code nutzte. In so einem Fall muss man auf einem 32-Bit-System installieren und jede Änderung an Registry und Dateisystem mitschreiben, dann kann man mit etwas Glück den Installationsvorgang von Hand nachbilden. Spaß macht sowas aber nicht.
Beim 'produktiven Einsatz' zeigen sich jetzt einige Mängel. Vielfach wird bei einem Befehl, der das Löschen oder Programmieren des EPROMs betrifft 'over current!' ausgegeben: AMD29F010 Beim Beenden des Programmes schlägt das 'quit' in die Kommandoebene des DOS fehl, sodaß der Taskmanager bemüht werden muß. Bezüglich des Überstromes könnte der ALL07 im Laufe der Jahrzehnte eine Macke bekommen haben und daß das Programm nicht richtig beendet werden kann, müßte an DOSBox liegen. Die Auswahl von cycles=1000 von vorher 3000 hat keine Veränderung ergeben. Ich werde die gleichen Aktionen noch einmal mit einem alten DOS-Rechner durchführen, um vergleichen zu können.
Harald K. schrieb: > Gerhard H. schrieb: >> Unter modernem Windows verweigert der >> All-11 die Installation. > > Wird daran liegen, daß x86_64 keinen 16-Bit-Code mehr ausführt, und alte > Windows-Programme aus der vorderen Altsteinzeit genau so etwas waren. > 32-Bit-Windows konnte das noch, und das war bis einschließlich XP der > Standard; Windows 10 gab es vor einigen Jahren auch noch in einer > 32-Bit-Version, aber das ist jetzt wohl Geschichte. > > Und damit ist eben auch der 16-Bit-Code tot. > > Manche frühen 32-Bit-Programme (die also eigentlich auch unter x86_64 > laufen sollten, lassen sich nur nicht installieren, weil das > Installationsprogramm (gerne sowas wie InstallShield oder Wise ...) > selbst noch 16-Bit-Code nutzte. > > In so einem Fall muss man auf einem 32-Bit-System installieren und jede > Änderung an Registry und Dateisystem mitschreiben, dann kann man mit > etwas Glück den Installationsvorgang von Hand nachbilden. > > Spaß macht sowas aber nicht. Das 16 Bit Subsystem ist aber auch in den 64 Bit Versionen von Windows vorhanden, es ist bloß deaktiviert. https://github.com/leecher1337/ntvdmx64
Harald K. schrieb: > Änderung an Registry und Dateisystem mitschreiben https://www.nirsoft.net/windows_registry_tools.html https://www.nirsoft.net/utils/reg_file_from_application.html
Marc X. schrieb: > Das 16 Bit Subsystem ist aber auch in den 64 Bit Versionen von Windows > vorhanden, es ist bloß deaktiviert. Danke für Hinweis & Link. Schade allerdings: > Please be aware that starting with Windows 11 22H2, > support for 16bit Windows applications (i.e. Windows 3.11 > applications) is no longer possible due to removal of > crucial functions (UserRegisterWowHandlers) from USER32.DLL > and the whole Win16 support relies on this. Andererseits: Wenn man gewillt ist, einen fürchterlichen Tod zu sterben, kann man ja auch einfach Windows 10 verwenden ... jedenfalls für den Rechner, auf dem man das 16-Bit-Windows-Programm verwenden will.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.