supercat
-
Content Count
7,259 -
Joined
-
Last visited
Posts posted by supercat
-
-
To compute the integer square root of any number from 1 to 65535, one need only compute the square root of numbers in the range 16384 to 65535. A 192-entry table (one entry for each 256 units of range) could be used to get an answer within +/-1 of the correct result. So do the rough lookup and then refine it.
-
yeah, i didn't figure it held great monetary value, i was more wondering about the usefulness of itI would suggest buying it, reading the manual, and printing off a set of overlays to put near the controllers. Although the cartridge is severely hamstrung by the 2600's limited RAM (half of which is available to the user) and keypad controllers, it's interesting to see what the 2600 can 'almost' pull off. The cartridge allows the user to open up windows showing the interpreter stack, the values of all variables, the code being executed with the current token highlighted, etc. If this cartridge had been designed as a teaching tool for the Atari 400 (with more RAM and something resembling a keyboard) such features would have made it interesting. Even if it just had an extra 128 bytes of RAM and a 6x8 keyboard, that would have improved things a lot. Even as it is, though, I still think it's neat to see the 2600 put up a pretty-darned-reasonable-looking text display.
-
Being that chess games are available free, then there should be some kind of easy way to get a good algorithm to implement into a 2600 game.Any good algorithm will require much more code, and much larger data tables, than would fit in 4K or even 64K. Further, a modern PC is over 1,000 times as fast as the 2600; a move that takes a second on the PC would take many minutes, if not hours, on the 2600.
-
I wonder also: could one of those homebrew bankswitch PLDs be modified to include the 128 bytes of Superchip RAM? That way you would take a new EEPROM and a new PLD and solder them both to a new board - no need for donor chips?There are no inexpensive DIP-based PLD's that include 128-bytes of RAM (indeed, I don't know if any such PLDs exist, period). Using a PLD plus an external RAM and ROM would be possible, but I know of no inexpensive PLD which would be suitable for that task and is available in DIP form. There is a chip that could be used which would include bank-switching, RAM, and ROM all within a single inexpensive chip, but it's only available in surface-mount. The latter chip will probably be used for 2600 carts in the future, but that design isn't finalized yet.
-
Hmmm, there's an interesting idea for a new homebrew project. How about a SuperChip 32K chess game? I bet the algorithm could be improved considerably.
I'm sure that adding some extra RAM and ROM would allow for a better chess game, but one would have to spend hundreds of hours of effort to still, at best, turn the 2600 into a rather mediocre chess player. When Atari's chess cartridge made its debut, it was cheaper than any other chess-playing machine on the market. Today, there are programs available free that are far better than anything the 2600 could dream of accomplishing even with a 70MHz ARM as a coprocessor.
-
Because of the bankswitching logic PLD, the original ROM's had the logic in the chip, EPROM's do not.BTW, it's probably too late for this idea to be useful, and it's probably not practical anyway, but I may as well suggest... would it be practical to make a daughterboard that would plug into the space occupied by the ROM on an Atari cart? I would guess it would be necessary to use surface-mount, but such a thing would have two advantages over using a new PCB:
-1- It would be a smaller PCB, and wouldn't need gold fingers.
-2- Though it would require more labor to assemble than a normal PCB, the labor required to destructively remove a ROM and solder a header to two boards might be less than the labor required to non-destructively remove a RAM and solder it into another board.
The approach might have been fairly nice (albeit pointless) for some older cart PCBs that had two rows of holes with all the cartridge signals; one could destructively remove the old ROM without unsoldering it and connect the new board to the other holes. It doesn't look like Atari's SARA boards have the extra holes, though.
-
Thanks for the links, NE146, cool stuff, but I was really wondering about human players trying to beat the VCS on level 7; are there any accounts of that?What would be the point? Make a move, come back 12 hours later, and find out that some of the pieces are no longer where they're supposed to be. Even if one were to reset after each turn all the pieces except the last one the computer seems to have chosen for its "move", the move may well have been chosen based upon incorrect positions for some of the pieces and may not make any sense (or even be legal, for that matter) with the pieces in their correct spots. Simply put, although the computer may spend more time "thinking" at higher levels, it is less capable of playing a coherent game.
-
I guess that's debatable, but I don't know enough about the Z80 to argue it myself. Stuff I've read in the past has suggested that a Z80 is faster when running at twice the clock speed. In particular I remember reading a debate in some forum/newsgroup/whatever where advocates programmed equivalent routines for each CPU, and it ended up that the Z80 @ 2x clock usually won.Examples can be worked out in which either machine will win by a considerable margin. The Z80 has a number of internal registers; register-accumulator operations with the accumulator as destination take four cycles and both register-immediate and accumulator-immediate operations take seven. By comparison, on the 6502, zeropage-accumulator operations take three cycles, accumulator-immediate operations take two, and zeropage-immediate operations must go through registers (thus taking five cycles). Thus, for applications that can be handled mostly in registers, the Z80 comes out ahead.
On the other hand, the 6502's memory addressing is much more flexible than the Z80's. Although the Z80 is much faster at incrementing a pointer in a register (6 cycles) than the 6502 is at incrementing one in memory (twelve cycles), the 6502 can perform address computations upon pointers stored in memory without having to modify them first using indirect-indexed mode. Many instructions on the Z80 have a very restricted set of addressing modes. Even just loading the contents of memory location $1234 into the E register requires 16 or 17 cycles and trashing another registers, e.g.
; 16 cycles, trashing D ld de,(1234h) ; 17 cycles, trashing A ld a,(1234h) ld e,a ; 17 cycles, trashing HL ld hl,1234h ld e,(hl)
By comparison, an absolute-mode load on the 6502 would take 4 cycles--a quarter of what the Z80 requires.
Also, in applications that require using lots of memory pointers, the 6502 can really blow the Z80 away. The BTP2 music player in Stella's Stocking requires 46 cycles per scan line. Even if one is nice enough to page-align everything and keep code in RAM, the Z80 would be horribly outclassed:
; A typical Z80 routine, equivalent to the BTP2 player. Note that this is one of four routines that must be used on a rotating basis. ld hl,(patch1+1) ld a,(hl) patch1: ld hl,voice0 add a,(hl) out (audv0),a inc h ld a,(hl) ld (patch0+1),a ld hl,(patch2+1) ld a,(hl) ld hl,(patch3+1) add a,(hl) out (audv1),a ; 16+7+10+7+11 + 4+7+13 + 16+7+16+7+11 ; 51 + 24 + 57 ; Total 132 cycles (as compared with 46)
Hmm... not quite as bad as I thought, since I shaved off a few cycles since the last time I looked at the concept. Still, I think the 6502 is the clear winner for that code.
-
Atari Video Chess moves pieces around the board somewhat arbitrarily at the higher levels, in a fashion not bound by any normal rules of chess. It is thus not possible to really play a game in the normal sense.
-
1
-
-
Since "stacking" (look at the enemy soldiers in Front Line) cannot be used in the Pac-Man games, in order to have a 2-color ghost you will need 2 sprites.Depends how clever you are. Since the ghost's eyes are black and white, and all the places in which the ghosts move have a white foreground and black background, one could draw the ghosts' eyes on the background layer without needing to use sprites for them.
-
Not just yet, it needs to go through testing to make sure there are no problems with it before we start churning out carts based on this revision.What's the ROM size? 16K? Would it be practical to make a 32K ROM that combined old and new versions, and allow an 'upgrade' option for owners of the original (so then owners of the original that didn't upgrade could sell their "rare collector's edition" carts for 5x the price
)? -
I think I took 200 shots to find one that looked the way we wanted.So which part of the code is that? >:*3
-
p.s. Your program completely confuses my scan converter (inexpensive TV/VGA converter)Some decoders count the number of equalization pulses (even vs odd) to distinguish even and odd scan fields. The only way I see to make this thing work is going to be to look at a real signal and at what the A8 puts out to compare them.
-
So the first of these 2 bytes has the first bit shifted into a flag and a branch is done to change the color of the first byte of data in the sprite which is pulled from the first color in the list, color 1.Then the sprite data is drawn for thoes first 2 scanlines then the next bit is shifted into the flag and checked for a branch to either change color to next in the list or no action. That way every 2 scanlines 0 would be no change or 1 would be change to next color in the list.s done.
The 2600 hardware imposes four limiting factors on a game. In usual order of severity, they are:
- Kernel time
- RAM
- Code space
- Non-kernel time
Note that any one of those constraints may pose difficulties, but RAM and kernel time are usually the most severe.
While it is occasionally possible to store data in compact formats and still work with it in the kernel, that is usually only workable if one can afford to waste a scan line or two unpacking the data. Strat-O-Gems employs such an approach, using two scan lines to unpack gem data for each row of the display. Hunchy II uses that approach to do the shape-table lookup for each 'row' of playfield (if you look at the playfield shapes, you'll notice some lines are always blank). Trying to use such an approach at kernel time is not going to work with vertically-mobile sprites.
There is, however, another approach you might be able to use if code space is more constrained than RAM (as it was with Toyshop Trouble). Have a RAM buffer which holds the shape (and/or color if you prefer) of a sprite, unpack the sprite data into that buffer during a non-kernel time interval, and then have the kernel fetch the data from RAM. If I recall, Toyshop Trouble has a total of 18 different shapes for the elf, and if they were read from ROM they would have to be preceded and followed by 15 bytes of zeroes. Storing all 18 shapes separately would have used up more than 500 bytes of ROM. What I did instead was to store the body and head shapes, along with a table that indicated that e.g. walking frame #3 of elf walking rightward was body #6 and head #4, mirrored. The screen is divided into 16-line zones, and the elf is 17 lines high, so the elf appears in two zones; I use 16 bytes of RAM to hold the elf GRP0 data for both zones.
The net effect is that I need to determine once, before each zone, whether the elf will appear at all in that zone and then set a pointer to either the RAM buffer (if the elf does appear there) or 16 bytes of zeroes (if the elf does not). Within the zone, there is no need for any decision-making about whether or not the elf should be drawn.
Addendum: the last line of the elf's coloring always matches the first, so the color can wrap every 16 bytes. There are I think three ways the elf can be colored; I have two copies of each of the three 16-byte color patterns stored back to back. I then have one color pointer, which I share among all zones, which points somewhere in those tables. I never worry about whether to color the elf sprite--I always just do it. For the lines where the GRPx data is non-zero the colors will be right; for the other lines, they'll be wrong but I won't care.
- Kernel time
-
I would never have written such things in my post without having checked the schematics first:Sometimes I like to imagine how I would have designed something before I see how it was actually done, to see how some of my insights compare with the designers'. I don't think I would have considered using slip counters for object positioning if I hadn't seen it done in PONG and the TIA, but slip counters do provide a very nice approach for things.
I recall that TANK did multiplex the players' score display logic; I don't remember if it multiplexed the shape display. Certainly multiplexing logic can save a lot of circuitry.
I'll take a look at the manual and see what I think.
-
Playing Pitfall II reminded me that decent audio is possible…...with extra hardware. Stella's Stocking demonstrates that even better audio is possible without extra hardware (though few games could afford the 46 cycles/line that Stella's Stocking spends on audio). The approach used by Stella's Stocking probably wouldn't be usable in a game; indeed, even displaying a decent title screen while playing music was a challenge. On the other hand, four voices with a five-octave full chromatic range using nothing but CPU power is pretty impressive. Incidentally, the BTP2 music driver in Stella's Stocking uses power-of-two rate multiplication for octave selection along with integer rate division for the pitch within each octave. There are 12 wave tables ranging from 60 entries © to 32 entries (B). The octave from middle C to the B above that plays each sample once; the lower octaves play each sample two or four times. At higher octaves, the code skips every other sample, three out of four, or (for the top C) seven out of eight. All pitches are within 1% of true, and sub-harmonic distortion is restricted to octaves below the correct pitch (e.g. playing the top C generates a little distortion at the C below, but does not generate distortion at other pitches).
I tested a version which used 3x as well as power-of-two rate multiplication and the subharmonic distortion there was just horrid.
-
Each of the 8 cars has its own seperate circuit board. Must have been a very expensive game to manufacture.Even without a microprocessor, I would think one could reap benefits from sharing a significant amount of circuitry between the cars. Though perhaps the game did and STILL needed a big board for each one. Though it wouldn't seem like it would need that much stuff...
Each car would need hardware to count its position (horizontal and vertical, and rotational), latch its shape for a scan line, shift out its shape when the horizontal counter triggers, latch collisions, count laps, and generate sound. It would also need some multiplexors. Not sure what functions couldn't be multiplexed. The shape ROM could be multiplexed by hitting each board once/line to fetch it. Motion could be handled by hitting one board for each of 8 scan lines at the start of each frame.
Microprocessors make it easy to multiplex functionality, but they're hardly essential. Still, maybe it's easier to just build eight of something than design a multiplexer.
-
I think the clever company (ie the one who would have escaped the crash) would have released the 7800 as a home computer.For computing purposes, how would the 7800 be better than the Atari 8-bits? I suppose if one could have afforded the RAM, a 320x200x4-color screen mode might have been nice, but MARIA really seems better suited for gaming than computing.
-
IMO, they kinda went about it the wrong way... a better system would be to have AUDF's value added to an accumulator at each interval, then have a phase transition each time an overflow occurs.A phase accumulator requires more hardware than using a frequency divider; further, when generating square or pulse waves sounds with a phase accumulator, one must use an input clock which is much higher than the desired output frequency or the results will sound terrible. It's certainly possible to design a good sound system around phase accumulators (e.g. Commodore's SID) but the minimum requirements to get anything to sound even halfway decent are pretty steep.
A more efficient way to design hardware for playing music would be to have a programmable integer rate divider (5 bits would be adequate, 6 pretty good, and 8 quite good) along with a programmable power-of-two divider. The biggest weakness with the TIA for music is that none of the wave-shaper settings produce divide ratios that are related by powers of two.
If I were seeking to achieve the best possible improvement in TIA sound generation capabilities with minimal extra hardware, I would probably add about two gates to each channel so that when bit 0 of AUDCx was clear, the channel to be clocked once per scan line instead of twice. That would cause the even-numbered selections to drop in pitch by an octave, thus allowing many more usable pitches. If i could afford a little more hardware, I would add two bits to AUDFx, and arrange for the horizontal scan circuitry to output pulses on three wires a total of four times per scan line in the pattern ABCB. Wire A would always clock the audio circuitry; wire B would also clock it if AUDFx.7 was set, and wire C if AUDFx.6 was set. That would thus allow an effective input rate of 15.75KHz, 30.5Khz, 47.25KHz, or 63KHz.
Of course, it's a bit late to be doing that, but I think POKEY might allow some power-of-two options.
-
How about a hybrid table/code approach:
; Divide value in acc. by 10 and store the result in Y. X trashed. tay lsr lsr lsr lsr tax tya sec; Could this be eliminated? sbc table1,y ldy table2,x cmp #10 bcc nobump iny cmp #20 bcc nobump iny nobump: ... table1: byte 0,1,3,4,6,8,9,11,12,14,16,17,19,20,22,24 table2: byte 0,10,30,40,60,80,90,110,120,140,160,170,190,200,220,240
Sixteen instructions totaling 36 cycles worst-case and 24+32=56 bytes
-
Laser tag does not use lasers, it's IR based.that employed use of a laser (not counting laser tag)?
Many laser-tag sets use visible-light lasers for aiming or for effect, even though they use other means to detect hits. Actually, I would think the best way to detect hits would be to have the target areas of each vest emit a modulated pattern of light and then have each "gun" incorporate a well-aimed photo-eye. When a person is hit, have the gun radio the victim (identified by the modulation pattern).
-
Doing it every frame only serves to move the entire screen down in a constant fashion, which isn't really what we want.If you can cause the system to drop half a scan line, I would suggest doing so at the very end of one field (just before vertical sync pulse) and at the very beginning of the next field (just after the SAME vertical sync pulse). That will leave 262.5 lines between sync pulses on both frames, and even even number of short lines between any displayable scan lines.
-
But the 6507 only has 13-bit (8K) address space? Maybe he already thought about some bankswitching logic inside the atari...Or else about using a full 6502. Not sure which he was considering; bank-switching on systems with proper timing signals would hardly have been unknown, though I wouldn't see much reason not to put the bank-switch logic in the carts themselves.
-
I stumbled into this forum even though I don't know a lot about programming. But since I'm here, I quick question came to mind. Throughout the movie Once Upon Atari there was a re-occuring sense of how difficult it was to program for the 2600. Todd(correct?) Frye talked about how he got a perfect picture in his mind about how he was going to port Gyruss to the 2600 before he started work on it, and then it took him 6 months to implement all of that into code. So anyway, has today's technology allowed 2600 programmers to automate a lot of the processes that used to take so much of their time? I would imagine if it still took 6 months straight on nothing but programming not many people would still be making games. But then again, 2600 fans are pretty die hard so I could be wrong about that.Today's machines allow a much faster edit/build/test cycle than would have been possible for even a well-equipped lab in the 1980's. Further, the trace/log functions allow one to see more easily and precisely what one's code is doing than would generally have been possible.
Were I trying to develop a game with 1970's technology, I probably would have wanted to build a setup with an analog RGB monitor, one channel of which would receive the composite out from the 2600, and two channels of which could be plugged into circuits which would generate either:
-1- A high output during a specified scan line.
-2- A high output on a specified cycle of a scan line.
-3- A high output when a particular TIA address is hit.
I'm not aware of any developer back-in-the-day having done such a thing, but it would have been very useful when trying to get timings dialed in correctly.
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Is Chuck Norris Superkicks finishable?
in Atari 2600
Posted
With the game hacked for invincibility, it is possible to get through far more enemies than would be even remotely plausible in an unhacked version. There is no level advance.