brpocock

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

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

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.

Looks good, but minor correction: It's missing "inc .a" and "dec .a" opcodes. Not sure if they belong with "inc/dec" (RAM) or with "inx/iny/dex/dey" ...

My wishlist (things that waste too much ROM): stacks or queues. Can you do selectable LIFO/FIFO? I like stacks. In 6502'land we often count "down" rather than up because detecting zero is cheap, and stacks would be a nifty way to deal with that. A queue would work too, a stack would just be "nicer" Multiplication and division -- at least 8b × 8b => 16b? nybble flip. 0b11110000 => 0b00001111 for example; $f8 => $8f (Think of text or similar data into sprites or playfield. Yes, this can be done in 5 lines using bit rotation, but one bit at a time... vs lda (spritedata),y:sta rotate:lda rotated) I second the motion for binary <=> decimal and so forth. Sure, it can be done in lookup tables, but it can easily be non-addressable memory doing the work. That is: with a 4k address space, having to make the LUT's addressable is a "cost" in available address space. Agreed, most of the things requested can be done, but doing it faster is the goal, right?

Nope, didn't find anything, and haven't had the time to create something myself. I also found that I had some semi-contradictory desires on how to handle different labels. (Important, because labels are case sensitive in DASM.) 964844[/snapback] Did you decide on a method or find an utility? -- Be kind to wizards or you shall be replaced with a very small Perl script.

I don't know anything about the 7800's art formats, but point me at some specs and I'll get you a PNG-to-7800 converter. NetPBM and Perl are your friends.

For Linux/Unix users (or those with access to a Linux/Unix box) the following Perl script can handle conversion of 8px, 16px, 20px, or 40px wide monochrome PNG's (white and black only, sorry...) into dasm-compatible data listings. The artwork is stored top-down, though, so if you reverse your scanlines to count down, you'll want to flip the images vertically to match. It sorts pixels in the PNG based on brightness, drawing in black and white is recommended for reliable results though. Just for human readability it also adds comments with "undumped" copies of the artwork. I use Gimp to draw out the artwork and keep the .png's in the project directory for editing, and then use a rule like this in my Makefile: gen/%.s: art/%.png tools/mkart $< > $@ obj/art.o: src/art.s gen/something.s gen/somethingelse.s gen/anotherthing.s $(AS) src/art.s -oobj/art.o ...and then have "art.s" as nothing but: seg rom org $f800; or whatever include "../gen/something.s" include "../gen/somethingelse.s" include "../gen/anotherthing.s" It's probably overkill for the 2600 but it means I never have to worry about the ROM image coming out with different artwork than I last doodled in Gimp, since Make will take care of it all for me. I have half a mind that I should be generating the "src/art.s" file and the Makefile rule for it automatically, but I haven't been doing that yet. In fact... I'm still working on my first real and true project. (I'm a strong believer in making the computer do as much work for me as possible)

Slightly (perhaps) better than reaching for a second joystick... is the Select switch... Which, of course, would require making it active for Game Select purposes only when the game is not actually being played. Just 2¢ from the peanut gallery...