Hornpipe2

The existence of separate CHROMA and LUM outputs gives me continued hope of an S-Video mod. I really need to open my FB2 up. EDIT: What about removing the existing 1M rom-containing chip and replacing with our own?

This is a way cool list. I'm actually looking for plug-and-play retro games that are 'moddable', i.e. allow addition of a cartridge slot or a way to get them to play more games. So far I've found the Flashback 2, C64 DTV and the Radica Genesis releases to be potential candidates. Do you think you could add any knowledge you have about hackability to your list? Maybe something as simple as a (M) to denote 'moddable', but leave it as an exercise to the reader to figure out exactly what can be done with them... -Greg

Yes, this is a 'solved' problem. But when you do a non-quarter rotation, source pixels are no longer 0 or 1 unit distant from one another per axis: they get somewhere in between. In that case you have to figure out how best to handle mapping those pixels back to screen-space. Graphics programs apply a filter to fix the results so they still look nice, but you pretty much have to draw this by hand with such a small number of pixels. It may be possible to do it by 'normalizing' all distances to be at least 1, but the result still won't look nice as pixels will become >1 unit distant on the other axis. Your sprites will also grow to greater than original dimensions. One alternate solution to this is vector graphics, which use floating-point by default and are not restrained to a grid like raster graphics. Too bad the 2600 can't handle that : ) But here's how you can take advantage of symmetries to reduce the number of sprites in your code: If your object is bilaterally symmetrical you can draw n sprites to get 4*(n-1) directions. E.g. for 16 directions you draw only 5 sprites: one each facing north, north-north-east, north-east, north-east-east, and east. Everything else is then reachable purely by flips over X and/or Y axis of the appropriate sprite. And if your object is symmetrical both in X and Y axis, you can save on flips. The nne sprite will be the same as the ssw, for example.

Every 2600 reference I've seen is a little different about what exactly needs to be done to ensure maximum compatability and stability across systems, emulators and carts. I was really curious what 'safety' type things need to be included into my assembly source file to prevent e.g. improper loading by the various multicarts, etc. My lack of understanding about this goes as far as not knowing when to disable VBLANK relative to WSYNC #3, etc. I know most TVs are a little forgiving about this stuff, but surely someone has some 'best practice' advice? About all I can say for certain is: * CLEAN_START macro is the safest way to start up. I've also heard that: * VERTICAL_SYNC macro is unsafe in its current (v1.06 macro.h) form * Supercharger needs 0s at $FFF8-9 (?!) * 7800 will freak unless $FFFA-B is 0 Hope my question makes sense. I basically want my game to be playable on any 2600 (and Flashback 2) out there, without fear of e.g. accidentally tripping the bankswitching emulation in TheSave50GamesOn1CartCart or whatever.

Would it be possible to do a nice gradient sky or water? I think that might spiffify the visuals a bit.

Companies can and do get by with 'minor hit' games, and Atari has their name on a number of those now - Neverwinter Nights for example was a huge hit among computer RPG fans and no doubt made them some significant cash. Here's a partial list of other successful Atari-published games - http://en.wikipedia.org/wiki/Atari#Atari.2...s_and_direction I imagine what they'll end up doing is folding up most of their business operations and concentrating solely on the things they know to be 'sure bets' to keep themselves afloat. That means continued publishing of their biggest selling series while dropping a lot of (all) R&D efforts. The Atari brand will surely still be around, but there will be have to be some pretty significant changes in order to survive. I think the end result of any reorganization can only be good for them.

Falcon boards are out now with a 65nm CPU, but there's no way to really tell the difference between them and the older Zephyr boards that are prone to destruction. However... http://citizengame.wordpress.com/2007/08/0...n-rev-has-hdmi/ Evidently, as long as you purchase one with an HDMI port, you get a safer 360. It'll either be the new 'Falcon' board with the 65nm chip, or it will be the older Zephyr with new thermal paste and an additional heat sink. I guess it's not a bad bet though - if yours blows up, just ship it back under warranty : ) You'd probably lose your save games though.

Right, because The Matrix Online was such a phenomenal success. Lots of people are under the misconception that MMOs are basically a license to print money, but there's a lot more that goes into the expense of running them beyond just the game's development (and it's stuff you don't pay for until after the game is done being written). That's stuff like... a big data center to house and secure your servers (air conditioning alone costs a fortune), a staffed and equipped call center for the inevitable millions of tech support needs, a dev. team to keep churning out new content week after week so the subscribers don't get bored and leave, in-game moderators, and more. That doesn't include the team needed to write the inevitable expansion for your game. Gamasutra has a pretty neat article on the hidden costs of MMOs if you're interested. On another note though, not everything Atari put its stamp on has been total crap these past few years. Unreal Tournament 2004, for example, is a great game and is probably still selling new copies today. I suspect that even if Atari's in-house developments are doing poorly, at least they can still get by as a distributor...

I know of you! You did some artwork for OneUp Studios in the past, yes?

Shifting the atlernate frames by half a scan line isn't going to fix the fundamental problem with flicker, which is that the pieces in front of light squares are going to appear much lighter than those in front of dark squares. If the problem can be solved, your best chance at doing so would be to use darker colors when showing the pieces in front of light squares than when you're showing them in front of dark ones. Minimizing the light/dark square contrast would also be helpful. I think it's probably possible to do venetian blinds with your wide spacing, but the code's apt to be nasty (not emulator compatible). If use of proper colors would make flicker-blinds look good with an Atari-sized board, I think that would be the way to go. If what I have so far works on a real 2600, I'll play with the colors some more and then go with that. (Colors have to be changed mid-line anyway) If not, it's back to the drawing board.

Okay, I've put together what I think is an interlaced demo. The gig is up, I'm attempting to write (from scratch) a version of chess that is better than Video Chess in every way... When I finish I'll post some logs of my game vs. Video Chess so you can see who wins! Here's a screenshot from Z26, and attached is a preliminary binary. Please please please, anyone out there with a way to test this on a real 2600: does it interlace or flicker?! I have to get this working before I even think about moving on. chess001.bin

My idea was to use interlacing and on the odd field, draw pieces 0, 2, 4, and 6. On the even field draw pieces 1, 3, 5, and 7. So: | Field 1 | Field 2 | Interlaced | ---- | ---- | ----____ | ---- | ---- | ----____ | ---- | ---- | ----____ | ---- | ---- | ----____ PS for anyone interested in interlacing, this message from the Stella archives shows how to do it: http://www.biglist.com/lists/stella/archiv...8/msg00110.html Still curious on whether there have been incompatabilities raised about this, especially with FB2 users (since I don't own a 2600 myself, only a hacked FB2 Rev. B)

That's a neat way to do it! Unfortunately, it's rather jarring on the emulator (how does it look on a TV?). Instead, I might consider: Every frame switch what group of 4 pieces is drawn first. E.g. if I was doing two rooks side-by-side: Frame 1: . . . . . . | X . X . X . X . X . X . | . . . . . . . . . . . . | X X X X X . X X X X X . | . . . . . . . . . . . . | X X X X X . X X X X X . | . . . . . . Frame 2: X . X . X . | . . . . . . . . . . . . | X . X . X . X X X X X . | . . . . . . . . . . . . | X X X X X . X X X X X . | . . . . . . . . . . . . | X X X X X . It leads to a 30hz 'flicker', but is probably less flickery than doing 'whole piece on/off at once' - I'm simply swapping the blinds back and forth very quickly. This might be the best way for me to do it. I am still curious about interlacing though as I'd rather use that I think. The alternative (using the Video Chess method on the big board) takes some mid-scanline HMOVE use to offset sprites twice as far, and I know this is not entirely portable to 2600jrs. I am looking for maximum compatibility on actual 2600s first of all.

I've decided to go with 8-bit sprites, 4 per line, using the Venetian Blinds technique like in Video Chess. It still looks good on the larger board (just tried it). Now I'd like to ask more questions about interlacing. I think I can use it to not only simplify my kernel, but also to make my blinds twice as fine for an improved appearance. Here's my understanding of how to make it happen: * Every even-numbered frame, draw 262 scanlines. Then waste half (38 cycles) of scanline 263, and then enter VBLANK/VSYNC. Start the kernel from here. * Every odd-numbered frame, enter VBLANK/VSYNC immediately following scanline 262. 1) How is Stella's handling of interlaced games? 2) Are there interlaced games I can look at for examples on how to achieve the effect? 3) What about doing the same for PAL? I want my BW/Color switch to swap between NTSC and PAL. 4) What does it look like on a real TV? 5) Any idea if it works on the Flashback 2? 6) Are there ANY compatibility issues with interlacing? I don't want to do it if it's not going to work for some people.

I don't know what I was thinking earlier - of course interlacing won't help me avoid the gaps! The only thing I guess I could do with that is get essentially double the vertical resolution - making the blinds half as wide (twice as many per piece) and so the effect would appear less drastic. I will probably still use it since it doesn't seem like it would add too much to the complexity of my code. Thanks for the tips though. Do you think using GRP0 for left-half and GRP1 for right-half of sprites I can put enough pieces on screen using Venetian Blinds? I'll play with it some more tomorrow and see what I can come up with. Unfortunately I am thinking this would be impossible since that would be 8 sprites/line which Video Chess didn't manage, but the gaps between pieces are larger so maybe enough time is available for sprite setup?

I'm working on a board game that is played on a checkerboard-patterned board. I've drawn the board so far using reflected PF1/2 and the ball (although there's an extra half-square every other line - should not be tough to fix.) I've seen Video Chess and its Venetian Blinds technique, and I am honestly not impressed : ) Attached is the Big Board I did. Ignore the extra-long bottom squares: they're an artifact of the Color/BW switch to change between NTSC and PAL. Now I need a way to put sprites (pieces) on it. I've designed some 8-bit sprites and set NUSIZ0/1 to draw double-wide sprites, hoping to fill the board with some big objects. I'm looking at a couple of ways to do it. Here are my 2 questions so far: 1) Interlacing. Are there any known problems with interlacing (turn on VSYNC midway through scanline 253 on every other frame) that I should be aware of? I am hoping to use this to let me do a similar technique as Venetian Blinds, drawing only half the pieces every field, to give the final illusion that all the pieces are being drawn without gaps. Make sense? 2) Multiple sprites on one line: Can it be done no-flicker with double-wide sprites? GRP0/1 WILL need to be updated mid-line (multiple types of pieces). Some pieces are red and others are blue. If interlacing works or I go with Venetian Blinds I need 4 sprites per line, but otherwise it would be up to 8. Check the size of the squares below and maybe that will help you determine if I can fit the code in. I'm somewhat worried that I need NUSIZ0/1 to be set for copies and can't do double-wide in order to do multi-sprite, but I am also thinking I can cheat by doing the left half of each piece with GRP0 and right-half with GRP1. Any pointers on where I should look for this info? My brain's working a little slow right now so pardon my wording of the questions.

I'm developing a kernel for my game which is going to have the following stuff on screen at all times. These objects can be independently positioned anywhere, and I want to use the hardware collision detection as well. The on-screen items are: A single Player0 sprite A single Player1 sprite A single ball A single Missile0 sprite A single Missile1 sprite A symmetrical playfield, which needs to change every N lines A status bar at the top or bottom displaying numeric information. (I think I can figure this out on my own though) Now my questions: * Can I cram all this into a 1-line kernel or do I need a 2-line? I may go with the 2-line anyway just because I don't need the vertical resolution of a 1-line kernel. Note that I'm _not_ okay with visual artifacts like cracks in the playfield, black bars on the left side of the screen, flickering, etc. * Where can I see samples of a 2-line kernel with these items? I don't need anything fancy like multiple sprites, wide sprites, etc. In fact any 2-line kernel source I can look at would probably help me out a ton. I've been looking for some time and I still don't quite get the hang of the main kernel loop. I think I can write the rest of my game logic no problem if I can just figure out how to get this stuff on screen. I wrote a mockup in bAtari Basic but the produced ASM is really tough to wade through.

http://www.classicgaming.com/vcsp/Step%20b...p%20Hacking.htm Scroll down to the bottom of Step 4. There's a nice pen-on-napkin schematic for how to wire up your paddle. You'll need a 1 Megaohm potentiometer and a .068 uF capacitor (actually, I think the capacitor is already in the system and you just need the potentiometer hooked up.)

I've got four auctions of vintage computing equipment going on right now on eBay. The main component of each is working but the hardware is so old I haven't been able to test the software. Here they are: Atari 800xl lot 1050 drives x2 cables Writer Graphix AT * Atari 800xl, two 1050 drives (one working one not), AtariWriter cartridge, Graphix AT printer connector, and a handful of software on disk (may or may not work) Lot of 11 Atari 8-bit Computer Books BASIC DOS 400 800 * Eleven books on BASIC and other manuals based around the Atari 8-bit line. Amiga 1000 A1000 Computer Lot + Drive Cables Games NR!! * Amiga A1000 computer, external disk drive, joystick, mouse, and some software on disk (may or may not work...). Plus the box and some manuals. AMIGA 1080 monitor RGB 13", cord/manual WORKS GREAT! NR * Just what it says - an Amiga 1080 monitor plus cords and manual.

Why not? PC-based emulators do it all the time. There are careful synchronization issues to be worked out to ensure the same presses hit each machine at the same time, and clearly it's not a perfect solution (think about random number generation, where each console starts with a different seed - this is impossible to sync). But that doesn't mean it's not workable. So just put a set of flip-flops driving the inputs on your PC-to-Atari board, and let the PC parallel port program them with new button press info when updates need to happen. That way the correct data is waiting when the Atari comes to read. Or are you referring to the original "joystick ports as null-modem" post? I probably should've started a new thread.

Anyone? ...Curt?

Definitely check local Target stores. Our local Target has two FB2 consoles on the shelf, $29.99 each.

Pac-Man Vs. for Nintendo Gamecube. One player plays as Pac-man on a connected Gameboy Advance, while the other three use controllers and play as the ghosts (who get a limited view of the playfield around them). If Pac-man eats the fruit he gets to move much faster. Whichever ghost gets Pac-man swaps the GBA with him and tries to complete the round. Whoever gets the most points wins. It's fun for a while, but the ghosts are at a huge disadvantage since Pac-man can see the whole level and the ghosts just wander around aimlessly hoping they can find him. This game came out as a free promo along with Pac-man World 2 (I think). I imagine most people probably had more fun with this tie-in than with the regular game!

I'd rather mod the FB2 if possible, since I think video signal is already degraded when converting internally from S-Video to composite. (Many devices have separate choma/luminance on board and then mix them into the composite signal later). I haven't gotten a chance to look at the innards of my FB2 yet, but if anyone has taken a good peek at the board, I have a good idea of what we're trying to do. Take a look at this page (about adding S-Video to the C64DTV): http://galaxy22.dyndns.org/dtv/common/svideo/index.html So if the FB2 really mixes those two signals together, we can separate them before it happens. Anyone who's opened your FB2 up, can you tell if there is a capacitor merging two signals together? Or does the chip output already-mixed composite signal?

I'm buying a new TV with an S-Video input and I'm wondering if it's possible to mod the FB2 to output Y/C signals. There's really nothing quite like extra-crisp giant pixels, and I'm looking for new cables for all my systems (or soldering new cables for the ones that aren't available already!).