Beiträge von hubersn

    Zitat

    Grenze müßte irgendwo bei 4GByte (evtl. auch nur 2?) liegen.

    RISC OS 3.5 und früher: 512 MiB pro Laufwerk bzw. Partition. RISC OS 3.6 und später: 256 GiB. Aber vor RISC OS 4 (aka "+"-Format-Filecore aka "new Filecore" aka "Big Dir Format") war die Platzeffizienz unterirdisch schlecht, so dass mehr als 8 GiB selten Sinn machen, es sei denn man hat hauptsächlich sehr große und vor allem wenige Dateien auf der Platte.


    Zwei moderne Ausnahmen: FAT32FS schiebt dieses Limit noch ein Stück weit raus, weil es Pseudo-Partitionen über SCSIFS verwenden kann. RISC OS 5 neuerer Bauart kann 4K-Sektoren, was das Limit dann (Laufwerk muss aber 4Kn sein!) auf 2 TiB erhöht.


    Gruß

    hubersn

    Mit Zusatzplatinen gibt es fuer den Pico zwar schon eine BBC Micro Emulation mit Videoausgabe,

    aber fuer mich spannender ist diese Version, die den Standard Raspberry Pi PIco (also den Mikrocontroller - nicht die Linux-Platine a la Zero)

    Blasphemie! Wenn man von BBC BASIC redet, ist es natürlich "die RISC OS-Platine a la Zero". Natives ARM BBC BASIC.


    Ob's allerdings viel schneller ist? Faktor 124 mit einem Cortex-M0 mit 133 MHz ist schon eine Menge.


    Gruß

    hubersn

    Die Unipod-USB-Implementierung über den Simtec-Stack ist eher sparsam. Chipsatztechnisch ist da ein ISA-Philips-Chipsatz vergewaltigt, USB 1.1-only mit wechselhafter Kompatibilität mit diversen real existierenden Geräten.


    Der eingebaute HID-Driver kann m.W. nur Tastatur und Maus, Joystick wird nicht unterstützt. USB-Sticks sind "hit and miss" und erfordern eine kundige Hand bei dieser frickeligen MassFS-Konfiguration. Auch die eigene Treiber-Implementierung ist nicht besonders einfach, die API des Castle-Stacks ist da einfacher.


    Ein paar Details dazu hier: https://www.riscos.info/index.php/Simtec_USB_technical


    Netzwerk und IDE sind kompetent, aber die 100 MBit/s kann man über den lahmen Podule-Bus eh nicht mal zur Hälfte nutzen, und für IDE gibt es bessere (und ggf. auch schnellere) Alternativen.


    Für die alten Kisten wäre es natürlich super, wenn es mal so ein All-In-One-Podule geben würde, Multi-I/O mit USB und PS/2 und IDE und Netzwerk...und am besten auch Floppy, weil die liegt im A5000 ja im gefährdeten Akku-Einzugsbereich...mal sehen, vielleicht erbarmt sich mal einer der Stardot-Bastler.

    Rein formal hat das CDFS m.E. 4 Hersteller unterstützt und da auch nur ein paar wenige Laufwerke. SONY und HITACHI waren da dabei. Yamaha ziemlich sicher nicht.

    Wenn hubersn sagt, daß Plextor gehen muß, dann wird das wohl so sein.

    Die mitgelieferten CDFSSoft-Treiber von EESOX werden in diesem Falle gar nicht aktiv, weil die spezifisch auf Gerätenamen wirken. Der CDFSSoftToshibaEESOX z.B. auf das 3201 und das 3301 - wenn die noch jemand hat, ist er echter Sammler :)

    Es gab mal ein Patch-Programm, um dem CDFSSoftChinonEESOX ein beliebiges anderes Laufwerk unterzujubeln - der Chinon-Treiber hat mit fast allen frühen SCSI2-CD-ROMs funktioniert, das war aber mehr ein Betriebsunfall bzw. -zufall.

    Im vorliegenden Fall wird aber der vom SCSI-Podule mitgelieferte CDFSSoftSCSI2_CT die Kontrolle übernehmen, und der ist sehr breit kompatibel, mit dem Plextor hatte ich den jahrelang im Betrieb (im Wechsel mit Power-Tec und EESOX), und er steckt auch in RISC OS 4.02, da sollte es wirklich keine Probleme geben. Auch nicht mit dem Yamaha-Brenner. Aber der ist recht stromhungrig, ob der vom altersschwachen A5000-Netzteil genügend Saft bekommt, würde ich in Frage stellen. Am besten sind externe SCSI-Geräte mit eigenem Netzteil, aber den Luxus hat nicht jeder vorrätig.

    Zu EtherH: EtherH16 ist für Deinen Fall korrekt - das "8" bezieht sich auf "8-Bit-Mini-Podule", also die internen Podules für A3000, A3010, A3020 und A4000. Das "16" bezieht sich auf Standard-Podules, die 16bittig die Daten übertragen. Also externes Podule beim A3000 und interne Podules bei A3xx/A4xx/A540/Rxxx/A5000/RiscPC.

    Zum CD-ROM hatte ich über Weihnachten noch n bissl bei meinem Bruder mit seinen Laufwerken getestet, aber kein einziges zum laufen bekommen. Immer der selbe Fehler vom CDFS. Was aber auffällt: wenn ich in die Diagnose-Software vom SCSI-Controller schau seh ich beim CD-Laufwerk immer ein Volume in der Größe der eingelegten CD. Es scheint also am CDFS zu liegen... gibt es eine Möglichkeit das auszutauschen gegen eine andere Version?

    Was Du siehst ist der generische CDFS-Fehler, der erst mal nach "komische CD, verstehe ich nicht" riecht, aber auch "Medienfehler" sein kann oder "Der Treiber passt nicht zum Laufwerk". Mit dem Plextor CD-ROM kann der Castle-SCSI2-CDROM-Treiber vom Podule auf jeden Fall zusammenarbeiten, da bin ich ganz sicher. Wenn die CD gepresst un nicht gebrannt ist, dazu Single Session, Mode 1 (also nicht aus versehen Mode 2 Form 1...), dann sind die Chancen maximal groß, sie lesen zu können.

    Eine neuere Version von CDFS wird gar nichts helfen, die sind alle gleich schlecht, also zumindest alle, die noch auf dem A5000 funktionieren...

    Ich habe irgendwo noch ein kleines BASIC-Tool, das einen Daten-Track von einer CD mittels SCSI-Kommandos (also ohne CDFS anzufassen) auslesen kann, das wäre ein guter Test wo genau das Problem liegt. Wenn es da auch Probleme gibt - Kabel, Terminierung, Stromversorgung, oder alles drei.


    Das was CDFS bei cddevices reported, ist das, was vom SCSI INQUIRY-Kommando kommt, das ist also "physisches Medium", es bedeutet nicht, dass CDFS irgendwas vom logischen Format auf der CD versteht.

    Ich hatte mal für die Hobby+Elektronik auf dem AUGE-Stand ein Festplatten-Image für einen A310/4MB/ARM3 erstellt mit vollem Internet-Zugriff über Ethernet, ich glaube das war 2007. Keine ANT Internet Suite, sondern normalen Acorn IP-Stack und "diverse Programme" von FTPc und FreeTerm über Browse bis Fresco, ArcWeb und Webster.

    Das Problem heutzutage ist tatsächlich, noch Gegenstellen zu finden, die man nicht selbst betreibt... HTTP und nicht HTTPS, nacktes FTP, echtes Telnet...und vielleicht noch Gopher :)

    Irgendwo muss es eine CD geben mit dem ganzen Zeugs, und der Mirror von Stuttgart FTP müsste auch noch eine gute Quelle sein.

    Der Fehler schaut mir nicht nur nach dem klassischen "CMOS-ClockChip kaputt"-Problem aus sondern auch nach einem eventuell teilweise kaputten 665 bzw. dessen Umgebung aus. D.h. serieller Port, paralleler Port, IDE, Floppy, Tastatur, Maus sind in Gefahr.


    Im Stardot-Forum haben schon einige Bastler Rechner in diesem Zustand und schlechteren Zuständen (bootet gar nicht...) wiederbelebt. Grundsätzlich muss man erst mal mit dem Schaltplan in der Hand und dem Durchgangsprüfer alles durchchecken, was vom 665 ausgeht. Da ist alles in der Nähe verdächtig, und das ist extrem fitzelig zu löten. Der 665 ist wohl auch etwas empfindlich was statische Aufladung angeht, also Extra-Vorsicht. Wenn man sowas noch nie gemacht hat - sehr schwierig. Ich traue mich an die SMD-Teile nicht ran, ich habe bisher nur Risc PCs rund um den PFC gefixed, das sind aber nur ein paar Drähte im Zweifelsfall.


    Die Frage ist, ob ein "normaler" A7000 es wert ist. So furchtbar selten ist der ja nicht, und wenn Du die Platine gut gereinigt hast, wird der Zustand ja nicht schlechter und Du kannst ihn auf Lager legen, bis er in einigen Jahrzehnten tatsächlich selten geworden ist.


    Gruß

    hubersn

    Arculator ist das Mittel der Wahl für "classic Archie" unter Windows und Linux.


    http://b-em.bbcmicro.com/arculator/download.html


    Zweite Wahl ist ArcEm.


    http://arcem.sourceforge.net/


    Windows-Only gibt es noch RedSquirrel. Für RiscPC und A7000 ist RPCEmu unter Linux und Windows erste (und einzige kostenlose/freie) Wahl.


    Unter RISC OS selbst gibt es spezifisch für Spiele ADFFS (eine Mischung aus Emulator und Patching und JIT und Hypervisor) und für "alles" ArchieEmu.


    Ich versuche, den aktuellen Stand auf meiner Seite hier http://riscosblog.huber-net.de/emulatoren-fuer-risc-os/ immer festzuhalten (inklusive der kommerziellen Optionen), hinke aber schon wieder hinterher :(

    RISC OS hat keine WLAN-Unterstützung. Im Moment arbeitet man gerade an einer aktuellen Portierung des BSD-IP-Stacks, dann sollen die WLAN-Dinge kommen. Nach der Geschwindigkeit der letzten Jahrzehnte zu urteilen, wird das in 3-4 Jahren zur Verfügung stehen :)


    Es gibt verschiedene "Workarounds", vom Pi-Wifi-HAT von Elesar über die typische LAN-WLAN-Bridge bis zu - wenn es nur "drahtlos" und nicht unbedingt "WLAN" sein muss - USB-UMTS-Sticks. Aber eben nicht das naheliegende: das integrierte WLAN in jedem Pi seit dem 3er.

    Das eigentlich Spannende ist ja auch, daß sie dann - also iNTEL - mal quasi zufällig an den StrongARM gekommen sind, damit ihren eigenen RISC Chip ( da schon i960 ) ersetzt haben, und anschließend aber auch das wieder abgestoßen habe ( Marvell ).

    "Zufällig" ist schön gesagt - das "Patent Settlement" mit DEC damals war schon ziemlich teuer. Und die DEC-Ingenieure, die StrongARM- und Alpha-Know-How hatten, sind ja dann direkt getürmt - schien gegen die Ehre zu gehen, für den Feind zu arbeiten. Was das Aus für den "so gut wie fertig"-StrongARM2 aka SA1500/1501 bedeutete.

    Und Intel hat ja nur die PXA-Krücken an Marvell weiter vertickt. Die IOP- und IXP-XScales haben sie ja moderat weiterentwickelt, Der IOP321 steckte im IYONIX pc und hielt die RISC OS-Fraktion bei Laune, bis das BeagleBoard kam. Der IOP342 wäre beinahe im IYONIX pc 2 gelandet, aber der hat es dann nicht übers wir-denken-drüber-nach-Stadium hinaus geschafft.


    Eingestellt wurde das XScale-Zeugs dann mit der Aussage, dass ja demnächst eine sparsame x86-Variante käme, die das alles ablöst. Auf die warten wir noch heute.

    Waren die nicht alle auf der "RISC User in a Nutshell"-CD? Also natürlich nicht physisch :)

    Fehlendes USB3 ist unter RISC OS nicht wirklich schlimm, wichitger ist, daß das 'neue' Ethernet für den geänderten Chip gut läuft - das wird man sehen. Woran es immer noch hakt, ist die fehlende Core Unterstützung - d.h. der QuadCore Chip mutiert zum SingleCore. Und es ist auch kein beschlußfähiger Ansatz in Sicht, wie das mal geändert werden könnte.

    USB3 hätte bei den Massenspeichern halt schon dramatische Vorteile, und bei einigen Dingen - RISC OS bauen, große portierte Software mit vielen shared libs starten (z.B. Otter, Iris...), Blu-Rays brennen - hat der Pi 4 eben keine Chance gegen die S-ATA nutzenden ARMX6 oder Titanium.


    Das Gigabit Ethernet des Pi 4 läuft sehr gut und stabil, Bremse ist hier der IP-Stack von RISC OS, der vor allem bei schlechten Latenzzeiten unglaublich langsam wird. Die einfachste Möglichkeit, das Internet unter RISC OS zu beschleunigen, ist einen Proxy-Server im lokalen Netz dazwischenzuschalten.


    SingleCore ist zwar schade, aber es gibt so unglaublich viele Ecken, die so unglaublich viel einfacher zu beschleunigen wären - I/O, VFP konsequent nutzen, GPU-Funktionen verwenden - MultiCore ist halt eine tiefgreifende Änderung, der daraus resultierende Testaufwand ist riesig und die zu erwartenden "Verlustliste" bei der Bestandssoftware droht im Hintergrund. Ein Minimalmodul zur Nutzung der anderen Cores gibt es ja inzwischen, aber es ist halt nicht OS-transparent. Wie auch, bei einem OS das weder Prozesse noch Threads kennt.

    Das mit dem CD-DVD-Burn ... nun ja, steht ja immer mal, daß da noch was kommt.

    Mach mal lieber eine Marktanalyse, ob das überhaupt noch jemand benutzen - respektive kaufen - würde. Vielleicht macht es einfach mehr Sinn mal das CD-Burn nochmal intensiv auf Fehler abzuklopfen und evtl. ein komplett neues interessantes "Projekt" anzufangen.

    Es gibt da ja durchaus noch andere RISCOS Sachen, wo ein guter Programmierer Wunder bewirken könnte.

    Diesmal wird es wirklich ein neues Release von CDVDBurn geben, versprochen. Ich liege in den letzten Zügen, und ich habe ausreichend kompatible Laufwerke auf allen relevanten Plattformen durchgetestet.


    Die Marktanalyse, ob es noch ausreichend Interesse gibt, läuft einerseits dauernd durch Bestandskunden, die nach Neuerungen fragen und Zahlungsbereitschaft signalisieren. Andererseits über die Mailingliste, da gab es ausreichend positive Rückmeldung. Und erfahrungsgemäß kommt die Hälfte der Kundschaft aus dem unbekannten Bereich, Namen die man noch nie oder schon lange nicht mehr gehört hat.


    Finanziell lohnen tut sich die Sache nur begrenzt, weil viel Investition in Hardware erforderlich ist und das Testen ziemlich aufwändig ist. Wenn ich da meinen normalen Stundenlohn anlege...oh je. Hauptarbeit ist immer Anpassung an neue Plattformen (S-ATA, USB) und neue Laufwerke. Der Rest ist Kleinkleckerleskram.


    Meine nächsten Projekte werden nicht unter RISC OS laufen, aber für RISC OS nützlich sein. Die Entwicklertools unter RISC OS sind einfach viel zu schlecht, das nervt mich die ganze Zeit. Und daran was zu ändern...das ist ein Fass ohne Boden. Und ganz und gar nicht meine Kernkompetenz. Die RISC OS-Welt hat sich ja letztlich auf C als Programmiersprache festgelegt, und das ist nun eine Sprache die ich wirklich abgrundtief hasse.

    Der Schneider hat eine abgerissene Taste, die ist aber zu Kleben, da die Teile vorhanden sind. Netzteil fehlt mir da leider auch.

    Die CPC-Serie hatte das Netzteil ja stets im Monitor integriert. Es gab auch ein externes Netzteil (MP-1 mit 5V für CPC 464 oder MP-2 mit 5V und 12V für CPC 664 und CPC 6128), dessen Hauptfunktion aber der eingebaute TV-Modulator war für den Direktanschluss über Antenne an ein handelsübliches TV in absolut grauenvoller Qualität und selbstverständlich mit Mono-Ton. Nicht, dass übliche CPC-Software die Stereo-Natur des Soundausgangs besonders gut ausgenutzt hätte...


    Ein CPC 464 kommt mit einem 2A 5V-Netzteil aus mit "normalem" Hohlstecker 2,1mm. Nur stabilisiert muss es sein, sonst wird der CPC ungut.


    Gruß

    hubersn

    So ein RiscPC ist aber ein ausgesprochen schönes Fass, ob mit oder ohne Boden :)

    Die Preise der Engländer sind aber wirklich zum Abgewöhnen. Es ist dummerweise noch eine recht große Nutzergruppe aktiv, die wenig Zeit, wenig technisches Verständnis aber ausreichend finanzielle Mittel hat. Mit anderen Worten: pensionierte Lehrer. Die mit Abstand größte verbliebene Nutzergruppe alter Risc PCs.

    Ob das CD-Laufwerk über SCSI sichtbar ist, kannst Du per

    *devices

    von der Kommandozeile aus testen.


    Ob CDFS prinzipiell das Laufwerk erkannt hat, kannst Du per

    *-cdfs-cddevices

    prüfen.


    In RISC OS 3.1 ist kein CDFS-Treiber mit an Bord, d.h. CDFS kommt auf jeden Fall vom SCSI-Podule-Flash-ROM, genau wie der CDFSSoftSCSI2_CT normalerweise - wenn also der Vorbesitzer nicht am Flash-ROM rumgepfuscht hat, sollte es hier kein Problem geben.


    Aber wir können auch mal was mit CDBurn testen wenn Du willst, das arbeitet low-levelliger als CDFS und kann so mehr zum Zustand des Laufwerkes aussagen (vor allem bei den Fehlermeldungen im Log).

    Die DIskette von SCSI Controller lässt sich leider auch nur noch teilweise lesen... grml. Vor allem das Setup-Utility mag nicht. Wo hab ich denn die beste Chance evtl. an ein Disk-Image für den Castle SCSI II Controller zu kommen?

    Hier sollte es passende Archive geben, rauf auf eine 1,44MB-Diskette und ab in den A5000:

    http://chrisacorns.computinghi…G/Castle_3216bitSCSI.html


    Ich habe noch die Originaldisketten im Bestand irgendwo, aber bis ich die finde...


    Gruß

    hubersn

    Speziell CPU´s habe ich auch das ein oder andere "Konvolut" aufgekauft ... Wenn man dann mal 20 PC´s vom Schrott bekommen hab, war das immer das spannendste - was für ne CPU ist drin .. Gerade die alten Keramik-CPU´s find ich klasse - und wenn man dann mal eine gefunden hat, die nicht von Intel oder AMD (wobei AMD auch schon selten vorkam) war, war das ein echter Glückfall. Irgendwann hatte man das Gefühl, das passiert nur noch alle 25 - 50 Rechner ...

    Für "Exoten" sind die Acorn Risc PC-x86-Karten eine recht gute Adresse. TI 486SX-40, IBM Blue Lightning DX2-66, TI 486DX4-100, IBM 5x86, Cyrix Cx486 DX2-80...


    Die alten PC-(Mini)Podules für Acorn Archimedes und Co. hatten auch merkwürdige Cyrix 486SLC irgendwas drauf. Nur die allererste war noch "Intel Inside" mit einem echten i386.


    Aber wehe Du schlachtest eine von denen nur wegen der CPU :)


    Gruß

    hubersn

    Der Rechner hat (nur) 4 MB RAM, eine 200 MB IDE Festplatte, ein Cumana CDROM, und läuft unter Risc OS 3.5. Natürlich waren weder Maus noch Tastatur dabei, aber zum Glück hatte ich noch eine serielle Genius 3-Tasten-Maus (Aktivierung mit "Configure Mousetype 1") und eine geeignete QWERTY PS/2 Tastatur (Risc OS 3.5 bietet ja keine internationalen Einstellungen). Sogar die gefederte Laufwerksklappe funktioniert noch :).

    Du bewirbst Dich damit für den Titel "Glückspilz des Jahres" - funktionierende Klappe in einem Risc PC UND auch noch eine serielle Maus gefunden. die mit dem Standard-Serial-Mousedriver von RO 3.5 funktioniert, das kommt nicht oft vor!


    Gruß und viel Spaß mit der "Reservekiste"

    hubersn

    Ich hoff mal dass ich hier ein paar Leute finde die mir mit ihrer Erfahrungen was die Archimedes betrifft etwas weiter helfen können.

    Frag' einfach, wir wissen dann schon was dazu :)


    Du kannst ein wenig in meinem Blog stöbern (Mischung aus aktuellen und Retro-Dingen rund um RISC OS): http://riscosblog.huber-net.de/


    Ich habe auch mal den Versuch gemacht, ein paar zusammenfassende Worte für Neu- und Wiedereinsteiger aufzuschreiben, wäre super wenn Du mir da Feedback geben könntest welche Themen Dich vertieft interessieren würden, dann kann ich das ergänzen - im Moment hat das Dokument ewigen Draft-Status: http://riscosblog.huber-net.de…sc-os-fuer-neueinsteiger/


    Zum Thema Datenaustausch plane ich schon länger eine Übersicht, weil das quasi bei jedem Neu-/Wiedereinsteiger bei den alten Kisten Thema ist. Im Moment halte ich "Parallel-Port-Zip-Laufwerk" für alles ab A5000 für den einfachsten Weg, der überall funktioniert. SCSI-Zip geht natürlich auch, und für neuere PCs ohne Parallel-Port eben USB-Zip als "Quelle", um die Downloads vom PC auf den Archie zu schaufeln.


    Fürs Joystick-Interface empfehle ich Selbstbau -das Interface von Ian Haylock für den Parallelport bietet zwei Ports für klassische Digitaljoysticks. Bauanleitung mit Software von meiner Webpräsenz: http://legacy.huber-net.de/Joystick.zip


    Nun viel Spaß mit dem A5000, ist eine tolle Maschine.


    Gruß

    Steffen aka hubersn

    Zweimal Gemini II, das ist schon mal gut. Viel besser als die IBM 5x86 wird es nicht.


    RAM ist begrenzt auf 32 MB, egal wieviel im Risc PC steckt. Gute DOS-Versionen sind PC DOS 6.3, MS DOS 6.2x und PC DOS 7.0 (das war bei den Gemini II-Karten mit gebundelt).


    Wenn eine SCSI-Karte im Risc PC steckt, kann mit PCPro 3.0x jedes SCSI-Device direkt von PCPro aus angesprochen werden - damit funktionieren z.B. unter DOS und Windows normale Brennprogramme mit jedem CD-Brenner. War cool, weil man konnte auf der RISC OS-Seite den Datenstrom mitschneiden...auf der x86-Seite gab es den ASPI-Treiber dazu. War eigentlich eine 3rd party-Geschichte von Andreas Walter, die Aleph1 dann aber in PCPro integriert hat.


    Der Grafiktreiber für Windows ist essentiell, sonst ist das furchtbar langsam. Windows 95 funktioniert, nicht jedoch Windows 95 OSR 2.5 und spätere Versionen (angeblich soll Windows 98 First Edition funktionieren, habe ich aber nie hingekriegt). Es gab auch mal eine experimentelle Linux-Version für die PC-Karte, andere OSes wie OS/2 oder NT funktionieren nicht.


    Irgendwo auf einem Backup habe ich noch drei oder vier DOS-Images mit allem von MS DOS über Windows 3.1 bis Windows 95. Aber wo?


    Soundemulation (Soundblaster-kompatibel) war sparsam für viele Spiele, es gab kommerziell von R-Comp "PC Sound Pro" als Upgrade. 16bit-Sound ist aber Voraussetzung im Risc PC.


    Ethernet wird unterstützt über "Network Links". Ist bei der freien PCPro-Version mit dabei. Funktioniert vor allem im Zusammenspiel mit Ethernet-Karten mit zwei virtuellen Interfaces prächtig. Tut so als wenn es NE2000-kompatibel wäre.


    Die Emulation von seriellem und parallelem Port ist sehr gut, da funktoniert praktisch alles inklusive Paralle-Port-ZIP-Laufwerke. Über seriell, ZyXEL U1496E+ und Windows 3.1 mit Trumpet Winsocket und handgedengeltem SLIP-Einwählskript für die Uni habe ich damals mit Netscape Navigator Gold 3 das Internet unsicher gemacht...


    Gruß

    hubersn

    Ein OAK neueren Datums, sehr schön. Das Original-OAK hat nur mit RISC OS 2 gut harmoniert, aber dieses hier (Issue 2 von 1989, sogar mit CDFS-enabled-Firmware wenn man dem Bebbr glauben darf) passt perfekt in die klassische Archimedes-Welt.


    Ist doch intern wie extern Pfostenstecker? Zumindest mein SCSI2SD würde da prima dranpassen mit einem kurzen 50pol. Flachbandkabel. Aber ich glaube das war eins der Podules, wo man entweder intern oder extern anschließen konnte, weil der Terminator fix war.


    Gruß

    hubersn

    Ich hab ihn zum Apothekenpreis bei eBay reingestellt. Wegen zu vieler Retroeskapaden brauch ich das Geld (siehe „Mein neuestes etwas“). Und jetzt stell ich ein paar meiner eBay Impulskäufe wieder ein... Ich weiss wirklich nicht, warum ich bei so vielen Rechnern, die ich schon habe nochmal zugeschlagen habe...:fp:

    Der Preis ist doch harmlos. Ohne Tastatur, ohne Maus, damit geht er quasi sicher in gute Hände über :)


    Einer der Screenshots ist falsch, zeigt RISC OS 3.1. Der Platinen-Shot zeigt aber klar RISC OS 2, so wie die anderen Screenshots.


    Gruß

    hubersn

    Oh, schön. Aber die passt besser in einen Risc PC, weil im Herzen ein DEBI-Podule (32bit DMA-fähig).


    Der leere Sockel ist hier für ein "Not-ROM", wenn es das Flash-ROM zerbröselt hat.


    Bin gerade nicht sicher, ob die Cumana DEBI-Podules auch RISC OS 3.1-taugliche Firmware hatten. Ich muss mich mal auf die Suche machen, irgendwo habe ich eins. In den Risc PCs bevorzuge ich allerdings Castle STORM, Power-tec Ultra-SCSI3 und Eesox. Aber jedes hat da so seine individuellen Stärken und Schwächen. Das Cumana war schnell, sehr früh am Markt (erstes echtes 32bit-DEBI-SCSI-Podule), und hatte brauchbare Software. Schlechter CDFS-Treiber. Schwache Streamer-Unterstützung. Wechselplattenunterstützung (Syquest, Zip) durchwachsen. Aber für Platten und Brenner sehr solide.


    Vielleicht hattest Du nur ein Problem mit Unplugged-Modulen, die RISC OS-Kisten speichern das pro Podule-Slot im CMOS, da muss man manchmal mit einem beherzten rmreinit nachhelfen.


    Gruß

    hubersn