2600 RPG - codename, "CiE"

[brpocock]

The number of active 2600 coders, using "active" loosely, is about 20-30.

 

The number of homebrew games you are likely to sell is around 100-200, assuming you even complete this.

 

Given those numbers, your concerns seem a bit...ridiculous.  You haven't used *any* code posted here, because of licensing concerns?

 

You're inventing problems that don't exist and then solving them with a sledgehammer.

1009580[/snapback]

 

This is what I do for a living, so worrying about licensing and milestones and build toolchains is par for the course. I'm just treating this like any other project. There's no real reason for me to treat this as a less significant project just because it's not going to be sold for mucho dinero. If anything, I'm being more careful with this project because it doesn't have a layer of corporate padding to check out all the licensing angles, and I'm in the USA where you're basically guilty until proven innocent if anyone decides to be a pain.

 

I doubt anyone here would, but better safe than sorry, eh?

 

But, seriously, the 2600 isn't so complex that one needs to copy others' code for e.g. initializing the machine states or enabling some fancy video overlay modes or ... And techniques aren't copyrighted. Hopefully nobody here was enough of an ass to go and try to patent the idea of e.g. redefining sprite data in between TIA updates or sommat.

 

The tile-based kernel code is just over 10k lines (including lots of comments) even after m4's done preprocessing it. Before m4 expansion it's under 1,000 lines still. Easier to reinvent the wheel on a small project like this.

[ZylonBane]

Just... wow. This guy is like a Dilbert character come to life.

[Shawn]

I pray to God this project goes all the way.

Yeah, screw all the starving and suffering people in the world. Pray to God for a videogame.

 

1009542[/snapback]

 

It's a figure of speech. I'm sorry if it offended you, I was just trying to say how much I would enjoy an RPG for the 2600. Was not trying to get anyone excited in a negative way.

Edited January 30, 2006 by silver_surfer

[Thomas Jentzsch]

I'm sorry if it offended you

No reason to be sorry, Zylon is notorius for seing everything the negative way.

[fabventure2600]

Ah...Dont Take IT so serious,IT make his number.....

[supercat]

...which is, presently, running an average of about 80 cycles per scanline with sprites. The amazing cruelty to TIA that is the tile-based drawing code is perhaps best described as "an 18lk", because each group of 18 scanlines passes through 18 slightly-different iterations of an unrolled loop. However, the bitmaps are more-or-less 2 lines of resolution with various levels of colour detail depending on the type of object and where it appears on the map.

1008008[/snapback]

 

Sounds fairly RAM-intensive. Might be doable in 128 bytes, but I wouldn't think you'd have enough left to implement a really good RPG without using some form of memory expansion (whether a joystick-2 EEPROM or something else). Maybe once I get some more 4A50 carts made you could look at that (64K ROM + 32K RAM). Otherwise, I'd think it too likely you'd end up with an "RPG" where there were maybe 3 or 4 monsters in the whole "world".

[Bruce Tomlin]

Actually milestones aren't a silly idea at all. I'm keeping track of progress in my ColecoVision RPG as a bunch of small milestones, which are basically a bunch of "I need to do this" notes in a text file.

 

Dated milestones for stuff you do in your spare time is overdoing it a bit, however.

 

The number of active 2600 coders, using "active" loosely, is about 20-30.

 

The number of homebrew games you are likely to sell is around 100-200, assuming you even complete this.

 

Given those numbers, your concerns seem a bit...ridiculous.  You haven't used *any* code posted here, because of licensing concerns?

 

You're inventing problems that don't exist and then solving them with a sledgehammer.

Writing a new game IS "inventing problems that don't exist". It's about time we get more folks doing something other than yet another freaking port (though I will admit that the Ladybug port looks pretty good). And I'm really impressed with the size of the sledghammer. I thought I was doing pretty good with my 50+ cycle macro every scanline in Red Box/Blue Box, but using Perl and M4 to generate kernal code, AND coming up with something that could realistically be called an "18-line kernal" is a magnitude above that.

 

And I may be the only one here who understands his concerns about reusing someone else's code in this. It's a rule that he's set for himself for good reasons. It just happens to be on a system that's tricky enough to program that people traditionally crib kernal code from each other and from disassembled games.

[supercat]

It just happens to be on a system that's tricky enough to program that people traditionally crib kernal code from each other and from disassembled games.

1009853[/snapback]

 

Well, there are only so many ways to code:

  lda #const1
 dcp vcount
 adc #const2
 sta ENABL

 

or other such kernel bits. Especially on platforms like the 2600, it's not always clear what level of "borrowing" is acceptable given how similar a lot of code will be naturally.

 

For stuff like 2600 code, I tend to think that bits of code that are small enough to reproduce from memory (or work out again if slight details are forgotten) are pretty much fair game. But nearly all cartridges will have a lot of code which goes far beyond what a person could remember.

[brpocock]

Sounds fairly RAM-intensive.  Might be doable in 128 bytes, but I wouldn't think you'd have enough left to implement a really good RPG without using some form of memory expansion (whether a joystick-2 EEPROM or something else).  Maybe once I get some more 4A50 carts made you could look at that (64K ROM + 32K RAM).  Otherwise, I'd think it too likely you'd end up with an "RPG" where there were maybe 3 or 4 monsters in the whole "world".

1009843[/snapback]

 

Well, to be honest, each battle uses temporary RAM for the monsters you're fighting, but there's a very small bank of "persistent" RAM that hangs around after the battle's over. Basically, player stats and a bunch of "flag bits" for e.g. "player has learnt this spell" or "player has completed this task."

 

32k RAM. Yeesh, I'd not know what to do with all that

 

Monsters and NPC's, of necessity, are not being "simulated" when the player isn't present. There's some kind of philosophical/physics statement there about parts of the world existing in a Schrödinger's Box until the player arrives, and then the state of the "persistent RAM" instantly snaps that region of the (game) universe into a deterministic state?

 

EDIT/PS: This isn't too dissimilar from how e.g. Legend of Zelda for NES operates. Zelda has a lot more persistence, though, e.g. each screen keeps a count of the number of remaining monsters, but not what their status is. (Go to an overworld screen with two types of monsters on it... e.g. the desert with the flying things and the sand things. Kill all but one, leave, and return a couple of times. The computer won't remember which type of monster is left, just that there's only one. Kill the last monster and return, and it regenerates the original max#.)

 

Even with more RAM, I'd probably want it more for precaching graphics data than simulating a large number of NPC's and monsters on every screen, however, the ability to track more persistent states -- like Zelda's "monster counts" -- would be useful.

 

The other "problem" is that the entire persistent RAM area has to be able to be encoded in an alphabetic sequence for continuation codes.

 

If I had a "dream cart," I'd want 1k RAM (bankable), 1k ROM (bankable), and 2k ROM (bankable) blocks, perhaps sacrificing a few ROM bytes for a serial EPROM like the MemCard. But ROM-only I know can be produced already, and to quote Steve Jobs, "Real artists ship."

Edited January 31, 2006 by brpocock

[brpocock]

I'm getting a MemCard for the project, so MemCard/AVox support will be definitely included.

 

Special thanks to Richard H.!

[vdub_bobby]

I'm getting a MemCard for the project, so MemCard/AVox support will be definitely included.

 

Special thanks to Richard H.!

1010793[/snapback]

 

Thanks Richard!

[MayDay]

I'm getting a MemCard for the project, so MemCard/AVox support will be definitely included.

 

Special thanks to Richard H.!

1010793[/snapback]

 

Arigatou gozaimes, Richard-san I'm not sure if we can ever repay your kindness, but want you to know we are very appreciative of it.

 

-JD

[Richard H.]

I have a box of the things, got to get rid of them somehow

[SeaGtGruff]

I have a box of the things, got to get rid of them somehow 

1011222[/snapback]

 

Come again? You have a box of what that you need to get rid of? I thought they were temporarily sold out or whatever until another batch gets made, or am I getting them confoozled with something else? Because if you've got something for sale, I'd like to know the details!

 

Michael Rideout

[Richard H.]

Come again? You have a box of what that you need to get rid of? I thought they were temporarily sold out or whatever until another batch gets made, or am I getting them confoozled with something else?

No, it's the AtariVox which is temporarily sold out, I was joking about the MemCard. I built 100 thinking they were going to sell out fast only to have no one wanting any, I'm glad to say it's changing now though

[supercat]

Come again? You have a box of what that you need to get rid of? I thought they were temporarily sold out or whatever until another batch gets made, or am I getting them confoozled with something else?

No, it's the AtariVox which is temporarily sold out, I was joking about the MemCard. I built 100 thinking they were going to sell out fast only to have no one wanting any, I'm glad to say it's changing now though

1011902[/snapback]

 

Coordinate with Albert to supply them to Strat-O-Gems purchasers. They really do make the game much neater.

[+Nathan Strum]

No, it's the AtariVox which is temporarily sold out, I was joking about the MemCard. I built 100 thinking they were going to sell out fast only to have no one wanting any, I'm glad to say it's changing now though 

 

I didn't even know about them. I must have missed the announcement. If they were linked to from the Strat-O-Gems page (or any other game supporting them) that would help get the word out.

[cd-w]

I didn't even know about them. I must have missed the announcement. If they were linked to from the Strat-O-Gems page (or any other game supporting them) that would help get the word out.

1012244[/snapback]

 

I heard them mentioned on the forum, but I am not sure how to get hold of one. They are not listed on the AA store pages as far as I can see?

 

Chris

[Richard H.]

Coordinate with Albert to supply them to Strat-O-Gems purchasers.

Good idea, I'll ask him.

 

In the meantime, if any one wants one go here

[mos6507]

I think a full-fledged RPG in 128 bytes of RAM is pretty much impossible. Secret Quest, for instance, has the Superchip. Dragonstomper uses the Supercharger for extra RAM and spreads the game across multiple loads.

 

The closest thing I can think of would be the "Adventure+" type engines used in games like Raiders, the Swordquest series, and E.T. But those are still a far cry from an Ultima-style RPG.

 

Wasn't the Homestar Runner RPG going to use some extra RAM?

 

If you have no persistence, then you have to force the game to be more linear, otherwise stuff keeps resetting which can be annoying and create lots of cheat opportunities. Either that or everything becomes a random encounter and you can't get creative in your level design besides the background terrain.

 

Also, the AtariVox is great not only for voice but for better-sounding music and audio than the 2600 can generate. I was impressed with how it was used in Strat-o-gems. You can make a lot of cool sounds with it, although there may be higher code overhead driving that vs. the TIA.

 

It seems a natural to store save-games on AtariVox vs. using a tedious passcode system.

Edited February 4, 2006 by mos6507

[SeaGtGruff]

In the meantime, if any one wants one go here

1012579[/snapback]

 

Thanks, I found the same link earlier tonight by searching the forums archive for "MemCard." I can't believe how cheap they are ($10, right?)! I haven't ordered one yet, but I figure I'll buy at least 2-- one for my 2600, and one for my 7800!

 

This is a great time to be an Atarian-- batari BASIC, Cuttle Cart (1 and 2), Krokodile Cartridge, AtariVox, MemCard... what's next? (Maybe supercat's bankswitched cartridge with oodles of executable RAM?)

 

Michael Rideout

[brpocock]

I think a full-fledged RPG in 128 bytes of RAM is pretty much impossible.  Secret Quest, for instance, has the Superchip.  Dragonstomper uses the Supercharger for extra RAM and spreads the game across multiple loads.

 

The closest thing I can think of would be the "Adventure+" type engines used in games like Raiders, the Swordquest series, and E.T.  But those are still a far cry from an Ultima-style RPG.

 

No, not so much Ultima as The Legend of Zelda (in scale of the simulation). Persistance of major events, but not minor ones. Most RPG events are basically "increase your stats to point [x]", or "acheive a goal" = "acquire an item" = "set a flag".

 

(However, yes, game play is in the Ultima/FF/Dragon format.)

 

It seems a natural to store save-games on AtariVox vs. using a tedious passcode system.

1012583[/snapback]

 

Yes, I'm working toward supporting both, however, since not everyone (not even most of the people on these fora) has an AVox/MemCard. That produces a second pressure on keeping the persistent RAM size small as it has to be something that can be encoded in text and entered on a joystick.

 

Perhaps for the sequel (..?!) we'll put the electronics gurus to the test to come up with a good bankable RAM solution

 

Ultimately the decision comes down to, whether or not it's "fair"[1] to use anything but ROM to do the game... As a baseline, we know that a 64k banked ROM can be manufactured and sold at a reasonable price.

 

[1] By "fair," I mean of course that ultimately just stuffing a 65816 or ppc405 CPU into a cartridge with a 2.5" HDD is plausible... although, certainly an obscenely extreme case... While I doubt the "suits" at Atari in the 80's would have ever approved a 64kiB ROM budget for a game in a totally unproven (at that time) format, much less given a two-man team leeway to devote the equivalent of a month or two's full-time development efforts to design it Of course, if it were 1983 now, we'd not have two decades of experience in doing tile-based menu-driven RPG's to draw on either... (and I'd be fixing to enter Kindergarten)

[vdub_bobby]

Also, the AtariVox is great not only for voice but for better-sounding music and audio than the 2600 can generate.  I was impressed with how it was used in Strat-o-gems.  You can make a lot of cool sounds with it, although there may be higher code overhead driving that vs. the TIA.

Actually, I don't think the AVox requires more code overhead to produce sounds than TIA does. Depending on the sounds, it might require less than an equivalent TIA-produced sound requires.

[Kroko]

Perhaps for the sequel (..?!) we'll put the electronics gurus to the test to come up with a good bankable RAM solution

What do you need and what do you think is a reasonable price for that ? And I need to know how many boards you need.

[brpocock]

Perhaps for the sequel (..?!) we'll put the electronics gurus to the test to come up with a good bankable RAM solution

What do you need and what do you think is a reasonable price for that ? And I need to know how many boards you need.

1013832[/snapback]

 

Hm, realistically:

 

If I could bank 2k ROM/4×256B RAM/1k ROM individually somehow, (the 1K at the end to catch the RES/BRK vectors), ideally with an instruction saying, "mirror such-and-such a RAM page into persistent (flash/EPROM/...) storage," that would be great.

 

The 4×256B RAM could just be a 1k RAM cache to a serial EPROM facility, actually, especially if I could swap a page of RAM to/from EPROM within the vblank interval... or asynchronously. ** This assumes that the black magic I just read about doing RAM without doubling address space for reads v. writes is actually doable? ... else that's understandable, but even 2×256B is usable...

 

Of course, the more ROM the better... (yes, I realize it'd also be EPROM/flash/... but from programmerland, it should act like ROM...)

 

That layout would let me shove 2k of gameworld data ... bitmaps, maps, whatever ... with a 1k kernel in context, give me "plenty" of RAM for different game areas to each use a page for "local" flags and such, plus a page for player/global stats, a page for self-modifying kernel code, and so forth.

 

This is just off-the-cuff, but if some sort of memory manager could do background DMA copies between ROM, RAM, and EPROM, that would provide some killer solutions.

 

I'd want to handle at least, oh... 128k or 256k "ROM" area, maybe 8k .. 16k of "RAM" working storage, and then, say, 4 savegames of 8/16k each... well, that's some odd sizes, chips don't come in 168k or 336k sizes, and I'd assume this would probably all end up on a single flash chip? If so, could something monitor the CPU clock and do bus sharing like the way the 6510 and VIC-II chip share accesses to RAM in opposite phase... and, then do DMA copies of memory regions asynchronously to the CPU's accesses, so that the program could just request a block copy from the working storage area into the save game area, and then periodically check a flag (say, during vblank interval) to determine if the transfer has been completed yet.

 

Or would it be more economical to make it as an EPROM for the ROM areas, a RAM chip for the RAM areas, and have a serial EPROM off to the side somewhere to mirror the RAM? Again, it'd be nifty to just send an offline command like, "dump RAM page (x) into EPROM page (y) and I'll be back in (n) cycles with your next orders."

 

In a perfect world, "swapping" RAM to tertiary storage (serial EPROM) shouldn't require program intervention, because it's almost certain to lead to a certain amount of delay every time we swap, which causes missed vblanks or relatively rough timing code. I don't think anyone ever wants to see an Atari tape come up with, "PLEASE WAIT..." screens...?

 

 

OK, ... this is all really off-the-cuff sketches, and I really don't know what the limitations are, or have the slightest idea of what the production costs would be for something like that.

 

Ultimately, whatever gets built needs to be something that AtariAge can stuff into little plastic boxes with my code on them and works.

 

And that leads to the question of whether there's an existing similar bank-switching mechanism that something like this could be based off of, so that e.g. when the Krok carts go back into production I can get me one and test on some real hardware...

 

Plus, modifying stella for my unit testing...

 

Any suggestions? :-)