Die ganzen "CHR GEN" Teile sehen nach Character Generator (E)PROMS für den Apple aus, der mit dem Totenkopf ist wahrscheinlich kaputt...
D0, D8, E0, E8, F0 sind auch wahrscheinlich Apple ROMs an den entsprechenden Adressen.
"Space 81" ist ein Apple-Klon; ich kenne den nicht im Detail und weiß nicht, wie stark der sich vom Original unterscheidet.
AY-3-8500 ist ein in Videospielen verwendeter Chip (siehe Link).
Keine Ahnung was die 7LT, 8LT, 9LT sein könnten.
Ich kann mich nicht daran erinnern, dass die Disk II jemals gestunken hat... und sonst kann ich mich an Gerüche aus meiner Jugend eigentlich ganz gut erinnern.
Ich würde auch gerne mal vorbeischauen, aber ich bräuchte noch eine Einladung mit Link zum Treffen...
Man braucht ja wohl im wesentlichen einen OpenVPN-Server, der hereinkommende Verbindungen bridged, und das sollte auch auf einer existierenden VM gehen. Oder ist es doch komplizierter?
Mit DECNET würde ich auch gerne mal spielen wollen, falls virtuelle SIMH-Maschinen, die nicht immer laufen, akzeptiert werden.
Das dürfte ja klar sein, wenn es USB-IDE-Adapter-Chips inkl. entsprechender Ansteuerung gibt (siehe oben, Hi-Z).
Ganz einfach: Die Versorgungsspannung des Synthi deaktiviert den USB-IDE-Chip und verbindet die HDD wieder mit dem Synthi, damit dieser nicht meckert "keine HDD". Dann ist die USB-Übertragung eben unterbrochen...
Dann ist's aber überhaupt nicht "im laufenden Betrieb", sondern entweder Synthi an und Synthi auf Festplatte, oder Synthi aus und PC auf Festplatte.
Da könnte man dann fast auch das Kabel umstöpseln, ist nur geringfügig mehr Aufwand als den Synthi ein- oder auszuschalten... (und deutlich billiger zu realisieren).
Vampire Taps, so heißen die Löcher?
Die Anschlusskästen bohren da wirklich mit einem "Zahn" ein Loch rein, "Vampir" passt schon. Wir hatten das Zeugs noch an der Uni, da durfte ich mal einen mitinstallieren. Dickes Kabel liegt im Flur, Vampire Tap draufgeschraubt, dann dünneres Kabel in das Zimmer rein.
Manual sagt "ein gleichzeitiger Datenzugriff ist technisch nicht möglich". Also ist es nicht "im laufenden Betrieb", sondern da sitzt ein USB-IDE-Adapter, der irgendwie auf den existierenden Adapter draufgemultiplext wird. Fragt sich, wie genau, und was passiert, wenn doch ein gleichzeitiger Datenzugriff angestossen wird, das ist nämlich das Haarige bei dieser Lösung.
Aber wenn der Synthi auf die Festplatte nur auf Kommando zugreift, ist das vielleicht in der Praxis kein Problem (aber ich kenne den Synthi nicht).
Die Frage ist nicht blöd: aber: dann müsste ich sie jedesmal ausbauen, wenn ich was Neues draufmachen will. Und das Datenmanagement ist am PC\Mac einfacher und komfortabler
Dann einfach das IDE-Interface + ggf. Strom irgendwie so herausführen, dass man sie einmal intern und einmal an den PC/Mac anschliessen kann? (Mac hat ja wahrscheinlich sowieso einen USB-IDE-Adapter). Dann musst du sie nicht ausbauen, nur das Kabel umstöpseln.
"Paralleler Zugriff via USB im laufenden Betrieb" ist schon ziemlich frickelig.
Blöde Frage: Warum das Ding nicht ausbauen, und dann an einen existierenden PC als zweite Festplatte hängen, und dann mal schauen, was da drauf ist?
Oder muss es im laufenden Betrieb sein?
Diese Karte hier sieht schonmal so aus wie deine, nur ist der linke Teil mit Widerständen und Transistoren bestückt, dafür fehlt rechts der Stecker.
Die Beschreibung sagt
ZitatIt's emulating an Apple Super Serial card, however, it only supports output and a fixed baudrate and uses simple software controlled "bit banging" to create the serial bit timing. All it needed was an EPROM, a few basic logic chips and three transistors. All chip markings were wiped, however, it's still quite clear how it works. This obviously was a cheap I/O interface replacement to connect an ImageWriter.
The card contains a 2K EPROM with surprisingly complicated firmware. It contains code to emulate Apple Super Serial escape sequences and also to format tabbed ASCII text specifically for the ImageWriter (probably meant to pretty print program listings).
The PCB mentions "NPARA-2" as a card name, but no manufacturer. The EPROM contains German error messages (when the printer is not ready) and also contains a copyright referring to a German name (R.Drenske). Might refer to a small electronics company in Cologne, which existed in the 80s - not sure.
Das sollte doch schonmal helfen.
Du kannst sie ja mal reinstecken und einen ROM-Dump machen.
Hm, "32 bit" scheint der Transfer Mode zu sein, dann ist es vielleicht doch ATA, also LBA-28...
Da das BIOS von 1997 zu sein scheint, wird es noch kein Atapi LBA-48 kennen, welches erst 2000 eingeführt wurde.
Somit sollte es nur maximal Atapi LBA-28 (28bit Sector Nummern) unterstützen, was 128GB entspricht.
Das ist reines ATA mit LBA, nicht ATAPI mit LBA, und in diesem Fall verstehe ich die "32 Bit" nicht.
Aber keine Ahnung, was dein BIOS da tut, vielleicht nennt es ja ATA LBA-28 "32 Bit"...
Kann man ja rausfinden: Große Platte dranhängen, kleines Assemblerprogramm schreiben, welches INT 13 aufruft, und dann probieren, wie hoch es geht.
Ggf. gibt's da auch schon irgendwo ein fertiges Tool, müsste man mal googlen.
Code//system.loadPack("http://localhost/contraltojs/images/" + diskName + ":8080",
Das kann so auch nicht gehen: Der Port gehört direkt hinter den Hostnamen, also "localhost:8080". Steht da nur "http://localhost", geht er auf "localhost:80", das ist verschieden von "localhost:8080", und deshalb der CORS-Request.
Und vermutlich rennt auf 80 auch kein Server (und selbst wenn einer rennt, hat der nicht das Diskimage, und auch eher keine CORS-Konfiguration), deshalb die Fehlermeldung.
Das Folgende läuft bei mir ohne Änderungen am Code:
git clone https://github.com/sethm/ContrAltoJS.git
cd ContrAltoJS
mkdir -p contraltojs/images
cd contraltojs/images/
wget https://archives.loomcom.com/contraltojs/images/games.dsk
cd ../..
python3 -m http.server --cgi 8080Dann Firefox auf http://localhost:8080/. Developer Tools zeigt im Network Tab, dass das Image relativ zum Hostname geladen wird.
So, doch mal schnell nachgeschaut, die ATA-Kommandos für LBA sind READ(10), READ(12), READ(16) und READ(32).
Mit 32-bit und 512-byte-Sektoren sollten sich 2TB adressieren lassen, wenn ich mich nicht verrechnet haben.
Wenn das BIOS LBA und 32-bit kann, sollten also 2TB gehen mit jedem OS, dass die entsprechende LBA BIOS Funktion auch benutzt.
Bei dieser Art des Zugriffs auf das BIOS entfallen auch die ganzen anderen Grenzen, die du verlinkt hast, und die alle durch die CHS-Übersetzung verursacht werden (und die wahrscheinlich der Grund für die Aussage "dieses BIOS erkennt 8GB Festplatten" sind).
Freedos sollte das z.B. tun, was genau D-OS und Wind-OS machen, hängt wohl sehr von der konkreten Version ab...
Aber genau das hatte ich ja auch probiert! Siehe auskommentierten Auszug weiter oben.
Da steht immer noch "https://archives.loomcom.com/contraltojs/images/games.dsk", und nicht "http://localhost/...", deshalb bin ich davon ausgegangen, dass die Adresse im Script hardkodiert ist, und du sie nicht auf localhost geändert hast.
Ansonsten gib doch mal die Fehlermeldung, die bei dieser Änderung passiert.
Bei Windows normalerweise nicht, es fehlen oft wichtige Treiber, gerade für einen Laptop.
Bei hinreichend generischen Linux-Systemen geht es.
So ganz grob aus dem Gedächtnis: Es gibt eine Serie von Spezifikationen mit unterschiedlicher Bitbreite für die Blockaddresse, von CHS dann über LBA mit diversen ATAPI-Befehlsklassen.
Das bestimmt denn höchsten Block, den das BIOS adressieren kann. Was allerdings keine Rolle mehr spielt, wenn du in ein OS bootest, was dann selbständig die Festplatte adressiert, und dem egal ist, was das BIOS macht. In diesem Fall muss das OS nur weit genug vorne auf der Festplatte liegen, damit es gebootet werden kann.
Der "sichere Weg" ist also: Ein OS benutzen, was große Festplatten selbstständig ohne BIOS unterstützt, und es so auf der Festplatte unterbringen, dass es vom BIOS gebootet wird.
"Spiegeln" sollte eigentlich nicht passieren, eigentlich sollte alle beteiligte Software sich beschweren, sobald die Bitbreite in den benutzten Befehlen überschritten wird.
Dann gibt's da noch die Spielereien mit der Blockgröße auf Festplatten, was zusätzlich Dinge spannender (und langsamer) machen kann.
Frage2: Ich versuche es lokal zu betreiben. Github ist hier:
https://github.com/sethm/ContrAltoJS
CodeDownloading file https://archives.loomcom.com/contraltojs/images/games.dsk... system.js:75:25 Quellübergreifende (Cross-Origin) Anfrage blockiert: Die Gleiche-Quelle-Regel verbietet das Lesen der externen Ressource auf https://archives.loomcom.com/contraltojs/images/games.dsk. (Grund: CORS-Kopfzeile 'Access-Control-Allow-Origin' fehlt). Statuscode: 200.
Das Internet wirft dich zu mit Informationen über CORS (googeln), aber kurz gesagt: Wenn du Javascript von foo.com ausführst, kann das Script nichts von bar.com laden, es sei denn, der HTTP-Server von bar.com liefert einen CORS-Header mit.
Das dient der Sicherheit: Sonst könnte foo.com (ein Hacker) nämlich so tun, als sei es bar.com (eine Bank), einen Benutzer zu verleiten, auf foo.com statt auf bar.com zu gehen, und dann echte Daten von bar.com stehlen oder imitieren.
Wenn du also ContrAltoJS von localhost ausführst, aber Zeugs von archives.loom.com laden willst, geht das nur, wenn archives.loom.com einen CORS-Header mitliefert. Was es nicht tut, und was du auch nicht anstellen kannst, da der Server nicht dir gehört.
Mögliche Lösung: Die Dateien auch auf den localhost-Server kopieren, und das Script so ändern, dass es auf http://localhost/contraltojs/images/games.dsk zugreift.
Bei der Online Version geht es ohne Fehler:
Das ist klar, denn dann führst die das Script auf archives.loom.com aus, also kann er auch von archives.loom.com laden.
https://seeseekey.net/archive/126538 habe ich gmacht - kein Unterschied?
Das erlaubt das Laden von lokalen Dateien, dann musst du https://archives.loomcom.com/contraltojs/images/games.dsk im Skript umändern auf file://was/auch/immer/der/pfad/ist/games.dsk.
Ich habe Guake installiert, und der Shortcut zum Terminal-Aufruf will einfach nicht funktionieren. Bei der gleichen Debian-Version auf anderen Rechnern gibts da keine Probleme.
Systematisch debuggen: Von `evtest` mit dem eigentlichen Tastendruck über alles, was da der Reihe nach den Tastendruck verarbeitet. Insbesondere wenn die Tastatur eh Probleme macht, erstmal `evtest`.
Ebenso reagiert der Rechner auf keine Tasten-Eingaben, wenn er ausgeschaltet war, z.B. DEL um ins BIOS zu kommen oder F12 zur Auswahl des Boot-Mediums. Ich muss den Rechner dafür erst mal in das installierte Linux bis zur Anmeldung booten lassen, und dann mittels Maus (jedenfalls ohne Abschaltung) einen Reboot auslösen, dann funktioniert die Tastatur im Boot-Vorgang. Im BIOS ist alles entsprechend eingestellt, der USB-Legacy-Modus ist aktiviert.
Das klingt nach "das BIOS initialisiert die Tastatur anders als Linux, und die Methode des BIOS klappt nicht, während die Linux-Methode klappt".
Kann man das BIOS flashen?
Noch eine Macke: Ich habe einen Wlan-USB-Stick angenopst, der funktioniert auch. Nur beim Shutdown bleibt der Vorgang beim Beenden von wpa-Supplicant hängen.
Das kann alles Mögliche sein. Kannst du wpa-supplicant manuell beenden? Fehlermeldungen?
Wo sind denn die Steckerleisten für die Schnittstellen? Auf der Rückseite? Oder bin ich blind?
Was jedoch bemerkenswert ist, ist die Reihenfolge der Sektoren. Diese wechselt mit jedem Track und wiederholt sich erst wieder nach 8 Spuren. Ausgenommen ist nur der Sektor 17, der immer am Ende einer Spur steht. Muss ein nettes Formatierungsprogramm sein. Beim Lesen sorgt ja dann der Controller dafür, dass die Sektoren in der richtigen Reihenfolge eingelesen werden. Die Programme brauchen also nur mehr die Daten 1:1 einlesen.
Wieso ist das bemerkenswert? Das ist der Sektorskew und durchaus üblich. Das war immer das Problem mit dem Floppytreiber in Linux, nämlich dass er einen fest eingebaut hat.
Bzgl. des 17. Sektors: kannst du mal den Sektorheader posten, inkl. Adressmarke und CRC-Bytes? Du hast nur den Datenblock gepostet.
Bemerkenswert ist schon, dass der 17. Sektor jedesmal woanders in der Skew-Abfolge steht. Wenn der 17. Sektor als Teil der normalen Formatierung geschrieben wird, hätte ich schon erwartet, dass er z.B. jedesmal am Ende kommt (also die Formatierung mit Sektor 0 4 8 ... anfängt, und mit Sektor 17 aufhört).
Das wird auch nichts nützen, wenn der Controller keine 128 Byte MFM-Sektoren schreiben kann.
Nur aus Neugier: Welche PC-Floppy-Controller konkret können denn keine 128-Byte-Sektoren mehr schreiben?
Man benutzt auch seit vielen vielen Jahren nicht mehr TeleDisk, sondern stattdessen ImageDisk. Ist allerdings auch ein DOS-Tool. Ich habe meine selbstgestrickte Linux-Version auf unserem FTP-Server unter /utils, Name imd bzw imd.c.
/pub/cm/utils, falls es noch jemand sucht. FDRAWCMD ist übrigens seit 2022 deprecated (weil Sicherheitslücke), und man muss es ggf. mit CONFIG_BLK_DEV_FD_RAWCMD im Kernel wieder anstellen.
Meine persönliche Mutmassung zum Bogwire und der RTC-Karte ist, dass, um der RTC-Karte einen "Nutzwert" zu geben, sie eine Zweitfunktion hat, eben die Auswertung der Shift-Taste vorzunehmen.
Das hatte ich auch erst vermutet, aber Durchlesen des Handbuchs zur "Time Master II H.O." läßt keinen Hinweis darauf erkennen... (Handbuch läßt sich leicht ergooglen). Ist eine reine RTC-Karte, mit der man außerdem noch externen Kram zeitabhängig steuern kann (deshalb H.O. = high output).
Die ganzen Steckkarten wurden einfach ohne weiteren Einbau (siehe 80 column card) in die slots gesteckt. Der Bogwire verschwand einfach im Sockel der RTC. Wahrscheinlich unabsichtlich. Die Karten sind erst mal alle draussen. Dein Vorschlag bezüglich Einbau dieses Sockels der 80CC scheint zu passen. Ich habe zwar nirgends eine Dokumentation zu meiner Karte gefunden aber auf einem amerikanischen Forum hat ein Kollege wohl die selbe Karte und auch diesen Weg genannt.
Aktuell warte ich noch auf meinen Videokonverter und kann deshalb nicht testen. Sollte in den nächsten Tagen aber eintreffen. Netzteil ist draußen und wird in den nächsten Tagen gemessen.
Das heißt, das eine Ende des Bogwire ist nirgendwo angeschlossen? Dann ist die Wahrscheinlichkeit hoch, dass der an einem der Tasteneingänge am Gameport hing.
Handbücher für diverse 80-Zeichen-Karten gibt es z.B. hier.
Ich kann meinen Apple auch an meinen LCD-Fernseher anschließen, das tut über den Analogeingang. Kein Videokonverter nötig.
Also die Tastatur kann ja keine Gross- und Kleinbuchstaben unterscheiden.
Daher war seinerzeit übliche Erweiterung die Shift-Taste abzugreifen und mit Bogwire an den Gameport zu stecken. In Bürorechnern wurde der eh ansonsten nicht benutzt.
Dazu das Character Generator ROM rausgeschmissen und ein EPROM reingesetzt.
Den Tastatur-Hack habe ich auch, inklusive Umschalter für Originalzustand/Mit Kleinbuchstaben, aber ich verstehe nicht, weshalb das direkt an einen Slot geht, und wie das damit funktionieren soll. Deshalb die Frage, wo genau es hin geht. Evtl. macht ja auch die Karte da irgendwas.
Wo ich gerade am Bilder hochladen bin:
Bei meinem Apple II gab es schon seit "damals" die Lösung, den Gameport mit einem Flachbandkabel, das von woanders geklaut war, nach draußen zu leiten:
Dann konnte man da diversen anderen Krams anschließen, z.B. eine Lochrasterplatinen mit Stiften für selbstgebaute Paddle, oder eine selbstgebaute serielle Schnittstelle:
Die Lochrasterplatine für die Paddles ist irgendwo verschollen, also ohne Foto.
Die Schnittstelle diente der Übertragung auf den damals neuen IBM PC, vor allem von Turbo-Pascal-Programmen. Angesteuert über Bit-Banging.
Nur sicherheitshalber, du machst es wahrscheinlich sowieso schon so:
Wenn der Apple II gereinigt ist, erstmal Netzteil separat testen.
Wenn das funktioniert, dann den Apple komplett ohne Karten anschalten. Du solltest ins BASIC kommen. Damit sieht man, ob der Apple selbst funktioniert, denn defekte Karten können da dazwischenfunken.
Offenbar waren ja nicht alle Karten eingebaut, also nochmal Grundlagen:
Language Card in Slot 0, 80-Zeichen-Karte in Slot 3, Floppy-Controller (ob nun emuliert oder nicht) in Slot 6. Ich tue die Z80-Karte immer in Slot 4. Slot 1 ist üblicherweise der Drucker, also freilassen, wenn du keinen hast.
Meine 80-Zeichen-Karte ist so angeschlossen (unter das IC, weiss/orange Kabel).
Das kann bei deiner Karte auch so sein, oder anders; im Zweifelsfall gibt's haufenweise Manuals von allen möglichen Karten im Internet.
Der blaue Flachbandstecker daneben steckt in dem "leeren" Sockel und leitet den Gameport nach draußen, das ist praktischer, wenn man da verschiedene Dinge anschließen will (bei mir: Selbstgebaute Paddles, oder eine selbstgebaute serielle Schnittstelle, alles noch von damals).
Die Language-Card wird so angeschlossen:
Keine Ahnung, was der Bogwire soll, auf welchen Slot und welchen Pin geht der? Dann kann man ggf. nachvollziehen, was da passiert.
Wenn du keine Software hast, schau dir mal ADT Pro an.
Viel Spaß!
Mein Apple II läuft jetzt (nachdem diverse Original-Netzteile alle den Geist aufgegeben haben) mit einem alten PC Netzteil, das noch die -12V kann.
Das sollte eigentlich auch mit einem IIe gehen, und PC-Netzteile mit -12V sind ggf. einfacher zu finden, wenn es dir hier keiner repariert...
