supercat
-
Content Count
7,259 -
Joined
-
Last visited
Posts posted by supercat
-
-
This would get you down to one ENABL every six scan lines (use COLUBK to hide the ball and playfield on the unwanted scan lines). That plus eliminating some extra playfield writes on the blank rows should free up enough cycles to add more stuff.Interesting idea, but just because you don't see it, doesn't mean it isn't there. The collisions will still happen
Yeah, I'd forgotten about the collisions, but those'd only a problem for the playfield, not the ball. Unless you think someone's going to sneak through the one-pixel gaps in the ball. So you could still save a little on the ball positioning logic.
You'll probably lose cycles on other places. Your unrolling suggestions makes the PF drawing easier, but it complicates the Sprite drawings.You can still INY (or whatever register you like) six times within the unrolled loop.
If you add a little padding on the balloon data, you can get by with checking the Y coordinate once every six scan lines instead of every scan line.That's ~ 10 bytes extra for each shape/HMOVE table, as you'd need to pad on both sides. Besides blowing up the data, it'll complicate things again on other ends, as this data will no longer fit into pages and stuff.
I'd not looked at your allocation to see how it's laid out.
Indeed, there are all sorts of tricks that become available when loops are unrolled.A tradeoff indeed. I choose to go another route. In my cost/gain analysis a somewhat better looking magnet ain't worth all the fuss involved to get there
(Not even considering the required ~500 extra bytes of ROM.)
Aw, my magnet was cute. :-) Still, your point is well-taken. Not everything that can be done, should be done. On the other hand, I do find myself thinking that you got a lot more out of the display system in Gunfight and Starfire than you do here, so there oughta be room for a little 'extra'. Though perhaps with Gunfight you weren't concerned with leaving ROM for more levels.
-
That could work, however, some gamers might be upset when the balloon doesn't move right from the start of the level if they have it held, because it could make them lose that fractional second. In most games, if you're going for speed, this wouldn't matter too much, you'd just get used to it, move that exact moment and not complain, but in this case, your controlled sprite isn't static, and could be in the wrong position because of this. i.e. You have to fit through a small gap, but because of that fractional delay, you have to sit in one spot for a sprite animation cycle before you can safely fit through.How about making the game wait until the joystick is released following the end of a level or balloon pop?
-
Is there any way to set Z26 so it'll flag a glitch if a frame is the wrong length? I know it has a function to show the number of scan lines and frame rate (though I'm puzzled by why 263 scan lines shows up as 62.xxHz), but that won't show if any individual frames are off-spec.
-
Pac-Man does 15Hz flickering, and it works, though it is a little annoying.Most people would regard it as intolerable; indeed, it's the primary reason the game is so despised.
Maybe another option to make the plane more visible would be to make it 30 Hz and the explosions 10 Hz each, though the explosions might start looking pretty bad by then. Still, if you can fugure out how to get a plane on there, I'm sure you could also figure out how to make it fire missiles or even smart bombs
As noted, the approach to get 30Hz flicker with the plane is simple. Have it only appear when it can drop a missile, which is to say when either (1) there is at most one group of missiles on screen, or (2) at least one of the groups of missiles on screen has only a single missile and it's targeting something other than the rightmost city/base, and the timing is right.
In the former case, the plane occupies the opposite frame from the group of missiles that's on the screen. A new missile is created which will reach the height of the plane at the same time as the plane reaches its X position; display of the missile and collision-detection for it will be inhibited on scan lines above the plane [alternatively, the height of the missile could be locked at the top of the screen until the plane reaches the right X coordinate, whereupon the height would be set to that of the bottom of the plane].
The latter case would be trickier, but might add some variety. Here, the plane would only appear once because NUSIZ would be zero. The plane would have to be timed to be 32 or 64 pixels to the right of the missile when its altitude reached the bottom of the plane. From that point on the frame downward, NUSIZ would be set to 1 or 2. This approach would be trickier than the first, since the timing on the plane would have to be correct. Could still be pretty cool, though.
-
Actually it's a 2 line kernel. In 2 scannlines it does 6 PF, 2 GRP0, 2 HMP0, 1 GRP1, 2 ENABL, 2 HMOVE.Ah. I'd figured you would have unrolled the inner loop three times to eliminate annoyances like division by three, etc. A time-space tradeoff to be sure, but it pays off big. This would get you down to one ENABL every six scan lines (use COLUBK to hide the ball and playfield on the unwanted scan lines). That plus eliminating some extra playfield writes on the blank rows should free up enough cycles to add more stuff.
BTW, the design of the magnet demo was predicated upon the idea that in a six-line kernel, one will have time on some scan lines but not others; the magnet moves could be done when time was available.
Vertical positioning of all writes besides HMOVE? That the kernel does a divide_by_3 in order to display the playfield? That the kernel has to reset the stack pointer? That even though it is a 2 line kernel, the balloon is rendered (and moved!) with single line resolution? Some general timing overhead here and there, where you're forced to buffer a value first to get it then written in time? General display loop overhead?Well, the loop overhead goes down to once every six scan lines if you unroll the loop, and some other things get simplified as well. If you add a little padding on the balloon data, you can get by with checking the Y coordinate once every six scan lines instead of every scan line. Indeed, there are all sorts of tricks that become available when loops are unrolled.
-
Unlike some other video systems which generate RGB and then turn it into composite, the TIA (and all other Atari 8-bit video systems as well) generate luminance and chrominance signals directly. The only way to turn that into RGB is with a chroma decoder of some sort. If you want optimal quality, the best approach would probably be to use five sample/hold circuits. The first three should take the composite signal and sample it at different phases of the chroma clock. The last two should be sample the outputs of the first two at the same time as #3 is sampled. If you get the timings right, this should yield a smear-free RGB signal that's pixel perfect.
-
It would most certainly have a lot to do with the above. I'll have to play around with that, since being able to move eight pixels left could be useful.
-
Wow. Now *that* is cool. I know "No Promises!", however, it's great to see an actual binary doing something.Too bad Mario can't get very far.
I must agree with earlier comments by supercat. The first screen is actually very well done. Graphically, what has always bothered me is not so much Donkey Kong, but Pauline. To this day, when I look at her, she appears as a creature rather than a person. Mario, on the other hand, I always believe looks very well done.I'd not looked at her critically, but agree with you. Using missle 0 to give her brown hair (and thus letting her skin be a more reasonable shade) would probaly have improved her considerably. Since there's no action on those scan lines, cycles should be available.
And yes, once again, I must agree with supercat. The gameplay on the rivet board is weak. It could definitely use some improvements. However, I would prefer to see the addition of the two missing boards over improving what is already there (Then again, I would love to have my cake and eat it too)! Seeing the additional boards added *and* improving what is already present would be a dream come true.Well, the elevator and conveyor screens both have fireballs, IIRC, and they should probably be made capable of climbing ladders. If that's done there, I'd see no reason it shouldn't also be done on the rivet screen.
-
Somewhere on the web, I once found very detailed documentation of the Odyssey 2's inner workings. It is actually more advanced than the 2600, but seems to have been designed with very specific game ideas in mind, which makes it limited in some ways. But I think that it is a very capable machine, and its potential was never fully tapped.Look earlier on this thread. I'd say there were three main issues with the O2:
-1- Most of the on-screen display objects must be drawn from a pool of 64 shapes, most of which are rather bland.
-2- The display documentation warns that bad things will happen if display registers are written mid-frame, but some games apparently do so without ill effect, so the restriction doesn't seem to be absolute; I don't know what the actual rules are.
-3- There was little third-party interest in the game until it was too late to matter.
Some of the later games show that it's possible to do a lot of things with the O2 that its designers never dreamed of. Unfortunately, the O2's situation didn't get beyond that the 2600 was in back when Atari was cranking out all the different variations of Combat and Air Sea Battle.
Indeed, I would expect that if you had shown a lot of O2 games to Atari's programmers/engineers back in the late 1970's, they would have thought the O2's games were far beyond anything their unit could do. Fortunately for the Atari, a lot of programmers weren't content to live within the 2600's limitations so they worked around them.
-
Mr. Frye being the author of the first Atari Pac Man? If he was in a good mood, I'd think he'd give a four-word answer to the effect of "Four kay six weeks" (or whatever his time limit was).
-
Really? What all is the kernel doing? In each group of six scan lines, the kernel writes each playfield register eight times, COLUBK twice, GRP0 six times, GRP1 six times, HMP0 six times, and HMOVE six times. Thirty-four writes. If each of those writes takes an average of ten cycles, that's 340 cycles out of 456. What am I missing?
-
Many people consider the comb to be a bug, because it can look ugly. I wonder if the designers might have put the comb in on purpose as a means to scroll sprites off and on the edges of the screen. Without the comb, a sprite off one edge will appear sticking out on the other side unless you do some nifty tricks in software. the comb is the same width as a standard sprite (8 pixels). So a programmer can use the comb as a sort of virtual backstage curtain to move sprites in and out as if entering or leaving a stage.Unlike most video chips which uses a position register for each sprite and have logic to check when the beam reaches the specified position, the 2600 uses a different scheme (which possibly saves a few transistors, though given some of the weird stuff they added to deal with it I don't know how much it really saves).
Each sprite on the 2600 has a counting circuit which will trip every 160 pulses. Normally there are 160 pixels on a scan line, and so the counter will trip at the same location every scan line. This would be all well and good if all you wanted to do was display a sprite at whatever position it powered up at and never wanted to move it. In practice, though, being able to move sprites is nice (well, actually pretty much essential for making any sort of playable game). There are two ways to move the player sprites and the ball, and three ways to move the missiles.
The first way to move any of these objects is to write to a special location, called the object's "reset address", which will cause the object's counter to be zeroed. This will cause the object to appear on every scan line at whatever X coordinate the electron beam happens to be. It is fairly easy to position objects to within +/- 7 pixels of any desired position (a 15-pixel range) by executing a variable delay loop before hitting the object's reset address. With trickier code, accuracy can be refined to +/- 1 (a three-pixel range). Placement more precise than this is not possible when using the reset address alone.
Because the designers of the Atari figured people would want more precise object placement than would be allowed using just the reset addresses, they added a ludicrously complicated bunch of circuitry which may be called the "hmove circuit". The HMOVE circuitry does two things:
-1- It feeds sprites' position counters an extra 0-15 counts during the horizontal blanking period. In the absense of part 2, this would have the effect of moving the sprites 0-15 pixels to the right.
-2- It disables counting (and video) for the first eight pixels of a scan line. This has the effect of moving all five sprites eight pixels to the right (offset by whatever amount they were moved in -1-).
There are many other weird and wacky intricacies with the TIA, and it must have had a somewhat interesting evolution (I don't think counting to 160 is really any easier than counting to 168, and if the counters did the latter there'd be no need to blank the first part of a display line when performing an HMOVE.
BTW, method #3 for moving missles is to program the hardware to trigger a reset of the a missle position counter when its corresponding player sprite has just output its fourth pixel of display data. Combad uses this when the player fires, but I really don't know of much other usefulness for this feature. Seems a waste of silicon that could have been better used elsewhere.
-
'you're smoking wackey weed' etc.Well, I used -all- 2600 sized pixels in those images, kept it to the number of scanlines a 2600 has and limited the colors per scan line.
The 2600's restrictions go much deeper than that. I posted earlier exactly what the 2600 has to work with. A few cartridges can go beyond the restrictions listed (Galaxian does admirably) but generally you get exactly what I listed and nothing more.
If one were coding for an 8K or larger cartridge, one could certainly do better than what Garry Kitchen did in 4K. On the other hand, if Garry Kitchen were coding for an 8K or larger cartridge, he could probably have done better as well.
The barrel screen is IMHO just fine. Some things could be improved slightly, it looks pretty decent. The biggest thing to investigate would be smoothing Kong using the sprite-shift technique in which selected pixels of a double/quad sprite are shifted to the right by one/two pixels. Since nothing movable appears in that part of the display, this would be feasible for a comparatively modest code expenditure (probably about 30 bytes).
The biggest problem with the game is the rivet screen, where the issue isn't graphics but gameplay. My personal design recommendation would be to assume full-time 30Hz flicker on the monsters and give each monster a two-level range of motion. This would improve gameplay interest considerably without being unreasonable to code. Unfortunately, the code to let the monsters use ladders would almost certainly push the cartridge beyond the 4K ceiling.
The "wicket" screen would certainly take more code space than would be available on a 4K cartridge, but would otherwise not be a problem. The mudpie screen would be doable if the fireballs were not allowed on the same lines as the mudpies, and provided that all the mudpies on a row moved in the same direction. Some other 'tricky' restrictions would also apply to the mudpies, but they're too complicated to discuss here.
Could Mr. Kitchen have done better given a larger budget of code space and time? Certainly. Given what he had to work with, is the result unreasonably bad? I think not.
-
At the local arcade, the repair guy uses a butane iron. Not quite sure why (it's not as though there's no electricity available) but he seems to like it.
-
That's why I'd think it would require an 8K cart, though actually I just had an even simpler idea (which would probably also require an 8K cart :-( since there's not a whole lot of code space) which would be to recognize that the whole point of a plane/satellite is to drop a missle, and so there'd be no point in having one come out when both "frames" of missles were already occupied. Thus, with 30Hz flicker the plane/satellite would be in-frame with a "single" missle.
If this could be done and still fit within 4K that'd be cool. On the other hand, since even that would probably push things beyond 4K one may as well bite the bullet and use multiple kernels to eliminate satellite flicker. Though I just had another thought on that subject: if one were really clever, one could have a single missile come down and be timed so that a plane/satellite would "drop" a second or third copy. The copy dropped by the plane would have to be the rightmost one unfortunately, but the effect could still be somewhat neat and it would make the gameplay less "wimpy" than only allowing one set of three missiles on screen when the plane/sat was on.
-
Regarding the bomber/satellite idea, a simpler solution is to reuse the player code that is currently in place for the player's shots. It currently uses 3 frames (1 per shot), so that area of the code could even be cleaned up a bit by using a nice round number of 4 frames (i.e. frames 0-2 = explosions, frame 3 = bomber/satellite).Explosions flickering is fine. After all, they're explosions. And 30Hz flicker on missle tracks is fine, since it's barely perceptible. But 15Hz flicker on an airplane or satellite would be intollerable.
Besides, if the code is expanded to an 8K+ cartridge and uses 7 copies of the display kernel (selected based upon the X coordinate of the plane/satellite) there should be no need for the plane or satellite to flicker.
-
The plane/satellite would have to be the same color as the missiles, and it can only be present when only using single copies of M0 or else there will be 2-3 planes/missiles, unless you add more flicker. And significant rewriting would need to be done if the plane or satellite is going to launch its own missiles. Would be a hard task.
If using an 8K+ cartridge, might it be possible to clear GRP0 immediately after the desired copy of the plane is drawn? -
Satellites wouldn't be possible I don't think, since there's no spare player sprite available. A somewhat-goofy-looking bomber plane might be possible using the ball (if the cursor doesn't) but even that would probably require a kernel rewrite.
-
Am I the only guy who'll stand up for this game? To be sure, a couple of slight hacks would improve it considerably [change the background color between 'zones' to make the boundaries clearer, and erase the sprite data for the obstacles] but despite its limitations I do find the gameplay compelling. Perhaps I'll code my own version with a few more improvements and see how that plays.
-
What do the graphics look like? Since the O2 only has four sprites, I'd think they'd have to so something interesting to 'jinx' the graphics, but I can't think how that would work. I don't think the 8048 is fast enough for 'venetian blinds'; does the cart do somethng else?
-
Cute game. Somewhat addictive, though I never get past the Green Zone. Those chopper packs sure don't seem to last long (at least not with my piloting). But I can't figure out what the other power-ups are for or what they do. Can you enlighten me?
-
Sorry, I'm not sure if I get you. Can you somehow visualize that?Uh, sure. Run this:
; Magnet-drawing demo processor 6502 include "vcs.h" include "macro.h" seg org $F800 magnet: byte $3E, $7F,$7F,$7F, $FF,$FF,$FF, $FF,$E7,$E7 byte $63,$63,$63, $63,$63,$63, $66,$66,$66 byte $66,$66,$66, $36,$36,$36, $36,$36 magmove: byte $00,$10,$00,$F0,$00,$10,$00,$F0,$00 magcolor: byte $4C,$48,$48,$48,$48,$48,$48,$48,$48 DoFrame: botlp: sta WSYNC lda INTIM bmi botlp lda #$42 sta VBLANK lda #2 sta VSYNC sta WSYNC sta WSYNC sta WSYNC lda #0 sta VSYNC sta WSYNC sta WSYNC lda #20+127 sta T1024T ldx #31 toplp: sta WSYNC dex bne toplp lda #0 sta VBLANK lda #$86 sta COLUPF lda #5 sta NUSIZ1 ldx #8 ldy #0 nop nop nop nop nop nop sta RESP1 nop nop sta RESM1 lda #$00 sta HMP1 sta HMM1 lda #2 sta ENAM1 drawlp: sta WSYNC sta HMOVE lda #$00 sta PF2 lda magnet,y sta GRP1 iny lda magcolor,x sta COLUP1 lda magmove,x sta HMP1 sta HMM1 sta WSYNC sta HMOVE lda #$FF sta PF2 lda magnet,y sta GRP1 iny nop ; Get clear of HMOVE 'no zone' nop nop nop nop sta HMCLR sta WSYNC sta HMOVE lda #$FF sta PF2 lda magnet,y sta GRP1 iny dex bpl drawlp sta WSYNC lda #0 sta GRP1 sta ENAM1 lda #$42 sta VBLANK rts RESET: lda #0 tax resloop: dex tsx pha bne resloop cld FrameLp: jsr DoFrame jmp FrameLp org $FFFA .word RESET,RESET,RESET END
That should give you a pretty good idea of the effect I'm thinking of.
-
Eightfold ROM expansion; sixteen-fold RAM expansion. Seems like a reasonable balance. It would be possible to add more RAM if the upper-order address lines were shared with the ROM, but that would mean that each half of the RAM was only available from within half of the ROM blocks; I would expect that in most cases this would be more trouble than it was worth. Adding jumpers to control this option might be possible, but would add to the cost. Using a more sophisticated PLD instead of a 22V10 would eliminate this restriction, but it would also increase the cost.
-
Now for the worst games IMO.Burgertime
Basic Programming
Burgertime didn't seem all that bad. To be sure, it used missles and the Ball to represent three of the enemies, but that allows the enemies to appear on the same scan line without flicker. The appearance might have been less annoying if the code moved those objects as it changed the width so as to make them spin about their center rather than the edge, but I would say the programmers did a reasonable job of trying to deal with the 2600's limitations.
As for Basic Programming, I think it unfortunate that Atari didn't bundle a keyboard with it. Extending the normal keypad scanning techniques to a device that plugged into both controller ports would have allowed for 48 buttons. Not great, but it would have avoided the need for four different shift states.
Be that as it may, the Basic Programming cart would seem like a pretty amazing accomplishment. Managing to get such a cart working while leaving half of the 2600's memory available is pretty amazing and I have no idea how Mr. Robinett accomplished it. My guess is that he must have re-used a lot of memory locations on-the-fly, but I still find it hard to believe. BTW, I wonder if would be adaptable to the SuperCharger? That'd allow enough user RAM to make things almost worthwhile.
Also, BTW, I just tried Stellar Track. Pretty faithful adaptation of the classic 'mainframe' game, though I do find some things a bit puzzling. Although I remembered the directions 1-8, I have no clue why this game would use those instead of arrows. I also found irksome the fact that impulse engines won't allow the ship to leave a sector (in the classic versions, they would go to the edge of the next sector).
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
A2600 Video Display Question
in Atari 2600
Posted
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?
Perhaps there's something in the hardware that makes it simpler than it sounds, but some of the quirks suggest that they did not use any of the simplifying approaches I can think of.
I find this puzzling, actually. I would think the simplest way to handle the hardware would be to have four derived signals during hblank which pulse (non-overlapping), one, two, four, and eight times. Just AND these signals with the appropriate bits in the HMxxx register and use that to add clocks.
When I said "count" to 160/168, I didn't necessarily mean using a binary ripple counter; I meant simply have a circuit which produces one output pulse every 160 or 168 input pulses. While the counter circuitry used to generate scan lines may divide by four and then divide by 57, the sprite circuits clearly divide by 160, since it takes 160 pulses to move them an entire line.
Air Sea battle might possibly use it, though there's really no point since the player's gun is always in the same spot. Most other games care about the shot X position, and would thus have no problem manipulating it directly.
The delay registers are necessary for many useful effects, though the term "vertical" is a misnomer. I find it interesting that the function is implemented using a mux instead of simply forcing the second register to act as a transparent latch when the delay is disabled.
Eh, rambling is fun. BTW, my biggest wish-list item on the 2600 would probably be a circuit which would generate four pulses per scan line and allow the user to have one, two, three, or all four routed to the sound circuitry. Would greatly improve the 2600's otherwise-attrotious intonation.