brpocock

I think there's limited support in dasm, but not to the level as ca65 (which I inaccurately referred to as as65 earlier). It's also great for banked-memory arrangements, since you can accurately mark segments as being banked or shared, or repeat a segment in the linker if you need to duplicate code in each of several banks, and so forth. In dasm, I'm finding it easier to manually sort out the duplicated areas and mark them with "org/rorg" pseudo-ops, but having a linker config file is nice. Plus... you've always the option to throw in C-level code for higher-level logic that's less time-dependent. (I can't imagine doing VCS/2600 kernel coding in C... the timing is far too tight... but even on the VCS you could do higher-level game logic in C.)

If anything, that might potentially hurt your case if it ever went to court, IMHO. Black-letter law, is, if you're editing someone else's code and copying it (e.g. burning EPROM's), you're in the wrong. As to whether anybody cares, I'd say, dump the name off it and nobody will... Companies like Namco are far more interested in guarding their trademarks than copyrights. Trademarks require active defense or the company could lose them (i.e. they could become a generic word)... Copyrights they are allowed to selectively defend, prosecuting only when they want to. If you really want to stick the name "Pac-Man" on it, I'd suggest sending a signature-required letter to Namco's offices, mailed the day that the carts go on sale, keep the receipt, and then wait for the C&D... PS. You might actually get some good advice on dodging trademark enforcements from some of the groups who publish Star Trek fanfics. Some of those organizations, e.g. "Starfleet International," have been running on just the right side of the law for decades, and know how to get things to work without a lot of hassle.

For the record, (and halfwise I'm just posting so this thread shows up on "My Posts" now ) I'm hoping to finish CiE more-or-less in line with its original schedule, and despite how primitive the test kernels might seem, most of the work there has been in the toolchain and Ursa script engines, so things should be moving along at a brisk clip now. I am thoroughly impressed with Paul's engine, though, definitely a different solution to the same "problem" but in many respects a more elegant one than mine. Different design constraints producing different results and all that. Best wishes to anyone able to pick this up ... if it's "unclaimed" after CiE goes alpha I might be able to take a crack at it myself

Are these PC-DOS/FAT12 diskettes? Drop me a private message if you'd like me to try to salvage their contents. I've an older Linux box just for rescuing half-a-dozen different removeable media types, including 5.25", Bernoulli, Seagate, and Iomega-Zip discs. PS: Should be able to read Amiga FFS diskettes also, although I haven't tried it. I've an ST here, too, but only got 3.5" drives for it, but I think that GEM's version of CP/M was pretty close to the DEC original, so I can probably recover ASCII files from those discs, at least. At worst, "strings /dev/fd1" can often ferret out a lot of source code... sometimes in slightly random order due to fragmentation :-)

It works fine on ppc/Linux. It's definitely the best C compiler for the MOS-6500, and its assembler (as65) is quite good, albeit incompatible in minor (syntactic) ways with dasm.

I had the same reaction the first time ... and then realized that the COLUPF was black, ergo, the "selected" pixels and the "empty" pixels were all the same colour regardless. Perhaps the same PEBCAK hit us both? Beautiful debugger, btw, guys. The only issue I've got with it ... and it's nitpicky at best ... is that I don't see how to remove a breakpoint set on a scanline by right-clicking. I don't think I could have gotten my tile draw working without the Stella debugger...

I haven't Flash, but I noticed this link also... http://www.youtube.com/watch?v=ix0fGy8CKSI...Wii%20e3%202006 Apparently a video of the virtual console screens.

Oh... and my Internet connection is somewhat back up, but mail probably won't work for a day or so yet because the cable bastards changed my IP address and my DSL won't be installed until at least Monday.

A while back, I posted some of my Perl utilities. Well, I finally got the 48-column sprite stuff into mkart, so, here's the latest. Oh, and this fixes a bug with 8-column sprites too. (The "bitmap pictures" weren't written to the comments field.) ramcart_disk.zip I haven't done playfields yet, and I need to for the Combat system in CiE, but ... just hasn't been urgent enough to get written. Oh... and mkmap is under the scalpel due to the epiphany and 24lk ... the new one has to do a lot more work including writing Makefile appendices and arranging stuff into ROM. It should be frightening/impressive.ramcart_disk.zip

I don't know the details of HDTV stuff, but both GCN and Wii support "progressive-scan HD" display. Apparently there are several hidef resolutions though and the GCN supports only the lowest one ... basically a widescreen version of low-def TV? ... the last I heard (pre-E3), the Wii doesn't have any higher-resolution modes, just greater detail within the frame.

The only counter-example I know of is Final Fantasy.

I dunno, I did it GameStop style... $30 game, $7.99 x 3 for three GBA's, $2.50 x 3 for 3 more link cables, and I already owned the one GBA-SP... so, not cheap, but not exceptionally bad. And a Hell of a party game... I went nuts and spring about $30 more to get rechargable battery packs for the GBA's and an universal power supply to charge 'em, though.

It's the tile lookups, I'm afraid. But really, the 3lk look is growing on me because it fills the screen more nicely. 8x8 tiles of 16 clocks by 24 scanlines treated as an 8x8 pixels region... means I have 4 clocks by 3 scanlines pixels... The player and decorations are still 2lk. The little demo I just posted the binary for is also 3,097 lines of code (excluding comments and commented-out code sections but including less than a page of graphics used in the demo)... I'll impose the gnarled nastiness of a fully unrolled kernel on the world only after I give up on it

Added another post with 'em. Or, they're in the Forums finally. grr.

second time today, the attachments failed me. executable: screenshot: starpath.zip

Yes, they mark the location to begin (again) generating the code for... but, a lot of speed-sensitive operations require precise alignment. On the MOS-6500's an operation that crosses a page boundary e.g. from $f8ff to $f900) often costs an extra CPU cycle. Also, there's a bug in the 6502 and 6507 that affects the use of e.g. a jmp instruction at the end of a page, but that's less likely to cause trouble.

Apparently the Game Cube can overheat if you leave it running for a few weeks outdoors in Florida in the summer. (Morning fog and dew is the norm, so add also the equivalent of 2" of rain spread out over time.) However, it shuts itself off nicely when it gets tired of the abuse and still works fine once it's dried out and cooled off...

First, because I was having "attachment issues" earlier, here again are: The kernel test image: tiledraw.bin And a screenshot of it courtesy of Stella: So, what does this show? First, there's a map of tiles: it's an 8x8 grid of 4x8 tiles. Each pixel is a playfield pixel wide and 3 scanlines tall. Second, there's a little crappy player sprite. He's just animating as though he were walking. He's 8x12px and is one player pixel wide by 24 scanlines tall. The player is rotating through some different colours, that's actually because I'm incrementing his "defense" points and it's doing a colour lookup to determine what type of armour he's wearing. What you do not see in the still is that every (n) frames the screen seems to jump, I think the sound code is spiking it over a threshold during the game logic section, I'll have to scatter some WSYNC's around more liberally to get rid of that. I think it's every 16 frames or so... for reference, the walking action changes every 4 frames I think. There's no music in this demo but I think I left the music playback code in. The movement code is stubbed out mostly because I was rapidly changing the map formats to do this new 24-line-kernel version and I kept breaking the "am I walking into a wall or not" logic. The TO DO list is much shorter now. I want to try to do the dual-banked version of the kernel to see if I can work colour changes back in. Oh, and the size isn't terrible either. The whole unrolled kernel is "only" about 1k long, with a total code length of about 1.5k. That leaves a "lot" of room (for a VCS game) for data. Oh, the player's positioning logic is accurate to 2 vertical lines, so he can "slide" between tiles in a fairly natural way.

Sorry... it seems to be firmly attached now: tiledraw.bin For your viewing pleasure:

Yeah, 'fraid so. The really stupid part? I forgot my Cube has a CD-R drive in it, I was looking for my Firewire one as I unpack... then happened to notice the mount path on the Cube was /media/cdrecorder. So, superb stupidity on my part. DISCLAIMER: This is just a test kernel. It's not a playable demo or anything yet! But the hard part is done: the kernel timings are worked out for the row-by-row drawing. Not that this will stop the flamage, but hey, constructive(?) flames encouraged. 3li resolution for playfield bitmaps and 2li resolution for P0/P1, multiplying out to nice 24li per row of tiles, which makes the 8x8 grid fill the display pretty nicely. Only P0 has line-specific (2li specific anyways) positioning though. I'll dump s'more details on my blog page and screenshots later if we've a slow day 't the office. PS. Don't blame Mayday for the art either. This is total programmer placeholder art. EDIT: DAMMIT. Here's the attachment. tiledraw.bin

Dunno for specific titles, but the Wii has WiFi built-in. So it's capable of connecting to your WiFi router and doing Internet gaming. (But how many games actually use the GCN -- that's "Game Cube with Networking" -- optional Ethernet add-on? ... perhaps so few because it's a rarely-used add-on product?) Oh, and a new Final Fantasy announced, almost forgot to relay that.

Highlights (from memory, working on some scripts while watching, so probably missing lots of details): Wii release date Q4 2006, which in order to make Christmas probably means late October / early November. Twilight Princess for both GCN and Wii released simultaneously. Wii version expanded with additional features over the GCN one, but basically the same game... thinking it's similar to Ocarina v. Ocarina: Master Quest or Mario 64 v. Mario 64 DS. Mario: Galaxy, new Metroid, some FPS from Ubisoft (...Steel...?), Wii Sports bundle including Golf, Tennis, and Baseball (also a launch title), Extreme Truckers(?) or something (offroad racer game of some kind) Both halves of nunchucks have 6 DOF sensors; speaker and force-feedback in at least the wand side; wand is accurate enough to use as a pointing device (mouse-type screen navigation) DS wireless linkage possible. Wii can run games while in power saver (standby) mode, including some kind of asynchronous events notification? -- message waiting, Animal Crossing events and such. Lots of new DS titles announced, too. No news on GBA or GCN titles, but third parties sure to stick with them for a little while since the NDS and Wii can play their games, so they get a larger installed base without dropping new users kinda. Guess the rest has been posted already. Yay Nintendo, and stuff.

The figures I've heard tossed about run in that ballpark, US$. That would absolutely rock! The conference is to start in the next 15 minutes! Wii!!!! Have a link? Nintendo.Com And... Twilight Princess on Wii... nice. What happend to the GCN version!?!? thank gods... both

The figures I've heard tossed about run in that ballpark, US$.

OK, smacking the shit outta Comcast, as I can't fulfil one promise... "the very minute" I had a stable display to upload the test kernel ... well, expect a lovely "spike24.bin" file as soon as I sneakernet one to the office, as Comcast has f---ed up my home Internet connection. (It came with the house. My solid-as-a-rock friends at Speakeasy should be installing in about a week.) However, there's a screenshot on my blog here from before the connection went down (sometime Saturday afternoon), sent very, very late Friday night. That was actually from spikeprecom.bin but I'm switching to something more like a "24-line kernel." The display just looks too scrunched, even with half a row hanging off the top of the TV. No, it's far from perfect, but it does still contain some no-op time in each row, it's not 24kiB long (one test kernel was... it unrolled a bit too much), and in fact, I think it lets me re-introduce some colour change codes that I was afraid I'd have to give up. So: it does exist and it will be uploaded, but requires me to unpack a CD burner or floppy drive or something. The switch from 18 to 24 lines, by the way, does effectively reduce the "pixels per tile" size from 4x9 to 4x8, but it lets me average out the "cycles per line" damages over three lines. (PS. I await barrage of flamage for no binary, but plead y'all hold off a day or two for my upload and then flame me for how lame the test kernel is, instead.) (PPS. My EPROM burner -- thanks Bruce Tomlin -- arrived Saturday also. My blank carts are in transit from Albert. So, I'll soon test on hardware, but not yet.)