Beiträge von geekdot

Ich habe mir einen Classic II zugelegt. Der fehlte noch

Was aber auch fehlte, war eine FPU - wie Ihr sicher auch, kann ich "ungestopfte" Sockel/Slots nicht ertragen - und auch wenn der Classic II busseitig Nachteile hat, kommt er mit einer FPU relativ dicht an einen SE/30 heran.
Nun hat der Classic II (und der baugleiche Performa 200) einen speziellen FPU/ROM Slot, der sich so nur in diesem Modell findet. Apple empfand es nie für notwendig, hier eine Karte anzubieten.

Ich schon

Hier also mein neuestes Werk

Passt schnuckelig rein...

...und findet sich:

Die Karte kann den 16MHz Bustakt nutzen oder (per Jumper) über einen externen Quarzoszillator (DIP8, DIP14 oder SMD) asynchron getaktet werden. Es ist ein hochwertiger TexTool Sockel verbaut - auf die fancy Buchsenleiste, die Apple damals vorsah, habe ich aus Kostengründen (12€!) verzichtet und ein standard Bauteil verwendet - passt auch so prima.

Da ich nur eine Karte brauche biete ich Euch den Überschuss an. Ich denke hier finden sich eher die Zielgrüppler als auf dem Marktplatz, oder?

Es gibt 3 Varianten:
"Naggisch" - Du besitzt eine PLCC FPU und optional einen Quarz und Lötkolben um diesen einzulöten

"mit Käfer" - Eine 40MHz 68882 kuschelt sich im Sockel, kann direkt losgehen... einfach so mit 16MHz oder einem Quarz aus Deiner Schublade.

"Alles außer scharfe Sauce" - Alles drauf, FPU und 40MHz Quarz.

VG Axel

Edit : Preise entfernt - bitte stelle solche Angebote im Marktplatz ein. MfG, Cartouce

Edit: Das Angebot im Marktplatz ist hier: Mac Classic II FPU Karte (yalsi)

Zitat von Jedi04

[...] vielleicht erstmal die Anschlüsse vom Expansionsport richtig reinigen. Vielleicht ist es ja nur ein simples Kontaktproblem vom Diagnosemodul?!

Hatte ich auch schon gedacht und fast gemacht... aber siehe unten.

Zitat von vossi

Als ich nun ein C128D (C128) Board testen wollte hatte der Test auch solche Probleme.

Erfolg hatte ich dann mit dem 789010JB-ROM - allerdings lief es nicht im Sockel, sondern nur auf einer C128-Steckkarte!

Das 789010JB auf Modul springt bei mir direkt in den C64 Modus - strange.

Aber bei meiner Recherche stieß ich auf einen Post von Bo Zimmerman - ich bin also nicht allein mit dem "Phänomen" (und nicht der einzige Irre, der sowas nachgeht ).
Glücklicherweise hat er nicht nur (vergeblich) die PLA getauscht sondern sich auch schon akribisch durch die div. Bus'e des C128 gefräst, um letztendlich 4 ICs auszumachen, die hier mit reinspielen könnten. Nach deren Tausch lief bei ihm auch die Diagnose sauber durch.

Ich werde also erstmal in die Richtung testen - bis auf das SRAM ist alles vorhanden. Vielleicht hab' ich ja Glück.

Hallo Zusammen,

Nachdem mein 8296 dank Eurer Forenhilfe wieder rennt wie Schmidts Katze kam jetzt mein C128 an die Reihe (Ja, ich arbeite mich durch den Keller).

Der flache Bolide tut im Prinzip wie er soll, sprich Basic 7.0 kommt hoch und auch der C64-Teil tut wie er soll. Floppy lädt. Man(n) könnte also zufrieden sein...

Aaaaaber man(n) will es ja immer genau wissen, also rein mit dem Diagnostic Modul (785260) und das will so gar nicht - auch als 789010JB direkt in U36 bringt es ähnlichen (Miß)erfolg, der mal so aussieht:

...oder nach verschiedenen Resets auch mal so:

...also mit crash in den Monitor (Der auch noch funktioniert).
Zur Gegenprobe: Der C64 Diagnostic (Rev 586220++) läuft nach einem initialen Reset meist nur bis zum RAM Test 1, manchmal auch 2... und hängt dann z.B. so:

Die lustigen Farbverschiebungen und der Zeichenmüll im C128-mode deuten für mich irgendwie in Richtung PLA, was ja beim 128er echt doof ist

Zudem enden ja sowohl /EXROM, /ROMH, /ROML als auch /ROMF in der 8721... grmbl...

Aber bevor ich den langen Käfer jetzt auf den blauen Dunst hin auslöte und für "teuer Geld^tm" ersetze, würde ich gerne noch mal auf Euren weitreichenden Erfahrungsschatz zurückgreifen.
Ich freue mich also also wie immer sehr über Eure Kommentare, Tips und Tricks.

Danke & Grüße,
Axel

Zitat von x1541

Zitat von geekdot

Was könnte Drive 0 denn so haben ?

Im schlimmsten, leider häufigen Fall Kopf defekt. Den erst mal durchmessen, und dann weiter sehen.

Ha! Ein Stecker war falsch draufgefriemelt... wer das wohl war? (Klassisches Layer 8 Problem ...)

Jetzt muss ich nur noch dem (mittlerweile sporadischen) Reset-nach-Einschalten-benötigt Problem auf die Spur kommen...

And the journey continues...

Da ist ja auch noch eine 8250LP. Beide LW brav ge-recapped, Mechanismus geschmiert... keine Morsecode. So weit so gut.

Aber wie soll's anders sein..

Drive 0 (JU-570-2) tut nicht -> Läuft, rattert, schwitzt, ist bemüht... file not found.
Drive 1 (interessanterweise das längere JU-570) funzt. Ließt und... schreibt. Leider Warum leider?

Vor ca. 100 Jahren, als ich die Combo erstand, hat mir ein netter User eine LOS-96 Diskette geschrieben und geschickt (warst Du das evtl. Toast_r ? Ist eine EDIXA 2D) - die habe ich gehütet und gepflegt .
Nun war sie also endlich dran, und siehe da, Drive 1 konnte sie lesen:

...uhhh "8296d diagnostic", das klingt praktisch. Starte ich mal...

[Währenddessen: Rrrrrrrrt, rrrrrrrt, rrrrrt....] toll, sieht ja alles Piko aus! Wie komme ich denn hier raus? ESC, Run/Stop, Ctrl-C... damn, egal, Reset.

Nuja. Und seitdem is' meine schöne Floppy hin. Total. diR verhackstückt, wahrscheinlich BAM auch... ::

In tiefer Trauer daher 3 (weitere) Fragen:

• Kann mir hier jemand evtl. wieder eine LOS-96 Disk mit all den schönen Dingen bauen?
• Warum himmelt der Test Disketten?
• Was könnte Drive 0 denn so haben ?

Wie immer: 1000 Dank für Eure Hilfe!

Zitat von geekdot

yup - einer ist ja auch erstmal kein Akt... wird aber wohl erst morgen was.

Taadaaa:

Dabei noch die beiden 7805 gegen Neue getauscht... hat den Zwangsreset leider nicht behoben. Da VR1 ja "komisch" ist, habe ich auch mal C6 ausgelötet und gemessen: Mein LCR sagt 65uF (statt der aufgedruckten 47uF) - C7, C11/12 (hinten beim RAM) geben mir sogar 160uF (in-system gemessen)... Kapazitätserhöhung bei gealterten Kondensatoren ist eher seltener, aber entsteht wohl durch den verringerten Isolationswiderstand... kann da evtl. einer von Euch netten Jungs nachmessen?
(Werde mal ein paar von den Elkos ordern - irgendwie hab' ich nie das da, was ich gerade brauche )

Aber jetzt erstmal ein dickes Danke an Euch alle für's mitgrübeln und all die guten Tips!

Zitat von x1541

War der RAM test mit dem Huckepack?

Was passiert wenn du ein an anderes RAM behuckepackst? Auch Probleme beim einschalten?

Ja... bei anderen RAMs auch... aaaaber: Jetzt braucht die Kiste jedes Mal "Starthilfe"
Sowas kenn' ich wenn nicht genug Sprit im Vergaser ankommt. Also nochmal die 7805'er messen und siehe da: VR2 bringt noch passable 4.99V aber beim Messen von VR1 resettet die Dame. Reproduzierbar. Verdammt, das Ding zerbröselt mir unter den Händen.

Zitat

Würde den RAM CHIP jetzt einfach Sockeln und tauschen. Da der Chip die kompletten ersten 32/64kB abdeckt kann er sehr wohl das Adressmuster erzeugen.

yup - einer ist ja auch erstmal kein Akt... wird aber wohl erst morgen was.

Zitat von x1541

lass dich von dem 00 00 00 / FF FF FF Muster im Speicher nach dem Einschalten nicht ins Bockshorn jagen. Dieses Muster ist normal,...

Alles klar - dann nehm' ich das erstmal so hin - ist ja auch ganz hübsch anzuschauen.

Zitat

vielleicht geht es erstmal ohne, mit der Huckpackmethode. Ich stecke dazu ein gutes DRAM in einen Präzisionssockel und stülpe den über einen eingelöteten, zu testenden, DRAM. Dann einschalten und prüfen. hält normalerweise bombenfest. Oft kann man so ein teildefektes DRAM "übersteuern".

Prima Idee - das kommt meiner Faulheit entgegen Leider brachte das auch nix - außer daß der PET nun einen Reset nach dem 1. Einschalten braucht, damit er hoch kommt. Ohne huckepack-RAM kommt er direkt.

Da das HRG Emu board schon mal draußen war, fielen mir die beiden bei mir gesockelten '244 Buffer (UC10/UD8) auf - verdächtig, sind also wohl schon mal getauscht worden... beide mal getestet, sind ok OK.

Dann habe mal einen RAM-test für Arme gemacht... sehr konsistent, diese 0x10. Immer in zwei aufeinanderfolgenden bytes.
Mangels hex$() etwas mühselig zu lesen:

Also in den Adressen $500/$501, $700/701, $900/901, $B00/B01,...$4300/4301 (und sehr wahrscheinlich bis zum Ende des RAMs) steht die $10 alle 512 bytes in Stein gemeißelt.
Es ist m.E. also eher ein Adressierungs-, denn Speicherproblem. Und zwar mit A8 (und A0 wenn A8 mitspielt...)
Ein Blick in den Schaltplan verrät mir, daß A8 und A0 am selben MUXer (UB9) hängen - aber den hatte ich ja schon getauscht. Und wenn ich das richtig lese bekommen die BA0-15 von UD8/UC10, welche ich ja auch schon überprüft habe.

Zitat von x1541

ist es nicht bit 4?

Das scheint auf dem Datenbus hin und wieder zu "flattern" - bit 7 könnte auf dem Adressbus für Verwirrung sorgen, denn immer wenn es "dran" ist kippt 6-0 um... (siehe die 128byte Lücke ab $xx80). Daher war meine Vermutung defekter MUXer gar nicht so doof - aber die hatte ich ja schon testweise getauscht.
Ich wollt's mir eigentlich ersparen, aber dann werd' ich wohl morgen mal die unteren 64K sockeln...

P.S: Gerade mal das HRG-Emu daughter-board gezogen - wow, das scheint ja mit der Hand gebrutzelt worden zu sein. Berge von altem Flux auf der Lötseite. Das schrubb' ich dan, wohl auch mal.
P.P.S: Die restlichen 2332 ROMs (HiRes-Basic etc.) habe ich auch mal alle ausgelesen und gegen die Images von zimmer.net verglichen - alles OK.

Zitat von Toast_r

Was passiert denn, wenn Du an den betroffenen Speicherstellen versuchst, Werte reinzuschreiben?

Nix - oder ich bin zu doof für TIM... egal, wo ich hinschreibe, $500 oder weiter oben bei z.B. $1500 (":0500,A5" ist doch korrekt, oder?) die bytes bleiben stoisch bei FF oder 00... dabei fielen mir jetzt div. gekippte bits auf. Ich habe die nicht angefasst, ich schwör'!
Hier z.B. $14fE - $1502 und $1530 ff.

Zitat von Diddl

Ich würde auch Mal die ROM prüfen. Vielleicht ist der RAM ja ok und der RAM Test defekt?

Gute Idee, hätt' ich ja auch mal drauf kommen können ! Moment... Ok, mein ROM scheint das 324746-01_b.bin zu sein (das "ohne b" bringt kein Bild), aber auch neu gebrannt das gleiche Verhalten. Schade, wäre so schön einfach gewesen.

Zitat von Toast_r

Schonmal mit dem Monitor probiert, was die vom Speichertest bemängelte Speicherstelle macht?

Hint: 255+1025=1279=$4FF

Da aber nicht 255, sondern 0255 angezeigt wird, würde ich auch auf fehlerhaften Speicher bereits in der Zeropage tippen.

Da der 8296 aber 64Kx1 RAMs hat, ist vor allem nach dem defekten Bit zu suchen.

[255 + 1025 sind bei mir $500 - aber worscht... hab's verstanden ]

Ok, also CALL -151, äh nee, hab's gleich, ah ja, SYS 54386.... und büttöschööööön:

Wenn ich mir das RAM so ab $0000 anschaue (also eigentlich $1000), dann habe ich immer ab $xx80 ein "Loch" von 128 bytes:

Ich würde also vermuten, daß bit 7 in die Suppe spuckt - aber warum klemmt dann das komplette byte?

Zitat von tokabln

...und die 255 Byte reichen jetzt nicht um die Lohnabrechnung zu programmieren ?

Sorry habe gerade einen Kasper gefrühstückt

Naja, stimmt schon [wer den Schaden hat,....] - nachdem ich gerade einen C116 reanimiert habe, erscheinen mir jetzt dessen 16384 bytes geradezu überdimensioniert.
Aber n'Bissel mehr als ein 1/4K hätt' ich mir von den ganzen RAM-Käfern schon erwartet

Während als hier Kasper und Clowns Mojitos zum Frühstück trinken hab' ich nochmal allen gesockelten Käfern die Beinchen geschrubbt und Lötstellen unterm Opa-skop begutachtet - nüscht Auffälliges...

Hallo Zusammen,

Ich bin mir sicher Ihr Profis hier könnt mir einen heißen Tip geben...

Nachdem mein 8296 ein paar Jährchen im Keller schlummerte dachte ich es sei mal an der Zeit, die Prinzessin wach zu küssen....

Sauber gemacht war sie schnell. Huch, das ist ja ein "G"... ganz vergessen - naja dann mal anwerfen die Dame: Kein Düdeldüt und auch kein Bild.
Ok, bestimmt die PLA denk' ich mir... adapter für UE5 gebraten, Sockel rein und: Dudeldüt & Bild Aaaaber leider sehr, äh, rudimentärer Speicher. Also so:

Ja, 0255 bytes... egal ob im "8032 emu mode" oder ohne Jumper... spaßeshalber habe ich mal alle 4 MUXe getauscht (UA9, UB9/10/11) keine Änderung.
UE6 ist OK (Gegenprobe mit EPROM-PLA gemacht), 5V sind sauber da.
Dank der HRG-Emu (denke ich) ist ein komplettes strippen - alle ROMs raus etc. - keine Option, oder?

Habt Ihr eine Idee, wo ich nach der Bitverklemmung suchen könnte?

Danke & Grüße,
Axel

Hallo Zusammen!

Da wollte ich gerade mal Werbung für mein Baby machen und dann hat sich das schon bis hier her herumgesprochen

Zitat von RalfK

So was ähnliches gab's schon "damals", wie Axel erwähnt:

Mensch Ralf, darum ist das ja ein clone, ne?

Zitat

Ich selbst habe mich ein bißchen genauso mit der 68k-FPU beschäftigt, und mit dieser:

http://mirrors.apple2.org.za/A…e%20Cards/CPU/CCS%207811/

Die wartet auf Inbetriebnahme.

Wie die Jungs, die den NumberCruncher damals gebaut hatten, schon schrieben: "Pull it fast!" - Der AM9511 hat auf der Karte nie richtig funktioniert und nur Wärme erzeugt.

Zitat

Je nachdem, welchen Bedaf an Floating Point-Rechenleistung Du hast, und wie Du den nutzen möchtest, bringt so was nicht viel bis ein bißchen was.

Nu ja... ein Mandelbrot in AppleSoft in 3:40 hat schon was...
Auf dem IIgs per SANE patch INIT läuft alles über die FPU!
AppleWorks II auf einem IIe per patch... "is wie wense fliechts".

Zitat

Ein großer Bremsklotz im Appel II ist die Ansteuerung der FPU, denn die ist auf das Bus-Interface der 68020-CPU ausgelegt: 32bit und Cache-Nutzung aus dem CPU-Cache. Wenn man die FPU mühsam mit 8bit-Häppchen versorgen muß, um nur eine FPU-Operation auszuführen, dann dauert das sehr viele Zyklen. Wenn Du dagegen ganze FPU-Programme schreibst, d.h. die Daten im Registersatz der FPU beläßt und weiterbenutzt, dann wird das was

Das geht mit der NC-R auch, kein Problem.
Ja man füttert von Hand, aber was drin ist, ist drin. Und dann kann man prima Register 1 mit 2 addieren und durch register 3 dividieren. Und das ganz ohne endian Konvertierung

Zitat

BTW, wenn Du Dir so eine Platine kaufen möchtest, dann nimm unbedingt eine 68882 wg. rund dopppelter Rechenlesitung.

Das wiederum bringt auf FPE, NC und NC-R nichts. Siehe meine Benchmarks.
Zudem war die 68882 im realen Mittel 30% schneller als die 68881 wenn man sie richtig füttert. Aber das sind schon wieder religiöse Diskussionen [wegduck']

Grüße, Axel

Zitat von RexRetro

Danke allerseits.

Hat mal jemand solche AVM Karten mit C= Bridgeboards im Amiga versucht?

Nein, noch nicht, sollte aber kein Problem sein. Die verhalten sich ganz brav, nutzen nur Port 0x150 und schmutzen nicht
Hier findest Du (ganz unten) eine kleine Session mit DOS debug- so kannst Du testen, ob alles i.O. ist.
Ich behaupte aber ein initialer Test mit ispy (ganz oben) wird sofort funktionieren.

Zitat von RexRetro

Hab mir gerade das Buch gegönnt mit Platine (leere) und ohne Diskette.

Hat jemand ein Image und gibt es brauchbare Emulatoren ? Vor allem welche, die mehrere Transputer emulieren, denn einer alleine ist ja relativ witzlos.

Glaube nicht, dass ich das Ding bauen werde. Hab auch keinen alten ISA PC. Muss mich aber erstmal aufschlauen.

Es gibt nur einen gescheiten Transputer Emulator und das ist der von Gavin. Da kommt keiner mehr ran... ultimativ, inkl. T800, den zuvor niemand emuliert hat.

Zur "Gerlach" habe ich eine kleine Page geschnitzt, welche u.A. die Bugs auflistet:

http://www.geekdot.com/categor…puter/das-transputerbuch/

Zitat von 1ST1

Die Programme hast du mir ja mal gegeben. Sobald ich so weit bin, will ich mal testen, ob das auf den Kisten funzt.

Nicht ohne den passenden loader. Es gibt/gab keinen Standard eine externe CPU anzubinden (egal welche) - also hat jeder sein eigenes Süppchen gekocht.

Die Hauppauge 4860 und Deine Olivetti LSX sind memory-mapped. Der Unterschied: Haupauge Doku und Software vorhanden vs. LSX... nicht

Selbst wenn man eine Memory-Map hätte, ist noch nicht klar, wie i486 und i860 sich arbitrieren, welche interrupts, wie ist die Speichersegmentierung.

IMHO wäre der einzige "Angriffsvektor" das Diagnostic tool, welches ja von einigen Dingen zu wissen scheint:

Hast Du dessen Code disassembliert und verstanden, geht es an "try'n'error" mit einem eigenen Loader.
Binary ins i860 ram drücken und rausbekommen, wie man ihn startet... alles in allem: Du solltest Dir die nächsten Monate nix vornehmen

Zitat

Der Quellcode für neuere DOS-Versionen wurde ja mal geleakt, ob man das mal für den i860 kompilieren sollte....? Ich weiß x86 Programme laufen darauf dann nicht, also ziemlich nutzlos...

Nutzlos ist Dos ja per-se (Ich darf das sagen, denn ich nutze es fast jede Woche)

Nee, das ist sinnfrei - ein i860 ist halt ein Numbercruncher... da braucht es kein OS auf dem Moped: Einfach Benzin rein und anzünden Will sagen: Der Algorithmus läuft im i860, die Daten verfüttert ihm eine echte General Purpose CPU und holt sie auch wieder ab.

So mach(t)en es letztendlich alle, ob nun die vielen "Beschleuniger Karten" oder Grafikkarten (ob Proprietär, TIGA oder NeXTdimension), die nur mit Displaymaps oder Display-PS hantierten.

Zitat von escimo

NT4 für i860 ist in etwa so häufig anzutreffen wie NT4 für SPARC.

Da hat man mit UNIX-Derivaten (ggf. AT&T System V/i860 Release 4.0 - also SVR4 für i860) voraussichtlich mehr Glück.

Uh, i860... da spring' ich doch mal rein

Selbst da wirst Du im Web nicht fündig... vielleicht in irgendeinem feuchten Uni Keller.

Und NT4 for "N-Ten" verließ nie die MS Labore. Der i860 eignet sich mit seiner Mörder-Pipeline auch nicht für ein OS, welches schnelle Context-Wechsel benötigt... also so ziemlich jedes OS außer DOS und CP/M

[Blablabla wegen Redundanz gelöscht - hätte mal weiter "zurück-lesen" sollen ]

Aber als Schmankerl: Mandelbrot auf i860? Ehrensache! https://www.youtube.com/watch?v=-wFxl6vq-Os

Zitat von geekdot

Falls sich hier also einer der wenigen ATW Eigner herumtreibt: Bitte mal Schublehre anlegen, Danke! Selbiges habe ich auch "drüben" schon die ATW'ler gefragt, bisher ohne Ergebnis.

Ok, feddich

Falls sich hier also ein ATW Besitzer rumtreiben sollte, der nicht auch bei atari-home zu Hause ist: Ich suche mutige Beta-Tester und gelangweilte VHDL Könner >:-D

http://www.geekdot.com/atw800-farmcard/

Zitat von Falcon030

Das ist - jedenfalls für mich als Hobby-Historiker - interessant. 2080ST^F und 4160ST^F wurden nach der Ankündigung im September 1986 auf der 9^th PCW in London noch vor Veröffentlichung wieder zurückgezogen - [...] Warum wurden also noch Anfang 1988 die Modelle produziert? Eventuell rein als Entwicklergeräte gedacht? Dann müssten sie ja eigentlich Dev.System o.ä. heißen. Oder ein zweiter Anlauf, die Geräte auf den Markt bringen zu wollen? Schließlich waren 1989 auch 2080ST^E und 4160ST^E geplant…

Hat der Floppyausschnitt denn auch gefaste Kanten wie der Falcon oder ist das einfach nur größer ausgeschnitten worden?

Nunja - letztendlich ist so ein Rechner auch nur die Summe seiner Teile - vielleicht ist es auch eine "Chimäre". Man kennt das ja, ATARI/Commodore/YourFavoriteManufacturerNamedHere geht pleite, die Reste werden verramscht... und irgendwer ersteht eine Palette Leergehäuse, packt irgendwann ein passendes Board rein und: Taaadaaa, die Nachwelt wundert sich. Es gibt ja bei solchen Dingen keine "Matching Numbers" wie bei Oldtimern der KfZ-Welt...

Ich habe hier noch ein paar Fotos vom Gehäusedeckel gemacht - der Floppyausschnitt ist sauber gefast (Nix Dremel )

...und eine "Batch/Form-number" gibt's auch noch:

Ich fasse zusammen: Zumindest der Deckel "historisch interessant", könnte er doch in einer Falcon-Form mit hellem Granulat gegossen worden sein.

Auch das Label ist schön authentisch in Atari-3D... das "Marketting" Label (Cousin-of-Kernal ) ist sicher auch nichts, was ein gelangweilter Schüler geschnitzt hat... die Revision C100059 des Boards ist ebenfalls nirgendwo gelistet. Aber ob original oder nicht kann wohl niemand mit Bestimmtheit sagen.

Hab' ihn trotzdem lieb (Ist er doch soooo viel mächtiger als mein 520+ damals 1985... Habe auch gerade noch die beiden ROMs gefunden, die das RAM-TOS nachluden, liegen brav bei den Arthur ROMs. Ja, so ist das als very-early-adaptor^tm

Zitat von Falcon030

Es gab ein paar Entwicklerversionen meines Wissens nach vom 2080STF, für eine Vermarktung war der aber ebenso wie der 4160STF nicht mehr vorgesehen. Die Produktionswoche der Platine wäre noch interessant, [...] – ist das 8613 oder 8813? Vom Layout her scheint mir das eher die neuere Version zu sein

Das ist 8813.

Ich vergaß zu erwähnen, daß dieser "STF" auch keine "Diagonal-Zentralknopf Floppy Blende" sondern einen schnöden Rechteck-Ausschnitt wie der Falcon hat.

Zitat

Die Schreibweise "Marketting" starb allerdings irgendwann im 19. Jahrhundert aus, ich sehe das mal als Rechtschreibfehler. Die Schriftart der FCC- und VDE-Felder will optisch auch nicht zum Rest passen… da das Gerät aber nie in großen Stückzahlen gefertigt wurde, muss das nichts heißen.

Ja, astrein ist das nicht und das "Marketting" ist mir ehrlich gesagt nie aufgefallen Aber für eine Fälschung wäre der Hochglanz offset-druck Label dann doch etwas aufwändig.

Zitat von 1ST1

Drüben in atari-home.de wurde übrigens kürzlich eine ATW 800 wieder in Betrieb genommen.

Hehe... ich hab' da ein wenig gewildert. Wollte eh schon immer mal eine ATW Farmcard schnitzen... die ist jetzt auch theoretisch fertig. Weil ich aber weder eine ATW (seufz) noch eine Farmcard habe, fehlen mir ein paar Details. Zum Beispiel die Slot-Abmessungen

Falls sich hier also einer der wenigen ATW Eigner herumtreibt: Bitte mal Schublehre anlegen, Danke! Selbiges habe ich auch "drüben" schon die ATW'ler gefragt, bisher ohne Ergebnis.

Hallo Zusammen,

Weil ich gerade "dran" bin (Frühjahrsputz ;-)), ein 2080ST, der m.E. nicht einfach nach Jugoslaven-Art umgelabelt wurde: "Marketing Sample"

keine Seriennummer, Papier-Kleber hinten, vorne richtiges 3D Label:

Innendrin ein STFM board ohne "M-Teil" dafür Blitter. Revision C100059 konnte ich bis jetzt auch noch nirgendwo finden...

Wenn er dann mal sauber und getestet ist mache ich schönere Bilder.

VG Axel

P.S: Etwas OT, aber kann ich eine vermtl. Hushi formatierte ATBUS platte irgendwie am PC/Mac auslesen?

Ers'ma' ein herzliches Dankeschön in die Runde für den nette Begrüßung!

Zitat von masi

Soweit ich mich erinnere, war der GC mit dem H1/T9000 geplant. Erst als dieser ewig nicht verfügbar wurde, hat Parsytec für den Übergang den GCel mit T805 angeboten, mit Option zum späteren Aufrüsten, wozu es dann aber nicht mehr gekommen ist. Die PowerPC-CPUs haben mit dem GC nichts zu tun, die hat Parsytec erst (in den späteren kleineren Systemen) eingesetzt, als klar war, daß es mit dem T9000 nichts mehr wird.

Ganz Europa und ein wenig USofA warteten auf den T9000 (ich hab' ihn :-P) und schauten sich nach Alternativen zur Überbrückung um.

Da gab es allerlei gerade und ungerade Umwege... i860, TMS320cxx und PPCs um nur einige zu nennen. Die Info zum GCel habe ich Fritz Lue und Lothar Waßmann. Beide ihres Zeichens Ex-Parsytec'ler und Geburtshelfer der GC(el)... und wenn die's nicht wissen, dann ist's wohl Demenz

Parsytec hat in den letzten Zügen ja dann sogar PPros verbaut. Bäh...

Zitat von Toshi

Ich bin neulich in den Besitz des Transputerbuchs von Hr. Gerlach http://www.geekdot.com/das-transputerbuch/ gekommen. Anbei ist eine Platine für den IBM PC, die ich mir die Tage mal aufbauen möchte. Anbei erst mal die Scans der Platine, bevor ich sie bestücke.

Danke für den Link Nicht vergessen die beschriebenen Bugs zu fixen, gell.

Die Apple II Karte gibt es "in geil" übrigens hier http://www.geekdot.com/t2a2-for-everyone. Die C64 Karte ist noch ein Prototyp... und obwohl "Sinn" bei mir selten eine relevante Größe ist, habe ich dafür noch nicht genug Anwendung und Nachfrage gefunden, um sie mal "in geil" zu bauen

Zitat von Jan1980

Ich habe einen Elnec Beeprog2. Aber ich denke, rein für retrocomputing wäre der etwas teuer.

Aber genau das Richtige!

Wie mein Vater immer sagte: "Ich bin zu arm für billiges Werkzeug" - recht hat' er. Ich habe ca. 10 Eprommer seit 1986 "verbrannt", aber mit dem Elnec singen jedes Mal Engelschöre, wenn ich ihn mal wieder zur Arbyte heranziehe. Einfach ein super Teil mit klasse Software...

Mein Blog post dazu: /http://www.geekdot.com/too-poor-for-cheap-tools/

Habe auch schon den sog. "AlgOR Service" von Elnec genutzt. Einfach mega cool! Hat man mal wieder einen IC-von-der-Venus, ein wenig Datenblatt und schickt denen beides zu, hat man in 99% der Fälle 14 Tage später eine neue Version der Software und der IC ist les/beschreibbar.

Sollte ich nur ein Retro-Tool mit in den Sarg nehmen dürfen, es wäre mein Beeprog+

Hey Joe,

Zitat von Joe_IBM

Reinigungsband könnte ich haben. Wenn noch Interesse besteht, geh ich mal auf die Suche...

Danke Dir! Aber keine Eile, mit Wattestäbchen und Alkohol kann ich mir ersteinmal helfen. Solltest Du irgendwann darauf stoßen und Dich erinnern, kannst Du ja dann noch mal schreiben.

Zitat von fritzeflink

bei QIC 24 Laufwerken solltest du aber auch mit Alkohol und Wattestäbchen an den Kopf kommen.

Ansonsten ein weicher Streifen Stoff mit Alkohol getränkt und ein Holzstäbchen geht auch.

Ein paar Bilder wären schön...

Ja, danke für den (Q-)Tip Habe ich von anderer Seite auch schon zugetragen bekommen. Ist wohl besser, als ein altes verharztes Reinigungstape...

Schöne Bilder kommen, wenn alles läuft. Meine RC ist leider nicht mehr so piko wie in den Broschüren - die Frontblende fehlt, dafür mit Farb-Framebuffer!

RC2030_topview.jpg

RISC/os 4.52 ist mittlerweile auch drauf, nur leider versteht sich die Büchse nicht mit "modernen" SCSI Platten - der fx(8) Vorgänger (wurde auch von SGI übernommen) kennt nur 12 fest definierte Platten. Alles andere muss von Hand eingetragen werden. Virtulle C/H/S ist nicht... und solche Daten bekommt man nicht mal aus den Untiefen des Netzes:

RC2030_HD_parameter.jpg

Also formatieren & partitionieren unter IRIX, dann installieren, mkfs (FFS!) etc unter RISC/os... leider habe ich bis jetzt keinen Weg gefunden, die "falschen" Partition tags zu korrigieren.

PartMap_RISCos.jpg

root und usr müssten eigentlich "4" sein. Somit bootet das Biest momentan leider nicht durch

sash findet den Kernel nicht, weil:

RISCos_FS_err.jpg

RISC/os Vetreranen bitte vortreten! Danke

[crosspost aus alt.de.folklore.computer]

Hallo Zusammen!

Wie's immer so ist... man nimmt sich endlich mal eines seiner Schätzchen an, die schon viel zu lange im Keller/Dachboden/Lagerhalle/Warehouse 13 lagen und dann kommt man von Hölzchen auf Stöckchen: Elkos, DS1287, RAM... Ihr kennt das ja.

Meine momentane Patientin, eine MIPS rc2030 Workstation... beinhartes 12MHz R2000(sic!) Teil. Hat keinen Schimmer von netboot & Co. Also soll das OS bitte per QIC Tape verfüttert werden.

Dazu benötige ich Eure Hilfe:

• Die original Bänder von 1989 (RISC/os 4.1) haben alle ausgeleierte "Antriebsriemen" - hierfür würde ich also Teilespender suchen. Zum Beispiel defekte QIC-24/120/150/525 Tapes, Hauptsache nicht QIC-20 oder 40 (aka "mini-QIC"), da ist der Riemen kürzer.
• Ich besitze noch *ein* NOS QIC-525 tape, welchem ich wirklich vertrauen kann. Das wird auch momentan hart rangenommen (Scheiben unter Linux, Lesen auf der MIPS, geht nicht, repeat) - ich würde mich freuen, wenn ich zumindest ein 2. hätte, falls dieses die Grätsche machen sollte.
• Und zu guter Letzt: Ein Reinigungsband wäre ein Traum... ich sorge mich etwas um den Schreib/Lesekopf meines Tandberg Drives, von dem ich nicht weiß, wieviele Kilometer Band es schon durchgeschleift hat...

Sollte also jemand von Euch netten Menschen so etwas rumliegen haben, freue ich mich über ein Zeichen

VG, Axel

P.S: Ach, und wenn noch jemand von Euch im Thema RISC/os (und ich meine nicht das von Acorn ;-)) ist, freue ich mich auch über Kontakt

Moin Charmanta,

Mega! Vielen Dank! Du hast post...

VG Axel