| |
trip6
Account closed
Registered: Jan 2007
Posts: 51 |
Berzek for C64
Hello... I recently recieved assembler source code for Berzerk video game. I was told that I would have to use CCS65 to compile it. However, I am quickly realizing that I have no idea how to do this in CCS65. Can some one help me our compile this for me with CCS65 if I sent the source code? All help is appreciated, I'd love to get a port of this classic on the C64.
|
|
... 260 posts hidden. Click here to view all posts....
|
| |
Heaven
Account closed
Registered: Jul 2008
Posts: 102 |
that's why I found it hard to take the 2600 version with it's "hardcoded" gfx kernel interleaved with game logic approach.
so... I will give a shot on the A8 version instead. But question... when porting Metallamas from VIC20 to A8 I used following way of patching
ORG patch_adress
insert new_code
ORG patch_adress2
insert new_code2
...
as A8 can have multiple file segments...so first Atari loaded the original game file into memory and then the other small patches which overwrote the wanted parts of the VIC20 code.
but what would be the practical way of doing that with C64???
|
| |
Martin Piper
Registered: Nov 2007
Posts: 645 |
Quote: Umm, the 2600 generates the display manually, so everything takes a whole frame regardless of complexity.
It generates the display manually but the 2600 can do a store to WSYNC which pauses the processor until the start of the next raster. Obviously the store WSYNC doesn't pause the CPU until the next raster on the C64 so I was expecting the actual frame time to be much less than discovered. On the C64 each store WSYNC translates to a "jsr ScanCalc" which keeps track of the virtual scanline and the PF/PL status to keep track of what to really draw on the C64 screen.
|
| |
Oswald
Registered: Apr 2002
Posts: 5025 |
the 2600 is slightly faster, so the same thing will take more time for the c64, also I guess you counted in the code which does nothing but builds up the screen. to sum it up 90% is pretty realistic.
heaven, bet you can patch code like that in an xasm . why waste diskspace for code that will be overwritten all the time anyway :P :) |
| |
Martin Piper
Registered: Nov 2007
Posts: 645 |
It is when, as I found out, during the actual game rendering the code to draw each scanline actually takes two scanlines. i.e. A store to WSYNC happens half as often and the code itself uses most of the available cycle times for two scanlines.
During the title screen, which is simpler, it takes about 40% of a frame.
|
| |
Heaven
Account closed
Registered: Jul 2008
Posts: 102 |
ok. startet the process of going through the DIS6502 output and as more as I got into the soures as more I see the port.
the A8 Berzerk does even have a PAL/NTSC detection inside.
So as my general "patching" method will not be possible I will produce a DASM compatible source of the A8 version and will try to compile that first. When done I will start the C64 porting. |
| |
d0c
Registered: Apr 2006
Posts: 186 |
thanks Heaven for making a c64 port of berzerk :) |
| |
Heaven
Account closed
Registered: Jul 2008
Posts: 102 |
well...the complicated thing will start when I am moving to C64... as I am not a c64 geek... ;) but Oswald & TMR might help here...
but look, the game uses zero pages $80-$ff so it is even more system friendly... ;)
|
| |
Martin Piper
Registered: Nov 2007
Posts: 645 |
I just had to worry about VSYNC and VBLANK being at $00 and $01. Not fun locations to be splatting values to. :)
|
| |
Heaven
Account closed
Registered: Jul 2008
Posts: 102 |
well... I heard of 0,1 not being fun... ;)
|
| |
Martin Piper
Registered: Nov 2007
Posts: 645 |
It depends. :) If interrupts are disabled and you don't want to use SID/VIC/BASIC/KERNAL then you're fine. :) |
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | ... | 27 - Next |
