Jump to content
IGNORED

Porting the original classic Castlevania to the 2600


grafixbmp

Recommended Posts

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 by grafixbmp
Link to comment
Share on other sites

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.

post-10601-1240685450_thumb.png

Edited by grafixbmp
Link to comment
Share on other sites

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 by grafixbmp
Link to comment
Share on other sites

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

Link to comment
Share on other sites

...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. :)

Link to comment
Share on other sites

  • 4 weeks later...

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 by grafixbmp
Link to comment
Share on other sites

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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

  • 2 weeks later...
  • 1 month later...

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 by grafixbmp
Link to comment
Share on other sites

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.

 

post-10601-1250488669_thumb.png

 

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 by grafixbmp
Link to comment
Share on other sites

  • 4 weeks later...

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.

 

:spidey:

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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 by grafixbmp
Link to comment
Share on other sites

  • 3 weeks later...

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 by Synthpopalooza
Link to comment
Share on other sites

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!icon_mrgreen.gif

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...