Posts by merlintwa

    Normalerweise macht man ein solides Design mit einem aufgebufferten Clock-Tree. Das hat viele Vorteile, unter anderem dass Elektromigration kein Problem ist.

    Das hatte das prototype auch, es war genau diese uberdimensionierte buffers im diistribuierten clock-tree die dann gebracht waren um hohere taktfrequenzen (faster rise/fall times) zu bekommen, die dan mit ein unacceptabel hohen ausfall percentage nach lifetime tests im ofen bekommen hat. Das konnten wir dan verbesseren durch hoheren metal-layer zu preferieren fur die clock-leitungen und wo moglich doppel-vias zu routen. Aber trotzdem gibt es tatzachlich ein nicht zu ignorieren percentage failure im feld von IC's durch electromigration.


    Ich kann mich dan vorstellen fur C64 IC's, nach den probleme in 1983 sind alle chips etwas anders geroutet oder vias grosser dimensioniert im exestierende mask-set. In diese jahre war den turn-around time von ein neue mask im mask-set (zb. nur alle vias grosser machen) ja wochen stat monate die es 10 jahr spater gebracht hat.


    Silicon production ist ja immer so das es einige von den milionen/milijarden vias in einer IC unter minimal-spec gefertigd werden durch production fehler. Diese tiele haben zum beispiel ein via het hohen wiederstand in einer stelle so dass den maximale taktfrequenz des teil etwas minder hoch ist, das wird dan hoffentlich im test phase im production schon detectiert (was nicht so oft wirklich gelingt) und nach binning als low-freq teil verkauft. Aber solche nicht-vollig-defecte vias, sind dan auch genau fur electromigration sehr gefulig und konnen ja dan im feld ausfallen.

    In factory-testen sind halb-functionierende transisor und hohere-widerstand via oft nich zu detectieren. Und den effect von ein halb-functionierende transistor oder schlecht geformte via sind nicht zu unterscheiden.

    Noch ein annekdote: electromigration war bei ein prototype chip woran ich gearbeitet hab, unerwartet im distribuierten clock-netz, nicht den power linien. Dieses clock-netz andert sich ja 2x pro takt, und hat ausserhalb des power-linien den grossten strohm. Aber, diese clock linien wurden alle minimal-abstand und minimal-width und nur 1 via geroutet - genau so wie alle andere spuren. Das haben wir dan im 1-woche ofen-test feststellen konnen, und reparieren konnen fur den production-variante.

    Sofern die Leitungen im IC nach gewissen Grundregeln designt wurden, ist das nicht der kritische Punkt. Der Effekt kommt dann zum Tragen, wenn ich an die Grenze gehe, was das Material gerade noch hergibt. Dann macht es in der Praxis einen Unterschied, ob Leitungen im IC abgerundete Ecken haben oder nicht. Wenn im normalen IC Elektromigration ein Ausfallschwerpunkt ist, wurde das Design falsch gemacht.

    Stimmt, aber CBM hat ja mit electromigration viel probleme gehat damit https://en.wikipedia.org/wiki/Electromigration

    "Electromigration due to poor fabrication processes was a significant cause of IC failures on Commodore's home computers during the 1980s. During 1983, the Commodore 64 computer for a time had a nearly 50% customer return rate."

    Ich denke als reaktion sind noch immer functionierende teile stark uberdimensioniert.


    Problem mit elecromigration ist das es nie aufhort, die ionen im material bleiben immer bei gebrauch langsahm weiter migriren,m wodurch wiederstand hoher wird, wordurch dan mehr local heitzung platsfindet. Bis es fehlt.

    Viel C64 chips sind ja normal schon uber 80C nach eine halbe stunde, also das macht electromigration viel mehr ein problem als bei CMOS. Bei CMOS sind es fast immer nur power-linien mit unerwarteten oder schlecht simulierten power-density oder local heating hotspots

    Electronmigration ja, auch schwerig dafur zu dimensionieren mit IC tools.

    Bei spateren chips wird bei die power-linien, weniger scharfe ecken (45 grat) gebraucht, oder wurden ecken in power-linien stark uberdimensioniert mit viele metal-layer und vias um es so lange wie moglich functioneren zu lassen.


    4797803600_1386367445_thumb.jpg

    Ja TTL, NMOS, HCMOS chips sind unglaublich uber-engineerd das sie jetzt noch immer functionieren. Das CBM-ziel war das den C64 nur einige jahren functionieren soll. Erst viel spater wurden die meisten chip fehler ursachen gut studiert und dann danach wurden consumer chips am meisten fur 10 jahre functionieren dimensioniert.


    Ich erinnere mich seht gut den IC-pin ESD-diode grosse discussion. ESD ist einer der meist vorkommende fehlerursache, und ESD dioden gebrachen sehr viel IC platz = geld. Also wurde damals in 90'r jahren sehr viel zeit genommen um aus zu finden wie klein man den ESD dioden unter jeden pin erstellen kann das den IC die gangingen ESD specification holt. Daneben, in ein ofen auf 200 C fur eine woche um so zeit-effecte zu emulieren. Alles nur um das beste compromis zwichen kosten (silicon area) und lebensdauer zu finden.


    Geht auch anders, altere Militar spec IC's und raumfahrt IC's sind eigentlich oft uberdimensioniert so das sie einzelfehler von transistoren uberleben konnen. Zum beispiel alte analog raumfahrt IC's hatten immer 4 transistors in ein schaltung so das diese 4 wie 1 transitor functioniert. Wenn 1 dieser 4 transistor in diese schaltung felht (entweder "offen" oder "geschlossen" fehler), bleiben die ubrige 3 noch immer functionieren wie 1 transistor. (Pioneer 10)


    Ich glaube mit C64 haben wir gluck das alles noch immer nach 40-50 jahren functioniert.

    Plastix ja ich kenne den systemloader nicht weiter, aber das tool kan ja nur den kernal-rom ersetzen mit C64 RAM.

    Also ich hatte das so eingeschatzt hier oben das die benutzer von systemloader die beschrankungen auch kennen.

    Nutzlich kan systemloader sein fur eigene C64 experimente, eigene kernal-mods mal ausprobieren, cross-compiler oder hardware checks aber naturlich wird systemloader nicht mit die meisten prg's compatibel sein. Um mit eigene experimente den KFF und systemloader zu gebrauchen sollen die alle auf ein D64 image stehen.


    Fur richtige soft-kernal support wie EasyFlash 3 hat, und wie skoe es in sein document beschrieben hat, braucht den KFF neue firmware. So wie ich hier oben geschrieben habe gibt es davon ein beta version, die wartet auf ein freiwilliger die das ausprobieren, messen kann. Danach kan es mit den gangigen firmware gemerged werden.

    @DerSchatten Es gibt schon ein betaversion von soft-kernal, die functioniert auf mein eigenes KFF-abgeleite prototype mit andere pinout.

    Diese soft-kernal wurde ich gerne zum merge mit den gangigen kff software vorbereiten, aber zuerst soll ein freiwilliger den soft-kernal version von KFF mal ausprobieren.


    Ich kann das nicht selbst weil ich kein original KFF besitz.


    Problem ist das es moglich ist dass den ST-chip GPIO pin fur EXROM und GAME auf meine version "normale" GPIO's sind und im standard KFF sind das "fast-normale" GPIO. Es kann sein das den timing von dieser pins etwas anders ist, und dadurch die ARM code etwas anders sein soll.


    Also wenn jemand dass versuchen will dan geht das schon. Auf eigene risiko naturlich - es gibt naturlich das risico das ich eine kleine fehler beim C programmieren gemacht habe fur den normal KFF version.


    Steht in meine github-fork

    Yeah 10k cycles is enough in any way I can think of. Its only used by KFF on firmware updates andwhen switching between larger than 64kB crt images.


    SDcards have similar cycle wear.


    For C64 hobby usage 10k cycles will last decades.

    Thanks merlintwa for your insights into the firmware. Interesting to know that there is a second timer to correct the first timer. I guess this is where the mcu becomes in sync with the C64. I have played witht the bluepill (stm32f103) and I noticed the latency jitter too. I think it might be because of the pipelines, they have to be emptied before branching on an interrupt. and then there is the flash cache prefetch thing also. I think.

    Hi bwack,


    The details of the STMF4 lacency is not made clear in the documentation, but I had to do quite a study of it while making the soft-kernal mode work to make an as short as possible jitter reduction code.

    Kim's approach is to read the running timer value at the start of the interrupt then copy it to a debug timer. The normal timer is on the APB bus and takes 5 cycles to access. The debug timer is part of the ARM core, sits right before the 3 bus muxes, and is around 3 cycles to access. Then Kim uses wait loops to wait for the debug timer to reach a value - so the remaining jitter is the max delay of one loop iteration, which is 7 cycles. Then the R/W, ROML, ROMH , IO1, IO2 are read and checked if there is an action to take. On a read, a second wait loop is used to hold data to the end of the cycle.


    The official ARM docs mention 12 cycles of latency plus a small amount of jitter depending on the currently executing instruction when the interrupt occurs. The doc is quite extensive on this part, and I can see from just the ARM doc that there can be 6 cycles of jitter just when the next interrupt is on the right cycle while leaving a previous interrupt (despite a lot of clever stuff in the CPU). But this ARM doc assumes all memory is zero-waitstate.


    However the peripherals on the ST busses have waitstates, some peripherals more than others. And the ARM has a write-buffer which I have measured will hold up a next instruction, and that next instruction will actually complete before the interrupt is taken. That is where I found 15 cycles of latency, it was because there is a write to a SD-card peripheral (which is put in the write buffer, and takes 7 cycles) followed by a jump to the start of the sd-card read loop (3 cycles) followed by an SD-card peripheral read (7 cycles). Somehow an interrupt occuring just when still executing that jump, will actually wait for the write-buffer to clear and then will fetch that read instruction (separate busses), then wait for both that write AND that read to complete before taking the interrupt.


    None of that is documented.


    In my soft-kernal mode code I found the 7 cycle jitter using a delay loop is too high so I use a 3 cycle delay loop instead. Also I had to re-code everything in assembly because the C compilation was too unstable (really minor changes causing radically different ordered code) for the soft-kernal mode. But it works!

    Hi bwack, its very close, timer is locked to counting the number of 168MHz cycles from the edge of PHI2, and an interrupt is generated (depending on NTSC or PAL) around 96-43 cycles after that edge. This is done using hardware features of the STM IC.

    Unfortunately, the ARM can have significant jitter (just like the 6510 with IRQ) on the start of the IRQ (I've measured 1-7 frequent and sometimes up to 15 cycles), so first another timer is used (which adds to the duration of the interrupt) to reduce the jitter of the start of the interrupt.

    Then, a cycle-accurate piece of code is run (which is compiled C but is quite sensitive to changes in C compiler settings or minor source code changes). After that completes, the ARM resumes background tasks.


    Some KungFuFlash cartridge-drivers have both a "normal" mode where there are some cycles left for background tasks

    Other cartridge drivers have "6510 + VICII" mode where the 6510 and the VIC both can access the cartridge for sprite data / char data for example. In this dual access mode, there are no spare ARM background cycles possible and the interrupt is active 100% of the time until the menu button forces a C64 reset.


    Even the "normal" mode driver can just make the interrupt timing when there are a lot of back-to-back accesses to the cartridge from the 6510. In such cases there are almost no background cycles left.


    But under normal cases, there are always some zero-page or ram accesses or wait cycles while running code from the cartridge every few cycles. When the Arm interrupt code detects there is no Cartridge access going on in the current cycle, it can exit the interrupt fairly early leaving sufficient background cycles to do things like SD-card access in D64 mode and USB in EAPI mode.

    Ich mag am liebsten die mindest-aufwendigen hardware losungen, also mit den mindensten IC count. FPGAs sind schon aber wenn es ohne kann find ich es schoner.


    UNO2IEC hat 1 IC und ist kleinsten PCB (Atmel, Arduino nano)

    KungFuFlash hat 1 IC (ST arm micro all-in-one)

    SD2IEC hat glaub ich 3 IC's, kann aber auch nur 1 haben (Atmel + 74xx sind optionel)

    Rest weiss ich nicht aber mehr als 3 glaub ich.

    Das ist doch (fast) ganz normal? Klar wird IPv4 UND IPv6 versucht (wenn der Server entsprechende DNS-Einträge hat und DNS überhaupt erreichbar war).

    Vielleicht, ist nicht meine erfahrung. IPv6 / IPv4 support ist in viel applications "best effort" und nicht so stabiel als nur IPv4 - wird also ofter ausconfiguriert in meine erfahrung weil alles stabieler wird.


    Bei ein hangenden WLAN treiber oder TCP stack, hilft doch oft um soviel moglich sockets force-closed zu machen. Das kann ein treiber ein "kick" geben. Zum beispiel weil es zufiel interne buffers offen sein, oder wenn intern auf ein mutex gewartet wird.

    Force close kann nur den application selbst machen. Der TCP stack warten bis ein socket timeout passiert + 2 minuten FIN_WAIT, und macht dan noch nicht immer ein gute cleanup.


    Noch so eine anekdote: Android 4 hatte damals ein apache-http-lib 1.0 im basis-OS-java set mitgeliefert. Diese lib hatte einen bug das den DNS timeout default nicht eingestellt war (also infinite timeout) und auch nicht extern vom API calls zu beeinflusen war. Das hatte viel arger bekommen, und viele app hangups verursacht genau wenn WLAN packet drops passieren bei DNS versuche.

    Damals war app size viel mehr ein issue als jetzt also wird fast immer diese built-in buggy library von apps verwendet.


    Mussten alle >1M user apps also die letzte version diesen library entweder selbst mitkomiplieren oder eine andere library gebrauchen.


    Naja damit will ich sagen, wenn es WLAN probleme auftreten - un in meine erfahrung passierst das bei sehr viele leute, sehr oft - dan sind basis-OS sachen nicht zureichend oder daueren viel zu lang (2+ minuten)


    Aber wenn ich deine berichte so lese gibt es keine WLAN dropouts in dein setup also das ist super!


    Fur meine eigene long-term SSH sessions gebrach ich X2Go. X2Go is sehr sensitive fur WLAN dropouts, hab ich bemerkt, aber das Linux GUI oberflach bleibt ja functionieren wenn die verbingung fehlt also sehr gut fur solche setups. Also ganz gut fur monat oder sogar jahren-lange linux sessions.

    Einge tage kann ich den ganzen tag ohne probleme mit X2Go eingelogd bleiben. Andere tage, 10 oder mehr dropouts pro tag.

    Im betriebs netzwerk wenn einer meine collega's ein Windows10 update downloadet, dan fehlt x2go jeden 15 minuten. Danach bleibt es 100% functionieren den ganzen tag. Wenn ich bekabeltes netzwerk im betriebsnetzwerk gebrauche dan functioniert x2go aber fast immer ohne probleme, auch wenn windows 10 updates platzfinden.

    Ok, meiner erfahrung ist anders, uber stabilitat von netwerk. Waran das exact liegt, weiss ich nicht.




    Fur mich ist SSH etwas wunderlich. Ich habe ein beispiel von ein 24/7 SSH - session zwichen zwei server in zwei rechencentrums in Afrika, wobei durch standige power verlust im land (auch bei den Telco) die routers ~10x pro tage restarten, und oft fur viele minuten sogar stunden down sind.


    Wenn ich nichts mache, keine berichte gesendet werden, bleibt SSH functionieren ohne probleme, weil mit TCP ja default *keine* keep-alives macht. Und wen ein router power-fehlt kommen auch keine TCP Reset-packets, also beide seiten von den SSH verbindung bemerken nichts davon. Komt power wider zuruck bevor ich eine taste beruht, bleibt alles functionieren.


    Stel ich aber TCP 30-sec keepalives ein, oder gibt es ein SSH mit log-file dump continue data, dan fuhrt jeden power-verlust langer als den TCP re-transmit timeout zum verlust von verbindung.


    Wie das exact so functioniert? Weiss ich nicht aber ich find das ganz Komisch.


    Also bei Browser, bemerk ich das bei netzwerk fehler viele sachen probiert werden, ich habe das interpretierts als:

    - Zuerst wird ein normalen TCP request gemacht. Normalen Nagle-algortime sachen dabei.

    - Komt dan innerhalb einige secunden kein antwort? Wird das nochmals versucht.

    - Kommen OS netzwerk fehler? Dan wird abhanging von fehlercodes:

    - In parallel, nochmals mit anderen source-IP versucht (ipv4/ipv6, aber auch local IPs LAN/WLAN/VPNs)

    - DNS auf neu probiert, *in parallel* von meherere DNS (wenn es meherere eingestellt sind)

    - HTTP-DNS versucht

    - Mit OS- functionen (strace) sockets force-closed und neu opened

    - Noch laufenden background requests force-closed

    - Ein error-meldung gezeigt an den user, aber sonstdem noch immer weiter im backgruond neu sockets versucht zu offnen, ips heraus zu finden, und expoinential-backoff retries

    - Http requests mit HTTP1.0 versucht stat 1.1


    Ja wie das alles und in welcher weise und was exact das OS selbst macht und was den browser exact sebst macht das hab ich nicht vollig studiert.

    Aber, normalen TCP/IP Linux/PC software ohne http libraries, bleibt oft bei ein einzelne gethostbyname anruf mit IPv4, ein ein einzige socket anruf, und das reicht fur 90% aller datacenter software. Bei ein TCP timeout wird entweder ein error gelogd und folgt kein retry, oder es folgt ein absturtz.

    Android / IOS sauber? Sicher nicht nee. Fast alles nur Junior programmer


    Aber wie ich selbst oft mit meine einge apps mitgemacht habe beklagen sich Kunden uber standig-crashende apps wenn man den Garten in- und aus lauft. Das hab ich fur meine Desktop apps niemals gehort. Und, wenn es genugend leute sich beklagen wird es linksum order rechtsum ja "gepatchet". Standart Andoird Junior dev style: Alle network-events => app restart. Functioniert besser als nichts, boss = happy.


    Aber die > 1Million user apps wie WhatsApp, YouTube, Browsers, banking apps, google apps, instagram, usw usw haben tatsachlich ganz complexe netzwerk-recovery sachen on-board.


    Fur Linux, PC sind es in meine erfahrung nur den Browser die solche complexe netwerk sachen haben

    Schau dir z.b. mal ein network-capture mit Wireshark an von ein browser wenn das netwerk fehlt. Unglaublich was es alles versucht wird wieder auf neu verbindung zu bekommen, meiner meinung jedenfals.

    Ist das so? Dein Android (also Linux) hat einwandfrei funktionierendes WLAN, Deine Fritzbox (also Linux) hat einwandfrei funktionierendes WLAN, Dein Fernseher (also Linux) hat einwandfrei funktionierendes WLAN.umchal


    Wird also wohl auf den Hersteller und die konkreten OSS-Entwickler jeweils ankommen.

    Android hat so gut functionierenden WLAN weil das umschalten zwitchen 3G/4G basestations und wifi ein fundamentelen basis function ist was ganz viel und mit unglaublich viel aufwand getestet wird.

    Alle pro- android/IOS developers wissen wieviel muhe man machen muss alle OS-events rundum netzwerk-anderungen bei zu halten usw, und wie anders es ist fur Android/IOS ein always-connected app zu bauen als fur PC / Linux - mit netzwerk retries, 100en von fehlertypen usw.


    Fritzbox hat *selbts* vielleicht als AP gutes WLAN, das reicht leider nicht fur den combination von client + Fritzbox.


    Den meisten fehrnseher sind nicht Linux, sondern Android und sind am meisten basiert auf Android apps mit unglaublich viel mehr fehler-detect und workarounds als standart Linux software.


    Zum beispiel: Fast alle linux software macht ein Berkley-sockets "bind" anruf beim aufstarten. Das functioniert leider *nicht* wenn dein IP etwas spater andert. Fur Linux, PC apps unterstuzten fast alle apps keine IP anderunden weil das program lauft, mus neu gestartet werden


    Fur android, IOS, unterstutzen fast *alle* apps IP anderungen weil das program lauft, oder her-startet das app sichselbst immer.


    Uber treiber, du hast recht, hangt ab von hersteller und entwickler.

    Aber am meisten hangt das ab von *gut documentierten* hardware-probleme, so das ein entwickler dafur ein work-around machen kann. Genau diese "Documentation errata" sind enorm seldsam, weil es ja den Hersteller nichts bringt solche documente zo produzieren und damit seine eigene fehler zu zeigen.

    Genau das ist das unterschied zwischen die meisten vendors, und auf welchen markets sie producten machen.

    ST und NXP haben gute reputation for hobbyisten weil sie solche documentation von hardware-fehler machen.

    Ich habe mich schon ofter den x86-code von mehrere USB-modul treiber wie WLAN, GSM usw in Windows angeschaut.

    Was seht man: Genau wie man sich gedacht hatte, gibt es oft ein USB-device crash-detector im treiber. Und wenn so ein crash detectiert wird, sendet den PC ein magic-combo von bytes zur USB-WLAN device das das ding ein hard-reset durchgeht und auf neu gestartet wird.


    Die open-source treiber fur linux, sind meistens nicht von dieselbe teams gefertigt als die Windows treiber, sondern von freiwilliger. Solche treiber machen meistens nicht solche not-losungen wie die closed-source treiber machen.


    Resultat ist das indertat Linux usb und andere nicht-datacenter hardware, keine hardware-bug-workarounds haben und nicht so stabiel functionieren.

    Genau das ist halt der Vorteil des SD2IEC, es belegt nichts am C64, genau wie ein Floppy Laufwerk.

    Stimmt.


    Ein oft nicht erwahnten nachteil des SD2IEC ist das es ein externen 5V adapter braucht, das fugt noch 5-10 euro kosten zu.


    Und fur mich personlich ist den UNO2IEC auch eine gute losung: Den billigsten losung um for cross-compiler experimente ein PC uber USB am C64 zu verknupfen.

    Nur ~ 2 euro (incl versandkosten) von der Chinaman incl. ein DIN-6 connector fur 0.20 euro.

    Ok, das heisst bei einem EasyFlash muss ich immer einen PC parallel zum C64 hochgefahren haben, damit ich mal schnell ohne flashen auf dem c64 ein Spiel spielen kann? Kann man alles machen...

    So weit wie ich es wisse:


    Fur EasyFlash, ja ist so. EasyTransfer auf den PC gebracht man sowohl fur flashen und fur direct aufstarten.


    Fur KFF kann man entweder direct auf den SD-karte PRG files setzten, CRT files, D64/D81 files, oder man verbindet mit USB und gebracht easyflash-tool um ohne flashen auf zu starten.

    Das KFF ist auch cool, keine Frage. Ich vermisse allerdings noch die Möglichkeit per USB Programme zu starten. Das finde ich weiterhin sehr komfortabel, gerade auch wenn man mal nur was ausprobieren möchte. Aber keine Frage ist ansonsten auch ne tolle Lösung.


    Das geht doch einfach mit den easyflash-tool (kff version)? Ich gebrauch das tool viel fur cross-compiler expirimente. Functioniert wenn KFF im menu-modus ist.


    https://github.com/KimJorgense…party/ef3utils/ef3usb.exe


    > Fakt ist, das ich auf ein EasyFlash, FinalCartridge, KungFu irgendwas keine 10.000 Spiele gleichzeitig draufkopieren kann, sondern immer erst flashen muss.


    Das gild nicht fur KFF. Alle images sind bei KFF direct auf den SD-karte.

    Alle d64/d81 starten ohne flashing.

    Alle cartridge images kleiner als 64kB wirden direct from ARM - RAM gestartet


    Nur die sehr kleinen set von vollig, grossen EasyFlash3 releases wirden zuerst von SD-karte im ARM-Flash programiert - das daert dan nur unter 1 secunde fur 1 Mbyte. Bemerkt mann fast nicht beim KFF.