Beiträge von markusC64

Nicht wirklich, da kann man auch das original CRT nach bin wandeln, die Startadresse $8000 voranstellen und flashen lassen. Als Startadresse gibt man $FCE2 an, und fertig. Der Superkernal kann schließlich auch Onefiler in den Slots unterbringen.

Ein Ultimax-Modul blendet so gut wie alles an RAM aus... Als Eprom gebrannt und in ein Ultimax-Modul verpackt wird es also kaum laufen.
Was mir gerade die 1541 Ultimate II bestätigt hat. Nach Umwandlng in CRT mittels "cartconv -t ulti -i galaxiankernal.bin -o galaxiankernal.crt" habe ich das resultierende CRT mit der 1541 Ultimate II emulieren lassen, und es geht wie vermutet nicht.

Nachtrag: Als Kernal eingebunden und nicht als Ultimax-Modul funktioniert es selbstverständlich. Aber deine letzte Antwort war ja "Ultimax Modul"

Ohne dass ich es wirklich weiß: Nimm mal die C64-Version als Referenzpreis. Eigentlich ist ja nur die Firmware anders, die Hardware jedoch gleich.

Zitat von Flocke1967

Kann man das Superkernal auch in einem 128DB benutzen?

128DB?

Vom Grundsatz her gilt: Es gibt einen separaten Superkernal 128 (andere Firmware!) - der allerdings noch im Betatest ist. Jener ist für den C128 gedacht.
Der Superkernal 64 passt auch in jene C128 Modelle, die mit 16k ROMs betrieben werden - bietet jedoch weniger Möglichkeiten wie der Superkernal 128 - man möchte das also eher nicht.

Der Superkernal 128 kann u.a. zusätzlich: Kernal 128 ersetzen (inkl. Z80-Bootcode), Reset-Verhalten des C128 konfigurieren, Autobbot des C128 auf Wunsch nur bei gedrückter CTRL-Taste,

Zitat von Ace

Ich wurde gefragt für welchen C64 ich es benötige. Von daher scheint es wohl zwei Varianten zu geben.

Lass mich raten - Du hast ein fertig zusammengebautes bekommen, welches Du nur in den C64 reinstecken musstest?

Also, die technische Implementierung von Acme kenne ich auch nicht

Jedenfalls könnte man konzeptionell an den Symboltabelleneinträgen jeweils eine Liste dranhängen, um wieviel Bytes die !PSEUDOPC verschoben sind (vorzeichenbehaftet). Dann kann der Assembler das bei einem Label zurückrechnen (auf dem PC ist ja Arbeitsspeicher da, da stört so eine Liste pro Label nicht).

Im Minimalbeispiel wäre das dann aus Benutzersicht:

* = $c000
!pseudopc 1000 {
!pseudopc 2000 {
!pseudopc 3000 {
!pseudopc 4000 {
demolabel nop
}
}
}
}

demolabel -> 4000
&demolabel -> 3000
&&demolabel -> 2000
&&&demolabel -> 1000
&&&&demolabel -> c000

Ja, zugegeben: Verschachtelt und dann auch noch die verschiedenen Adressen braucht man nicht so oft - aber wenn schon, dann sollte ein Vorschlag universell sein.
Um "&" als Zeichen sich wirklich eignet: Keine Ahnung, es erinnert nur in angenehmer Weise an den Adress-Operator von C.

Ich nehme ACME, da kann ich per Makro schreiben:

+beq ganz_weit

und der Assembler ersetzt das Makro dann durch ein

bne +
jmp ganz_weit
+

Ja, zugegebenerweise nichts neues, aber dennoch lesbarer.

Es gibt in ACME übrigens noch ein Feature, welches ich vermisse - ich versuche das mal an einen Anwendungsbeispiel zu erklären:

Es sei ein !pseudopc-Block gegeben, der beispielsweise in der Floppy ausgeführt werden soll. Dann sind darin natürlich eine gewisse Anzahl Labels drin. Jetzt stelle man sich vor, dass der Teil vor der Übertragung zur Floppy noch gepatched werden soll - je nachdem, welche Floppy erkannt worden ist.
Man fängt also an, wild mit den Labels zu rechnen, um die Speicheradresse zu bekommen, wo der Code im Programm ist:

floppycode
!pseudopc $0300 {
nop
nop
nop

floppylabel1 STX a1801 ;PA, port A
}
floppylabel1addr = floppylabel1 + 1 - $0300 + floppycode
sample: lda #$1c
sta floppylabel1addr

Schön wäre es, wenn einfach schreiben könnte

sample: lda #$1c
sta &floppylabel1+1

und er durch das Prefix "&" vor dem Label erkennt, dass er pro Prefix eine "pseudopc"-Ebene rausgehen soll und die Adresse, wo es dort dann (virtuell) steht nimmt.

Zitat von Mac Bacon

Nein. Das würde ich auch kaum versuchen wollen, da es prinzipiell nicht 100%ig sicher machbar ist.

Eben. Sehe ich auch so. Machbar wäre wohl, dass der Programmeirer per "!native" oder "!emulation" dem Assembler mitteilt, unter welcher Umgebung der Code lt. Itention des Programmeirers ausgeführt werden soll.
Wenn man sich entschließt, solche Befehle einzuführen, könnte man die Warnungen spezieller machen.

Zitat von Mac Bacon

Das ließe sich machen. Wenn die 65816-Coder diese Warnung als kontraproduktiv empfinden, baue ich das entsprechend um - ich selbst habe kaum praktische Erfahrung mit dem 65816 und würde mich da nach der Mehrheit richten.

Ich habe mit 65816 auch keine Erfahrung - würde aber wollen, dass der Assembler mich nicht dazu überredet, etwas zu ändern, was ich auf einer gewissen Zielcpu gar nicht ändern müsste.

PS: Beim 65802 (und ich vermute auch beim 65816) wollte man im Emulationsmodus auch die CPU-Zyklenanzahl zum 6502 beibehalten. Vermutlich deswegen hat man gewisse Bugs nicht korrigiert im Emulationsmodus - obwohl i. A. Bugs korrigiert worden sind.

Nicht nur für den Anfang ist https://www.c64-wiki.de/wiki/ACME dafür ganz gut geeignet. Auch wenn die Neuerungen der aktuellen Version da noch nicht berücksichtigt sind.

Zitat von Mac Bacon

Neue Warnung: Zeropage-indirekte Adressierungsarten mit der Adresse $ff erzeugen eine Warnung, da das Highbyte des Pointers nicht von $0100, sondern von $00 geholt würde. Bei den 24-Bit-Pointern der 65816-CPU passiert das natürlich auch für $fe. Vielen Dank an Gerrit für den Vorschlag!

Wäre schön, wenn die Warnung nur dann kommen würde, wenn die !CPU - Einstellung auf eine betroffene CPU hindeutet.

Gibt es eigentlich eine Übersicht über solche CPU-Bugs und ob die in 6502, 6510, 65C02, 65802 bzw. 65816 vorhanden sind (ggf. nach Mode unterschieden)?

Ups, den habe ich übersehen...

Zu meiner Rettung kann ich allenfalls hervorbringen, dass mein Makro allgemeiner ist. Man kann damit auch bspw. auf eine durch 100 teilbare Adresse alignen - wenn die bspw. für den Benutzer leichter zu erinnern sein soll. Mögen sich beide Möglichkeiten sinnvoll ergänzen.

Nein, gibt es AFAIK nicht, kann man jedoch selbst recht leicht nachbauen:

!do while * < $0900 { !byte $00 }

Die Adresse kann man ggf. ja vorher in einem Makro mit lokalen Symbolen berechnen...

Nachtrag: Etwa so:

!macro skipto .boundary {
.tmp = * % .boundary
.dest = * + (.boundary - .tmp) % .boundary
!do while * < .dest { !byte $00 }
}

Verwendung:

+skipto $0100

oder auch:

!macro skipto .boundary {
.tmp = * % .boundary
.amount = (.boundary - .tmp) % .boundary
!skip .amount
}

An der Stelle ist erst mal die Frage, was dann genau schief geht. Als erstes würde ich mal tippen, dass bei aktivierter Kernalersatzfunktion der Ultimate das Superkernalmenü nicht mehr verfügbar ist.
Und als zweites sollte es von der Theorie das Problem geben, dass der Superkernal das Menü darstellen wll beim Poweron. Wenn das dann auf den Bildschirm ist, ist vermutlich die Ultimate so weit und Reseted den C64 erneut, diesmal mit Kernalersatz. Jezt greift der Kernal des Suerkernal nicht mehr, und der SUperkernal kommt nicht in den Modus: Normalen Kernal ausgeben...was beim Abschalten der Kernalersatzfunktion der Ultimate für Überraschungen sorgen sollte...

Es steht ja leider nicht, was schief geht. Es könnte ja einfach "nur" das gerade genannte sein... im C128 kann ich das nicht ausprobieren, und mein C64 ist noch nicht per Kermnalsockeln vorbereitet - was aber nur eine Frage der Zeit ist.

Den Superkernal für den C128 betateste ich. Im Grunde funktioniert er sehr gut - allerdings ist RetroJack dabei, die letzten von mir gefundenen optimierungswürdigen Stellen zu optimieren - um mal das Wort B**s nicht zu benutzen. Danach wird geschaut, ob dann wirklich alles passt.

Die Firmware ist übrigens eine andere wie für den Superkernal 64.

Ach ja, nicht zu vergessen: Der C128 ist dafür auf 32k ROMs umzurüsten.

Das ginge - man hat lediglich das "Problem", dass das mit original C64 Gehäuse schwierig ist. Da sind ja nunmal die Joysticks, wenn man die dort wegnimmt, muss man dafür wieder einen neuen Platz suchen...

Wie man sieht: USB kann man bei dem Ultimate 64 weder schwer zugänglich machen noch von der Benutzbarkeit einschränken - etwa indem der Stecker noch dieses und jenes alternativ machen soll... man hätte dann plötzlich ein emuliertes Laufwerk ohne Datenträger...

Vor diesem Hintergrund ist es nachvollziehbar, dass USB leicht erreichbar an der Userportstelle ist. In der 1541 U2-Firmware ist Unterstützung für USB-Tastaturen reingekommen - vermutlich auch für den Ultimate 64, d. h. der zweite USB-Anschluss hat dort auch seinen Grund.

Weil der in etwa so ist wie eine Floppy ohne Diskette. Zumindest für die emulierten Floppies.

Natürlich nur bei der U2+, bei der U2 wäre das ja eher die Micro-SD-Karte...

Einserseits wahr, anderseits: Für größere Kopieraktionen oder aber einen Abgleich des Stickinhaltes mit dem PC (Sicherheitskopie etc.) extra den Ultimate 64 auseinanderbauen - auch nicht so toll.

Zumindest die 1541 Ultimate ist über Ethernet beim Dateitransfer recht langsam, so dass man für größere Kopieraktionen auch mal den Stick in den PC stecken will.

PS: Einmal habe ich es hinbekommen, mit meiner Ultimate das Dateisystem zu schrotten. Deswegen gilt für den C64 auch, was für andere Geräte gilt: Eine Sicherheitskopie ist zu empfehlen...

Man merkt, dass Du keine Ultimate verwendest... da ist ein USB Stick quasi permanent eingestöpselt. Somit wäre ein USB Port dauerhaft belegt und stünde somit nicht mehr für andere Geräte zur Verfügung.
Man muss realistisch mit USB und HDMI dauerhaft angeklemmt planen und trotzdem Userport haben wollen.

Oder irre ich mich, und Du verwendest doch eine Ultimate?

Davon abgesehen kann der Speeder S-Jiffydos das. Wobei er IMHO Track 18 nur nutzt, wenn woanders nichts frei ist und die entsprechende Option eingeschaltet ist.
Müsste aber nachschauen, wann er wirklich Track 18 nutzt...