Mit "20MB Floppy Format" sind wahrscheinlich die Flopticals gemeint. Sieht aus wie eine 3,5" Diskette, passt aber 20MB drauf. Bei den Indys von SGI waren manchmal entsprechende Laufwerke eingebaut. Ein funktionierendes Medium habe ich nie gesehen.
Falls Du so was wie das LS-120 bzw. LS-240 von Panasonic/Matsushita meinst - das ist das 32MB Format.
20MB ist irgendwie ein Zwischenformat zwischen 2.88MB und den besagten 32MB, wo ich für mein LS-240 auch ein Formatierprogramm habe.
Auf https://www.heise.de/news/Wind…oeffentlicht-4912561.html steht angeblich, aber wenn man beim Googlen etwas geschickter ist, sieht man, dass das nicht nur angeblich geschehen ist.
So konnte ich es auch letztendlich finden, interessant ist z.B. das "Drivers" Unterverzeichnis, dort unter dem weiteren Unterverzeichnis Storage findet man bspw. auch den sfloppy-Treiber.
Das ist ganz interessant, weil dort auch eine Liste der unterstützten Floppy-Disk Formate als Kommentar in der Quelldatei steht.
Die meisten der Formate sind natürlich bekannt, mir aber weniger bspw. ein "20MB Floppy Format":
Drive360Media160, // 5.25" 360k drive; 160k media
Drive360Media180, // 5.25" 360k drive; 180k media
Drive360Media320, // 5.25" 360k drive; 320k media
Drive360Media32X, // 5.25" 360k drive; 320k 1k secs
Drive360Media360, // 5.25" 360k drive; 360k media
Drive720Media720, // 3.5" 720k drive; 720k media
Drive120Media160, // 5.25" 1.2Mb drive; 160k media
Drive120Media180, // 5.25" 1.2Mb drive; 180k media
Drive120Media320, // 5.25" 1.2Mb drive; 320k media
Drive120Media32X, // 5.25" 1.2Mb drive; 320k 1k secs
Drive120Media360, // 5.25" 1.2Mb drive; 360k media
Drive120Media120, // 5.25" 1.2Mb drive; 1.2Mb media
Drive144Media720, // 3.5" 1.44Mb drive; 720k media
Drive144Media144, // 3.5" 1.44Mb drive; 1.44Mb media
Drive288Media720, // 3.5" 2.88Mb drive; 720k media
Drive288Media144, // 3.5" 2.88Mb drive; 1.44Mb media
Drive288Media288, // 3.5" 2.88Mb drive; 2.88Mb media
Drive2080Media720, // 3.5" 20.8Mb drive; 720k media
Drive2080Media144, // 3.5" 20.8Mb drive; 1.44Mb media
Drive2080Media2080, // 3.5" 20.8Mb drive; 20.8Mb media
Drive32MMedia32M, // 3.5" 32Mb drive; 32MB media
Drive120MMedia720, // 3.5" 120Mb drive; 720k media
Drive120MMedia144, // 3.5" 120Mb drive; 1.44Mb media
Drive120MMedia120M, // 3.5" 120Mb drive; 120Mb media
Drive240MMedia144M, // 3.5" 240Mb drive; 1.44Mb media
Drive240MMedia120M, // 3.5" 240Mb drive; 120Mb media
Drive240MMedia240M // 3.5" 240Mb drive; 240Mb media
Desweiteren findet man dann im gleichen Quellcode auch bspw. die Drive Media Constants, die Teil des Bootsektors sind.
Na ja, zum recompilieren von Windows XP reichen meine Kenntnisse jetzt wirklich nicht, aber die allermeisten Systemdateien kenne ich da schon namentlich, das hilft auch beim Suchen im Quelltext...
Nochmal kurz dazu eine Frage.... tritt der Fehler nur in dem "multicomp" Image auf, oder auch in den viel kleineren z80pack "Standard IBM" floppy disk images ?
Wenn nur in dem "multicomp" Image, in allen 4 Laufwerken (also A bis D), oder nur in B bis D, und A ist immer ok (dann könnte ich mir schon denken was das Problem ist) ?
Danke Rene für das Download-Angebot und die Arbeit. Mir ist allerdings nicht klar, wieso es noch "Sektorfehler" geben kann.
Wie packst Du da in die Disk-Image-Dateien einzelne CP/M-Dateien rein .... mit cpmtools ?
Was würde er mit einem modernen Rechner und modernem OS verwenden, oder was würde er verwenden, wenn er das mit einem 486er und MS-DOS machen würde ?
Mit BIOS ist nicht das Rechner BIOS im Eprom gemeint, sondern das DOS-Basis-I/O System (wird bei IBM-DOS bspw. in der IBMBIO.SYS abgelegt), ist also Teil von DOS. Die Anpassungen halten sich in engen Grenzen, so ein Kit gab es in ähnlicher Form auch für MS-DOS vor Version 3.
wo ist eigentlich eine gute download Quelle für DR-DOS?
Muss mal meine Disketten durchgehen, aber ich glaube ich hab keins mehr.
Dachte mir das ich auch mal eine CF mit DR-DOS fertig mache, für alle Rechner ohne Windows.
Die "winworldpc" "OS library" ist sicherlich die beste Adresse dafür.
Nur mal zur Info... es gab solche High Density Floppy-Controller für ISA 8-Bit Bus auch schon vor Sergey's ISA Floppy Disk and Serial Controller.
(Und nein, den will ich behalten, ist unverkäuflich)
Es gibt auch eine BASIC Version 5.29 (statt der auf der Seite im Link abgebildeten 5.21). Das ist ein toller Hinweis (die Seite mit dem Patch), wenn ich die ungepatchte 5.21 mit der gepatchten Version 5.21 vergleiche, und die so gefundenen originalen Bytes in der 5.29 suche, wird auch die 5.29 höchstwahrscheinlich patchbar sein. Das Problem mit dem "inkompatiblen" Backspace gibt es nämlich häufiger.
Verstehe aber die Frage zur angepassten Version nicht ganz, Fullscreen-Edit mit der alten CP/M MBASIC Version hatte ich nie gesehen/gefunden.
In dem Manual von BASIC-80 (CP/M Version = MBASIC) findet man da auch keinen Hinweis auf eine Terminalanpassung.
Toast_r Hinweis war eigentlich schon von Anfang an zielführend. Die DBLSPACE.* Dateien auf dem Wurzelverzeichnis sind versteckte Systemdateien und werden bspw. von Norton ohne "Nachhilfe" nicht angezeigt.
Die DBLSPACE Dateien stören, wenn sie vorhanden sind lädt MS-DOS die auch ohne CONFIG.SYS usw.
Ich bin jetzt nicht von geteilten Lizenzen ausgegangen. Allerdings ist Softmaker Office für 35 Euro und auch für mehrere Benutzer nutzbar bestimmt günstiger.
Leider hat Office 365 (aka Microsoft 365) andere Nachteile... Ich finde ein Abo-Zwang (1 Jahr und dann immer verlängern) zwar kaufmännisch sehr geschickt und das erhöht sicherlich den Gewinn bei Microsoft, aber ich bevorzuge einmalige Zahlung und dann "unbegrenzte" Nutzung, mal vom in die Cloud speichern ganz abgesehen.
Daher bin ich schon längere Zeit auf Softmaker Office 2018 (und jetzt 2021) umgestiegen... tut's auch und kostet nur ein Bruchteil von Microsoft's Software (nur als Student/Schüler kostet die einen angemessenen Preis).
Danke für die Blumen 
Ich muss mich aber schämen, im Programm ist tatsächlich noch ein (weiterer) Rechtschreibfehler gewesen.
Da stand "rectancle" als Programmausgabe, aber es sollte eigentlich "rectangle" lauten.
Für die Rechtschreibfanatiker habe ich das ZIP also nochmal verändert, Downloadmöglichkeit siehe mein neuester Blog-Eintrag.
Wer da abholen kann - suche auch noch ein FD55FV (80 Spur QD/DD, nix HD) .... wäre toll wenn das klappen würde.
Gibt doch heute schon Nachbauten vom 64er, und das ändert an den Sammlerpreisen exakt gar nix.
Btw. kennt jemand eine preiswerte (<119 Euro inkl. Versand) Quelle vom C64 Maxi ?
1ST1 - ich habe nach einem weiteren, weit verbreiteten Terminal-Typ gesucht (und gefunden). Ich habe jetzt auch das Hazeltine Esprit Terminal zur TESTTERM.COD hinzugefügt, d.h. es sind jetzt 6 (statt vorher 5) Terminals mitgeliefert.
Ich musste allerdings dazu auch das Programm abändern, damit auch die Cursor-Koordinaten Y und X vertauscht werden können, also X und Y (in der Reihenfolge) gesendet werden kann. Das README.TXT ist entsprechend auch abgeändert worden, und eine Versionsnummer 1.01 hinzugefügt.
P.S.: Eben (um 22:44 Uhr) nochmal die TESTTERM.COD im ZIP verändert. War ein Tippfehler noch drin.
Hmmm.... CP/M 3.0 würde das wohl schaffen, CP/M 2.2 ... keine Ahnung - Du bräuchtest ein Programm, was bspw. die Druckerausgabe in eine Datei umleitet, und dann könntest Du mit "Ctrl-P" einfach alles auf den Drucker ausgeben. Oder schau Dir mal Microshell (für CP/M 2.2) an, da gab es auch Dateiumleitung. Habe ich aber nie benutzt...
Also so in der Binary Datei reinzuschauen ist schwierig.
Ausführen kann ich komischerweise die Datei auch nicht (zumindest nicht mit 22NICE).
Hast Du auf dem Olivetti ETV System den STAT Befehl verfügbar ?
Könntest ja theoretisch die Bildschirmausgabe mal auf eine serielle Schnittstelle leiten (e.g. STAT CON:=TTY: (oder umgekehrt)), und auf der anderen Seite per Nullmodem ein PC mit Terminalprogramm laufen lassen. Und ggfls. dann als Mitschnitt/Capture in eine Datei sogar speichern. Damit könnte man sich dann nur die Bildschirmausgaben anschauen, und damit auch die Control-Sequenzen.
Pech hat man nur, wenn die Ausgabe direkt in den Bildschirmspeicher erfolgt, also ohne Control-Sequenzen. Denke aber das gab's noch nicht bei CP/M Maschinen.
Habe mein Terminal Testprogramm (welches ein bisschen Kopfzerbrechen wg. Hitech-C gemacht hatte) fertig.
Ich habe in der README.TXT beschrieben, wie die Konfigurationsdatei dazu (vordefinierte Terminals schon mitgeliefert) aussieht und welche Grenzen das Programm hat.
Ich werde das Programm auch noch bzgl. Invers-Darstellung erweitern, bin mir aber nicht sicher ob das jedes Terminal kann.
Gedacht ist es dazu, bei (seltenen) Rechnern/Systemen die Terminal-Emulation zu testen, um bspw. herausfinden zu können, welcher Terminaltyp für Wordstar o.ä. genutzt werden muss.
Ich habe für VT100, VT52, TV920/950, ADM-3x und WYSE-50/60 die Definitionen nach bestem Wissen angefertigt, aber man weiss ja nie ob sich nicht doch noch ein Fehler drin befindet.
Ich würde mich freuen, bei eventuellen Fehlern / Fehlfunktion aber auch wenn's mal geholfen hat, ein Feedback zu bekommen.
Nein, Monitore würde ich auch ungern verschicken, kommt halt oft Bruch heraus.
Sehe gerade, Du hast - ganz Apple-untypisch - auch einen TA Dario 386 im Regal stehen
Über dieses Thema schweigt sich das User Manual aus. Wie gesagt, habe halt den Hi-Tech C bisher für CP/M genutzt. Kann auch mal einen anderen CP/M C-Compiler nutzen, aber die sind alle nicht ANSI-C kompatibel. Ich entwickle gerade ein Terminal-Testprogramm für CP/M, welches die Terminal ESC-Sequenzen aus einer Konfigurationsdatei (Text, editierbar) in ein mehrdimensionales Feld einliest. Um möglichst modular die Quelldatei zu entwerfen, war halt die Ausgabe der ESC-Sequenzen in einer Funktion angedacht.
Bitte nicht mehr antworten, Danke für die Bereitschaft zu antworten.
Ich nutze keinen GCC. Ich habe von Anfang an geschrieben, dass ich einen bestimmten Compiler unter CP/M nutze.
Da ihr scheinbar selbst das Ganze nicht ausprobiert habt, sind da leider alle Antworten nur Mutmaßungen.
Eine Übergabe mit array[][2][2] erzeugt natürlich auch einen Fehler.
Ich glaube ich nutze meinen Workaround. Wird wohl am Compiler liegen, der ist einfach schon zu alt.
Die Fehlermeldung bei Angabe der eckigen Klammern in der Funktionsparameterübergabe lautet:
"Expression too complicated"
Wir reden von einem alten C-Compiler für CP/M...
Die Adresse (auf den Anfang des Felds) wird korrekt übergeben, habe das mit einem anderen Testprogramm extra nachgeprüft.
Mit typedef kommen noch mehr Fehlermeldungen.
Mit ***feld verliere ich die Möglichkeit, das als Array mit Indices in der Funktion zu benutzen.
Ich möchte nicht einen einzigen Feldinhalt in die Funktion übergeben, sondern das gesamte Array.
Ich habe folgenden Workaround erarbeitet, aber ich möchte eigentlich nur feld[index1][index2][index3] in der Funktion benutzen:
#include "stdio.h"
void funktion(char *pointer,int m,int n,int o) {
int index1,index2,index3;
for (index1=0;index1<m;index1++) {
for (index2=0;index2<n;index2++) {
for (index3=0;index3<o;index3++) {
printf("array[%d][%d][%d] = %d\n", index1, index2, index3,
*(pointer+index1*n*o+index2*o+index3) );
}
}
}
}
int main() {
char feld[2][2][3]; /* 2*2*3= 12 array fields in total */
feld[0][0][0]=1;
feld[0][0][1]=2;
feld[0][0][2]=3;
feld[0][1][0]=4;
feld[0][1][1]=5;
feld[0][1][2]=6;
feld[1][0][0]=7;
feld[1][0][1]=8;
feld[1][0][2]=9;
feld[1][1][0]=10;
feld[1][1][1]=11;
feld[1][1][2]=12;
funktion(feld,2,2,3);
return 0;
}
Damit werden alle Werte korrekt ausgegeben. Sieht aber nicht gerade elegant aus.
P.S.: Einrückungen gehen hier bei der Forensoftware immer flöten, sorry.
P.S. : Wenn ich das statt in Hi-Tech C in Turbo C mache, und das wie folgt abändere, geht es in Turbo C:
01:#include "stdio.h"
02:
03:void funktion(char array[2][2][2], int nummer) {
04: printf("array[%d][0][0] = %d\n", nummer, array[nummer][0][0]);
05:}
06:
07:int main() {
08: char feld[2][2][2];
09:
10: feld[1][0][0]=32;
11:
12: funktion(feld,1);
13:
14: return 0;
15:}
Das geht aber so leider nicht in Hi-Tech C.
Habe ein Problem mit Hi-Tech C (3.09), aber vielleicht ist das gar nicht Hi-Tech spezifisch.
Ich habe eine Funktion und ein Hauptprogramm in einer C-Quelldatei (ich lasse mal unwichtiges weg und zeige nur den "Rumpf"):
01:#include "stdio.h"
02:
03:void funktion(char array[][][], int nummer) {
04: printf("array[%d][0][0] = %d\n", nummer, array[nummer][0][0]);
05:}
06:
07:int main() {
08: char feld[2][2][2];
09:
10: feld[1][0][0]=32;
11:
12: funktion(feld,1);
13:
14: return 0;
15:}
Der Compiler mag Zeile 4 und Zeile 12 nicht.
Wie definiere ich die Funktion ab Zeile 3, so dass ich in der Funktion selbst wieder auf das Array mit einem Index zugreifen kann ?
Arrays sind erstmal bei Übergabe nur Adressen. Irgendwie schnallt der Hi-Tech C Compiler das aber nicht.
Oder er kann keine mehrdimensionalen Felder übergeben.
Stehe irgendwie auf dem Schlauch momentan.
Alles anzeigenVirtual Basic bietet sogar ein Klassen Modell, also Objekt orientierte Programmierung mit Ableitungen etc.
Mengen?
Es gibt Listen, also Arrays mit dynamischer Größe und Strings oder Zahlen als Index.
Seit .net kann man sogar beliebig die Sprachen mischen.
Du meinst sicherlich Visual BASIC, nicht Virtual Basic
Im Hobby-Bereich war und ist sicherlich auch noch Visual BASIC bis in die Gegenwart im Einsatz/beliebt.
Kommerziell ist aber BASIC, egal welches Dialekt, schon lange tot.
Alle großen Softwareprojekte sind meist in Java, C++ und C#, Javascript oder vor auch in Python programmiert .
Suche mal auf github oder sf nach Softwareprojekten, die in BASIC geschrieben sind.... viel Spaß beim Suchen.
Aber ich denke, hier im Thread ging es nicht um das "ernsthafte" Anwenden und Projekte stemmen, sondern um den hobbymässigen Einsatz.
Da es aber um DOS ging, ist GFA BASIC oder BBC BASIC keine Option, und das Visual BASIC für DOS gab es auch nur in einer Version, bevor es den Kram nur noch für Windows gab.
Für mich ist BASIC dennoch nur noch von historischem Belang. Aber das muss ja nicht schlecht sein. Hier geht's ja auch um historische Rechner
detlef : Das ist ein echter Sonderfall - die serielle Schnittstelle wird in (Q)BASIC tatsächlich gepuffert ausgelesen, und in genau diesem Fall würde ich auch wahrscheinlich (Q)BASIC nutzen, aber das sagt noch nichts darüber aus, ob der Rest der Sprache und des Compilers (bzw. Interpreters in diesem Fall) für alle anderen Fälle besser geeignet ist. Und oft wird halt in BASIC nur Spaghetti-Code programmiert, also alles monolitisch in einem Programm, viele GOTOs und am Besten nur globale Variablen. Nee Danke, für große Softwareprojekte ein Graus.
Wenn man hier drei Leute fragt, bekommt man vier Antworten ... so scheint es jedenfalls
Ich würde empfehlen, bei DOS-Programmierung mit den Borland Compilern anzufangen.
Also Turbo PASCAL oder Turbo C - die gibt's bei Embarcadero auch in einer freien Version, oder Googlen hilft dabei auch.
Die Entwicklungsumgebung (IDE) hilft dabei erheblich, man braucht keinen zusätzlichen Editor und es ist es auch ein Debugger dabei.
Und es gibt eine Unmenge Programmierbeispiele.
Alles andere ist für mich exotisch bzw. brotlose Kunst. Selbst QB/QBASIC ist eher von historischem Interesse und nicht wirklich geeignet, modular und klar strukturiert arbeiten zu können.
Was ist denn ein AT-Bus "Pre-IDE" Hard Disk Drive ? Erinnert mich an die IBM PS/2 P70 ESDI (DBA) Laufwerke irgendwie...
Siehe auch https://blog.nicholasandre.com…-the-land-before-windows/
P.S.: In den Kommentaren des erwähnten Blogs steht wohl eine Korrektur (scheint doch IDE zu sein, muss aber genau die Größe der eingebauten Originalplatten haben). Eingebaut ist entweder eine Conner CP2084 (80Mb) oder eine Conner CP2124 (120Mb).
