Posts by 64erGrufti

Da wir die Tage zufällig auf das Thema gekommen sind, aber dort keine Antwort kam (keiner was wusste, die richtigen nicht gelesen?) erstelle ich hier mal einen extra Thread.

Kennt jemand ein Programm, mit dem man komplette Disketten kopieren kann, welches 2 Laufwerke unterstützt und in dem man die Laufwerksnummern auswählen kann? Hintergrund ist das Kopieren von Images von einem SD2IEC auf echte Disketten und umgekehrt. Es gibt dafür zwar Dracopy, aber das ist unglaublich langsam. Ich dachte, ob es nicht was schnelleres gibt? Leider war in meiner Sammlung von Kopierprogrammen nichts passendes zu finden. Wenn ein Programm schon 2 Laufwerke unterstützte, dann musste man die Laufwerke zur Identifizierung ab- und wieder anschalten. Das ist mit SD2IEC natürlich so nicht möglich. Man müsste also einfach die Laufwerksnummern selbst angeben können.

Ja, ist ein bissl blöd. Bei mir passiert es nur, wenn ich eine benutzerdefinierte Skalierung habe. Ich habe nun die Textskalierung benutzt, damit geht es.

Ist das nicht schon in der Wolke? Zumindest habe ich es irgendwoher. Ich habe es mal gezippt, dann passt es

Ja, wurde mir vom Augenarzt so empfohlen.

Quote from Bierminister

Wenn das mit DraCopy etwas länger dauert, macht das nichts.

Ja, besser als nix, aber ich hoffe immer noch, dass ich mal was besseres finde. Ich mache das bisher immer mit einem Adapter und der 1541 am PC. Das geht flott.

Ich habe das Problem, dass beim Klicken die Position des Mauszeigers nicht mit der Position überein stimmt, auf was reagiert wird. Man sieht das schon beim Charset-Fenster. Oben links lasst es noch, was gehighlightet wird. Unten rechts ist es ein Versatz von 1 Zeile und 2 Spalten. Ist das nur bei mir so, oder haben andere das auch? Gibt es irgendeine Lösung dafür?

Quote from Bierminister

Da war ich ja schon (Screenshot Beitrag #14). Ich kann aber im unteren Teil nichts machen. Jedenfalls komme ich da mit den Cursor-Tasten nicht weiter.

Wie @SkulleateR gewschrieben hat. Das ist ein Dateibrowser mit 2 Fenstern (mit irgendeiner Taste kann man auch die Aufteilung ändern, weiß ich aber gerade nicht, wie). Im einen Fenster das Diskettenimage auswählen, im anderen Fenster die reale Diskette. Das Fenster mit dem Diskettenimage auswählen (wichtig!!), dann F8 drücken.Dann fragt er nochmal, ob Du das wirklich machen willst und kopiert dann die Diskette Sektorweise. Das wird auch grafisch dargestellt. Dauert nur leider etwa 10 Min. Leider kenne ich kein besseres Programm, mit dem man das hin bekommt.

Quote from Magician

Nimm die üblichen Kopierprogramme. Dein SD2IEC ist wie ein Laufwerk

Welche können das? Ich stand auch mal vor dem Problem. Aber keines meiner Kopierprogramme ließ mich die Laufwerksnummer auswählen. Ich habe leider nur Dracopy gefunden. Das geht zwar (mit F8), aber ist unglaublich langsam.

Quote from kinzi

Wenn /EXROM=0 und /GAME=0, dann ist das interne BASIC abgeschaltet und es wird im Bereich des BASICs ($A000..$BFFF) das ROMH eingeblendet.

"Eingeblendet" heißt aber doch nur, dass für Schreib-/Lesezugriffe des Nutzers das externe ROM eingeblenet wird. Fürs aktive arbeiten mit Basic muss dann doch trotzdem das interne Basic verwendet werden.

Jetzt beim durchblättern habe ich gesehen, dass das ja wirklich nur Ersatzteilnummern sind. Das ist heutzutage natürlich nicht mehr so interessant. In der ersten Liste war das mit Explosionszeichnung und Angabe, welche Teile wo sind, interessanter. Aber evtl. hat sich am Gehäuse auch soweit nichts geändert.

Quote from Snoopy

Ich habe hier nur noch eine Ersatzteilliste von 1991 auf der Platte gefunden.

Wow cool. Danke.

Das wären vielleicht Dokumente für die Wolke. Ich hab da nur keine Erfahrung, wie man da was rein lädt. Ich finde es derzeit auch recht unübersichtlich, durch die Mehrfachverzeichnisse.

Sowas müsste es doch für die neueren Versionen auch geben. Da ich ein Assy 250469 habe, wäre eine Version dafür für mich interessant.

Quote from Markus64

Ich hatte was von Layoutfehler D0 gelesen

Der soll seit Rev.4 behoben sein, wie man auf der Homepage sehen kann. Da es keinen Schaltplan gibt, wo auch die Anschlussnummern drauf stehen, lässt sich das so leider nicht prüfen. Aber ich habe ja jetzt schon mal den Schaltplan von der THT-Version. Wenn ich nun aus der SMD-Version einen erzeuge, müsste ich das hoffentlich finden, wenn da noch ein Layoutfehler drin sein sollte.

Das mit ROMH soll laut Thomas so normal sein. Allerdings steht noch die Antwort auf meine Nachfrage aus, weil so ganz habe ich das nicht verstanden. Er schrieb jedenfalls, dass der C64 ROMH anspricht, um nach einem Basic zu schauen. Das würde ich dann so verstehen, dass der C64 bei einem 16K-Modul nach einem Basic schaut, wenn dort keines zu finden ist, benutzt er sein internes. Ist das so?

Dann habe ich mir nochmal die Memory Maps angeschaut. Dass das ROM nur bei ROMH aktiviert wurde, aber nicht bei ROML, würde ja eine Konfiguration 16K, LORAM=0, HIRAM=1,CHAREN=1 bedeuten. Das ist aber nicht der Standardwert. Da das ja dirket beim Einschalten passierte, müsste $01 bereits dort "manipluliert" werden. Gibt es da irgendwelche Möglichkeiten, über Leitungspegel $01 beim Start zu verändern, so dass der C64 beim Start in einer bestimmten Konfiguration hoch fährt?

Quote from Markus64

Dort mal die fertigen Images probiert?

Ja, aber das sind angeblich sogar die falschen.

AABER!

Zumindest für die THT-Platine hat sich das Problem vom Prinzip jetzt gelöst. Da war es scheinbar ein Platinenfehler. Nachdem ich ja, wie geschrieben, die im Layout eingearbeiteten Jumper durchtrennt hatte, musste ich wieder Jumper einlöten und - tada - plötzlich läuft es. Zumindest mal halbwegs. Mit dem Assy 250469 gibt es da scheinbar generell mehr Timingprobleme. Beim Einschalten startet der UC-Loader meinstens erstmal nicht. Erst nach Reset oder kurz aus- und einschalten kommt das Menü. Aber mit dem Timing sind wir gerade beim Kernelumschalter auch am experimentieren. Da gibt es nämlich auch Probleme, die mit dem alten Layout nicht auftreten.

Warum die SMD-Platine nun nicht läuft, weiß ich noch nicht. Da lst das testen auch leider nicht so einfach. Aber auch da werde ich wohl erstmal einen Schaltplan zeichnen müssen. Aber immerhin schon mal EIN Erfolg.

Ich habe jetzt mal den ROM-Inhalt ausgelesen und als BIN gespeichert. Dann zuerst die ersten 8K genommen und mit cartconv in ein CRT verwandelt. In Vice eingebunden und das Menü startet. Nun das gleiche mal mit 16K gemacht und schon habe ich den gleichen Effekt wie am echten C64, es startet nicht. Und das ist jetzt exakt das Image, was mir Thomas geschickt hat, was mit dem UC1.5 laufen soll.

Quote from kinzi

außer am Speicheroszi

Und genau damit habe ich geschaut.

Jetzt bin ich einen Schritt weiter gegangen und habe die Brücke von GAME durch gekratzt. Jetzt ist EXROM auf LOW und GAME auf HIGH, also im 8K-Modus. Jetzt kommt aber nicht UC-Loader, sondern das ganz normale Basic.

Quote from Jood

Genauer weiss das nur Diddl, aber soweit ich weiss startet das UC1 immer im 16K Modus.

Ja, im 16K Modus startet es auf jeden Fall. GAME und EXROM liegen erstmal auf LOW. Aber die geben doch nur an, welche Speicherbereiche an einem externen ROM liegen. Die Startprozedur, dass der C64 nach dem "CBM80" sucht und den Startvekor von $8000 lädt, müsste doch gleich sein. Würde er den laden, müsste aber ROML auf LOW gehen und nicht ROMH. Zumindest habe ich die Startprozedur bisher so verstanden.

Wohin wird der UC-Loader beim Start geladen?

Nachdem ich nun schon seit ein paar Wochen verzweifelt versuche, ein UC1.5 zum Laufen zu bringen, zuerst eine falsche Platine bekommen habe und nun mal einen Schaltplan zum nachmessen gezeichnet habe, bin ich auf einen (zumindest mir) seltsamen Effekt gestoßen. Beim Start wird ROMH auf LOW gesetzt. Ich hatte nach einigen Versuchen mal das Image auf ein EEPROM in einem einfachen Modul getestet. Dort konnte ich den Loader mit ROML starten, was ja wohl darauf hin deutet, dass er an $8000 geladen wird und auch für dort geschrieben wurde. Wenn er nun über ROMH geladen wird, landet er doch an der falschen Adresse?

Mal zur Geschichte: Ich hatte das Projekt "THT" in den Warenkorb getan, dort waren aber die SMD-Dateien im Projekt. So bekam ich die SMD-Platinen. Daraufhin habe ich mir die SMD-Bauteile bestellt und aufgebaut. Ergebnis: Schwarzer Bildschirm beim Start. Nachdem die Projektdaten berichtigt waren, habe ich mir nochmal die THT-Version bestellt und diesmal auch bekommen. Aber nach dem Aufbau stellt sich das gleiche Bild ein. Auch ein Test an einem anderen C64 (gleiche Baureihe) verlief genauso, was also den Defekt des C64 ausschließen lässt. Auch die ICs lassen sich bei der THT-Variante besser testen. Das ROM ist am Brenner auslesbar (ich habe schon AM29F040 und W29C020 und 29E020 probiert). Auch die 74273 sind laut TL866II in Ordnung. Das GAL dürfte auch OK sein, zumindest ist beim Auslesen das gleiche drin, wie rein geschrieben werden sollte. Auch ein selbst geschriebener Logiktest wird bestanden. Da es ja leider keinen Quellcode gibt, musste ich mich dabei auf das Decompilat verlassen, was aber bei dieser GAL-Variante 100% funktionieren soll und vom Code her auch logisch klingt.

Da exakt der gleiche Fehler bei der SMD- und THT-Variante auftritt und nur das ROM wieder verwendet wird, davon aber 3 Chips getestet wurden, würde ich einen Hardwarefehler eher ausschließen. Mich macht der Zugriff auf ROMH dabei stutzig. Ich kenne den Ablauf beim Start nicht, aber meinem Verständnis nach müsste er doch erstmal $8000 laden und dort starten, oder liege ich da falsch?

muffi Übrigens noch ein Hinweis: Mit Thinapp habe ich das schon gemacht, mit Cameyo sollte das aber auch gehen, da es auf dem gleichen Grundprinzip basiert. Aufgrund der Virtualisierung ist es sogar möglich, 2 unterschiedliche Versionen eines Programms völlig unabhängig gleichzeitig zu starten. Mit PortableApps ist das aufgrund fehlender Virtualisierung natürlich nicht möglich.

Quote from muffi

Danke, den AppCompactor habe ich gefunden! Den Wizard habe ich auf github gefunden.

Wie schon geschrieben. Das ist sehr manuell. Man muss das zu packende Programm genau kennen, was es macht, welche Dateien und Registry-Einträge dazu gehören und wo es hin speichert. Das alles muss man dann in der Konfigurationsdatei angeben und dann das Paket daraus machen. Viel Handarbeit, kein Wizard, wie es bei Cameyo ist. Außerdem ist das ein völlig anderes Prinzip.

Cameyo und Thinapp analysieren die Änderungen im Installationsprozess, machen ein Paket daraus und leiten später beim Starten der Anwendung die Schreibzugriffe um. Deshalb ist es auch nicht wichtig zu wissen, wo die Pfade des Programms sind. Die Schreibzugriffe werden sowieso umgeleitet (in den konfigurierten Hauptpfaden, die Pfade lassen sich konfigurieren) und somit auch evtl. Schreibzugriffe, die nur in bestimmten Situationen erfolgen.

PortableApps "installiert" die Anwendung im System beim Starten, startet sie dann und beim Beenden werden die Änderungen kopiert und die Anwendung wieder "deinstalliert". Ist die gleiche Anwendung bereits auf dem zu nutzenden Rechner installiert, werden die Dateien, Pfade und Registryeinträge beim Starten umbenannt und hinterher wieder zurück umbenannt. Deshalb ist es auch extrem wichtig, dass man alle Dateipfade und Registryeinträge der Anwendung genau kennt und angibt, um Komplikationen mit einem bereits installierten Programm zu vermeiden. Da gibt es natürlich Probleme, wenn man einen Speicherort vergessen hat, weil dieser nur in bestimmten Situationen geschrieben wird, und man dies nicht bemerkt hat. Das ist also nicht wirklich einfach. Dafür fallen mögliche Probleme durch die Umleitungstreiber weg, da es diese nicht gibt.

Bei Thinapp gibt es gerne mal ein Update, wenn es ein neues Windows-Release gibt und die alten Pakete erst wieder dafür neu gepackt werden müssen. Ansonsten finde ich Thinapp echt super und einfach. Aber eben leider nicht kostenlos. Mit Cameyo hatte ich, obwohl es eine recht alte Version ist, noch keine Probleme festgestellt.

Edit:

muffi Dieses Video hatte ich mir dafür auch gespeichert. Da wird das auch erklärt.