Hallo Besucher, der Thread wurde 27k mal aufgerufen und enthält 144 Antworten

letzter Beitrag von kinzi am

"Dead Test++" - Ideensammlung / Brainstorming

  • So einfach und so kostengünstig wie möglich...

    Das sind meine Vorgaben auch, immer. :P

    Wie auch immer:
    Sobald axorp mit seinen Test-Platinen fertig ist (er wartet noch immer auf Bauteile) werden wir euch im Forum Teil haben lassen.

    Dann lasst uns doch endlich mal teilhaben, was da so rauskommen soll ... :)
    Konkretes, worauf aufgebaut werden könnte konnte ich bisher nicht rauslesen.

  • Ähm - holt mich mal gedanklich ab bitte... wieso möchtet Ihr den ein ROM/EPROM per CPU simulieren?

    • Man kann den Controller ("CPU") neu flashen -> es braucht kein EPROM (neu) programmiert werden [EDIT] bei einem Software-Update. [/EDIT]
    • Man kann alles mit dem Controller abfackeln und braucht kein zusätzliches EPROM -> Platz-, Strom-, Geldersparnis. ;)

    Das ist aber nur so ein "Bonus-Punkt" und kein Must.Have.

  • Mit einer CPU, die man sich für die Entwicklung ausgesucht hat - die Kosten sind da IMHO erstmal egal, da muss der Entwickler sich entscheiden was er investiert und das muss nicht viel mit den Kosten der CPU im fertigen Gerät zu tun haben. Aber zu fordern, dass man erstmal die CPU-Wahl ausdiskutieren muss, weil das vom Entwickler gewählte Modul aus Anwendersicht zu teuer wäre scheint mir eher kontraproduktiv zu sein.

    Aber für die spätere Umsetzbarkeit ist die CPU-Wahl schon entscheidend. Es nutzt doch nichts, wenn das auf einer teuren CPU läuft und später nicht kostengünstig realisiert werden kann.
    Deswegen gehe ich meistens so vor, dass ich mir erst mal eine oder mehrere mögliche CPUs aussuche, und dann schaue, was damit möglich ist.
    Dabei sind nicht nur die Kosten und die Leistung enscheidend, sondern auch die Bauform und die Programmierung. Irgendjemand muss das ja auch mal aufbauen die Software dafür schreiben.

  • Man kann den Controller ("CPU") neu flashen -> es braucht kein EPROM (neu) programmiert werden [EDIT] bei einem Software-Update. [/EDIT]


    Man kann alles mit dem Controller abfackeln und braucht kein zusätzliches EPROM -> Platz-, Strom-, Geldersparnis.


    Das erkauft man sich aber mit reichlich viel Software-Aktion, die kaum zu handlen ist und den Controller über die Maßen beschäftigt. Timingprobleme und wie oben auch schon erwähnt wurde Gefahr des Schrottens von Modul oder Mainboard inclusive.


    Vorschlag: Flash-Speicher mit drauf. Ja, das braucht ein paar Quadratzentimeter mehr Platz, dafür wird aber alles aussenrum deutlich einfacher - zumal man dann sogar die Möglichkeiten bekommt, minimalistisch kleine Happen des Flashs als Testroutinen für den 6510 einzublenden - damit könnte man bei Defekten auf dem Adressbus des C64 das "Ausfallrisiko" sogar nochmal reduzieren - zumindest solang nicht grade die unteren Adressleitungen defekt sind, was wiederum bei defekter PLA einiges erleichtern dürfte.


    Übrigens würde ich nicht so sehr an bedrahteten Bauelementen klammern. Wer sich so ein Modul mit seinen Möglichkeiten antut, gehört doch schon eher zu den Leuten, die mit einer feinen Lötspitze umgehen können, und zur Not sind Controller (und Flash-Speicher) in SMD auch schnell mal auf der Herdplatte gelötet.

  • Vorschlag: Flash-Speicher mit drauf.

    Finde ich prinzipiell eine gute Idee. Vorausgesetzt der Speicher lässt sich über die externe CPU (USB) ohne zutun des C64 flashen.
    Das erfordert aber wiederum einiges an Hardware-Mimik.


    Die Idee einer Emulation würde ich aber nicht gleich ganz aufgeben. Softwareaufwand hat man nur einmal. Hardwareaufwand dagegen bei jedem einzelnen Modul.

  • Das erkauft man sich aber mit reichlich viel Software-Aktion, die kaum zu handlen ist und den Controller über die Maßen beschäftigt. Timingprobleme und wie oben auch schon erwähnt wurde Gefahr des Schrottens von Modul oder Mainboard inclusive.

    Dann sieh dir mal den Superkernal an. ;)

    Vorschlag: Flash-Speicher mit drauf. Ja, das braucht ein paar Quadratzentimeter mehr Platz, dafür wird aber alles aussenrum deutlich einfacher - zumal man dann sogar die Möglichkeiten bekommt, minimalistisch kleine Happen des Flashs als Testroutinen für den 6510 einzublenden - d

    So oft wird mal die Software nicht erneuern, zumindest nicht die, die im C64 laufen soll. Aber gut, streichen kann man es immer noch. :D

  • Wurde bisher glaube ich nicht genannt:


    Zwischenstecker für die Stromversorgung - also zwischen Türstopper und Cevi.


    Dann könnte man generell (unbelastet) die Spannungen testen
    und erst bei positivem Test den Cevi dranhängen und belastet weitertesten.

  • Wurde bisher glaube ich nicht genannt:


    Zwischenstecker für die Stromversorgung - also zwischen Türstopper und Cevi.


    Dann könnte man generell (unbelastet) die Spannungen testen
    und erst bei positivem Test den Cevi dranhängen und belastet weitertesten.

    Wurde bei unserem Konzept bedacht...



    Was ich weiss:


    - mehrere Spannungs- und Strommessmodule (speziell beim CBM seien diek korrekten Spannungen an mehreren Punkten auf der Platine extrem wichtig; Spannung am C64 Netzteil oft zu hoch)
    - die mittlerweile schon öffentliche Schaltung mit den 2x 4040 ->
    welche defekten Bauteile welches Ergebnis bringen müssen wir testen...
    - speziell für den C64: ein integrierter Überspannungsschutz, da ja die Netzteile mittlerweile oft abrauchen


    Von vielen restlichen kleinen Schaltungen weiss ich selbst noch nichts...


    Aber wie gesagt: Automatismen mit CPUs, die dann ueber Displays etwas ausgeben wird es bei uns erst mal nicht geben.
    Bei uns wird es dafür ein ausführliches Handbuch geben.


    Sobald die ersten Test begonnen haben werden wir das auch öffentlich machen...
    Bloß gibt es momentan wie schon mehrfach gesagt bis auf Ideen noch nicht Mal etwas auf Papier...


    Und wie ich schon mehrfach mitbekommen habe wurden manche Projekte nicht fertig eben weil zu früh gepostet wurde und versucht wurde alle möglichen Dinge ins Projekt mit aufzunehmen.
    War am Schluss dann einfach too much und kam ausm Beta-Stadium nie raus.

    Inventar:
    PET2001 (defekt), CBM3032 (defekt), CBM8032-SK (braucht mal ne Reinigung), Proxa 720 (diverse Macken), mehrere C64 (manche davon defekt - kommt Zeit, kommt Hardware für ne einfachere Reparatur ^^), Modding C64 (mit neuem Gehaeuse, MixSID, Keyman64), Ultimate64 - definitiv einer meiner Favorits!, SX-64 (seit der CC2019 defekt - repariertes Netzteil muss wieder eingebaut werden.), Amiga1200 (in der Lernphase :böse ), Amiga 500
    PI1541, Easyflash3, KungFuFlash, SD2IEC, PETSD+, Tapecart, Tapduino...

    2 Mal editiert, zuletzt von csdragon ()

  • Ich hatte mit @GMP heute Mittag kurz über das Thema gesprochen. Folgende sehr preiswerte Lösung hätte ich Anzubieten:


    Wir haben damals mit @LazyJones zusammen den Servant erdacht - ein Arduino Nano am Userport.


    GMPs-Edit: @KiWi Habe Dir mal das Servant-Bild eingefügt. Igrendwas hatte hier nicht funktioniert. Damit die Leute auch wissen, worum es geht:


    Diesen kann man recht gut Missbrauchen um Daten ohne Monitor o.ä. auf den PC via Serielle mit 230.400 Baud zu dumpen. Ich habe ein Test-Kernal gebaut was beim Einschalten einfach mal diverse Speicherbereiche "ausgibt". Es sind noch keine Test-Routinen an sich Eingebaut, man
    hätte aber z.b. den Vorteil das man nicht beim Dead Test Blink-Codes erraten muss sondern man kann Live den Speicher der defekt ist "sehen".


    Ist halt alles noch Brainfuck aber wäre ggf. eine zusätzliche Diagnosemöglichkeit den Check64 sehr Preiswert "aufzurüsten".


    Das hier passiert beim Einschalten:


  • @KiWi:
    Das finde ich ne top Idee!

    Inventar:
    PET2001 (defekt), CBM3032 (defekt), CBM8032-SK (braucht mal ne Reinigung), Proxa 720 (diverse Macken), mehrere C64 (manche davon defekt - kommt Zeit, kommt Hardware für ne einfachere Reparatur ^^), Modding C64 (mit neuem Gehaeuse, MixSID, Keyman64), Ultimate64 - definitiv einer meiner Favorits!, SX-64 (seit der CC2019 defekt - repariertes Netzteil muss wieder eingebaut werden.), Amiga1200 (in der Lernphase :böse ), Amiga 500
    PI1541, Easyflash3, KungFuFlash, SD2IEC, PETSD+, Tapecart, Tapduino...

  • @KiWi Das sieht prima aus! Nur damit ich es richtig verstehe: Das Ding hängt am User Port, muss also vom 6510 "betankt" werden; d. h., der Rechner muss in Grundzügen laufen?


    Den Test-Kernal könnte man ja als Ultimax-EPROM mit auf dem Check64-Modul unterbringen, wenn 4 kB RAM und 4 kB (bzw. 6 kB, wenn nur einer der beiden Zeichensätze gebraucht witd.


    ( @GMP Eine EPROM-Erweiterung auf 27512 wäre eventuell sindvoll für eine neues Release von Check64, gamz umabhängig jetzt mal von dem hier.) :)

  • Vielleicht hilft das hier:
    https://github.com/ArtemioUrbi…10A/tree/master/Z80_Check


    Ist zwar im moment nur für Z80 und 68000 sollte aber sicher auch auf 6502 anpassbar sein.


    bzw. (original seite leider nicht mehr verfügbar)
    https://web.archive.org/web/20…arcade/ArduinoMegaICT.htm


    Ähnlicher ansatz und geht auch mit 6502.



    Davon könnte doch was hilfreich sein ?

  • Nur damit ich es richtig verstehe: Das Ding hängt am User Port

    Ich habe ein Servant-Bild oben noch mal neu eingehängt.


    Eine EPROM-Erweiterung auf 27512 wäre eventuell sindvoll für eine neues Release von Check64, gamz umabhängig jetzt mal von dem hier

    Ja, das wäre sowieso mein Plan gewesen. Ich hätte damals nicht gedacht, das mehr als 4 Diags auf dem CHECK64 sinnvoll wären. Aber wie das halt so ist. Nach oben gibts keine Grenzen. :-D

  • @KiWi Das sieht prima aus! Nur damit ich es richtig verstehe: Das Ding hängt am User Port, muss also vom 6510 "betankt" werden; d. h., der Rechner muss in Grundzügen laufen?


    Den Test-Kernal könnte man ja als Ultimax-EPROM mit auf dem Check64-Modul unterbringen, wenn 4 kB RAM und 4 kB (bzw. 6 kB, wenn nur einer der beiden Zeichensätze gebraucht witd.

    Jetzt pack da noch ein günstiges kleines Display dazu und stecke den Nano auf die Expansionport-Platine statt auf die Userport-Platine, dann ist das genau die Lösung, die ich seit Tagen her (und mit GMP schon seit Monaten) diskutiere. Ich wollte halt den Atmel direkt einsetzen oder das Nano-Gedöns aussen rum.
    Aber wenn das von mir kommt, scheint das irgendwie immer zu teuer, zu kompliziert (oder was weiß ich) zu sein. ;)


    Ich bin jetzt wirklich raus hier. Ich schaue mir dann mal in ein paar Monaten an, was daraus geworden ist. Ihr macht das schon :thumbsup:

  • Aber wenn das von mir kommt, scheint das irgendwie immer zu teuer, zu kompliziert (oder was weiß ich) zu sein.


    Ich bin jetzt wirklich raus hier. Ich schaue mir dann mal in ein paar Monaten an, was daraus geworden ist. Ihr macht das schon

    Wer sagt denn das? So ein Quatsch. Du hast bis jetzt sehr gute Ideen gehabt und ich würde mir wünschen wollen, wenn Du weiterhin im Boot bleibst. :thumbup:


    Ich wollte halt den Atmel direkt einsetzen oder das Nano-Gedöns aussen rum.

    Ja, wenn ein Atmega328 schnell genug ist, dann lass uns den doch mal dranhängen. Hat der eigentlich genügend IO-Ports? Weiß es jetzt gerade nicht.
    Einen Nano hätte ich sogar noch da.

  • Ich bin jetzt wirklich raus hier. I

    Kein Grund, eingeschnappt zu sein. :D

    Jetzt pack da noch ein günstiges kleines Display dazu und stecke den Nano auf die Expansionport-Platine statt auf die Userport-Platine, da

    Auf dem Display kriegst du diese viele Information doch niemals unter? Wie willst du das alles denn auf einer Briefmarke darstellen? Noch dazu, wenn es "live" sein soll und dauernd Daten liefert?

  • Wenn ich mal Zeit finde, könnte ich den RPi, den ich am Expansionsport habe, mal zur Modulemulation umbauen (gerade lausche ich auf A0-A5,A8,IO2,D0-7,RW,...). Das Problem mit der Ausgabe wäre auch gelöst, der hat ja HDMI ;-)


    Wenn's mit dem RPi Zero geht, wären die Kosten ja auch noch überschaubar.


    Aber wie @Unseen geschrieben hat, erstmal schauen was funktioniert, dann was es kostet.