From my personal perspective, if I were designing a core, I wouldn't see the ARM as an advantage but as an invitation to being lazy and push everything to the ARM CPU and the Linux kernel since I know software development best.
Do you have any experience with developing such a "mixed-approach" system?
Ich habe mal in einem anderen Forum gelesen, dass ein 1F Kondensator explodiert, wenn man ihn aus Versehen kurzschließt.
Das mag für die Coladosen-grossen Kondensatoren aus dem Autoradio-Übertreiber-Bereich stimmen, aber das Winzteil in der XBox ist ein Pufferkondensator für eine RTC und hat einen vergleichsweise hohen Innenwiderstand. Damit entlädt der sich selbst bei einem Kurzschluss nur langsam.
die USA fliegen seit 1955 mit der B52 durch die Gegend
Na ja, die verwenden aber nur noch weniger als 100 der ursprünglich gebauten 744 Exemplare, da hat man jede Menge über, die als Ersatzteilquelle dienen können.
The Arduino Mega has interrupts only on port D and port E
If you use dedicated interrupts for both ATN and CLK, nothing stops you from connecting the signals both to the IEC-dedicated port and to a pin on another port that can trigger a dedicated interrupt. It might need a bit of additional initialization code to set up the interrupt pin as input with pullup though.
Die max track Länge muss angepasst werden, sobald nur ein MFM Track geschrieben wird, bzw. das komplette image einmalig anhand der neuen max länge neu gebaut werden.
Schon, aber wenn ihr Bit 15 der Pro-Track-Länge als MFM/GCR-Marker baut, dann ist das fast eine Garaantie für einen Bufferoverflow in Nicht-MFM-angepassten Programmen. Die können sich ja darauf beschränken, einen Trackpuffer in der Grosse der MaxLen aus dem globalen Header anzulegen und wenn ein Track mit Bit15=1 als MFM markiert ist wird zwangsweise irgendwann über das Pufferende hinaus gelesen oder geschrieben.
At least ATN must be on a pin that can trigger an interrupt. If you want to use Dreamload, CLKin must also be on a pin that can trigger an interrupt. The code can use either a dedicated interrupt for both or a common pin change interrupt for the entire port.
There is another problem though: The ATmega2560 is a 22-bit PC device, which means it needs an additional clock cycle for (R)CALL and RET instructions compared to the AVRs supported by sd2iec. The low-level fastloader code is written in cycle-counted AVR assembly, so the timing will be off. I'm not sure if this change is big enough to throw off JiffyDOS, but it will almost certainly cause data corruption with Turbodisk.
Das Problem ist halt, dass existierende Programme mit den MFM-Tracks eh nichts anfangen können und eher die Gefahr besteht, dass sie durch die "übergrossen" Per-Track-Längenangaben crashen, weil vermutlich im Header immer noch die reguläre maximale Track-Länge drinsteht. Dann kann man das IMHO besser einmal richtig machen als es mit Tricks (aber doch inkompatibel) ins bestehende Format zu pressen.
Wenn es doch kompatibel bleiben soll könnte ich mir eher vorstellen, für MFM-Tracks eine weitere Offset-Tabelle (und ggfs. ein zweites Tracklängen-Feld) vorzusehen und den Offset für den jeweils "unpassenden" Datentyp auf 0 zu belassen. Für ein Nur-GCR-Programm sieht es dann so aus, als ob der Track leer wäre. Falls beide Offsets vorhanden sind sollte dabei GCR bevorzugt werden, falls das Image mal mit einem Nicht-MFM-Tool bearbeitet wurde. Aber auch so löst das natürlich noch nicht das Problem, wie man einen Track mit gemischten MFM/GCR-Daten darstellt.
(und wenn man G64 eh grösser umbaut könnte man mal die Speedzone per Bit einstellbar machen...)
Gideon hat sich in einer privaten E-Mail vorgestellt, dass weitere G64 Erweiterungen (also solche Sachen wie RAW MFM) dann zur Aktivierung Bit 14 der Träcklänge benutzen
Ihr habt aber schon mitbekommen, dass das G64-Format ziemlich an Anfang ein Versionsbyte hat?
Um zu wissen, dass man am C64 (o.ä.) eher sowas nicht in vertretbarer Zeit berechnen kann, braucht man gar nicht anfangen zu rechnen.
Ist aber ein weiteres Beispiel dafür, dass die Prämisse im Anfangsposting des Threads Blösinn ist: Wenn der Preis von Rechenleistung dermassen hoch ist wie postuliet, dann kann man 4K-Video komplett vergessen weil das nun mal eine gewisse Mindestrechenleistung erfordert um es in sinnvoller Zeit zu bearbeiten.
Es gab ne inoffizielle Ergänzung zwecks MFM.
Aber warum macht man das dann nicht gleich vernünftig und nimmt ein Flux-basiertes Format? Dann ist es egal ob die Disk mit GCR (Commodore, Apple, etc), FM, MFM, RLL oder sonstwas beschrieben wurde...
Japp, das error Byte im G64 ist darin auch irgendwie unterspezifiziert
Verwechselst du das evtl. mit D64? Bei G64 gitbs meines Wissens keine Error-Bytes weil die Fehler alle schon im Bitstrom darstellbar sind.
Apropos MM.
Ist das die stark zensierte Version?
Zumindest bei den Speichermedien gilt bei dem Gedankenexperiment ja...
Aber Speicher ist nicht alles. Mal so als erweitertes Gedankenexperiment: Wir nehmen Full HD 50fps-Videomaterial (1920x1080) in 4:2:0-Farbcodierung, d.h. gemittelt 1,5 Byte pro Pixel und wollen eine 1 Sekunde lange Blende zwischen zwei Videos berechnen. Dazu muss man für jedes erzeugte Frame beide Eingabeframes lesen, also zwei Lese- und ein Schreibzugriff pro Frame. Ausserdem nehmen wir mal zur Vereinfachung an, dass die CPU die eigentliche Berechnung unendlich schnell vornehmen kann und der Speicher ähnlich wie beim C64 mit 1MHz angesprochen wird. Dann braucht man alleine für die Lese- und Schreiboperationen 1920*1080*1,5*(2+1)*50 Speicherzugriffe.
Das sind ca. 466 Sekunden Speicherzugriffszeit für eine Sekunde Videolaufzeit und das für eine ziemlich simple Blendenoperation. Würde man die CPU noch mitmodellieren wäre es nochmal um einen ziemlich grossen Faktor langsamer, beim 6502 werden ja nur alle paar Taktzyklen Daten statt Befehle geladen. Da gibts auch nichts zu optimieren, die verfügbare Speicherbandbreite setzt dem ganzen ein hartes Limit.
Und das ist nur eine Blende - Videokompression ist algorithmisch um einige Grössenordnungen aufwendiger.
Ich habe mal modernes Lot versucht, huh, wenn das bei mir mit dem Lötkolben in Berührung kommt, habe ich grauen Dampf im Raum.
Das kommt vom Flussmittel im Lot. Das Zinn auf der schon gelöteten Lötstelle enthält keines mehr.
I wonder if early flat TVs have exactly this resolution or if they already have something that is a multiple of that
I don't think I've ever heard of a flat TV with a CEA (720x480/x576) resolution, not even as a plasma display. There are of course 640x480 which would be a square-pixel variant of the 525-line system ("NTSC"), but 625-line users (most "PAL" transmissions) were basically shafted. Coming from the CRT times with its 5-10% overscan, TV manufacturers also rarely cared about pixel-exact reproduction of the input signal anyway and instead continued to crop the signal borders long into the HD area.
Just get something with a sufficiently high resolution and a good scaler to minimize the artifacts caused by the pixel aspect ratio mismatch and non-integer scaling factors. Or use a CRT, which tends to have other issues (size, weight, power).
das RAMboard wird dann sowieso noch auf aktuelle SRAMs umgestellt.
Sind 16 MB SRAM nicht ziemlich teuer? Oder wolltest du auf PSRAM setzen?
Zumindest solange da keine Rasterzeileninterrupts programmiert sind, sollte man die Periodizität erkennen und die eigene Abfrage möglichst mittig zwischen zwei Durchläufen ausführen können.
Du kannst dich aber nicht darauf verlassen, dass alle zur Tastatur führenden Leitungen zwischen zwei Scans high sind, damit du eine eigene aktive Abfrage dazwischenmogeln kannst. Zum einen kann die Scanroutine im C64 die Leitungen in beliebigem Zustand hinterlassen (bzw. muss es sogar, um den richtigen Joyport für Paddles auszuwählen), zum anderen können Joysticks die Leitungen von aussen auf low ziehen und dir bei deinem Scanversuch dazwischenfunken.
Passiv den Tastaturscan mitlauschen und daraus die vermutlich gedrückten Tasten rekonstruieren geht natürlich immer.
but the output video signal is not NTSC or PAL since those kind of signals cannot drive a regular VGA monitor at least
There are monitors that can accept a 15kHz 50/60Hz RGBS/RGBHV signal over a VGA connector. There are also adaptor cables from a VGA connector to a SCART plug for connecting devices that can output such signals on a VGA plug to a regular European TV which can certainly accept such signals (but only rarely 31kHz VGA) via SCART.
(PAL and NTSC refer to color encoding standards, not video timings - an RGB signal does not use either of them, no matter what timing it uses)
Du willst, daß ich mich für einen Kernalumschalter in das Videosignal einschleife?
Da hat doch jemand schon vor längerem mal was vorbereitet: Overlay64
Also gibt es (ohne Umbauten) keine Möglichkeit festzustellen, an welcher Stelle sich der Loadercode gerade befindet, ähnlich wie es beim C64-Code nach einem Freeze der Fall ist?
Das Problem ist erstmal, dass es keine Möglichkeit ausser einem Reset gibt um den Loadercode zu unterbrechen - ein Freezer-Modul am C64 macht das durch Erzwingen eines NMIs und Einblenden des eigenen ROMs, aber das geht in einer 1541 ohne Modifikationen nicht.
Und der Kopf kann nicht so ohne Weiteres wieder an die vorherige (gesicherte) Position geschickt werden?
Dazu müsste man erstmal wissen, wo die Position denn gesichert ist. Für das normale Commodore-DOS ist das einfach, aber ein Loader kann das beliebig anders machen.
