brpocock

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. 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? 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. 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? 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. 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. 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. 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 :-) 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.

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? :-)

Not to raise any unwarranted hopes, but a WiFi adapter for the GBA/Micro wouldn't be impossible. But I tend to agree that it's probably limited to GCN games at this point... Ntd is already supporting three systems and trying to launch a fourth, something is going to have to give, and I'd expect to see the last round of "AAA" GCN and GBA titles to be coming out this summer, leaving the NDS and Revolution for AAA stuff for a while. And opening up the GBA market for more "B" titles and homebrews for the next 10 years or so. Those things are remarkably rugged, even compared to a Lynx or GBC (or the SGG or NGB, but those were freaking fragile).

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

Yes, it's called, "due diligence," and is a mark in our favour if in future someone were to get nasty.

The problem is that they are sort of compatible, but if everyone uses a 3 char+8 scheme while you use a 1-byte code+8 scheme then programmers have to code in the special case for the bB files. Two schemes at work at the same time is just asking for collisions, no matter how compatible. 1012047[/snapback] Three bytes or one, it's the same problem, collision control. As a variant on the "Classed Addressing" theme: ID type byte $00 is reserved for "app info" blocks, à la "Desktop DB". $ff = free block. Let's say ID types $01..$20 are "reserved." $21..$7e (ASCII7 printable characters) are byte 1 of a multichar "type." The type must be at least 2 bytes long, consist only of chars $21..$7e, and the last byte has the high bit set. This is followed by a filename consisting only of chars $20..$7e (note, $20=SPC), again with the high bit set on the last char. $7f "reserved." $80..$bf are one-byte "opaque" types. Note, $bb. There is no filename or internal structure implied. The type may be multibyte or not (e.g. types like $bb, $b0) but no guarantees are made about format, &c. $c0..$fe are two-byte opaque identifiers with a filename following. The second byte can be $00..$ff. The filename follows, restricted to $20..$7e, with the high bit set on the last byte. Does that meet everyone's needs ... ?

Unless there's a public record of them explicitly releasing it to the public, the copyright on DK/2600 should expire around 2077 (Coleco version) and 2082 (Atari version). That's 95 years (standard corporate copyright duration for published works) from 1987.

As I take it, there are several Links who are "called to be the Hero," as there are several Zeldas. Into each generation, a Hero is born... one Hylean in all the world, a Chosen One. One born with the strength and skill to fight Ganon, to stop the spread of his evil and the swell of the monsters' numbers... Wind Waker did a pretty good job of establishing how that works. The bloodlines of Link and the royal family of Hyrule "pass down" the power of the Triforces from one generation to the next. Ocarina explained more fully the history of the universe, how the Triforce came to be, the creation of Hyrule, and so forth. While each game generally stands on its own just fine, despite there being an amazing number of similarities from one game to the next; repeated puzzles and similar items and so forth. Still, there are a number of "in jokes" hinting at the whole repeating nature of the Link/Zelda/Ganon[dorf] saga...

Not that it's the most professional packaging ever, but there are extra-large jewelcases meant for multiple CD's (packs of 6 or . Printing jewelbox books is relatively easy. So would be cutting styro inserts for something like that, I suspect? (To make a cart fit)

Note that the GBA->Revolution is known to work, but NDS->Revolution hasn't AFAIK been official yet.

Works for me.

I think that's an unlikely case. Normally, cart games allocate the storage space up front. So there's only three cases here: 1. Everything is fine 2. MemCard is full, and you don't have the game that created the files. In that case, it doesn't matter which file(s) you delete. 3. MemCard is full, and you do have the game that created the files. In that case, switch over to that cartridge and let it review the files to choose one to delete. For example, in CiE you might see player names, in "Synthcart De Luxe" you might have longer song titles, in some other game perhaps it'd just be an indication of how many lives or what level or score ... I think the basic difference is that on console games (and mainframes, not that it matters), we typically allocate storage up front, and on PC games and apps, one allocates storage "on the fly," with e.g. "File/Save As..." If there was a possibility that someone might run out of MemCard storage during game play, then we'd have more trouble, but I think that's unlikely to occur. To quote the old Stella discussion, I think that's a de facto fallacy, though. No matter what, someone will have a collision unless there's an effort to keep a registry. Yes, with 3 bytes instead of 1 the odds are reduced greatly, in some respects, but it also introduces a psychological aspect. For example, in PC-DOS/Windows, "DOC" is used by (at least) MicroSoft Word (several mutually-unintelligible dialects), MicroSoft WordPad, WordPerfect, and plain text files. On the other hand, Apple ProDOS used one-byte type codes, and still had collisions between apps, even though Apple maintained an official registry service... which is why MacOS and (I think?) SOS went to using 4-byte creator codes, and MacOSX recommends appending extension types like ".iMovieProject" ... If we assume that 2 developers are working on save game functionality without some means of communications, it's a safe bet that "SAV" or "GAM" will be used by two different games in fairly short order. My initial concept of using 8×8 icons for file types was based on the idea that bitmaps are far less likely to "collide" than text, and 2**64 (18 quadrillion, US = 18 thousand billion, commonwealth) is a larger search space than 2**15 (3 ASCII characters ~ 32,768) or 2**8 (254 "usable" one byte type codes). But, having Richard H. deal with allocating type ID's = static allocation blocks provides a neat answer to any possible namespace collisions, I think, and also provides for some great answers to other game-related issues. "System" settings can go in the static area... (e.g. PAL v. SECAM flag? Turn off sound effects?) "Per-Player" settings or "per-document" settings or whatever is appropriate go into individual files. And apps that handle files can, optionally, provide icons for their files. Plus, not that it matters greatly, but this is similar to the way files are handled on machines like the GCN that face the same division between ROM and storage. Actually, Supercat handled that case by giving a 6-byte user-visible application string in the static allocation area, and an additional (but optional) expanded application info area for a user-visible file icon at 8×7px and what amounts to an entire splash screen bitmap. Hopefully, whether using some common library like MC_FILER or "home-grown" routines specific to one particular game, when a list of "foreign" or "all" files is shown to the user, the 6-char type (at least) will be displayed, and preferably, also the icon (at least the 8×7 version). Reviewing the old [stella]list discussions ... not to trivialize the thought that went into it, but: I doubt anyone is really going to do Huffman coding on filenames and such, and even having a filename could be meaningless in many cases. Paul Slocum's & Supercat's idea of type bytes + optional filenames seem fair. If we could come to an agreement on allowing variable-length filenames with either zero byte termination or high bit set on last character, that'd be great. The amount of work required to support such a scheme is pretty minimal, and different carts can choose to participate at various levels of compliance (just types, types+6char id's, types+id's+full app info), based on how critical file management is, how much ROM space the app can spare, &c.

I don't know, I've got about 12 diff games that use it. All of them except Final Fantasy, to good advantage. Luckily GBA's are about $10 at GameStop, so I just bought a bunch.

No, there's no serial port. Nor can you use it as a GBA for head-to-head games.

There's a very nice, extremely configurable, painfully high learning curve program called "Emacs" on MacOSX too. It's textual, runs in the terminal, and supports so many functions that many people joke that it's not just a text editor, it's an operating system of its own right. (Examples: code editing, building, compiling, eMail, www, newsgroups, games, desktop publishing, &c.) Plus it can talk, which is always a great way to annoy roommates. Incidentally, versions of Emacs run on practically every computer around, and it's what Atari used to ship with their devkits on the Atari ST. The earliest known copy seems to date back to 1954 :-) However, I wouldn't call it an "easy" app until/unless you've already learned how to use Emacs, but there is an online tutorial built in as well.

OK. Seems like the various "conformance levels" of Supercat's proposal work well. One further minor caveat: To ensure that we see application strings in the static area only when they're real: let's ask for the first 5 bytes of the app name to be ASCII7, the 6th byte ASCII7 & $80 (high bit set), just like filenames. If the high bits aren't 0,0,0,0,0,1, then we assume it's not an app ID string. Static allocation blocks are statically allocated. The "Scratchpad" area is available to the running app but its contents are not guaranteed to be meaningful between executions. File area blocks have a leading type byte. If there is a static allocation block matching the type byte, it's checked for a 6 character type data. Programs that just want to save small amounts of data can request a static allocation ID from Richard H, to guarantee no collisions. Programs that just want to work with their own type of files, e.g. bB, just look for their type byte. They may, or may not, register a static block with an application type ID. Programs that want to have a more "Unix-like" filer can write a metadata block with ID $00. This week, time permitting, I'm planning to throw together a standard library for these functions which I've named MC_FILER. Here's the planned API: At compile-time, to use MC_FILER, set MC_LEVEL=MC_FILE, or MC_FILES and include "mc_filer.s" For MC_FILE and MC_FILES, the same basic rules apply. The application should define MC_FILENAME as either a RAM area of 8 bytes, or a ROM pointer if the filename is fixed. In addition, an active file# temp location will be tracked. MC_SEARCH locates a filetype/name combo somewhere in the file area, and leaves it selected as the "active file." The search routine can be instructed to search for matching types and/or names based on some kind of flags (probably bits 6&7 of .a), and can be given a maximum filename length limit. EG: For CiE to find "native" files, it'll search for type $C7 (for example) and the user's name as filename; to find all available CiE files, we'd only care about type $C7; for all files on the MemCard, we just want the next block that's neither app data ($00) nor unallocated/scratched ($ff). MC_READ and MC_WRITE copy from file to arbitrary RAM offsets, or from arbitrary RAM/ROM ranges to the file. There's no reason that MC_READ/MC_WRITE wouldn't work with expanded RAM on a cartridge, either. MC_WRITE can be used to change the type or filename of a file. MC_SEEK selects a block in the file area to be the active block. MC_CREATE allocates a new file. If the conformance level is MC_FILES then the MC_CREATE routine will also confirm the existence of, or create if necessary, an application data block with its contents copied from MC_APP_DATA in ROM. MC_INFO attempts to locate information about the active file, for example, after an MC_SEARCH. If the type byte of the active file block is $00, the type returned will be "MEMCRD". If the type byte is $ff, then "EMPTY ". Otherwise, the type string will be set to "$xx " - the hex type byte, and the static area will be checked. If the static area returns the proper high bit pattern, it will be copied into the type RAM (with the final high bit cleared). Finally, if the type is other than $00 or $ff, the file area will be searched for a matching application data block (type $00). That block will remain selected as the active file for MC_READ. If it's not found, carry will be set and an error returned in .a indicating that while the type string was found, the application data block (DESKTOP DB anyone? ) was not found. This function is only available for MC_FILES level, saving some ROM for MC_FILE level apps. MC_SCRATCH removes the current active file by writing 9 $ff's to the start of the active file block. To scratch a file by name, ergo, do MC_SEARCH first! Error conditions will be reported by setting carry and loading .a with an error code number, e.g. "MC_ENOFILE" or similar. If full error reporting is overkill for a particular app, the app can define a macro MC_ERRBRK to "brk" or "jmp (someplace)". The macro must be defined before include "mc_filer.s". MC_ERRBRK will not affect the following errors (they will always be returned in 'c and .a): memcard not found, file not found, and (for MC_INFO) application data block not found. (For example, in the production build of CiE, I'll probably use To support custom screens during I/O, the routines will periodically jsr MC_WAIT_SCREEN, which should return control during the vertical blanking interval and mustn't mess with the RIOT timer. Anyone wanting to access the static or scratchpad areas can just use the existing low-level drivers.

Yes, but depending on the speed of the serial access, you might need to do some vblanks during the search. Search (n) blocks, vblank, search (n) blocks...

I'll try to dig up those archives tomorrow. I didn't notice such postings on a quick Googling, just the "first 8 bytes as filename" suggestion in the SDK docs, which leaves the file type collision issue wide open. Do you know by any chance approximately when the discussions were made?

Only downside I might see is that it makes it rougher to identify specific savegame data from another game if the area were to get full. Ideally, games shouldn't be deleting one another's data, but realistically, as with e.g. the GCN, we have a disparity between game ROM and secondary storage. It's quite plausible to have e.g. a borrowed game's data "stuck" on a MemCard "forever" if there's no way to delete "foreign" data. Since CiE is such a huge beast and I've got a bit of space to dedicate to a file manager, having the ability to delete arbitrary files would be nice. (Carefully buried on the OPTIONS menu with a default to "NO" on the confirmation, of course.) With no "filename" identifiers, the only info I can show will be the icon and app name. That should suffice for most purposes, though, since if the player has the cart that created the file, s/he can use that card to browse the files and delete them singly using some more meaningful ID: player name, or whatever. EG: Browsing CiE files from the CiE cart will show the player's filename or user name entered when they saved. If s/he finds an arbitrary file of type "METROD" and doesn't have access to a "METROD" tape to discover something more useful about that particular file, then deleting it "sight unseen" isn't really going to hurt anyone. I'll hold off until the week-end at least before coding up anything, in case there are further refinements on the above, but I do like the plan. I'll see about creating some standard routines for accessing files using that structure, post them here, and submit them upstream to the AVox SDK.

8B was intended to allow a user-visible icon, but certainly is overkill. Realistically, one byte is probably all that's absolutely needed; I don't forsee 255 (plus $ff=deleted) different games needing file space. ...wouldn't the tempvars for MemCard access require 16B of temp RAM at least (including at least 8B for filename and 8B for the various other tempvars)?

A European charger would have the same voltage on the side connected to the GBA, so you should be able to pick one up from an European gaming store. Barring that, a good ol' 240/50 -> 120/60 converter is about $20 at an electronics shop.

For "CiE," we'll likely be allowing multiple user "files" to be stored on one MemCard. Apparently the file area has never been used before, so I have a proposal to structure the blocks somewhat to prevent collisions between programs. Creating a directory structure and the like may be overkill, but here's the general idea I'm working from: Each pair of 64B blocks is "ganged" into a single 128B "file." Each "file" block begins with 8 bytes of "file type" data, followed by 8 bytes of "file name" data, in 7-bit ASCII, padded with blanks (hex $20). Valid filename characters are ASCII A-Z, 0-9, "-" (minus/hyphen), and $20/space. Other characters may or may not be supported. Bytes 0 and 8 (the first and ninth byte, the first filetype and first filename byte) are both $ff if the block is available. Each program that supports user-named files should have basically the same actions: 1. To CREATE a file, scan from the start of the file area until finding a block where bytes 0 & 8 are both $ff, then write out an 8-byte, fixed, filetype code, and the 8-byte filename. 2. To WRITE a file, look for the 16 bytes file type + file name and then write over it. Files taking more than 112 data bytes should write the same 16B header on each subsequent file block they use, so that other "dumb" software needn't know about it. 3. To DELETE a file, same. Blanking out (to $ff) bytes 0 through 8 is preferred, i.e. writing 9 "blank" bytes. If deleting a multiblock file, every block with the same file type and file name should be deleted. 4. To READ a file, same game, but keep reading for 128B. 5. To SEARCH for a file, scan the first 16B of every 128B file block. The 8-byte file type should be treated as an 8×8 bitmap in "player" format. Programs accessing the MemCard may display the bitmap for each file type. For example: CiE's main menu might have a DELETE FILE (or, in NES terms, ELIMINATION MODE) entry. CiE doesn't need to know about the file structure of various other games, but it can display the icon and file name on the deletion menu or list. This provides some verification of file types, so CiE won't accidentally try to load data saved by another app. It also allows files with the same names, but different types. Given that most Atari games are likely to only use initials, or short (4, 6, 8 byte) player names, odds are good that one person will use the same filename for every game. Having a dozen files named "BRPOCOCK" on one MemCard won't be a problem in this situation. Sticking to a limited character range will make it more likely that filenames can display in various games. Perhaps games with restricted fonts (i.e. not full ASCII 7bit font ranges, i.e. most games) should display any character not present in their font as some "identifiable" character meaning "other character I can't draw" -- e.g. a hollow box should be fairly doable, even in a 3px × 5px font... @@@ @[email protected] @[email protected] @[email protected] @@@ So, my questions: Any comments, suggestions, improvements on the above? European users in particular: is being stuck with A-Z too unbearable? Are there a very few additional characters that are absolutely necessary? I don't speak the languages, but I gather ø and ß might be necessary? Is it necessary to distinguish between I and 1, O and 0, Z and 2, and S and 5, or should we just store those using their numeric forms since most 2600 games aren't going to distinguish between them on screen? Is anyone else even planning to use the named file area or should I just run wild? EDIT: $ff for blank blocks, not $00 as I'd initially written; and fixed typo, 112B of each 128B would be free after 16B header.

I'm getting a MemCard for the project, so MemCard/AVox support will be definitely included. Special thanks to Richard H.!

In programmer's perspectives, it's a console if it doesn't have read-write storage (cassette, floppies, hard disc) and a keyboard, so yes... Besides, the Game Gear and the SEGA Master System are practically identical.

vague attempt at Zelda continuity: Minish Cap is the earliest, Link gets hooked on green hats Four Sword next (in various versions), the Four Sword becomes the Master Sword Ocarina of Time Majorca's Mask (either during or after Ocarina) A Link To The Past Link's Awakening, Oracles? Wind Waker The Legend Of Zelda Adventure of Link