2600 RPG - codename, "CiE"

[Kroko]

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...

I have not tested the magic writes myself, but supercat is confident that it works. And my feeling is, that I have to try it and see what happens

 

Of course, the more ROM the better...

Its nice to know what you need in an ideal world, but I also do need to know what you think is the minimum for your project. There are always some compromises necessary on the 2600 (and you want to be able to pay for it)

For example if you would really need the magic writes, then it would be necessary to interface all 8 datalines. This leads to a situation where you have less lines available for your Rom Space, or where you have to live with larger "bank" sizes (> 256 byte).

There is only a limited number of I/O lines on the logic chips and it does not make sense to use a device with more than 44 pins for a standalone board (Because that is what I think can be produced by hand)

 

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 have to think about that, but my feeling is that this will at least be complicated.

 

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 you don't insist on the magic writes, that Rom/Ram size is not a problem

 

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 order to copy something to RAM, the bus must be available for the cartridge. That means nothing shall drive the bus, while the cart is working on a memory copy. I am not sure how you would make sure, that the bus is absolutely free for a longer time period ? The alternative is, to disconnect the bus from the VCS while the cart does the copy. But that requires some additional chips which makes it more expensive. And you need a routine that runs in VCS Ram to wait for the copy to finish. Maybe by polling a hotspot ?

 

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.

The question is, what would you be willing to pay for your game and what part of that can be hardware costs. If you come up with a limit, then its much easier to judge if it is realistic or just a dream

 

And that leads to the question of whether there's an existing similar bank-switching mechanism that something like this could be based off

The memory dump is new. Maybe a CC2 could do things like that, but nothing else I know of (and the price is 200$). The bankswitching itself is not a big problem. To be honest, I would think about using AtariVox or the EPROM sticks. I don't say its not possible to design a device with internal writable eprom, but it may be too expensive.

[brpocock]

brpocock

Of course, the more ROM the better...

Kroko

Its nice to know what you need in an ideal world,

Kroko

but I also do need to know what you think is the minimum for your project. There are always some compromises necessary on the 2600 (and you want to be able to pay for it)

 

Well, the current project goals I'm confident we can meet in the 64k=4k×16 configuration. It does present a few limiting factors.

 

#1. Can't guarantee everyone has a MemCard, so need to have code-entry savegame functionality.

 

#2. 128B of RAM plus limits of code-entry "storage" leaves very little room for persistent player stats, inventory, and gameworld event flags.

 

#3. 4k banking requires that a certain amount of code and data be duplicated a few times, so this "64k" budget is more like "48k" of unique data.

 

This thread is, in my opinion, more for the benefit of what could come next. Say, once CiE has reached a nice alpha version, what can be done bigger/better/faster/more...

 

...Or is this the sort of R&D that could be done in parallel with the software development? How long a lead time is there on this kind of design work?

 

There's a lot of games out there that have been done using tile-based graphics, since that's a native hardware graphics system on the SMS, SGG, NES, NGB, GBC, and even C=64 and C=128, so I hope that the engine/kernel for CiE still has a lot of places to go even after the one game is done.

 

Kroko

For example if you would really need the magic writes, then it would be necessary to interface all 8 datalines. This leads to a situation where you have less lines available for your Rom Space, or where you have to live with larger "bank" sizes (> 256 byte).

There is only a limited number of I/O lines on the logic chips and it does not make sense to use a device with more than 44 pins for a standalone board (Because that is what I think can be produced by hand)

 

Banking in RAM at 512B would be probably passable, if it got me magic writes so I'd still have the ability to address 2 RAM banks at once and still have 3k ROM. The ROM spaces I'd peg at 1k and 2k areas. I vaguely figured that putting the 2k low and the 1k high would be easier since it'd keep it split 2k ROM + 2k = ( 1k RAM = ( 2×512 or 4×256 ) + 1k ROM ), rather than splitting it e.g. 1k/2k/1k where the middle 2k wouldn't have uniform high address bits.

 

The logic, for my purposes, of having it banked 2k + 1k at all is that the kernel in its current (not very optimal but getting there) incarnation is about 1300 bytes. With self-modifying code I could factor out chunks of that, but it's still basically a 1k'ish region that must be duplicated in each bank of ROM (using the regular 4k×16 banking scheme) giving a fairly high overhead. Having 2k chunks paging in with map data and bitmaps would be fairly good, but still lead to duplicating some data (the player sprite data and bitmaps that are used in maps in multiple 2k banks).

 

I suppose I might even be overtailoring something like this. If it's plausible to arbitrarily bank any 1k ROM or RAM region into any of the 4 1k "banking slots," that would be a more general-purpose solution and also could eliminate some of my concerns with RAM size. I just want to guarantee the ability to copy RAM-to-RAM. If I can bank in 1k of RW RAM or 512B of double-addressed RAM into any of the four banking slots, that would solve nicely the situation, and probably provide something that others would find more useful as well.

 

Which is easier/cheaper: doing arbitrary slots or something more like the 2k/4×256/1k scheme?

 

I could almost imagine having four latch registers (presumably buried at the F7 banking points?) into which 1k bank offsets would be written, i.e. if I write $01 to bank slot control register 0, than my first 1k bank would be from $00400 .. $007ff from the physical ROM range... If those are one-byte registers I'd have 256k addressibility only, so there would have to be some lost ROM for RAM unless it's all actually flash or something underneath?

 

Else, multibyte registers, or something like ... if you write to this register, it sets bank slot 0 to the selected 1k RAM range from $00..$0f, if you write to this register, it instead sets bank slot 0 to the selected 1k ROM range from $00..$ff, ... thus having something like BANK0RAM, BANK0ROM, BANK1RAM, BANK1ROM, ... control register pairs?

 

Also, if I could have arbitrary ROM and RAM banking, I'd need to power up in a known initial banking state since RAM banks will probably have $ffff in the RES vector otherwise?

 

brpocock

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.

Kroko

I have to think about that, but my feeling is that this will at least be complicated.

 

Ah, yes, I've no doubt. I'm really not clear what level of "intelligence" a multibanking scheme would require ... are we talking about gate kit chips or a PIC/FPGA level of complexity?

 

DMA offline memcopies are probably pie-in-the-sky if this can otherwise be done with "gate" level chips like a "normal" banking system. If it were a PIC or something, that's another story.

 

brpocock

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?

Kroko

If you don't insist on the magic writes, that Rom/Ram size is not a problem

Any sufficiently advanced technology is indistinguishable from magic?

 

I'm curious whether crossing the 256k mark with 1k banking regions is a limit on bankswitching via register writes or if 16b latches could exist?

 

brpocock

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."

Kroko

In order to copy something to RAM, the bus must be available for the cartridge. That means nothing shall drive the bus, while the cart is working on a memory copy. I am not sure how you would make sure, that the bus is absolutely free for a longer time period ? The alternative is, to disconnect the bus from the VCS while the cart does the copy. But that requires some additional chips which makes it more expensive. And you need a routine that runs in VCS Ram to wait for the copy to finish. Maybe by polling a hotspot ?

 

I'm not clear on the electronics involved, and it may be different on 6507 v. 6510, but the C=64 has it set up such that the CPU does accesses to RAM/ROM during phase 0 (I think) and the VIC-II (the GPU) does accesses to memory during the opposite phase. (Now, one thing that I know is 6510-specific is that the VIC-II will "hold up" the CPU during "bad lines" while it fetches sprite data, and the 8502 is modified to handle a three-phase handshake where a Z80A has the third phase...)

 

If the "phase clock" were known to the cartridge, it seems like an "offline copy" operation could be done during the opposite phases, and if each read or write took 1 CPU cycle, it would even be a predictable 2 cycles per byte for the copy to complete.

 

The other idea, this also totally bogus and based on no electronics guesswork whatsoever, would be to require the source and destination to be banked out during the copy.

 

But nix that. As long as I can do RAM-to-RAM copying we're good.

 

brpocock

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.

Kroko

The question is, what would you be willing to pay for your game and what part of that can be hardware costs. If you come up with a limit, then its much easier to judge if it is realistic or just a dream

 

Well, myself, I'd just like to see it made possible, but since money is money, after all:

 

It looks like if I bought one-off parts it'd cost around $10 to do a 32k game. I'm guessing the 64k=16×4k situation would be similar, but since the 64k PCB's/EPROM's aren't standard stock yet, perhaps a bit higher? Adding labeling and a nice manual we're probably around $15 costs going down the standard path. Actual sticker prices on most games run $13..$25 via AA, excepting Thrust Platinum at $35.

 

If we make a quantum leap forward to, say, 256k ROM and 16k RAM, plus PCB and controller logic and so forth, let's make the marketing assumption that there would still be 50-100 people who'd be willing to pay on the higher side of that range, let's say it could hit $30. If we give AA the same margin for upkeep and so forth -- let's say $10 hardware costs leads to $25 street price meaning printing and upkeep is $15/game? -- then a $30 title has a $15 hardware budget.

 

I'm thinking, perhaps in error?, that anything about around $30 is going to be too steep for anyone to afford on their toy budgets, especially if it requires a $10 MemCard to really use it.

 

brpocock

And that leads to the question of whether there's an existing similar bank-switching mechanism that something like this could be based off

Kroko

The memory dump is new.

Ah, well, in brainstorming this, this way, I'm easily done away with that if need be. It's something we have on CBM machines with expanded memory ("copy a page of RAM into/from the RAM Expansion Unit"), but if it's difficult to do then strike it right off.

 

Kroko

Maybe a CC2 could do things like that, but nothing else I know of (and the price is 200$). The bankswitching itself is not a big problem.

 

 

Ironically, I thought that it'd be the hard part.

 

Clearly don't want to make a game that'd cost $200 a pop. Myself, for development... well, I may have to break down and get an EPROM burner anyways, so if I could get hold of a model board to work from, I could probably work out a reasonable development process for this.

 

And with any luck I, or someone, could hack Stella to cope with it for unit testing :-)

Kroko

To be honest, I would think about using AtariVox or the EPROM sticks. I don't say its not possible to design a device with internal writable eprom, but it may be too expensive.

1013896[/snapback]

 

 

Yes, that makes sense.

 

From a marketing standpoint... the AVox and MemCard are both "out of production" right now. Assuming that the MemCard at least were back in production by the time the game were finished, I wonder if people would "go for" a plan such as: "Buy this game, $30 for the game alone (*REQUIRES MemCard), $40 for game plus 32k MemCard (also works with these games: ...)"

 

If I were Joe Stellalover off the street and saw a $40 VCS game, I'd probably just skip over it, but a $30 game with a $10 MemCard that'd also work for Stratagems and CiE (assuming the fancy new game is a CiE sequel/followup), and potentially some other future games.

 

Heck, maybe the $40 kit could throw in some other silly "extra" or anyother. Lagniappe, as they say. "Collectors' Edition?"

 

 

Back on the money page, assuming that the MemCard minus labour actually is in the sub-$10 pricerange, that's still cutting it awfully close on the "tolerable upper price" range.

 

OTOH, if the whole shebang... scads of bankable ROMS, some small amount of bankable RAM, and an onboard serial EPROM... could be manufactured and keep the mfg. costs under $15..20?, that might work. It also opens up using the serial EPROM for swapping RAM into more frequently, reducing the RAM requirement. With the MemCard solution, I'd not want to trust the presence of the MemCard always, because it eliminates two-player games, or (like CiE) using the Video TouchPad for "hotkeys," among other things.

 

Granted, it'll be a pain to have to unplug the second joystick or the touchpad or whatever every time you save, but it's preferable to "losing the port permanently" I think.

 

 

 

EDIT: The QUOTE bbcode thing hates me.

Edited February 6, 2006 by brpocock

[Kroko]

How long a lead time is there on this kind of design work?

A difficult question. I don't have a good answer to that. Most people here are hobby designers. Depends on when they have time and if your design is similar to something they have already done.

 

Which is easier/cheaper: doing arbitrary slots or something more like the 2k/4×256/1k scheme?

Arbitrary slots consume more internal logic resources and smaller banks need more pins. Not easy to compare. I don't think either of the two methods is especially difficult.

 

are we talking about gate kit chips or a PIC/FPGA level of complexity?

The logic chip internals would be more complex (serial EEPROM writing algorithm and control of a bus transceiver and some way of doing a complete page dumb with just one command) It would most likely not fit into a cheap Xilinx device and that means the boards can't be easily produced anymore ... Not to speak of the development time needed for a thing like that.

I'm curious whether crossing the 256k mark with 1k banking regions is a limit on bankswitching via register writes or if 16b latches could exist?

The withs of the latch is only limited by the amount of resources on the Logic Chip. There actually is no limit for one special aspect. Its the complete design that has to fit into the device.

 

and keep the mfg. costs under $15..20?,

That is realistic, if you skip the serial EEPROM idea and keep to standard banked flash-rom together with RAM.

[vdub_bobby]

EDIT: The QUOTE bbcode thing hates me.

I think there is a limit on the number of quote tags you can have in a post. Exceed it and it kills all of the quote tags!

[brpocock]

(/me dumped the hardware thread over to the hardware forum)

 

I think there is a limit on the number of quote tags you can have in a post. Exceed it and it kills all of the quote tags!

 

Ah, that splains it, thanks !

[supercat]

Which is easier/cheaper: doing arbitrary slots or something more like the 2k/4×256/1k scheme?

Arbitrary slots consume more internal logic resources and smaller banks need more pins. Not easy to compare. I don't think either of the two methods is especially difficult.

 

Well, my 4A50 bank switch card has the 32K RAM and 64K ROM accessible via the following bankable areas:

$1000-$17FF -- Any 2K page of RAM, or any of the first 16 2K pages of ROM

$1800-$1DFF -- The first 1.5K of any 2K page of RAM, or of any of the last 16 2K pages of ROM

$1E00-$1EFF -- Any 256 bytes from RAM or ROM

$1F00-$1FFF -- The last 256 bytes of ROM (fixed bank)

 

The logic chip internals would be more complex (serial EEPROM writing algorithm and control of a bus transceiver and some way of doing a complete page dumb with just one command) It would most likely not fit into a cheap Xilinx device and that means the boards can't be easily produced anymore ... Not to speak of the development time needed for a thing like that.

 

My second proto 4A50 bank cart includes 8Kx8 of i2c serial EEPROM (just got it assembled, but it's untested). Accessing it, if it works at all, will be rather "interesting", to put it mildly, since the clock wire is wired to one of the upper address pins. The code to do the access, and any data buffer therefor would pretty much need to run in the 128 bytes of RIOT RAM. As to whether this will be worthwhile, I don't know, but I figured if I left space for the part and didn't populate it it'd be pretty harmless.

 

and keep the mfg. costs under $15..20?,

That is realistic, if you skip the serial EEPROM idea and keep to standard banked flash-rom together with RAM.

[right][snapback]1013994[/snapback][/right]

 

The parts budget on my board is under $15, but the problem is that for some strange reason I can't find anyone who'll build these things for $1ea labor.

[brpocock]

Which is easier/cheaper: doing arbitrary slots or something more like the 2k/4×256/1k scheme?

Arbitrary slots consume more internal logic resources and smaller banks need more pins. Not easy to compare. I don't think either of the two methods is especially difficult.

 

Well, my 4A50 bank switch card has the 32K RAM and 64K ROM accessible via the following bankable areas:

$1000-$17FF -- Any 2K page of RAM, or any of the first 16 2K pages of ROM
$1800-$1DFF -- The first 1.5K of any 2K page of RAM, or of any of the last 16 2K pages of ROM
$1E00-$1EFF -- Any 256 bytes from RAM or ROM
$1F00-$1FFF -- The last 256 bytes of ROM (fixed bank)

 

Wow. Rather baroque.

 

I'm not sure something precisely like that would work really well for e.g. the engine I'm using in CiE, most significantly since there's no way to do a RAM-to-RAM copy as I see it? (i.e. one could only copy from the first 1.5k of a 2k segment into another)

 

I kinda like the idea of the fixed position final page, it does solve a few problems.

 

Would the same kind of circuitry be capable of doing different bank slot sizes?

 

And, what kind of programmer's interface is there to control this? I assume it's more like virtual registers and less like write strobes?

 

The logic chip internals would be more complex (serial EEPROM writing algorithm and control of a bus transceiver and some way of doing a complete page dumb with just one command) It would most likely not fit into a cheap Xilinx device and that means the boards can't be easily produced anymore ... Not to speak of the development time needed for a thing like that.

 

My second proto 4A50 bank cart includes 8Kx8 of i2c serial EEPROM (just got it assembled' date=' but it's untested). Accessing it, if it works at all, will be rather "interesting", to put it mildly, since the clock wire is wired to one of the upper address pins. The code to do the access, and any data buffer therefor would pretty much need to run in the 128 bytes of RIOT RAM. As to whether this will be worthwhile, I don't know, but I figured if I left space for the part and didn't populate it it'd be pretty harmless.

[/quote']

 

That would probably render it useless for swapping, then, since it'd be unreasonably difficult to do a copy from (offboard) RAM into EEPROM? Still, it's a nice option to have.

 

and keep the mfg. costs under $15..20?' date=' [/quote=brpocock']

That is realistic' date=' if you skip the serial EEPROM idea and keep to standard banked flash-rom together with RAM.

[right']1013994[/snapback][/right]

 

The parts budget on my board is under $15, but the problem is that for some strange reason I can't find anyone who'll build these things for $1ea labor.

1014137[/snapback]

 

Actually, the $15 figure was just accounting for parts, assuming that the target street price would be around $30, and there's printing manuals and labels and various upkeep/overhead expenses to be accounted for... That's basically derived from some shirtcuff maths of what the total "markup" is on existing AA carts and what the market might bear for a "really damned huge" game price. Not that I'd presume to dictate biz stuff to AA, but rather to determine if something like this were economically feasible

 

Unless you were meaning that the labour is much more expensive than for other bankswitching schemes?

[supercat]

I'm not sure something precisely like that would work really well for e.g. the engine I'm using in CiE, most significantly since there's no way to do a RAM-to-RAM copy as I see it? (i.e. one could only copy from the first 1.5k of a 2k segment into another)

 

You neglect to consider the region at $1E00-$1EFF which is actually one of the more useful bankable areas. Doing a RAM-to-RAM copy of data which can span 2K blocks will be a pain, but if you want to copy a 1K RAM block that doesn't cross a 2K boundary to a 1K area that's aligned on a 256-byte boundary, the code would be something like:

 ldx #4 ; Number of pages
 lda #dest_page
 sta $FF ; Sets bank switch register at $1E00 to specified page
 ldy #0
lp:
 lda (srcptr),x
 sta $1E00,y
 iny
 bne lp
 inc srcptr+1
 inc $FF
 dex
 bne lp

Nicer than any other bank-switch scheme I've seen on the 2600 (only two, E7 and SuperCharger, even allow more than one bank of RAM to be active simultaneously).

 

Would the same kind of circuitry be capable of doing different bank slot sizes?

 

To some extent.

 

And, what kind of programmer's interface is there to control this? I assume it's more like virtual registers and less like write strobes?

 

Read the blog.

 

That would probably render it useless for swapping, then, since it'd be unreasonably difficult to do a copy from (offboard) RAM into EEPROM? Still, it's a nice option to have.

 

With 32K RAM and 8K of serial EEPROM, just use the RAM for swapping.

 

Unless you were meaning that the labour is much more expensive than for other bankswitching schemes?

1014352[/snapback]

 

Well, it's all surface mount. Makes things cheaper from a mass-production standpoint, but harder for hand assembly.

[Albert]

EDIT: The QUOTE bbcode thing hates me.

1013945[/snapback]

Just for future reference, there is a hardcoded limit concerning the number of QUOTE tags you can have in a message. If you exceed that limit (I think it's 10?) then the forum simply ignores the QUOTE tags, which is extraordinarily lame since it does not even warn you about it. If you encounter this again, you can try splitting your post into multiple messages.

 

..Al

[Bruce Tomlin]

Also, if even one QUOTE or /QUOTE tag is unmatched, it doesn't do any of them. This applies to other tags as well.

[Paul Slocum]

Don't worry, I haven't given up completely on my RPG...

 

And based on my memory planning, a decent RPG is possible in 128 bytes. The bigger challenge for my designs was fitting it in 64k. Tile maps, bitmap character graphics, and text get big really fast.

Edited February 17, 2006 by Paul Slocum

[+Nathan Strum]

Don't worry, I haven't given up completely on my RPG... 

 

I'm glad to hear that - the demo was very cool.

[Shawn]

#1. Can't guarantee everyone has a MemCard, so need to have code-entry savegame functionality.

 

I don't think it would be a bad thing if I had to buy a memcard for this game. Actually I think it would be well worth it. IF this game comes with maps,memcard, ect. I will have no problem dishing out $40 to $50 bucks for it and I'm quite sure just the nature of this game would make others feel the same way about spending a little more to get this game.

[ZylonBane]

Anyone else even slightly disconcerted that this thread has been almost entirely about software licences and bank-switching schemes, and almost nothing at all about the GAMEPLAY?

[brpocock]

Anyone else even slightly disconcerted that this thread has been almost entirely about software licences and bank-switching schemes, and almost nothing at all about the GAMEPLAY?

1019974[/snapback]

 

The gameplay is pretty well understood, I expect. Move across gridded map, select items from menus...

[MayDay]

Anyone else even slightly disconcerted that this thread has been almost entirely about software licences and bank-switching schemes, and almost nothing at all about the GAMEPLAY?

1019974[/snapback]

 

The gameplay is pretty well understood, I expect. Move across gridded map, select items from menus...

1019982[/snapback]

 

Something else Robert hasn't really talked about was a decision I made early on in the process. I decided many of the game characters and plot should remain hidden from public view until we actually release the game because a semi-complete understanding of it would effect the way the game was played (and ultimately percieved). On finding out some of the details he agreed with my assesment, and we have moved forward to that end. That is why even the working title is left undeclared at this point.

 

And on the other hand, it's like Robert said. 2D RPGs are really not all that different from one another. Case in point, he described CiE as an "Ultima clone", which is a game I had never heard of before designing this game. Other than being "atari-ized", for me the idea is to look and feel as close to a NES RPG as possible. <sarcasm> And while I *really* appreciate your concern </sarcasm>, if you scroll up you will also find that this is under the game programming section. For anyone like myself who doesn't really understand all this (apparently zylonbane too), I've been working on something to help expain the gameplay but have just been swamped at work and haven't had the opportunity to complete it. Starting on Monday, this should change, but that's what I said last Friday too.

 

-JD

[ZylonBane]

Case in point, he described CiE as an "Ultima clone", which is a game I had never heard of before designing this game.

You've... never... HEARD OF... ULTIMA?!?!?!

 

Dangit, where are the bug-eyed jaw-dropping smilies when you really need them?

[Bruce Tomlin]

Something else Robert hasn't really talked about was a decision I made early on in the process.  I decided many of the game characters and plot should remain hidden from public view until we actually release the game because a semi-complete understanding of it would effect the way the game was played (and ultimately percieved).  On finding out some of the details he agreed with my assesment, and we have moved forward to that end.  That is why even the working title is left undeclared at this point.

That's been my feeling too. I have a working title, but haven't told it to anyone. But some of the few story-like things that I came up with while developing my graphics engine may make it in anyhow.

 

You've... never... HEARD OF... ULTIMA?!?!?!

 

Dangit, where are the bug-eyed jaw-dropping smilies when you really need them?

Heh. I've even taken out Lord British's trash a few times. Long story, but it had to do with his birthday parties. It's amazing how much junk can be left on a lawn after firing off a few cases of fireworks. And I've met a few of the real people that some of the Ultima characters were named after. But I still haven't played any Ultima games, since I went straight from TRS-80 to Macintosh, so I didn't have much exposure to Apple II or PC games.

[ZylonBane]

I've never played any of the Ultimas either, actually. But to have never even heard of arguable the single most influential RPG series in the history of computer gaming... the mind boggles.

[Cybergoth]

Hm... I never liked any of the top-down Ultimas. Influential? - I hope not!

 

The two Ultima Underworld Episodes though - Groundbreaking!

[Heaven/TQA]

ultima 4 rocks...

[MayDay]

I've never played any of the Ultimas either, actually. But to have never even heard of arguable the single most influential RPG series in the history of computer gaming... the mind boggles.

1020231[/snapback]

 

If you read the posting, this is not what I said. I said "I had never heard of" which means that now I have (thanks to BRpocock early in the process). I've gone through several top 25, top 50, etc. listing of games and have never seen it appear on any of those lists. I'm sure you can find one where it is ranked, but the mere fact that it isn't on most is reason enough to say it's hardly "arguable(bly) the single most influential RPG series in the history of computer gaming". Since we didn't have a PC of any kind, I also didn't have any reason to look at those games at the time. And where I grew up wasn't exactly the cultural mecca of the video gaming industry...

 

More to the point I think you're either trying to anger me or discredit me. To that end, you've at least failed at the first one. I'll waste no more of my time defending this inane stance, and will try to keep future postings in this topic relevent to gameplay.

 

-JD

[supercat]

I have not tested the magic writes myself, but supercat is confident that it works. And my feeling is, that I have to try it and see what happens

1013896[/snapback]

 

Prototype #2 of the 4A50 cart is working, and I've also got in-circuit programming functional. Unfortunately at the moment it requires running DOS or Windows 95/98, and the latter are much slower than the former. Does anyone know any easy and fast way to bit-bash the parallel port through Windows? It takes about 1,000 parallel-port writes to program each byte of memory, so speed is pretty critical (don't even think about trying it with a USB printer port adapter!)

[ZylonBane]

Hm... I never liked any of the top-down Ultimas. Influential? - I hope not!

Sigh...

 

GameSpot Presents: 15 Most Influential Games of All Time

 

1UP.COM's Essential 50

 

Ultima III - Wikipedia

 

And so on and so forth...

[Bruce Tomlin]

I've gone through several top 25, top 50, etc. listing of games and have never seen it appear on any of those lists.  I'm sure you can find one where it is ranked, but the mere fact that it isn't on most is reason enough to say it's hardly "arguable(bly) the single most influential RPG series in the history of computer gaming".  Since we didn't have a PC of any kind, I also didn't have any reason to look at those games at the time.  And where I grew up wasn't exactly the cultural mecca of the video gaming industry...

Maybe those lists were made by console gaming fanboys? Ultima was clearly important as an early tile-map RPG, but it was esentially only an Apple II / PC game. Yes, I know there were NES and SNES ports, but they were outshined by the Japanese RPGs which were further down the evolutionary path.