solidcorp

Since there isn't enough CPU time to draw a 48 pixel display plus missiles and the ball, I suppose you flicker or interlace between shield and other objects? Actually, I think there may be enough time to load the sprites, missiles, and the ball in double line mode, but there wouldn't have been enough ROM. The shield drawing routine is pretty huge as it is, and there is only one free byte left in that 4k bank today. Your shield seems 46 pixel wide and about 90 pixel tall. Most rows seem interlaced, but not all (top left outer shield, why that?). I wonder how you store this information in the RAM. Even interlaced you would need 6x45 bytes, so there must be a trick I am missing. BTW: I never played the game, so I suppose, the rings are not just animated static segments, but the player can shot holes into them. They are indeed 46 pixels wide and are 92 double lines tall - you must have really been counting. In the original design the shields were represented internally as arrays of bytes that the CPU shifted to rotate. It was easiest if the number of bits in each ring was divisible by 8, but i settled on 16 bytes for the outer ring, 11 bytes for the middle ring and 5 1/2 bytes for the inner one. That is where the actual size came from and actually, it is a little too big compared to the coin op which had more room to fly the smaller ship around on. You can get a lot more fine detail on a screen with vector graphics . I'm happy with the balance I've struck here though. I just posted you tube video links for you and others who haven't seen the original. The shields were vector 12-gons with individual sections that could be destroyed. You can't just go blowing pixels out of a bitmap, there are 12 discrete sections with clear boundaries. The Atari 2600 version has 12 discreet sections but they had to be done in a circle rather than an 12-gon, it was the only way I could think of to do it within 8k which was the maximum cartridge size of the day. Even though Yars Revenge was an original game by its own right, it drew many vital game elements from Star Castles design and it is an outright miracle that all that gameplay and the game configurations were made to fit into the 4K cartridge. Instead of moving all data when the ring rotates, couldn't you just move parts of the data and e.g. the outer ring by just changing the offset into the circular buffer? Or would that result into problems when drawing it? I am really interested how your data structure looks like. The final algorithm works similarly to what you described but it's kind of a hybrid and it uses some trickiness that is necessary not only to move and draw the shields but to actually collide with them and knock them out. I was going to share the data structure but some others here were sounding like they may take a crack at writing a version of the game and to be honest with you, I'd like to leave that part as an exercise for the readers. I'm interested to see how others crack this problem. D. Scott Williamson

That's a really good idea but I think you caught on at the end that there may not be enough RAM/cycles to pull that off. My routine (and there may be other equal or better approaches) really packs the bits so they fit in RAM and they can be drawn in a tight kernel later. Also, my routine packs the shields and cannon into 60 bytes at one bit per pixel, at 4 bits per pixel it wouldn't fit in RAM. The nibble packing is a different geometry that would be hard for the 2600 to draw. I don't want to discourage you, that was a very clever approach. D. Scott Williamson

I should have posted these earlier. Here are the better youtube videos of the original coin op I used for reference Star Castle And the crash D. Scott Williamson

Thanks a bunch. I believe that Crimefighter had the high score and it was between 33,000 and 37,000 at VGS. Next time I show the game we will need to start over though because several bugs have been fixed including collision and scoring issues that make playing the different versions of the game an unfair comparison. (Crimefighter, it looks like your VGS 2010 record will stand for eternity ) D. Scott Williamson

Thanks, and it just got better! Hardware pixel accurate collision, improved shot shield collision, a better attract mode, fixed drone sound, and a handful of bugs got fixed this weekend. The big items remaining are increasing difficulty and adding accuracy to shot trajectories, both of which I have made a plan for and have freed some RAM/ROM for. My cart function is much improved thanks to batari's suggestion too, though I still think there may be situations in which I get false bank switches. I'm writing a test ROM to validate my cars function completely. He was right, once I started looking at the address lines up on the scope(s), I hadn't accounted for enough (any) settling time and while I can't look at 13 address lines at a time, I can definitely see how false clocks could occur. I get the feeling that this is a typical logic vs analog pitfall that engineers with programming before electronics experience are prone to. Live and learn. Thanks for the tip! Oh, and one more thing. I may have heard indirectly from Howard Scott Warshaw through a private conversation re. my youtube video. Both he and the intermediary complemented the work and we've been discussing the history of 2600 development around that time. I have no reason to doubt they are who they say they are, the conversation is allegedly with one of the interviewers, but I'll need to verify it ... and I'm a lot less likely to be posting any private messages to the forum without the consent of all parties concerned. As I have said before, I plan to finish the cartridge before contacting Howard Scott Warshaw directly despite the cat being out of the bag so to speak. D. Scott Williamson

Thanks ls650! D. Scott Williamson

D. Scott Kudos to your game, awesome work! I can appreciate how you feel and I will fall in the camp of gamers that will respect whatever your decision is and still pat you on the back for a job well done. On another note, I was going to respond with pretty much the exact thing save2600 said in the above quote (except that I love emulation as well but Save2600 probably means the ones that ONLY play emulation) . I think your concern about a gamer stealing the ROM is a bit miss placed specifically when dealing with the tight knit 2600 community.. Thanks Atari2600Lives! D. Scott Williamson

LOL - Nathan you and I think alike - that was one of the first things I thought of too. Unfortunately, that would require Rip-Off being completed someday (j/k)... I would like to compliment Mr. Williamson for what looks like a fantastic port of Star Castle - one of my favorites from back in the day. I, like so many, wait with anticipation at a chance to play the game some day (and buy a copy should it ever be sold). Reading the posts this reminds me of how I felt challenged to port Lady Bug. It was believed that a decent port could not be done, and it certainly was a thrill to put together a game (with lots of help, mind you) that proved otherwise. As the development thread shows, this was a collaborative effort from the design point-of-view but I was still able to come up with mostly all of the 'tricks' that allowed the game to be ported over with little or no compromises. Additionally, because of the feedback from the community and help with the sounds (Bob D) and graphics (Nathan) the final result was even better than I could have imagined. By comparison, my port of Caverns of Mars (titled Conquest of Mars) was developed 'in secret' (for certain reasons beyond my control) and only released directly to the AA store. Although I am proud of the technical achievement, I do wish that I could have used a similar approach as I ended up using in Lady Bug for it would have certainly produced a better 'game', and in the end that is what I feel is the most important reason to program for the 2600. Anyway, just some thoughts about the challenges I faced when making a game for the 2600 - maybe these experiences can help you decide the best approach for the development of Star Castle. Good luck on finishing Star Castle... if there's one thing that I've learned is that it's very difficult to call a game 'done', especially when it's a 2600 game and you still have cycles/ROM to use... there's always 'one more thing' Thanks so much, and I'll finish it if it kills me (or my wife kills me ). Seriously, it's close. D. Scott Williamson

Hi Thomas - Yes - the shields are rotating. I'm not sure how to get screen shots off of YouTube (beyond capturing the whole screen)... if I can figure it out I'll post them here. I'm sorry about the delay, I'm the only one who could post actual screen shots and I have been unavailable. Here are some that show the shields rotating. D. Scott Williamson.

Thanks littleman jack! D. Scott Williamson

I didn't use playfield pixels because they are each 4 player pixels wide, but there is no reason they couldn't be used. The method you outline sounds interesting but my method is a little different. There's more than one way to skin a cat, especially in software. I used the two players, missiles, and the ball for all the graphics and only used the playfield bits for debugging which is commented out now. You can display each player triplicated (is that really a word? 8 bit image repeated 3 times 8 bits apart). I triplicated each player and positioned them centered on the screen so that they interleaved each other like this P0 P1 P0 P1 P0 P1, each sprite filling in the spaces between the others images. Normally the same 8 bit pattern is displayed in each 3 images for each player but if you load the graphics registers very quickly with just the right timing and some creative programming you can just stay ahead of the electron beam and display 48 unique bits of sprite graphics. That's how the title screen, score screen, and shields/cannon are drawn. The routines to draw the shields pull bits out of a packed structure in RAM and mask them for display. Logically, each ring is a circular bitmap, albeit in a complicated nonlinear data structure. The bits are packed into memory in a way that is friendly to the draw routine which must be done very quickly. There is one large routine that calculates which shield segments are on and which are off with rotation, which is simply a scroll function since each ring is a circular bitmap, and fills the appropriate bits accordingly. The cannon frame is also packed You are definitely on the right track with the trig; I use sin and cos tables for shot and fuzzball velocity, ship thrust velocity vector, and the trajectories of the sparks. I use a custom atan2 table to calculate relative angular directions to things to get the cannon to face the ship, the ship to bounce off the shields, the sparks to chase the ship, and as part of the calculation to determine which shield a shot has collided with. IDK if batari basic already has any function for 48 pixel wide sprites but that may be a nice addition if the timing intricacies can be handled at compile time. D. Scott Williamson

Yes, please, we don't need to taint this discussion with that. ..Al OK. Sorry. D. Scott Williamson

Has anyone ever heard of anyone getting their hands on one of these Atari keyboards? http://www.atarimuseum.com/videogames/consoles/2600/keyboard/ It doesn't look like it was finished, but it looks like a cool start. That looks like a 400/800 drive cable. D. Scott Williamson

I'd still like to hear someone tell in their own words what went down with the 7800 Gorf guy. D. Scott Williamson I suggest that should be done via PM, we don't need another piracy flamewar breaking out. The story keeps getting better and better, more tantalizing - okay if anyone wants to message me, I'm all ears, but I will head the moderators warning and drop it. D. Scott Williamson

I'd still like to hear someone tell in their own words what went down with the 7800 Gorf guy. D. Scott Williamson

Page 89 of this 2600 field manual is getting close to what I'm looking for: http://www.atariguide.com/pdfs/Atari_2600_VCS_Domestic_Field_Service_Manual.pdf D. Scott Williamson

Thanks, you may have salvaged my weekend D. Scott Williamson

I'll be happy to talk about it later but I want to get it done and working first. I have some questions about bus timing on the Atari though. My bank switching used to work and now it's broken. There's a good chance that I messed up the combinatorial buss logic when I edited the file last (it was a cleanup - some cleanup ), but now it appears to doing bank switching when it's not supposed to. Is there a good buss timing diagram for the 2600 somewhere? So, am I correct in assuming that A12 is really an active high output enable? Does it go low high low for every byte read or does it stay high for sequential reads? (can it alone be used as a clock)? Do A0 - A12 transition lazily (simultaneously) or does A12 (OE) lead or trail the address lines? Put another way, if used conspiratorially to generate a clock are overlapping address line transitions likely to generate false clocks? I can and will sort all this out, but the best I have is a digital dual trace (three if I view the trigger line) osciliscope so it takes time to really get a handle on buss transitions. I bet you anything that I've accidentally inverted the internal clock line which will kind of look like its working most of the time, which is the observed behavior. Thanks, D. Scott Williamson

Actually, I have many types of PCB's available most of the time, I can even provide you with PCB's that support the SARA chip (more RAM). Thanks CPUWIZ, actually your boards were the ones I found later. Making my own board turned out to be fun though. D. Scott Williamson

I am sure I could help here. In the words of Ren Hoek "I can do it... myself!" (bonus points if you have any idea what I'm talking about) Thanks for the offer, I've made it this far and I'm compelled to complete it on my own. No bonus points for me, but I completely understand. BTW: I suggest you to set yourself some kind of deadline, else you might never finish your project. Will do. Did you have a look at other people source code (e.g. disassemblies or homebrews)? Actually, originally, I got out my xeroxed 6502 reference pages, Atari notes, and yellowed fanfold printouts from when I worked at Atari. Later I did look at internet reference, code snipets, and demos from Bjars, alienbill (HTML stella manual), and others. I found the Harmony cartridge here on Atari Age and was driven to design my own PCB and logic because of the [understandable] unavailability of carts and cases (I found some later). I needed the most help in audio which is ironic because the code I wrote for the 2600 at work at Atari was a digitized sound driver. I didn't look at any home brew source or bins until I looked into some of the links here on the forum. I haven't necessarily been part of the community. D. Scott Williamson

I am sure I could help here. In the words of Ren Hoek "I can do it... myself!" (bonus points if you have any idea what I'm talking about) Thanks for the offer, I've made it this far and I'm compelled to complete it on my own. No bonus points for me, but I completely understand. BTW: I suggest you to set yourself some kind of deadline, else you might never finish your project. Will do. Did you have a look at other people source code (e.g. disassemblies or homebrews)? I did, it was VGS Seriously without that deadline I wouldn't have it nearly this far right now - ask my wife, she missed me in the evenings for the last few weeks. D. Scott Williamson

I am sure I could help here. In the words of Ren Hoek "I can do it... myself!" (bonus points if you have any idea what I'm talking about) Thanks for the offer, I've made it this far and I'm compelled to complete it on my own. However, if I ever release the source I would love to hear what you and others have to say - good and bad - about it. It's damn clever in spots but it's far from perfect. D. Scott Williamson Would that be Ren from Ren and Stimpy? Ding Ding Yes it is.

I am sure I could help here. In the words of Ren Hoek "I can do it... myself!" (bonus points if you have any idea what I'm talking about) Thanks for the offer, I've made it this far and I'm compelled to complete it on my own. However, if I ever release the source I would love to hear what you and others have to say - good and bad - about it. It's damn clever in spots but it's far from perfect. D. Scott Williamson