supercat
-
Content Count
7,259 -
Joined
-
Last visited
Posts posted by supercat
-
-
If I understand correctly, these would not be reprogrammable. They would be used so that developers could release SRAM games in a cart format.That is precisely the idea.
I would say that $5 is really ambitious. In large quantities, half of your budget is spent on the PCB alone.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.
I was able to implement most non SRAM bankswitching without a clock. In fact most can be done with only a few logic chips, no need for PLDs or CPLDs. But when SRAM got added, my timing requirements got really difficult. Address read, data read, and write enable hold all needed different timing. I think an RC clock may be too sloppy for this job. I know that my timing was tight, one extra clock pulse and it didnt work (14.7456 MHz clock). Thats why I went with a canned oscillator, so timing was consistent from one cart to the next and one environment to the next.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.
-
I'd agree with that, if for no better reason than that if you're going to violate a cart, I can think of none more deserving than Froggo's Karate. Violate them twice if you can.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
-
This is true, but they look like authentic 20th Century Fox lab loaners. There are several distinct features that help me determine if they look genuine. I can't be 100% sure without actually knowing the trail of ownership, but I feel confident that they are real just from experience.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 guess it's like wanting to own a real cart rather than a rom. It's all about collecting and owning a piece of history.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?
- Address $1800-$1FFF always access the last 2K of EPROM
-
-
-
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?
- ID of owning application (1 byte; application base address/64)
-
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.
-
It would seem that the TIA uses a four-bit counter and five 4-bit comparators to handle the HMOVE circuit, in addition to having to have the five divide-by-160 units and the sequencing logic for the HMOVE. Doesn't that seem a little overcomplicated to you?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.
Hmmmm...I think I see what you mean here. The *only* thing I suspect is signal routing might become an issue since this would also be tapped off of what I call the "master sequencer"...these ancient processes only had two metal layers (and perhaps polysilicon) available for routing. So, yes, you could share a lot of circuitry, but for routing purposes, you might have been better off simply slapping down an existing layout and be done with it
! Again, this is all speculation. I have never seen TIA layed out. Now that I have access to a probe station again, I might dig into this some ! I'd like to actually see what TIA looks like !
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.
Wasn't there a variation where players moved all over the place? I forget....it has been a while! At any rate, all the early two player games where the point was killing one another probably used this missile to player reset. The more I think about it, the more I agree with you that it is rather useless in the longrun overall.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.
-
-
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.
- Front of worm head, in four directions (4 characters)
-
All the same, those games that were meant to be played with a trak ball (Missile Command, Centipede, Crystal Castles, etc.) play surprisingly well with a CX22/CX80, even in spite of the fact that it's still acting like a joystick. The control feels much more natural and responsive. There are some joystick games that even feel better with the trak ball -- mostly those games that require frequent direction changes such as Spitfire Attack, or target games like Crossbow.I wonder if it would be practical to include a REAL mouse interface in the next AtariVox-or-whatever gizmo that comes along? Games would have to be programmed to take advantage of it, but it shouldn't be too hard to make something a game could simply poll when convenient for an X/Y/button readout.
-
When I ported my "Wormy" jingle to the 2600 (quite a few years ago, actually) I wrote a PC program in which I specified the 'importance' of different pitches and then had the program search for the least awful tuning. That actually worked pretty well after I tweaked things a few times. Too bad Atari wasted silicon on the RESMPx circuit instead of adding a 1/2/4/8 prescalar circuit to the sound generators.
-
What about having the user point the stick in the desired direction, but without the stick providing thrust? Use one side button (selectable which one) for thrust, the other for fire, and the 'any key' on the keypad for hyperspace.
-
On the Commodore 64, you could select up to 4 players even with only two joysticks; the other two players would use keyboard for bidding. Since you've got joysticks and buttons, it would seem possible to do the same sort of thing, albeit awkwardly, on M.U.L.E. Especially if the real goal is to have all four "players" cooperate to achieve the best colony score.
-
I recall reading an interview of (IIRC) John Carmack and he was reluctant to release the QuakeC source code for ID's new game not because of fears people would do unauthorized ports, but rather because people would see how sloppy he was. Some parts were sorta cute, though. IIRC...
if (player.inwater) cprint(" sleeps with the fishes."); else if (enemy.classtype==ENEMY_DOG) cprint(" was mauled by a rotweiler."); else if (enemy.classtype==ENEMY_ARMY) cprint(" was shot by a grunt."); ... else /* Hell if I know--he's just dead */ cprint("died.");Been ages since I looked at the code, but I still remember that comment.
-
Your 'calculator', however, can't really determine what is musically the closest fit. Sure it might give you numbers that are closest in frequency to the correct notes, or it might even go so far as to suggest what key to transpose the piece into for a least-squares fit of sorts. But getting good music on the 2600 generally requires going beyond that.
In some situations, a note which is 35 cents sharp might sound horrible and selecting a different pitch entirely might sound better. In other cases, the note which is sharp might actually sound okay and changing it would disrupt the melodic flow of the piece. Your 'calculator' is very unlikely to know the difference.
Also, while some people's opinions may differ, I tend to think that percussion on the 2600 is good for smoothing over intonation problems. That plus it sounds cool.
-
It would probably be possible to come up with something that could produce an arbitrary collection of games which were limitted to Combat-style objects and playfields. Such games would tend to be regarded as not very interesting.
Trying to get graphics beyond the level of Combat or Adventure gets tricky. The games that manage the best graphics have very carefully-crafted restrictions about what objects can appear where, and then use clever tricks the programmer used to take advantage of those restrictions. Crafting a good game on the 2600 requires a good understanding of programming and of fun, to ensure that the restrictions in gameplay don't prevent the cartridge from being enjoyable.
-
...and that leads back to the missile problem. Without a way for the bomber to fire missiles of it's own (i.e. possible for the display kernal to allow missiles to begin mid-screen instead of just from the top), finding a way to add the bomber is a non-issue. The first step would be to reorganize as much of the native ram as possible (combining variables wherever possible...breaking them down to use bits instead of full bytes).This is why I thought 30Hz flicker would be a good goal. Basically, to send out a bomber in frame 1, what you would do would be to create a single missle in frame 1 and set the frame 1 "bomber" flag and bomber X position (possibly Y position, if you can afford to make it variable). Before the display kernel, if the bomber flag is set for the current frame, if the X and Y positions of the missle are both less than those of the bomber, set the Y position of the missle to the bomber altitude minus a little bit.
Then during the kernel, set the player 1 position to the bomber's X coodinate. When about to draw the 'main' part of the frame, check to see if the bomber flag is set. If not, use the normal kernel. Otherwise, use a two-part kernel. First part shows players 0 and the ball normally, but doesn't show player 1 or missle 1. Middle part shows players 0 and the ball along with player 1 (the bomber). This then falls into the normal kernel which is used for the remainder of the frame.
Voila--now there's a plane that drops bombs. If the bomber is destroyed before the missile has become visible, the missile should be silently (and scorelessly) destroyed as well. If the bomber is destroyed after the missile has become visible, its horizontal position should be set to zero but the bumber flag should remain set until the missile is destroyed. Once the missile is destroyed, the bomber flag should be cleared when and only when the bomber is also destroyed or flies off screen.
A bit of magic, but it should be workable.
-
Aw, my magnet was cute. :-)Definitely! Gotta use that somewhere else some time. I think Activision have the effect in Dolphin and/or Stampede.
Certainly in Dolphin; probably in Stampede as well. Star Wars ESP uses it for the walkers' legs, and various other games use for other sorta-big objects.
Still, your point is well-taken. Not everything that can be done, should be done.Hm... I admit I may be lazy here and there as well. When a game is almost done, I get pretty reluctant when someone suggests more or less a total rewrite. Ask Thomas about that, he always tries that
Well, none of my 2600 kernels have been overly complex, but I sometimes rewrite them between one version and the next. My seven-color paint kernel, for example, was limitted to making the cursor be red or icky-yellow. By totally rewriting it, I was able to make the cursor be any color I want.
BTW: I had another thought about a 6 line kernel: With all regular skipdraw techniques used everywhere, I'm sure at some point you'd be running into issues where your branch targets will be farther away than 127 bytes.Sometimes code can get pretty convoluted to deal with that sort of thing. Yeah, it's a pain. I've actually never used skipdraw (heresy?) but instead try to figure out what all I'm going to be doing for a certain section of display so as to minimize the number of conditionals within it. Probably much easier with some game designs than with others.
Well, I like the striped playfield even though it's simply easier to draw than a solid one.
I think my biggest graphics peeve is probably the fact that balloon and string are the same color. That and the fact that my balloon is always popping. 
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Minimal-cost RAM-plus cart ideas (2600)
in Hardware
Posted
I believe 3F and 3E bankswitching work as follows:
3F bankswitching:
3E bankswitching
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.