supercat
-
Content Count
7,259 -
Joined
-
Last visited
Blog Comments posted by supercat
-
-
The games in the videos looked a bit better than I'd expected from the descriptions, but seemed to show a lack of caring on the part of the programmers.The descriptions are more accurate than the videos, then. After you've played them a few times - you have no reason to ever plug them in again.
I don't doubt it. But I wasn't implying they were good enough to be worth playing. Merely that the programmers did at least a few things that require some effort:
-1- In NERDS, the game recognizes when NUSIZx'ed sprites are destroyed and attempts to make the right ones disappear (unlike some games where all sprites get hit at once).
-2- NERDs seems to recognize when the enemy ships are close enough to the player ship to make flicker worthwhile, rather than flickering constantly, though perhaps that's a bB thing.
-3- The Last Ninja has enemies that recoil from being hit. Small detail, to be sure, but not all games do that.
-
It's kinda sad, to me. Both games look like they could be cool, if. If they had more testing, if they had more time, if someone with more skill had debugged them, if if if. If someone who cared had been programming them.The games in the videos looked a bit better than I'd expected from the descriptions, but seemed to show a lack of caring on the part of the programmers. Making the shot sound in NERDs decay would have taken about lines of code and would have made it much more pleasant. Oh well. Hopefully games like that won't glut/crash the homebrew market.
-
He's back! Yaaay!
-
1
-
-
Has it been a year already since this version came out??
I'm waiting for this one too. Should be a good game.
-
If you can spare a byte or two to keep track of what objects collided, that might be helpful, especially if you run the main game loop at 30Hz but can run the flicker routine at 60Hz.
-
That's a kickass demo. I certainly hope it can be recreated using Chimera. As it is now I'd hope there is room for at least one 4-cycle read every scanline or two to use as the sync trigger for the immediate mode patching.As I've noted before, I see no reason to require wasting four cycles/line on a Chimera hit. It should be easy enough to configure the Chimera CPLD to notice accesses in the $40-$7F range; those could be used for Chimera signaling without any cycle cost whatsoever.
-
Glad you like the demo. Uses up a good chunk of 32K just to show a single static screen (well, flickering pair of screens)
It might be to someone. In general I think status type information is better left above or below the bitmap. Even though it constrains the total resolution, the score will then be solid instead of flickered which would be prettier. But you never know.Personally I'd like to see how playfield could be mixed in somehow.
Depending upon what is being drawn on the display, having the score/status be solid rather than flickering could be a good or bad thing. And for those where a solid score/status display would be good, one could use my ten-digit score routine which shows two groups of five full-size digits (or 2x10 small ones). In any case, the rightmost two "outside" sprites in that kernel are "freebies" which have to show up to make the other 14 sprites work; they either have to show something or be blanked. One could save two cycles by blanking them both with #0, but otherwise one may as well use them.
On the other hand, there may very likely be some games that really don't benefit from the even/odd coloring, and bashing out another byte of display may be fun.
It should be no problem doing 96 pixels "reverse video" with a full playfield overlay and full even/odd coloring (I've worked out timing to do 96 pixels of "reverse video" with even/odd coloring of COLUPx only using ABS,y mode for most stuff; going to immediate mode will make even/odd coloring trivial). Doing 104 pixels of non-reverse video would be easy, but probably not as useful. Pushing out to 104 pixels of reverse video may or may not be workable.
-
Still, I expect to be able to get the left column working.Nope. Don't think I'll manage it, unless I figure out some new trick. I still think it may be possible if I give up even/odd coloring. Would that be worthwhile trade-off?
-
The first demo was nicely structured, with evenline and oddline that start on cycle 0-4 and end on cycle 0 precisely; they take a parameter indicating what cycle they're starting on, and parameters for each item to be displayed on the line.
To free up the necessary cycles to make the left column work on a real 2600 I'll have to push things around so they won't be nearly as nicely structured. They'll probably start on cycle 6-10 and end on cycle 6, and four of the parameters the evenline macro will be shape data that should appear on the next oddline macro. Still, I expect to be able to get the left column working.
-
You were perfectly addressing the flaws of the arcade. Being doomed sucks. You always are in these older games, but it's rarely as obvious as in Colony 7
Some Asteroids players might disagree with you about 'always' being doomed.
My more specific complaint with Colony7 is that once an enemy has fired a shot toward one of your guns, you can't do anything about it unless you have a super-bomb. Perhaps if the player could shoot enemy shots, that would help things.
-
I was just thinking it might be possible to get some kind of playfield underlay going for more effective colors per scanline, something similar to Homestar Runner.Or maybe if the colors were inverted it might be possible to write vector type games like Star Castle where the playfield is used to colorize the vectors.
Inverting the colors is what I did for Ruby Runner, but it's harder than it sounds. With a 48-pixel kernel, there's no problem, but with a 96+ pixel kernel, you need to somehow black out all the areas where the background shouldn't show. And that can be a trick in and of itself.
Otherwise, using different colors on alternate scan lines (e.g. blue and brown) can be a good approach, but solid areas of blue or brown will flicker badly. For a vector-style game, though, such an approach should allow three-color graphics to be produced pretty well.
Check out the mega demo in my blog.
-
Sounds great. When you say status area you mean only being able to do pluses and minuses and things?Not at all. I mean that what you'll get will be 136 pixels worth of bitmap, but with a big gap between pixels 7-8 and between pixels 119-120. So you have 8 consecutive pixels to the left of the leftmost gap, then 112 pixels continuous in the "middle", then 16 pixels to the right of the rightmost gap. The left status area could be used for bargraphs, icons, two-digit readouts, etc. The right area could be used for short words, four-digit readouts, scanners, etc. At the moment one would have to trade off the left-side strip for the rightmost eight pixels of the right side, but I may be able to display them both.
Unfortunately, although everything is playfield-aligned, the non-symmetric placement of the gaps is apt to limit the usefulness of the playfield. I could probably adjust the kernel to show 8+112+8 kinda-sorta centered, or I might be able to do 16+104+16 centered. My original design goal was to simply maximize the contiguous bitmap region, but making things symmetrical might improve overall aesthetics.
-
Using immediate-mode addressing, I think I've come up with something new and amazing. Should have tested it earlier on real hardware, since I don't think I can get quite what Z26 led me to believe, but what I can get is a flicker-blinds high-res screen with either of the two following formats (each character is eight pixels, starting 4 pixels from the left)
#-##############-#- --##############-##
A "#" means displaying eight arbitrary pixels there, and a "-" means not. So that's a 112 pixel high-res area, with either an 8-wide status or decoration area on each side, or a 16-wide status area to the right. Z26 led me to believe I could do all the status areas; I don't think the timing will work for that, but it might. I'm not using the Y register at all, and I have some free cycles near the beginning of the line, so I might be able to get the status area on the left while keeping the extra width of the one on the right. This would probably misalign two sprites near the right by a pixel or two, so the high-res area would be 111 or 112 pixels and the status area 14 or 15. Still an impressive amount of content to display, though. In the right-side status mode, half the scan lines are showing NINE different sprites.
Edit: I think I may be able to pull off the full display of both status areas, with all sprites perfectly aligned. But not tonight.
-
It could also disable all banking, though I wonder if the logic equations could be minimized enough to fit on the PLD? Maybe I'll see if the VHDL compiler can make it work. I guess I've been spoiled - I don't remember how to do that stuff by hand
Should be pretty easy, I would think. Something like:
Q17 := A11 & !A12 & Q12 & Q13 & Q14 & Q15 & Q16 # Q17 & !A11 # Q17 & A12 # Q17 & !Q12 # Q17 & !Q13 # Q17 & !Q14 # Q17 & !Q15 # Q17 & !Q16 Q16 := A11 & !A12 & Q12 & Q13 & Q14 & Q15 & Q17 # Q16 & !A11 # Q16 & A12 # Q16 & !Q12 # Q16 & !Q13 # Q16 & !Q14 # Q16 & !Q15 # Q16 & !Q17 Etc.
I believe the 16V8 gives eight product terms per pin, so the above fit perfectly.
-
Hmm... is "evil trick" referring to the shrinky digits, or the use of TXS/TSX? The latter reminds me of my 1994 Color-'ems (later Strat-O-Gems) kernel. 8-) Useful trick then and now. BTW, in Toyshop Trouble I could have saved a cycle in one of my kernels, at the expense of 14 bytes of RAM, by using the "LAS" instruction (the irony is that the RAM waste would be from storing the same data in RAM 15 times to allow for the ",y" addressing mode of LAS).
There are other tricks one can use there for certain score colors. For example, if you wanted colors $06, $08, $46, $48, $86, $88, $C6, or $C8, you could swap the roles of P0/P1, set up the right combination of P0/P1 and M0/M1 collisions, and then use "DEC COLUP1" or "INC COLUP1" to set the color. This would allow you to load the accumulator with a GRPx value instead of the stack pointer, thus saving you the four cycles you'd otherwise spend on TXS/TSX.
Using LSR or ROR on COLUP1 would let you have $n2, where 'n' is any even number. Using ASL on COLUP0 or COLUP1 would let you have $0C, $0E, $8C, or $8E.
Obviously an NTSC/PAL translation would have to be hand-tweaked in this scenario; usual methods of using color-equates would not suffice.
What about, as an another "evil" alternative, using one or both missiles for the last digit? That would let you make the other digits full-sized. Use the playfield to obscure the extra missile copies.
-
A few 4k games don't work with the scheme (due to indiscriminate BIT Absolute instruction-skipping) but most seem to. If nothing else, this could be a selling point for the board, making it marketable before any games are ever made for it.It would be trivial to make a PLD which would disable banking if anything other than the startup bank were selected.
Incidentally, the problem isn't just with "BIT abs"; Asteroids does some careless accesses using (zp,x) mode.
-
$2.50/sq in would put the boards at $15/ea which is way, way too much. While a 32-pin DIP would fit on a standard sized board, the board would not fit in the cart shell, which is the reason for moving it beyond the screw hole in the first place. Other shells may work (I'll open up an Activision cart to see.)I started playing with a socketed PLCC board and it looks like I can fit a DIP PLD, and maybe a DIP serial EEPROM, so this might be the best direction.
Whatever fits. I was just looking at a VGWIZ clear plastic board and it looks as though a DIP32 would almost fit, but probably not quite. I don't much care for PLCC sockets, but maybe it would make sense.
-
Hard to say, the price can be very board specific. For your prototypes a would recommend batchpcb.com. They are the same guys that run SparkFun.com. $2.50 per square inch ... period ... well almost. If you order a 1 sqin board you pay $2.50 for it. There is a very small setup fee, but its included in the shipping costs. I usually try to order a bunch of small items at once so the shipping/setup fee is only incurred once.Is there adequate clearance to put a 32-pin DIP in the spot where Albert now puts a 28? That would be the big deciding factor I'd think. The overall width of the Albert's board looks like it could handle it, but the chip would extend over the 'notches'. I've not examined all the plastics to know which would allow for such a thing, and which would have trouble.
The 16V8 and 24LCxx should fit in 1.4 inches, which is the length of the present DIP28, so there shouldn't be a problem there. Adding a small gap between the chips might be a good idea, but if space isn't available for that the 24LCxx could be rotated 90 degrees.
-
Some additional thinking: although there should probably be no problem wiring the EEPROM pins as described, it would be theoretically possible for a sequence of banking operations to accidentally trigger an EEPROM write--possibly with disastrous consequences. Rather than use an I/O pin as an input only, it would probably be better to use it as an open-collector output.
Assuming Q12 is wired to the I2C clk, the chip could be set up something like:
I2CDAT = A0 & !A0 & A1 & !A1 & A2 & !A2 & I2CDAT & !I2CDAT ; Always false I2CDAT.oe = !Q13 & Q14 & Q15 & Q16 & Q17 ; Assert in on banks 60-61 only CSout = /A12 ; Simple chip-select. Rising edge will also serve as clock Q12 := Q12 & !A11 # A0 & A11 ; Latch A0 if A11 high. Note that we know A12 is low since ; we have a rising clock edge. Q13 := Q13 & !A11 # A1 & A11 ; Just like above, but latching A1 ; Q14 is trickier and is handled below Q15 := Q15 & !A11 # A3 & A11 ; Just like above, but latching A3 Q16 := Q16 & !A11 # A4 & A11 ; Just like above, but latching A4 Q17 := Q17 & !A11 # A5 & A11 ; Just like above, but latching A5 Q14 := Q14 & !A11 # A2 & A11 # A11 & A1 & A3 & A4 & A5 & I2CDAT ; Similar to above, but bank 111x1x will map to 11111x if data pin is high
Code banks 58-63 are used when accessing the I2C chip. Attempting to set bank 58-59 will instead select 62-63 if the I2C data pin is high. Within an I2C transaction, code execution should switch banks only as needed to perform I2C transactions. Outside of an I2C transaction, however, banks 0-57 may be used freely.
-
I think an 8-pin serial EEPROM should be more than enough for a single cart (I think they are available from 128 bytes up to 8k bytes) and will be more likely to fit. However, my feeling is that most wouldn't use the EEPROM, so if those extra holes, jumpers and the like increased board size at all, I'm not sure it would be worth it.DIP-8 EEPROM chips are available in all sorts of sizes (including 64Kbytes and up).
It should be possible to make a version of the banking which would support up to 256Kx8 and an EEPROM (of arbitrary size) while allowing direct access to almost any bank.
Inputs: A0-A5, A11-A12, and EEPROM data (nine)
Outputs: Q12-Q17, /CE (seven)
The /CE output would be connected through to the clock pin via an RC circuit. The EEPROM clock input would be wired to Q12; the EEPROM data pin would be wired via resistor to Q13 and directly to the "EEPROM data" input of the PAL.
The PAL would be configured so that an attempt to select banks 60 or 61 would instead select banks 62 or 63 if the EEPROM data input was high. Giving up four banks out of 64 shouldn't be a particular problem.
Since the EPROM will be 1.6 inches long, the CPLD, EPROM, and resistor should fit nicely in a similar length.
-
A serial EEPROM, if that's what you mean. If you are using 128k, there would be one macrocell available to drive it. (You'd need a different PLD program but that's not a big deal.) But the only way I'd want to do it is if it did not add any board space, and its holes could safely be left unpopulated if not needed. In the DIP version, there will probably be space for the chip somewhere.Another approach I was thinking of for the EEPROM would be to have a 24-pin area for a 16V8/22V10, with pin 1 being the same for either chip (if not using the EEPROM, just put a 16V8 in the upper 20 holes). It's too bad I believe the 16V8 requires pin 11 to be grounded; otherwise things would be much easier.
There are tradeoffs between execution speed, board space, jumpering requirements (when not using EEPROM), etc. If you like I can sketch out some options.
Also, I don't want to support a SARA chip - I'd rather figure out how to add SARA support to a PLD and use a standard SRAM chip for the RAM so we wouldn't need to rely on salvaging the chips from existing carts. I worked on this a couple of years ago and never got it working on the proto board (though it worked in simulation.)I think CPUwiz has a supply of SARA chips which should be adequate for awhile. If I'd known of them, I wouldn't have bothered with the 4A50 board which was intended to be the cheapest possible expanded-RAM board using modern chips. I really can't think of any way one could manage RAM more cheaply than I have done without using custom silicon.
-
I like SUPER (with the recursive backronym.) Better than the ideas I came up with last night, like BFC: Big Fun Cart (or maybe Big F'un Cart?)Switch Using Previously Excluded Region, Cheapening ARcade Translations.
Though actually I think "SuperCart" would probably be overly confused with "Superchip cart" (Millipede, Dig Dug, etc.)
-
Laying out the board right now. I might be able to make both a DIP and PLCC (socketed through-hole) version. The PLCC version is likely to be cheaper overall if using new parts. The DIP version would be good for those with stacks of DIP EPROMs (I personally have 200 128kX8 DIP EPROMs.)If practical, it would be nice to have space for a SARA chip. If SARA functionality isn't needed, it could would be easy to jumper it out. Since the hotspots are all at address 01xxx*, there should be no problem using the A12 output of the SARA chip to feed the PLD (it would turn addresses of the form 10000* into 00000*, but that shouldn't affect banking).
It might be fun to also support an EEPROM. Would it be worth trying to incorporate such functionality do you think?
-
You failed to mention that Strat-o-gems actually uses the tone generator portion of the Speakjet to enhance the music/soundfx.It does? That would be news to me, and I wrote the thing. >:*3
Strat-O-Gems uses the ability to specify the 'pitch' of speech to make it 'sing' more or less in tune with the TIA. The non-vocal pitches are done by the TIA, not the AtariVox.
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Homebreviews - part 19
in (Insert stupid Blog name here)
A blog by Nathan Strum
Posted
Generally true, but I hope Toyshop Trouble is an exception.