brpocock

CBM CPU's: KIM: 6501 and 6502. The 6501 was "too close" to the M6800 so it never(?) got marketed to the general public because of Motorola lawsuits. PET's: Mostly 6502 (but there were a LOT of different PET variants, so I wouldn't doubt some variations) VIC-20: 6502 C=64: 6510 = 6502 + on-board 8-bit I/O port C=128: 8502 + Z80A. The 8502 is a 6502 souped up to share the bus 3 ways with the VIC-II (video coprocessor) and the Z80A, or to run at 2MHz with just the 8502 and Zilog chips (VIC-II disabled), using the "EGA-compatible" display only. (The left screen goes blank in 2MHz mode) I think the C=16 and its more popular bastard offspring the Plus/4 were actually using the 65c02 chip? Amiga, M68k. 68020 and 68040 versions I've heard, but I don't know which Amiga models had which. Apple: Apple II, IIplus were definitely both 6502. IIe might have varied depending on the model? IIc seems to always be the 65c02. IIgs was the 65816, the 6502 + 16-bit modes. Nintendo: NES: 6502 SNES: 65816 Gameboy: Z80 or Z80A? GBA: Z80 for compatibility, ARM7 for native mode NDS: ARM7 for GBA mode, ARM7+ARM9 both in native mode N64: R4300 GCN: PowerPC 750e Sears: My parents' old Kenmore microwave had what I think was a 6505 CPU, but by the time I got there it was a bit skunky so it might have been 6503 or 6508. Definitely not 6502 though. PS: Sorry for any confusion. Yes, CBM == Commodore...

There are some pretty major problems with continuity *from one game to another* in the Zelda series. Wind Waker tried to sort out some of it, but a lot does not hold up to any rational scrutiny. Hell, there's still a lot of fan discussions about what "game world chronological order" the games occur in, although I think most people have decided that Ocarina is the earliest and the two NES games are the last... (EDIT: insert *fr...er*)

CBM owned MOS. The way I heard it (growing up in CBM-land) was that they did all the fab for all the 65xx CPU's themselves at first, then outsourced after one bankruptcy or another to e.g. W.D.

VCS for me. Although it was "the family machine," it's now got a spot on my games table. "My" first was a CBM SX-64 with a "lovely" built-in 3" CRT screen, so I would stop hogging the TV set.

Well, to be honest, each battle uses temporary RAM for the monsters you're fighting, but there's a very small bank of "persistent" RAM that hangs around after the battle's over. Basically, player stats and a bunch of "flag bits" for e.g. "player has learnt this spell" or "player has completed this task." 32k RAM. Yeesh, I'd not know what to do with all that Monsters and NPC's, of necessity, are not being "simulated" when the player isn't present. There's some kind of philosophical/physics statement there about parts of the world existing in a Schrödinger's Box until the player arrives, and then the state of the "persistent RAM" instantly snaps that region of the (game) universe into a deterministic state? EDIT/PS: This isn't too dissimilar from how e.g. Legend of Zelda for NES operates. Zelda has a lot more persistence, though, e.g. each screen keeps a count of the number of remaining monsters, but not what their status is. (Go to an overworld screen with two types of monsters on it... e.g. the desert with the flying things and the sand things. Kill all but one, leave, and return a couple of times. The computer won't remember which type of monster is left, just that there's only one. Kill the last monster and return, and it regenerates the original max#.) Even with more RAM, I'd probably want it more for precaching graphics data than simulating a large number of NPC's and monsters on every screen, however, the ability to track more persistent states -- like Zelda's "monster counts" -- would be useful. The other "problem" is that the entire persistent RAM area has to be able to be encoded in an alphabetic sequence for continuation codes. If I had a "dream cart," I'd want 1k RAM (bankable), 1k ROM (bankable), and 2k ROM (bankable) blocks, perhaps sacrificing a few ROM bytes for a serial EPROM like the MemCard. But ROM-only I know can be produced already, and to quote Steve Jobs, "Real artists ship."

I'd heard a ballpark figure of production costs of about $20 each for the 6507, TIA, and RIOT, but that there was a lot more set-up and design cost for the TIA, which ultimately was why the sale to Warner.

Right now they're boxed up. I'm in progress of moving. Once it's all set up again perhaps? It's probably a fluke thing with the type of battery that game used. The ROM-only ones are prolly in better shape?

I have a garage with AC and a locked door. Between games, systems, cabling ... that's just about enough room. (70+ machines ranging from the 2600 and Apple ][plus to the AMD x86_64...) Except the ones I'm playing recently, which are usually stacked in the living room. Regarding sealed games, specifically Zelda... I bought a Zelda/SNES (I think that one is Link to the Past, right?) in the box, and it didn't work ... turned out the battery leaks acid if it's not powered up periodically.

If the trademark really is expired (as seems to be the case) then calling the game Ladybug would prevent anyone from registering the trademark again. Not sure exactly what the procedure is for officially noting that you object to any future trademark registration under the name. 1008807[/snapback] The name itself is absolutely fair game. Original artwork, e.g. cabinet art, specific copy of the way the word "ladybug" was written (e.g. scanned photos), that sort of thing ... not so much. Crapshoot as to whether whoever currently holds that copyright decides to get pishy. The screen artwork should be safe since you're not precisely duplicating anything, just drawing a different representation of a ladybug and so forth. Simply using the name protects against future claims. Trademarks can't be applied retroactively. (EDIT: clarified "artwork")

Yeah, there is. But not as much as you might think. Since the game lends itself to having several discrete screens: conversation, combat, travel (map view), attraction, stats, save/load game, &c. -- the major screens each get their own bank(s). Major meaning "requires tons of data" -- e.g. travel views require fast access to map data, tile data (what colour is it? is it a wall? does it trigger a script to step here?), and tile bitmaps, which collectively suck down a lot of ROM space. Likewise, the script engine needs access to script data as well as string tables (for displaying conversations) and font bitmaps. Combat engine needs monster stats and bitmaps as well as scenery bitmap data. The minor screens get packed in where they fit: the attraction sequence, the player stats, the new game, enter code/load game, get code/save game, and so forth. The downside is that some code has to be duplicated in multiple banks, giving a painfully large overhead. Every bank containing travel (map) data, for example, needs a copy of the travel kernel. There's no way I can see to bankswitch fast enough and often enough to fetch data for multiple tiles per row, and no way to cache enough of it in 128B of RAM that has to be shared with player stats, game progress flags, and other "persistent" data. In a perfect universe where one could bankswitch 1k or 2k boundaries a more complex set-up with the kernel code packed into a certain 1k bank and the other 3k switched might work, but it's an edge case for custom elecronics for a niche product as it is. Plus, the emulators would hate it. No need to introduce that much complexity, it's complex enough as it is. Incidentally, the various kernels all share an overlapped area of RAM that's wiped by a common bankswitching subroutine. To go to another map or run a certain script or enter a certain combat mode, the registers get loaded with a bank ID and a "function ID" and the program does a jmp bank_switch . The identified bank gets swapped in and a common entry point there reads the function ID, which might select a map, a combat set-up, a script ID, or a specific screen (attraction, stats, ...) depending on which bank is selected. It's kinda like how CP/M & DOS use their registers to select a subfunction in INT handlers, if that makes sense to anyone. The shared RAM area gets zeroed during the switch (which happens during vblank interval) and in some cases (short scripts) a second switch could happen almost immediately, without the player seeing anything at all. (e.g. -- map triggers script which jumps to other map, say, a "tunnel" or similar ... the switch, script execution, switch again all happens during vblank so all player sees is map A in one refresh and map B in another.) So, from a certain perspective, the "64k game" will really only have like 48k or so of unique data, with some of the code ... and even some data (e.g. player bitmaps) duplicated in multiple banks just to avoid bankswitching too often.

This is what I do for a living, so worrying about licensing and milestones and build toolchains is par for the course. I'm just treating this like any other project. There's no real reason for me to treat this as a less significant project just because it's not going to be sold for mucho dinero. If anything, I'm being more careful with this project because it doesn't have a layer of corporate padding to check out all the licensing angles, and I'm in the USA where you're basically guilty until proven innocent if anyone decides to be a pain. I doubt anyone here would, but better safe than sorry, eh? But, seriously, the 2600 isn't so complex that one needs to copy others' code for e.g. initializing the machine states or enabling some fancy video overlay modes or ... And techniques aren't copyrighted. Hopefully nobody here was enough of an ass to go and try to patent the idea of e.g. redefining sprite data in between TIA updates or sommat. The tile-based kernel code is just over 10k lines (including lots of comments) even after m4's done preprocessing it. Before m4 expansion it's under 1,000 lines still. Easier to reinvent the wheel on a small project like this.

No, the game itself is just data in this case. The game engine just supports the data that you're designing. It doesn't include the artwork, music, sounds, maps, scripts, ... just the actual assembly-language code. So the game itself can't be sold. But, if someone wants to come along and spend a few months designing their own game using the toolchain I've developed, more power to them. On the other hand, if they find a bug or limitation in the engine ... say, find a way to crank out an extra colour change that I didn't find ... they have to share that improvement with me, you, God, and everybody, if they distribute the change. Also note that only people who legally obtain the binary have a right to the source. If the game is only sold via AtariAge, only people who buy it have a right to get the source code. But, as I said earlier, I'll probably just post the source on the www for everyone to share. That also applies to modifications. If someone were to modify the sources for their own use, only someone who legally obtained their binary would have a right to their sources.

Yes, feel free :-) However, we're only talking about license for the game engine. The game data -- art, maps, conversations, scripts -- will be licensed exclusively through AtariAge. But, you can use the engine and design your own game using it, and then sell that game data. Which is exactly the idea :-)

Well, "viral" is a real flamebait word, but I'll let that slide. The critical difference between GPL, LGPL, and BSD/X/MIT-style licenses is what someone who gets the code, can then do with it. GPL code is guaranteed to be free, forever. Any modifications must always remain GPL. However, non-GPL/LGPL code cannot be used with GPL code. LGPL code is also guaranteed to be free, forever, but can be mixed with non-GPL code to a greater extent. BSD/X/MIT licenses allow anyone to copy the code and use it without releasing their changes. The original objection to GPL Andrew T. made was that most projects are based on hacking existing projects, which means that you can't GPL them now unless they were in the public domain before, or were already GPL'ed, or one gets relicensing permission from every author whose work was included. On the other hand, unless the author explicitly released his work to the public domain, or under an open license like one of the above, it'd be illegal for me to include his (or her) work in my own without such a release, anyways. GPL'ing it is the safest for posterity. The only reason I can think of for LGPL'ing something would be if there were an existing body of open source works under a BSD/X/MIT or LPGL license, or under a proprietary license (meaning that it's not declared as GPL, LGPL, BSD/X/MIT, or explicitly placed in the public domain), that someone would want to combine bits and pieces. I gave bB as an example because it's proprietary, I believe. I didn't see any explicit license declaration, so by default, it's under standard copyright terms, and nobody but the author is permitted to modify it. If Batari wanted to copy the tile-based kernel, it'd have to be released to him by the author (myself), or placed under the LGPL. In order to protect the public from, e.g. me being hit by a bus, I could LGPL it to remove the onus of each potential future author contacting me to get my release. As far as, "freedom to keep their own code private," neither the GPL nor LGPL affect anyone's code but mine. The GPL simply does not give anyone the right to make changes to my code without also sharing those changes. But, neither does any license except BSD/X/MIT. Since 90% of the code people have posted here is not explicitly licensed, by default, none of it can be used ... so I haven't.

May be... there aren't a lot of useful things that can be done with variable-length irregularly-spaced gaps varying up to a max of about 30 bytes, not relative to the number of them that'll exist. EPROM support is a fairly big undertaking, but it's high on the priority list, right under the milestone requirements.

True. But nobody makes one... Adapting a Genesis controller to four digital buttons and an analogue stick might be a nice simple dongle solution. A few resistors to convert the stick, yes? Downside: no way to support both the standard joystick and such a beast.

Yes, that's more or less what I was pitching. I'm no electronics guru, but it's how the IEC port ("serial port" for discs and printers) works on CBM machines. Not without external power, I'd imagine.

Although, for reasons of ROM space limits, I'm 90% sure we won't be supporting the AVox for speech I can't say I'm heartbroken about that, but I'm at least disappointed.

France, and North Africa... but, yes, it's an even smaller subset of an already tiny "market." True enough, but (not to sound sarcastic, not my intention) why limit oneself to what others are doing? It is, ultimately, a ridiculous undertaking to try to cram what is an (exceptionally pale) imitation of the Ultima format onto a 30-year-old console system that was designed to play Pong and Space Invaders. I do gather that most (nearly all) PAL games are playable, but just look silly... True, it's a silly extension. Ultimately, though, I'd liefer to have the extra support in there than to just waste the ROM space due to alignments. Hopefully not wasting too much of MayDay's time in picking colours from the other palettes in his artwork, but ... *shrug* Plus, dealing with conditional compilation of thousands of lines of code, much of it machine-generated, could be a nightmare, and it may end up being a nightmare that I have to go through still if I can't optimize the bloody kernel to run just a wee bit faster. (The map kernel itself now weighs in at 3,831 lines of assembly code total, plus lots of comments -- and that's just to draw the map screen, no setup, no input, ...) I think, though, probably the above are rationalizations, and I'd just feel heartbroken if there was something that the 2600 could do that it wasn't doing. The game might be perfectly playable with just big coloured blocks and a square "man," but pushing the machine is part of the reason for such things.

I understand the theory behind gut negative reactions to GPL, but the advantages are better. In this case, there's no CNP code, since (afaik) this has never been done before, so the only content from a third party is vcs.h, which is included with dasm, ergo excempt. The reason for GPL is practically the same reason as AA's programmers fora and the Stella list: to ensure that the source code must survive. Hopefully, in future, someone will find a new use for the program or its build utilities, and I don't want any potential problems with licensing to prevent him or her from building his(her) own game from the sources. More to the point, my day job is programming videogames, so I cannot release this unless it's GPL'ed without getting legal paperwork from my employer, because of the wording of my contract. My employer is kind enough that there's an "escape clause" for GPL'ed (or LGPL'ed) projects. All of that being said: I may change my mind to LGPL to allow someone to link my code with CNP code from elsewhere that might be under a different license. However, the post you link to indicates a fundamental misunderstanding as to how copyright law (at least in USA) works. Including any source code from someone else (more than a few "trivial" lines... in 6502 assembly, that might be about 10 or 20 operations) requires a license -- source or binary. Something released with "no license" is automatically, "all rights reserved to the author or his(her) successor" which basically puts it off-limits if the author can't or won't sign a release. Placing something into the public domain might be "doable," but it does introduce a slew of other problems. Not that I plan to sue anyone for using my code or downloading a ROM image, but if I didn't put some kind of license there, anyone who did so would potentially face civil and criminal penalties under copyright law and the DMCA. I will take a closer look at LGPL as an option, though. That at least ought to protect legitimate (in my mind) uses such as yanking the map kernel and stuffing it into batariBasic or something. Naturally! I'm still tuning important things like the number of tiles and number of colour changes trying to get it all in, and to stabilize it so that each row takes precisely 76 cycles rather than varying from about 70 to a max of 90[!] right now, without running out of RAM for player stats. Right, switching is silly, but I'm concerned about production costs for the ROM's. And, it's easier (since every colour of every tile, sprite, ... has to be encoded twice) for my map compiler, tile data compiler, and so forth, if the three colours (NTSC, PAL, and SECAM=B&W) are written out at once. Once the time draws nearer I may reconsider and just code a build macro or something to produce two binaries, but NTSC and PAL versions still want 2 palettes (NTSC + B&W, PAL + SECAM=B&W), so there's very little complexity added other than selecting the number of lines to blank on the display. One extra compare/branch/load set during VBLANK is pretty trivial altogether... plus a 50% bloat in COLUM values. * In case that sounds silly, I didn't realize until late in the game that each SECAM colour has a different (fixed) luminance, so the SECAM palette can be used as the B&W palette for NTSC and PAL both. Since SECAM boxes have the SWCHB setting permanently set to read "B&W" and are otherwise basically PAL systems, that works out to getting PAL B&W for free and NTSC B&W just requires changing the number of scanlines and using the SECAM palette. It also means we -- and by "we" I mostly mean MayDay as he's doing the artwork -- don't have to worry about setting up four colours per colour block... The other reason is that certain tables (e.g. tile maps) have to be aligned certain ways (to avoid e.g. crossing page boundaries). The current estimation is to align maps on 128B boundaries (half-pages). This means that if the third palette were absent, there would be more "padding" and less "useful data" in the ROM, so there wouldn't be much savings. Individual test maps are running between 90..118 bytes with all three palettes, wasting up to 38B per map, but I'm experimenting to see how many tiles I can crank out of the drawing routine before I guarantee that format. The current working theory is 8 columns, 10 rows, with some horizontal "letterboxing" on the left and right because there isn't enough time to decode bitmaps for more than 8 tiles per row and still handle multicolour sprites and such.

Bruce-Robert Pocock and Jason D. "MayDay" are proud to announce the ongoing development of a the second* Atari 2600 Rôle-Playing Game. The project, code-named "CiE" for now, is a turn-based RPG and uses a menu-based combat and conversational engine and a tile-based map system for traveling through the game world. Perhaps unique among 2600 games (?), this game uses compiled scripts to drive Non-player character interactions and other gameworld events, allowing the game's designer to write high-level instructions for game events which are then interpreted at runtime. The language (in both source and binary forms) is nicknamed "Ursa." Source code for the game engine will be available under the GPL. Game data (art, sound, maps, and conversations) will not be included in the distribution to make it slightly more difficult to cheat. ROMs will be available for download. Pending acceptance of the final product by AtariAge, we intend to offer it to AtariAge for publication on cartridge with manuals. * (after Paul Slocum's HomeStar Runner game, also in progress) Working Title: CiE Designer, Maps, Scripts, and Digital Art: MayDay Programmer, and Documentation: BRPocock Build tools: dasm, m4, perl, NetPBM, gmake Source languages: 6502 assembly, about 75% generated by perl/m4 from source text files Target ROM budget: 64kiB Estimated size of game world: a total of over 30 maps. License: GNU GPL v2 (source code, program code); game data: free for personal use, to be exclusively licensed to AtariAge for commercial distribution. Some more detailed notes: Traveling through the world map is a tile-based engine similar to [a stripped to the bare metal version of] an RPG like Ultima, or Final Fantasy. Combat uses a joystick-driven menu system. Conversation is text-based, using a 12'ish characters per line system. The font system is actually semi-proportional... characters may be "narrow" or "wide," so e.g. "M" is wider than "I" but "I" and "A" are the same width. The game supports use of various weapons and magic spells, and has player stats for things like attack, defend, hit points, gold, and the like. Game save will be supported using a (rather painfully long ) "code entry" system. Support for AVox or similar memory devices is possible but not guaranteed. (In particular, depends on whether I get a hold of one before alpha test.) Joystick for general control. Color/B&W switch is abused to select NTSC or PAL/SECAM mode. Actual color/B&W or PAL/SECAM switching available from the main menu. Difficulty switches are being used for difficulty handicapping of the combat system. Game Select switch is used to pause the game and review player stats. Video TouchPad (as a second controller) will be supported as an alternative "hot key" system for making menu selections. Due to the script-based nature of the engine, translated versions for other Latin-alphabet languages (but, sorry, in ALL CAPS with no accented characters...) are possible in future. Tentative builds schedule Note: Milestone test releases will demonstrate various software behaviours but will not be using the actual game world data. You'll be able to walk around maps and talk to people but they'll be designed to stress various parts of the game engine and not so much to tell a story. Alpha test release will be in limited circulation with game world data. Beta test release will be posted to AA with game world data. Please be courteous about posting plot spoilers...! Milestone 1: March Milestone 2: April Milestone 3: May Alpha test: July Beta test: August Release: October Included in the digital release kit will be printer-ready PDF versions of the "How to Play" manual as well as a second "manual" describing the game world, a 64k binary, and the source code for the engine, allowing anyone (with access to a Mac or Linux machine) to write their own game using the engine without writing any kernel code. And, before anybody asks: No, I don't have a ROMfile or screenshots to post just yet. Code for Milestone 1 is still being tuned. For those of you who are programmers on "modern" systems: consider this: more than half of the ROM is being generated by Perl scripts, and the tile-based drawing kernel required more complex macro code than dasm could provide (or would have required so much cutting and pasting that I'd never find all the typos), so I've resorted to using m4 to preprocess the main drawing routine... which is, presently, running an average of about 80 cycles per scanline with sprites. The amazing cruelty to TIA that is the tile-based drawing code is perhaps best described as "an 18lk", because each group of 18 scanlines passes through 18 slightly-different iterations of an unrolled loop. However, the bitmaps are more-or-less 2 lines of resolution with various levels of colour detail depending on the type of object and where it appears on the map. The very moment that I get the display kernel stabilized I'll post something to the 2600 Programming forum here.

Thanks to Disney and MicroSoft (and Sonny Bono), copyright is automatic. Unless you have proof that you created something uniquely, you are in violation of copyright law as it stands today. Guilty until proven innocent. Such proof means: Source code; new artwork or music that differs (greater than 51%. Yes, that means 52% or more. Weird law) from the old; different text &c. ** Note that this is all US law. European law is quite similar but reserves more rights to authors, and less to publishers, and doesn't default to extending for centuries. As for "works entering the public domain:" as it now stands, the last published works to go into the public domain were in the 1920's. Unless someone has explicitly, in writing released a work to the public domain, it's copyrighted, and distributing it without authorization is illegal. There's some work (by lawyers) going on trying to create a new class of "abandonware," refering to works where there is no clear owner of copyright any more, but there isn't a legal concept of such as yet. So, if I pick up some novel from 1938 and decide I wanted to copy an illustration out of it, I have to find who claims ownership of that novel. Just because I can't find the person claiming ownership doesn't allow me to copy it. Which sucks, because the person who theoretically owns it might not even know it. Even if the author died intestate, the copyright might have reverted to an agent or publisher...

For the record ... yeah. Been there, gotten that C&D.

The current DS has one, too. I found it odd that they mentioned that. I think it's a change from 3 levels of brightness to 4? Reason to buy another DS: because nobody else I know has one and some of those multiplayer tapes look nifty.

True. Genesis, SMS, and 7800 controllers, in particular, could use a cheaper rewiring scheme to acheive similar results by mapping the additional buttons to the paddle lines, but this concept is regarding getting full addressibility of the digital controls. To contrast: Wiring up the Genesis controller with just a pair of DB-9 ports could leave D+ and B tied to the stick and FIRE digital inputs, and tie A and C to the paddle controls, ignoring START; or, use the second port to accept A, C, and START signals. Upside: this is just wire and jacks. Downside: you might lose START and make reading A and C difficult, or else lose the second controller port, and with it, any AtariVox option also. However... the "address decoding" scheme above would allow full, digital decoding (avoiding messing around with pot/caps) of all eight discrete signals from the Genesis controller. Downside: this requires a logic chip of some kind. Upside: it could work for two controllers (or maybe four) in one port, all digital signals remain digital (and potentially, analogue signals remain analogue), and it leaves the second port open for AtariVox, memory cards, and the like. Further upside: the controller logic is similar to the address banking logic used in cartridges, so I expect some folks around here know how to do it cheaply, perhaps without requiring a PIC or FPGA. If it does come to using a PIC/FPGA, though, any overhead could be used to support multiple similar controller types in one device. EG: A dongle with NES, SNES, and SMS/Genesis ports available. Similar dongles to accept various game pad devices and convert them to USB are commonly available for modern PC's.