supercat
-
Content Count
7,259 -
Joined
-
Last visited
Blog Comments posted by supercat
-
-
byte 92,48,82,88
byte 31,22,49,21,127,211,21,120,212,255
-
The Radio Shack desoldering iron can be nice, but it might not be a bad idea to periodically check to ensure there's no continuity between the metal exterior and the AC line. One of my coworkers where I used to work was using one of those things that developed an internal short to the frame. Blew some traces off the board he was trying to repair.
-
A bit of a nuisance to parse your graphic. "sex machine"?
Hmm... Maybe I could be 00111110 00111010 00101010 00110011.
-
I don't think getting one extra column is worth the drop from 1/2 duty to 1/3 duty. Having 26 characters generated dynamically would be nice.
I've tried for 28 characters at 1/2 duty. It almost works, but I couldn't get get the letter spacing consistent. The 26-character approach is far more elegant.
-
I've been an HD snob for the past few years, if it's not HD it has to be really peek my interest for me to watch it, and odds are I won't know about a show as I don't watch the SD channels. Right now the only SD shows in my DVR list are Battlestar Galactica and Dr. Who - both of which are currently between seasons.I have an HD set, but SD is fine for me (using a $120 DVD recorder). VHF reception for the CBS affiliate is dodgy at best, though.
BTW, is there any easy way to edit the 'anamorphic' flag on DVD+RW titles? My DVD recorder never sets it, even when it should, which means playback on a normal TV set gets stretched. Further, if my DVD did set it properly, there would be times I'd want to clear it since some stations stretch out 4:3 material to fill the 16:9 frame generally ugh, though if I'm recording to DVD it would actually be nicer to have the transmission stretch out the material and then show it on a 4:3 screen than have blank borders on the side and then additional borders on the top and bottom when viewed 4:3.
-
This may be possible - I need to look at the code again. I still have no idea how you managed to get 26 sprites on a line - does it require hitting RESPx mid line?There's a four-line pattern; take a break every seven lines if that's your font height. So the first row of text does lines 0-3 and 0-2 of the pattern. The second does lines 3, 0-3, and 0-1. The third does 2-3, 0-3, and 0. The fourth does 3, 0-3, and 0-1. HMP0 and HMP1 should both be zero.
On line 0 of the pattern, STA RESP0 on cycle 38 and STA HMOVE on cycle 71.
On line 1, just STA HMOVE at cycle 71.
On line 2, STA RESP1 on cycle 38 and STA HMOVE on cycle 71.
On line 3, just STA HMOVE at cycle 71.
Each line pair only requires spending nine cycles moving sprites. I would guess your present code probably spends about 17 cycles (one LDA#imm, two STA HMPx, one STA HMCLR, and two STA HMOVE). Adding an extra column would increase the "prep" time, but would actually save two cycles in the kernel (assuming six cycles to load the shape)
-
Unfortunately, I don't see a way that would work. My display kernel is pretty tight as-is and I think situations where the sprites are very close or very far apart would break it. It would be really awesome though!Having two freely-mobile 40 pixel players with flicker-blinds would be tough. If the players were 24 pixels wide instead that might make things a lot easier. In that case, each scan line would have one "single" sprite and one "double". Thus, there would only need to be one write performed during the scan line. I'm not sure how many different versions of the code would be required to deal with the need to hit HMOVE at about the same spot each line. That would be a complicating factor.
If both players were 32 pixels wide, then both would have to be written during the visible part of the line. Every possible scenario could be handled with code (sometimes using VDEL, sometimes not) but I can't think of any way for practical code to allow much mobility.
If you didn't mind having a couple of vertical stripes running down the two human characters, and if you didn't mind limiting motion to 3-pixel increments, it would probably be possible to show two 31-pixel-wide players on alternating scan lines with no flicker. Not sure if that would be useful or not.
-
I haven't looked at your code yet; could you avoid the need for four versions of the kernel by using the two "frames" on alternate lines (so the first line of text starts with sprites to the left; the second line starts with sprites to the right; etc.)? Otherwise, any possibility of pushing things out to 26 characters? Even if your kernel sprawls into two banks that shouldn't be the end of the world.
-
This could be useful:The flicker-text kernel places some restrictions on font design which aren't present in most cases. Most notably, letters that have an imbalance of even and odd scan lines are apt to flicker much worse than those which are balanced. If you tone down the contrast enough you may be able to get away with just about anything, but a good font design can improve things greatly. Not sure what you can do with mixed-case text, though you might test things with both 4- and 5-pixel high lowercase letters. I would expect the 4-pixel letters to flicker much less.
BTW, I wonder whether the best approach might be a compromise between my pre-paired letters and your on-the-fly rendering. Pre-pairing the letters as I do requires a bigger font, but it packs two characters per byte in the text storage area. If it were possible to pre-pair most of the characters but provide that each line could have some number of characters built on the fly, that might offer the best of both worlds. Keeping the worst-case timing reasonable might be tough, but nobody said the 2600 was supposed to be easy.
-
Impressive. Though I like the higher text density that can be accomplished by using pre-formed character pairs, your demo does a good job at building things on the fly.
It would seem as though the 64-character limit is rather arbitrary, since you could use characters numbered 0-84 and store three partial character sets per page (4 2/3 pages total), or characters numbered 0-127 with two partial sets per page (7 pages total).
I'm not quite clear why interleaving the character-prep code with the kernel code would require having four copies of the kernel. I could see things being tricky if you were using my 26-character approach (which does use four kernel versions since the two players swap positions) but I don't see the difficulty here.
Also, I don't think the overhead of copying data from ROM to RAM would be as outrageous as you suggest, especially if text were pre-formatted into lines. If each bank has 128 lines of text, then the code to fetch each line of text to RAM would be:
; Assume y holds line number * 2 ldx #char23buff txs ldx #1 lp: lda char23_11,y pha lda char22_10,y pha ... lda char12_0,y pha iny dex bpl lp ldx #stack_top-2 tsx
That's about 180 cycles to do 24 characters. To compensate for that, though, your copy routine would save 96 cycles by replacing:
ldy #6 lax (TPTR1),y lda (TPTR0),y tay
with
ldy char0buff ldx char1buff
RAM usage shouldn't be a problem, since you could store the text temporarily at the end of the buffer. The last 7 bytes of text would get overwritten while rendering the last two.
-
Normal color coding is brown/red/orange/yellow/green/blue/violet/grey/white/black
Curious there's no violet wire.
Wire up/down/left/right to brown/red/orange/yellow
Wire green to +5.
The ground wire should be connected to ground. Based on numbering, that would be grey, but black would also be a logical choice.
Connect pin 7 ("Select") to Paddle 1, along with a 22K resistor to +5 and a 0.1uF cap to ground.
Connect pin 6 to Paddle 2 through a 1K resistor.
Connect pin 9 to the fire button input.
That should yield a controller which will be compatible with the normal one on most games (use "C" for fire), but which could be programmed to read all the buttons.
It would be possible to wire things so as not to require the resistors and capacitor, but at the expense of compatibility.
-
How difficult would it be to make a text kernel that supported upper and lowercase?To minimize flicker, uppercase letters should be 7 or 11 lines tall. Lowercase letters should probably have an even height but should certainly not have a height of 5. On a 7-line "E", the top and bottom lines will flicker opposite the middle ones. On a 5-line "e", all three horizontal strokes would flicker together.
Further, for purposes of my pre-paired letters kernel, adding upper and lower case would increase the number of different character pairs required.
-
A book cipher can be as secure as a one time pad (which is completely unbreakable) if only a small portion of the book is used, and if a given book is only used once. Security will be downgraded severely if the same book is used multiple times.
To be interesting, a cryptography algorithm--and especially one for a contest--should use a comparatively small key. Otherwise there will be many possible "solutions". Indeed, it's almost tempting to cobble together a "key" file of sensible-looking English text which would make your message translate into something clever and witty. Probably not worth the time, though.
-
The only ways that I can think to speed this up are:- Pre-calculate all possible combinations of letters in ROM (would require a huge table).
- Move some of the code into the display kernel (e.g. the OR operation).
It looks like your code does things differently, but I can't see how to avoid the above steps? It seems that you are using SBX in some clever way, but how is the character data stored in the first place? Any clues would be most welcome!
It uses a huge table, but is set up in such a way as to make a large character set practical. If all of the lines of text are predetermined, precomputing the character set shouldn't be a problem. Every 250 characters will take up 2K (the code can't quite handle 256). While 256 characters isn't quite enough, it's close. I would expect it should be possible to code all the text for a reasonable text adventure such that all but one of the characters on each line would be within a 250-character set. Each line would then have an extra byte to indicate which character (if any) was the oddball.
- Pre-calculate all possible combinations of letters in ROM (would require a huge table).
-
In the poker games, are you actually competing against the computer in betting-style poker? From your description, it sounds like it. That would seem to be a video game first. How well does it play by the rules? On the TI 99/4a poker cartridge, if an opponent's bank roll falls below the maximum bet, you can force the computer to fold by simply betting above his bankroll (in real life, the opponent would go all-in).
-
I still think it turned out great, but it could have been more vivid.I like the muted-colors concept, but the piece feels like the foreground is just plopped onto a stock background. I'm not sure whether it's because of the coloring, or the total values, or the shapes. Perhaps there could be a twisty-curvy building or two in the background as well?
-
Alternative proposal, if something a little fancier than a 22V10 is acceptable (the Atmel ATF750 is a 24-pin DIP with 20 macrocells instead of 10).
Wild and Zeepy Banking
The basic concept would be to have a four-bit banking register for the top 1K and one for the lower 3K, along with a "Wild and Zeepy" mode bit.
When "Wild and Zeepy" mode is turned off, everything would work pretty much normally; some addresses in the range $0400-$0FFF would be used for bank switching.
With "Wild and Zeepy" mode turned on, any access in the top 1K of address space would copy D5-D7 to three bits of the lower bank select and set the fourth. Zero-page accesses $C0-$FF would do likewise. Zero-page accesses $80-$BF would copy D5-D7 to three bits of the lower bank select and clear the fourth.
The net effect of this is that while one would want to avoid running code from $1000-$1BFF while "Wild and Zeepy" mode was active, 24K of ROM would be accessible via abs,x or abs,y addressing, or by (ZP),Y addressing with pointers in the second half of RAM, and a different 24K would be accessible via (ZP),y addressing with pointers in the first half of RAM. An alternative arrangement would be to make the zero-page areas be $A0-$BF and $80-$9F, with the other areas of zero-page not having such effects. That would allow code to run in $1000-$1BFF provided it didn't touch those areas of RAM. Note that in that case one could JSR or JMP directly from code in the $1C00-$1FFF range into 24K worth of code in the lower range.
Perhaps it would be nice to have separate enables for the auto-banking in the $1C00-$1FFF and zero-page regions (so that subroutines in the lower banking region could manipulate pointers). Trying to take advantage of direct JMP/JSR's would likely result in considerable confusion, however, so such notions might be best avoided.
-
I like the idea, but it would be much better if all 4k of the data banks were available. Is this possible, even though it may have limitations elsewhere?The reason for having only 3K be addressable via the pointer is to ensure that code in the top 1K of address space won't get "yanked out" under the CPU. If there were only 1K of code that ever wanted to access certain banks of data, that code could simply be replicated in all such banks, but that would be pretty confining. Splitting the address space avoids that issue, though I've got an even cooler idea if it's acceptable to go to an ATF750 . . .
-
Sounds similar to something we were thinking about attempting for Chimera, which is the "nobanking" thing, where a 2600 program can only run 4K of code at once but can read and write to 32K at a time, separated by 4K gaps. So you'd decide whatever you want to be in your 4K execution window and which 32K half would be in the data window. It seemed useful other than the annoying 4K gaps.Some similarity in concept, but huge difference in execution. Chimera requires some pretty fancy stuff. The "Magic Zeepy" banking scheme could work in a 22V10 (it would be nicer if I either had another macrocell, or could manage 24 product terms in one, but such is life). To be sure, Chimera could probably access the whole 4K out of each bank instead of being limited to 3K, but being able to access 24K directly would still be pretty cool.
-
The player ship explosion sound reminds me a lot of the crash noise on the Odyssey2.
The game generally looks pretty good, though if I might offer a couple of suggestions...
-1- I don't know how many segments there are in the shields, but it might be nice to have the segments be grouped into clumps (larger clumps on the outside).
-2- If you could make one of the rings rotate opposite the others, that would be nice.
Star Castle was a classic, so it will be nice if it can come to the 2600.
-
Does anyone have some saved reviews for Toyshop Trouble that they could post?
-
INPT2 = address $A, INPT3 = address $B $A=%00001010, $B = %00001011. The 8 used to flip the sprite = %00001000, so the "normally returns same bits as address" explains why it works for most people as the bit for 8 is turned on for both $A and $B.Bit 6 of INPTx will always be zero. Bits 0-5 of any TIA register will, with most cartridges, read as the last thing on the data bus. When using the ZP addressing mode, the last thing on the data bus will be the address. When using absolute addressing mode to read a TIA register, the last thing on the data bus will be the high byte of the address (can be useful for setting TIA registers without disturbing any 6502 registers).
When doing a read via ZP,x or ZP,y addressing, the 6502 will actually perform two reads. The first read will be at the specified address (before indexing); the second will be the indexed address. If X=1, "LDA $0A,X" will do a read of INPT2 (yielding $0A or $8A), ignore that value, and then a read of address $0B (again yielding $0A or $8A, since that's what was last on the data bus). If X=$80, then "LDA $80,X" will perform a read of address $8A (which is RAM), and then a read of $0A (yielding INPT2 on the MSB, zero on the next bit, and 6 bits from whatever was in $8A).
-
-The player seeing the brick. It might blend in with the backgrounds too much, since it shares a color.I'd suggest striping the vertical segments. That would make the brick stand out a lot more.
-
The colors aren't as intense as in my earlier entry. Also, with a lighter background, there's less contrast. The end result, is that although all of the shapes have hard edges, it still has a "soft" look to it.The colors look a bit loud on my screen, but that's not to say they'd be overly loud when printed. It's hard to judge how labels will look other than by printing them on a printer similar to Al's.
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
b*nQ
in Kenfused's Blog
A blog by kenfused
Posted
Qix on the 2600 would require extra RAM. Even with extra RAM, some concessions would be needed. Especially given the risk of trademark issues, it may be better to use a slightly different game design (most notably replacing the bouncing bunch of lines with something else bouncy). The bouncing lines would be neat, but the only way I can see those working would be to use a 104x192 two-color "flickerscreen" bitmap. That might look okay, but it would require a lot of RAM.
If the bouncy object were a more conventional sprite, then it might be possible to use a color-striped playfield for the background and get by with something like a SARA-size RAM.