supercat
-
Content Count
7,259 -
Joined
-
Last visited
Posts posted by supercat
-
-
Doesn't Stellar Track also use venetian blinds?Stellar Track appears to use the same "flicker-blinds" kernel as Basic Programming; according to Warren Robinett, that kernel was invented by David Crane.
-
Since the original was the first full color arcade game ( that I'm aware of? Please correct me if I'm mistaken. ), it's even more important to pay attention to the design choices of the original artist...The 2600 is limited to per-line coloring; the arcade game wasn't, and the designs took advantage of the fact that it wasn't.
Perhaps the color choices were a little to bright for some television sets, but it's important to note that there was (and still is) a lot of variation in how televisions display color, so there was no single optimum color choice. Perhaps dropping the luminance value by 2 would have been helpful, but Galaxian is hardly a crime. Pac-Man on the other hand...
-
It would be nice to get an Oscilloscope capture of what's happening. as per interlace.It would indeed. It's important that the total number of scan lines in two fields be odd, and that the total length of the VSYNC pulse be the same on even and odd fields. Trying to simply cut half of the VSYNC pulse from every other field while the fields remain the same length won't be good enough.
BTW, the C128's 80-column chip didn't interlace properly; it output an even number of lines in a frame IIRC. Nearly any CRT will support interlacing if the timing is right, but if the timing is wrong it won't.
-
I've thought about doing a DDR or Guitar-Hero-style game for the 2600, using my BTP2 music driver. My big concern was whether the game would be enough fun to make it worth the monstrously-difficult kernel. Since then I've figured out a different possible approach for killer music. Still not sure about the 'fun' factor, though.
-
You may gain some cycles with the extra speed but at the cost of exactness and predictability (non-integer = misalignment of pixels and CPU cycles).Non-integer doesn't imply that there wouldn't be a small integer ratio. Imagine a machine with a 512x400 resolution (interlaced) with four colors. Dot clock is chroma*10/3, so the data rate would be chroma*5/6 (one byte ever 4 pixels). If the memory rate were chroma precisely, there would be 525 clocks every two scan lines, and on each scan line pair during the visible frame, a particular 256 of those clocks would get used by display memory fetches. No less predictable than things are now; the difference would be that the stolen clocks would not all be consecutive. From a hardware standpoint, it would be necessary to add one or two levels of synchronization registers, but that's just an extra 8 or 16 latches. No biggie.
-
Try to defend these instead?What's your objection with Galaxian? The yellow border?
Galaxian has to use the Ball for the player's shots. Missile 1 used for enemy shots, and Missile 0 can't be used because of NUSIZ0. The Ball is the only thing left.
The multi-RESP0 trick used for the aliens doesn't work well near the left edge of the screen. It is thus necessary to mark off part of the screen so that aliens have something to fly into (rather than just vanishing from mid-space). If the Ball and playfield could have been colored independently, that would have been great, but they can't. One must thus either -1- Use a bright shot and put up with a bright border, or -2- Use a dim border and put up with a dim shot, or -3- Skip the border, but have enemies disappear from the edge of their motion range (which does not reach the edge of the screen). Atari chose the first option. Some people might prefer the third, but I think it's better to simply tolerate the bright border.
-
That'd be great! A littel out of my league, though. The next one I make can have test LEDs for paddles and evfen vibration, though. That'll be pretty neat. And maybe an Altoids tin that is styled up like a 2600 with woodgrain and everything.To test paddles, I'd suggest wiring each pot input to its corresponding button input, and the measuring the resistance between "power" and "ground". Use a resistance-controlled oscillator and you can make a device which will use zero current when a button isn't pushed, and will also let you hear if there's any jitter in the paddles.
-
I wonder what speed was possible for the 6502 in 1982. The BBC ran memory at 4MHz and the 6502 at 2MHz ( with no wait states ) - An 800XL with 3.84MHz memory and a 3.84MHz 6502 would have ruled ( especially if it have additional graphics modes )What CPU was the BBC machine using? The Z80, IIRC allows almost two full T-states between outputting address and sampling data; the 6502 allows slightly less than one cycle.
Still, if the Atari could have run its memory system at 3.579MHz while keeping the CPU at 1.79MHz, that could have made more bus cycles available for the display hardware, allowing higher-resolution modes like 160x200x16 or 320x200x4 with no CPU slowdown, or 160x200x256 or 320x200x16 with significant CPU slowdown. Alternatively, it could have allowed a 7800-style oodles-of-sprites system.
BTW, I wonder if there were any systems which shared RAM between the CPU and display, and didn't have an integer number of CPU cycles for each display column. If one is trying to use RAM at its maximum speed all the time (as opposed to interleaving, which leaves cycles idle outside the vertical display interval), I would think that it might make sense to use a non-integer number of cycles so that the CPU would never have to be stalled for very long. For example, if each display column took four chroma clocks and on the badlines required two bytes, and if the memory clock rate was 9/16 the chroma rate (2.24MHz), then even on the badlines the CPU could use cycle every 16 chroma cycles (223Khz). A standard 6502 can't have its clock rate fall below 100KHz, and it takes a few cycles to suspend operation while its clock is running, but if the display controller could run the CPU in slow motion without violating the minimum speed, the extra DMA startup cycles could be eliminated.
-
IIRC, the expansion board contains all the signals that would be necessary to generate a composite signal for 7800-mode games (I'm not sure about audio), but it does not contain any of the video signals from the TIA.
-
Really, any chance I can get a copy?Check the blog entry "What the dickens".
-
That is pretty much exactly how I wanted it to work. Now I need to learn how to set up the timer, what values are appropriate for a full VBL/full overscan (I'm programming for PAL)?I would suggest using TIM64 and experimenting with values. To make it easy to detect upcoming or entry, I would suggest that instead of having INTIM count down to zero, you have it count to a value like 125 (tripping at 124). Thus, the code would be something like:
lda #125+40 ; Experiment with this value sta TIM64T ... lda #125 ; Next three lines are optional sta WSYNC cmp INTIM bcc INTIM_Wait ; Set 'oops' flag if desired INTIM_Wait: sta WSYNC cmp INTIM bcc INTIM_Wait
Rather than calculating the TIM64T values to use, it's often easier in the age of emulation to simply experiment. Make a guess and then adjust up or down as needed.
To see if INTIM is 127 or less, you may use the instruction BIT INTIM without disturbing other registers. If the N flag is clear, that means that you have 256 or fewer cycles remaining before you should be at your VBLANK routine (180 or fewer with optional code included). Using such an approach makes it practical to have loops that run at variable speeds and which will take multiple frames to complete (Strat-O-Gems uses that technique heavily, btw).
-
I envied the American A8 owners, as a lot of the early conversions ( Drol, AE , etc ) looked really terrible in PAL. At least some of the other Apple conversions were moved to multicolour mode though..I wonder how hard it would be to make an "artifacter" mod for PAL machines? Generate a square wave at half the pixel rate, along with a couple of out-of-phase sine waves at the PAL chroma rate, and feed the latter waves into a multiplexer controlled by the former. Use the output of that to modulate the luminance output and I think one would end up with a bad-looking but functional artifact-color display.
-
Since no more than two colors can be shown on a single 8-pixel line/space, I would assume that the little marker would have to move at 1/2 space at a time (horizontally).I would think Venetian Blinds would be the right approach. Limit the size of the QIX bouncy thing to 64 pixels so it could be drawn using a 4x4 cluster of sprites on half the frames; on the other half of the frames, the player and sparks would be drawn (once the sparks split, their flicker speed would drop to 15fps, but they're sparks so they should flicker).
-
Huh? Of course they did. Not only did they release their own BASIC expansions like "Super Expander" and "Simon's BASIC" for the C64, but the later Commodores like the Plus/4 and C128 (especially the C128) had a much more updated BASIC. Also, the un-released C65 had an updated BASIC as well.The VIC-20 had lots of unused address space; putting the Super Expander's ROM into that address space did not cause any difficulty. Note that even with a Super Expander installed, the BASIC ROM from from $C000-$DFFF is entirely unaffected. Despite that, there are many programs that require that the Super Expander be unplugged or disabled in order to work.
Simons' Basic (which I own, somewhere) isn't really compatible with anything; there are many programs that won't run with it plugged in.
As for the Plus/4, C128, etc. none of those are compatible with the C64, with the exception of the C128 in compatibility mode.
BTW, the niftiest "development system" I ever saw back in the day was the Fast Assembler published in Compute's Gazette. That thing was slick.
PS--Back in the day I wished I could have somehow sneaked into Commodore and removed the logic that prevented the creation of a useful "enhanced" C64-compatible mode. Imagine some of the software development possibilities if one could, e.g., use 64K of the 128K as a RAM disk. That would have been amazing. Too bad it's not possible.
-
The downside for Commodore (and their customers) was because of this deal they never got an updated Basic and had the same aging version in all the computers.There was a lot of software that relied upon the precise inner workings of the BASIC ROM. Had Commodore moved anything around, much of that software would have been broken.
Indeed, if one looks at various revisions of the KERNEL ROM, one will notice that changes are carefully patched in so as to avoid disturbing anything. E.g. if it was necessary to change something like
patch: lda #1 ldy #0
so that it would load the accumulator from somewhere in memory (not zero page) rather than using the constant 1, it would be patched as something like
patch: jmp wasBlank brk ; Blank byte endPatch: ... wasBlank: ; Some spot that had been blank lda magicLocation ldy #0 jmp endPatch
Not a perfect patch, since a program that attempted to enter the kernel at address patch+2 would fail, but it would nonetheless avoid the massive problems that would result from simply replacing the "lda #1" with "lda magicLocation".
-
Agreed, but I would rather see it revived.I'm not sure it's really meaningful to compare entries against all different systems. If a 4K game on the C64 behaves identically to one on the 2600, should the latter get more credit for doing more with less? How much? Given that many people have different biases toward different systems, I think it might be better to have separate contests for different platforms.
Also, I don't think the contest will be worth much of anything if there isn't a forum that actually works.
-
To be honest 4bit + 4bit is not equal to 8bit
... It's actually 5bitWell, 5.5 bits if one doesn't mind generating some extra noise at the sample rate (and harmonics thereof) and the sample rate is high enough that aliasing isn't a problem. Set one of the waves to be full-time "on" and the other to 50% duty cycle. Voila--46 output levels instead of 31.
-
The only thing is, I don't understand the clue that's given in the manual. I'll have to look at it closer, I guess.Hint: In the original release of the game, the message included the word "GREETINGS". The clue doesn't make sense without that; in the re-release, I forgot about the importance of that word when I changed the message (everything else about the game plays identically in all releases so for HSC versions they are interchangeable).
-
Atleast it would need to know stuff like this:No, in that situation it should simply figure the cycles are used. Likewise on cycles 3 and 4 of a branch instruction. Trying to exploit those particular cycles would require way too much effort to be worthwhile.
-
I think building a circuit to use the cycles of 6502 when it does not use bus is not that complex-- it does not involve caching, 2nd bus, nor a redesigned motherboard. The other point was getting more cycles from kernel routine without using up 10K of RAM which is a software issue and not related to hardware upgrades.It would involve basically to have a 2nd emulated 6502 outside to find out which cycles are "free" because 6502 doesn't tell you that. And then there hardly are any cycles at all to be gained. Most cycles are neccessary bus cycles too.
The 6502 includes a signal that indicates the first bus cycle of any instruction. The state machine necessary to identify most of the read/ignore cycles would not be particularly difficult, but trying to take advantage of cycles that are available here and there would add complications of its own; further, I really don't think there are enough such cycles to be worth worrying about.
-
Juno First (soon to be remedied)?Existed for C64. So did Anteater, IIRC.
-
Thanks to everyone who responded both on and offlist; the suggestions were very helpful! As such, here is a updated version of the Pac-Man Dossier with better page graphics, a much-improved introduction, and a new chapter devoted to the "split screen" level (including a map of the hidden dots). As always, I encourage people to send in their feedback, corrections, and suggestions on the guide.From what I understand, the kill screen isn't a result of the level counter itself overflowing into other areas of RAM. Instead, it's a result of two factors:
-1- The 'show fruit' routine works by showing a fruit, decrementing a counter, and seeing if the result is zero. If not, it loops and keeps drawing fruits until the result is zero. Thus, an attempt to draw zero fruits will draw 256.
-2- Since the game would malfunction if it tried to draw dozens of fruits, the game limits the number of fruits drawn if it's greater than seven.
The kill screen occurs because the game decides it's save to draw zero fruits (since zero is less than seven), but it actually ends up drawing 256.
BTW, on Ms. Pac Man, I once saw a copyright notice appear near the bottom the screen, obliterating some of the dots. The player and ghosts were able to pass over the copyright notice without impediment, but there were no dots there. After the player died, the copyright notice disappeared but the board was still short of dots and so the game was unwinnable. I think the player was on the second level--it certainly wasn't a level-256 killscreen, but it was an anomaly I'd never seen before or since. Has anyone else ever seen such a thing?
-
I'll jump on this bandwagon! I totally agree that TT is one of the best games ever made for the VCS. In fact, I stated in the "What 3 games would you take" thread that TT would be one of them.Not only is the gameplay superb and the replay value high, I love the title screen. The way the lights dance to the music...very nice effect. I also love how the 'loser' music is set in the minor key, as opposed to the intro music, which is in major (Hey, I'm a music teacher. I live for this stuff.)
The Toyshop Trouble music is interesting from a coding perspective. It's divided up into groups of four eight-quarter-note-long phrases; each phrase has two bass notes (an octave apart) and four melody notes, and the pattern of bass and melody notes repeats every four phrases. The bass and melody notes for the whole tune, both major- and minor-key versions, fit in 20 bytes.
BTW, the major version of the song is in "melodic major" sort of--the memody voice has a rather sharp B natural and an even more flat B natural. When I use the B natural as a leading tone (phrase 4), I use the sharp one; when it's not a leading tone (phrase 3) I use the flat one. I don't particularly like the horrible intonation in the major-key version, but it's the best the 2600 can do without some serious magic. In the minor-key variation, I like the intonation a bit better. I think the B-kinda-flat note works very nicely in phrase 3 of the minor-key version. Better than a proper B-flat or B-natural would.
Can you do it in 4K?I tried to do a mini-game version. If I'd started out targeting 4K, I might have managed something decent, but squishing everything into 4K would be hard. On the other hand, if Atari could have had that game in Christmas 1979 I don't think they would have balked at the extra cost of 8K cartridges.
I find I play constantly with the button pressed. If I could toggle that then my thumb would be so happy!I seriously considered doing that, but I was afraid that people would too likely end up confused since many people don't know the state of their difficulty switches at any given time (some may not even know where they are!) Somehow the idea of pushing the fire button to not paint toys doesn't seem very intuitive.
Besides, when people complain about sore thumbs, that's how I know I have a good game.
-
Until not too long ago, PCs were extremely compatible with legacy hardware. Newer PCs are more and more legacy-free. It is likely that in the near future your lovely PIT timer won't be there anymore on newer PCs.I wish Microsoft would either do a decent job of providing a virtual old-style PC, or else provide the OS hooks for someone else to do it. Even if it would be necessary to do cycle-by-cycle emulation, modern machines could still run programs that were written for something like a 386 at least as fast as the original machines would run.
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Fast divide by seven?
in Atari 2600 Programming
Posted
For medium-sized numbers, there's a huge difference. For really big numbers (crypto-sized), the difference isn't as significant, since the number of steps required to approximate 1/x to a certain number of bits is roughly proportional to the log of the number of bits; once one has a good estimate for the reciprocal of a dividend, the number of multiply/subtract operations is related to the amount of error in the approximated reciprocal.
I haven't looked to see to what extent this trick is used in RSA crypto implementations, but if it isn't used, it should be.