Log inRegister an accountBrowse CSDbHelp & documentationFacts & StatisticsThe forumsAvailable RSS-feeds on CSDbSupport CSDb Commodore 64 Scene Database
You are not logged in - nap
CSDb User Forums


Forums > C64 Coding > Berzek for C64
2008-07-30 18:07
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....
 
2008-09-07 14:00
Oswald

Registered: Apr 2002
Posts: 5094
I dont think codebase is a place for that. It's about programming infos, and not about 5% converted game's sources.
2008-09-07 15:28
Martin Piper

Registered: Nov 2007
Posts: 722
Well the source file is but one of the many in that archive because it's part of the user projects section. It seemed a bit silly to do a code update of the compression and multiplexor parts and leave out the project.
2008-09-07 18:19
Burglar

Registered: Dec 2004
Posts: 1101
I think the User Projects space on codebase is an excellent place for things like this. I cannot think of a single reason why it shouldn't.

Keep it up!
2008-09-08 06:26
Martin Piper

Registered: Nov 2007
Posts: 722
Quote: and finally the joystick routine is found, too...

so all main procederes to get started are found. so... maybe this afternoon I will transfer the code to C64 and look what happens... ;)

first task will be the mimic the bitmap screen & draw maze/logo stuff.

So question:

the game uses $0000-$3fff for RAM, where the bitmap screen is at $2028ff. display list at $1000 and lookup tables at $10d0 ff. Hardware sprite at $1400-$17ff and $1800-$1fff again game lookup tables.

So, how would you structure the c64 memory layout?

in a perfect world I would like to have bitmap at $2000 and the screen ram at $4000 but I guess that is not possible as they are different VIC banks... so what about using $4000-$7fff for bitmap screen, font and sprites?

this would leave $2000-$3fff free for custom c64 routines.

what do you think?




Yes, given the memory layout restrictions you have then using $4000-$7fff for graphics seems sensible. Or get the code compiling to such a state that you can move the Atari graphics/code/data around to anywhere you like. :)
I'm glad you like the multiplexor, it's heavily tweaked (to add more sprites and make it more like a general purpose extensible library) from a version found on codebase.

PS. Thanks Burglar. :)
2008-09-15 05:43
Heaven
Account closed

Registered: Jul 2008
Posts: 102
ok. small update.

i jut found the last puzzle to start getting the code over - the maze draw routine.

why did it take so long? because I need to learn how the game was written...imho not very "readable" and not very slim and optimised or not even common "tricks" are used. That could be the reason why I haven't spottet the importantant routine at a first glance... well... it looks like my first games or demos written back in the glory days ('it works...don't ask how but it does...' ;))

So I have to assume that it was a kind of novice doing the game... interesting that he was able to do digi speech but no proper sprite routine... ;) the lookup table routine for the scanline start adresses takes more than 60 lines of code alone! and there are tons of LDA ADC STA LDA ADC #0 STA sequenzes etc etc...

question... (I raised that already in #osg) would you rewrite the stuff or try as much as possible to run the original code?

if I run the original code there is a chance that the game slowes down as 1,77 MHz vs 0,99 MHz plus non-linear vram calculations on top...





2008-09-15 09:12
Martin Piper

Registered: Nov 2007
Posts: 722
If you can disable as much of the redundant drawing code. I found even after hacking out a lot of frame drawing code that wasn't needed the game code still took several C64 frames.

But you get extra bonus points if the source can be used to build and run the original version on the Atari. :)
2008-09-15 11:15
Heaven
Account closed

Registered: Jul 2008
Posts: 102
well... next step will be disabling all hardware related stuff.

GTIA = $D0xx ;sprites plus colours
ANTIC = $D40x ;graphic mode handling
POKEY = $D20x ; sound

I guess all conflicting with C64 chipset somehow... ;)

then the next will be in throwing custom routines for VIC-init.

and yes, Martin, it's good to be able to assemble Atari version and C64 version with DASM. So I can change bits and pieces and see what happens in the game...

Monitoring in Atari800win would be much more difficult... It really helps of being able compiling the original game.

2008-09-15 12:26
Shadow
Account closed

Registered: Apr 2002
Posts: 355
A bit off-topic:

What's strange with the sequence "LDA ADC STA LDA ADC #0 STA", seems like an addition of 8 bit value to 16 bit value, nothing peculiar, or?
2008-09-15 12:53
Martin Piper

Registered: Nov 2007
Posts: 722
Quote: A bit off-topic:

What's strange with the sequence "LDA ADC STA LDA ADC #0 STA", seems like an addition of 8 bit value to 16 bit value, nothing peculiar, or?


Assuming zero page for the loBye/hiBye if it is:
lda loByte
adc #foo
sta loByte
lda hiByte
adc #0
sta hiByte

16 Cycles 12 Bytes

Then this is slightly quicker and uses less bytes:
lda loByte
adc #foo
sta loByte
bcc .over
inc hiByte
.over

15 (+1 less often) Cycles 10 Bytes
2008-09-15 14:00
Heaven
Account closed

Registered: Jul 2008
Posts: 102
Martin is right...

assuming that the game depends a lot on the horse power of the CPU for rendering the software sprites... you find a lot of (!)

ldy #0
CLC
LDA zp,y
adc var1
sta zp,y
lda yp+1,y
adc #0
sta yp+1,y
...

or the

CLC
lda var1
adc #val
sta var1
lda var1+1
adc #0
sta var1+1
...

which all can heavily optimised...

I don't want to blame the guy(s) who wrote the game but look at his lookup table generator:

; ----------------------------------------------------------------------------
;lookup table generator for each scanline
;$AE98,$AE99 start adress of Antic E bitmap screen
;$10d0 lookup table for scanline begin
;format lo,hi,lo+40,hi, lo+80,hi etc lo=$10d0+i*2 hi=$10d0+i*2+1
L856C: lda #$02
sta $9C
lda #$D0
sta $8B
lda #$10
sta $8C
;calc first half
ldy #$00
clc
lda LAE98
adc #$01
sta ($8B),y
iny
lda LAE99
sta ($8B),y
dey
L8589: clc
lda ($8B),y
adc #$28
iny
iny
sta ($8B),y
dey
lda ($8B),y
iny
iny
adc #$00
sta ($8B),y
lda $9C
cmp #$64
bne L85C1
;2nd half of the screen
dey
clc
lda LABBA
adc #$01
sta ($8B),y
iny
lda LABBB
sta ($8B),y
clc
dey
tya
adc $8B
sta $8B
lda $8C
adc #$00
sta $8C
ldy #$01
lda $9C
L85C1: inc $9C ;scanline counter
cmp #$b0 ;176 lines?
beq L85CB
dey
jmp L8589
; ----------------------------------------------------------------------------
L85CB: rts
`

aehm... the output is a 176 bytes lookup table.
and best... it is interleaved... so the index needs to be ASL (*2)...

Previous - 1 | ... | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | ... | 27 - Next
RefreshSubscribe to this thread:

You need to be logged in to post in the forum.

Search the forum:
Search   for   in  
All times are CET.
Search CSDb
Advanced
Users Online
Acidchild/Padua
Mike
Jammer
deetsay
WVL/Xenon
Frostbyte/Artline De..
zscs
Murphy/Exceed
Guests online: 118
Top Demos
1 Next Level  (9.7)
2 13:37  (9.7)
3 Mojo  (9.7)
4 Coma Light 13  (9.6)
5 Edge of Disgrace  (9.6)
6 What Is The Matrix 2  (9.6)
7 The Demo Coder  (9.6)
8 Uncensored  (9.6)
9 Comaland 100%  (9.6)
10 Wonderland XIV  (9.6)
Top onefile Demos
1 No Listen  (9.6)
2 Layers  (9.6)
3 Cubic Dream  (9.6)
4 Party Elk 2  (9.6)
5 Copper Booze  (9.6)
6 Dawnfall V1.1  (9.5)
7 Rainbow Connection  (9.5)
8 Onscreen 5k  (9.5)
9 Morph  (9.5)
10 Libertongo  (9.5)
Top Groups
1 Performers  (9.3)
2 Booze Design  (9.3)
3 Oxyron  (9.3)
4 Censor Design  (9.3)
5 Triad  (9.3)
Top Webmasters
1 Slaygon  (9.6)
2 Perff  (9.6)
3 Sabbi  (9.5)
4 Morpheus  (9.4)
5 CreaMD  (9.1)

Home - Disclaimer
Copyright © No Name 2001-2024
Page generated in: 0.055 sec.