supercat

If it's a marginal case of bitrot, reading the device out with different VDD levels may be able to help.

"LDA WSYNC" will take three cycles, regardless of when in the scan line it occurs. The MSB of the accumulator will indicate whether a collision occurred between player 0 and the playfield; bit 6 will indicate whether a collision occurred between player 0 and the ball. Bits 0-5 will most likely be "00 0010".

I can't think of anything better than a classic 12ga shotgun with a 3.5" magnum turkey load and a full choke. And a 12ga is a pretty common skeet gun (even though most units used for skeet shooting have 2.75" or 3" chambers).

What's a 20.06? Is it just a smidge smaller than a 20ga? I certainly would not advise firing a 30-06 at any airborne target unless you are in the middle of open ocean. A 30-06 bullet can travel for miles (it's not accurate out that far, but it could still hit someone).

The O2 hardware is designed to display four sprites that can be any shape, twelve objects whose shapes are predefined (letters, numbers, the walking man, etc.), and four groups of four horizontally-arranged objects each whose object shapes are likewise predefined. My guess from your description would be that the O2 is using some tricks to form the chessmen out of 'pieces' of the predefined shapes. Sorta clever if that's what they're doing. Any possibility of a screenshot?

Not a lot. Simple loop. The memory is quite small, searching is fast - it happens in the blink of an eye. How many pages per frame can you read headers from while showing a display? Obviously if you screen-blank you can read stuff much faster, but screen blanking is ugly. That's why I'd suggested that the first part of the flashcart memory contain the name of each game. This would allow a lookup based on application ID. How are files over 117 bytes handled? Not much. Whatever scratchpad is needed by the I2C routines, plus a 2-3 bytes, and maybe 4-6 bytes of stack (all but 2 of which could safely be used by the display kernel). Fair advantage. Well, then you need a way to let users decide what they want to delete. To be frank, no, sorry. I fail to see how it cures any problems, but it creates new ones. You may be right. I sometimes have good ideas and sometimes bad ones. Only way to know is to put 'em out and see what happens. I'll look into that. Thanks.

I think I figured out a good single-comparator-based solution if it's acceptable to have /WE go low 355ns after address stabilization and high 684ns after address stabilization. It assumes that the PLD will switch cleanly to VDD, and that 4.0 volts (0.8VDD) will be a valid high for the /WE signal, but I think those are pretty save assumptions. Adding another resistor would allow /WE to be pulled higher, but would require refiguring all the other resitors. The PLD generates a signal which is low except when an address looks interesting and the /WE output from the compator is high; when both of those conditions apply, it should be driven high. This signal goes through a 223 ohm resistor to a 1nF cap on the non-inverting input of the comparator. The other input of the comparator connects via 1K resistor to ground, 249 resistor to VDD, and a 57.6 resistor to the output. The output of the comparator connects to /WE on the RAM chip and to a feedback input on the PLD. Normally, the cap will sit at ground. When an address is interesting, PLD will output a high and the cap will take 355ns to charge to 4.003 volts. At that time, the output of the comparator will switch to ground. The PLD will then start outputting a low, causing the cap to discharge until it reaches 0.897 volts. At this time, the comparator will again float its output (allowing it to be quickly pulled back up to 4.003 volts). The PLD's output will also go high again at this point, but since the cap would take another 311ns to charge to 4 volts and the memory cycle will end before that, this will not pose a problem.

Can you throw on an amplitude envelope to make it sound 'dingy' or 'hooty' instead? Adding an amplitude envelope or modulation can help mask some of the objectionable out-of-tune-ness. To be sure, the masking only stretches so far and some of the 2600's notes are truly horrible clinkers. But amplitude shaping and percussion can help a lot.

That would eliminate the cost of the PCB then, which would help a lot. I would say you could get really close. My thinking is that if RAM-plus carts cost $30 in the Atari store, people may still buy them. If they cost over $40, many fewer people will. Since the Atari Store can sell their current carts for $20, I would figure the extra cost for the RAM-plus cart shouldn't be much over $5 if the Atari Store is going to sell them for $30 and make a profit. If one is trying to do a bank-switch on a read cycle that's supposed to return valid data (as in $F8 bankswitching), timing is apt to be tricky because one needs to do the bank switch soon enough that the EPROM can respond to it and output the new data in time. For the bank-switch methods I'm using, the timing is not so critical, and so I'm using the /WE timing logic for the bank-switching. Since /WE has no effect if the RAM is deselected, and since the rising edge of /WE occurs (must occur) when address and data are both stable, this should provide a good timing point for doing the bank switch. The problem is that the address stabilizes happens way before the data. Like I mentioned above, 2 ticks (136ns) for bankswitch delay, but I had 7 ticks (about 476ns) for my falling edge of WE and 1 tick (68ns) for WE return. SRAM timing was tight. Is it really that tight? If data is stable 556ns after addresses become stable, I would think you should have about a 250ns window for /WE to go high (assuming 30ns for address stabilization). If the target time is set to 675ns, that would allow for +/- 18% on the timing. Good point. I'm thinking that I should probably add an 8-pin analog comparator to the timing circuit so as to yield something less touchy. I've come up with a 1-comparator, 5-resistor, 1-cap solution which should work if there are never two 'interesting' accesses back to back (and I can't think of any reason there would be). Oddly, all of the two-comparator solutions I can come up with use more resistors. What board house do you recommend? Also, I wonder if it's best to try to come up with a good mechanical fit on the first proto, or space things out more and simply try to get the circuit working? Since the proto houses I know of charge more $$$ for non-rectangular boards, I was thinking of making a board that's 1.2" by over-long. Would look a little goofy, but it'd avoid having to get the thing cut to fit the cartridge slot.

I believe 3F and 3E bankswitching work as follows: 3F bankswitching: Address $1800-$1FFF always read last 2K of ROM Addresses $1000-$17FF read a selectable 2K bank of ROM Any access of a memory location where A12, A7, and A6 are all low will cause the value on the data bus to be latched for a bank-select. If all 8 bits are latched and used, this would allow 512K of ROM to be accessed. The above address includes addresses $00-$2C, used by the Stella chip. Fortunately, the Stella chip may also be accessed at $40-$7F (necessary when using this bank-switch method). The 'preferred' address to use for bank-switching is $3F, as this will assist emulators in auto-detecting the proper bank-switch method. Although reads to $3F (or other 'trigger' locations) will cause a bank switch, the actual bank switched to is unpredictable. Use a write to $3F to switch banks. 3E bankswitching Similar to 3F bankswitching, except that A0 is latched in addition to the data bus. If A0 was latched high, 2K of ROM will be selected at addresses $1000-$17FF If A0 was latched low, 1K of RAM will be selected for reading at addresses $1000-$13FF and for writing at addresses $1400-$17FF. The 'preferred' bank-switch trigger addresses are $3E and $3F, as this will assist emulators in detecting the proper bank-switch method. In the open-source flash cart thread, I also list a few proposed new bankswitch methods. Note that I if I actually actually build this thing I may use something a little different from described depending upon whether I end up with more or fewer inputs/outputs than expected.

That is precisely the idea. I meant $5 over the cost of a non-SRAM bankswitched cart. I don't think $5 total would be plausible in any reasonable quantity. On the normal SRAMs I've dealt with, address can change any any time in relation to chip-enable and the data will become valid Tacc later. It's acceptable for chip-enable to remain active for many read cycles (or even to be strapped low) and the chip won't care. The only timing constraints I'm aware of are (1) address must be stable before the falling edge of (WE | CE) and must remain stable until after the rising edge; (2) data need not be stable before the falling edge but must be stable before the rising edge. I don't know how nearly-simultaneously the address lines on the Atari switch and how long the address and data remain valid, but my plan was to use a pair of RC's so that the /WE signal would go low about 50ns after a seemingly-valid address appeared and remain low for about 150ns. I wouldn't expect either of these times to be very critical since the 2600 was designed to work even with what by modern standards would be ploddingly slow ROMs. Which timing parameter did you have trouble meeting without using a crystal? Thanks.

Yeah, well the Karate cart wouldn't even play on my TV without rolling the picture. Though in retrospect I'm wondering if it might have been a PAL cart since the version for download here is only 269 lines and I'd think a TV oughta be able to handle that. As for Skeet Shoot, if the bullets moved twice as fast at "A" difficulty it might almost be playable. I do find it interesting that in the game variations, they let you 'lock in' a shooter position and target angle but not straight ahead from the center post, nor left bird from right post, nor right bird from left post. I wonder why they left those out? >:*3

If you're confident. I would just worry about the provenance. Since lab cartridges would generally have been produced hastily and reused a lot, it would seem trivial for someone to take an otherwise-unexceptional lab cartridge and "improve" it by sticking in an EPROM of something else. Perhaps I'm wrong, but I'd think it much easier to fake a prototype cartridge than a production one. I can certainly see that for pieces of known provenance (e.g. if Warren Robinett had been allowed to keep a lab cart of Adventure back in 1978 and were to put it on eBay, that would be an identifiable piece of history. And I guess if you happen upon a prototype of game for which there are no known other copies in existence, that prototype might have the historical significance of having been for awhile the sole 'life-line' by which the game was rescued from oblivion (and you might want to keep the cart as a souvenir of your having rescued the game). I guess I view the collecting prototypes thing somewhat like autographs. If I get someone's autograph personally, I may have an attachment to the item as a result of the autograph that I would not have in its absense. But an item that was autographed for someone else would have no particular significance for me. Likewise, if I had a prototype cart that had let me rescue a game from oblivion, I would want to keep it, but a prototype cart that let someone else rescue a game from oblivion would have no particular value to me. I do buy carts, btw, because I'd rather play 'the real thing' than a downloaded copy. I also buy modern carts to help support the authors and encourage more development. But there's no way I'd be inclined to spend $hundreds or $thousands on a cart. There are other things I'd rather do with my money.

I'm working on a minimal RAM+EPROM cart design which I'd open-source if anyone would be interested. Approximate part BOM: 1-32Kx8 EPROM 1-32Kx8 SRAM 1-22V10 7 resistors 5 small caps (3 bypass caps + 2 small timng caps) 3 jumpers (intended to each be soldered one of two ways to select one of two configurations) The device would accommodate the following bank-switch methods. Note that not all address wires are decoded, so bank-switch registers may be shadowed throughout the $0000-$0FFF range. Bankswitch style 3E, extended (32K EPROM + 32K RAM): Address $1800-$1FFF always access the last 2K of EPROM Write 0-15 to location $003F to select a 2K bank of EPROM to appear at $1000-$17FF Write 0-15 to location $003E to select one of the first 16 1K banks of RAM to appear for reading at $1000-$13FF and for writing at $1400-$17FF Write 0-15 to location $023E to select one of the other 16 1K banks of RAM to appear for reading at $1000-$13FF and for writing at $1400-$17FF Writes to even addresses $00-$3C will act the same as $3E, but will also affect Stella. Writes to odd addresses $01-$3D will act the same as $3F, but will also affect Stella. Use addresses $40-$7F to read/write to Stella without bankswitching. Writes to $0200-$027D will behave analagously to writes to $0000-$007D. Bankswitch style x3D (new 32K EPROM + 1K RAM): Address $1200-$1FFF addresses one of eight 4K banks of EPROM. It is recommended that reset vectors be present in all to force a bank-switch on power-up. When RAM is enabled, address $1000-$10FF addresses one of four pages of RAM for reading, and $1100-$11FF accesses it for writing; otherwise that address range accesses the same EPROM bank as $1200+ Write anything [data is irrelevant] to address $023D to enable RAM, or $033D to disable RAM Write anything [data is irrelevant] to $43D-$73D to select one of four 256-byte pages of RAM Write anything [data is irrelevant] to $83D-$F3D to select one of eight 4K banks of EPROM Bankswitch style x3C (new 16K EPROM + 2K RAM): Address $1200-$1FFF addresses one of eight 4K banks of EPROM. It is recommended that reset vectors be present in all to force a bank-switch on power-up. When RAM is enabled, address $1000-$10FF addresses one of eight pages of RAM for reading, and $1100-$11FF accesses it for writing; otherwise that address range accesses the same EPROM bank as $1200+ Write anything [data is irrelevant] to address $023C to enable RAM, or $033C to disable RAM Write anything [data is irrelevant] to $43C-$73C to select one of four 4K banks of EPROM Write anything [data is irrelevant] to $83C-$F3C to select one of eight 256-byte banks of RAM Bankswitch style x3B (new 32K EPROM + 8K RAM, with restrictions): Each 4K bank of EPROM has four associated 256-byte pages of RAM Address $1200-$1FFF addresses one of eight 4K banks of EPROM. It is recommended that reset vectors be present in all to force a bank-switch on power-up. When RAM is enabled, address $1000-$10FF addresses one of 32 pages of RAM for reading, and $1100-$11FF accesses it for writing; otherwise that address range accesses the same EPROM bank as $1200+ Write anything [data is irrelevant] to address $023B to enable RAM, or $033B to disable RAM Write anything [data is irrelevant] to $43B-$73B to select one of four 256-byte pages of RAM associated with the current EPROM bank Write anything [data is irrelevant] to $83B-$F3B to select one of eight banks for both RAM and EPROM The first bank-switch method would require all three jumpers to be in the "A" position; the other three would require all three jumpers to be in the "B" position. All four methods would require the 22V10 to be programmed differently. Anyone think that sounds like an interesting concept?

Take a Froggo Karate apart and you can make a 4K cart which takes 2764's (a little cheaper than 2732's).

So I'm not the only one to stand up for that game? Reminds me of Killer Bees, my favorite O2 game.

If I might make a few suggestions, I've done some flash file system stuff and I really don't think the proposed file system is too good. It requires a lot of searching for an application to find its data, and there's no defined way for applications to avoid picking identical file names.I know it was a preliminary idea, but it would be good to nail something down before people code stuff that would be incompatible with something better. My personal thinking would be that file system usage should be standardized to the point that someone could use an Atarivox Manager cartridge to list and delete files, as well as to try to repair a corrupted file system. Toward this end, I would offer the following proposals: -1- All new applications after some cutoff point, and all applications which save data in the file system (instead of the application-specific area) would be expected to have the first byte of their private space be a pointer to their first file [0 if none], and have that be followed by a null-terminated application name of up to twelve characters in length. All such applications would have private storage addresses which are higher than any storage addresses for applications not meeting these criteria. -2- Each allocated file block would start with the following information: ID of owning application (1 byte; application base address/64) Address of first block of next file (1 byte; 128+[address-$4000]/128, or 0 if none) File index (1 byte; defined by owning application) Address of next block within file Block index within file (0=first block; 1=second; etc.) For first block of file, a null-terminated filename up to 12 characters, or a 0 byte if none. Unallocated blocks of memory would be kept in a linked list; the system would maintain a pointer to the first such block. An application wishing to create a file would retrieve this pointer, check to ensure the block was actually free, retrieve the "next" pointer, rewrite the "first free block" pointer to equal the next pointer, and then write its block of data. Assuming a routine called "STARTREAD" is defined which will start reading at byte Y of block A, and a routine called "READBYTE" is defined which will read the next byte from the I2C, a program could check for the existence of some number of valid free blocks by doing something like: lda #5; [number of blocks to look for] sta ctr LDA #SYSTEM_FREEBLOCK_PAGE LDY #SYSTEM_FREEBLOCK_OFS JSR STARTREAD JMP firstread lp: LDY #0 JSR STARTREAD JSR READBYTE BNE NOGOOD ; This block is already claimed by someone firstread: JSR READBYTE BEQ NOGOOD ; No more free blocks DEC ctr BNE lp ; We have at least 5 free pages Doing this sort of test before the application starts would avoid any risk of frustration from a user being unable to save his work. In the event that a test like the above failed, I would suggest that an application should suggest that a user run the ATARIVOX MANAGER cartridge to scan and repair the file system. Although the file system should be fairly robust, things can go wrong. An application could try to slog things out by searching manually for free blocks, but recommending use of the manager cartridge would seem like a good idea. BTW, I would add another couple notes regarding cartridge usage: declare that addresses $3C00-$3FFF may be used as scratch pad by any application (including the file manager) but applications should not expect anything to stay there between uses. Addresses $3800-$3BFF would be usable by any application other than the file manager; applications could use this to temporarily store files if the file system got corrupted. Any application actually using this space should store its ID in the first byte. Any of those concepts seem interesting?

Unless the binary happens to be different from all other known binaries, how can one tell a real prototype from a pirate cart or fake prototype? It would seem that most prototypes lack a clear trail of ownership, so how can they be authenticated? I can certainly see the interest in the code for work-in-progress games. And some prototypes are physically interesting as well (e.g. ones that have hand-wired mods to implement new bank-switching methods, etc.) But for the most part, I fail to see much reason for interest in the artifacts themselves. Can someone tell me what I'm missing?

The Commodore has three voices instead of four, and so notes may have been changed to fill in for that, but otherwise the C64's pitch accuracy and frequency range are better than those of the Atari 8-bit computers.

Yes, this is exactly right. I guess I am referring to the transistor level implementation...it's quite simple...basically (if memory serves) there are two n-channel transistors per bit. One is driven by the "counter" and the other by the value latched in HMOVE. These are all wired in parallel. If any "set" of transistors are not turned on (thus indicating a compare), the line indicating a match is pulled down (i.e. "not" match signal) Therefore, the comparison is quite simple to implement and requires very little in terms of gates.. So why would using an 8-bit binary counter and 8-bit comparator have been a problem? I know an 8-bit counter is more complicated than the linear feedback shift register, but only one counter would have been needed for all the sprites. I guess maybe for sprite cloning the LFSRs work out well, but splitting a comparitor into a most-significant and least-significant part might have worked well. Heh. Maybe it's that way 'cos I didn't design it. Though I'd have probably made some other different mistakes. BTW, the generation of several non-overlapping timing signals with different power-of-two rates and selective AND'ing of them is really a very nice approach that I'm surprised isn't used more often. If used in baud-rate generators, for examine, it would allow much finer control of baud rates than is otherwise available and yet cost less silicon than existing BRG designs. It's basically only really useful in games where a player is moved around the screen with the program having no clue where it is. In the absense of RESMPx, the program would have to keep track of the player's X position and be able to put the missle there. So for a game like Combat it probably saves four bytes of RAM and 40 bytes of code. Yippie. That could cause some interesting problems I'll bet. Sometime I hope to download and examine the Stella schematics; I'm sure they're fascinating. Things like playfield generation and reversal seem interesting. My own inclination with a playfield might have been to have a 48-bit register with write addresses for left half only, right half only normal, both halves with right half normal, and both halves with right half reversed. But that's just me.

No, it is but a demo. 714109[/snapback] True, but the earlier boing version had an Easter egg (or was it a Christmas egg?) that doesn't seem to be in this one.

If one limits oneself to Never The Same Color (NTSC) units, can artifacting be used to create consistent colors on the 7800? I know it can on the Apple II family of computers and on the original IBM CGA, but it can't on the Commodore 64. Since the 7800 pixel timings are chroma-derived (2x chroma) I would think artifacting would be usable there as well. Has anyone tried it?

Cute. I don't quite understand how it works, though playing around with the disables on Z26 it seems you're using ten sprites for 'masking' purposes (clever) and you're using the Ball to fill in the middle part of the playfield (so you don't have to do 2x/line updates between rows). Not sure how you're going to handle alternating black and white stones in the first five columns and none in the rest, though. BTW, with regard to the go puzzle idea, I think it sounds cool if you can find a non-copyrighted source of puzzles. Each puzzle would take 17 bytes in a fixed-size format if you packed things optimally and simply stored the board and the solution, so you could fit about 60 puzzles per kbyte. To add interest, you might allow a variable number of additional bytes per board which would give an 'if-then' of proposed solutions and results. So if someone selects a wrong move which was anticipated by the puzzle creator, the program could illustrate what would happen if that move was played (and thus why it's a wrong move). This would require an engine that could understand the rules, but no AI.

It's important to sanity-check velocity, though. Otherwise goofiness can ensue (e.g. in Spacewar, if a player just keeps thrusting in the same direction).

I've programmed a nice worm game on the PC, and would suggest you use a technique similar to what I used. Use a programmable-character set mode and use 32 characters for the following combinations of things: Front of worm head, in four directions (4 characters) Worm tail in all four directions (4 characters] Head-body join in all combinations of directions (12 characters) Body-body or body-tail join (12 characters] These 32 characters will fit in 256 bytes. If you have eight copies of this 32-character set, one for each pixel of motion, you will be able to achieve smooth animation along the entire length of the snake (no matter how long it is) simply by doing a 256-byte copy. If you want to use a player for the head of the snake, you may make things even faster because you'd no longer need the special head characters and would thus only have to copy 128 bytes/frame. One thing I would recommend doing in a snake program to greatly enhance playability would be to make it so that repeated joystick presses in the same direction will accellerate the snake. Pressing the joystick in a new direction will reset the speed to baseline (pressing in the direction opposite motion will have no other effect). This ability greatly reduces boredom on slower levels. BTW, in Wormy II, the penalty for timer expiry is uncontrollable snake accelleration up to maximum (which is unplayably fast). If the player manages to grab an "extra time" power-up while the snake is accellerating, the accelleration stops (but the speed remains whatever it is). If the player survives, good for him.