brpocock

...as for the general discussion about biz plans and such, which I can't say I'm paticularly interested in... Nintendo's already said their hope is to make this everybody's second system. Let Sony v. MicroSoft continue, but the unique capabilities (and low price) they hope will encourage people to also buy the Wii. Myself, I'm preordering.

The prior announcement was: GCN games use the GCN controller ports on the side (under a door), as well as regular GCN memory cards. Revolution Wii games and use the wand and a different memory card type, probably/possibly a standard type such as SD cards. NES games use the "wand" held sideways. They haven't (afaik) clearly said what will become of SNES or N64 games. A few N64 games have already been ported to run on GCN (e.g. Ocarina of Time without any major issues, so they could easily use that emulator.

Yet, millions of people insist on driving poorly-built (imho) import cars with "Killed In Action" stamped on the hood.

It's been a long time a-coming but something "clicked" in my head Friday and I managed to get the above entry (lovely grid pattern that's stable) drawing. The idiots at the cable company have somehow managed to fry my connection at the moment, so I may have to burn a CD-R and sneakernet it to a Panera to get anything uploaded. The biggest fallout is that I've gone from a "2lk" format for the tile artwork (as shown in the yellow photo) to a "3lk" format for the playfield, with a "2lk" format on the sprite overlays (not shown). Moving around a few details, that makes fora 24-scanline-tall row. I might be able to afford one extra branch-and-test after the 12th row to reduce the ROM footprint. I'm also contemplating the evil but fun option of splitting the kernel between ROM banks: i.e. having the ROM data for different parts of the map in different banks with a bank switch occuring within the kernel itself. It'd save a lot of ROM, and is just nutty enough that it might work. The ill-defined concept would go something like this: the tile maps (which tile art goes on which spaces on the display) and the tile bitmaps for the upper 12 scanlines (4 logical lines) are stored in bank (n), with the kernel code to draw the upper 12 scanlines. After the 12th scanline, though, the kernel does a bankswitch and continues the 13th line (line 12) in bank (n+1) where we have the bitmap data for the lower halves (4 logical lines) of each tile. The breakthrough that made this possible? Pre-OR'ing tiles. The compiler now handles arranging every used combination of tiles in advance. More work for the PC compiling the game... less work in realtime. And, not a bad overall impact on slated ROM sizes. Travel test kernels for your viewing pleasure coming shortly. PS: the screenshow appears below not above on this blog format. Or just click on Saturday's date on the calendar. It's totally unimpressive.

Details a-comin' ... but ... at long last ... It's late and it's Cinco de Mayo. More to follow.

Thanks! Perfect answer. Cheap and known-to-work is a good combination. I'll just have to re-invest when we start working on the 128kiB sequel... (kidding!)

ASAP

Care to share?!? I wouldn't be able to use it as is - but it would give me some insight on automating the conversion of Nathan's artwork for the Dragon in Medieval Mayhem. OK, here we go. BIG post :-) Here's the HTML manuals for asm2pod, mkart, mkconverse, mkfont1, and mkmap: tools.manuals.html.zip The Perl scripts, plus "wrap" that I use to capture build output: tools.zip General infos: asm2pod extracts Perl-style POD documentation from .s files, so you can use POD inside of assembler comments to generate text, HTML, LaTeX, and PDF documentation. mkart converts certain PNG black-and-white artworks into data for CiE or other games. mkconverse compiles Ursa scripts into a symbolic form that the assembler likes, including transcoding the text strings. This is probably only useful for CiE. Not all opcodes are supported yet. mkfont1 creates the "pre-rotated" form of a font. mkmap compiles CiE-type map data. Probably only useful for CiE. Some of the limitations of the mapping format and such may be inaccurate in the manual... I keep changing stuff around faster than I can keep track of some days wrap is just a little command to simultaneously echo output to a log file and the terminal so I can review the output of a "make" later more easily. It laos prints pretty little rows of hyphens and stars so I can tell where one command begins and ends. I once had a CBM assembler that did that ... ah, nostalgia. All of these are subject to ongoing mutilation, but they are functional now. Sample Makefile rules: gen/font1.s: include/font.s tools/mkfont1 $< > [email protected] gen/%.png: art/%.v.png convert $< -flip [email protected] gen/%.s: art/%.png tools/mkart $< > [email protected] gen/%.s: game/%.con tools/mkconverse $< > [email protected] gen/%.s: game/%.map tools/mkmap $< > [email protected] I'm using gen as the "generated files" folder (so I can blow away gen/* in make clean. In particular note how I have gen/image.s from art/image.png, and then do an include "gen/image.s" from the appropriate memory bank(s) to pull in the data. The object file then needs to depend on the gen/image.s file to trigger an automatic build. Likewise, the map and conversation/script files need to have dependencies and includes set up for them. I think I broke the MENU code in mkconverse today too, am toying with changing to allow variable-length screens rather than fixed four lines displays, but that feature may be dropped. Mac kids may need/want to grab some Mac ports via e.g. (?)Frisk(?) kit (I forget the name... I run Linux on my Macs...) ... MicroSoft users will need CygWin. Quick PS: The order of characters in the mkconverse manual is braindead-wrong. The correct order should be: 0 2 4 6 8 10 1 3 5 7 9 11 Also, the documentation indicates to "see below" regarding lines storage. I forgot to write that section. In brief: Lines are referenced in a "string table" of 12-byte lines. If the same line occurs twice, it's stored once. So, for example, given the two texts: TALK MY NAME IS GEORGE. HOW ARE YOU? TALK MY NAME IS SUSAN. HOW ARE YOU? The lines table might contain (in twisted notation): GEORGE HOW ARE MY NAME IS SUSAN YOU? PPS. I also just noticed some profanity in the output source code. O:) oops.

Not necessarily. In this case, it's quite large, but by virtue of being larger, is faster. Only half-joking about it being an "18 line kernel" -- the loop is unrolled specifically to "work around" the lack of registers and avoid a lot of branch/conditional logic. All the conditional logic is handled in M4. Manually. The M4 macros are not really any different than using the built-in macro capabilities of the assembler, I just (a) don't know dasm-specific syntax well enough or (b) perhaps it isn't capable of doing the level of complexity I need; I don't know which, in either case, M4 works fine for the task. Here's to hoping that we meet the schedule ... knock on wood... So far, so good, although some of the "would be nice" features have been already completed and some of the critical features have slipped. It is a living entity and the real world does trump it unfortunately. M4 is doing code generation... it's no worse than any assembler's macro package, really. I think I posted some code snippets showing it before? Perl is just doing conversion of scripts, maps, and artwork (PNG to raw bitmaps), freeing me up from hand-converting all of that. In particular, I'm not storing text as ASCII -- in order to look up font glyphs more easily I have them in strange order ("0123456789abcdef" at the beginning to make printing numbers in decimal for display easier, and in hex for debugging), some characters are double-width (e.g. "m") and are stored as two parts ("m-left/m-right"), and some glyphs are re-used ("o" and "0" use the same glyph, so there's "no o" in the font, e.g.) to save font space It's all to reduce human labour ... I'd really hate to do the macro unroll by hand but I'd absolutely dread how error-prone it would be to code all the text manually. Sorry to have been so silent on the boards here. The code is running, but there are lines still "over" (too many cycles expended) in the main map kernel. That causes line skips and would on a real TV probably cause rolling. It sure pisses Stella off. I may have to drop one of the colour transitions I was hoping to keep. Stella doesn't seem to like 64kiB binaries. I'm testing as though it were 32kiB, but will need to work around that once the real game data starts going in. At last report from Mayday most of maps were done and some of the artwork for the maps. The test engine is just displaying "static" type patterns right now. By M2 hope to have the display stabilized. If nothing else I may drop to monochrome for a while and come back to that problem :-( Presently focusing efforts on combat engine. Conversation/script engine is doing OK, but no big surprises there, it's basically a 12 column text routine with a little script interpreter tacked onto it and some only-slightly-strange text encoding (mentioned above). As promised, once the core is stabilized I'll be posting here like a proud papa... It'll be a pre-alpha still but I just want to see a grid on the display at this point. Not sure if we were clear but milestones are code tests not game tests so will not include playable game data as Mayday doesn't want to spoil the storyline with partially-functional/buggy/whatever releases, which I agree... no different than perhaps the nonplayable "kernel tests" most of y'all are used-to, though. Incidentally, anyone recommend an EPROM burner that's easy to work with on Linux (Intel or PowerPC) systems? I know nothing about such things but it's beginning to look like that's going to be a necessity to test the full 64kiB tape once we get up to the alpha stage. Silly/minor point of pride, ... no sprite flicker. Dunno if that's good or bad, as it does mean I'm using playfield registers for most of the artwork. Regards to (Paul? Someone?) mentioning the tiny RAM as an issue with RPG: yes... we're mostly using bit-wide flags for stuff. I think the "player RAM" area is like 20 bytes? (still subject to change a bit) I do "steal" some MemCard memory (in theory -- the driver code is still a no-op) to store info only useful when using the MemCard (e.g. player's save game "file" name), and have a "big" chunk of memory that's remapped depending on which mode the tape is in (combat, script/conversation, travel/map, or some of the minor modes like teaser, MemCard/AVox access, &c.). As for the insane degree of hubris to tackle this, well, the list of "nifty things I should have done but it's too late to tack on, now" is growing. The H*R-RPG-demo in particular impressed me with the "smooth" scrolling of the world where we jump by screens; the newer MMUs like 4a50 and so forth, RAM/flash on cart, ... 'Nuff said for now, just wanted to touch base lest anyone fear the project was slipping or shelved or so on.

[aside: yay for the new compose window on AtariAge, this doesn't suck!] Here's the goals for Milestone 1, i.e. the Milestone 1 image should be able to pass these tests. Testing for M1: Cartridge starts up to Conversation mode * Conversation: displays text correctly * Conversation: handles menu selections * Conversation: passes some basic self-tests written in Ursa ... * Combat: displays appropriate number and type of baddies, and player HP, and MP * Combat: user can select "flee" to return to map * Travel: displays map without shearing * Travel: joystick moves player around * Travel: player armour colour determined by defense value or atkdef value * Travel: hitting special square triggers Conversation, which in turn may trigger Combat * Travel->Conversation->Combat transition must be able to happen with no visible screen roll (fast enough to happen during VBLANK) Of these goals, I can already tell I'll be deferring: - Player colour changes, we haven't nailed down the colours for this, so the player armour will just be a random colour - Some special overlay tiles may not be visible/used in this demo as a "cheat" to optimize the kernel in time Both of these should get bumped to M2. FYI, M2: Stats kernel up and running, able to display statistics screens * BRK handler (for debugging!) able to display crash dumps * Combat is able to equip items, and exchange "hits" with monsters. HP are handled correctly and both monsters and the player can die. * Random combat sequences can occur from the Travel map. * At least 20% of maps completed and work correctly. * All conversations/Ursa Scripts complete for those map areas * At least 20% of monster definitions completed (including art, HP/MP) * Game SELECT and RESET logic works * Game DIFFICULTY switches work * Game "save code" and "enter code to continue" logic works 100%. So, add to that colour fixes, special tile overlays, and the MemCard support. Edit: OOPS, I already added AtariVox/MemCard under M3. M3: * 80% of maps * All Ursa for those maps * 80% of monsters * Game can be won * If possible, introduce save-game support for memory device(s) e.g. AtariVox or similar. * Attraction mode kernel 100% functional * "You win!" animation kernel 100% functional Alpha release 100% of maps, scripts, and monsters * Game appears complete and playable to both of us * Post binary, documentation, and source (without conversations, art, nor maps; just raw code) to AtariAge. * Initial "Digital Press Kit" information posted on WWW * Discuss publication requirements with AtariAge * "How to Play" and "Story" manuals 100% complete (text) and layout "mostly" complete (but subject to editing). * Begin translations. * FEATURE HARD FREEZE. * String freeze on English version, including manuals. * Minimum 3 week duration (to allow sufficient outside time for testing) Beta release * Close all open bugs from Alpha release * 100% translation. * All printed materials in publication-ready PDF forms * Theoretical "perfect" release * Exhaustive playtesting in various emulators as well as on actual hardware. * Minimum 3 week duration (to allow sufficient outside time for testing) * Self Test script made difficult to access Final release * Close any bugs opened during Beta release * Delivery Theoretical schedule: M1: March, M2: April, M3: May, Alpha: July, Beta: August, Final: October (This is my way of distracting y'all from the fact that I haven't uploaded a working cartridge image yet because the games I get paid for are keeping me too busy as yet. However, that kind of slippage was built in to the above schedule.) PS: Anybody wanting to use the engine to do their own games, since we'll be dumping the sourcecode LPGL-style later on... drop me a message, as I may get you in on the build system now. The more designers who are looking at the build system early on here, the better the odds that it'll be flexible and robus and all that good stuff. Just don't expect Ursa to be Perl... it's about --->| |<--- that far away from assembler.

Status Report: Fighting real life schedules to wrap up the M1. Was hoping to have it to the debugging point already, but no such luck. Family business, romance, and work all cut into my hobby time Similar general status as before. In case any confusion, the Milestone 1 is only to demonstrate some code, it's not a playable demo per se. It's basically a test harness for the kernels at this point. There'll be something to look at, though. Rough figures: Combat system: 10% Conversation system (display/input): 95% Travel kernel: 85% Scripting ("Ursa") interpreter: 100% functional for 75% of commands (and no code for the others at all yet) ... but handles about 95% of scripts I expect to be needed/wanted I think all of the compiler-related code (m4 macros, Makefile, PNG-to-artwork compiler, Ursa script tokenizer, map compiler) are 100% complete, but there are undoubtedly some bugs in them somewhere. Will post M1 ASAP... hopefully entering a somewhat calm period including the weekend coming up.

Basically, all the loop controls are done up front, by the precompiler. There are no compares within each 18-line-set. The playfield is only 4 PF registers wide, to free up some cycles. All the "compare" type work is performed by the m4 macro processor before the assembler ever sees the code. The "spare" cycles, such as they are, are spread out within each 18 line "row" to perform different functions. For example, tile bitmap data is looked up and OR'ed on both the odd and even scanlines of a pair in today's version (still over the cycle count, dammit) ... So e.g. I refer to the pairs of scanlines as "0o" (zero odd) and "0e" (zero even) running 0e .. 8o; during lines 0e and 0o I precache the bitmap data for line 1. So, it's a 2lk wrapped in a 9-pair-"loop" that's completely unrolled with numerous special cases happening on each of the 18 lines. Without the macro preprocessor I'd be totally lost. And the data structures involved are insane, organized in ways no sane human would ever do, so I have Perl jobs that convert and precompute the bitmap data and such, in order to do things like pre-rotating left-side and right-side OR'ed bitmap data, splitting it out into tables with strange memory skip spaces to make the register usage lower, and things like that. For example, map data is stored with the left and right sides of the screen (playfield and asymmetric playfield) in different memory areas, with the even columns first then odd columns, so something like a b c d e f g h i j k l m n o p ... is stored more like: a c b d i k j l ... e g f h m o n p ... Text is similarly split... THIS TEXT... T I _ E T ... H S T X ... Some genius could probably have done this in '76, but it would have taken a dog's age to do all the data mangling and code editing by hand. [EDIT: not that I by any means claim to be a genius, I would never have taken this on "by hand," I'm letting Perl and M4 do that crap for me :-)]

Slightly off-topic: I've a friend who somehow had a small cockroach crawl into the modem jack on his PowerBook and lay eggs. Little tiny baby roaches popping out of every opening on that thing for ages. And what can you do? Don't exactly want to disassemble the thing and hose it down with Raid...

At the moment, I'm cramming trying to prove that wrong The travel kernel is, in fact, tile-based. There are some strange limitations (for example, I can't possibly decode tiles and change playfield colours as often as I'd like, so there are horizontal "blocks" of tiles sharing common colours), but basically, yes, it's tile-based. Tile bitmaps are 4×9, "four-colour" images, on an 8×10 tile grid. That does, sadly, leave the screen looking a little letterboxed on the sides. (180 scanlines, only using the four center playfield registers.) The "18lk" basically does the decoding "interleaved" between various scanlines. There is a small amount of RAM used to precache the "next" playfield register values, but mostly I just try to stay one scanline ahead of the raster. The "excess" cycles on each row are needed to do things like colour decoding and sprites. By unrolling the kernel, I can do different things on each scanline without the extra cost of a compare-and-branch operation after each scanline. That cost only occurs every 18 scanlines. I also don't have to have a set of logical tests like "if the current scanline (within the tile row) is (n), then do (x)." Those tests are performed by the m4 macro preprocessor. Here's a snippet of the source. At this point, $1 is which pair of scanlines (0.. on the tile row, and $2 is 0 or 1 for whether we're on the "even or odd," the first or second scanline of the pair. ;; prefetch colour data in rows 7e,7o,8e and 2o,3e,3o if $1 == 7 && $2 == 0 PREFETCH_COLOUR(pfc_left_next, tile_colours_lower) endif if $1 == 7 && $2 == 1 PREFETCH_COLOUR(pfc_mid_next, tile_colours_lower) endif if $1 == 8 && $2 == 0 PREFETCH_COLOUR(pfc_right_next, tile_colours_lower) endif if $1 == 2 && $2 == 1 PREFETCH_COLOUR(pfc_left_next, tile_colours_upper) endif if $1 == 3 && $2 == 0 PREFETCH_COLOUR(pfc_mid_next, tile_colours_upper) endif if $1 == 3 && $2 == 1 PREFETCH_COLOUR(pfc_right_next, tile_colours_upper) endif ;; this must happen after PF1/right has been drawn if [ [ $1 == 8 && $2 == 1 ] || [ $1 == 4 && $2 == 0 ] ] ;; promote cached colours lda pfc_left_next sta pfc_left lda pfc_mid_next sta pfc_mid lda pfc_right_next sta pfc_right endif At last count (from memory) I have about 2 lines out of every 18 that are "over" by 6 cycles, still, and at least 4 lines that aren't meeting the playfield register update timings -- i.e. they change the PF2 too soon or too late. But those numbers fluctuate regularly as I try different things. I'm afraid I'm wont to just compile and count on something this complex The worst limitation of the travel kernel, imho, is that only the player sprite can move "freely," and at that, not entirely smoothly. At the moment, other sprites are stuck in place because of some really really nasty baroque HMOVE crap I do to position them. See, I can't afford to just "sleep and whack" the horizontal position register, so sprites are positioned basically by HMOVE relative to the row before. Sprites in the travel screen are basically just used for variety against the lowres playfield bitmaps, though, so it's not a huge loss.

Incidentally... I'm not really doing it in this game, but there should be the impression that I am to the player due to a moderately large number of boolean "did (x) happen?" flags. But you definitely can't bake bread.

10-key entry is used all sorts of places. I carry around a 10-key keypad for my laptop because of how often I want to do so (and a 12" iBook has a kinda lame one). It's still one of the basic clerical skills.

Uh....I think you are overcrediting Ultima. Verb object pairing? I don't think so. 3D mazes? Again, I don't think so. The vocabulary was established by several text games way before ultima. And also, whats the difference between 'a menu basis' and 'keypress selections'? Isn't that what a menu is? 1021324[/snapback] Not the concepts, the mechanics. First implementations of the basic infrastructure. But the original Ultima games had one memorize the 26 letter keys' associated verbs, versus the later NES practice of onscreen menus. Edit/PS: Meaning that on the NES one might e.g. press (B) and see four or five verbs listed instead of just hitting a non-existent letter key on the keyboard. Of course, CiE will have to do it NES-style, with on-screen displays. Similar contrast to early King's Quest or similar graphical "text adventures" versus later ones with a fixed set of 5 or 10 verb icons to adapt to mouse pointer. Fairly certain. Akalabeth might not have (I'll have to check sometime when an Apple II is unboxed again) but Ultima I did a faux-3D first-person, a la 2600 Skeleton.

Well, Ultima (or properly, Akalabeth, "Ultima 0") did "invent" graphical maps, first-person 3D mazes, the variant on the DND stats system, Verb-Object pairing, inventory management, and most of the other stuff we take for granted today. It basically established the "vocabulary" for all the games that were to come after it. The biggest donation that consoles had to that vocabulary was shifting to a menu basis rather than using keypress selections. The thing that impresses me most about the Ultima series, in fact. Every tenet of society is functional. Playing with Exult, you can actually leave the little "ship in a bottle" running for months or years of virtual time and the characters will act out their bottled lives, baking bread, eating meals, going to work, and whatever else they need to do, all in a more or less accurate simulation of daily life. I guess it's like a SCA version of "The Sims" in that respect.

For the record, last week consisted of (a) personal "business" of the soap operatic variety (b) finishing moving in to my new place © wiring up 26 of the more important videogames and computers and last but not least (d) working until 4am on the "9 to 5" "day job" shipping some critical videogames Unfortunately, my only AtariAge-related time was trying out Starfire on my hardware for the first time. It looks at least twice as good as on a PC monitor. The "bleed" effect on the radar actually had me thinking the TV cable had slipped for a second. But, fear not, three of the four of those things were built in to my schedule. And my soap opera, well, *sigh.* The game will get done on time

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

I get paid to do what I was doing, anyways. Not a lot of people who get paid for their hobbies.

What version of Stella are you using? And is the USB controller you'rs using a "standard USB joystick device," or does it require some kind of drivers? I just plug in the joystick before clicking the ROMfile and it picks it up automatically.

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

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. 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. 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. 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. That is realistic, if you skip the serial EEPROM idea and keep to standard banked flash-rom together with RAM. 1013994[/snapback] To save anyone joining in late in the game some reading, here would be a dream board for doing something like RPG's or other "huge" games... 4k addressing space split into 4×1k "bank slots" Each bank slot individually selected from either 256k ROM or 16k RAM... or more of either... Ideally, programmer just stores a (1k-based) address into a 16b latch register, presumbaly hidden under traditional bankswitching "trigger" addresses (e.g. under F7 method). Since it seems we're into FPGA turf, ideally, have something like four 16b registers, each controlling one banking slot, triggering the switch after the high byte has been written (assuming low byte, high byte ordering). While (initially) we'd onyl have the 256k ROM and 16k RAM, this would potentially allow 64M of addressable storage, in 1k chunks. (2**16×1k) As a fair alternative, use four pairs of latch registers, one each for ROM and RAM. Write a (1k-based) ROM address to a latch to engage a the related ROM into that slot, write to the other latch to select a RAM bank into the same slot. However, if the "magic writes" (RAM that can be accessed read-write using a single addressing range) can't be used, then instead RAM banks should automatically be switched based on 512B boundaries, with read and write regions to fill the 1k slot. If at all possible, leaving a space to slip in a serial EPROM or other persistent storage, like the AVox/MemCard -- or a smaller one, or something like that -- would be a great option to have, even if not all carts needed it. Based on the prior discussion, a $15 manufacturing cost seems to be the target area...

(/me dumped the hardware thread over to the hardware forum) Ah, that splains it, thanks !