potatohead
-
Content Count
4,794 -
Joined
-
Last visited
-
Days Won
16
Posts posted by potatohead
-
-
Good Job Jess!
-
-
Same here. For what it's worth, I think I'll buy two of the first batch. Pester, pester, pester....
-
-
-
The Genesis game Warpspeed had some similarities to Star Raiders.
But it does strike me as odd that there have been no remakes for SR, especially considering it was probably one of the most famous computer games of the early 80s, and one of the very, very few to make the transition to consoles (2600 and 5200). It was in the top ten list for years and years.
Also strange to me is that Atari never ported it to any other system back then as an Atarisoft title either....
There was a rumor that Atari was working on a remake for the Jaguar but it turned out to be Space War 2000.
Battlesphere's Alone vs. the Empire mode is very similar to Star Raiders.
What makes SR is the random element. Modern games of the same genre (think Wing Commander, X-Wing, and so on) are mission-based. Events are mostly deterministic. So replay value isn't there. It's just a matter of figuring out the right strategy to beat a particular scripted mission. The gameplay experience of Star Raiders is different every time you play it.
I think InfoTari should remake it, but it's hard to preserve the gameplay when adding in multiplayer, and with a genre like this, people are going to pretty much expect multiplayer.
Interesting... I've always thought this game could be multi-player. The sticky part is syncing everybody up for a mission. Queue, say 4 players, then everybody starts with a common map and common goal, defeat the baddies. Players would be able to communicate with their sub-space radios, provided they are not damaged in combat of course. Maybe heavy damage sets off the homing beacon! Allow players to trade resources to help one another. One perfectly healthy player can give up their radio in trade for another players engine fix, for example. Then the two have to make it to a mothership.
Over the network this would be cool. The number of baddies could scale according to the players in the mission.
Everybody only gets one shot. No re-spawns. This would reinforce cooperation in the game.
If you were talking about single screen versions, I agree multi-player isn't going to work well as the split screen would not be immersive as it is for just one person.
-
My fave is the 8bit version though analog control would be nice.
As kids, we would play it two player. One person running the joystick and the other running the keyboard. Getting the higher scores was easier because of the faster control possible. Plus it's a fairly unique collaborative experience. My kids will do this today when I drag out the machine. Good games are always good games.
-
Re: Cheats, none of these ideas are going to make one bit of difference. The high scores are an honor system thing. Nothing short of a real video capture is going to erase doubt --and even then there is doubt. Maybe scanned photos?
As for disabling the print screen, use VNC to remote the computer desktop --done.
Pausing? Run the whole works in a virtual machine --done.
All kinds of fun can be had with patch roms too.
I suppose one could get nasty and try the video overlay bit --like for DVD's. That's a lot of extra code that is rendered moot with a hacked or friendly driver.
There is some little evil workaround for all of the cheat protects, why bother? Either there is some honor in the high score or their isn't.
-
Just had a chance to check this out.
Pretty damn cool if you ask me. Bb continues to stretch it's legs!
-
All this hardware talk is pretty interesting! Looks like good times ahead.
-
I really like the idea of pages being controlled by ram accesses. Unless it ends up be seriously broken somehow, keep this feature please.
The more I read about this cart, the more I want to get my hands on one!
-
I have now gotten my 4A50 Supercart working on the 2600jr, a Heavy Sixer, and the 7800. Unfortunately, compatibility with the latter required a design concession I'm not too happy about.In particular, the cartridge allows reading address $7E to get the bottom six bits of the current page setting for the upper memory bank. Since writing $7E sets those bits, this allows a program to use "INC $7E" to go from page to page without having to know what page it's on.
Unfortunately, the 7800 boot code access accesses xxxx 0000 0111 111x and gets unhappy if I output anything on the bus then.
Is there any safe way to resolve this other than by simply never outputting anything on the bus when A12 is low [and thus not providing a bank-readback feature]?
Wait a while before allowing this? Allow the programmer to toggle the feature, once it's known safe?
-
Got the CD too. #96!
Nice topic. I've wondered about this too.
-
I've changed my mind about it. Basically, I now think a "post-processor" is the best way to do it.Agreed. Your solution is pretty slick.
but I'm thinking in terms of subroutines that call other subroutines, and the fact that subs can be nested only three at a time in bB, so using PHA like that boils down to having no more than two nested subs. That could just be part of the "rules and regulations" about how things must be done, but it would also be nice if there were a solution around the indirect JMP bug that doesn't involve using the stack any more than necessary.
Having subs only two levels deep is not that big of a deal, though it might be given the larger projects the additional RAM and ROM make possible. Still, ease and reliablity in page management is king.
Using flags to handle game states is not too bad. Gets messy quick if one does not document things. When I wrote Ooze the second time, using mostly flags because of the gosub bug, I learned a few things.
Multi-purpose subroutines are expensive in terms of space. This is the downside to flags. More stack capability would have allowed slower, but far tighter program loops. I don't think time would have been an issue though. It turns out that one can do a lot of little branches cheap. IMHO, it all comes down to program space. If space is tight, the stack really helps you out because you get the most for the address space. If space is not really the issue, the limited gosub is less of a problem because it then becomes possible to manage things on your own with few worries, other than keeping it right.
I'm sort of a stack snob really. Miss it on the 6502 because it's so limited in the first place. A one page stack really sort of sucks because it's only good for subs and variable passing. Anything beyond that gets risky quick, compared to a real stack. Programming on the CoCo, with the 6809 and it's two very nice stacks was sweet.
IMHO, the stack needs to be used sparingly on 6502 systems no matter what. There just is not enough of it. Far better to gain address space and use a pointer. That's just the way the CPU is.
The 6502 is fast but quirky it seems. This forces some style choices. Largely ignoring the stack, but for times when it really, really matters, is one of them.
Of course, there is the issue of normal RAM writes with supercats scheme. If we see working carts, Bb could then use the additional on cart RAM for storage, thus freeing up a lot of stack!
I haven't looked at all the schemes, but the ones I did check out, made RAM writes some sort of hack. Funky addressing, counting cycles all makes the whole thing hard from a Bb perspective. Major changes would be required to get things working --if the RAM were to be used for variables & such. The user could always make a subroutine or function that handled these things.
-
Also, what would you guys say are the degrees of popularity of the bankswitching methods, as far as which ones homebrewers seem to prefer the most, and also which ones are easiest to produce carts for? I'll expand the bB bankswitch stuff to accommodate the other schemes besides M-Network, but it would be nice to know which ones to tackle first.Very cool! I'm actually interested in supercats scheme the most. I know we don't have hardware just yet, but when we do I think it's gonna be great. From a programming standpoint, it's got a lot to offer with the biggie being ordinary RAM writes. I'm thinking this will enable a fairly sane Bb / cart combination.
Since I'm new, and only using some assembly at the moment, I'm going to defer to others here as to which scheme is better, popular, etc...
Kind of looking forward to my next game after Ooze.
Thanks a bunch for heading this direction.
-
I would like to see an 8bitter with an added chip or feature set to allow for homebrew / new games. Whatever they do, it should have a cart port and said port should be open.
The homebrew scene is really good right now, but it really depends on old hardware. The FB2 brought a nice refresh, if a bit buggy, to the classic crowd and the price was good! $30 is a steal!
IMHO, this is all about the classic feel. The 2600 embodies that, but is a bit limited. My FB2 has seen a lot of play from the kids and a few interested adults. Well worth the dollars.
If the price were, say $50, but carts could be added and it brought a few extensions to the table, Atari may well find that they have opened a door long thought closed.
I think the whole thing depends on expectations set. The FB works because the old Atari is remembered and it has a feel that is unique. The games have a real time element because of how the games had to be written. Rather than escalate this by moving up the chain to full computer capability, (400 / 800 style) I would add a coupla features to the 2600 way of doing things that enable better games that preserve the overall feel.
IMHO, the 2600 defines classic. Go newer and the expectations quickly rise. Unless they are properly set, people won't get the same enjoyment out of the whole thing. Make the machine too good, and it then gets seen as modern and limited. Kind of like a game boy or NES that connects to the television. Maybe that's the way to go. I'm not sure, but it would not be the same and it gets a lot more expensive to produce. I would love such a system though as there are a ton of 8bit computer games that are very fun.
How to incorporate them is the problem. Cart only keeps a lot of games off the table. Save states & other such things become a part of the equation, which detract from the simple, turn it on, choose your game and have fun factor.
If it were me, I would keep the focus on 2600 style games. These games are simple, yet fun and can be rewarding.
I would add a feature or two to allow better productions to happen and contract out a coupla of the better developers here to showcase the new stuff.
-
Why not just define all the sprite pieces and use an on-goto to sort 'em out at run time?
Either way, the data sits in ROM, it's just how you address it.
eg:
player0:
%00100010
%01110111
%01111111
end
on bottomhalf goto 10 20 30
10 player1:
%00100010
%01110111
%01111111
end
goto skiphalf
20 player1:
%00100010
%01110111
%01111111
end
goto skiphalf
30 player1:
%00100010
%01110111
%01111111
end
skiphalf
(rest of game)
-
Because they can't be pushed in quite the same way. They are flexible, but not in the same fashion. Expectations are higher too. The computers are capable of some pretty nice visuals. Maybe I'm going out on a limb, but the limits of the 8bitters is known. We have not yet seen all the 2600 can do. I'm not saying it's more powerful, but it is way more flexible than any other classic system.
That flexibility really is the attractor for me anyway. Seeing the innovations year after year is just great. Look at the Boulderdash game posted here a while back. Holy cow! That's one powerful piece of programming. The end result would be trivial on the computers and that's what makes it so great to see on the 2600. There just is no environment like it.
-
There are a ton of working 2600 machines. Not so many 800's.
Personally I would like to see the 7800 get more attention than it does, but there is the same problem --lack of machines.
Re: Gameplay. Can totally relate to this. The simple nature of the 2600 makes for interesting games --there is a feel to a well done 2600 game that's just cool. Having to sync everything is a big part of that.
-
BLinkenlight? Yes. Somebody will use the darn light for something, just as they do everything else.
Cost -vs- functionality?
How much would a finished cart be?
Having read / writes work as they should is a big deal, if that is traded for cost, it's a mistake IMHO.
-
Can't you get this by just holding down reset while turning the machine on?
Of course, that brings me to another question:
Can this behavior be replicated in the emulators?
-
I've just drawn up a prelimiary specifiication for a new bank-switching method I call $4A50. With luck, carts which implement this specification should be manufacturable at reasonable cost. The design as quoted here should fit within a Xilinx 95C36 chip, though it will be tight. I welcome any comments or suggestions, though I don't know if I'll be able to fit in much beyond what I'm planning. To my knowledge, if this works, it will be the first cart ever to allow the use of all instructions and addressing modes to read and write RAM, even including the read-modify-write instructions.Very interesting. I love the hardware aspect of the 2600.
Any chance at allowing program execution from RAM (read / write)? I'm thinking of self-modifying code. I know it's supposed to be a no-no, but it had it's merits on the 8bitters. With all the room this scheme allows, self-modifying code would not be important for game logic stuff, but may well permit exotic kernels.
-
Sorry to ask, but can I get the source so that I can compile for Linux?
If it's messy or whatever, let me know and I'll run it in the win32 environment.
Nevermind... just understood what I was looking at!
Yeah, the "source" is actually just a lex grammar file...
Not long... I got a cup of coffee and started writing, and I was done before the coffee was cold (Though the last swig was a little tepid.) Probably less time and more accurate than doing Ooze by hand.
Well, that's exactly why I am not a programmer by trade. Takes too damn long! I bow before your Kung-Fu!
Feeling Ok this morning. I'll play a little and post what happens.
-
Ok, I'll take the hint! --Thanks. I'll give this a whack soon.
Kind of dismayed about the reduced avaliable space though. I believe the game was floating around ~200 bytes free. Oh well, the functions, improved bit ops and proper gosub should free most of that back.
Need to finish current work project first though. (money first, games second!)
The compiler compiled on Linux, so that's a good sign. Haven't tried the code converter yet, but will soon. The little scripts I wrote to compile things didn't bring me much joy using the included sample.bas file. Which shipped with some bad lines in it... were those for testing?
The new sample should compile as-is, the problem is there are more compile steps.
EDIT: I said "binary" when I meant "source"
In the source distribution, there is a shell script included that should do what you need, 2600basic.sh I think.
That did the trick. Ran the code converter. It made a coupla mistakes, but nothing major. Got some lines that looked like this p(s{3} = xx. Only two of them, easily fixed.
So it compiles, but is -89 bytes down from ~+154. Not too bad. I think the improved bit operators will help out quite a bit in this area as well as if-then-else will too. I missed those two the most, with a working gosub being a close third. The rest of 0.2 worked nicely for me, IMHO.
First things first though. I'll read the help and see what my options are and go from there.
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Solar Plexus officially released!
in Atari 2600
Posted
Yes! The game is solid, but needs one more round of spit 'n polish. I plan to get the release canidate up this weekend for more intense playtesting. Gotta sort out the level progression and overall difficulty issues.
Since this has come up, how does one start the process? I want to package Ooze, the source code and the development notes all together in the box, along with some introductory Batari Basic information links. The idea is to play the game, see how the game was made and hopefully encourage more people to write games!
Originally, I was going to ask these questions a coupla months ago, but decided to let the compo run it's course first. Partly for the comments and a reality check on the game itself, and partly because I didn't want to be seen as vote whoring.
Now that's it's all over, I'm eager to start getting a cart going.