Porting the original classic Castlevania to the 2600

[kaishaku]

What do you think your final ROM size would be? Looks like the NES one's 128k.

[nonner242]

Sounds wickedly cool!

Keep it up!

[+grafixbmp]

What do you think your final ROM size would be? Looks like the NES one's 128k.

Most of the data will consist of the graphics followed by the music. If these things can be consolidated... no more than 32k. I originaly was thinking around 16 or one of the more obscure ones like 24 or something. This should cover everything. But it is still too soon to know for sure. Right now the first level may be around 8k but alot of that could be reused for each consecutive level and that would help to keep each additional level less in size. But like I said, time will tell.

I decided to go with the f4sc bankswitching scheme this will give 32 k ROM and another 128 b of RAM. I know this will get the project done. having a total of 256 bytes will allow the involevent of dynamic code and this could

get the screens done well.

 

I'd like to thank "Wickeycolumbus" for the suggestion of using f4SC cause I think this will be the biggest defender of this project yet. And with the posting of demo bankswitching test roms lately, it will be much easier to layout the code in a predefined manor. And again, thanks to "Wickeycolumbus" for the demos.

Edited May 6, 2009 by grafixbmp

[+grafixbmp]

I figured since the level 2 music has been made for atari, I would toy with what the second level might look like. I was looking for 3 basic colors to sum up what the level is all about. Most of the time as with the first level there are atleast 3 colors and with quick changes to the palette mid scanline, 4. But anyway, I did a test mock of the first screen just to see what it could look like but even still I need to makesure there is enough time for writes the the PF registers.

 

Was juat wondering if you guys like the color scheme. Granted this image is far from complete and will need more filler but right now I just wanted som opinions on the colors. Thanks guys for your support and to thoes who have taken an active part.

Edited April 25, 2009 by grafixbmp

[+grafixbmp]

I should add that the other songs in Castlevania are much more complicated, and will be a lot trickier! Still, this only took a few hours total, so it wasn't that bad.

Since you have already done level 1 and 2, do you still feel this to be true in retrospect regardless of precussion not being added?

Edited April 25, 2009 by grafixbmp

[kaishaku]

Some more music, programmed last night while my Internet was out:

 

castlevania_level1_07.bascastlevania_level1_07.bas.bin

The drums haven't been added yet, but it's a reasonable approximation. I've deliberately coded it very inefficiently, to make the raw data as clear as possible. I'll have to think about how I'd like to add drums.

 

Hi, you did an awesome job on this so I certainly don't mean to upset you with this suggestion:

 

There's 4 places where you use pitch 24 on distortion 1 for an E, but it's way sharp. Changing it to 25 gives you a really flat E, but it sounds better to me because all of the notes around it are also really flat.

4,1,24

=>

4,1,25

 

I've attached updated versions that reflect this suggestion. There's still one more note that really bugs me in the ascending chords at the very end, but I haven't pinned that one down yet.

 

castlevania_level1.bas.bin

castlevania_level1.bas

[BDW]

Now THIS would be cool in cartridge format....

[+grafixbmp]

...or a self-modifying line kernal, which allows up to 10 transfers from anywhere in rom to hardware registers (potentially consuming nearly half of native ram temporarily, tho). In such a case, you'd use multiple variations of the looped routine that goes into ram and decide which of them to set up and branch to while less-demanding scanlines are being displayed...and leave the same way. The results could fool you that the display was created by a 2600.

I was reading back through original post on this topic and I bet if I went with F4SC (32kb ROM + 128 b RAM) then I could use this exact method. This would be plenty of ROM space for every level also.

[+grafixbmp]

Ok going with f4SC has totaly changed my aproach tward the kernel and so I would like to look at all possible designs and go from there. when it comes to how the objects are used, I would like to use both players and both missles but given most senarios, player 1 will be used many times on the screen with atleast 2 scanlines separating any of the player 1 graphics.

 

If i understand the f4SC then no mater which bank I am in, the extra RAM is accessable from any bank so any pieces of data used for any screen could be stored there before a new screen is jumped to. THis could help with data for the PF. I will work on some layout that may be able to help me design a better kernel.

 

If f4SC gives 32k and an extra 128 bytes of RAM, how is that really layed out. I had heard that the first 256 bytes are the ram access with the first 128 being write and the lat 128 being the reads. the rest would then be the rom for the first bank. Is the ram actualy accessable from all banks? if so then is the ROM actualy more like 30 k since every bank omits the first 256 for superchip RAM access?

Edited May 23, 2009 by grafixbmp

[SeaGtGruff]

If f4SC gives 32k and an extra 128 bytes of RAM, how is that really layed out. I had heard that the first 256 bytes are the ram access with the first 128 being write and the lat 128 being the reads. the rest would then be the rom for the first bank.

Yes, that is how it is laid out.

 

Is the ram actualy accessable from all banks?

Yes, it is.

 

if so then is the ROM actualy more like 30 k since every bank omits the first 256 for superchip RAM access?

Yes, each bank of ROM has 3.75K of usable space, so if there are 8 banks of ROM, that's a total of 30K.

 

Michael

[+grafixbmp]

If f4SC gives 32k and an extra 128 bytes of RAM, how is that really layed out. I had heard that the first 256 bytes are the ram access with the first 128 being write and the lat 128 being the reads. the rest would then be the rom for the first bank.

Yes, that is how it is laid out.

 

Is the ram actualy accessable from all banks?

Yes, it is.

 

if so then is the ROM actualy more like 30 k since every bank omits the first 256 for superchip RAM access?

Yes, each bank of ROM has 3.75K of usable space, so if there are 8 banks of ROM, that's a total of 30K.

 

Michael

Just another thing among many things that deal with the atari where you have to calculate to know what you have. From now on I will refer to f4SC as 128 b RAM and 30 k ROM cause that IS exactly what it is.

[nonner242]

Hell yah it would.

Id love to do the art mock up for the box/label!

[+grafixbmp]

Hell yah it would.

Id love to do the art mock up for the box/label!

Go right ahead. That would be awesome.

[Gemeni]

Looks great I dont much about programing but all I can say is so far what you have done looks great keep up the good work I hope I can play this soon!!!

Edited June 9, 2009 by Gemeni

[+grafixbmp]

Sorry for no update in forever but I've been a busy bee. I haven't ditched castlevania at all but woundup burt out for a while and stuck for some time. However, I think I may have a breakthrough for the kernel that will enhance not only sprite register updates but resolution as well. This will also allow a mix and match sorta speak of backgrounds easily. I even thought about having background color changes as well for specific screens at specific locations.

 

I will need to redo most of the level 1 layout only for the vertical res. This can be a more generic kernel now cause loading the PF won't be so elaborate as before. I think this project may work best with a dual frame kernel where the overal color outline of the level is used for one frame and the sub tones are used the second. Kinda like first frame even scanlines in outline color and second frame odd scanlines with color bands dependant on the current screen. The BG color will not change during these areas. Only the special areas outside of game play like water and floors. This greatly frees up so much since one scanline dedicates itself for simon and playfield and the next is only used for the majority of all sprites. Alternating the screens for this so called combing effect can allow totaly diffrent bands of data to be combined for dozens of unique screen frames while leaving plenty of screen time for probaly every single sprite to be loaded besides the need for H moves.

 

I was inspired by the former work on jumpman, just with a twist.

 

So... What do the experts think?

 

Also on a side note, a slight side effect that might enhance the ghostly effect of the game is that when any sprites are flickered for more objects, there will be banding across the sprite where every other linewill slightly bleed through from the playfield, not sure how this will turn out but I think the benefits out way the negatives here.

Edited August 5, 2009 by grafixbmp

[+grafixbmp]

I have a simple mock to ilustrate. The mock isn't done but it shows that for every piece of data is double scanline but skips every other scanline for more sprite data room and then the next frame shifts down one scanline and does the same.

 

I have the new image the old image and what will be each of the 2 frames that make up theach screen.

 

 

I'm not sure if any other games have attempted this display method, but I have high hopes and I am rather sure this version will be easier to code since everything gets spread out more and can be more generic in nature than before. I already know this scales down the kernels quite a bit more than before. I also thought about having several types of kernels which load data in diffrent ways so that I can acheive a kind of dynamic loading.

 

The main kernel type can load a strait ROM table for a screen section. Another can load from the same data but for certain registers can load a preloaded section from RAM rahter than ROM. This will allow for new sections to be slightly diffrent than others based upon the kernel section used to load the data. With the extra ram from the super chip, this is quite dynamic in nature. And for the playfield sections, only player 0 is loaded with new data. Then the next whole scanline is then dedicated solely to sprites.

 

I could have around 8 to 10 types of kernels that can load the same data tables but each kernel can then load alternate data from RAM that would be pre loaded outside the kernel. Each type of kernel loads specific registers in specific orders from RAM thereby keeping lots of detail for many levels while minimizing data storage. (I hope)

Edited August 17, 2009 by grafixbmp

[StanJr]

This was my original ambition when I wanted to journey down that road to asm programming. However, it proved better than I and I have happily left it to better, stronger minds. I am so excited about this project I cannot properly express it. Everything looks so great! Please keep up the effort and keep us posted on your progress!!

 

wow.

 

[+grafixbmp]

As a bonus, On another thread I have been disscussing adapting another more advanced control to the atari... an NES controler. Given that it winds up working, I will have both controler types (NES and joysticks) avaliable if there is enough room in the code for it. I don't think this will be a problem. Only in the last year have I been able to make considerable headway with the kernel code. If This part can be completed, The rest should be gravy.

[StanJr]

Dude, you are just busting up ground like there is no tomorrow! How soon until we can get a playable anything on this?

[+grafixbmp]

I don't know about "playable". I would imagine the first builds will be more like how jumpman 2600 port work went. However, cstlevania will atleast have a finished first level. After that, only time will tell.

 

It's looking like the first thing I end up putting out will be the overall first level. 15 cycled playfield screens and no sprites yet. no control or gameplay. But atleast the level's look will be there.

Edited September 5, 2009 by grafixbmp

[+grafixbmp]

On a fun note (no pun intended) I happened upon this nice video while searching some castlevania info and thought I would pass it on. THis same guy also did a rendidtion of the jungle theme from Contra. Enjoy!

[+thegoldenband]

That's fun! But my favorite version is still the one played by The Advantage:

 

[+grafixbmp]

That was awesome. I'm familiar with The Advantage but haven't heard alot from them. Heart of Fire seems to be rather popular. Did they do one of that? I even found a rap of Jay-Z done to HOF.

[Synthpopalooza]

As a bonus, On another thread I have been disscussing adapting another more advanced control to the atari... an NES controler. Given that it winds up working, I will have both controler types (NES and joysticks) avaliable if there is enough room in the code for it. I don't think this will be a problem. Only in the last year have I been able to make considerable headway with the kernel code. If This part can be completed, The rest should be gravy.

 

Idea: use a sega genesis controller instead. Button B is mapped to the regular joystrick trigger, while button A is mapped to the paddle(0) register ... at least that's how it works on the Atari XL ... I programmed a Tetris game on the Atari XL (Tetricize) which uses both buttons to rotate the falling piece, and a similar control was used on Bill Kendrick's GemDrop game ... will this control scheme work on the 2600? Might be worth a try.

Edited September 29, 2009 by Synthpopalooza

[nonner242]

As a bonus, On another thread I have been disscussing adapting another more advanced control to the atari... an NES controler. Given that it winds up working, I will have both controler types (NES and joysticks) avaliable if there is enough room in the code for it. I don't think this will be a problem. Only in the last year have I been able to make considerable headway with the kernel code. If This part can be completed, The rest should be gravy.

 

Idea: use a sega genesis controller instead. Button B is mapped to the regular joystrick trigger, while button A is mapped to the paddle(0) register ... at least that's how it works on the Atari XL ... I programmed a Tetris game on the Atari XL (Tetricize) which uses both buttons to rotate the falling piece, and a similar control was used on Bill Kendrick's GemDrop game ... will this control scheme work on the 2600? Might be worth a try.

 

I like!