hallo, wie sieht eine kleine demo als cartridgemodulprogram aus in asm die man dann in vcice laden kann?
mfg
Du bist in Begriff, Forum64 zu verlassen, um auf die folgende Adresse weitergeleitet zu werden:
Bitte beachte, dass wir für den Inhalt der Zielseite nicht verantwortlich sind und unsere Datenschutzbestimmungen dort keine Anwendung finden.
letzter Beitrag von InsertDisk2 am
hallo, wie sieht eine kleine demo als cartridgemodulprogram aus in asm die man dann in vcice laden kann?
mfg
Hi
Das CRT-Format für cartridge-images ist zum Glück ziemlich einfach aufgebaut, das kann man gleich im Assembler erstellen. Um zu verstehen wie das funktioniert sollte man aber ein paar Grundlagen der Module kennen:
1) Module blenden sich im einfachsten Fall einfach in die Speicherbereiche $8000-$9fff und/oder $a000-$bfff ein. Dazu muss im Falle von $8000-$9fff die ExROM-Leitung, im Falle von $a000-$bfff die GAME-Leitung auf 0 gesetzt werden.
2) Der C64 überprüft beim Einschalten und beim NMI ob er in den o.g. Speicherbereichen ein Modul vorfindet und springt dann ggf. dorthin. Ohne vorher großartig irgendetwas zu initialisieren, das müsste das Modulprogramm selber machen.
3) Der neu eingeblendete Speicherbereich muss folgenden Inhalt haben damit er als Cartridge erkannt und verwendet werden kann:
$8000-$8001: Startadresse des auszuführenden Programms
$8002-$8003: Startadresse des NMI
$8004-$8008: "CBM80" (dient zur Erkennung des Moduls)
$8009-$9fff: beliebiger Inhalt
Das CRT-Format besteht nun aus einem CRT-Header ($40 Bytes lang) und beliebig vielen Data-Packages (die jeweils wieder einen $10 Bytes langen Header haben). Genaues zum Aufbau findet man hier: CRT Format in der Power64-Dokumentation
Das Beispielprogramm hier erzeugt ein CRT-Image das sich in den Bereich von $8000-$9fff in den Speicher einblendet. Das Programm initialisiert sich erstmal notdürftig und tut dann nichts anderes als forwährend die Rahmenfarbe zu ändern. Beim Druck auf die Restoretaste wird ein NMI ausgelöst, der die Änderung der Rahmenfarbe in eine Änderung der Bildschirmfarbe ändert (und umgekehrt). Bei der Programmierung eines solchen ROM-Images ist freilich zu beachten das man dort leider keine Variablen oder selbstmodifizierenden Code ablegen kann. Ansonsten kann man dort ganz normal programmieren.
he, toll.
das find ich klasse.
ich habe lda #1 und sta 1024 reingenommen um ein "A" auf den screen anzuzeigen, es erscheint nicht, wie muss man den code zb unterbringen?
.....
.....
programmstart
jsr $fd15 ; initialisiere einige kernalvektoren
lda #1
sta 1024
lda #$00 ; flag für $d020 oder $d021
sta $02
loop
ldx $02
inc $d020,x
jmp loop
.....
....
mfg
Ohne das jetzt ausprobiert zu haben vermute ich das dein code zwar durchaus richtig funktioniert, aber die VIC-Register halt nicht wie gewohnt initialisiert sind. Das wird normalerweise beim Reset/NMI vom Kernel erledigt, in diesem Fall nehmen wir ihm jedoch beide Routinen "aus der Hand", so daß diese Initialisierung eben nicht durchgeführt wird.
Versuch mal die VIC-Register selber zu setzen ($dd00, $d018, $d011, und was auch immer nötig ist), dann sollte es klappen.
hallo, danke. jetzt klappt es.
wie du gesagt hast, es kommt nicht zur initialisierung.
was mach dieser befehl eigentlich :
lda $dd00
ora #$03
sta $dd00
wie kann man das warten auf einen tastendruck da hinein bringen :
eingabe
jsr getin
beq eingabe ; warte auf tastendruck
......
.......
jsr eingabe
mfg
ZitatOriginal von super_castlewas mach dieser befehl eigentlich :
lda $dd00
ora #$03
sta $dd00
Das sorgt dafür, daß die unteren beiden Bits von $dd00 gesetzt werden, der Rest aber unverändert bleibt. Die oberen Bits haben mit Floppy und ähnlichem zu tun, sind hier eigentlich egal, ein lda#3, sta $dd00 funktioniert auch.
$dd00 sind allerlei Ein/Ausgänge der CIA1. An den unteren beiden Bits hat man den Wahlschalter für die 16KB-Bank des VIC angelötet. Im Prinzip müsste man über $dd02 auch noch bestimmen, ob die Bits in $dd00 als Ein- oder Ausgang funktionieren, aber beim Wert 3 in $dd00 ist selbst das egal.
Tastaturabfrage weiß ich jetzt nicht, was da alles initialisiert sein muß, damit die ordentlich läuft. Sicher einiges, schliesslich soll die ganze IRQ-Routine im Rom lauffähig sein. Ich würde da sowas wie $ea87-$ea98 nachprogrammieren und gut ist.
wobei es an der stelle null sinn macht nur die unteren bits zu setzen - der rest wurde ja auch noch nicht initialisiert
Mit dem Cartridge-Format kann man ja nur maximal $4000 Bytes unterbringen.
Wie bringt man größere Programme auf ein Cartridge, die größer sind?
Oder waren damals wirklich alle Spiele, die auf Cartridges verkauft wurden, so klein?
es gibt verschiedene cartridge-typen :
http://www.infinite-loop.at/Po…rmate.html#Section%20E.11
http://www.unusedino.de/ec64/technical/formats/crt.html
auch teilweise mit eigenen speicher-ram.
ich versuche gerade mal ein cartridge mit einer reu zusammen im vice64.
mfg
@Nightshade
Guck mal hier, ist auch ne Möglichkeit...
http://www.emu-ecke.de/hardware/64k_modulkart.htm
Die "normalen" Cartridges waren alle nur 8K, oder 16K.
mfG Hucky
ZitatOriginal von sauhund
wobei es an der stelle null sinn macht nur die unteren bits zu setzen - der rest wurde ja auch noch nicht initialisiert
Richtig, und da vor allem das DDR noch nicht gesetzt ist, werden die Bits eh ignoriert.
Was spricht eigentlich gegen die "volle" Initialisierung, wie sie auch im Kernal der Reset-Routine ab $FCF2 steht (direkt nach dem Test auf das ROM-Cartridge; siehe die gesamte Routine ob $FCE2):
Das Initialiseren des Arbeitsspeichers (womit auch testen inbegriffen ist) könnte man weglassen, um Zeit zu gewinnen. Weiterer Vorteil: Man riskiert nicht, dass $A000 geändert wird, wenn man das Cartridge-Image erst im RAM testen will.
Gruß,
- Spiro.
Am Anfang waren es 8/16k Module, später auch größere (Ocean).
Imo verwenden sowieso alle Module 8/16kB. Der Rest ist Banking-Beschaltung. Dann wird halt mehrmals 8/16kB rauskopiert.
Michael
oben links in der ecke werden jetzt alle buchstaben in schneller reihenfolge angezeigt.
wie kann ich jetzt diesen befehl unterbringen, das nur nach jeden tastendruck ein neues zeichen erscheint :
getin = $ffe4
eingabe1
jsr getin ; zeichen einlesen (veränderte register: a, x, y)
beq eingabe1
-----------------------------------------------
!to "module1.crt", plain ; assembliere ohne startadresse
* = $8000-$40-$10 ; geplante startadresse, abzüglich der header
; --- cartridge header -------------------------------------------------------
!raw "C64 CARTRIDGE " ; magic word (16 bytes)
!byte $00, $00, $00, $40 ; headersize
!byte $01, $00 ; version of crt-format
!byte $00, $00 ; hardwaretype
!byte $00 ; exrom line
!byte $01 ; game line
!byte $00, $00, $00, $00, $00, $00 ; unused (6 bytes)
!scr "ich bin ein ganz tolles modul ": !byte $00 ; name of the module (32 bytes)
; --- chip data packet 1 -----------------------------------------------------
!raw "CHIP" ; magic word (4 bytes)
!byte $00, $00, $20, $10 ; length of chip-package
!byte $00, $00 ; chiptype
!byte $00, $00 ; bank
!byte $80, $00 ; adress
!byte $20, $00 ; length
; inhalt des "ROMs",
; bereich $8000-$9fff
!word programmstart ; resetvektor
!word nmi ; warmstartvektor
!pet "CBM80" ; modulkennung
programmstart
JSR $FDA3
JSR $FD50
JSR $FD15
JSR $FF5B
eingabe
inc 1024
jmp eingabe
nmi
rti
* = $a000
ZitatAlles anzeigenOriginal von super_castle
;.......
programmstart
JSR $FDA3
JSR $FD50
JSR $FD15
JSR $FF5B
eingabe
lda $dc01
and #$10
bne eingabe
inc 1024
jmp eingabe
nmi rti
* = $a000
So aus dem Stand. Musst es mal testen.
Michael
hallo, es funktioniert mit der space-taste, wenn ich die drücke, werden die buchstaben laufend angezeigt, beim loslassen bleiben die buchstaben stehen.
es ist schon ein teilerfolg.
wie kann man denn eine beliebige taste abfragen und dann auswerten?
mfg
diese abfrage "jsr getin" geht doch im cartridgemodul nicht.
mfg
es hat irgendetwas mit dem interrupt zu tun der im cartridgemodul läuft.
im wiki finde ich keine lösung, weil ich nicht weiss, von wo die suche losgehen soll.
mfg