Cybearg

I've been wanting to try my AtariVox's voice synthesis capabilities, but, needless to say, testing output by emulating through a Harmony for each attempt is very time-consuming. It would be great if I had a way to plug my AtariVox into my computer. Are there any plans to create an AtariVox-to-USB adapter that I could use to quickly access the AtariVox through Stella?

This was before everyday home electronics were powerful enough to require fans for cooling.

Are the tiles all essentially playfield pixels with pixels only every other line? Or can a series of tiles be specified so that different tiles exist within the 8x8 pixels of each tile? I know that ASDK only allows for 2 sprites at a time, which could be fine for what I had in mind (Princess Rescue managed with just 2), but it would largely depend on whether those tiles can look like anything besides blocks and whether colors can vary between them (at least on vertical tile lines) or whether colors affect all of the background/foreground together. I wasn't quite clear on the ASDK page which was the latest, fully-functional version of ASDK. Or has it not been significantly changed since October/November '13? Also, is there a way to read the tile map entirely from ROM, freeing up all that RAM for other things?

Essentially, I'd like a kernel for the '2600 that I can adapt for vBb in order to make a game with tiles, such as for a top-down adventure game. I've heard that this has been done by others. Can anyone point me to an available kernel? Are there any special tricks necessary for this in hardware? I'm content using data sets rather than holding the entire tile set in memory, to save space. From what I understand, there's not enough clock-time to address a sprite and place it for drawing as a tile while racing the beam, so there's got to be some other wizardry that is far beyond me going on. Anyone have any leads, please?

Hitting reset + select will return you to the main menu.

Thanks for the support, people! I can't promise a cart release, though. It realistically probably won't happen. By the way, for those with an Android mobile device who wanted to play Heartbreak, I recently recreated it in Gamemaker as part of a mini-Ludum Dare. You can get the .apk here.

Well, it's true. As I said, it MAY be possible with a custom kernel, but it would not be easy. It would take an Assembly programmer who knew how to squeeze every drop out to make it happen, at least from my half-way understanding. Unfortunately, I am not that programmer, so Fix-It Felix is going to have to be as is unless someone with the time and experience steps up as willing to create a custom kernel to handle all that extra stuff.

That's fantastic to hear, thank you! Flipside's multiplayer was very uncertain for me because neither myself nor any of the testers were able to actually test it out in multiplayer mode, beyond me trying to get my parents to give it a shot with me (and they were just baffled by the Atari controller, haha). If you notice any problems or areas for improvement, please let me know! That's a good idea, but it's entirely possible that all 9 windows could be broken, and there are only 2 missiles and 1 ball at my disposal. Also, they are being used for other things. The bricks that fall when Ralph beats the roof are the missiles, and that happens frequently enough that they would be falling (and thus, not indicating broken windows) almost as often as they were in place on the windows. As for the ball, that's used as the "pie," which randomly appears in a window to give you bonus points and an extra life. Even if I had the missiles and ball at my disposal and they weren't occupied doing other things in the game, the fact that I can only show 3 at a time out of potentially 9 broken windows makes me worry that it would be more confusing than helpful on account of being inconsistent. I'm not sure how I would even be able to display the broken-ness of those windows with just the three objects. Furthermore, in the multisprite kernel, the ball and missiles are capped at 1 pixel tall, which works fine in the context that I use them, but that means that I couldn't create vertical "cracks" in the windows--either just a dot (which would look more like a power-up than a crack) or a horizontal line (which, personally, I wouldn't recognize as being a crack from seeing a short, fat horizontal line in a window). As I said, there ~is a way to check if windows are broken without being in front of them. The indicator in the lower left shows you which windows are broken on the row you're standing on. It's far from perfect, but it at least allows one to get an idea of how many windows are broken and which column they are in.

Yes, you would think so, and I dearly wish this was the case, but it leaves me with a difficult trade-off that I see no way around: I'm not using the standard kernel. I'm using the multisprite kernel, which not only has a mirrored playfield (so I couldn't show a broken window on just one side without implying it's on the other side of the building as well), but there is also no way to write directly to the playfield (you can only load in pre-set playfields from the ROM, but they can't be modified after that). Now, theoretically, the game could be remade in the standard kernel, but there are a few complications: For one, the sprite for Ralph is actually two sprites wide, and that would be impossible, so he'd have to be lower-res and stretched out to fit the space, which probably wouldn't look as good. Another issue is that there would be less variation in difficulty. Currently, there are ducks that fly back and forth on each row, adding some additional challenge. That is only possible because of the multisprite kernel's 6 sprite limit, while I would have only 2 sprites available at a time in the standard kernel, meaning those ducks would have to be cut. So it would then only be a game about dodging falling bricks, with not much more to increase the difficulty. Finally, even if I was able to fill in the windows, they wouldn't be able to be filled in with any color besides the background or foreground colors, So if a window was fixed, it would be filled in, making it difficult to tell that there is a window there at all. I worried that this would make navigation difficult, because you couldn't tell where you would snap to when you moved your character. So, to summarize, in order to make those windows fill in like that, I would need to simplify the gameplay, simplify the sprites, and possibly make the play area difficult to navigate. I felt that my alternative--using a little indicator--while not as elegant and possibly a bit confusing initially, was a reasonable sacrifice for all the benefits that come from using with the multisprite kernel. For reference, the indicator in the lower-left displays the row you're currently standing on, with three blocks on either side of a gap (the gap being analogous to the gap between the two columns of windows on the playfield) to denote the status of the row's windows. If a window is broken, one of those blocks will be blank, showing you that the row isn't fully filled in. It's true, you can't see which windows are broken everywhere at a glance, but you can check the status of the rows fairly quickly by moving up or down. There is probably a more elegant solution that could be coded with raw Assembly, if the game was re-made from scratch without using batariBasic, but I do not know how to do it. If there is a talented Assembly programmer who is willing to work with me, I'd be fine remaking the game for the compilation if they were able to build me a custom kernel that could do everything I need (namely, change the background's color mid-scanline before each window is rendered while displaying 6 sprites on-screen without flicker). In lieu of that, however, I think we'll have to stick with the window indicator.

Thank you, and yes, but at present he is busy filling other orders. I need a label artist before I can make any more progress toward a cartridge release. In the meanwhile, consider this thread a "release candidate testing phase," so if anyone notices anything that seems off, and especially any blatant bugs, please let me know so a cart release can be as polished as possible.

No, I understand all that. I'm asking, what happens behind-the-scenes? This all came from me asking my C++ professor if I could define a static data set that didn't use memory, like these Assembly data sets do. You can move through the data like an array, but it doesn't actually put all those bytes into a memory array, so it saves a lot of RAM. He seemed insistent that it's impossible to read data without loading it into memory, unless there was some kind of super-specialized, rare hardware in the CPU. So I'm asking--how does it read the data without loading the full array into memory, and is there some simple equivalent in C that doesn't actually use RAM but merely increases the program's size, like how adding a data array uses up ROM instead of RAM?

It was batariBasic. You can tell by the way the score looks.

I'm not sure I truly understand the fight scenes, but I assume it's some kind of quick-time sequence, where you have to press fire when the prompt comes on-screen, correct? And, out of curiosity, what is the deal with the girl's tummy when you enter the club? It always looked to me like going up stairs or something, but I don't follow why there's the close-up on the woman's belly.

This isn't really a programming question per se, but more of a conceptual thing. When I do something like this: LDX index LDA DataSet,x ... DataSet .byte 128 .byte 64 .byte 32 .byte 16 .byte 8 .byte 4 ... What exactly is going on, technically? Is the program saving the current location of the program's execution in the stack, then jumping to DataSet, incrementing by index bytes, reading a single byte, and returning to the location pushed to the stack? Is there any modern equivalent of this in, say, C? Normally in C, you have to specify actual memory to be used to hold an array, but is there any way to do a "hard array" like you can do with the 6502 in Assembly (or batariBasic)?

This looks like the best adult game that the 2600 has ever seen. Seriously, your art skills are jaw-dropping. Very clever use of limited assets to do what you're doing. Astonishing, especially for a beginner!

The ! not is useful for any command, but in the case of joy0fire, it is checking for whether a bit is zero or one. In non-bitwise cases, ! means "is zero" and without the exclamation means "is not zero." For instance: if variable = 0 then... Could be written as: if !variable then... Likewise, this: if variable > 0 then... can be written as: if variable then... This is necessary for bitwise operations (when you're checking individual bits to see if they're on or off), but it's also a more code-efficient way to check a variable's zero/not-zero status and I believe it can be used in expressions as well, such as: if !(variable > 5) then... ... though sometimes that may lead to compilation problems, so it's always best to use the most straightforward logic necessary to do things. in this case, !(variable > 5) would be more easily written as variable <= 5 In bit operations, like with the joy0fire thing, the bit can only be true or false, hence the "joy0fire" for true and the "!joy0fire" for false. The code is actually checking a single bit in a byte that it receives from the controller. There are, likewise, bits for up, down, left, right, select, reset, color/BW, left difficulty, and right difficulty, plus up/down/left/right/fire for joystick 1, all of which can be programmed to do whatever you like. If you really wanted, you could have your game controlled by the reset/select/difficulty switches and have both joysticks do absolutely nothing. The only switch on the 2600 you have no control over is the power switch. And for reference, a "not equals to" sign would be: if variable <> 5 then... ... As opposed to the C-style !=, which doesn't work in BASIC.

And to answer your earlier question, you can have up to 64k on a ROM if you use the standard or multisprite kernels. 32k if you use DPC+.

The 2600 can only access 4k of ROM at a time. Bankswitching basically starts you in one bank, then yanks it away and puts in another 4k bank, so the 2600 keeps working as if it was been reading from that second 4k ROM the whole time. In this way, you can make large games by switching from one 4k bank to the next. It all depends on how big your game is.

I just added version 1.0.5 in the first post. As well as having larger pick-ups, as nanochess suggested, I also found and fixed a bug where Flipside would overwrite its high score on every AtariVox save, regardless on whether the new score was higher or lower than the standing high score. There are a few other changes as well: Added more backgrounds to Joyride, which are randomly selected for a bit of variety. Added the ability for playfields to be mirrored in Ping, so maybe there will be a bit more variety in the stages now. Also, after every few stages, you come to the exit of the cave you were flying through. Leaving through it gives you a little bonus before moving on to the next cave. Rewrote Heartbreak from the ground up to be more efficient and improved the increasing ball speed that hard mode has. Also, easy mode gives you fewer bonus points, but the ball doesn't speed up over time and the punishment for losing your ball into the black isn't as harsh. Added a PAL60 version of the compilation. Let me know if anyone comes across any more issues!

Ah, yes. That's basically what I did, though I didn't think to re-define it as its own name. That's the auto-generated code that bB spits out, yeah.

Alright, I found a way around this problem. Unfortunately, it seems that a lot of direct uses of the included constants don't work. I'm not sure what the pattern is, but something causes things like colorvar = COL_44: COLUP0 = colorvar to, more often than not, result in an incorrect color. I've managed to reliably fix this by assigning the included constant to another, in-code constant, then using THAT, like so: const RED = COL_44 colorvar = ReD: COLUP0 = colorvar This seems to work every time. Using the included constants in data sets/arrays has never caused any problems for me yet, so that's fine: data colorlist COL_44, COL_54, COL_64 end player1colors: COL_44 COL_54 COL_64 end ... etc. This all works fine.

Just wanted to say, that sprite looks great! Not sure how you managed it, unless you have the player1 and player0 sprites on top of one another to create the black outline. Still, really good use of the layered colors. To make missiles wider, you'll need to use NUSIZ0 and NUSIZ1 to set up those parameters. Make sure that they are within your main game loop, as they get lost every drawscreen. You can have up to an 8 pixel wide missile.

Hm... It seems to have some problems sometimes. For instance, this works: temp6 = (counter & 7) * 2 if !scoreshow then scorecolor = COL_40 + temp6 else scorecolor = COL_90 + temp6 ... But this transforms the colors into 4 and 0 (decimal), respectively: if !scoreshow then scorecolor = COL_44: sc1 = p0sc1: sc2 = p0sc2: sc3 = p0sc3 else scorecolor = COL_9C: sc1 = p1sc1: sc2 = p1sc2: sc3 = p1sc3 For whatever reason, it's misreading COL_44 and COL_9C. Same if I change them to, say, COL_40 and COL_90, but they DO work if I just put $44 and $9C. Any idea what's wrong, there? .L0196 ; if !scoreshow then scorecolor = COL_44 : sc1 = p0sc1 : sc2 = p0sc2 : sc3 = p0sc3 else scorecolor = COL_9C : sc1 = p1sc1 : sc2 = p1sc2 : sc3 = p1sc3 LDA keepbits AND #8 BNE .skipL0196 .condpart76 LDA COL_44 STA scorecolor LDA p0sc1 STA sc1 LDA p0sc2 STA sc2 LDA p0sc3 STA sc3 jmp .skipelse10 .skipL0196 LDA COL_9C STA scorecolor LDA p1sc1 STA sc1 LDA p1sc2 STA sc2 LDA p1sc3 STA sc3 .skipelse10

I didn't really get it figured out, but I worked around it when I realized how the decimal place was handled. I was expecting it to be a 0-100 decimal place kind of thing, but it's fractions of 256, so 0.5 is 00 on var 1 and 128 on var 2. Pretty obvious, in hindsight. Loon, up to now, I've used counters to time things. For instance: if !(counter & 3) then player1x = player1x + 1 It's worked alright, but I wanted to be able to incrementally increase the velocity, which that movement-skipping method can't do so easily, even if the results are essentially the same.

Currently, this doesn't work: const START_VELOCITY = 0.5 _velocity = START_VELOCITY [code] Is there a way to make floating numbers work with constants or perhaps to "fake it" by just setting the decimal-place variable to a constant? The problem with the latter is that it doesn't seem to be clear-cut as to what real number is interpreted as what in decimal places. For instance, .3 looks like $4C or 76 in decimal, so I can't say I see the connection.