brpocock

Zelda usually does it for me. I haven't bought a Nintendo console until they do their Zelda port. Bastards, releasing 3 (2.5?) Zelda games this year and a new console. For the Genesis, it was Sonic. The SMS, it was actually something called "Aztec Adventure" I think. I'll have to dig that one up some time, I haven't played it since it was new, I think, and I don't recall getting too far. Ironically, the DS, it was PictoChat that I bought it for, originally, although the Mario RPG there was a nice bonus. (I'm blanking on the name ... it's like, Mario Brothers, Twins in Time?) I think Final Fantasy would be the Playstation killer app for me, but I'm not quite addicted enough to spend that kind of money on a PS2 for the one game. Of course, once I buy the thing, I'm sure I'll find 20 other things to love about it.

I'll have to dig up some ROM's for those. As for collection, no, I'm afraid I don't actually own a single VIC cartridge... just scads of cassettes in questionable working-order. I've had to test the loading on my '128 for lack of a working VIC-20. I may start scouting eBay again for one, but I do try to avoid paying more than $5 for anything without a G4 processor I'm particularly interested to find the Robin Hood/Lancelot game. Since there are no sprites on a VIC, they must be simulating same using redefined characters, which is very impressive technique, especially given the RAM crunch.

They still (marginally) support the NES, albeit not for free. I've never had a problem with a system, but a friend did a return on a GCN due to CD player problems and had a new one in his hands the next day -- before they could have received the broken one -- and just paid S&H. But he did end up with a black one when he'd started with platinum, so nobody's perfect.

I'm sending a fax# at my office in a PM, if you'd like to pass it along?

Thanks to the wonders of M4, and my total inability to perform long strings of arithmetic, and the joys of Stella, ... no I was worried about it at first. In fact, you'll see an earlier blog screenshot where I was having problems on I think it was line (4,1) because of boundary crossings. There's only exactly one branch in the kernel -- on every second line -- and it's always taken (i.e. one of two branches are taken, so there's always a branch). The thing is, I set all my timings experimentally, running in Stella and deciding to add (n) cycles to each line with a bunch of special-case code like if [ $1 == 7 && $2 == 0 ] SLEEP 8 endif When M4 unrolls the loop, it does so with the variables $1, $2, and $3 set to the triplet, the offset within the triplet, and odds-or-evens (I have an example in one of past couple days' blog entries) To make sure that minor code tweaks never do "nudget" where the boundary falls, though, I did put in this monstrosity: jmp draw_rows align 256 draw_rows: Thus guaranteeing that whatever I do to the prior code, the kernel will always start on a page boundary. That's fine for now (development); once I declare a "code freeze" I could probably compress out that gap and deal with the consequences once, but right now the rest of the kernel's in a state of flux, too, and I'm not as pressed for space now as I shall be, shortly. Incidentally, the kernel (unrolled) for tile drawing is weighing in around 1K, which is terrible because it constantly accesses map data, thus preventing me from sharing it across memory banks. (I can't do mad amounts of bankswitching within the kernel). Here's the frightening but plausible thing I thought of ... splitting map data such that the data referenced during the first 6 scanlines was found always in bank 1, the next 6 in bank 2, the next 6 in bank 3, the last 6 in bank 4. But even with Perl compiling my data and M4 composing my code, I'm not insane enough to want to split the data up like that. It'd be a logistical nightmare, more so than it is already. So i've to bite the bullet and duplicate about 1kiB of "identical" (or nearly so) code in each memory bank that's to display tile-based data. Including support stuff, that's really closed to 6 pages, possibly more, of the 16 pages banked in. 10 pages isn't a lot of space, especially given that there are alignments needed for several data

Many VIC-20 games suffer from this, but not all. Using the same sort of techniques that other machines without hardware sprites used (the Spectrum likely being the best example, and the Apple II after that) it's possible to have fairly smooth movement, and transparency, though colour clashes will happen. I haven't seen an example of one, myself. The lack of a bitmap display mode is more damning than the lack of hardware sprites, I think. Can you think of any examples of games that had smooth overlaps between objects on the VIC-20? I'd genuinely like to try some out. (Sadly, the video sub-board on my real VIC-20 is burnt out or something, so I'll have to check them out in VICE ) PS: in case I was unclear, the Spectrum and Apple ][ both had bitmap graphics modes, but the VIC-20 has only "text" mode. By "redefining" characters, you can create some graphics, but since the "font" has 256 character slots and the screen has 528 character cells to fill, and a stock VIC-20 has typically 8K total RAM, of which the screen takes up 528 bytes, the font 1KiB ... that doesn'y leave much, if any, room for redrawing parts of the character set or similarly faking a bitmap display. Title screens and so forth that try to "fake" a bitmap on the VIC-20 usually just leave a wide, blank border so that 1/2 of the character cells on the screen are empty. If a game has a few, small graphics -- say, a "space invaders" clone with 2 or 3 types of Invaders -- then you can spare characters for the invaders drawn at, say, 2 character cells full, or 3 character cells with 4 pixels' blank space on each side... anyway, suffice to say that it's really really difficult to do and I don't have anything in my collection that actually does it, but it's not impossible by any means -- especially on a cartridge. (Tape loads would really make it worse)

Timings on the first row are perfect, and the HMP0/1 bugs are basically flushed out finally, so that's all good. There's still some crap involving line (7,2) on each row, but there should be sufficient SLEEP cycles now that I don't use WSYNC to make up for it. A new bug that crept in somewhere there, though, is that the cursor pointing into the map data seems to be drifting. Here's the lowdown. There's a big macro that draws a line. Lines are grouped into triples, and odds & evens. So, the main drawing loop for one row then just calls that macro 24 times: row_start: DRAW_LINE(0,0,0) ; Triplet 0, first line, this line is even DRAW_LINE(0,1,1) DRAW_LINE(0,2,0) ; Triplet 0, third line, this line is even DRAW_LINE(1,0,1) DRAW_LINE(1,1,0) ... DRAW_LINE(7,2,0) OK, so far so good, right? Line (7,2) -- which currently bears the lovely debugger breakpoint convenience label of "seven2" -- is a "no draw" line which prepares for the next row. So, really, I'm drawing 23 lines. Depending on which line I'm on, I precache various data like the tile pointers for the next row or the bitmaps for the next line triplet. Even and odd lines alternate updating decorative tiles (P1) or the player (P0) as appropriate. There are tile ID pointers in RAM for "this row" and "next row" (copied over in (7,2) after being decoded during the row), and the triplets precache bitmap data for the next triplet, and alternate between an "odd triplet#" and "even triplet#" bitmap buffer for drawing PF1/2 left/right. (e.g. during line triplet 1 I precache the bitmaps into the "even" buffer while drawing from the "odd," then in line 2, precache "odd" while drawing "even"). During this maddening mass of multiply-indirect lookups, I have to hit PF2 exactly at the middle of every scanline and HMOVE exactly at the end. (I can't spare any screen lines to use RESP1 to position decorative tiles -- other than the top row -- so I have to use HMP1 to move the P1 position if there's a decorative tile on a lower line not in the same column.) The important thing I have working, now, is that the PF2 and HMOVE always hit at the right time. It's a tiny thing to have no HMOVE bars, and in fact, I'd probably be just as happy to have them all the way down, but once you're into that kind of cycle-exact timing mess to do reflected asymmetric playfield, you might as well go full monty. "seven2" however is not always exiting at precisely the right cycle. Also, I advance the pointer into the map at various times in the loop, basically every time I pull a tile ID out of the map I "inc" the map cursor, and at the end of a row I have to skip over some colour and decorative tile data to start the next row. Well, somehow in all that mess, I'm getting the map cursor off by one (and I haven't looked at it closely enough to figure out just how), so it'll start pulling colour data in as though it were tile ID's, thus looking up garbage data in ROM instead of valid bitmaps, and likewise getting decorative tile bitmap pointers instead of colours, and so on. Basically the whole "wild pointers are bad" "well, no shit" story. So, that's the last real hold-up on the tile-draw, although i've got an open "RFE" to try the cleaner (pixel-based rather than tile-plus-pixel-offset based) joystick code out and see if it's reliable. I expect it actually will be. Combat kernel is due for some pretty significant overhauls and then the connections between them all have to be stitched back in. The next time I test on the hardware I should be seeing the pieces working together. A public alpha test is not far in the future. Given the amount of time I'm actually hacking on this, though (a couple of hours a week... I spend more time in the forums here probably, at 10 minutes a spell) "not far in the future" probably means early August for a real playable demo with all the major pieces intact. Some of that depends on Mayday's equally mad schedule, though. It would help to have some map data or graphics or scripts to all this And, to that end, I need to write a new map coimpiler to handle the changes I made going to the "24lk" format. Kernel size has actually grown a bit from the timing fixups, but there are a lot of NOP's that I can probably compress some work from (7,2) into them now. If so, I may even be able to update some of the graphics during (7,2) as well. It does annoy me to have "dead lines" all over the screen, even if they should blend in with the background nicely in the real world, I guess.

Has it?

That one I've seen So picture that, but every object on the screen has to "jump" by 8 pixels every time it moves, and any 2 objects in the same place, one of them covers the other, completely hiding it... I think you'd quickly go from "terrible" to "what the f--- was that?"

Got my HMOVE's almost all striking at the right timings, but not my PF2's, and somewhere in there I really walloped the HMP0 when I shouldn't have. But, notice where the HMOVE bars are(n't). So, 20 minutes' work in Stella debugger knocked out most of the problem... and the remaining stuff should be as easy (...?!) to clear up. I hope.

Well, actually, it looks like s/he "stole" 100% of the code, then added more to it. (i.e. it's more like 56% is the original code, with minor alterations, the rest is new).

In a very non-optimized non-expert disassembly, it looks like almost all of the Space Jockey code is (mostly) intact, with a few extra subroutines wedged in and most of the artwork changed. Of course, in those days, without having the advantages of modern assemblers and disassemblers, the wise thing to do would be to leave as many things in place, so that you wouldn't inadvertently disturb something. That implies that the hacker did not have access to the original source code, but I think this was assumed from the beginning.

Yes, it's always 2 paddles to one port. You are testing this with a paddle game, e.g. Breakout or Warlords? They're not interchangeable with the joysticks. PS: See http://www.atariage.com/controller_page.ht...&ControllerID=2

I'd really doubt that anyone would waste their time, in fact. The VIC-20 had somewhat "random" memory placement (depending on how much RAM you had, it would appear in different places), making it difficult enough to release binary apps for, but on top of that, there was no dedicated bitmap mode nor hardware sprites, so you're limited to mapping 256 8x8 pixel "characters" to any of the 20x24 (IIRC) screen display positions, one background colour, and a choice of one of 8 (?) foreground colours per cell. It's hard enough to display something full-screen to look like a bitmap; doing Double Dragon would be a nightmare, and Street Fighter? I think the VCS versions of both would be an order of magnitude easier to program. At least.

OK, this is a little bit interesting, but it's far more "conspiracy theory" than useful info I ran some rough comparisons of a raw disassembly of the Air Raid and Space Jockey binaries from AtariAge. My thought was, basically, to look for signatures. One pair of strings found in Air Raid (and not Space Jockey) are: VDHLHD PRTV edit:typo corrected Googling for that, I only get http://starbase.jpl.nasa.gov/archive/vo1_v...bxx/f059b01.ibg hm. I need to look at context.

Well, the code itself, we know the origins. maybe to run some "diffs"... but there isn't much "personal style" to 6507 binaries unless, like I would, s/he hid his/her initials somewhere in unused space.

If it's RS-422 you can buy the cables for ~$15 via e.g. Belkin... I have several of the mDIN varieties as RS-422 mDIN (about 1/2" diameter) are used on SGI and OldWorld Macintoshes, and RS-422 DIN were used on e.g. Apple //c.

Not to turn up the flames too much, but the PSP has, to my eyes, "more powerful but boring" hardware. It's an interesting blend of, say, a Nokia 7700 and a Palm Pilot with a 3D chip, but ultimately, the NDS has microphone, WiFi, touchscreen, all of which (in my book) are "cooler" hardware, even if its 3D engine is "only" N64-quality and so forth.

Well... dunno if it counts, but: BattleTech Center. Does that count as one machine?

Observations (pardon if any of this is too painfully obvious, but, for the record): The Telesys cart has obvious branding on it (in the PCB), and the PCB traces were written out very orthogonally, rectilinearly. The cart has a punchout edge only at the top, with smooth edges on left and right. The U.S. Games cart likewise has the maker's mark etched into the PCB, but has a somewhat more fluid, hand-drawn set of traces. The PCB also has punch-outs on - let's call it the "left" - side and the top. The Air Raid cart has even more fluid, perhaps calligraphic, traces, varying in width to meet the contacts on the edge connector even. In other words, I doubt the same person drew any two of these PCB's. This, however, sheds no light whatsoever upon the makers except that I find it unlikely US Games would have (a) forsaken their branding, or (b) secretly created men-a-vision out of thin air . . .

My goal there was originally to do matched-cycle work on every frame, i.e. have joystick and sound code that was constant-execution-time, but when I got down to it, it's probably going to be easier to just cap it off with the timer PS: Yes, I realize that my above post is probably one that I'll be laughing about in a few weeks. "No need to use the overscan, but I forgot all about (---nightmare-here----)..."

I got both of mine for free, for fishing in the bins of stuff that the Salvation Army deemed "too crappy to bother selling." I haven't gotten 'em hooked up to see if anything works, yet, though. So, figure they sell NES'es for $5, that'd put the street price of a 5200 in Central Florida at about $2.00 or so? But, only one had a box.

I've owned carts in the past that have the exact same stenciling on them. Not to read too much into it, but ... do you recall who the mfr. was ?

Actually, the drawing is complicated, the script interpreter is complicated, but ultimately the game logic is downright pedestrian. EG: The tile draw code has one moving object under joystick control. That's it. Almost everything else is static. The combat code is turn-based. The drawing is complex, but the logic involved boils down to rolling a dice once every 10 seconds or so. At the moment, about 1/2 of the vblank is idle time. I think I had 20+ WSYNC's in a loop to pad it out... plus a couple of others embedded to do HMOVE's. I wouldn't rule out using it, but ... it's so little time ... *shrug*

I'm not sure, in whose book is that "acceptable." See, I can understand the theory of 5% failure rate -- during QA -- but any failures after QA passes are a seriously bad reflection on the company. That goes for software, hardware, whatever. Cast in not-very-different light: Mc Donald's probably serves meats to a million (?) people a day. Now, suppose that their meat supply had a 5% chance of having "mad cow." 5%, but caught before QA: no problem... nobody knows the wiser. 1%, not caught in QA: 10,000 people die. OK, nobody's died from an Xbox failure (afaik... yet... ) but I don't think it means that lax corporate standards are "acceptable" to me (or a lot of other people). PS: local statistics for my circle of friends: 4 purchased US 360's. 1 purchased a JP 360. At least three of the US models had to be returned, one took a replacement, two took refunds. The JP model is on its second replacement (3rd unit) but seems to be stabilised now.