mrsid: Vielen Dank für die ausführliche Erklärung.
Eine Sache hat mich allerdings überrascht. Den Originalcode für den AppleII kenne ich zwar nicht, hätte aber vermutet, daß solche Dinge wie Gitterstäbe als Shapes plus Maskenshape abgelegt sind und für jeden Frame über die Figur gemalt werden, sofern sich die FIgur innerhalb des Shapes aufhält. Das hat den Vorteil, daß man keine ganze Bitmap für die Maske benötigt. Der Einsatz von Sprites macht die Sache natürlich etwas komplizierter, da man die Masken dann fürs Sprite passend zurechtschneiden und shiften muß, aber generell sollte es möglich sein, oder?
Hallo Besucher, der Thread wurde 10k mal aufgerufen und enthält 58 Antworten
letzter Beitrag von Diddl am
Prince of Persia Disk Version ?
- Ernie76
- Erledigt
-
-
PrinceOfPersia und TrapThem64 haben die selben Probleme. Nur ich habe die Mühe einer Diskettenversion gemacht.
Ja, auch ich habe eine REU Version ausprobiert. Nur kann ich es nicht selber testen außer im Emu. Der Trick ist wie eine Diskette die REU nutzen, nachdem sie im REU endlich geladen ist.
An einer REU bzw SCPU Ramdisk arbeite ich seit gestern
Die SCPU-Ramdisk (im moment nur für sektorbasierende lader zu gebrauchen) funktioniert. Einfach das d64 in das SCPU-Ram ab $020000 laden.
Den Code habe ich in "Borrowed Time" eingebaut.
Code- * = $6A00
- jmp j6A08
- a6A03 .BYTE $01 ; Track Hex
- a6A04 .BYTE $01 ; Sektor Hex
- a6A05 .BYTE $00 ; Ramload Lo
- a6A06 .BYTE $20,$01 ; Ramload Hi
- j6A08 lda #$00
- sta $d07b
- php
- sei
- lda #$bf
- sta trb01 ; scpu op-code einfügen
- lda #$00
- sta trb01+1 ; trackpuffer auf 00 setzen
- sta trb01+2
- lda #$03 ; REU = 00 , SCPU = 02
- sta trb01+3 ; trackpuffer bank
- ldx a6A03 ; angeforderter track
- dex ; track - 1
- beq AST04
- AST01 lda tra01,x ; x = zeiger auf sektoren pro track
- clc
- adc trb01+2 ; startwert ist 00
- sta trb01+2
- bcc AST02 ; übertrag vorhanden ?
- inc trb01+3 ; trackpuffer hi einen erhöhen startwert ist 00
- AST02 dex
- bne AST01
- AST04 lda a6A04 ; angeforderter sektor
- clc
- adc trb01+2 ; anzahl der sektoren
- sta trb01+2 ; zum trackergebnis addieren
- bcc AST03
- inc trb01+3 ; bei übertrag, hi-byte un einen erhöhen
- AST03 lda a6A05 ; zeiladresse der daten lo
- sta RAM01+1
- lda a6A06 ; zeiladresse der daten hi
- sta RAM01+2
- ldx #$00
- trb01 lda $021000,x ; lade aus scpu ram
- RAM01 sta $1000,x ; schreibe in c64 ram
- dex
- bne trb01 ; 256 bytes
- cli
- plp
- ldy #$f4
- lda #$00
- sta $d07a
- rts
- tra01 .byte $00,$15,$15,$15,$15,$15,$15,$15,$15,$15,$15,$15,$15,$15,$15,$15,$15,$15
- .byte $13,$13,$13,$13,$13,$13,$13,$12,$12,$12,$12,$12,$12,$11,$11,$11,$11,$11
-
Kann man nicht die Animations phasen halbieren ? Sieht dann nicht mehr so smooth aus, aber das würde am Spielfluss ja nix ändern .
-
ja, gischt mir dann bescheid bau ich deins ein kommste in die credits
-
Vernunftmensch: Kannst du bitte aufhören, diesen Thread zu verhunzen.
Kann man nicht die Animations phasen halbieren ? Sieht dann nicht mehr so smooth aus, aber das würde am Spielfluss ja nix ändern .
Dazu hat mrsid auch was geschrieben: Schau mal in den Beitrag ganz unten Prince of Persia Disk Version ? -
Aber gleich im 80 Zeichenmodus - O.K. der VDC kann keine Sprites, schon Problem 1 - und mit 2 MHZ.Nicht wirklich ein Problem, der Apple II kann das ja auch nicht. Vorausgesetzt das Schreiben ins VDC RAM geht schnell genug, sollte es kein grosses Problem darstellen.
Diese Routine kopiert nun per mvn befehl (bedeutend schneller als die REU)
die entsprechenden Bänke aus dem SCPU-Ram ab $020000 nach $8000-$bfffVergiss nicht das Schreibzugriffe ins ROM im RAM darunter landen müssen, und das man das ROM mit $01 ausblenden kann. Letzteres ist essentiell wichtig um aus der Bitmap darunter zu lesen, beim maskieren.
mrsid: Vielen Dank für die ausführliche Erklärung.
Eine Sache hat mich allerdings überrascht. Den Originalcode für den AppleII kenne ich zwar nicht, hätte aber vermutet, daß solche Dinge wie Gitterstäbe als Shapes plus Maskenshape abgelegt sind und für jeden Frame über die Figur gemalt werden, sofern sich die FIgur innerhalb des Shapes aufhält. Das hat den Vorteil, daß man keine ganze Bitmap für die Maske benötigt. Der Einsatz von Sprites macht die Sache natürlich etwas komplizierter, da man die Masken dann fürs Sprite passend zurechtschneiden und shiften muß, aber generell sollte es möglich sein, oder?Hier mal ein Beispiel der Maske für den ersten Raum:
Der Bildschirm wird mit Painter Algorithmus gezeichnet. Für die Elemente die den Spieler verdecken, wird nach dem Layer auf dem der Spieler ist die Maskenversion des Elements gezeichnet, und danach die Vordergrund Version des Elements.
Nach dem Zeichnen des Raumes rauszufinden welche Maske man an der Stelle des Spielers braucht (der Raum wird ja nur einmal gezeichnet) würde bedeuten das man das meiste davon jedes Frame nochmal durchlaufen lassen müsste. Es schien mir wesentlich einfacher den ganzen Schirm als Maske zu speichern. Shiften muss man das dann auch noch.Kann man nicht die Animations phasen halbieren ? Sieht dann nicht mehr so smooth aus, aber das würde am Spielfluss ja nix ändern .
Ja klar, siehe CPC version. Ich find's scheisse, aber manche haben andere Meinungen. Es wird dann immer noch sauknapp, aber wer's versuchen will...
-
Danke für die Info. Das richtige setzen von $01 habe ich schon bei anderen Projekten vergessen. Ergebnis = Grafikmüll oder Abstürze.
Das SCPU-Projekt war eigendlich nur eine fixe Idee von mir.
Nun denke ich, das ich es doch mal versuchen werde. Mehr als scheitern kann ich auch nicht.
Ich habe gerade alle Bänke des EasyFlash Moduls ausgelesen. Von Bank 00 bis Bank 31 (Dezimal).
wobei die letzte Bank wohl Savestates sind.
Alle Bänke zusammengelinkt ergibt ein Ramfile von 2065 Blocks das liegt dann ab $020000 im SCPU-Ram
Gruß: Stephan
-
Also ich habe mir gerade mal die CPC Version angesehen, die ja deutlich weniger Animations Phasen hat, aber ich finde das es immer noch gut Spielbar aussieht. Könnte man nicht wie bei Sams Journey die Kostüme einige sachen bei bedarf reinladen / rauswwerfen. Das geht ja bei Sam selbst bei der Disketten Version verdammt flott.
Ich Persönlich könnte schon mit abstrichen leben, wenn es dafür auf einem Vanilla Cevi von Diskette laufen würde.
Das ist jetzt natürlich nur die Meinung von einem Pixel Schubser, der vom Programmieren null Ahnung hat. ( Habs echt Probiert, ich bin zu blöd für alles oberhalb von Basic )[Externes Medium: https://www.youtube.com/watch?v=TQpbCCUquFY] -
Danke für die Info. Das richtige setzen von $01 habe ich schon bei anderen Projekten vergessen. Ergebnis = Grafikmüll oder Abstürze.
Das SCPU-Projekt war eigendlich nur eine fixe Idee von mir.
Nun denke ich, das ich es doch mal versuchen werde. Mehr als scheitern kann ich auch nicht.
Ich habe gerade alle Bänke des EasyFlash Moduls ausgelesen. Von Bank 00 bis Bank 31 (Dezimal).
wobei die letzte Bank wohl Savestates sind.
Alle Bänke zusammengelinkt ergibt ein Ramfile von 2065 Blocks das liegt dann ab $020000 im SCPU-Ram
Gruß: Stephan
Sag, wieso möchtest Du denn ne SuperCPU Version machen ? Du machst Dir mehr Arbeit als Nutzen, da die meisten hier automatisch ne Reu haben als SuperCPU.
-
Ach, einfach so aus Spass.
Ich mache da jetzt nicht den großen Aufriss
Ich wollte einfach mal wissen ob das wirklich zu realiaieren ist.
und zudem noch ob eine EasyFlash mittels SCPU emuliert werden kann.
Die SCPU hat das BasicRom ab $01a000 stehen und den Kernal ab $01e000.
Wenn man dort etwas verändert,sagen wir mal den "ready promp", bleibt das solange bis man die Hardware neustartet.
Die EasyFlash ROM-Bänke kann man einfach nach $018000-$01BFFF kopieren.
Ich habe einen Artikel dazu auf einer US-Seite gelesen. Es ging allgemein darum Module zu Emulieren.
Lade und starte mal die Datei "pppatch" mittels SCPU von dem angehangenen D64
und kopiere mittels paste & copy das kleine Programm in den Bildschirm
nun sagt dir der C64 "HALLO"
10 poke 107384,72
20 poke 107385,65
30 poke 107386,76
40 poke 107387,76
50 poke 107388,79 -
An einer REU bzw SCPU Ramdisk arbeite ich seit gestern
Nicht wirklich ein Problem, der Apple II kann das ja auch nicht. Vorausgesetzt das Schreiben ins VDC RAM geht schnell genug, sollte es kein grosses Problem darstellen.
Wenn das fehlen von Sprites kein Problem darstellen, könnte man Prince of Persia auf den C128 portieren.
Wäre doch ein Projekt für C128-Programmierer, mit 64KB-VDC-RAM sollte man doch was anstellen können.
* Träum *Gruss C=Mac.
-
@Klaus Scheuer: Das ist wohl der sportliche Ehrgeiz?
-
@Klaus Scheuer: Das ist wohl der sportliche Ehrgeiz?
Ganz genau, so ist es.
Wenn es nicht funktionieren sollte, ist es auch nicht weiter tragisch.
Es gibt noch genug andere ProjekteGruß: Stephan
-
Es gibt noch genug andere Projekte
Ja, Soul Crystal und Sam Journey
-
Ja, das wird schon.
Morgen schaue ich mir in aller Ruhe den Triad-Crack an.
Ich habe eine Woche Resturlaub zu verbraten.
Die EasyFlash Version ist auch interessant.
Um ein kompatiblen IRQ-Loader (1581/CMD) komme ich aber nicht herum, so wie es aussieht.
Gruß: Stephan
-
Ich habe gerade alle Bänke des EasyFlash Moduls ausgelesen. Von Bank 00 bis Bank 31 (Dezimal).Ja, die letzte LOROM bank hat die Speicherstände. Anbei die ganze Bankbelegung, falls es hilft...
Code- ROM_LO_ALLOC | 00 | 0000 | pop.prg |
- ROM_LO_ALLOC | 03 | 0000 | title.obj |
- ROM_LO_ALLOC | 04 | 0000 | data/rom/blueprint_level1.bin |
- ROM_LO_ALLOC | 04 | 0900 | data/rom/blueprint_level2.bin |
- ROM_LO_ALLOC | 04 | 1200 | data/rom/blueprint_level3.bin |
- ROM_LO_ALLOC | 05 | 0000 | data/rom/blueprint_level4.bin |
- ROM_LO_ALLOC | 05 | 0900 | data/rom/blueprint_level5.bin |
- ROM_LO_ALLOC | 05 | 1200 | data/rom/blueprint_level6.bin |
- ROM_LO_ALLOC | 06 | 0000 | data/rom/blueprint_level7.bin |
- ROM_LO_ALLOC | 06 | 0900 | data/rom/blueprint_level8.bin |
- ROM_LO_ALLOC | 06 | 1200 | data/rom/blueprint_level9.bin |
- ROM_LO_ALLOC | 07 | 0000 | data/rom/blueprint_level10.bin |
- ROM_LO_ALLOC | 07 | 0900 | data/rom/blueprint_level11.bin |
- ROM_LO_ALLOC | 07 | 1200 | data/rom/blueprint_level12.bin |
- ROM_LO_ALLOC | 08 | 0000 | data/rom/blueprint_level13.bin |
- ROM_LO_ALLOC | 08 | 0900 | data/rom/blueprint_level14.bin |
- ROM_LO_ALLOC | 09 | 0000 | bitmap_clear.obj |
- ROM_LO_ALLOC | 0f | 0000 | screen_clear.obj |
- ROM_LO_ALLOC | 10 | 0000 | color_clear.obj |
- ROM_LO_ALLOC | 10 | 0c00 | sprite_clear.obj |
- ROM_LO_ALLOC | 11 | 0000 | data/rom/title/title_01_background.png.bin |
- ROM_LO_ALLOC | 12 | 0000 | data/rom/title/title_01_background.png-v.bin |
- ROM_LO_ALLOC | 12 | 0400 | data/rom/title/title_01_background.png-c.bin |
- ROM_LO_ALLOC | 12 | 0800 | data/rom/title/top_sprites.bin |
- ROM_LO_ALLOC | 12 | 0840 | data/rom/title/bottom_left_sprites.bin |
- ROM_LO_ALLOC | 12 | 0880 | data/rom/title/bottom_right_sprites.bin |
- ROM_LO_ALLOC | 12 | 08c0 | data/rom/title/side_sprites.bin |
- ROM_LO_ALLOC | 12 | 0900 | data/rom/title/broderbund_overlay_sprites.bin |
- ROM_LO_ALLOC | 13 | 0000 | data/rom/title/jordanmechner_overlay_sprites.bin |
- ROM_LO_ALLOC | 13 | 0480 | data/rom/title/broderbund_bg_slice.bin |
- ROM_LO_ALLOC | 14 | 0000 | data/rom/title/jordanmechner_bg_slice.bin |
- ROM_LO_ALLOC | 14 | 0c00 | data/rom/title/logo_screen_slice.bin |
- ROM_LO_ALLOC | 14 | 0d68 | data/rom/title/logo_color_slice.bin |
- ROM_LO_ALLOC | 15 | 0000 | data/rom/title/logo_bg_slice.bin |
- ROM_LO_ALLOC | 15 | 0c00 | data/rom/title/text_bg_slice.bin |
- ROM_LO_ALLOC | 15 | 14c0 | data/rom/title/text_screen_slice_blue.bin |
- ROM_LO_ALLOC | 15 | 15d8 | data/rom/title/text_screen_slice_red.bin |
- ROM_LO_ALLOC | 15 | 16f0 | data/rom/title/text_color_slice.bin |
- ROM_LO_ALLOC | 16 | 0000 | data/rom/title/text_1_bg.bin |
- ROM_LO_ALLOC | 17 | 0000 | data/rom/title/text_2_bg.bin |
- ROM_LO_ALLOC | 18 | 0000 | data/rom/title/text_3_bg.bin |
- ROM_LO_ALLOC | 19 | 0000 | data/rom/title/text_4_bg.bin |
- ROM_LO_ALLOC | 1a | 0000 | intro.obj |
- ROM_LO_ALLOC | 1a | 1980 | data/rom/easyflash_bolt_sprites.bin |
- ROM_LO_ALLOC | 1a | 1a40 | data/rom/easyflash_logo_overlay_sprites.bin |
- ROM_LO_ALLOC | 1a | 1b40 | data/rom/easyflash_logo_base_charset.bin |
- ROM_LO_ALLOC | 1a | 1c00 | data/rom/manual_charset.bin |
- ROM_LO_ALLOC | 1b | 0000 | data/rom/manual.bin |
- ROM_LO_ALLOC | 1d | 0000 | music.obj |
- ROM_LO_ALLOC | 1d | 0720 | data/rom/title/title_music_01.bin |
- ROM_LO_ALLOC | 1d | 0acc | data/rom/title/title_music_04.bin |
- ROM_LO_ALLOC | 1d | 0c3a | data/rom/title/title_music_05.bin |
- ROM_LO_ALLOC | 1d | 10b2 | data/rom/title/title_music_07.bin |
- ROM_LO_ALLOC | 1d | 1131 | data/rom/title/title_music_09.bin |
- ROM_LO_ALLOC | 1d | 124a | data/rom/title/title_music_0A.bin |
- ROM_LO_ALLOC | 1d | 1271 | data/rom/title/title_music_0B.bin |
- ROM_LO_ALLOC | 1d | 1317 | data/rom/title/title_music_0D.bin |
- ROM_LO_ALLOC | 1d | 1498 | data/rom/ingame_music_01.bin |
- ROM_LO_ALLOC | 1d | 150e | data/rom/ingame_music_02.bin |
- ROM_LO_ALLOC | 1d | 1587 | data/rom/ingame_music_03.bin |
- ROM_LO_ALLOC | 1d | 15cc | data/rom/ingame_music_04.bin |
- ROM_LO_ALLOC | 1d | 16c2 | data/rom/ingame_music_06.bin |
- ROM_LO_ALLOC | 1d | 174b | data/rom/ingame_music_08.bin |
- ROM_LO_ALLOC | 1d | 178e | data/rom/ingame_music_09.bin |
- ROM_LO_ALLOC | 1d | 197d | data/rom/ingame_music_0b.bin |
- ROM_LO_ALLOC | 1d | 19fc | data/rom/ingame_music_0c.bin |
- ROM_LO_ALLOC | 1d | 1a3f | data/rom/ingame_music_0d.bin |
- ROM_LO_ALLOC | 1d | 1bc0 | data/rom/ingame_music_0e.bin |
- ROM_LO_ALLOC | 1d | 1c3f | data/rom/ingame_music_10.bin |
- ROM_LO_ALLOC | 1d | 1dd8 | data/rom/ingame_music_07.bin |
- ROM_LO_ALLOC | 1d | 1e3c | data/rom/title/title_music_0F.bin |
- ROM_LO_ALLOC | 1d | 1f63 | data/rom/ingame_music_05.bin |
- ROM_LO_ALLOC | 1e | 0000 | sfxplayer.obj |
- ROM_LO_ALLOC | 1f | 0000 | data/rom/savedata.bin |
- ROM_HI_ALLOC | 00 | 0000 | bootstrap_easyflash.obj |
- ROM_HI_ALLOC | 00 | 1000 | savegame.obj |
- ROM_HI_ALLOC | 00 | 1800 | data/rom/eapi.bin |
- ROM_HI_ALLOC | 00 | 1b00 | data/rom/ef3_name.bin |
- ROM_HI_ALLOC | 00 | 1ffa | data/rom/bootstrap_vectors.bin |
- ROM_HI_ALLOC | 01 | 0000 | data/rom/cutscene_bitmap.bin |
- ROM_HI_ALLOC | 02 | 0000 | data/rom/cutscene_screen.bin |
- ROM_HI_ALLOC | 02 | 0400 | data/rom/cutscene_color.bin |
- ROM_HI_ALLOC | 02 | 0800 | data/rom/hourclass_bmp_scr_col.bin |
- ROM_HI_ALLOC | 03 | 0000 | data/rom/kidimage_rom_offsets.bin |
- ROM_HI_ALLOC | 03 | 0200 | data/rom/guardimage_rom_offsets.bin |
- ROM_HI_ALLOC | 03 | 0250 | data/rom/kidimage_rom_widths.bin |
- ROM_HI_ALLOC | 03 | 0330 | data/rom/kidimage_rom_heights.bin |
- ROM_HI_ALLOC | 03 | 0410 | data/rom/kidimage_rom_configs.bin |
- ROM_HI_ALLOC | 03 | 04f0 | data/rom/guardimage_rom_widths.bin |
- ROM_HI_ALLOC | 03 | 0510 | data/rom/guardimage_rom_heights.bin |
- ROM_HI_ALLOC | 03 | 0530 | data/rom/guardimage_rom_configs.bin |
- ROM_HI_ALLOC | 03 | 0600 | tables.obj |
- ROM_HI_ALLOC | 03 | 1080 | prince_code2.obj |
- ROM_HI_ALLOC | 04 | 0000 | data/rom/kidimage_rom_normal.bin |
- ROM_HI_ALLOC | 09 | 0000 | data/rom/kidimage_rom_mirrored.bin |
- ROM_HI_ALLOC | 0e | 0000 | data/rom/dungeon_bgimage_rom_table.bin |
- ROM_HI_ALLOC | 10 | 0000 | data/rom/palace_bgimage_rom_table.bin |
- ROM_HI_ALLOC | 12 | 0000 | data/rom/guardimage_rom_normal.bin |
- ROM_HI_ALLOC | 13 | 0000 | data/rom/guardimage_rom_mirrored.bin |
- ROM_HI_ALLOC | 14 | 0000 | data/rom/skelimage_rom_normal.bin |
- ROM_HI_ALLOC | 15 | 0000 | data/rom/skelimage_rom_mirrored.bin |
- ROM_HI_ALLOC | 16 | 0000 | data/rom/fatguardimage_rom_normal.bin |
- ROM_HI_ALLOC | 17 | 0000 | data/rom/fatguardimage_rom_mirrored.bin |
- ROM_HI_ALLOC | 18 | 0000 | data/rom/vizguardimage_rom_normal.bin |
- ROM_HI_ALLOC | 19 | 0000 | data/rom/vizguardimage_rom_mirrored.bin |
- ROM_HI_ALLOC | 1a | 0000 | data/rom/cutsceneimage_rom_normal.bin |
- ROM_HI_ALLOC | 1d | 0000 | data/rom/cutsceneimage_rom_mirrored.bin |
- ROM_HI_ALLOC | 1f | 1c00 | data/rom/cutsceneimage_rom_offsets.bin |
- ROM_HI_ALLOC | 1f | 1d00 | data/rom/cutsceneimage_rom_widths.bin |
- ROM_HI_ALLOC | 1f | 1e00 | data/rom/cutsceneimage_rom_heights.bin |
- ROM_HI_ALLOC | 1f | 1f00 | data/rom/cutsceneimage_rom_configs.bin |
-
Nein, das geht aber auch nicht. Prince of Persia läuft nur auf dem Easyflash
Und jetzt auch auf der UC-2 Hardware ...
Also fast, das mit den Speicherständen läuft (noch) nicht.
-
Und jetzt auch auf der UC-2 Hardware
Gepatcht oder EAPI für UC-2 geschrieben?
-
Gepatcht oder EAPI für UC-2 geschrieben?
Ein Patch war meine erste Idee.
Aber das war zu kompliziert (für mich).
Bin wohl zu doof dafür ...
Dabei geht es viel einfacher.
Einfach ein neues Jedec für den CPLD.
Jetzt verhält sich diese UC-2 wie ein EF mit 512K Flash.