Posts by MacFly

    fanhistorie: Gutes Auge! ;) Im Moment ist die Platte wieder eingebaut, aber beim nächsten Öffnen werde ich nochmal genauer nachschauen. Ich denke aber, dass das rosa Kabel des Hall-Sensors nicht verschmort ist - sondern dass es Ablagerungen durch den schwarzen 18Ohm/2W Widerstands (R29) sind. Wenn man den Sandwich zusammenklappt, dürfte das Kabel direkt auf dem Widerstand aufliegen (wie gesagt, da ist sehr wenig Platz zwischen Platine und Chassis der Festplatte). Die saubere Abdruck auf dem rosa Kabel dürfte die Stelle sein, wo das Kabel direkt auf dem Widerstand aufliegt - dort kommt kein Schmutz heran. Die schwarzen Ablagerungen sind dann direkt daneben (vermutlich Dreck, der durch die Abwärme des Widerstands aufgestiegen und angepappt ist). An den anderen Kabeln daneben ist ja auch etwas Schmutz zu erkennen:




    Schalt ein das Ding und lass es am Laufen


    :)

    Auch eine Idee! Wenn die Maschine (Lüfter+Festplatte) nur nicht so laut wie ein :choplifter: wären... ;)

    So, ich habe den Controller mal demontiert. Einige der Kondensatoren habe ich ausgelötet und getestet. Die waren aber alle einwandfrei. Zwei habe ich trotzdem getauscht. Die anderen sind so überraschend winzig für ihre Kapazität/Spannung, dass ich dafür extra welche bestellen (und auch erst mal finden) müsste (sehr geringe Bauhöhe, weil nicht viel Platz unter dem Laufwerk ist - die Höhe der ICs/Stecker ist fast schon die maximale Bauhöhe).


    Ich denke, es ist aber auch kein elektrisches Problem: es tritt ja nur nach längerer Standzeit auf, und dann hilft es nur, wenn man die Spindel etwas weiterdreht. Der Motor ist bürstenlos - es kann also eigentlich nur am Lager liegen. Leider.




    Was ich noch gemacht habe, ist den Massekontakt zur Spindel zu säubern. Der Kupferstreifen war so angelaufen, dass mit dem Multimeter kaum ein Widerstand zu messen war (bzw. unendlich...). Kontaktspray half auch nicht, da musste der Glasfaserstift ran. Nun ist es sowohl an der Platinenseite, als auch an der Lauffläche wieder blank - und das Multimeter zeigt einen Widerstand im Komma-Bereich.


    Nach dem Schaltplan hat der Massekontakt zur Spindel aber nichts mit dem Antrieb zu tun. Der Motor hat eine eigene Masseverbindung. Der Streifen soll wohl nur den Plattenstapel erden, vermutlich um statische Aufladung zu verhindern. Dürfte also wenig an dem Anlaufproblem ändern.




    Ich habe sie nun wieder eingebaut. Und da die Spindel bewegt wurde, ist sie auch wieder sofort angelaufen.

    Vermutlich hilft nur regelmäßiges, tägliches Einschalten der Retro-Maschine... :)

    Hallo,


    ich habe hier eine Tandon TM252, eine MFM-Festplatte aus einem alten Olivetti. Die Festplatte hat Anlaufschwierigkeiten: wenn sie einige Tage stand, dann läuft sie beim Einschalten nicht an. Es reicht dann aber aus, wenn ich den Motor minimal weiterdrehe. Von der Unterseite kommt man direkt an die Spindel heran. Es reicht aus, die Spindel etwas weiterzudrehen - in ausgeschalteten Zustand.


    Wenn ich danach einschalte, läuft sie jedesmal problemlos an. Ich habe das Spiel nun schon zig mal gemacht. Ist immer das gleiche.


    Ansonsten läuft die Festplatte problemlos. Keine Probleme beim Schreiben-/Lesen, keine defekten Sektoren etc.


    Ursprünglich hatte die Platte auch singende, kreischende Geräusche von sich gegeben. Das hat sich inzwischen, nach einiger Laufzeit, aber komplett gegeben. Sie surrt nun ganz normal vor sich hin - wenn sie denn angelaufen ist.


    Ist das ein bekannter Effekt - Problem mit dem Lager?




    Die Kopie des ROMs von der NPARA Karte hätte ich auch gerne. :)


    Ich bin übrigens der aus dem anderen Thread oben, der die serielle Variante der NPARA Karte hat. Deine scheint dagegen eine parallele Karte zu sein - sie ist ja anders bestückt.


    Die NPARA Karten hatten Drucker-spezifische ROMs. Meine hat ein ROM für Apple ImageWriter. Das Drucker-spezifische kommt daher, weil die Karte nicht nur als dumme Schnittstelle agiert, sondern auch höherwertige Kommandos versteht - z.B. um den Bildschirm-Inhalt (sogar den Grafik-Bildschirm) in unterschiedlichen Formaten auszudrucken. Dafür muss sie natürlich die Steuercodes des Druckers kennen, um überhaupt Grafik drucken zu können.


    Diese höherwertigen Funktionen wurden m.W. ursprünglich von den Grappler-Karten eingeführt(?). Diese Karte unterstützt die gleichen Kommandos - ist aber viel billiger aufgebaut. In meinem Fall eben mit Bit-Bangig einer seriellen Schnittstelle.

    Gerade vor ein paar Tagen hatte FrozenSignal in einem anderen Fritter-Thread den Status seines Projekts aktualisiert. Er arbeitet seit einiger Zeit mit Henry (ReactiveMicro.com) zusammen, um Verkaufsversionen für den IOU+MMU Ersatz zu erstellen.


    Sie haben inzwischen schon erste Verkaufskandidaten - mit der IOU aber nochmal Probleme gefunden, d.h. das verzögert sich etwas. Für die MMU soll die Verkaufsversion ein anderes CPLD nutzen, als er (FrozenSignal) ursprünglich verwendet hatte (im github Projekt). Auch damit testen sie aber schon.


    Es scheint also bald fertigen IOU+MMU Ersatz zu geben - zumindest als "kommerzielle" Version über ReactiveMicro (kommerziell in Anführungszeichen: klar, die verkaufen das dann über den Shop, aber reich wird damit keiner. Und ich glaube, FrozenSignal gibt sein Design auch kostenlos an Henry ab, damit er das auf Adapter-PCBs schrumpft, produziert und für jeden verfügbar macht).


    Soll jetzt keinen davon abhalten, nicht selbst an einer Lösung zu basteln - oder vielleicht sogar eine bessere Hardware-Lösung zu finden. Das Design steht ja auch unter CreativeCommons Lizenz. Wenn es aber nur darum geht, generell einen (ersten) IOU+MMU Ersatz zu schaffen, dann scheint sich dieses Problem in Kürze zu lösen (in einigen Wochen/Monaten/dieses Jahr, so wie die Berichte klingen).


    Uncle Bernie's "Replica 2e" (WW Prototype of an Apple IIe replica) | Applefritter


    "We're very close to the finish line. We only need to fix the problem with the adapters, re-test everything and produce the retail version of the adapters."


    Falls du es nicht bereits auf dem Board hast, würde ich dir doch die erweiterte Firmware empfehlen:

    GitHub - ThorstenBr/Apple2Card: Apple II Peripheral Card that Interfaces to a ATMEGA328P for SD card storage
    Apple II Peripheral Card that Interfaces to a ATMEGA328P for SD card storage - GitHub - ThorstenBr/Apple2Card: Apple II Peripheral Card that Interfaces to a…
    github.com

    Bringt mehr Komfort, mehr Flexibilität, ermöglicht Firmware-Updates direkt über den Apple II und bringt einen FTP Server mit (der erreichbar ist, wenn du noch ein Wiznet-Modul aufsteckst). Dann kommst du auch von deinem Arbeitsplatzrechner an die Festplatten-Images auf den SD Karten heran.


    Die Karte funktioniert übrigens auch einwandfrei im Apple ///. Für den Apple /// habe ich inzwischen auch ein Custom ROM, so dass man dort, wie auf dem Apple II, auch ohne Floppy direkt ins Menü des Controllers kommt - und geeignete Images auch direkt bootstrappen kann. Das ist dann aber noch mal ein Thema für die Apple /// Ecke... ;)

    Quote

    Fix long standing bug that prevented creating more than 33024 files in a directory.

    Na, endlich ist dieses tägliche Problem auf dem Apple II mal gelöst! ;)


    Im Ernst, freut mich, dass er doch noch weitergeht. Ich dachte neulich schon, er hätte es aufgegeben, nachdem die letzte ProDOS 2.5alpha Version zum Testen schon 3 Jahre alt ist. Aber zumindest Bugfix-Releases für ProDOS 2.4 gibt es weiterhin.

    Quote

    https://archive.org/details/pe…85-01-02/page/88/mode/2up

    Tester Dripke ermutigte mich: „Der Einsatz der Platine in den Computer ist problemlos. Allerdings: Im Unterschied zu der Mehrzahl der Apple-Karten müssen die Bauteile von vorne gesehen nach links zeigen.“

    Das hat "Tester Dripke" (der ja eigentlich nicht "der Tester", sondern Autor/Hersteller der Karte ist) aber schön ausgedrückt. Natürlich hat "die Mehrzahl" der anderen Karte die Bauteile auf der anderen (richtigen) Seite... :D

    Richtig, das größere Adressfenster führt natürlich zu einer größeren Granularität bei den möglichen Adressen. Das ist ein Nachteil. (Der nötige Adressbereich ist aber 32KB, nicht 64KB).


    Ja, A15+A16 braucht man zum Programmieren nicht. Steht auch explizit so im Datenblatt. Das hat man extra so gemacht, damit es das Problem nicht gibt, dass man einen Baustein nicht mehr programmieren kann, wenn man einen größeren Baustein der Serie bestückt hat (finden Firmen immer gut, wenn man notfalls einfach einen größeren/teureren Bausteine als Ersatz bestücken kann, z.B. wenn mal wieder Chipkrise herrscht, und irgendwas plötzlich nicht lieferbar ist). Den 32KB Adressraum (Leitungen A0-A14) braucht man aber zum Programmieren. Kleinere Flashs als 32KB gab es in dieser Serie nie.


    Was man sonst auch machen könnte: die Jumper, die A13+A14 mit dem Adresskomparator verbinden, trotzdem anbieten - z.B. als optional Steckbrücke. Dann hat man die Wahl: zum Programmieren des Speichers muss man die Jumper öffnen, damit der 32KB Bereich zugreifbar ist, und der Baustein beschrieben werden kann. Für den normalen Betrieb dürfte man sie aber wieder setzen - wenn man den Adressbereich wieder auf 8KB beschränken möchte. Man müsste dann das 8K ROM nur an die richtige Stelle in dem 32KB Bereich flashen, damit der Inhalt auch im 8KB Modus sichtbar ist. Oder, wenn man nicht nachdenken möchte, programmiert man das 8KB ROM einfach stumpf 4x hintereinander in das Flash. Dann ist es auf jeden Fall korrekt sichtbar, auch wenn man das Fenster wieder auf 8KB reduziert.


    Technisch alles überhaupt kein Problem. Gebe aber zu, es wird komplizierter das alles jemanden zu erklären... Ist halt die Frage, ob es das wert ist.

    Ich glaube trotzdem, es ist beides genau das, was du brauchst, um den Flash statt EEPROM anzubinden.

    Das Flash ist programmierbar, wenn es als mindestens 32KB Fenster eingeblendet wird. Das sind genau 256kbit. Das ist genau die Option, die du mit den Jumper schon im Schaltplan hast. A15+16 kannst du dagegen auf Masse legen. Macht das XT-CF-light auch so. Die Jumper, die A13+A14 mit dem Adresskomparator verbinden, musst du öffnen - damit das Adressfenster von 8KB auf 32KB vergrößert wird. Ich sehe jetzt keinen Schaltplan zu deinem PCB, aber wenn du da Pull-Down WIderstände an den A13+A14 Eingängen des HCT688 gelegt hast, dann müsste das Trennen der beiden Adressleitungen zum HCT688 schon das gewünschte Ergebnis bringen. Da sind doch schon Widerstände direkt neben dem HCT688. Sind das nicht Pull-Down Widerstände?

    Klar, A13+14 anbinden, dann aber auch das Adressfenster vergrößern, damit der Chipselect des Speichers im gesamten 32K Bereich aktiviert wird. Wenn ich mir das PCB oben anschaue: ist das nicht ohnehin so vorbereitet? Da sind zwei Jumper "8K" - und Jumper für A13+A14. Was passiert, wenn man die 8K Jumper nicht setzt, aber die Jumper A13+A14 setzt? Ist das nicht schon das, was du brauchst? Dann musst du den Schaltplan nicht mal groß ändern.


    Ansonsten: es gibt ein XT-CF Lite. Da ist der Flash auch drauf (mit A13+A14 verbunden):

    https://www.lo-tech.co.uk/w/images/3/3b/Lo-tech-xt-cf-lite-schematic.jpg

    Dazu gibt es auch ein Flash-Tool:

    Lo-tech XT-CF flash utility - Lo-tech Wiki


    Das sieht doch vielversprechend aus...

    Das Flash würde grundsätzlich gehen, man verliert aber definitiv die Option, den Baustein im System updaten zu können. Nicht nur, weil XTIDECFG.COM das Schreiben dieses Flashs nicht unterstützt, sondern weil es bei diesem Baustein grundsätzlich nicht geht, wenn man die Adressleitungen A13..A14 nicht ansteuern kann (weil sie auf dem PCB hart auf einen Pegel gelegt sind). Bei dem Flash muss man A0..A14 steuern können, um es in den Programmiermodus zu bekommen (durch Schreiben von bestimmten Bitmustern auf Adressen 0x5555 + 0x2AAA, wofür man Leitungen A0...A14 braucht). Die Adressleitungen >= A15 werden dagegen für das Programmieren nicht unbedingt benötigt. Das wäre zumindest ein Nachteil gegenüber dem 28c64.

    Er sagt, dass er eine Maschine mit deutscher Beschriftung hat, oder?


    Das Video oben handelt von einer Einladung "von einer Mainframe Organisation" nach Deutschland, wo er (beruflich) einen Vortrag gehalten hat, und sich dann das Datencenter anschauen und filmen durfte.


    Aufgrund der Umstände tippe ich darauf, dass es sich bei dem "Mainframe Hersteller" um den ursprünglichen, drei-buchstabigen Hersteller der genannten Systeme handelt, und das in derem "Cloud Rechenzentrum" in Frankfurt aufgenommen wurde. Ist aber nur mein Tipp.

    Welcher andere "Mainframe Hersteller" würde eine halbe Etage für alte IBM Systeme reservieren, und die für Demo-Zwecke betreiben...

    Wenn du ein Floppy-Image hast, das auf ProDOS-basiert, dann kannst du die Datei einfach konvertieren. Das ".dsk" und das ".po" (bzw. ".hdv") unterscheiden sich nur in der Reihenfolge der Daten. ".dsk" ist ein Format, das die Daten so ablegt, wie sie auf der Floppy liegen (Tracks aufsteigend, die einzelnen 256byte Sektoren aber etwas verwürfelt). Bei ".po" sind die Daten einfach linear aufsteigend ablegt - so wie es inhaltlich eigentlich logischer ist. Für die Konvertierung reicht ein einfaches Skript - wie dieses:

    GitHub - paulhagstrom/dsk2po: Python script to convert Apple II/III .DSK (DO) images to ProDOS-ordered images
    Python script to convert Apple II/III .DSK (DO) images to ProDOS-ordered images - GitHub - paulhagstrom/dsk2po: Python script to convert Apple II/III .DSK (DO)…
    github.com


    Die Konvertierung macht aber nur dann Sinn, wenn der Inhalt der Floppy auf ProDOS basiert. Ansonsten hast du die Daten zwar korrekt konvertiert - aber du kannst das konvertierte Image dann trotzdem nicht von einem Festplatten-Emulator (wie Apple2-IO-RPI, DAN ][ Controller etc) laden. Diese Karten implementieren eine Schnittstelle nach "ProDOS Interface Standard". Der Standard wurde, wie der Name schon sagt, erst mit ProDOS eingeführt. Programme die auf DOS basieren, oder gar kein Betriebssystem nutzen, sondern einfach low-level direkt auf die Hardware des Floppy-Controllers zugreifen, kannst du dann nicht von so einer Festplatte laden. Ohne ProDOS wissen diese Programme gar nicht, wie sie da weitere Blöcke von dieser Hardware laden könnten.


    Und hinter Sammlungen wie TotalReplay steckt mehr Aufwand, als man das auf den ersten Blick denkt. Die Spiele wurden alle einzeln konvertiert. Da gibt es Enthusiasten (Cracker... :) ), die sich die Spiele einzeln vorgenommen haben - und die Spiele patchen. Da wird dann im Binary nicht nur der Kopierschutz entfernt, sondern auch alle Floppy-Zugriffe ersetzt - und auf ProDOS Datei-Funktionen umgebogen. Das Ergebnis ist dann ein neues Spiele-Binary, das unter ProDOS läuft. Solche Binaries lassen sich dann zu einer Spielesammlung zusammenfassen und in ein großes Festplatten-Image packen.


    Vielleicht kennt ja jemand die Technik im Forum?


    Sieht für mich so aus, als müssten das einfach zwei serielle 8bit Schieberegister (LS165) in Reihe sein. Der Ausgang QH/D7 des rechten Schieberegisters ist mit dem Eingang des linken verbunden. Alle parallelen Eingänge sind mit Masse verbunden - aber einige sind nicht eingelötet. Die 74LS haben alle interne Pullups an ihren Eingängen, d.h. alle nicht gelöteten Eingänge sind auf 1, die gelöteten sind 0. Man konnte so das identische PCB nehmen, und verschiedene Kodierungen einstellen - je nachdem welche Pins verlötet waren.


    Wenn der SWITCH Ausgang des Kassettenports auf 0 ist, werden die Werte der 16 Einänge in die Schieberegister geladen. Danach kann man SWITCH auf 1 setzen, und durch Clock Pulse auf dem WRITE-Port die 16bits einzeln heraustakten und über die READ Leitung lesen.


    Echter High-Tech Kopierschutz... (Ist das beim iPhone auch so gemacht? :D )

    Ja, aber ich habe noch keinen gesehen, bei dem das auch auf dem Chip stand. Selbst beim ///plus habe ich einen 6502A gefunden.


    Es gab aber tatsächlich einige davon. Hier ein Foto, dass zufällig gerade jemand in anderen Zusammenhang gepostet hat. Apple /// mit Synertek 6502B mit Datumscode "81/03". Da das schon das überarbeitete Mainboard ist, dass ab Dezember 1981 verkauft wurde, dürfte es aus einem der frühen Maschinen nach dem "Relaunch" des Apple /// stammen.


    Gestern mal den DAN ][ Controller aufgebaut, den ich auf der CC von MacFly als Bausatz bekommen habe.

    :love: Sehr gut, sehr ordentlich aufgebaut!

    Du kannst gleich mal das Firmware Update laufen lassen. Ich hatte die Controller schon vor einigen Wochen programmiert. Auf der SD-Karte ist schon eine neuere Firmware (3.3.2). Du kannst das Firmware Update direkt vom Controller aus laden und starten.


    Die weiterentwickelte Firmware ist derzeit nur in meinem GitHub. Auch die Doku ist dort deutlich erweitert:

    GitHub - ThorstenBr/Apple2Card: Apple II Peripheral Card that Interfaces to a ATMEGA328P for SD card storage
    Apple II Peripheral Card that Interfaces to a ATMEGA328P for SD card storage - GitHub - ThorstenBr/Apple2Card: Apple II Peripheral Card that Interfaces to a…
    github.com


    Der Schaltplan ist identisch zum Original - allerdings sind bei mir schon einige Pullup-Widerstände korrigiert. Ansonsten unterscheiden sich meine PCBs, da die Bauteilwerte direkt auf dem PCB aufgedruckt sind. Beim Original musste man jedes Bauteil separat auf dem Schaltplan nachschauen, wenn man eine Platine aufbauen möchte.


    Ich hatte für die CC einige Boards besorgt. Da mir das Löten dann aber zu aufwendig wurde, hatte ich die meisten einfach in Einzelteilen eingetütet und in komplette Bausätze verwandelt. Ich war mir nicht sicher, ob sich jemand für einen Bausatz interessieren würde - hatte die Teilnehmer so einer CC dann aber doch deutlich unterschätzt. Die Bausätze waren sogar viel beliebter... Oder wie es einer sagte "Ich will einen Bausatz. Mir ist egal, ob der etwas billiger ist. Ich will so oder so einen Bausatz, nicht weil ich sparen will, sondern weil ich es lieber selber bauen möchte." :D :thumbup::thumbup:


    Das andere was mich gefreut hatte war, dass es etwa genauso viele waren, die es für den Apple /// haben wollten, wie für den Apple II. Eigentlich sind Apple /// Besitzer sind ja seltener. Aber viele Apple II sind ja schon mit diversen anderen Lösungen versorgt. Insofern wohl doch nicht so überraschend, dass es viele Apple /// User einen wollten.


    Aktuell habe ich keinen (vollständigen) Bauteilsatz mehr, aber ich habe noch einige der edlen "goldenen" PCBs (ENIG beschichtet und mit angeschliffenen Slot). Nachdem der erste Schwung auf der CC wegging, werde ich nochmal Bauteile für die übrigen besorgen. Ich mache dann vermutlich auch mal im Marktplatz einen Eintrag...

    Der Apple /// hat ein Character-RAM (nicht ROM). Die korrekten Pixelmuster für das Alphabet muss das ROM beim Booten erstmal in das Character RAM laden, sonst wird nur Schrott angezeigt. Soweit kommt deine Maschine ja derzeit aber nicht. Sie kann daher keine normalen Zeichen anzeigen. Du siehst daher einfach Zufallsdaten, bzw. die Initialwerte, die halt nach dem Einschalten in den RAMs stehen. Und während du RESET drückst, gibt er kein Video-Signal aus. Daher ist dann kurz der Bildschirm schwarz.

    Bei der Video-Darstellung suchst du aber aktuell an der falschen Stelle. Du musst klären, warum der 6502 nicht anläuft - und noch nicht mal die ersten zwei Instruktionen ausführt. So lange das nicht geht, ist klar, dass er nur Schrott anzeigt.

    Das mit den Aufstellern wäre auch etwas für die nächste CC. Im Forum hieß es vorher mal irgendwann, es wären vom Verein ausreichend viele Aufsteller verfügbar. Am Freitagmorgen waren aber schon keine mehr zu haben. Also vielleicht doch in die FAQ aufnehmen, dass es zwar einige Aufsteller gibt, die aber nicht für alle reichen, und Teilnehmer sich besser selbst welche mitbringen, wenn sie wert darauf legen.