brpocock
-
Content Count
304 -
Joined
-
Last visited
Posts posted by brpocock
-
-
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.
-
The number of active 2600 coders, using "active" loosely, is about 20-30.The number of homebrew games you are likely to sell is around 100-200, assuming you even complete this.
Given those numbers, your concerns seem a bit...ridiculous. You haven't used *any* code posted here, because of licensing concerns?
You're inventing problems that don't exist and then solving them with a sledgehammer.
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 :-)
-
The difference between GPL and LGPL is that GPL forces you to license your own code as GPL if you use GPL code with it. LGPL gives you more choice, by allowing you to use it witn non-GPL code as long as you make the LGPL source code and any changes to it available. (The "L" stands for "Library", such as the C runtime libraries.) This is why the GPL is referred to as a "viral" license. The GPL enforces Richard Stallman's political views about software freedom upon the rest of the world, while the LGPL gives users the freedom to keep their own code private.Then there is the BSD-style license which does not require any re-distribution of any source code, only acknowledgement of where you got it from.
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.
-
1)You appear to want to use J0 and J1 as both output strobes to the controller and inputs back from the controller, unless you incorporate some controlling mechanism such as a bidirectional tristate buffer
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.
-
-
A couple of things regarding color schemes:First, who in the world actually uses SECAM anymore?
France, and North Africa... but, yes, it's an even smaller subset of an already tiny "market."
Very few, if any, homebrews have been released that support SECAM and I have never seen any requests for SECAM support.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.
-
GPL? You might read this: http://www.atariage.com/forums/index.php?s...54entry838654I 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.
And this looks pretty cool, though I'll wait to see anything before getting too excited. Or before getting excited at all.
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...
-
-
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.
-
Aha!
I heard this thread existed.
It's quite possible to connect custom controllers, as in, gutted and rewired, using a fairly simple "addressing" protocol. Whether it would be worthwhile to support such controllers in a game is left as an exercise to the reader...
http://www.atariage.com/forums/index.php?showtopic=82461&hl=
In point of fact, something like the 7800 controllers could be scanned using an adapter to move the sense lines around on the controller port. That'd be a simple "dongle," basically two DB-9 ports wired up to sort out the lines. I haven't gutted any SMS controllers, but the rumour is that NES controllers use a serial communications protocol that would probably require a decoder chip to create such an adapter.
A PIC / FPGA could probably make an NES, Genesis, &c. controller use the above addressing protocol, but perhaps some of the electronics gods on this site could do it cheaper?
(Thanks to MayDay for pointing me at this thread!)
-
Yeah, unfortunately, I'm actually using them for Difficulty :-)
I also probably lack ROM space to have three palettes :-/ but I might ... we'll see. Might have to resort to a menu option for palette corrections. (NTSC, PAL, SECAM = B&W)
I started to say, "four palettes," but note that each SECAM colour has a fixed luminance and they're all different, so SECAM screens are "usable" as B&W screens, theoretically.
-
I heard a rumour this was being discussed elsewheres, but I couldn't find the forum topic ... so please excuse me if I'm repeating something here.
The question was, "how could one pack a modern-like game pad onto a 2600's controller port?"
And my suggestion:
This is working from the model of a Game Cube controller, with the exception of entire inability to actually use that physical device -- just one with the same controls.
Those controls are, basically:
* Basic pushbuttons: A, B, X, Y, and (on the shoulder) Z
* Analogue shoulder switches: L, R
* Analogue sticks: D-stick and C-stick
* Digital joystick cross: D +
* Rumble pack activation: pulse the rumble core "up" or "down"
To distinguish the analogue stick from the D+ I'll call it just "the stick."
Well, suppose you could gut a GCN gamepad and remove all its electronics. The current electronics are based on a smart serial design that would be a royal pain in the ass to link up to poor Stella.
Now, we take four joystick lines (Up/Down/Left/Right, let's call them j0,j1,j2,j3 because I don't have the pinouts handy) and wire them up so that we can read them as inputs.
At startup, we remain in "2600 original mode" until we see a signal on "j3." In "original mode" we take the D+ and feed it back into the j0..j3 lines, the A button goes to Fire, and the stick feeds the two paddle controls.
If we detect that both paddle ports are scanned at the same time as j0..j2 are low and j3 is high, we enter the "enhanced mode." From then, on, we treat j0..j2 as addressing lines whenever j3 is high.
The software brings up j0..j3 together, where j3 is always 1 to indicate "select." j0..j1 address keys as follows:
j1 j0 j0 j1 j2 j3 fire p0 p1 0 0 --------------- D+ --------------- A D-stick H&V 0 1 B X Y Z START L R 1 0 B X Y Z A C-stick H&V 1 1 B X Y Z A D-stick H&V
The strange-looking arrangements with buttons repeating is meant to make it easier for software to scan more frequently-used keys together. For example, the "00" setting is good for current Atari games, but the "11" setting scans the most important keys for typical GCN games. Scanning the "START" button only on alternate frames, for example, would be valid.
Once j3 returns to 0, the "selected" controls should remain connected until j3 is brought back to 1 by the Atari. That's particularly important for reading the analogue controls.
j2 could then be used to select a second gamepad on the same controller port, making the 2600 the equal of the GCN (four gamepads), or, use j2 to select Rumble functions: e.g. while j2=1, swing the rumble device's state based on the value of j1, so, to make it shake, send a series of signals such as: [j3,j2,j1] = [1,1,1], [1,1,0], [1,1,1], [1,1,0] ... with appropriate timing intervals.
Unfortunately, I don't remember enough logic gate magic to think of how to construct the encoder for this type of selection logic cheaply, and I haven't actually unscrewed a GCN controller to see if its components are even remotely plausibly decoded this way (or if they're too complex or tightly integrated or whatever). However, the same general principle should work for any modern controller type, in general, i.e. remapping the controls using output address select logic.
Notable exception is the Xbox, since all of its buttons are analogue and would require hellish amount of circuitry to convert to digital, I imagine (or produce rather flaky button signals). But N64, or in particular Duo (PS1/2) controllers should be fairly easily mapped this way.
As for NES, SNES, Genesis, and the like, the wiring and logic are easier since there are no analogue circuits:
NES: A = fire j0 j0 j1 j2 j3 0 ------------ D+ ---------------- 1 Start Select A B SNES: A = fire j1 j0 j0 j1 j2 j3 0 0 ------------ D+ ---------------- 0 1 Start Select L R 1 0 X Y Start B 1 1 X Y A B Genesis: B = fire j0 j0 j1 j2 j3 0 ------------ D+ ---------------- 1 Start A B C Saturn: B = fire j1 j0 j0 j1 j2 j3 0 0 ------------ D+ ---------------- 0 1 Start A B C 1 0 Start X Y Z Jaguar: j2 j1 j0 j0 j1 j2 j3 fire 0 0 0 ------------ D+ ---------------- A 0 0 1 B C Pause Option A 1 0 0 KP9 KP6 KP3 KP+ A 1 0 1 KP8 KP5 KP2 KP. A 1 1 0 KP7 KP4 KP1 KP0 A
Duo controllers (PS/2) are similar to GCN but harder to type "triangle" so I'll leave that as an exercise to the reader.
Note that, in particular, the "B" button is the usual "fire" button on Sega controllers. (e.g. on the Genesis controller there's even a "tab" on it like the ones on home row -- F and J for US/Qwerty -- on your keyboard.) Since these controllers have far fewer keys, leaving the "fire" button always available just makes the decoding logic easier. Duplicating them on the digital scan inputs (e.g. compare modes "00" and "11" on the SNES) might make some programming tasks easier, though, since the digital input lines are read from a distinct location cv. the fire button signal.
Any rate, that's our collective 2¢ on the subject...
[EDIT: HERESY! I didn't include Jaguar. Of course, I've never actually seen a Jaguar in person either :-(]
-
Ultima.
To be particularly impressed, some time, download Exult (an alternate engine for the Ultima VII data) and use its "cheat" keys to scroll the view around, away from the player.
Even when you're not there, everyone goes about their lives, walking to work, eating meals, doing whatever they're supposed to be doing.
Of course, so do the dragons and bat in Adventure...
-
You can't measure INTIM vs. WSYNC because they both measure time in clocks, not the actual time. If there ever will be a detection scheme, it will be helped along by hardware. The PAL 2600's clock runs around 1% slower than NTSC, so an accurate crystal on the board with some logic and some very precise software help might make this possible.Ah, that's what I was afraid of.
It's that 1% I was hoping to somehow detect, that there might be some slight drift, but bah.
The "good thing" is that SECAM seems to have the switch permanently in BW position (wired shut) so it's only an inconvenience to PAL users. Assuming that NTSC users all have colour TV's in 2006...
Thanks, though :-)
-
Seems like this must have come up before, but I didn't find it on Stella lists or the forums here...
The basic difference between NTSC and PAL is the refresh rate and VBLANK interval. If game timing based on "real time clock" rather than "number of screen draws," one cart should be able to work for both consoles, with the requisite colour variations, right?
That said, is there a way to determine at runtime the system being used? For example by comparing INTIM against WSYNC or similar?
For my current [and first real] project, I'd like to support PAL hardware on the same cartridge as NTSC, but at the moment my only idea is to scan the COLOR/BW switch and treat it as COLOR=NTSC/BW=PAL,SECAM...
-
My take on the label. As you can see, it's a coleco style label, but using their boxes as a template...I also took the coleco name off of the label, since it's not related to Coleco in any way...I made a similar label for my copy of Looping, which is in a spare 2600 coleco case I had lying around...looks pretty cool...IANAL, but, showing the arcade cabinet probably passes as "confusingly similar" with regards to trademark law. (Implies that whoever holds the rights to the arcade franchise these days had in some way authorized this version.) Also, even though the name "Ladybug" is available, the cabinet design is copyrighted, not trademarked, ergo it won't expire for about 75 years (from now). And, Coleco is still a viable trademark, ergo, the owners could get nasty.
Luckily, the 2600's gfx and sfx are poor enough to (unless someone is really really seriously angry) avoid violating the videogame copyright (which includes artwork and sound fx), but the copyright on the design of the packaging, including titles with unique fonts, arcade cabinets, manuals, and so forth, are all protected by copyright which generally lasts at least 100 years from the publication date.
As far as using a similar graphic for the title as the arcade version, it's a coin toss between trademark (which often expires after a relatively short period) and copyright. If the owners claim that you directly photographically duplicated the artwork, it violates copyright.
If, on the other hand, it's reproduced in a "similar" (but slightly different) way, even if it's intentionally similar, it comes down to a matter of "confusing" the potential buyer into thinking that the original owner (Coleco, &c.) are in some way related to the new product. Think about e.g. the various public domain stories that Disney makes movies from, e.g. The Hunchback of Notre Dame. When some little league art company makes their own direct-to-DVD version of the story, they may have some characters who look similar to the Disney versions, even have a similar title font, but they're careful that someone seeing their box wouldn't think it is the Disney version.
The short of it is, sticking Ladybug on there in similar typeface is great, but the cabinet is potentially treading on dangerous grounds.
-
D'oh, stupid me.
They're absent on the pure 6502 and the 6507, of course.
My cheatsheet on the wall has 65c02 opcodes and I didn't notice the asterisk. Sorry.
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Ladybug - 2600
in Homebrew Discussion
Posted · Edited by brpocock
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")