Porting the original classic Castlevania to the 2600

[+grafixbmp]

If usign an NES controller turns out to be viable, then no changes will be made to the controls for thoes who wish to use one with an adapter. The regular joystick will have a control scheme as default. As for using a genesis, this has been discussed numerous times through other threads and is absolutly possible to use an extra button, I will only go this route if the NES version doesn't pan out. I would like to have all original controls for they have been proven... And this keeps the pause where it should be. Having all 3 options would be over kill.

 

#1 Limited/combersome control with classic joystick. Everyone with an atari should have one. Doable

 

#2 Sega Genesis controler adds an extra button. This maybe automaticaly added regardless if oneis using joystick or sega controls. Doable but about as useless as s-video if option 3 really works.

 

#3 create routine to read every button from an NES controler. Control layout stays intact to the original NES version. 3 extra buttons. Diffrent routine needed to load in serial rather than parallel. custom adapter needed.

 

I may just do all three if the NES works.

[lapetino]

If usign an NES controller turns out to be viable, then no changes will be made to the controls for thoes who wish to use one with an adapter. The regular joystick will have a control scheme as default. As for using a genesis, this has been discussed numerous times through other threads and is absolutly possible to use an extra button, I will only go this route if the NES version doesn't pan out. I would like to have all original controls for they have been proven... And this keeps the pause where it should be. Having all 3 options would be over kill.

 

#1 Limited/combersome control with classic joystick. Everyone with an atari should have one. Doable

 

#2 Sega Genesis controler adds an extra button. This maybe automaticaly added regardless if oneis using joystick or sega controls. Doable but about as useless as s-video if option 3 really works.

 

#3 create routine to read every button from an NES controler. Control layout stays intact to the original NES version. 3 extra buttons. Diffrent routine needed to load in serial rather than parallel. custom adapter needed.

 

I may just do all three if the NES works.

 

I think this might have been said before, but instead of using the NES controller as a hack of some sort, or reworking the Genesis controller, why not use the multibutton Atari joystick that already exists? http://www.atari7800.org/console/joypad.htm These work for all the Atari systems, including the 2600. I have a couple of them, and they work great. While not as plentiful as the standard stik, it seems to my non-technical mind that using one of these would be easier than doing one of the above. Or would these be the same as the Genesis?

[+grafixbmp]

Probably about the same as genesis controler. The NES interfacing maybe only be just in code as the wire connections seem as if they could just wire in. The only thing needed then would be a small 6" or less adapte plug. I wanted to try and make one that would work with special code that refrences all 8 buttons. But I will proabably still have the option for the expanded atari/genesis controls using the extra button anyway.

 

These links show the majority of info about Atari 2600, sega genesis controler, and NES.

 

http://pinouts.ru/In...00_pinout.shtml

 

http://www.atarihq.c...iles/stella.pdf

 

http://users.ece.gat...ES/protocol.htm

 

http://pinouts.ru/Ga...er_pinout.shtml

 

http://pinouts.ru/Game/genesiscontroller_pinout.shtml

 

If NES controls are possible to use, then Super NES would more than likely work as well. 12 buttons would give masive control options.

[lapetino]

 

If NES controls are possible to use, then Super NES would more than likely work as well. 12 buttons would give masive control options.

 

Makes sense, but isn't your goal to replicate the Castlevania NES experience as much as possible? Don't need those 12 buttons for that.

[+grafixbmp]

 

If NES controls are possible to use, then Super NES would more than likely work as well. 12 buttons would give masive control options.

 

Makes sense, but isn't your goal to replicate the Castlevania NES experience as much as possible? Don't need those 12 buttons for that.

I never would go that far. Never intended to either. Just saying if the NES controls work, the SNES should as well. Others might like using it if it suits their needs. NES controls are ideal for castlevania.

[+grafixbmp]

OK! Its been a year in the design phase and now I have a kernel that looks to work ok. It is raw, cude, and missing TONS of info but atleast it doesn't roll in stella. Anyway, I haven't gone through it yet to check for exact cycle timming but I will soon, especialy when all the data for screen displays is loaded into the code. I was more or less just going for a layout now. I just hope that there is enough time to load both players and both missiles with P0 being single scanline and the rest double scanline. One way I was considering doing P0's increased resolution was loading the data second first and first second. Like 2 1 4 3 6 5 etc. I also will need to have the option to change P1 NUSIZ multiple times mid kernel.

 

As of now, NOTHING of importance is displayed. Basicaly space for the HUD, the gameplay screen space and the floor.

 

processor 6502

include vcs.h

include macro.h

;constants
;GROUND = 22
;BELOWCANDELABRA = 30
;CANDELABRACOUNT = 6
;FIRSTFRAME = #1
;SECONDFRAME = #2

ORG $F000


;clear mem

ldx #0
txa

clear
dex
txs
pha
bne clear

cld

Reset		

;setvsyncandvblank

Start

lda #0
sta VBLANK
lda #2
sta VSYNC

sta WSYNC
sta WSYNC
sta WSYNC

lda #0
sta VSYNC
; load playfield pointers
; set pf and bg colors
lda #33 ; set index cycler for indexes of playfield data
sta $80
lda #$04
sta COLUBK

ldy #37
verticalblanking	
dey
sta WSYNC
bne verticalblanking


;kernelstart		
;prep for icon display
lda #03
ldx #32
;ldy #192
icondisplay
sta WSYNC
dex
;dey
bne icondisplay
lda #$08
sta COLUBK
lda #$02
sta COLUPF
sta WSYNC
kernelmain	
nop
nop
ldx $80 	;setup screen loading index
lda $80,x ;load ordered index for scanlines
tax		;tranfer index
;scanline pf loading routine	
lda $fa00,x
sta PF0
lda $fb00,x
sta PF1
lda $fc00,x
sta PF2
lda $fd00,x
sta PF0
lda $fe00,x
sta PF1
lda $ff00,x
sta PF2
nop
nop
nop
nop
nop
nop
;dey
lda #0
sta PF0
sta PF1
;Second scanline
sta PF2
; future sprite loading section
;dey
lda 02
sta WSYNC

;third scanline
nop
nop
ldx $80 	;setup screen loading index
lda $81,x ;load ordered index for scanlines
tax		;tranfer index
;scanline pf loading routine	
lda $fa00,x
sta PF0
lda $fb00,x
sta PF1
lda $fc00,x
sta PF2
lda $fd00,x
sta PF0
lda $fe00,x
sta PF1
lda $ff00,x
sta PF2
dec $80
nop #2
;dey
nop
nop
lda #0
sta PF0
sta PF1
;fourth scanline
sta PF2
; future sprite loading section
;dey
ldx #13; not sure on value?
countdown	
dex
bne countdown

ldx $80 
bne kernelmain

;lowerkernel

ldx #3
lda #$26
sta COLUPF
freshfloor
stx $80
ldx #8	
lda #$ff
sta PF0
sta PF1
sta PF2
floorkernel
; future sprite loading
sta WSYNC
dex
bne floorkernel
;floorbreaks	
lda #0
ldx #2
sta COLUBK
sta PF0
sta PF1
sta PF2

secondblank

; future sprite loading	
lda #2
sta WSYNC
dex 
bne secondblank
ldx $80
dex
bne freshfloor

;endofkernel
ldy #30
sta VBLANK
redoit    
   sta WSYNC
   dey
   bne redoit
   jmp Start
   ;future game engine code
   
   ORG $FA00
   
   .data %11110000
   .data 000000
   .data 010000
   .data 100000
   
   ORG $FB00
   
   .data %11111111
   .data 000000
   .data 101001
   .data 100100
   
   ORG $FC00
       
   .data %11111111
   .data 000000

   
   
   
ORG $FFFA



.word Reset          ; NMI

.word Reset          ; RESET

.word Reset          ; IRQ

 

Castlevania 2600 level1.bin

[Fischer500]

WOW. This looks so freaking awesome! I couldn't get it to work, but still... it rocks! IF this becomes a game cart, I think I'd pass out. Then I'd wake up,and pass out again.

[+grafixbmp]

It works ok for me. There may be a lower number of scanlines but stella did ok for me to see it.

[+Random Terrain]

Nice to see a working demo. Works for me with Stella, but the scanlines seem to jump between 263, 264, and 265.

[+stephena]

It works ok for me. There may be a lower number of scanlines but stella did ok for me to see it.

Not related to your game, but you should look into upgrading Stella to 3.0. There have been a ridiculous number of fixes since version 2.5, not the least of which is a fix for weird characters in the disassembly (which can be seen in the snapshot above).

[+grafixbmp]

Alright, now I have a version 1.0 arangement of all sprite data and most of their associated colors aligned into a 4K space. There will actualy be 8K where the second 4K bank is a dupicate of the first with a few minor changes to the sprites and totaly diffrent playfield data. The frames alternate between the 2 banks so that the playfield layers the main outline one frame and adds colorful things to the screen the second frame. I may find myself eliminating some of the redundant color pallettes to save more space. The lower lefthand corner of the 4K map is where playfield data will be located for each bank. much of the data can be reused all the time so I can get plently of frames based upon a prearanged table list for each screen.

 

I am also debating on taking a queue from the prince of persia port to 2600. Making the playfield reflected and doing only 4 writes instead of 6 thereby saving precious time for more of the objects display routines. This will also save more space by using less playfield data.

 

[RASK1904]

forget best 2600 homebrew. This would be the best homebrew ever! I cannot express how bad ass this is. Just read the whole thread. Love it man. This thing is coming along amazing. You have to finish this!

[+grafixbmp]

By George, I think I have it now! It will be done with PF reflected and next to no writes to PF0. This won't be true of the HUD though. This helps with so many things including better alignment to the original game layouts. I also think the way I want to do the movable objects may give me control of the ball as well. The Super Chip will be a must though atleast until a Harmony is in my hands. I will be redoing the full first level with all the new changes minus the visual flicker which by the way should not be noticable much. And as for multiplexing the objects, that will be a piece of cake.

 

After seeing how well it looked for prince of persia, I agreed with the look. And today I saw the Castlevania movie to comeout 2011, this would be perfect to parallel the release. I have much work to come. As of now, I only am shooting for the first level but If the schedule permits, level 2 may join the ranks as well. As soon as the first level is completed, The engine will obviously be done if anyone would like to then compile the bianary data for the other levels, please do. I will then post the raw scanline data for the levels so others can use it as it will be the total of the raw data table used for all levels, or atleast half of them.

[+grafixbmp]

The new kernel allows for so many new things.

 

* Increased vertical resolution

* Robust color pallette

* More kernel time for all objects

* Takes up less raw data than previous version

* etc

 

I feel I have a new vigor for design again. I figured I would use the new multi color pallettes to ad some accents to the collums. Wanted some feed back. This isn't anywhere near final, just a test image. I'm quite excited about this almost bact to the original conception of the port.

 

 

Now with objects added.

Edited October 29, 2009 by grafixbmp

[lapetino]

The new kernel allows for so many new things.

 

* Increased vertical resolution

* Robust color pallette

* More kernel time for all objects

* Takes up less raw data than previous version

* etc

 

I feel I have a new vigor for design again. I figured I would use the new multi color pallettes to ad some accents to the collums. Wanted some feed back. This isn't anywhere near final, just a test image. I'm quite excited about this almost bact to the original conception of the port.

 

 

Most excellent. But what are the green lines for? Hard to see at the small size...

[+Random Terrain]

Many pants will be pooped if the game is really going to look that good.

[+grafixbmp]

I'm going to need to run some tests to find the best colors that blend well. This image is a 1-2 frame comparison of the full image and I am hoping since the majority of the whole image is in a constant flicker rather than just a portion of the screen, then it may not be too noticalbe especialy since the playfield doesn't move. Many times i've seen color blending at 30Hz, I rarely notice the flicker. Since the playfield(s) are always on the same colored background, this should minimize distortion. I will get a single image going and see how it looks. If I don't get a headache, then it should be fine lol.

 

Edited October 29, 2009 by grafixbmp

[MausGames]

I tried it as an animation at 50fps; my gif animator goes by 1/100th of a second increments, I'm guessing that is gif standard. Everything looked ok, but I'd say Simon suffers the most. He looks very washed out and none of his details stand out against the gray walls. Not sure why you use dark gray instead of black for the bg, but it does make quite a noticeable difference in the flicker as well; will you be using dark gray or black in the actual game?

Edited October 29, 2009 by MausGames

[+grafixbmp]

I tried it as an animation at 50fps; my gif animator goes by 1/100th of a second increments, I'm guessing that is gif standard. Everything looked ok, but I'd say Simon suffers the most. He looks very washed out and none of his details stand out against the gray walls. Not sure why you use dark gray instead of black for the bg, but it does make quite a noticeable difference in the flicker as well; will you be using dark gray or black in the actual game?

I only had a fleeting thought but I figured I would use black. I also figured I would end up making the BG one shade darker gray anyway. Would love to see your gif posted. Oh and the only thing about simon is he will only be flickered when using an item such as whip, throwing something, etc.

 

Well I did some revisions if you would like to try animating it and see if the color changes help both simon and the basic outline

Edited October 29, 2009 by grafixbmp

[MausGames]

Here is what i got; it was fast and sloppy so I might not have gotten them aligned correctly. Selective flicker on Simon sounds like a good plan. I tried filling in your bg graphics as solid and black-only, and they honestly look really good that way. I appreciate what you've done to increase detail and color depth though.

 

Edited October 29, 2009 by MausGames

[+grafixbmp]

I went ahead and came up with this one. How ya like it?

 

 

I know this may be far in advance, but I had thought about how the second level might look. I would like to have the BG be a shade of red but I also wanted to use the darkest blue possible instead of black but I am afraid if I went with the traditional color pallette, they will turn out purple unless there are color combinations out there that will get a red and a dark blue?

Edited October 29, 2009 by grafixbmp

[MausGames]

I think you should keep the walls the lighter gray, and instead make Simon slightly darker if possible. Then if there are levels with black backgrounds, bring his colors back up a shade. Looking at the frame that contains Simon, there just doesn't seem to be enough contrast, with or without flicker. I could be completely wrong, definitely get more opinions.

[+grafixbmp]

I think you should keep the walls the lighter gray, and instead make Simon slightly darker if possible. Then if there are levels with black backgrounds, bring his colors back up a shade. Looking at the frame that contains Simon, there just doesn't seem to be enough contrast, with or without flicker. I could be completely wrong, definitely get more opinions.

 

All thoes things are easily doable and I agree.

 

One thing that troubles me is interaction with the playfield. I need to be able to do these things:

Not go through walls.

Detect stairs. simply pass by them or press upward to walk up them when present at them.

Ignore any screen artwork (widows, pillars, curtains, etc)

recogize all floors.

 

Since I will be using 2 separate images, I can do contact combinations with them.

 

frame 1 - 0

frame 2 - 0

 

frame 1 - 1

frame 2 - 0

 

frame 1 - 0

frame 2 - 1

 

frame 1 - 1

frame 2 - 1

 

This would mean that the whole level will need to be designed around the movement of simon which removes much of the artwork which isn't so bad but is a major handicap.

Any thoughts?

 

Updata: I redid a gif with the modified colors and I must say, it looks great. However my gifs run too slow. Could ya speed them up some?

Edited October 29, 2009 by grafixbmp

[tokumaru]

I don't want to be mean, in fact I like your project a lot, but I think you rely on flicker too much. In my experience, flicker is not a clean effect, the frames never blend perfectly, and you can always see that that there's something wrong when playing on a TV. Worse than that, it's tiresome for the eyes, and can even give headaches, specially if it's such a large portion of the screen like in your game.

 

So, unless you want your game to be playable only in emultaros that cleanly blend frames, I suggest you cut down on the flicker a lot, even if that means giving up on some color detail. Flicker is acceptable for sprites because they're small, but if such a large portion of the screen does it, players will have seizures with that game.

 

Also, have you seen like a TV slightly modifies/distorts the image depending on the brightness of the scanlines? I can't explain exactly and I don't know what causes this, but try to display an image in your (crt) TV that's half dark and half bright and you'll probably see some distortion if you compare both sections. I can only imagine how bad this effect will be when you flicker between black and gray (for the borders) every frame!

[+grafixbmp]

I don't want to be mean, in fact I like your project a lot, but I think you rely on flicker too much. In my experience, flicker is not a clean effect, the frames never blend perfectly, and you can always see that that there's something wrong when playing on a TV. Worse than that, it's tiresome for the eyes, and can even give headaches, specially if it's such a large portion of the screen like in your game.

 

So, unless you want your game to be playable only in emultaros that cleanly blend frames, I suggest you cut down on the flicker a lot, even if that means giving up on some color detail. Flicker is acceptable for sprites because they're small, but if such a large portion of the screen does it, players will have seizures with that game.

 

Also, have you seen like a TV slightly modifies/distorts the image depending on the brightness of the scanlines? I can't explain exactly and I don't know what causes this, but try to display an image in your (crt) TV that's half dark and half bright and you'll probably see some distortion if you compare both sections. I can only imagine how bad this effect will be when you flicker between black and gray (for the borders) every frame!

This isn't the issue that it use to be with older televisions. Newer units (LCD)can get rid of most noticable flicker and many newer tricks rely on heavy flicker to get more on screen than before anyway (4 colors instead of 2). I foresee lots of newer games using flicker heavy screens in conjuction with the harmony/Melody carts since they can proccess more. I figure that it's all about choosing the right color combinations that blend well on screen for minimal distortion. I wish there was a chart that displays most of the best 30Hz color combinations possible. That way many would know what works best and what doesn't.

 

15Hz is the worst though. 20Hz is pushing it.

 

And it may even be possible in code to darken down the borders for the even frames just by changing out the BG color at the right times.

Edited October 31, 2009 by grafixbmp