grafixbmp

these days anything is possible. Even the endevors with the harmony/melody cart types, interfaces nicely with atari hardware. System link for atari would probably work best by using cart to cart conections. I imagine there could be the possibility of 2 melody boards being hooked together and exchange data through a custom connection. You could ask batari about the chances of that being possible.

Been doing some basic tests with the kernel and thought I would share the current progress. things added: joystick sampling (data readout between where HUD area and game screen meet) temporary hard coded animation to guage best animation speed(s) raw vertical movement (no actual jump or crouch yet) The animation looks a little off but thats because horizontal movement has not been added yet. Doing baby steps here. Every step is a step twards progress. update: I removed the constant animation and added left facing to the mix. Just tryin to get a feel for the controls. Guess im getting in the 'zone' or something Next on the list is horizontal movement and jump and crouch graphics And BTW, some documentation out there for the TIA is incorrect with respect to REFP0 (REFP1). For D7|D6|D5|D4|D3|D2|D1|D0 (the register associated with REFP) It is "D3" that needs to be set. Some documents I have read as D2 which does nothing. This needs to be 0 for non reflective and 1 for reflective. This is the most current file. Castlevania 2600 kernel v2.6.1 new input.bin

Been doing some basic tests with the kernel and thought I would share the current progress. things added: joystick sampling (data readout between where HUD area and game screen meet) temporary hard coded animation to guage best animation speed(s) raw vertical movement (no actual jump or crouch yet) The animation looks a little off but thats because horizontal movement has not been added yet. Doing baby steps here. Every step is a step twards pogress.

Ok I retooled the palette and came up with this.Castlevania 2600 kernel v2.5 new4.bin

Are you running in emulation or an actual console? I created an image from emulator screen captures and placed all versions on simon side-by-side for comparison.

I got some advice from a friend of mine and came up with this color scheme. It appears to be a bit more balanced over the whole sprite and may just work at a 30Hz as well as the normal 60 so an extra palette may not be needed. Castlevania 2600 kernel v2.5 new3.bin

I wasn't too sure on the colors either. I lightened most of them a shade or two and it does feel a bit more even. I'm considering having 2 main pallettes. one dark and one light. if the background color is light like the test screen then the light one will be used for 60Hz and and the dark one for 30Hz. If the background color is dark then they will be inverted. (dark 60Hz light 30Hz) Castlevania 2600 kernel v2.5 new2.bin

Here ya go.

Time for a minor/new update. I have added player 0 sprite capabilities to the kernel and everything with it seems to be working just fine. There are no controls at the moment since i'm just doing display testing. Things are very much alive just very slow moving. Once the program is expanded out to 32k, ram won't be so constrained and other features can be added. Inquries about source code i'll respond on a case by case basis. Castlevania 2600 kernel v2.5 new.bin

Might I suggest this thread be a sticky. Very handy info for all so shouldn't it be made easy to find?

Thanks but I'm not interested in an s-video mod. I would prefer composite. and I don't need another mod since I built my own. I am only asking if any other components need to be removed from the main board besides what I've already done? Anyone else?

I set out to take my light sixer and get rid of a horrible RF signal. SO I looked up the easiest I could pull off on my budget and went with the latest from Ben at http://benheck.com/book/support/Atari2600VidMod.htm Unfortunately his tutorial is missing where 5+ v came from and doesn't cover a six switch unit so I was able to fill in the gaps with "the atari 2600 video mods comparison project" site. So I constructed the circuit and checked the components over half a dozen times so I know the're right. I also checked for bridged contacts as well. I removed the resistors for TIA pin 2 5 7 and 8 and I also removed the one at the audio point. I now have wires for: 5v + gnd pin 2 pin 5 pin 7 pin 8 audio As of now I have no picture on either a CRT or LCD. Audio sounds fine on the CRT but is horribly muffled on the LCD. On this should I remove/ cut any other items on the main board for the sound to come through clear? Any help please. And to think I went to school for this stuff years ago. ps I've rewired the circuit a second time with fresh wire and replaced the original 2n4401 with a spare thinking I may have blown the first one. Still no luck.

could you perhaps make only one calculation in reference to both players goal post knowing that both sets reside at opposite ends of the same playing field and share a coordinate? Sorta calculate for one then invert the values and save it in case the other player's screen needs them for the opposite side? That is assuming your calculations are based on the coordinates of the game arena grid. I'm sorry. I probably don't understand the full context. I'm gonna re-read the posts.

That what I LOVE so about atari as compared to modern systems. Its like reading a book compared to going to the movies. One has every part of the story done with high detail leaving nothing to the imagination. The other gives just enough so that it sparks the mind to fill in the gaps and immersion can take to the skies.

I stumbled across this technique while trying to make a Simon Says like game, but I'm sad to say that it has fallen by the wayside. One difference is that I'm not using no_blank_lines. simon_8.bas So, the pratfall image just looks like your regular 1 color for background and 1 color for pixels.. BUT, the Simon Says image has at times 4 *different* colors per row!! I just don't understand! When I look at the simon_8 code I see just two sections with pfcolor commands.. How are we getting 4 colors per line? There are after all 4 color registers in the TIA. background, playfield, player0 and player1. So as the image shows, the backbround changes purple colors while the playfield stays grey. One of the player graphics is green then chages to blue while the other player graphic is red and changes to yellow. And finally both players are set to quad size. easy peasy.

I found a neat trick with the demo. Because of the animation of the white player graphic, when you move the graphic directly above the blue bar extending across the playfield and contact with it, then move side to side, the player consistently move slower than not contacting it. This is because for the frame that the extention of the ship is not visible allows it to move but when it is visible it counts as a collision and won't move. I think thats a cool bonus.

I still can't get the images to display on the Figures page. Do they look the same as the ones on this page: http://www.atariarchives.org/dev/tia/figures.php I can't seem to get the figures to load either. They may be the same. THe address details and summary are the best parts that load and the schematics won't load either. If all of it won't work then ya can ignore it. I did an archive of the best parts for future reference. TIA_address_details_&_summary.zip

Thanks. I can't get most of the pages to come up fully or at all, but it looks like the info might be included here: http://alienbill.com/2600/101/docs/stella.html A good portion of it is however, the wording may be a bit easier to understand and the diagrams for me at least are easier to follow (they are colorized ) and it also has the schematics too. It's this part of the site I thought might be helpfull: http://classic-web.archive.org/web/20060924094927/www.howell1964.freeserve.co.uk/Atari/tia/addressdetails.htm And perhaps this: http://classic-web.archive.org/web/20060924094918/www.howell1964.freeserve.co.uk/Atari/tia/addresssummary.htm

Did you have this one. This is an html version of the TIA manual by Jay Miner in 1976. I like the way it has everything layed out. Anything you want to know about the TIA is here. http://classic-web.archive.org/web/20060924093654/http://www.howell1964.freeserve.co.uk/Atari/tia/index.htm

Who would like to try out the first test bin? Extra special thanks to SeaGtGruff. This bin only renders out one game screen. It has not HUD code (yet) and no ame sprites or controls. It doesn't exactly refect the original PNG images i've posted but thats because there are only 19 addresses across 5 pages oout of 256 possible scanline data being used to create the screen. As you can see there are unavoidable color artifacts on the right hand side of the screen. This is a minor price to pay and IMO is easily overlooked. What do you guys think? More to come in time. I'm only posting the bin for feedback. castlevania_2600_2.2_kernel_test_rev.bin

Ok thats what I thought. But what about the proper illegal opcode for a 3 cycle nop? I know lax but not the nop.

Got a few questions dealing with proper syntax and wondered if anyone had the answers. With illegal opcodes, what is the proper syntax and specifically the 3 cycle nop. Is it just adding an operand to it or is it some other abbreviation? If I'm checking if a processor register has reached 0, is it a rule that it has to be check as soon as it has been decremented or any other codebetween the decrement and the branch could corrupt the result? example: right way dey beq special ~ *code* ~ special (do stuff) wrong way dey ldx temp lda mancount,x sta current beq special ~ *code* ~ special (do stuff) I may have other questions later just wanted to confirm what i'm thinking.

Well, At least we all get to play Halo 2600...

I did some basic calculations and worked it out where one single bank can carry so near every single image necessary for the whole game from beginning to end. And the engine is getting closer too. The method I have followed in order to do this port is to rely on the existing game itself since it is what a good port needs to live up to. I played the damn hell out of it learning what to expect in each location just for this game port. I never once looked at its code. I then took record of the simple physics of what was happening throughout the game for every single event. This has been my planning stage for the bulk of the 'real' game itself (engine). This is simply basing everything in the port upon all the doable (on atari 2600) characteristics of the original game encompassing every one of the 6 levels. And then I coded out what happens for every event that happens. Then it was just a matter of connecting the loose ends of every event as coded in asm to each ones trigger and each event in the game to where it should continue when it has finished. I logically deduced The maximum the engine could produce based upon the maximum that could be done in a possible kernel while conserving for resources of the system. This process has made it to where the port will have near, I'd say about 88% to 92% of the original game intact. The 2 main thing different are: No III tile and no scroll at all. Vertical scroll could change in the future but for simplicity's sake it will begin with full static imaging.