boutell

Just bought a Supercharger on eBay. There have been many different stories about what does and doesn't work, how easy it is to work with as a development tool, etc. So I'll just mention my outcome: 100% positive. It works fine straight off my laptop's audio output jack, I didn't need any adapters. wplaybin works great (even in XP) and even 4K ROMs cross the wire in just a few seconds (I know, it's funny to be bragging about how fast we can more 4K in 2007, but the point is it works). I sometimes have to hit play more than once but it's never a real problem. I gather there are some memory addresses that you can't touch in an unmodified supercharger or something, which might be why I experienced a crash while playing a recently posted 4K Pac-Man demo, but it hasn't been an issue for my own development so far. Testing on the real thing has been vital - kernels that have a solid display on stella roll like crazy on the real hardware. But the stella debugger (hit the backtick key and be amazed) has been enormously helpful in fixing same - it's great at displaying how many scanlines are in a frame!

Congratulations! You have successfully implemented the most frequently-suggested, never-actually-done Atari 2600 thing ever. (: (Um... this is a sincere compliment, in case that's kinda hard to infer! It's a major accomplishment.)

Sure, I've seen a lot of this. Unfortunately I can't completely imprison anything to a particular scanline, it really wouldn't work for the game I have in mind (although I'll try to question that assumption some more). But I can at least impose some limitations that will allow me to do something *like* that but have some vertical liberty in some situations that will add much more verisimilitude.

I found some Kroko Cart info. Looks like there is an... impressive backlog of orders. (: I'm thinking I'll push to get the game working very well indeed and possibly beg a few test runs by owners of such hardware before forking over $100+, though I'd love to!

This is very helpful, thank you. Although the shield in Yar's is made of big pixels, it sure does look like it's flickering at 30hz. I'm guessing it alternates with the mystery zone in the middle. I need to nail down a real 2600 (all I have in the house at the moment is a Flashback II - hey, it was a gift, at least it's an emulation of the original machine, unlike the awful Flashback I)... and I need a way to load games to it, yes. My understanding is that the old-school supercharger is an ebay item, the cuttle cart is sold out forever, and the krokocart... I'd never heard of that before and it's very interesting. But I haven't found a home page for it, just some tantalizing references. Got more information? My game ideally calls for ten fully independent player sprites. Har har har. In the real world, what I have so far is: 1. A set of three sprites which are independent except that they can't share scanlines (that works for my purposes). 2. A set of three additional sprites which are "slaved" to the first three in that they must share Y coordinates with the first three - but their X coordinates are independent. 3. Two "extra" sprites that are faked with NUSIZ0 but don't have any independent behavior. That's a viable compromise for me too. 4. The hard part: two truly independent sprites above and beyond all that. This is where I punted and went to 30hz flicker - the independent sprites are P0 and P1 of the second 30hz "phase," the other sprites are displayed in the first 30hz "phase." Unfortunately missile or ball graphics wouldn't cut it for my purposes. What I have now works, but I'm thinking I need to do some optimization of flicker to better justify using 30hz when it is truly needed. There are two independent sprites which could conceivably overlap the other sprite types, and that is the only time 30hz is needed. I'm pretty sure there are a maximum of five changes between the flickering and nonflickering behavior. So with subkernels... I'm probably going into too much detail here, but yeah, I've got ideas. (: Thanks again!

Wow! Thank you so much. Looks like you nailed it with... three cycles to spare, in the worst case! I think I can actually use this, too. I understand your logic, it's not too bizarre. (; By switching to player counters you avoided some extra math that's in my version and won back the cycles to squeeze in COLUP0 and COLUP1 at exactly the right moments without an explicit STA WSYNC. Since posting this I've done a "multiple sprites as long as they aren't on the same scanline" demo, though it's not as tight as it could be. I thought that was cool until I looked at Activision Freeway and realized they managed to put three completely independent player graphics on a scanline with no flicker whatsoever. Ahrgh! I'm pretty sure they are only able to do it because the two "bird" sprites have no freedom of motion on the X axis - they must be retriggering P0 (or P1) at a fixed point in the scanline kernel after loading a new graphic to account for differences in vertical positioning. Wow.

Can anyone point to some clear examples of games that use 30hz flicker extensively? As opposed to the vastly worse 20hz or 15hz? I'm trying to get a handle on how appalling 30hz really is. In Stella it's either OMG TOTALLY APPALLING (without phosphor mode) or totally fine (in phosphor mode). While Pac-Man and Football still look awful even in phosphor mode (because they are 15hz games). I'm trying to get a sense of what 30hz is like on an actual TV. I'm thinking it may be acceptable to use 30hz, especially if I avoid it for those segments of the screen in which I don't currently have three independently positioned objects to worry about. Opinions on that are welcome. Thanks!

I've attached a simple demo which displays two single-height sprites simultaneously. They overlap for part of their vertical extent, and they change color on every scanline. The bitmap and the colors are both loaded from tables, so you could substitute any sprite and one-color-per-scanline colormap. Maybe this will be helpful to someone else. Here are my questions about the results the demo is producing: Why don't the playfield bars at left and right appear normally? They vanish after their first scanline. Is there a way to keep the lower of the two sprites from shifting colors around as it moves between the rightmost edge and about 20% of the way into the screen? There is no VDEL mechanism for player colors. I'm trying to simulate it with a shadow register but I don't have enough cycles after WSYNC to do it there, so I do it shortly before. Any suggestions on winning back some cycles here? In the vertically overlapping case, I'm using every single scanline cycle right now. Thanks! P.S. Thanks to all who responded to my previous question, the impact of that advice should be obvious from the fact that I have two full-vertical-resolution sprites in this demo. (; demo1.zip

Despite the name, VDEL does not limit you to double-height sprites. Many games with single-height sprites use VDEL a lot. ... Because you can write to PF0 at a "bad" time and get that magically copied to the real PF0 when you write to PF1, which you cleverly do at a "good" time. ... Right? My early results there are encouraging though my code is definitely still sloppy. Thanks for the hint!

This is impressive but I sure don't understand it yet. (: How should the player counters be initialized? To the starting scanline of the player in question? And in the spirit of actually understanding rather than blindly using stuff: You load the accumulator, you use dcp which decrements a memory location without borrow (no impact on A that I can see), you branch if carry is set, if not you load zero into the accumulator. Then waht did the first load of the accumulator accomplish? And what does .byte $2C (BIT ABS?) do? I can't find an intelligible explanation of that one. Thanks!

Shouldn't it at least have WSYNC somewhere? Well, in theory the desired effect is pretty simple to achieve: ; Loop overhead ; Do whatever RhabarberDraw Technique you want to get shape 1 into X ; Do whatever RhabarberDraw Technique you want to get shape 2 into A STA WSYNC STX GRP0 STA GRP1 ; Loop underhead Voilà, both sprites set in only 6 cycles of HBLANK I always work like that or similar, I believe outside some sixchar techniques almost non of my code uses VDEL. This tactic actually works very well for me. A variation on it is doing the job nicely. Is it also practical to change the player colors on each scanline? Or is that unrealistic given the time constraints we're under? I've tried alternating bitmap bytes with color bytes, placing the color bytes in a second table after the bitmap table, etc., but any way I slice it I wind up taking too long and consuming a second scanline. I've been looking at Super Football and thinking "I should be able to match that!" but apparently that game uses the 6-digit score technique which is an entirely different kettle of fish and probably won't suit my plans.

With VDEL, I can only have double-height sprites. And late-era 2600 games in the same genre - Super Football, to be specific - manage not only single-height sprites, but single-height sprites that change color on every scanline! So I'm trying real hard here not to write a game that looks like Gunslinger. Super Football manages a LOT of impressive stuff.

All bB kernels use VDEL and double-height sprites The VDEL is done not because of the 2-line kernel but because writes for one player and the ball would otherwise occur during the visible screen, which IMO is the most useful aspect of VDEL. Thanks for answering that one. My planned game doesn't need a ball, and it looks like I can avoid VDEL in that situation and have full-res sprites. Yay!

Shouldn't it at least have WSYNC somewhere? Well, in theory the desired effect is pretty simple to achieve: ; Loop overhead ; Do whatever RhabarberDraw Technique you want to get shape 1 into X ; Do whatever RhabarberDraw Technique you want to get shape 2 into A STA WSYNC STX GRP0 STA GRP1 ; Loop underhead Voilà, both sprites set in only 6 cycles of HBLANK I always work like that or similar, I believe outside some sixchar techniques almost non of my code uses VDEL. Interesting - but what is the RhabarberDraw technique? Thanks! Edit: oh. Rhabarber = rhubarb = joke. Gotcha.

Is it practical to have two nonflickering, freely moving, single-height player sprites without using VDEL? My vertical positioning code takes 20-ish cycles to handle just one sprite, and that's about all the horizontal blank time there is to play with. But I get the impression there are games out there that have this problem licked, as long as I don't make other demands as well (playfield changes, etc). Any code out there that demonstrates how to nail this? I need to be able to move the sprites arbitrarily, so a trick kernel that works only when the players are on the same horizontal line (for instance) won't do the job for me. Does the Batari BASIC kernel do this somehow (I'm coding in assembly)? Or does it use VDEL and double-height sprites? Thanks for any information! (2600 development looks quiet since 2007 began...)