supercat
-
Content Count
7,259 -
Joined
-
Last visited
Posts posted by supercat
-
-
The ability to coax the SID into producing an 8-bit DAC value is pretty cool. Too bad the top frequency isn't higher. I wonder why they chose to use a 24-bit phase accumulator? The 4KHz top frequency isn't all that high, and 1/8 or even 1/4Hz frequency accuracy would have been just fine.
I know the Atari 2600 can produce nice-sounding four-voice music using two four-bit DACs running at a 15.75KHz update rate. It might be interesting to cram extra voices out of the C64, but the 8KHz sample rate limit and requirement for precise timings would make things somewhat difficult.
-
It might be interesting to have a RAM-game contest for the 2600 and maybe also one for the 7800. Any size cart could be used for initialization (though anything over 2K would probably be pointless), but once the game is running it can't use the cart any more. In theory, one could pull the cart and the game would continue to run (in practice I wouldn't generally recommend it). I wonder how much of a 2600 game one could do in 128 bytes (or more, for the 7800, but not a whole lot given the required layout of display lists).
-
A cart to capture the state of a 2600 could probably be constructed, though making it reliable might be tricky. The best way to do it would probably be to have the cartridge take over operation when it sees a store to VSYNC; the cart should disable the other cartridge, stuff code to JMP $1000 (while noting the address from which it was fetched), store the CPU registers to cart space, and then probe the TIA state as well as it can. Wait the proper length of time to complete the frame and let operation resume. It's not possible to probe the entire TIA state, but it may be possible to glean most of it if one doesn't mind trashing a few registers. Most cartridges reload most registers each frame, so trashing a few registers shouldn't disrupt things.
-
I'm sorry - but where is your proof that I thought wrong? The clocking is the same as required for the high res case and the internal circuitry is actually smaller - rather than 4 16 bit shiftregisters and 4 16bit latches ( for the ST case ) I can implement a similar system with 1 16 bit latch and as little as 20 bits of shift register..The EGA system used a planar architecture in part to allow faster programming (though the usefulness of those features was limited until the VGA added a couple of practical enhancements). For certain applications, the planar design is very nice; for others, it's a pain in the tush. Nobody uses those modes any more, but for some purposes they worked quite well.
As for hardware complexity or simplicity, planar modes make it easy to support an arbitrarily-variable number of bits per pixel. Using two or four bits per pixel may be more convenient in a "chunky" system than in a planar one, but what about using three or five? A bit-plane architecture which is equipped to handle pixel-level shifting of two sets of bit planes may use the two sets individually to produce an parallax-scrolling background, or together to produce more colors.
Unless one is using byte-sized "chunky" pixels, I don't see a huge difference between planar and chunky approaches for most applications.
BTW, I wonder what machines have used interesting addressing tricks to allow a processor to view memory in different formats? Rescue on Fractalus on the 7800 omitted an address line from its RAM chip, so as to allow each byte of RAM to be displayed twice, but what other tricks have been done?
-
I am not a HW dude so I may be mistaken on this approach, but I thought that because the 6507 in the VCS uses CMOS it is possible to use a Wired-AND approach. Such that if you have the processor always drive the data lines all high ($FF), then the cartridge hardware can pull the data lines low to make any data value.The 6502 and TIA are NMOS, not CMOS; NMOS does behave somewhat as you describe (many CMOS do not), but I would be extremely loath to design around the fact that a CMOS "low" will win over an NMOS "high". The 6502 will not generally be destroyed by an occasional conflict on the data bus, but that does not mean that thousands of bus conflicts per second wouldn't take a toll. Although the pull-up transistors on the 6507 are not nearly as strong as a modern CMOS pull-down, the device does use active pull-up transistors which are not intended to be overdriven.
BTW, a 6507 can be damaged by trying to drive an address pin high with a CMOS output. My 2600jr needs a new processor because of that.
-
So here's the idea: Make a cartridge with a fast onboard processor and memory, etc. that creates the ROM image for the game system on the fly. The actual game programming could be handled by the onboard processor and the "generated code" could be mostly immediate loads and then stores to hardware registers. So the 650x processor on the 2600 only has to deal with the hardware.Generating code completely on the fly would be possible, but annoying. I have an approach which should allow much of the benefit of full on-the-fly generation while maintaining a reasonably clear emulation model; I had planned to use it for last year's Christmas cart, but those plans got somewhat derailed. It may appear in next year's, however.
-
Supercat, I really wish I knew what the heck you are talking about here; 151 bytes for the entire alphabet would be great. I just made another scroller when I was messing with Solar Nexus, and still used the same awful method more or less:Each byte of data represents one column of seven dots; seven bits the dots, and one bit to mark whether a column is the last one. Characters are one to five columns wide, and the shapes are thus represented by 1-5 bytes. Each byte in the "string" shows where that character's data starts in the shape table. What more help do you need?
-
I wonder what the best way to handle "copy-protection" issues would be? It may be possible to make money on a popular game for a popular computer even if 90% of the copies out there are pirates, but on a comparatively obscure console that's not going to work. I have some ideas for how things could be implemented, but I'm not sure what would be best.
-
Yeah, sure CPU can help both sides to some extent, but ultimately hardware support is better in this case as 4 multifrequency DACs cannot be made up for by software.In many cases, I think one should evaluate what a sound chip can do if there will be periods of 1,000 cycles or more during which one is not allowed to write to it. Many sound chips can do marvelous things if one is willing to babysit them constantly; even the Atari 2600 can do nice four-voice music with a five-octave range (15.75KHz sample rate), if one doesn't mind spending 60.5% of the CPU cycles on EVERY scan line processing the audio, but for the most part such techniques of sound production aren't practical within a game. Both the SID and POKEY have unique abilities; the SID's filters are unlike anything on any other machine, and the POKEY's four-voices cannot be matched by the SID's three.
-
If each pixel is subdivided into 15 sub-pixels, then for hue values other than $00, about half of those will be lighter than the other half. For one hue value, the light ones would be first; for the next hue value there would be one dark, then half light, then the rest dark. There is thus some control over where to place the brightest part of the pixel.
If it were possible to set the hue for a single 320-mode pixel, such ability could be used to achieve high resolution when viewing stuff on a monochrome screen (on a color screen, chroma artifacts would make it impossible to see fractional pixels). Unfortunately, the hue is set for a pair of 320-mode pixels; consequently, while one could make the left half of a pixel lighter and the right half darker, or vice versa, or the center two quarters lighter and the left and right quarters lighter, or vice versa, there is no way to make the left quarter lighter without also making the right quarter lighter. I thus don't see any strong prospects of showing a usable 640x200 screen.
-
I read somewhere that sega genesis turbo controllers have been used with the 2600's synthcart, but you are limited i which sounds you can access using the turbo buttons. So, I though I would build my own controller to access all 24 sounds while also being able to control the speed of the turbo.I don't see much point in trying to build a crazy complicated piece of electronics for that purpose. If you're seeking to use the 2600 as a performance musical instrument it would be better to figure out what exactly you want to do and have someone write some suitable software, probably in bBasic. The keypads are not designed for rapid operation, and trying to pulse them quickly would probably not yield the results you're after.
-
You could update the player graphics, but you probably wouldn't have time for drawing an asymmetric playfield, for example.Probably not for drawing a full asymmetric playfield, but if one is using the 'copy' mode rather than 'mirror' mode, one could use VBLANK to hide places where the playfield really shouldn't be duplicated but is anyway. My Ruby Runner demo did that (it shows the middle 80 pixels of the screen).
-
None of the secret rooms or the easter egg are revealed in the playthrough, I was just trying to complete the game as fast as I could and watch for any bugs that might have come up. It does reveal how to beat the game, so don't watch if you want to be able to figure that out for yourself. In order to make it easier for me to finish it quick, I enabled a cheat for myself so I could replenish my health at will. You may see me stop in the game for a brief second several times, that's when I'm cheating and adding to my health.
The only issue I came across during this playtest was a few times the falling rocks in the locked caves were larger. I'll look at correcting it, although I did kind of like it that way, even though it was unintentional.I hadn't looked at this game before. It seems quite nice. One caveat, though: it looks as though the screen is bouncing up and down a bit, probably related to sprite positioning. Have you looked into that, or would you like any help?
-
It's possible to create interesting "Z-ordering" by selectively blanking parts of a sprite. Toyshop Trouble blanks the portions of sprites that go "behind" the edges of the conveyor, for example. You'll need enough RAM to hold the sprite that will be partially blanked, and some creativity will be needed to make things work. I'm not sure such an effect would be practical in bB, though if there's room for the sprite it might be workable. Here's a more extreme demo of the approach. Move the man with the left controller and observe that he goes in front of some objects, but behind others.
-
Ah ok. So the book is right then.Not quite. The Atari 2600's horizontal motion circuitry is rather complex, and I doubt that more than a handful of people back in the day ever understood it (and I suspect none understood all its wrinkles). The horizontal motion circuitry is designed to hit each sprite with 0 to 15 extra motion pulses during horizontal blanking interval. That would have the effect of moving the sprite 0 to 15 pixels left. To allow sprites to move rightward, the TIA designers engineered the TIA so that an HMOVE would blank the first 8 pixels of the following line and disable the motion pulses that would normally occur there. Eliminating the first eight motion pulses effectively moved all the sprites eight pixels rightward. If the horizontal motion registers were set to output 8 pulses, the 8 pulses they output would offset the eight pulses that were blanked, leaving the sprite's position unaffected. If it output fewer than eight pulses, the sprite would move right. If more than eight pulses, it would move left.
There are two ways to reposition objects without blanking the left 8 pixels of the following scan line:
-1- Set the sprite's position to a multiple of three pixels using RESxx and don't fine-position it with HMxx/HMOVE. For shapes that are at most six pixels wide, one may achieve pixel-level control by selecting one of three different versions of the sprite shape. Both approaches were used back in the day, but I don't know if they were ever combined (the only use I'm aware of for the latter is in Galaxian).
-2- Hit the HMOVE register just before the start of horizontal blanking. This will trigger the pulser circuitry for the usual 0-15 pulses, but it will not trigger the blanking circuit for the next line. The net effect is that sprites will move 0-15 pixels left (instead of -8 to +7) but the HMOVE "bar" will be eliminated. I am unaware of any game using this technique in the twentieth century.
-
...but the Stella programmer guide states that playfield priority (bit2) should be off when using score mode.Setting playfield priority causes anything that would be shown using COLUPF to take precedence over anything that would be shown using COLUP0 or COLUP1. Electrically, score mode causes the playfield to be drawn using COLUP0 and COLUP1 in addition to COLUPF. If COLUP0/COLUP1 have priority, that will effectively cover up the COLUPF-colored playfield. But if PFP is set, the COLUPF-colored playfield takes precedence.
-
Indeed, I think Stargate is easily one of the most technologically advanced titles for the VCS. I was very much stunned by the level of detail and the amazing sound effects that were used on this cart. Anyone know off hand how much memory was used on this one?Impressive indeed, especially given that it's only 7.5K+128B.
-
1) Were you able to accomplish this using a modified batari kernel, or was the display kernel built from scratch in assembly?Custom kernel. I think it's possible to use custom kernels within VB, but I don't know how it's done.
2) Is the rain created with a sprite or the missiles? I really like the fast rain. Much better than either of my shower attempts.The rain is implemented using the Ball.
3) Could you explain the difference between the different states shown on "Difficulty A" with joystick up, down, left and right? Are the using the same half-res sprites, but are flickered differently?The kernel uses four shape pointers and four color bytes: even frame even line, even frame odd line, odd frame even line, and odd frame odd line. Presently, there are two shapes defined in the code.
Pushing the joystick up or down forces the kernel to display only even frames or only odd frames. One of the difficulty switches controls whether the even scan lines show the same frame as the odd scan lines, or whether they show the other frame. Note that if you were to use different shape data for the even and odd lines, you could improve your vertical resolution if you use flicker, and may be able to improve apparent resolution for areas of the 'bright' color. though testing would be necessary to determine what actually looks good.
-
A DIP switch inside the case selects the 3 modes of operation -Do you have any thoughts about a practical way to use an Atarivox plus a second joystick?
-
Supercat, in your BTP demo, did you have to design a wavetable for every combination of pitch-pairs you used, or is there a way to generate that on the fly? In other words, to get 4-voice textures (which in this case is 2 voices per channel), do you have to pre-generate every conceivable interval between the two voices -- one wavetable for a minor second, one for a major second, and so on up to an octave and beyond? If so, I'd imagine that makes it difficult to have different rhythms in the two voices without a lot of careful planning.Two wave tables for each pitch from middle C to the B above (one for loud, one for soft). There are also twelve modulus tables (one for each pitch). Each channel mixes two waveforms selected from those, independently selectable for 1/4x, 1/2x, 1x, 2x, or 4x speed; the C may also be played at 8x. The Stay Frosty tune uses the full 5-octave range.
Getting a 4-channel wave-table synthesizer to run in 46 cycles/sample was no easy task (note that 6 cycles were spent on STA AUDVx, leaving 40 to do the computations). The code is unrolled in an interleaved 4-line pattern, so generating four samples requires, for each voice, four LDY zp, five LDA (zp),y or ADC (zp),y, and one STA zp (40 cycles in all).
-
Or, to take a more advanced example, the voice samples in Quadrun and Open Sesame -- I assume they're somehow generated through rapid toggling of square waves. But how does that work? Does Supercat's 4-voice demo of "The Entertainer" use the same method? I notice that he's able to keep an onscreen display going while playing the music, whereas the other two titles have to blank the screen.Open Sesame can show a display while outputting its "speech". In that sense it's more sophisticated than Quadrun.
Pitfall II, Quadrun, and Open Sesame all work by setting AUDC0 to zero and banging audio out AUDV0. My BTP2 demos, and the Stella's Stocking menu use both AUDV0 and AUDV1. Basic speech output at 7.875KHz would require less than 30 cycles per line pair, so keeping up some sort of display shouldn't be a problem. The BTP2 driver uses 46 cycles per scan line for 15.75kHz output; showing a good-looking display in the remaining 30 is a major challenge, but in Stella's Stocking I was able to manage it (the title screens drawn by Nathan et al. would be considered good by 2600 standards even if they didn't have fancy music playing; a new banking scheme was necessary to free up enough cycles for stuff to work, but the music in Stella's Stocking is all generated by the 6507.
With regard to using fractional-frame timing to generate phasing effects, that would be theoretically possible, but difficult. The Atari's sound channels each have a five bit counter which counts twice per scan line and is reset to zero if, at the start of a count cycle, it equals AUDFx. When it resets to zero, it also triggers the AUDCx-based noise shaper circuit. Note that when changing from a lower frequency to a higher one, if the programmed value goes from being higher than the counter to being lower, the result will be a longer-than-normal wave cycle as the counter misses the programmed value and runs until it wraps at 32. If one were trying for subtle phasing effects, the audio disruption from that would almost certainly ruin them.
It would probably be possible to generate some very nice phasing effects by changing AUDFx at appropriate points in a frame, but one would have to always be aware of what the frequency counters were doing. Probably more complicated than would be worth bothering with.
-
How about Combat? With two players of matched skill, it's a lot of fun. But it's often viewed as the generic 'had to put something in the box' game.
I'll admit, though, Sears may have had the right idea with Target Fun (Air-Sea Battle), since that does include some one-player options. Not great, but none of the games from the first set were very good as single-player.
-
I don't understand the rationale of requiring the player to waste a slingshot before being able to turn on a lamp. I would think it would make more sense to design things so that aiming at a lamp point-blank will turn it on without using a pellet.
I would think the game should fit pretty easily within the 2600's abilities, especially if there were only one lamp, desk, or other object per line (it would be possible to handle two or three such objects, plus the player, using 30Hz flicker, but I think it would be nicer not to). I'd also be inclined to allow the player to move smoothly if practical; I see no particular reason that shouldn't work.
-
LOL!!!! Gigilo looks really funny.... i'd play it.Cathouse Blues is about the only "adult" games that I've found playable; Gigolo is essentially the same thing. At least in Cathouse Blues, prostitutes walk to their houses (hence the title of the game); the player has to remember which houses have prostitutes, and visit each of those only once. There doesn't seem to be any particular reward for visiting all of them (other than to watch more prostitutes walk to houses) but the overall play mechanic could be the basis of a decent 'decent' game. AVGN missed Burning Desire (similar to Jungle Fever, but with sex roles reversed) and Lady in Wading (Knight on the Town), but also missed one title which is very different from the rest: X-Man.
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
RAM Racer
in Homebrew Discussion
Posted · Edited by supercat
According to page 2 of the schematic, the collision latching logic is gated with /VB, which is the inverse of the vblank register. The TIA, of course, has no way of knowing whether the electron beam is over a displayable part of the picture tube, but it gates using the VBLANK register. Interesting to know.
As for horizontal, that might be worth some experimentation. The collision logic on page 2 does not seem to take into account the /HB signal (horizontal blank), and the signals it samples (pp. 3-4) are synchronized to CLKP (a clock that runs 228x/line) rather than MOTCK (which runs for the 160 visible pixels).
By my read of the schematic, if a Player 0 is positioned so that GRP0 bits 0-3 are visible at the right edge of the screen, and 4-7 are visible at the left, and horizontal motion were not activated, then its sprite generator will output bit 3 of GRP0 continuously during the horizontal blank. If Player 1 were similarly positioned, its sprite generator would output bit 3 of GRP1. If going into horizontal blank, GRP0.3 was clear and GRP1.3 was set, and during blanking software set GRP0.3 and cleared GRP1.3 (in that order), I would expect it to cause a collision. If it doesn't, I'd be curious to know why.
If things work as I described, the HMOVE behavior would be a bit tricky to describe. Before I bother, it would be helpful to know whether collisions like I described can occur.
PS--On real hardware, VBLANK should start at least a line before VSYNC, and continue on for a dozen or so lines afterward. I suspect most newer televisions probably won't care, but a 1950's model might.