supercat

I think I may have you all beat; about 12-15 years ago, I saw a company using a punched card sorter. Those things are pretty amazing; the cards move so fast one can't actually see the individual cards flowing through the machine. Instead one sees a blur of flying cards as the source stack gets shorter and the output stacks get bigger. I don't know precisely what the company was doing with the cards, but it looked as though each card had a roughly 2"x2" hole in it within which was mounted some sort of optical film. I'm not sure how the company kept the films from getting scratched, but it did seem a somewhat clever use of an antiquated technology to manage physical films (I'm not sure what was actually on the films, but nowadays digital archiving would probably be more common).

I would aver that the problem is that many games require that the player have a number of buttons that can be operated by reflex, and controllers that had keypads, often did not have their other buttons well-placed for reflex operation. The paradigm used to be to have one hand hold the controller and operate buttons, while the other hand operates the joystick. This generally meant that there could only be two or three "reflex" buttons, and they'd have to be on the same side of the stick; unfortunately, many games tried to use the buttons on opposite sides of the stick for different functions. Today, the paradigm is to have both hands hold the controllers while fingers operate buttons and thumbs operate joysticks. With regard to the comments about the N64 controller requiring three hands, I would agree that it would be a lousy controller for any game which attempted to use all its features simultaneously. I would suggest, however, that it should not be viewed as a three-handed controller, but rather as two controllers in one: a modern Xbox-style controller (if one ignores the stuff in the middle), or an older-style held-by-one-hand controller (if one ignores the rear triggers and such, and doesn't try to do do many things at a time with the top). Sometimes I've thought it would be nice to design a controller with a keypad-ish touchscreen that had little transparent ribs on it to allow a number of operations to be done by 'feel'. That would seem especially useful for various types of sports or strategy games, allowing players to confidentially enter their plays with feedback they could see, but which other players could not. Of course, with the move away from using controllers at all, I'm not sure manufacturers will ever take advantage of the fact that cell phone screens have become amazingly cheap.

I wonder what the creators of Burgertime thought they'd be able to manage? It doesn't use anywhere near the whole 2K of RAM, but some testing I did would suggest that it would be possible for a kernel that did use that much RAM to draw fancy shapes with the missiles and the Ball, in much the same way that other M-Network games do. Getting a game working with such a kernel, including having getting all the necessary non-kernel stuff to fit in vblank, would be tough, though. I wonder if anyone was planning on using the extra RAM to produce fancier graphics than were in fact achievable.

The TIA outputs a 1.19MHz phi0 signal which has a fixed timing relationship with regard to the video scan line it generates. On the 2600, this signal drives the 6507, and which in turn generates a phi2 signal which is used to strobe TIA accesses. On the 7800, the phi0 signal from the TIA is ignored and the 6502 is clocked using the phi0 signal from the Maria which on startup will have a random phase relationship with regard to the TIA's signal. The TIA's logic doesn't require any particular phase relationship between its phi0 output and the phi2 input, but the exact pixel positions where TIA writes take effect will be determined by the phase relationship between the phi2 input and the scan line.

The clock would have to be derived from the TIA's clock, so that a known number of cycles would happen every TIA clock. With that taken care of, if one were running at a rate of 16x the chroma clock, one could simply have a loop which took about 228*16 cycles, taking an extra cycle if it saw a phi2 in the wrong place, or an extra 48 cycles if, for six or more scan lines in a row, it didn't see a sync pulse in the right place. The ARM would only have to worry about outgoing sync pulses during those parts of the line when it wasn't having to worry about incoming picture data, and would only have to worry about incoming sync pulses during those parts of the line it wasn't having to worry about any picture data. With an ARM clock of 16*chroma, it might almost be possible to have the ARM do everything, including watching the 6502. It would be tricky, since one would have to worry about watching for TIA writes every 48 clocks, but since one only has to watch for TIA writes once every three pixels it might be possible to do it if one spreads out the work of handling TIA writes. My guess would be that the timing wouldn't be too terrible if one were willing to restrict TIA COLUxx to once every three cycles (a restriction which would work with all "normal" code). The inner "loop" would probably be a macro that handled three chroma clocks (48 cycles): ; R13 -- I/O port base ; R12 -- Pointer for video data to be output ; R11 -- Pointer for video data coming from TIA ; R10 -- Active color base ; R4 -- Color data being computed for output ; r3 -- Temp data fetched from TIA ; r0-r2 -- Data fetched from buffer ; ; Assume r0-2 are loaded with next three words to be output, and r5 is r0>>16 ; Cycle 0 strh r0,[r13,#OUT] ldr r3,[r13,#IN] ; Top two non-blank bits must be luma bits, and next lower bit must be blank ldrh r4,[r10,r3,lsr #whatever] ; Cycle 8 strh r5,[r13,#OUT] lsr r0,r1,#16 sub r3,#Whatever ; Subtract base address of COLUxx lsls r3,#Whatever ; See if everything is valid for a COLUxx write (will be zero if so) bleq handle_write nop ; Show there is enough time to deal with things in branch case nop ; Cycle 16 strh r1,[r13,#OUT] ldr r3,[r13,#IN] ldrh r5,[r10,r3,lsr #whatever] ; Cycle 24 strh r0,[r13,#OUT] ; Value that was in r1, shifted right 16 add r4,r4,r5,asl #16 str r4,[r11,#4]! lsr r0,r2,lsr #16 ; 2 spare cycles ; Cycle 32 strh r2,[r13,#OUT] ldmia r12,{r0,r1,r2} ; Cycle 40 strh r5,[r13,#OUT] lsr r5,r0,#16 ; 5 spare cycles Including five cycles to handle a test for whether a TIA write cycle is occurring, the code ends up fitting with 7 cycles to spare when using a 16x clock (assuming a fully-unrolled loop for the parts of the line which require simultaneous latching and display of data). A COLUxx would knock things a little "behind", but on the next 6507 cycle one could skip the check for a COLUxx store, and thus get caught up. Perhaps it would be possible to make things work. It would certainly be very close.

How many cycles does the ARM require to read or write a port? Is it a 3-cycle LDR or two cycle STR? My estimate would be that every four chroma clocks would require four port LDR (12 cycles), eight port STR (16 cycles), one memory LDRM of two registers (4 cycles), one memory STR (2 cycles), and nine shifts (9 cycles). A total of 12+16+4+2+9 = 43 cycles. I don't know if the internal PLL of the ARM could easily run at Chroma*12, but if my estimates are right an ARM like you use for Harmony would be plenty fast to do the data buffering if it didn't have to do anything else. Adding 8-to-16-bit translation would add an extra 4 memory LDR for color translation (+12 cycles) and add two registers to the buffer LDRM (+2 cycles). The extra cycles for the buffer STRM would be offset by eliminated shifts; the net would be 57 cycles every four chroma clocks (probably use chroma*16).

I just came upon this thread. One thing I've been pondering for awhile is whether it would be practical to build a 480P component video mod using a CPLD and a fast cheap micro to act as a scan doubler? The basic idea would be a board that would sit between the 6507 and the TIA, intercepting pins D1-D2, so that they would be passed through in all cases except when writing to COLUxx; on COLUPx writes, the board would latch the value of A0-A1 and D1-D7, and would force D1-D2 to match A1-A2. The board could then use the two lower luminance outputs to detect which of the four colors the TIA is outputting. I don't think a cheap ARM would be quite fast enough to do everything, since it would be necessary to output 7 million dots per second. It may be possible for an FPGA to do everything, but CPLDs don't have RAM and adding a fast cheap micro would probably be cheaper than adding 160 bytes of RAM.

Some types of electronics have precious metal content which exceeds the cost of reclamation. In some cases by a fairly hefty margin. The money recycling outfits can make by selling the valuable metal content helps to offset the cost of disposing of worthless components. That having been said, it's sad that there isn't a formal procedure by which people could express interest in stuff. A recycling outfit might not like it if a device that had $5 net worth of precious metals got hauled away by a scavenger, but probably wouldn't mind if it got paid $20 for it by someone who would recognize it as being worth $500 intact.

The Melody has 8K of RAM, slightly beyond what was available in the day, but not massively so, since the SuperCharger had 8K, and BurgerTime was 2K. The concepts behind DPC+ are beyond anything that was sold in the day, but bus-stuffing was apparently used in the prototype Atari Graduate peripheral.

The 6502 data bus floats pretty well when it's not doing a memory write; the data bus pull-ups are at least somewhat active. That being said, your experiments would suggest that overdriving low's onto the bus is probably pretty safe. It might not be a bad idea to output "overdrive" bytes by storing zero in the data register and setting the output-enable register to the desired pattern. That would avoid accidentally trying to drive "1"'s on the bus. My first 2600jr I ever owned bit the dust when I misprogrammed a PLD in a cartridge and back-drove a high onto the address bus.

Hmm... how about this: Even frames, even lines: Show 'light' data in color $7A, on background color of $72 Even frames, odd lines: Show 'dark' data in color $B6, on background color of $B2 Odd frames, even lines: Show 'dark' data in color $B6, on background color of $B2 Odd frames, odd lines: Show 'light' data in color $7A, on background color of $72 If you can't change the background color every line, then Even frames, even lines: Show 'light' data in color $7A, on background color of $72 Even frames, odd lines: Show 'dark' data in color $76, on background color of $72 Odd frames, even lines: Show 'dark' data in color $B6, on background color of $B2 Odd frames, odd lines: Show 'light' data in color $BA, on background color of $B2 The latter would probably flicker more, though, and generally not be as good.

Protecto Enterprises did exist as a company with some real products, and I remember seeing the 2600 emulator advertised back in the day. I have no idea whether it was ever produced, but the only way it could possibly work would be if it had a pass-through connection for the VIC-20 audio and video, and disabled those when using the 2600 mode; the only VIC-20 features that would be used would be the power supply and the RF modulator. Given that the VIC 20's RF modulator was better than the 2600's, video and audio quality could be improved versus a stock 2600. Still, I'm dubious how Protecto could have been expecting to make much profit at that price.

The flicker-blinds are just for luminance, right? You have picture data on every scan line? Because luminance and chroma are independent, I would think that scan lines which flicker between e.g. $64 and $A8 would look pretty similar to those flickering between $A4 and $68. Do they not?

The 2600 adds a luminance signal to a fixed-amplitude chroma signal. One consequence of this is that saturation is very high with darker colors, and very low with brighter ones. Another more interesting consequence is that flickering between chroma X1 luma Y1 and chroma X2 luma Y2 will yield a color similar to flickering chroma X1 luma Y2 and chroma X2 luma Y1. Have you tried using different colors on alternate frames? Flickering between two colors whose chroma values differ by four will yield a color whose tint is about halfway between the two colors, but whose saturation is considerably reduced. Increase the difference to six and the saturation will be reduced even further.

A nice easy trick for getting a 108-column "flicker-blinds" display is to start with the two sprites set for three copies wide (32-pixel spacing) and have one sprite 16 pixels to the right of the other. Then on every scan line you shift both sprites left 8 pixels, and on every other scan line you RESPx the leftmost sprite just as its second copy would appear. That "second copy" will still appear, but now it will be the first copy and two more will follow. The net effect is the sequence: ---1-0-1-0-1-0----- --1-0-I-0-1-0-1---- ---0-1-0-1-0-1----- --0-1-O-1-0-1-0---- Where "I" and "O" are the spots were RESP1 and RESP0 are hit, respectively, and "1" and "0" are the places the other copies of player 1 and 0 show up.

Do you have any idea how many games use AtariVox for speech but don't "hit" the EEPROM chip first? It would be nice to have an adapter that could auto-detect a cart as either being designed for normal joystick/paddles, normal AtariVox, or special AtariVox-plus-joystick protocol. Unfortunately, the AtariVox will always read as a joystick being pushed in a direction, and the Atari won't try to "speak" unless it detects that joystick push, so I don't know that AtariVox-speaking software can be detected if it doesn't try to access the EEPROM first. Though I suppose one could have a button or switch to force AtariVox mode. Would you like any help with such a project, including a two-player-compatibility mode?

The best thing would be to modify a 2600 by replacing the Stella with a daughterboard containing the Stella and an ARM processor; the latter could then output 480P component video. I don't know exactly what various television sets will tolerate when it comes to component video frame rates, but using 480P component video would avoid the problems some sets have when receiving a 240-line non-interlaced signal. I wouldn't have time to do too much development work on such a project myself, but would be glad to assist anyone else who wants to tackle it. The Stella chip would be used mostly as "normal", except that the ARM would intercept bits D2-D3, and replace their values when writing any of the COLUx registers. The ARM would then use two luminance output bits along with blanking and sync signals to detect what Stella was generating. By intercepting writes to COLUx, the ARM would know what colors it should be outputting, and could output them in component video. Note that unlike most emulators which add a frame's worth of delay, an Atari modified in this way would be able to display its video without any added lag.

It's pretty easy, and should avoid some of the difficulties that would occur just using one. Do you understand the requirement about periods? One approach would be to do something like this: Temp = 255 Prescale: If TotalCardsLeft > Temp Then Goto GetRandom Temp = Temp / 2 ' Shift right goto Prescale GetRadom: RandomNumber = (Random Number 0 to 255) If (RandomNumber and Temp) >= TotalCardsLeft Then goto GetRandom Temp = 0 GetCard: RandomNumber = RandomNumber - CardsLeft(Temp) If RandomNumber > 248 Then Goto Done ' It underflowed Temp = Temp + 1 Goto GetCard Done: CardsLeft(Temp) = CardsLeft(Temp)-1 ' Temp holds value of new card Really? Once upon a time, that might have had more appeal to me. But now I've got something much better (a wife).

How do you make sure that when a denomination of card is getting scarce, it's less likely to be chosen?

My normal pseudo-random generator is a 16-bit LFSR, where the upper and lower halves shift in opposite directions, and where each returned value is the xor of the upper and lower halves. The code is something like: get_rand: lda rand1 rol ror rand2 bcc no_carry eor #$DB ; I think that gives period 65,535 no_carry: sta rand1 eor rand2 rts This generator will return 65,535 out of 65,536 possible two-byte sequences; the only missing one is 0,0. For a card game, I'd suggest using the above generator along with an 8-bit generator of length 128 (not 255, since 65,535 is a multiple of 255) and eor'ing the results of the two generators. It might be good to run the 8-bit generator three or five steps for each output value, so as to avoid having a run of eight values that look too strongly "patterned". To get a number in the range 0-n, AND the accumulator with an appropriate power of 2, then compare with the target value. If too big, simply grab another number from the random generator.

I believe they are. Handling the extra 12 pixels could be a bit of a nuisance, though I think the upper portions of each picture are the same regardless of attire, so it might have been practical to have the three lower pictures associated with each opponent, plus the upper portion, take up a 4K bank. Fair enough for this project, but something to consider for the next, perhaps. How are you tracking those? Using 26 bytes to keep track of what has been dealt (one bit per card)? Seems a little expensive. If you have a routine which can give a repeatable sequence of 208 numbers, the first being 0-207, the second being 0-206, etc. you can use the following algorithm to find the Nth card that should be dealt: N = CardToGet ' 0 for first, 1 for second, etc. Reseed generator I = 208 Loop: I = I-1 NewRandom = Random # 0 to I, inclusive If N=NewRandom Then N=I if N=I then N=NewRandom If N < I then Loop The code is a little slow (since it may have to run up to 207 loops to get a card) but the result will be unbiased. Indeed, the result will be the inverse permutation of a Fisher-Yates shuffle using the same sequence of random numbers.

I'm not sure how your code is set up, but my normal inclination would be to use a little RAM to hold the shape pointers and colors for even and odd scan lines, and then have a single kernel which would display things appropriately. I'd put twelve pages of graphics data in each bank, and the gist of the code would be: ldy linecount_even loop: sta WSYNC ; Adjust the position of this as appropriate inc linecount_even lda color_even sta COLUP0 sta COLUP1 ; Show one line of graphics, using Y as index, from $1100, $1200, $1300, $1400, $1500, $1600 ; then... ldy linecount_odd sta WSYNC ; Adjust the position of this as appropriate inc linecount_odd lda color_odd sta COLUP0 sta COLUP1 ; Show one line of graphics, using Y as index, from $1700, $1800, $1900, $1A00, $1B00, $1C00 ; then... ldy linecount_even cpy frame_end_even bcc loop No need to waste twelve bytes of zero-page pointers, and no difficulty supporting either interlaced or non-interlaced colors. If the pictures were 84 scan lines tall, each bank should be able to handle three of them without trouble (3*6*2*84 is slightly under 3K). I think you have nine pictures, so I'm not sure why code space would be tight. Out of curiosity, how are you handling the deck and dealing? If speed isn't an issue (and I don't think it is here) it's possible to output a sequence of random-ish cards without duplicates without needing anything other that a random number generator that can either run bidirectionally or else be repeatedly reseeded with the same sequence, and counter for which card should be output next (1st, 2nd, etc.) and a couple of scratch variables.

My curiosity got the better of me, so I tried it out. Looks cute, though some LCD television sets tend to mangle flicker-blinds and things might look better if the graphics flickered at 60Hz between the two color frames without the Venetian blinds; perhaps the color/BW switch could select modes. By the way, have you seen Andrew Davies' Chronocolor demos? Some of them look pretty good.

On CRT-based screens, flicker-blinds are better than column-based flicker. On some LCD screens, flicker-blinds come out really ugly and column-based flicker is decidedly better. One of the sprites was set to show three copies (of which two actually appear on screen) and the other two copies (of which one appears). Hitting RESPx on both sprites in the proper order when they're properly configured will cause one sprite to appear between the copies of the other two. There will be one column of overlap and one blank column, but such is life.

The quad-sized objects are four 8-pixel objects which are placed with 8 pixels between. Crypto-Logic uses four quad objects plus twelve individual objects to display 28 letters total.