Beiträge von HofMar

    In dem Archiv aus der C= Supportbox über Commodore-PCs, findet man im Dokument "Embedded.txt" folgendes:


    Ferner wird auch im Dokument "Festplatten4.txt" noch die Schnittstelle mit einem anderen Namen betitelt:

    Zitat

    Nebenbemerkung:
    Die Plattenschnittstellen von PC 10/20-III und PC 30/40-III
    sind verschieden, u. a. ist der Datenpfad auch zur Platte
    beim PC 40-III 16 Bit breit, beim PC 20-III nur 8 Bit. All-
    gemein werden sie als WDSSI-Schnittstelle (für Western Di-
    gital Small Systems Interface) bezeichnet.

    Das bezieht sich zwar alles auf die PC10-III, PC20-III bzw. PC40-III, jedoch ist die eingesetzte Technik doch ähnlich.


    Hier noch ein weitere Hinweis, zwar für die Installation von MS-DOS, jedoch passend zu den Laptops in der Datei "MSDOS5.txt" komplett zitiert:


    Gruß Martin

    Hallo MIG,


    leider schreibst Du nicht, welche Festplatte zuvor in dem C286-LT drin war. Ich selbst habe leider kein solches Gerät, lese aber unter diesen Link, daß dort eine CP-2024XT verbaut war. Diese hatte noch einen Vorläufer des IDE-Bus, ein XT-Interface. Diese Schnittstelle setzte Commodore auch bei anderen PCs (z.B. PC10-III) ein. Vielleicht ist das ein Ansatz zur Lösung Deines Problems?


    Neben dem XT-Interface (8-Bit) gab es auch das AT-Interface (16-Bit). Dieses wurde später zu dem heutigem IDE. Näheres kann man auch hier nachlesen.


    Gruß Martin

    Hallo,


    ist also nen 93459PC Fairchild Semiconductor 16 x 48 x 8 Field Programmable Logic Array

    Damit gibst Du selbst die Antwort. Der 82S100 von Signetics heißt bei Fairchild eben 93459. Bei Philips heißt er dann PLS100. Offensichtlich hat hier Commodore leere PLAs eingekauft und diese ohne weitere Beschriftung mit den PLA-Daten beschrieben. Vielleicht klebte auch mal ein Aufkleber rauf? Damit sind das auf jeden Fall programmierte PLAs und keine maskenprogrammiere wie sie Jens schon ansprach. (Siehe auch unter http://www.softwolves.com/arkiv/cbm-hackers/1/1500.html)


    beide Files sind identisch

    Prima, dann wäre nur noch zu klären warum es eine neue CBM-Nummer für diesen Baustein gibt.


    Gruß Martin

    Ich habe leider nicht mitbieten können und damit die PLA nicht ersteigert. War es nun jemand von hier? Zuvor hatte ich noch Kontakt mit dem Verkäufer, welcher noch folgendes schrieb:

    Zitat

    Der PLA 251064-01 werkelt hier in meinem "Brotkasten" C64 von 1984.
    Es ist soweit ich weiß die letzte
    Revision der Großen Platine. ASSY Nr. 250425 ?1984.

    Das würde soweit passen. Jedoch ist dabei nicht klar, mit welchem Board genau diese PLA nun wirklich ausgeliefert wurde.


    Zitat

    denn ich habe schon die Masken-Teile und echte 82S100 hier gehabt

    Worin unterscheiden sich diese verschiedenen Typen äußerlich?


    Gruß Martin

    Hallo,


    bis jetzt kannte ich nur die 906114-01 als PLA für den C64 bzw. SX64. Dabei handelt es sich doch um ein 82S100. CSG führte dafür auch Bezeichungen wie 7700-001 oder 8700-001 ein. Nun bin ich jedoch auf ein 251064-01 gestoßen (siehe eBay Art.-Nr. 120664427857), welcher auch eine PLA für den C64 sein soll. Offensichtlich nur in den ersten Revisionen. Das verwirrt mich ein wenig. Was unterscheidet ein 251064-01 vom 906114-01? War der 251064-01 vielleicht ein richtig programmierter 82S100 und der 906114-01 nur ein Nachbau, welcher maskenprogrammiert war? Daher vielleicht auch die passenden CSG-Modellnummern 7700 und 8700?


    Würde mich über weitere Erkenntnisse freuen.


    Gruß Martin

    Hallo enigma,

    Da scheint wohl der Controller auf DD zu limitieren.

    Das ist korrekt. Der FDC kann nur DD lesen. Um aber trotzdem 720kB-Laufwerke (z.B. für 3 1/2") ansprechen zu können, kann man sich mit einem Befehl in der CONFIG.SYS behelfen. Dazu gibt es DRIVPARM, wo jederzeit ein Laufwerk unter DOS umgeändert werden kann und damit nicht mehr die Default-Einstellungen, welche evtl. auch vom BIOS kommen können, gelten. Nähres unter diesem Link. Möchte man ein weiteres Laufwerk für ein anderes Format, hilft auch der Treiber DRIVER.SYS, welcher als DEVICE in der CONFIG.SYS eingebunden werden kann. Auch hier ein kleiner Link.


    Gruß Martin

    Hallo 128er-Man,


    ich nutze dafür immer WIMAGE.EXE aus dem FDFORMAT-Paket in der Version 1.8. Ist in TP geschrieben und als Source verfügbar. Das erzeugt ein normale IMG-Datei, welche auch mit anderer Software (z.B. IMG-Plugin im Total-Commander) lesbar ist. Hier ein Link. Insbesondere kann der dort enthaltene Treiber FDREAD.EXE (AT) oder FDR88.EXE (XT) auch 720kB-Disketten ohne Probleme unter DOS mit einem HD-Laufwerk (1,2 MB) lesen!


    Gruß Martin

    Hallo,

    Commodore hat meistens Eproms der Serie 23xx (24 Pins) verwendet.

    Die Serie 23xx sind MROMs, also makenprogrammiert ROMs.

    Da die 27xx (28 Pins) Eproms aber einfacher zu beschaffen und zu brennen sind, haben Bastler meistens diese verwendet, um andere Kernals oder Erweiterungen einzubauen.

    In diesem Falle hatte selbst Commodore in vielen Geräten des Types 6x0 und 7x0 nicht die MROMs (2364), sondern EPROMs (2764) verbaut. Zum einen gab es auch viele Revisionen bei den verwendeten BASIC- und Kernal-ROMs, zum anderen lohnte es sich anscheinend nicht einen größeren Posten ROMs zu produzieren. Es gab aber auch definitiv MROMs (2364) von einzelnen Revisionen.

    Dazu ist dann ein Adapter nötig, deshalb auch die zwei zusätzlichen Sockel zwischen Eprom und Board.

    Wobei genau dieser Adapter nicht Commodore-typisch aussieht. Bei vielen Geräten der 6x0er Serie war eine einzige Adapterplatine (ASSY 324533-01) für alle drei EPROMs verbaut. (Siehe folgende abgelaufende Auktion) Jedoch will das bei Commodore nichts heißen. Daher wäre es evtl. doch möglich, daß er so direkt ab Werk kam.

    Vermutlich sind das also Kopien (obwohl bei Commodore ja alles möglich ist).

    So ähnlich sehe ich das auch. Die beiden äußeren EPROMs sind definitiv original. Das mittlere EPROM ist ein geändertes BASIC mit zusätzlichen SuperTape-Routinen. Das wurde damals in der c`t 12/1986 auf Seite 112ff auch für den Commodore 610 veröffentlicht. Steht da auf dem Aufkleber nicht auch Heise drauf?
    Man muß noch wissen, daß die höheren Versionen des Kernals keine Tape-Routinen mehr beinhalten. Diese wurden Opfer für den eingebauten Monitor. SuperTape war daher eine gute Wahl, zumal dies den freien Speicherplatz im BASIC nutzte und man damit keine Kompromisse eingehen mußte.


    Sollte es mit dem BASIC-ROMs Probleme geben, kann man diese auch getrost entfernen. Das Kernal arbeitet auch allein und man landet dann nach dem Einschalten direkt im Monitor. Dieser hat auch wieder eine Spezialität: unbekannte Befehle versucht er als Dateinamen zum Nachladen von der Standard-Device 8 zu interpretieren. Klappt das, wird das entsprechende Programm gestartet. So konnte man das BASIC auf Diskette speichern und gegebenenfalls nachladen. Insbesondere sehr interessant, da es zwei Basic-Versionen hab: BASIC128 für den 610 mit 128KB RAM und BASIC256 für den 620 mit 256KB RAM. Da man aus einem 610 durch nachlöten der 16 RAM-Fassungen (DIL16) sehr schnell einen 620 machen konnte, hatte man nun auch beim BASIC die Wahl.


    Gruß Martin

    Hallo,

    HofMar hat das z.B. auch auf Speichermodulen (SIMM/DIMM o.ä.) gesehen.

    Und natürlich auch direkt aus dem Hause Commodore, die REU hat auch solche Widerstände. Wäre gleich mal eine interessante Frage, ob diese auch mit der defekten CPU läuft?

    Wunderlich wäre das trotzdem, dass es nur hier auffällt und nicht bei anderen carts.

    Das sehe ich ganz anders. Bis jetzt gab es kaum Cartridges, welche so massive Schreibzugriff nutzten. In der Regel sind die Cartridges nur-Lese-Module. Klar gibt es einige, welche auch Schreiben, jedoch ist das Schreiben bei den Flash-Bausteinen auch wieder etwas ganz anderes. Es passiert parallel und zeitversetzt bzw. verzögert, da es mehrere us/ms benötigt. Daher werden die Daten und Adressen zwischengespeichert. Das dort verwendete Timing ist alles andere als identisch zu den Timings zur Ansteuerung eines SRAMs oder eines IO-Bausteins (VIA, PIA oder CIA), was man eben sonst noch auf Cartridges findet. Daraus resultierte auch der erhöhte Aufwand bezüglich der Generierung der /CS, /OE und /WE Leitungen. Das ist alles andere als trivial!


    Daher kann man an dieser Stelle nur noch einmal sagen, EasyFlash benutzt, wie der Name schon sagt, Flash-Bausteine. Das ändert eben das eine oder andere...


    Gruß Martin

    Hallo,

    Also ich bin davon ausgegangen das das funktioniert.

    Hast Du es mal probiert? Es könnte sogar funktionieren. Jedoch ist mir keine Applikation von Atmel bekannt, nach der das auch vom Hersteller so angegeben wird.

    Ich hab ein wenig gegoogelt und im http://www.mikrocontroller.net wurde erwähnt das man 2 AVRs mit einem Quarz parallel takten kann.

    Könntest Du eine genaue Quelle (URL) benennen?

    Warum geht denn das nicht?

    Wie ich schon oben schrieb, könnte es sogar funktionieren. Jedoch werden damit die Eingänge und Ausgänge des Oszillators einfach verbunden. Der Oszilator ist im Idealfall ein Inverter. Da würde das jetzt kein großes Problem sein, jedoch verändern sich ein paar Parameter, welche evtl. das Schwingen des Quarzes beeinträchtigen könnten. Außerdem ändert sich die Last auf der Eingangsseite, da dort zwei Eingänge vom Quarz beschaltet werden und damit bedient werden müssen. Daher wäre es eben besser, einmal den korrekten Quarz-Oszillator am ersten AVR aufzubauen, und dann direkt nach dem Inverter, den Oszilator-Ausgang zum Takt-Eingang des zweiten AVRs zu führen. Nur muß eben das Fuse-Bit für die Taktquelle von externen Quarzozsilator zu externen Takteingang verändert werden. Dies ist auch in den Appliaktionen von Atmel so verwendet. Z.B. ist selbst das alte STK500 mit zwei AVRs (AT8535 und AT1200) genauso beschaltet.


    Und immer dran denken, Deine Idee kann funktionieren, evtl. auch nur einmal auf der Welt, und zwar genau bei den beiden AVRs, welche Du verwendest. Ein sicherer Nachbau erscheint mit damit nicht garantiert!


    Gruß Martin

    Hallo,

    Wäre toll wenn jemand einen kurzen Blick drauf werfen könnte um zu sagen ob das ganze so funktionieren könnte.

    Die Beschaltung mit dem Quarz macht so keinen guten Eindruck. Du hast beide Ozsilator-Anschlüsse der beiden AVRs parallel geschaltet. Damit also jeweils beide Eingänge und dann auch die Ausgänge, und zum Schluß nur einen Quarz drangeschaltet.


    Entweder nimmst Du zwei Quarze für jeweils einen AVR und trennst die Verbindungen oder Du verschaltest und programmierst (Fuse-Bits) den zweiten AVR korrekt auf externen Takt-Eingang und holst Dir den Takt am Ozsilator (Ausgang) des ersten AVR ab.


    Wie das dann aussieht kann man auch hier sehen.


    Gruß Martin

    Hallo,

    Bit 0/1/2/3/4/5 der <banknummer> müssen an Pin 2/5/7/10/12/15 vom 74HCT174 = U6 erscheinen.

    Das war beim Prototypen so, jetzt bei der aktuellen Version 1.4.1 Rev. B wurden einige Pins vertauscht, da U6 sechs gleichberechtigte D-Flipflops beinhaltet.


    Die korrekte Reihenfolge lautet daher:


    Bit 0/1/2/3/4/5 der <banknummer> müssen an Pin 7/10/2/15/12/5 vom 74HCT174 = U6 erscheinen.


    Gruß Martin

    Hallo,

    Die Frage ist: wo kaufen?

    z.B. eBay? Artikelnummer: 130333328665, 12 Stück beim Startpreis von 11,50 EUR. Wenn man sucht wird man noch weitere finden. Und welbst wenn's ein paar Cent teurer als die größeren EPROMs der 27xx-er Reihe wird, spart man den Adapter.


    Gruß Martin

    Hallo,

    Ja, man braucht immer einen Adapter, wenn man ein 27xx-EPROM in einen ROM-Sockel des C64 stecken will. Wie oben schon gesagt, die Pinbelegung ist anders (weil das EPROM mindestens 4 Pins mehr hat).

    Moment, das Char-ROM des C-64 (901225-01) ist ein 4kB-ROM (2332). Dieses 2332 sollte pinkompatibel zum 2532 sein. Nur beim 2732, was auch 24 Pins hat, gibt es an einigen Pins Unterschiede (betrifft eigentlich nur A11), welches einen Adapter rechtfertigen würde. Aber warum sollte man dann nicht ein passendes 2532 nehmen?


    Gruß Martin

    Hallo,

    Was ist das für eine C64 "Bastel"-Hardware ??

    Wenn ich mir das so ansehe, sieht es sehr einfach aus. Der SN75498 ist ein neunfacher Treiber für neun der zehn LEDs. Die Eingänge werden über die neun darunter befindlichen Widerstände über den Userport angesteuert. Rechts daneben befindet sich noch ein Transistor mit ebenfalls einen Widerstand. Dieser scheint der Treiber für die zehnte LED zu sein. Sein Eingang wird auch über den Userport angesteuert. (Das sind dann die zehn orangen Leitungen). Dann gibt es noch eine gelbe Leitung zum Userport. Diese vermute ich als Masseleitung, welche auch zum DIN-Stecker führt. Die zweite orange Leitung vom DIN-Stecker geht in Richtung des Pin 20 vom 75498, und sollte damit VCC sein. Vermutlich wurde hier eine externe Speisespannung eingespeist.


    Also ist das einfach nur eine zehnfache LED-Ansteuerplatine, welche über den Userport gesteuert wird.


    Der Rest (also welche Pins vom Userport genutzt werden und wie die Software aussehen muß), verrät die Rückseite der Platine, auf der die Draht- oder Lotzinnbrücken sein müssen.


    Gruß Martin

    Hallo,

    Er ist mit Kick 1.3 / 2.05 / 3.0 bestückt

    Mal eine ganz generelle Frage zum A1200:
    Bis jetzt dachte ich immer in dem 1200er sind zwei 16-Bit-breite ROMs drin um einen 32-Bit-Zugriff auf die ROMs zu haben (U6A und U6B). Dafür gibt es auch extra ROMs 391523-01/391524-01 (3.0) und 391773-01/391774-01 (3.1). Demnach würde die obige Patine nur zwischen zwei ROMs umschalten.


    Jetzt schreibst Du etwas von 1.3 / 2.05 und 3.0. Die 1.3 und 2.05er Versionen gibt es doch aber nur 16-bittig und vermutlich nur für die Amiga 2000/500/600/CDTV, oder? Kann man die einfach auch im 1200er verwenden? Welche ROMs sind auf der Erweiterung genau drauf? Sind beide Sockel des 1200er mit der Adapterplatine adaptiert? Vielleicht gibt es auch noch ein etwas besseres Foto.


    Gruß Martin