Urchlay

Hm, I've never noticed any difference... but that'll give me an excuse to hook up the 5200 and try it again

Not 100% guaranteed. On some TVs, you can fix the rolling by adjusting the V-hold. I've got a 1976 Mitsubishi TV that doesn't even need that. It's an NTSC TV, but it can handle most PAL 2600 games without rolling, and without adjusting anything. Even if you manage to get a non-rolling picture, the colors will still be wrong. The game should still be playable, though. Also, if you've got a TV capture card in your PC, it should support PAL, so you could play the game that way (display it on your PC monitor). In that case, the colors will be correct (I guess for PAL, you have to call them "colours"). How much is this PAL HERO cart? $5? More? Loose or boxed? I'd take a chance on it, myself. Even if you never get it working, it'll be an interesting piece for your collection... or you could trade it for something else.

Last time I played 5200 Defender, I lasted 4 hours... didn't notice any problem moving to the right. I had just finished calibrating the controller (mechanical calibration, moving the plastic stops inside the stick), and 4 hours of play didn't break it. I had to get used to centering the stick myself, but that only took a couple of minutes... Defender on the Atari 8-bit computer was probably the second game I ever owned, so I played a lot of it. From what I can tell, the 5200 version is identical (except the controllers of course), so you might try the 8-bit version if you're able. If you're playing in MAME, you might try a trakball (the kind replaces your mouse). I use a Kensington Expert Mouse trakball... I assign its Y axis to move the ship vertically, one mouse button for thrust, and the other for reverse (the buttons are under your pinky and thumb). Ctrl on the keyboard fires lasers, the space bar is the smart bomb, and the third mouse button is hyperspace (harder to reach, but doesn't matter since I never use it). The X axis on the trakball does nothing. With this setup, you fly the ship with one hand and control the weapons with the other. I got pretty good at playing this way, a couple years ago. The same setup might work OK with a regular mouse, I've never tried it.

How about: lda v bpl .foundabs eor #$ff clc; not needed if the state of C is known up front adc #1; would be "adc #0", if C is known to be set .foundabs Not much of an improvement, but it does run 1 cycle faster if v is negative (or 3, if you can leave out the CLC). Reading over this thread, I can see that I need to learn how to use the illegal/undocumented opcodes. About the only ones I've ever used are DCP and some of the extended NOPs (e.g. to sleep for 3 cycles).

The 50/100V is the maximum voltage that the part can handle... The Atari power supply is only 5 volts, so either one would be fine.

Thanks for the tips! I've been using pretty generic paint, mistake #1. Also I was trying to cover the whole thing in the first coat, mistake #2... I've got about 300 old keyboards and computers in storage, no shortage of practice material. Some of them are so ugly that even a botched paint job would look better than they do now.

Hmm... cmp #1 adc #255 lp: lsr bcc lp Should do an early exit (NZ) in the A=0 case. Nice! Now it's elegant.

This isn't up to TJ's standards, but I just thought of another solution in the shower: ; destructively test to see if the accumulator is a power of two ; on exit, A is trashed, X and Y are preserved, and Z is set if A was a power of two is_a_power_of_2: subroutine; { cmp #0; Test for special case A==0 bne .loop adc #1; another "CLZ" rts ; All powers of two have only one bit set! .loop; { ; This loop terminates when we find a set bit lsr bcc .loop ; } rts; If we found a set bit, the Z flag will be set if that was the *only* set bit ; } That would actually be kind of elegant, if it weren't for the need to test for the special A==0 case

The return value should really be in a flag, so you can immediately use a branch instruction afterwards... otherwise you'll need something like "cmp #0" in the caller. How about: ; Warning: untested code! is_x_power_of_2:; convenience entry point: checks X instead of location v stx v .byte $2C; aka BIT absolute opcode, skips the "sta v" below is_a_power_of_2:; convenience entry point: checks accumulator instead of location v sta v ; Main entry point: is_v_power_of_2: subroutine; { lda v bne .main lda #1; Special case: return with Z flag false, if v==0 rts .main; v is known to be non-zero, here dec v and v; accumulator now contains 0 if v is a power of 2 (Z flag is set correctly, but "inc v" is about to destroy it) ; If you don't care about preserving v, you can comment out both these lines: inc v cmp #0; set Z flag true if a==0, or false otherwise (needed because "inc v" trashes the Z flag) .done rts ; } It's not so "killer" any more, but it's easy to use: ldx $whatever; get a byte from somewhere stx v jsr is_v_power_of_2; Was it a power of 2? beq yes_it_was; yep! ; no, do whatever here... ;; Alternatively: lda $whatever; or, A could be the result of some calculations jsr is_a_power_of_2 beq yes_it_was Also, since you're only dealing with an 8-bit byte, you can just brute-force it: ; Return Z=true if A is a power of two, or Z=false if it isn't ; Uses no RAM, preserves A/X/Y, trashes flags is_a_power_of_2: subroutine; { cmp #1 beq .yes cmp #2 beq .yes cmp #4 beq .yes cmp #8 beq .yes cmp #16 beq .yes cmp #32 beq .yes cmp #64 beq .yes cmp #128 beq .yes ; if none of the compares are true, Z ends up being false .yes; if any of the compares are true, Z is true when we branch here ; Either way, just return it. rts ; } Converting the brute-force method to a loop... which will be slower than the original: is_a_power_of_2: subroutine; { ldx #1 stx tmp .loop; { cmp tmp beq .done; return with Z=true asl tmp bne .loop ; } ; original: lda #1; return with Z=false (too bad there's no CLZ in 6502-speak) ; EDIT: ldx #1; return with Z=false, preserving the value of A .done rts ; } However, TJ is probably about to post something that blows all this code away

I vote for the 6-switch (heavy or light sixer)... unless you're really interested in Atari 7800 games too, in which case you should get a 7800 (which will play 2600 games, too). The nice thing about the 6 switch 2600s is that you can easily look and see what the difficulty switches are set to, because they're on the front panel, and they're clearly labelled. On a 4-switch, they're in the back of the console, and the labels are molded into the plastic, but not painted (so they're raised black letters on a black background, very hard to see). I'll always consider the 6-switch design to be the "real" Atari VCS... though I'm not a fanatic about the heavy vs. light difference. On the other hand, I've got ehhh... four 4-switchers (including a Sears Tele-games), two light sixers, a Sears Video Arcade II, and three 7800s. Also I have a Gemini console (2600 clone, by Coleco), and the ColecoVision 2600 adaptor (but no working ColecoVision to plug it in to). Oddly, I've never owned a 2600jr, even though I think they're kind of cool... If you're more interested in playing games than collecting, you should get a 7800 and look for a Cuttle Cart II. That'll let you download thousands of ROMs, stick them on a memory card, and play them on the 7800 (but not a 2600) by choosing from a menu... unfortunately the CC2 is no longer being produced, so you'd be buying a used one. Still, I highly recommend it.

Why not, very stealth I don't know if I could get all those keys off the keyboard without breaking anything... also the keyboard layout on an Atari is non-standard enough that I'd go crazy if I couldn't look and see the key labels, so I couldn't just spray them black, I'd have to put white decals or something on them (no way would I attempt to actually paint letters/numbers/etc on there by hand!) On good PC keyboard (IBM Model M), I don't need the key labels... in fact, they come off (they're separate pieces from the actual keys), and I taught myself how to touch type by removing all the caps from my good keyboard (leaving only plain grey keys). I cussed a lot for the first 2 weeks, but after a month I was able to touch type with 99.9% accuracy at maybe 60 words/minute. The down side of this is that I have a hard time adapting to any other keyboard (like the Atari ones)...

Long description: http://en.wikipedia.org/wiki/Parity_%28telecommunication%29 Short version: An 8th bit that's added to a 7-bit byte, so that the number of 1 bits comes out to an even number (even parity) or to an odd number (odd parity). Used to detect errors on a serial line: the sender sends bytes with correct parity, and the receiver calculates what the parity bit should be... and if they're different, the receiver knows the data got garbled during transmission.

Where do you work, and are they hiring?!

Hm, every time I've tried to spray-paint a plastic computer case, I end up with bits of it flaking off for months... what kind of paint do you use to get it to "stick" to the plastic? Do you have to rough up the plastic with sandpaper or something before spraying? I dream of owning an all-black XEGS (well, except I wouldn't try to paint the keys on the keyboard)...

The back cover of the book "De Re Atari" has something similar. There's a web version here: http://www.atariarchives.org/dere/programmerscard.php That page has the whole thing as HTML, and also scans of the original in GIF format. Very handy... Though I actually bought the book (B&C has them in stock, brand new).

Holy crap, *that* is a killer hack! 10 cycles if v was 0, and 63 cycles if it was $FF (worst case)... in 10 bytes of code! Also, your version is optimized for lower numbers... the execution time depends on where the most significant set bit is, instead of the number of set bits like the Kernighan version (so your version is faster for $0F than it would be for $F0, even though both have 4 bits set). If I were wearing a hat, I'd take it off to you

A while ago, I wrote this bit of code to calculate even/odd parity. It could probably stand some improvement... I definitely don't consider it a "killer hack": it's coded for clarity more than speed or size, but it does implement something from the bithack page, so I thought someone might be interested. ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ; calc_parity will calculate even or odd parity for the low 7 bits of A, ; sets the high bit and N flag to the result. ; Input: ; A = data to calculate parity for (bit 7 ignored) ; C = carry set for odd parity, clear for even ; X, Y, other flags: ignored ; Output: ; A = data with correct parity bit in bit 7 (bits 0-6 unchanged) ; N = parity bit (same as A bit 7) ; C = parity bit (same as A bit 7 and N) ; Z = 1 if A is 0, or 0 otherwise ; X = 0 ; Y = bits 0-6 of input ; tmp = same as Y ; Memory usage: One byte at tmp. No stack used. ; If desired, the routine could easily be modified to preserve the ; Y register (and use another RAM temp instead). ; Execution time: Constant, 108 cycles, +6 for RTS. Add 10 cycles if tmp is ; not located in zero page. ; Code size: 25 bytes, +1 for RTS (+4 if tmp not zero page) ; Code: calc_parity: subroutine;{ and #$7F ; 2; throw away top bit (it will get replaced anyway) sta tmp ; 3; copy in tmp will be repeatedly shifted (destroyed), tay ; 2; so stash another copy in Y lda #0 ; 2; init accumulator: rol ; 2; A=1 if C was set, otherwise A=0 ldx #7 ; 2 ; =13 (+1 if tmp not ZP) ; { .loop ; loop executes 7 times... lsr tmp ; 5 adc #0 ; 2 dex ; 2 bne .loop; 3 ; =12*7-1 = 83, +7 if tmp not ZP ; } ; A now has count of set bits from bits 0-6 of the original argument, ; plus 1 if C flag was initially set. ; Bit 0 of A will be the new parity bit. ror ; 2; C = bit 0 of A lda #0 ; 2 ror ; 2; bit 7 of A = C, bits 0-6 are 0 sty tmp ; 3 ora tmp ; 3 ; =12 (+2 if tmp not ZP) rts ; 6 ;} BTW, the comments with the curly braces (lines like "; }") are a Stupid Editor Trick: My editor lets me jump from an opening { to a closing } quickly (very handy for C or Java code), so I've gotten in the habit of using them in 6502 asm code for easy navigation. I use Vim, and I know Emacs has support for this, too. I'd bet that any halfway decent code editor or IDE supports it, too. I've also got a vim macro that selects the current block of code (from the { to the }), for cut/copy or applying other commands. I just press F2 to highlight... and I've got F1 bound to a macro that comments out the block (or uncomments it, if it's already commented). Who says vi is hard to use?

The EOR trick still uses RAM (locations a and b).

I'll take a stab at it... Execution time for your version is 11 cycles if v is 0, or 5+n*23-1 cycles if v is not zero (where n is the number of bits set in v). Average time (4 bits set in input) is 96 cycles. One obvious improvement would be to use the X register instead of memory location c. Use "ldx #0" to initialize (saves 3 cycles, assuming "c" was a zero page address), and "inx" instead of "inc c" (saves 3 cycles per set bit in v). Also the code gets 2 bytes smaller. Of course, if you already had written a lot of code that used this as a subroutine, all that code would have to change (to look for the result in X instead of c). Depending on how the calling code used the result, you might end up losing a lot more than the 2 bytes you've saved. Another improvement would be to move the Loop label down two lines (below the "beq Done")... You only need to do "lda v : beq Done" once, before the first loop iteration (to catch the special case where the initial value of v is zero). At the end of the loop, you're making this check again (the "bne Loop")... if this branch is taken (back to Loop), it's redundant to check v for zero again (you're guaranteed it's not, since you just took the "bne Loop" branch). This will save you 4 cycles per set bit in v, and it won't break compatibility with (hypothetical) existing code that calls the routine, either. (It will add 4 constant cycles before the loop, though) Applying both improvements (X register and moving the label) would save 7 cycles per loop iteration, which is a 30% speedup (of just the loop)... not bad. Code looks like: ;--count set bits in v ; trashes v, accumulator, result is in X register ldx #0 lda v beq Done Loop inx dec v and v sta v bne Loop Done Timing is 8 cycles if v is 0, or 7+16*n-1 if v is not 0... Average case (4 bits set in input) is 70 cycles, 28% faster than the original, assuming I've gotten all the numbers right (if not, I apologize). Total code size is 15 bytes (3 bytes smaller than the original). However, there are a couple of other ways to count set bits that are faster at the expense of more code. I was messing around with this a while back, and came up with 5 other solutions (I never came up with the Kernighan method on my own, though). Here are a couple of them: ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ; Count the number of set bits in A ; Unrolled version ; Result in A ; Uses one byte of RAM at tmp (preferably ZP) ; On exit: X and Y untouched, C/Z/N undefined ; Code size: 36 bytes (+1 for RTS = 37) ; Execution time: Constant, 5+(7*8) = 61 cycles (+6 for RTS = 67) countbits_3: sta tmp; 3 lda #0 ; 2 rol tmp; 5 adc #0 ; 2 rol tmp; 5 adc #0 ; 2 rol tmp; 5 adc #0 ; 2 rol tmp; 5 adc #0 ; 2 rol tmp; 5 adc #0 ; 2 rol tmp; 5 adc #0 ; 2 rol tmp; 5 adc #0 ; 2 rol tmp; 5 adc #0 ; 2 rts ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ; Count the number of set bits in A ; Nybble table version ; Result in A ; Uses one byte of RAM at tmp (preferably ZP) ; Execution time: Constant, 35 cycles (+6 for RTS) ; Code size: 17 bytes table + 19 bytes code = 36 bytes (+1 for RTS = 37) ; This is faster than the fully-unrolled version, ; but it trashes all the registers and flags. Could use PHA/PLA instead of ; TAY/TYA, to preserve the Y register, at the expense of 2 cycles. nyb_bits: byte 0, 1, 1, 2, 1, 2, 2, 3, 1, 2, 2, 3, 2, 3, 3, 4 countbits_4: tay ; 2 and #$0F ; 3 tax ; 2 lda nyb_bits,x; 4 sta tmp ; 3 tya ; 2 lsr ; 2 lsr ; 2 lsr ; 2 lsr ; 2 tax ; 2 lda nyb_bits,x; 4 clc ; 2 adc tmp ; 3 rts ; 6 Neither of these is all that original. The unrolled version is obvious to any 6502'er, and the nybble-table idea came from some code I saw either here or on the [stella] list (I couldn't find the original code, so I rewrote it from scratch). Here's one I came up with on my own. It's not all that fast, but I like it because it fits in 11 bytes of code and doesn't use a temp location in RAM. Also, if I added a ROL before the RTS, the accumulator and carry flag would keep their original values, which might simplify things for the calling code. ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ; Count the number of set bits in A ; Result in Y ; Uses no RAM ; On exit: ; Y = result, X = 0, A = undefined, C = undefined, Z = 1, N = 0 ; Min execution time (input $00, 0 bits set): ; 4+(2+3+2+3)*8-1 = 83 cycles ; Avg execution time (input $AA, 4 bits set): ; 4+(2+3+2+3)*4+(2+2+2+2+3)*4-1 = 87 cycles ; Max execution time (input $FF, 8 bits set): ; 4+(2+2+2+2+3)*8-1 = 91 cycles ; (add 6 cycles for RTS to all 3 counts) ; Code size: 11 bytes (+1 for RTS = 12) countbits_2: ldx #8; 2 ldy #0; 2 cb2loop rol ; 2 bcc cb2_noiny; 2/3 iny ; 2 cb2_noiny dex ; 2 bne cb2loop ; 3 ; rol; adding this ROL preserves the original values of A and C (and sets Z and N according to the A value) rts; 6

Thanks! Would it just be a copy of the original 2.3 release, or would the re-release for the Construction Set be different? If it's the same as the original, you should be able to snag it from the Holmes archive link above (same link repeated here: http://www.langesite.com/atari/Holmes/Holm...ting%20Systems/ )

Those are some pretty good game ideas, but... I'm pretty sure someone's already done this...? The tricky part of doing 2600-like mockups in a modern language is that you'll get tempted to break the rules (too many players on one line, or too many variables/arrays/etc that wouldn't fit in a real 2600's 128 bytes of RAM). Nothing wrong with that, unless your intention is to really port the game to the 2600 later. I'd say you should first write a simple game on the 2600 for the experience you'll get, if you haven't already.

Zip them first, the forum software will allow a zip file

The article doesn't go into much detail, it just says they're making "gaming PCs"... Are they just going to be Commodore-branded Windows PCs, or something more Amiga-like? (Probably a dumb question... even Apple is making Wintel PCs now...)

Any chance of this being posted as a zip file or such? The board software destroys the formatting, so it'd need some work to be able to actually assemble the source...

Take it apart, clean all the contacts you can get to. At least clean the cart port and keyboard cable contacts... also, reseat any socketed ICs (careful not to bend any pins, though). The RAM is on a removable board, clean its contacts and reseat it, too. 99% of the problems with old machines can be fixed this way. Also it's possible that the keyboard is bad, not just dirty... B&C Computervisions or Best Electronics should have a replacement (maybe even an aftermarket one with full-stroke keys instead of a membrane). It may even be possible to fix a bad 400 keyboard, but I have no idea whether it's even possible to take one apart.