supercat

Well, I just snuck 8x8->16 in up above. I would think that for your fixed-point maths you'd want an 8x8->16 multiply. As noted, it's pretty easy. Here's a simple divide routine off the top of my head, but it probably isn't quite right. I'll have to simulate and see if I got it correct. It should divide A:quot by denom, leaving the quotient in quot and the remainder in A. ldx #8 lp: cmp denom bcc toosmall sbc denom ; Note: Carry is, and will remain, set. rol quot rol dex bne lp beq done toosmall: rol quol rol dex bne lp done:

Computing 8x8->16 multiply is more useful than 8x8->8, and isn't really any harder. The 6502's lack of add-without-carry is somewhat irksome, but there are a variety of workarounds that could be used. ; Compute mul1*mul2+acc -> acc:mul1 [mul2 is unchanged] ldx #8 dec mul2 lp: lsr ror mul1 bcc nope adc mul2 nope: dex bne lp inc mul2 As for division, the normal approach is to do a shift-and-subtract. A 16/8->8+8 result is pretty easy, with the caveat that the results will be meaningless if the quotient doesn't fit in eight bits. I'll try to work one up for you.

Well, by "accelleration" I was thinking of Spacewar-style, but thanks for telling me about the fire button. Makes the game much more playable.

Is the output of the RF modulator capacitively coupled? If so, I'd think a resistor and inductor (in series) to a clean DC voltage would suffice (VDD might suffice if the inductor was big enough).

Cute title screen, given the kernel restrictions, though an ASM one might be better. The game concept is amusing and somewhat playable, though when the target is distant and the fireball is timed to hit it at the same time as a ship on optimal path, there's not really much the player can do. I would think the game might be better if it used both missiles as targets and offered a few variations: Both missiles always on screen, and can be gotten in any sequence. Both missiles start out on screen and can be gotten in either order, but first one gotten won't reappear until second is gotten, whereupon both will reappear. Both missiles appear on screen, but player can only usefully grab the one that matches the player's color. Grabbing that will cause the fireball-colored one to become the player's color while a new fireball-colored missile reappears (thus giving the player a heads-up as to where the next missile is going to be). Otherwise, a few more that might improve gameplay: Visible screen borders, so as to allow the player to better judge where the fireball will bounce. Perhaps setting COLUBK to something other than black would accomplish this. Diagonal moves and/or accelleration. Some penalty other than sudden death for using more than the optimal number of fuel. I think a game called Roadblasters used a good scheme: the player has a 'normal' tank and a 'reserve' tank. At each stage, the normal tank gets filled but the reserve tank does not, though goodies are available to boost it slightly. Despite the game's simplicity, it does have definite charm.

On the other recent "Okie" thread, I charted out the basis vector that can be used to solve the game on paper with the minimum number of moves.

Agreed. Before this, the game was too hard and tedious to be any fun. The hack doesn't exactly makes it easy, but does make it more satisfying. Now if only the monsters would stay blue longer...

I know the F8 is horrendously more complicated, but I thought both used ten-bit instruction words. Maybe I'm misremembering. In any event, my recollection was that one of the complications of the F8 addressing device was the need for an ALU to compute branch addresses. Having branch addresses partially-precomputed in the excess words of an instruction would seem to greatly simplify the addressing logic (among other things, doing the Nth bit of an ALU in a PLD requires 2^N minterms; this quickly becomes impractical as N gets big. If one had six extra bits which could hold precalculated intermediate carries, one could split the ALU into smaller pieces, vastly reducing the number of minterms required for each.

If a Supercharger game doesn't need to write any of the memory in the Supercharger during program execution, converting it to cartridge form is apt to be pretty simple. If it does need to write memory, converting it to (RAM-less) cartridge form may be basically impossible. The 1K minigame contest entry I'm working on falls into the latter category. It's a "small title" [only 1K of code] but it would be absolutely impossible to get the graphics I do without using 2K of RAM for data storage. If I used more RAM, I could probably make the game even better except that doing so would require bank switching which would use up precious code.

Basically correct. The board I am designing will use a "complex" programmable logic device (CPLD) to control bank switching and RAM access. I intend to design the board with the cheapest CPLD that will perform the required functions, a 95C36XL at a cost of about $1.30. If a 95C72XL were installed instead of the 95C36XL, the board would probably be able to handle Supercharger games, but I see no reason to spend the extra $5 or so for the fancier chip. To be sure, I don't really know or care what Superchargers cost these days, since I got mine years ago, but more importantly my goal is not to let people run pirate games but rather to let people produce homebrew games that require extra RAM. Hopefully enough people will take up such programming to make my efforts worthwhile.

Interesting stuff there, including the (somewhat hard to read) schematic. It's interesting that while the Channel F is regarded as having 64 bytes of RAM, it actually had 2 whole kbytes of video memory. I don't know what restrictions where were on processor access to VRAM, but it would seem the Channel F could probably do a lot of things the 2600 and Intellivision could not. A decent Missle Command knockoff would seem entirely feasible. I don't really see much point in homebrewing for the Channel F, though, given that the audience is much smaller than the audience for e.g. Atari 2600 games. It would appear, though, that it should have been possible to produce some decent games for that system. BTW, I wonder if it would be practical to design a homebrew cartridge system using logic quite different from (and simpler than) what the F8 designers had in mind. For example, since the ROM data bus is going to be 16 bits wide even though only 10 bits are needed by the F8, the other 6 bits could be used to assist in address calculation. Alternatively, one could probably code an entire game mechanic in something like a PIC and just have it feed the F8 instructions to draw what needed to be drawn and kick back information about the controllers, etc.

Addendum: To solve any position reasonably quickly, it is sufficient to remember three patterns (and be able to figure out their reflections). Clearing all but the bottom row is trivial--just start at the top and click below each lit 'okie'. To clear the bottom row, you just need to remember the patterns to clear each of the left three okies and be able to apply them reflected to the right okies.

Okie Dokie can be solved using linear algebra or with the aid of the following chart. To use the chart, draw a 5x6 chart and look up each lit 'okie' in the following table. Then place a mark in the squares indicated. Do this for all of the okies. Then, simply hit the okie on each square which contains an odd number of marks. Once this is done, the puzzle will be solved. ---*** --**-* -**-** **-**- *-**-- ***--- *-*-*- -----* *-*--- ---*-* *----- -*-*-* *-**-- --***- **-*** ***-** -***-- --**-* --*--- -*-*-- *-*-*- -*-*-* --*-*- ---*-- **---- ***--- -***-- --***- ---*** ----** *-*-*- -----* *-*--- ---*-* *----- -*-*-* *-*-** ----** *-**-- --**-* **---- **-*-* *---*- -*-*-* ----*- -*---- *-*-*- -*---* -***-- **-**- *-*-** **-*-* -**-** --***- --*--- -*-*-- *-*-*- -*-*-* --*-*- ---*-- *-**-- --***- **-*** ***-** -***-- --**-* *---*- -*-*-* ----*- -*---- *-*-*- -*---* -**-** ***-** **---- ----** **-*** **-**- *---*- -*-*-* ----*- -*---- *-*-*- -*---* *-**-- --***- **-*** ***-** -***-- --**-* --*--- -*-*-- *-*-*- -*-*-* --*-*- ---*-- -***-- **-**- *-*-** **-*-* -**-** --***- *---*- -*-*-* ----*- -*---- *-*-*- -*---* *-*-** ----** *-**-- --**-* **---- **-*-* *-*-*- -----* *-*--- ---*-* *----- -*-*-* **---- ***--- -***-- --***- ---*** ----** --*--- -*-*-- *-*-*- -*-*-* --*-*- ---*-- *-**-- --***- **-*** ***-** -***-- --**-* *-*-*- -----* *-*--- ---*-* *----- -*-*-* ---*** --**-* -**-** **-**- *-**-- ***--- For example, if the center two okies are set and no other ones are, one's chart would look like: 221122 -1--1- 11--11 -1--1- 221122 (with numbers indicating the number of marks in each square). Thus, one would click all of the squares that show an odd number ("1" in this case, though if there were more lights lit in the original puzzle, there might be 3's, 5's, etc. as well). As another example, suppose that the left center square and the three squares next to it were lit. This would yield the following chart: 2-422- 222222 322-42 222222 2-422- Thus, one notices that all of the marks cancel out to even numbers except the left-center square itself (which ends up with an odd number, "3").

I haven't yet figured out how this scheme would work. I'll look into it a little more. 894669[/snapback] The scheme I'm planning to actually use (the first one mentioned) would take thirteen cycles (I miscounted sixteen). The memory from $1F00-$1F5F would be preloaded with the eight-byte pattern $01,$02,$04,$08,$10,$20,$40,$80; the memory from $1F80 to $1FDF would be preloaded (by the programmer) with $FE,$FD,$FB,$F7,$EF,$DF,$BF,$7F. Any access in the range $1F00-$1F5F or $1F80-$1FDF would set the bank-switching hardware so that the appropriate column of display data would be accessed at $1000-$10FF. Figure in those assumptions and the sequences to set and erase pixels should be pretty clear. As for the latter scheme, it would require that the cartridge itself contain read-modify-write hardware. If I were willing to use a 95C72 instead of a 95C36 (i.e. a more powerful programmable logic chip) it would be possible to make it so that the CPLD would turn certain read accesses into read-modify-write operations internally. In fact, I slightly-overcomplicated the proposal and it's not necessary to use fully page crossings since memory and logic devices are fast enough to do the whole read-modify-write operation in a single 6507 cycle. Although it would be rather cute to be able to do that, though, I suspect the performance gains would in practice be pretty marginal and not worth the extra hardware required. The approach given at the top of this post, however, would require relatively little hardware to implement (and what it requires should fit in the 95C36). It would be equally usable with both index registers (as indicated) or with one, in case the other was needed for loops (e.g. to draw a series of points) ldx #numpts-1 lp: ldy xcoord,X lda $1F00,Y ldy ycoord,X ora $1000,Y sta $1000,Y dex bpl lp If an object needed to be movable in the X dimension (without recomputing all its coordinates) but not in the Y direction, the loop would still work nicely: ldx #numpts-1 clc lp: lda xcoord,x adc xposition ; Should never set carry tay lda $1F00,y ldx ycoord,x ora $1000,y sta $1000,y dex bpl lp Dealing with the case where the Y coordinate is mobile is harder, since there's no nice way to do the arithmetic without trashing the value in the accumulator (there's a funny opcode to subtract from X, but only if the accumulator is $FF). Even that's not too bad, though: ldx #numpts-1 clc lp: lda xcoord,x adc xposition ; Should never set carry tay lda $1F00,y pha lda ycoord,x adc yposition tay pla ora $1000,y sta $1000,y dex bpl lp Sound interesting?

What are you using "asl" for if this is supposed to be a divide-by-eight? I would suggest something like the following: idiv8: ; Divide the number in the accumulator by eight (signed) cmp #128 bcc div8cc ; Value in Acc less than 128 adc #$02 ; Carry is set, so we're adding 3 bcs div8ccnr lsr lsr lsr ora #$E0 rts div8cc: adc #4 div8ccnr: lsr lsr lsr rts Perhaps not quite optimal, but it should yield symmetrically-rounded results.

What's wrong with x86 assembly, if I can get semething that will compile it with everything else? BTW, what do you think of my idea for the hi-res optimized banking scheme? Sound like it should allow for some interesting games? I don't really see how one could do a whole lot better unless one reserved two pages for hires graphics and, with Y>0, did stx $3D ; [or wherever--some special address to set the X coordinate] lda $10FF,y ; Do automatic read/modify/internal-write This would reduce the pixel-plotting time from 16 cycles down to eight, but would require much more complicated hardware that I don't really think would be worth it.

The older 2600 units have a trapdoor on the cartridge port which is released by the pokey-pins on the cartridge (no relation to the POKEY pin on a Ballblazer or Commando cart). It would probably be possible to use a small object to jam the trapdoor open when you insert the Hockey cart, but you should definitely not force anything.

I wonder how hard it would be to make a Kaboom-O-Matic, similar in concept to Rogue-o-mathc (i.e. a device which would automatically play an unmodified Kaboom cart on an unmodified 2600, using some simple hardware to detect the position of the Mad Bomber)?

If one limits the bitmap to 127 pixels tall, what about having the RAM address be $base+256*Y+X/4? This would use 32K of memory and result in a bitmap 1024 pixels wide, thus allowing for double-buffering and easy scrolling. Having addresses computed in that way would make blitting easier: ; Assumes targ is set up to point to the first byte of the destination and ; shapem and shapex are set to point to the pre-shifted shape data for the ; shape. ldx #0 ldy #15 ; Character height lp: lda (targ,x) and (shape1m),y xor (shape1x),y sta (targ,x) inc targ+1 dey bpl lp If a lemmings are 16 pixels high by a max of 5 pixels wide, the above code would be run twice to plot each lemming. The loop takes 7+6+6+7+5+2+3 (23) cycles per iteration, so with the surrounding overhead that would be about 800 cycles per lemming. Pretty efficient as such code goes, though not really good enough to draw 99 lemmings at a good frame rate.

Well, Alt-X in Z26 can be handy. :-) Otherwise the level 4 game is very hard, even though I beat level 3 on the first attempt.

What must I do to compile Z26 for Windows? I'd like to add some new bank switching methods (which I'm currently working on hardware for). I haven't figured out the details of my new hardware yet, but one feature will be "hires helper" mode, useful for developing games with a Stell-A-Sketch style hires screen. On the new hardware, plotting a pixel at coordinate X,Y (i.e. in the X and Y registers) will take three instructions: LDA $1F00,x ORA $1000,y STA $1000,y Erasing a pixel will also take three instructions: LDA $1F80,x AND $1000,y STA $1000,y The "hires helper" hardware will actually be very simple--essentially, it will cause any access to $1Fxx to copy bits 4-7 of the address into bits 0-2 of the page address, and bit 3 of the address into bit 3 of the page address. Despite its simplicity, however, the "hires helper" should allow the creation of games for the A2600 that would otherwise not be possible. BTW, in case anyone is wondering, the hardware would regard a single access to addresses $1000-$10FF as a read, and the second part of a double access as a write. Because "LDA $1000,y" performs a single read and "STA $1000,y" performs a read and write consecutively, these instructions would be correctly handled by the hardware. FYI, the following instructions would be handled correctly be the hardware: ; Note: I is X or Y; STO is any store instruction; RMW is any read-modify-write instruction All addressing modes of reads EXCEPT indexed reads that cross a page boundary WITHIN the RAM area. RMW $10xx RMW $0Fxx,I [page crossing INTO the RAM area] RMW ($xx,X) RMW ($xx),Y [page crossing into $10xx] STO $10xx,X [page crossings into, within, and out of the RAM area are all acceptable; the latter will not result in a store] STO ($xx),Y [all page crossings acceptable, as above] The following instructions would not be handled correctly by the hardware: READ $10xx,I [page crossing WITHIN the RAM area] READ ($xx),Y [ditto] RMW $10xx RMW $10xx,I [except for page crossing from outside the RAM area into it] RMW ($xx),Y [ditto] STO $10xx STO ($xx,X) ***Code execution from RAM*** Note that while the set of usable instructions under this scheme would be somewhat reduced compared with those allowable under a SuperChip-style scheme (using separate read and write addresses), it does not require the use of double address space for writing and reading. The current plan is to have a 256-byte area and a 1.75K area of RAM available with separate write-protect latches; a write-protected area would be usable for code execution. What would be necessary to add such a feature to Z26? I've looked at the SuperCharger library, and I have something of an idea of how I'd implement the banking, but I have no idea how to recompile Z26 to do that.

Sprite replication is a built-in feature of the hardware. Flipping a bit hardly counts as an accomplishment. I wasn't counting the replication feature in the hardware--I was talking about the use of multiple RESPx/HMPx/HMOVE operations within a frame. Indeed; I think it took awhile for people to figure out that such a thing was possible. First game to identify the author onscreen is Adventure, but I wouldn't say that was conspicuous, especially when compared with e.g. Solaris.

I was wondering who is responsible for the following various innovations, and the year and game in which they first appeared. Can anyone help fill in any of them? First use of a sprite at multiple horizontal positions within a frame (Air Sea battle?) First use of multiple colors within a sprite (Superman?) First use of flicker to show more than two on-screen hires sprites First use of different images for multiple sprite copies on the same scan line (Slot Machine, Video Chess, or Video Basic?) First horitontally-moveable use of different images for different copies on the same scan line (Dragster?) First game with dynamically-moving 'zones' for sprites First game which allows one player sprite to move across zone boundaries First game which allows both player sprites to move across zone boundaries First six-digit hires score routine First game to CONSPICUOUSLY identify author on screen (?) First use of more than three copies of a sprite on the same scan line using repeated RESP trick First use of more than three copies of a sprite on the same scan line using NUSIZ trick First use of more than one double-width sprite on the same scan line using well-timed NUSIZ (does any game other than Meltdown do this?) First use of more than three differently-shaped copies of a sprite on the same scan line First use of small HMOVEs to smooth or widen sprites (e.g. the horse in Stampede is smoothed with HMOVEs, and the lasso is widened with them) First mass-produced cartridge to use any external RAM First mass-produced cartridge to use over 128 bytes of external RAM First cartridge NOT to include a screen-saver First cartridge to generate audio by using AUDCx value of 0 and modulating AUDVx (Pitfall II and Quadrun do this; does anything else?) Third cartridge to display 12 characters on one line using David Crane's interlacing technique first illustrated in "Basic Programming" and "Stellar Track" First cartridge to play coordinated two-voice music Many of the things listed above are things that the original 2600 designers never expected people to do, but they allow for a far greater variety of games than would otherwise be possible. A few techniques, like the 12-character flickertext, seem almost conspicuous by their absense (Phaser Patrol by Starpath features 12-character text which does not use flicker-reducing interlacing and doesn't look nearly as nice as the text in BP or ST). Anyone know who's responsible for all these innovations? Note that in some cases it may not have been the game programmer (e.g. Basic Programming's text kernel was written by David Crane even though the cartridge was mostly programmed by Warren Robinett).

Freeway: A game somewhat similar to Frogger, but with chickens. The game allows two people to play simultaneously, which is nice, but restricts motion of each player to a vertical line, which is not so nice. Being hit by a car does not cost a life, but merely knocks the player backward; rather than running until the player runs out of lives, the game runs for a fixed duration. Stampede: Player moves a horse up and down to try to herd and lasso cattle. The game moves too fast for a player to lasso every cow when it first appears, so herding is essential. Even this, however, is tricky. One of few Activision titles to use the "venetian blinds" technique (used here on the horse's legs and on the lasso). Laser Blast: Pow, pow, pow, scroll, repeat. Pow, pow, pow, scroll, repeat. Pow, pow, pow, scroll, repeat.... Starmaster: A first-person space shooter in the general style of"Star Ship" for the A2600 or or "Star Raiders" for the A400/A800, but much better done than the former and running on cheaper hardware than the latter. Features two screens that can be selected via either the color/BW switch or the difficulty switches [the latter feature, oddly enough, not being mentioned in the manual].

It is impossible to do it in such a way as to have any significant likelihood of it working. The die-bonded chips require just as many solder connections as standard chips, but they're much smaller. Whereas a DIP has ten pins per inch and surface-mount parts have 20 to 51 pins per inch, a die-bonded part will typically have something on the order of 120 pins per inch or more (assuming 10 pins per side on a 2mm part). You don't see the solder connections because they're so tiny, but they're there and without them the device won't work.