Posts by Jotta

    I don't see any pullup resistor on the BA line

    A pullup is not necessary, because this signal is already driven by BA.

    This is not the case for "your" DMA-Line, it's undriven.


    A first sight would lead to the opinion, that the BA/AEC-designpart

    in the schematics is a misscontruction, because it doesn't let you

    act like a VIC on the bus. But this is not true, due to the fact, that

    the VIC is unstopbable and the BA-Signal has several jobs like driving

    a PLA-Pin etc. And just pulling the BA down ruins the whole bus timing.

    Instead of connection BA (or AEC) to GND, try to pull it down with many-K-Ohms

    to GND and observe, what happens to the signals. If these Pins are OpenCollector-

    resp. OpenDrain-Pins, the signals go down to GND.

    Zummindestens softwareseitig macht ein fehlender SID keine Probleme, der KERNAL

    läuft problemlos drüber weg (Ausnahme ist ein fehlender VIC-II, bei dem Register in einer

    Schleife abgefragt werden, d.h. die Schleife wird nicht verlassen!).

    Hardwareseitig dürfte eiglich auch nichts passieren (ausser eben fehlender Sound),

    aber ein IC falschrum richtet wahrscheinlich irreparable Schäden an (hatte meinen VIC-II

    so geschrottet).

    Also betrachten wir das doch mal ganz konkret:


    Ich generiere einen Sinus von 50MHz, der also aus 100 Millionen Halbwellen je Sekunde besteht.


    Ich nutze dazu einen Arbiträrgenerator, der IM SCHNITT jede 100. Halbwelle weglässt, jedoch zufällig und NICHT GLEICHVERTEILT im Abstand.

    Kein Problem, siehe Bilder.


    Kurze Erklärung (ledes der Bilder enthält mehrere Tausende Waveforms):

    - Bild1 zeigt "digitale" Signale, der Trigger kann z.B. bei 10% der Zeitachse

    gelegt werden und ist so ab 70% der Zeitachse wieder scharf, d.h. eine Waveform

    wird also teilweise zweimal angezeigt, d.h. kein Datenverlust und damit kein

    übersehener Fehler.

    - Bild2 zeigt mittelfreq. Sinus-Wellen, überlagert von einem hochfreq. Sinus-Wellen

    (fast ausserhalb der Bandbreite).

    - Bild3 zeigt in Etwa dein Szenario, ohne viel Mühe erkennt man den Fehler.


    Du kennst dich zwar unbestreitbar in einigen Feldern rund ums Oszi gut aus,

    deine Vorstellungen bzgl. Digital-Oszi sind aber start ausbaufähig: Daten werden

    in einem DSO idR nicht an die CPU weitergereicht und von der gezeichnet, sondern

    z.B. wie bei mir von einer complexen FPGA-Logik (bei mir: in zweistelligen GigaPixel

    Bereich, füllt etwa 80% des FPGAs). Mit entsprechender Triggerlogik (mehr als nur

    einfache Übergänge, z.B. Definition von ganzen Bereichen) kann man die perversesten

    Trigger definieren. Damit übersieht man wirklich nichts Denkbares mehr.



    Was dein 50Mhz-Signal bei 250MS/s angeht: für C64 oder Amiga total uninteressant,

    Signale haben max 25MHz, evtl. mal Glitches, aber die erkennt man auch bei 250MS/s.

    Was mich am Owon HDS272 stört, ist der relativ kleine Speicher von 8KSamples, das

    ist sehr knapp.


    60 vs. 500.000 beim analogen Oszi!

    Was für eine Bildschirmtechnik steckt denn in einem analogen Oszi?

    Das ist einfach nur ein phosphorbeschichteter Schirm, der von Strahl

    zum leuchten gebracht wird.

    und spiegelnden Display -dem ich im Übrigen die behaupteten 10.000 Bildwechsel (das wäre 0,1 ms für einen Bildaufbau!) absolut NICHT zutraue-

    Es sind nicht Bildaufbau/sec, sondern wfms/s. Und 10.000 als Wert sehe ich in keinster

    Weise als unrealistisch und hat nichts mit dem Display zu tun (mein Oszi z.B. ist ein

    Welec W2022A - schau mal auf mikrocontroller.net nach - das mit meinem Design/SW

    etwas über 1.000.000 wfms/s schafft, das entgeht mit kein Fehler!)

    Aztec Challenge fällt vlt. nicht unter "nicht schnallen", ein Level ist aber auf einem

    Schwarz-Weiss-Fernseher unspielbar, zummindestens hatte ich es damals nicht

    geschnallt. Man muss durch einen Fluss voller Piranias schwimmen, kann aber l

    eider wegen der Farbwahl die Piranias vom Wasser nicht unterscheiden. Es gab

    mal einen Poke, der die Farben geändert hat. Damit soll's dann auch geklappt haben.

    (zu TIA: schau mal hier nach, aber kleine Warnung: ist wegen Python extrem

    langsam EDIT: PIA ist leider nur SW, ist aber auch kein für eine exakte Simulation

    so wichtiger Chip)


    zu Subgraphisomorphismus: ich selber hab's einfach per Graphensuche gemacht.

    Dazu muss man nur die Netzlistenelemente und ihre Verbindungen untersuchen

    und die Gleichungen aufstellen (NOT, NOR, NAND etc.). Hat aber den Nachteil,

    dass z.B. Latches im Meer von Gleichungen untergehen und dir dein Compiler

    eine "Latch-Warnung" ausspuckt. Was aber kein Problem ist, du willst ja Latches

    haben. Allerdings wären explizite Latches mit entsprechender HDL-Zuordnung

    besser.

    Und genau hier ist z.B. ein Isomorphismen-Ansatz besser: du gibst "bequem" alle

    Typen als Beschreibung vor, und falls dein Algorithmus einen Transistor nicht

    zuordnen kann (lässt sich ja leicht ermitteln), dann lässt sich lokal manuell der

    neue Typ ermitteln, zum Algorithmus hinzufügen und die Suche beginnt von

    vorne. Wenn du also etwas Stabiles, Erweiterbares suchst, wird das wohl die

    beste Wahl sein.

    Das mit der manuellen Umwandlung in ein Vektorformat habe ich mir fast

    schon gedacht, ist wohl vergleichbar kompliziert wie OCR etc.


    Die HDL-Umwandlung habe ich auch mal versucht, aber wie gesagt, leider

    an komplizierteren Konstrukten wie Latches schon gescheitert. Hab aber

    auch nicht viel Zeit investieren können.


    Kennst du Seiten wie diese hier? Da gibt's neben kompilerbarer C++-SW

    auch fertige HDL-Beschreibungen. Eben diese habe ich mal in einem VC-20

    eingesetzt, funktioniert perfekt. (und btw.: eine TIA-Beschreibung existiert

    ebenfalls, d.h. ein 2600er kann damit perfekt nachgebildet werden. Auf

    Visual6502 lässt sich auch die ARM1-Netzliste auslesen und umwandeln,)

    Mit ReverseEngineering auf Chipebene bin ich so gut wie nicht vertraut:

    - Du hast also eine SW, die dir die einzelnen Layer in Vektor-Format umwandelt.

    Davon gibt's ja für viele Einsatzbereiche entsprechende SW.

    - Die Vektor-Beschreibung muss aber dann in eine Netzliste umgewandelt werden.

    Hast du die SW dazu selbstgeschrieben?

    - Und zum Schluss: hast du auch eine SW, die die Netzliste in HDL umwandelt.

    (ich hatte mal vor Jahren einen Blog gelesen, in den der 6502 per

    Graphenisomorphismen in HDL umgewandelt wurde. Das Ergebnis lässt sich

    ohne Probleme auf einem FPGA zum laufen bringen. Ich hab's auch mal versucht,

    aber leider nicht alle Latches erkannt :((( )

    What is wrong here?

    You compare value 1 with a zeropage location, that itself is not

    wrong. Your problem is, that nobody changes the value in this

    location as long as your loop runs. I guess it's like with the C64

    Kernal, some routine do some calculation and stores a value

    in that location and exactly that routine should be called at the

    beginning of your loop or in some way via interrupt.


    (I guess that solves your problem, my first thought was, that

    this was related to some HDL-Design Error)

    Eine wesentliche Einschränkung bzgl. Geschwindigkeit ist ja die Tatsache,

    dass BASIC-Listings mehr oder weniger unverändert und ohne Zusatzinfos

    abgespeichert werden.

    Zahlen werden nicht in ein "maschinengerechteres" Format umgewandelt,

    eine Vorverarbeitung findet nicht statt, Aussnahme ist die Tokenumwandlung

    der Befehle. Würde man z.B. Zahlen umwandeln, dann könnte man sie ja

    beim Ausgeben des Listings idR nicht mehr rekonstruieren. Es sei denn, sie

    würden im Listing zusätzlich hinzugefügt, was aber auch nicht so einfach ist,

    auch im Hinblick auf Speicherplatz.

    ist das viele Schwarz drumrum eigentlich rein technisch bedingt oder macht das auch den Reiz des Spiels aus? Also waere das Spiel besser wenn man die komplette Landschaft sehen wuerde

    Zum einen sicherlich aus Performancegründen, zum anderen, und wohl der Hauptgrund

    um Clipping zu vermeiden. Du siehst ja immer eine komplette Kachel.


    Es gibt aber mittlerweile Zarch-Adaptionen, die denn Bildschirm komplett ausfüllen,

    schau mal bei Youtube nach.

    aber ob die FPGAs defekt gehen wissen wir derzeit noch nicht, kann ja sein die sind so toll dass sie in 35 Jahren noch laufen, und so wie ich die Bastler in der Retro-Szene kenne, wird es IMMER irgendwie einen Weg geben, irgendwas wieder hinzubekommen.

    Meine aktuell ältesten FPGA-Boards sind schon mehr als 15 Jahre alt (d.h. von mir in Besitz,

    idR gebraucht gekauft und schon vorher benutzt) und laufen noch immer perfekt. Ein Beispiel

    ist ein altes Stratix1-Board (Nios-Std.Edition) mit 5V-toleraten IOs. Damit habe ich schon zig

    Chips analysiert und zig Retro-FPGA-Designs getestet (d.h. ein paar Hundert mal verwendet)

    ist also ständig in Gebrauch.


    MMn ist der einzige Schwachpunkt an den meisten FPGA-Board der Flash-Speicher, der sich

    nicht beliebig oft beschreiben lässt. Das lässt sich aber ohne Probleme handeln.


    Aber die FPGA-Geschichte teilt sich ja in 2 Aspekte: Die Hardware, wie eben beschrieben und

    die Software. Zur Software kann ich nur sagen, dass sie auch noch in 10 Jahren mit eher

    kleineren Problemen auf neue FPGA-Familien übertragbar sein wird. Da habe ich überhaupt

    keine Bedenken. Und damit wird ein defektes Board kaum ein Problem sein.

    Dann präzisiere deine Frage doch bitte nochmal ganz genau

    Die Frage lässt sich nicht in einem Satz fassen, es sind der Schaltplan

    und mehrere Bemerkungen notwendig:


    - durch den 16MHz-Takt und den Taktteiler wird ein Takt T_div und

    mehrere Signale erzeugt

    - T_div (und weitere Signale) steuern die Shift-Register für Lese-

    und Schreiboperationen

    - T_div wird ebenso vom 2. 9602 gesteuert (genauer gesagt: Resettet)

    - im Prinzip wird der Taktteiler durch den 9602 getaktet, die Frequenz

    aber auch durch die beiden Bits beeinflusst

    - direkt hinter dem Taktteiler ist eine Logik (mehrere Chips), die

    dafür sorgen, dass nur eine bestimmte Menge an Bits einen gleiche

    Wert haben (siehe GCR-Codierung etc.). Diese Logik wird ebenfalls

    von Signalen des Taktteilers gesteuert.


    Der letzte Satz der letzten Bemerkung führt für mich zu der entscheidenden

    Frage: Kann die Logik (und das daran anschliessende Shiftregister) durch

    eine ungünstige Konstellation (= Abstand Taktflanke nach Taktteiler und

    Ausgang 9602 sowie die beiden Bits 5 und 6) zu einem Fehlbit führen?

    Im Buch steht nur (sowie in mehreren Foren und Blogs), dass die Taktung

    durch den 9602 erfolgt, es ist aber eben nur eine Behauptung.


    Ich muss bemerken, und damit möchte ich mich nicht rausreden, dass ich

    mich nur alle paar Jahre mit der Materie beschäftigen kann und deswegen

    viele Details vergesse und auch nicht alles Denkbare bis jetzt durchgetestet

    habe. Im Bild sieht man z.B. 2 Floppies, das eine schreibend, das zweite

    vom ersten lesend. Wenn ich mal wieder dazu komme, werde ich auf jedenfall

    dieses Szenario durchtesten.

    vielleicht helfen dir noch diese Bilder & Infos hier.

    Die Infos kenne ich schon lange, beantworten aber nicht

    die heiklen Fragen bzgl. Syncronisation (die Infos ergeben

    sich auch aus den Seiten meines Links von Oben). Meine

    erste Behauptung sollte vlt eher eine Vorsichtsmassnahme

    sein, sollange man nicht sicher ist.

    Muss leider widersprechen ... der Lesevorgang geht von der Taktteilung her mit einer *fixed rate*.


    Kann man in diesem Buch hier nachlesen ...

    Muss nicht unbedingt ein Widerspruch sein: In dem Buch (Seite bei mir 204?)

    sieht man ja, wie der Taktteiler (2 Chips) sowohl vom Systemtakt und den

    beiden Bits als auch vom Sharpener (2 9602er) gesteuert werden. Da der

    Systemtakt und die geschriebenen Bits ja idR nie synchron laufen, wird

    zum Reseten der Teiler der letzte 9602 verwendet. Und damit stellt sich die

    sehr wichtige Frage: Kann das Taktverhältnis (Schnell:16 zu langsam:13)

    und ein ungünstiges Verhältnis des Taktes und des Bits auf der Floppy zu

    einem Fehlerbit führen? Diese Frage wurde in all den Forenbeiträgen, die

    ich bis jetzt gelesen habe noch nicht beantwortet. Es kann aber sein, dass

    die ungünstigsten Konstellationen nicht zu Fehlerbits führen, d.h. du im

    Prinzip recht hast, ich weiss es jedenfalls nicht (ich habe eine komplette

    HDL-Simulation samt aller beteiligten diskreten Chips, allerdings noch nicht

    die Zeit gefunden, alle möglichen Konstellationen durchzuspielen). Der Link

    von mir weist auf eine Seite, auf der mehrere Rechnungen in der Richtung

    gemacht wurden. Einige von denen sind aber falsch, kann ich jedenfalls mit

    meiner Simulation zeigen.

    Die Bits 6 und 5 in $1c00 legen ja die Schreibgeschwindigkeit der Magnetisierungswechsel in der 1541 fest.


    Gilt dies nur für den Schreibvorgang?

    D.h., beim Lesen sind diese Bits in $1c00 irrelevant, da der Timer im Controller ja durch die 1er Bits / Magnetisierungswechsel getriggert wird?


    Ich würde es anders formulieren: die beiden Bits steuern einen Taktteiler,

    der für Schreib- als auch Lese-Shiftregister als Takt dient. Von daher

    gilt der Zustand in Bit 5+6 für beide Richtungen. Schau mal hier nach,

    da sind zwar einige Fehler in der Beschreibung, das Wesentliche wird

    aber gut zusammengefasst.