Posts by tRITON

    Diese Stecker lagen damals sogar dem Amiga 3000 bei. Aber wie Decay schon schrieb, brauchtest Du damals schon einen Monitor dafür, der das Syncen konnte. NEC MultiSync war damals meine Wahl, auch, wenn der Monitor damals gegenüber anderen Geräten viel teuerer war.

    Ergäntzt durch den "Mangel" an Vektoren und den knappen Speicher beim 6502 wird das sehr dünn für eine reine Software Lösung.


    BRK/IRQ Teilen sich ja einen Vektor. Jedes größere Programm wird aber den IRQ Vektor nutzen, für Routine Aufgaben, wie Ton oder Ein-/Ausgaben zu nutzen. Dazu noch das fehlen einer MMU, welche den Speicher für Software nicht mehr beschreibar macht, sind für eine Software Lösung nicht die einfachste Umgebung beim 6502.


    Mit dem 68000er und seinen vielen Vektoren 7 Hardware + noch mehr in Software, plus dem riesigen leeren Speicherbereich (16MB) und seinem wenigen vorhanden RAM (früher 512KB) konnte man ja gut sein Programm irgendwo verstecken. Ein tolles Beispiel hierzu finde ich hier für den Amiga den BeerMon. Hierzu gab es eine kleine Platine zu nachbauen. Diese stelle RAM bereit in welchen man den Monitor laden konnte und dann per IPL Taster anspringen konnte. Gerade genügend RAM für den Monitor und auch nicht automappend. Wer nicht wusste, dass er danach suchen musste, fand diesen Speicherbereich auch nicht.


    Später mit 68020 und der MMU dazu 68851 oder noch später mit 30er inkl MMU konnte man den RAM Zugriff abfangen und darauf reagieren per Software, wie auch bei den x86ern, wie oben bereits geschrieben.

    Ich denke, Du hast mit deiner Vermutung recht, wenn man sich die Sources zum Microsoft Basic ansieht:


    https://www.pagetable.com/?p=774


    Dort ist ebenfalls diese "ungewöhnliche" Schreibweise anzutreffen. Ich frage mich, was zu der Zeit dann der Assembler der Wahl war?

    Im Artikel steht ja was von Macro-10, welcher wohl für Microsoft Basic, also CBM Basic genutzt wurde.

    Wieso sollte das Modul schäden verursachen? Es ist ja eine Speichererweiterung (3k) + erweitertes Basic, mehr nicht.


    Wenn du den Expander drinnen hast ändert sich ja das Fehlerbild. Wild Teile tauschen oder Sockeln bringt da nichts. Es wird ja mit dem Expander besser nicht schlechter.


    Vermutlich ändert sich was, wie ich schrieb, weil der Basic Start in den Speicher des Expanders verfrachtet wird und der Speicher der sonst bei $1000 vorhanden ist wird zum Bildschirm speicher. Hast du "komische" Zeichen auf dem Einschaltbild mit dem Modul zusammen?

    Ok, also die alte Revision, dort hast Du ja dann insgesamt 9 RAM Chips ....


    Was war das denn mit dem Courser ... Der blinkt nicht und du kannst nichts eingeben? Was interessant ist, das der Rechner ja scheinbar richtig initialisiert mit dem Expander ...


    Das bringt mich gerade auf eine verückte Idee:


    Wenn Init mit Expander (also zusätzlichem Rom) und dann Crash, könnte es das Basic Rom (901486-01) sein, welches defekt sein kann. Das Kernal startet die Kiste. Hast Du ein Spielmodul da zum testen? Die Dinger brauchen ja meistens nur das Kernal. Das Basic gibt es so weit ich weiß nur in einer Version sowohl für NTSC, als auch für PAL

    Es könnte ein Speicherfehler sein in deinem VC-20. Bei dem Superexpander hast du ja 3k weiteren Speicher. Das führt ja auch dazu, das die Memorymap sich ändert Basic $1000 -> $1200 und Screen $1E00-$1FFF -> $1000-$11FF


    Wenn der Speicher in de letzten 1K Block ist ( 2k+2k+1k) ... Muss aber jetzt echt erst mal gestehen, das ich nachsehen muss ob der Speicher so rum oder 1k + 2k+ 2k in dieser Reihenfolge angesprochen wird.

    Wenn es ein älteres Modell ist ist der interne Speicher noch mal anders aufgebaut.

    Möglich ist das. Ich habe jedenfalls, wann immer möglich, neue ST-x Disks beschafft. Einen Digitizer konnte ich mir damals nicht leisten oder wollte es nicht :) ...Einen DX7 habe ich damals auch noch nicht bessesen, heute schon ;) . Die Zeit mit den ganzen Samples hat aber zumindest bei mir nicht lange angehalten. Spannender fand ich dann den Weg hin zu den Chiptunes, also dann doch wieder "gequitsche" erzeugen, anstatt Samples zu nutzen. Dennoch kann ich mich gut daran erinnern lange mit den Samples rumgespielt zu haben oder auch Module zu rippen und Samples daraus zu holen, um sie selbst zu nutzen. Wo die her kamen, war mir damals eigentlich egal, hauptsache passten zu dem, was ich machen wollte :)

    Oft starten die Schaltnetzteile mit einer kleinen Bootstrap Schaltung. Der Kondensator der dafür zuständig ist hat daher eine wichtige Funktion, um das Netzteil zustarten. Wenn dieser je nach Freuquenz mit der er angestuert wird eine abweichende Kapazität hat gegenüber der Messung, kann es zu obigem Problem kommen.

    Testest Du den Kondensator also mit einer Frequenz die nicht zu der der Schaltung passt, kann es sein, das du Werte angezeigt bekommst, die Ok scheinen, aber innerhalb der Schaltung nicht mehr ausreichend sind.


    Die Elkos auf der primären Seite erfahren ja meistens nur 50-120Hz mit der die Ladungen da reingepumpt werden. Auf der Sekundendären Seite kannst du aber schon mal 1k+ Hz haben. Daher haben diese Kondis dann deutlich mehr Stress und altern daher auch schneller. Das führt dann dazu, das oft alle Elkos auf der primären Seite noch Ok sind auf der Sekundären Probleme machen.

    Du hast glaube ich nicht ganz verstanden, was die Verzögerung bewirken soll. Du sollst nicht dein Programm verlangsamen und damit uneffektiv machen, sondern der Rasterint muss 50/60 mal/Sekunde durch laufen. Verlangsamst Du also alles, flackert es weil der Bildschirmaufbau nicht nach kommt.


    Was du aber machen solltest, ist z.B. einen Zähler auf 50 zählen zu lassen 1x pro Raster IRQ. Wenn Du 50 erreichst, dann lässt Du dein Scrolling um eine Position weiter laufen. So scrollst du um einen Pixel pro Sekunde (was viel zu langsam sein wird, aber einfach nur mal als Beispiel)


    Pseudo:


    Lade Wert aus Variable

    erhöre um 1

    vergleich mit gewünschtem Wert (BEQ wert passt)

    wert kleiner, dann nicht weiter in der Scroll Routine (RTS)

    wert passt: Wert auf 0

    Scrollen


    Was Du dann z.B. machen kannst bei bestimmten Zeichen im Text ($ff, $fe, $fd) in der Scrollroutine reagieren und somit auch verschiedene Geschwindigkeiten einstellen, indem du deinen Variablen andere Werte zuweist. Wenn du sehr große Fonts nutzt, dann
    kann es ja z.B. auch sein, das Du mehr als 1 Pixel/Sekunde scrollen willst.

    Mit einem Oszilloskop wäre es jetzt einfacher etwas zu sagen.


    Was genau bedeutet "Fehler ist immer noch da?" ...


    Du hast alles wieder eingelötet, Baustein rein und wieder an den Rechner gehangen?


    Wenn Du U16 raus läßt, sollte die Floppy keinen Einfluss mehr auf den Bus haben und z.B. Device not present error am C64 ausgegeben werden. Wenn das so ist dann ist U16 defekt oder der 6522 dahinter.
    Den U16 könntest Du ja noch per Hand testen mit etwas Mühe. einfach abwechseln +5 und GND an die Eingänge und den Ausgang jeweils messen. Nur weil du ihn ausgetauscht hattest muss der neue ja nicht Ok sein.

    Grundsätzlich richtig. Wenn der Pin aber erst mal in der Luft hängen würde, könntest Du noch mal omisch messen von der Buchse nach +5V und Masse, ob es dann noch Verbindung gibt. Was eigentlich nicht sein sollte, solange dann die beiden Bustreiber raus sind. (U15,U16).


    Falls du jetzt immer noch einen Widerstand messen solltest, dann könnte in der Tat was nicht mit der Buchse i.O. sein.

    5V sollte +-10% ok sein 4,97V scheint mir daher OK.


    Auf dem Bus passiert so weit ich weiß folgendes: Die Floppy willst Du ansprechen dazu wartet das Gerät darauf, das die Clock Line wieder auf 5V hoch geht. Ich wette, das die bei Dir immer bei 0V (oder weniger als 2.5V) hägen bleibt und daher der Rechner ewig auf das Gerät wartet.


    Könntest Du dort mal messen, wenn kein C64 angeschlossen ist und bitte einmal, mit C64? An Pin 4 liegt das Signal an, daran hängen RP1-3, U16 Pin 6, U15 Pin 3. Dort sollte eigentlich überall der selbe Wert anliegen. Wenn Du U16 und U15 entfernt hast, dann sollten dort ca. 5V sein, ohne einen C64

    Schau mal im Schaltplan gibt es nicht viel, wie ich schrieb. Mess doch mal mit nem Multimeter ob Du bei den Ferritperlen Kurzschluss zu Masse (EMI1-3) hast oder ob die Widerstände (1k) (RP1-4, RP1-3, RP1-2) nach 5V und R36 (Reset) , ebenfalls 1k, noch ihren Nennwert haben. Es gibt noch EMI4 in der FAST CLK Leitung den habe ich gerade vergessen.


    Roman

    Nimm doch mal U15, U16 raus. Die hattest Du ja gesockelt und hänge die 1571 an den Rechner. Friert der dann immer noch ein?


    Wenn ja, dann gibts glaube ich nur noch ein paar passive Komponenten die am Bus hängen, wie die Feritperlen oder die Pullup Widerstände.


    Evtl ist dann dort was im Argen. Wenn die Floppy so den Bus nicht mehr "sperrt", dann hängt hinter U15,U16 der U9, also der 6522. Dann macht der etwas auf dem Bus.