LocalH

I deeg it. I deeg it As far as names go. Just take a cue from the old arcade bootlegers! What with names like Crazy Kong or heck... DONKEY KING We can just name it Monkey Dong 881804[/snapback] Heh, "Donkey King" was the name of the CoCo 2's unofficial DK port. Compared to many of the other CoCo 2 games, it played awesomely, although it also played a lot slower in terms of getting Mario to the top. I think N got pissed at the name, though, because I've also seen it referred to as "The King".

Go to ccs64.com if you want an unrestricted beta of both 2.0 and 3.0 (I prefer 2.0 myself, but it can't run in a window like 3.0). Also, as long as the Stelladapter shows up in the Game Controller control panel, then it should work with any modern Windows game or emulator (I have a PSX adapter that works great with just about anything). Which means it should work with CCS64 (both 2.0 and 3.0), VICE, WinUAE, and just about anything else (look in Game Controller and see what the system calls your Stelladapter, then choose that in your emulator, if it only gives you a list of generic-sounding "joystick # x", then choose the first one (probably 0).

Both emulation and original hardware kick ass, and both have their advantages and disadvantages. Emulation advantages: Economy of space - you can store thousands of ROMs, plus an emulator, on a hard drive that's pretty much roughly the size of two NES carts. Display clarity - barring special filters, the display is pixel-accurate to the original. Development - it is much easier to do build-test cycles with an emulator than it is to either do an EPROM burn-test-erase cycle, or even to download the test binary to a cart like the KK. Many emulators (but not all) also offer debuggers that are "external" to the emulated system, as opposed to the more limited debugging that you can do directly on the real hardware. Emulation disadvantages: Accuracy - some mature emulators are quite accurate (look at CCS64 and VICE with regards to the C64 - there is very little code that doesn't work on the emulators, and they use very obscure hardware quirks). Despite this, no emulator is currently 100% accurate, and there is ALWAYS going to be some little piece of code that will cause the emulator to puke. Experience - it's just not the original hardware. There's something to be said for plugging up a real VCS (especially a heavy sixer), attaching the original joystick, inserting a real cart, and getting the REAL 2600 experience. Especially if you play it on a TV of the same vintage. Legality - the only way to play classic games legally is to own the carts. Of course, if you do buy the carts, this opens the door to 100% legal emulation, but for most people (including myself), several of the games that you emulate were undoubtedly acquired illegally. That's why I am a big fan of emulation, and I'm also a big fan of classic hardware. That's also why, if I ever hit the lottery, I will make sure that my emulation is 100% legal, even if it means amassing a monstrous collection of original software and arcade cabs. I will also build a 100% legal MAME cab, with the original machines kept in a nice climate-controlled warehouse (thus, I can even charge for use of the MAME cab, since I'm not using my originals and the emulated copies at the same time).

Well, yes, but protos are generally EPROMs (in fact, I've never seen a proto with mask ROMs). That's why I said "EPROM-based carts". If you've got one, you'll most likely know it. I just didn't want to say "prototypes" because protos aren't the only carts out there with EPROMs - for example, I would imagine that many, if not all, homebrew carts are EPROM, and the same advice applies there, especially those in transparent or translucent cases.

My problem with N's legal strategy isn't their ROM distributing policy (since that echoes the law), but with their emulation policy (where what they say directly contradicts the law). They can go after all the ROM distributors they want.

General note to everyone: You'd do best to keep any EPROM-based carts for any system well away from UV of any sort. I know the case protects the chips somewhat, but still I keep my singular EPROM cart (which isn't a 2600 game at all, but rather a "release candidate" Sonic 3 for Genesis on EPROMs) well away from the sun, inside of a standard black protective case, just to be safe. You don't want to wake up one day long down the road and notice that your cart suddenly doesn't work. Of course, if it's dumped, you can get it reprogrammed, but it makes sense to delay the need to do so as long as you possibly can.

I'm not sure about the VIC-20, but I know that the C64 clock relationships have been documented as based upon the dot clock, since that's what the VIC-II handles, and the VIC-II pretty much drives the rest of the system. Quote from the aforementioned "VIC article", in the "important signals" section: There was also a table I saw in the textmag Commodore Hacking, which detailed the exact Hz value for each the CPU along with the dot clock, cycles/line, and number of lines, on each video standard (including the two different NTSC VIC-IIs, one with 64 cycles and one with 65). PAL C64's always have 63 cycles and 312 lines. I wasn't aware that there were two different 65-cycle VIC-IIs, however. I'm also mostly sure that the SID runs at the CPU clock rate - the pitch is slightly higher on NTSC as compared to PAL, running the same tune.

And it's one heck of a great gaming system. It's really fast, far more so than the C64 due to it's sprite handling (I'm assuming). Lots of very fun games on it too. I recommend Gridrunner, Star Post and Pharoah's Curse 876176[/snapback] The VIC-20 is technically slightly faster than the C64 due to the way the C64 handles character fetches. The 6502/6510 is a two-phase processor - and in both the VIC-20 and the C64, the video chip runs on phase 1, while the CPU runs on phase 2. The VIC-20 has enough phase 1 cycles to fetch all the character and color data that it needs to. The C64 has enough phase 1 cycles to fetch the bitmap data and some of the sprite data, but if you have more than 2 sprites (I think, don't quote me on this), then the VIC-II eats phase 2 cycles to prevent corrupted graphics. Also, every 8 scanlines, the VIC-II needs to steal 40 cycles from the 6510 in order to fetch character cell and color data (this is called a 'badline'). This is why you can disable the screen on the C64 and gain a small amount of speed, but you can not do the same on the VIC-20. This also details why Commodore had to release the 1541 - the VIC-20 with 1540 is actually faster than the C64 with 1541, simply because of the badlines. That's also why the 1541 had a 1540-mode, so that you could use it with a VIC-20 and gain full speed. Here is an article detailing the VIC-II's operation in the C64 down to the cycle level. I'm not aware of any similar VIC-20 documents, but I'd imagine it's somewhat simpler due to the lack of badlines and hardware sprites.

Well, as far as I know that's the only such email he's gotten, and there's been no response yet. Besides, as I mentioned to him in the email, eBay tends to pull these auctions anyway (and no, I'm not reporting it - the only one who could have it taken down is the legitimate rights holder). Actually, if there were enough people able to chip in $25 or $50, then I'd say it could easily be bought. If anyone decided to put together such an effort (only gotta raise $1100!), I'd chip in. I don't even have much interest in TG16/PCE stuff. I just want to see prototypes dumped and preserved for history.

Hahahahah...speaking of Mr. Frye, it sure would be nice if that 8K version of Pac-Man that he coded was still around...

If I had the money, I'd buy it and explicitly break that agreement. It's not for him to make that call, if I buy it, then I have the right to do whatever I want with it, including dumping it. I just sent the dickhead a question asking him who he is to put such terms on the game. I also mentioned that since he is not the rights holder, he has no position to make such demands. We'll see his response.

Theoretically, it should be possible to stick your own ROMs into the Activistion Anthology, given that you follow any size constraints that may exist. It would also be possible to rip the emulator code from the rest of the ROM. I would imagine the first would be easier unless the 2600 binaries are encrypted or compressed.

Original Pacman. The only reason people hate it is because it's not close to arcade Pacman. Had it used different graphics and not been a Pacman, then it would have been received much better. In and of itself, it's a great game, it's just not really Pacman, that's all.

This is weird. On the cable system here, we have some interactive games available. One of these games is called "Deal With It", and is basically Poker Solitaire. The only difference is, a royal flush is worth 450 instead of 500, there are two "discard" slots, and there is one card per matrix that is treated as a "double" card that doubles the value of all hands that use that card. This version of the game tracks the high score for the nation, and for the city that you're in. Guess what the national high score is? 3340.

Bullshit. 720p is HD. Anything over 480p is HD. 480p is ED, and 480i is SD. 1080i sucks anyway. You only get added vertical resolution on still images, motion is limited to 540 lines per instant in time, as opposed to 720p's 720 lines per instant (with 1080i, you have 60 half-frames per second, whereas with 720p you have 60 full frames per second). Also, it is nearly impossible to detect a difference in the horizontal resolution between 720p and 1080i - I have a very trained eye and I can barely see the difference. The only way that 1080i would be advantageous, is if the vast majority of games on the next gen consoles run at 30fps (since you can treat each pair of 1080i fields as a single progressive frame). Whereas with 720p, you gain the capability to run at 60fps, at a comparable pixel rate (you have less pixels per line, but more lines per 1/60th second). Interlacing sucks. 1080i should be boycotted. Also, to clear up a misconception, the FCC has absolutely no mandate for stations to broadcast HD. The only mandate is that stations broadcast digital signals. You can easily buy digital tuners that can receive SD, ED, and HD streams and display them on NTSC devices, albeit at a lower resolution in the ED and HD cases. In this area, there are as many SD 480i digital streams as there are 720p/1080i HD streams. Which is why, when CBS threatened to discontinue their HD broadcasts without a broadcast flag, had I been the FCC I would have told them "Fine, go ahead, but if any of your owned & operated (O&O) affiliates aren't broadcasting digital signals, then you're getting fined out the ass". But, I digress. Back to the point, 1080i sucks balls.

I always liked Megaball on the Amiga (and the clone DX-Ball for the PC). I'll have to check this one out, though, it looks awesome too.

To their credit, you'd be crazy to write a full game on current-gen hardware in assembly (whether it be PC or console). It would simply cost more and there's no need to get at the hardware, since 3D graphics don't tend to rely on raster-based control like the earlier systems were. That's a big contrast between earlier machines and modern - modern systems have more capability out of the box, but it's much harder to push past the hardware limitations than on some of the earlier systems (the C64 is the prime example here, but there are a number of other systems where programming efforts went past what the machine could 'officially' do).

Yeah, you can see what I was talking about on that Gen2 screenshot, on the right-hand side of the blue ball (and also a tiny bit on the bottom edge of the sword on the left). Another good place to see it is in the Sonic games, when you have no rings and the word "RINGS" in the HUD is flashing between yellow and red. Also check Sonic 1's Marble Zone lava...yeeuch. Look at Kega Fusion through a TV-out, and converted to composite with a Radio Shack adaptor (to cause the 'transparent' dithering to blend, such as Sonic's shield, or the tubes in S2 CPZ), that's what the Genesis' output would look like in an ideal world. Nice and clean. Damn, that X-Eye video really does look rough...

I've always noticed that Genesis composite output is extremely low quality (especially in areas of fully saturated red, it seriously looks like half resolution in those areas). And since the RF is modulated from the composite, that would be your culprit right there. From what I understand, this is common to almost all NTSC Genesis models (you mention that you hacked your Gen1 - was it a matter of just wiring up lines to an existing chip, or did you source your own encoder chip and use that with the RGB lines?). I have never seen a Genesis output 'clean' video through anything except RGB. The edges of highly saturated reds especially look horrible.

I've seen two different speed hacks. One merely changes the byte in the ROM that controls the delay between Ms. Pac's 'move' frames (so that instead of waiting, she moves on every frame). The other one was tied into the start buttons, IIRC, and caused the whole game to speed up, ghosts and all. In my area, it's rare to see a Ms. Pac without the first hack detailed above. I've only seen one Ms. Pac with the second hack, and I don't think I've seen any machines with the original Ms. Pac speed (except for the Ms. Pac/Galaga anniversary cab that's at the only arcade in this city, which I don't count since it's a rerelease, and not an original cab).

My SNES is two-tone, bottom half is yellowish. Bought it secondhand at the local Gamestop (it may have still been Software Etc. when I bought it, to put somewhat of a time frame on it). Oddly enough, if it were just UV exposure, you'd expect top halves to be more yellow than bottom halves - but in my case, the top half is grey. Dirty, but grey.

I was a bit off earlier, you don't have to press Up. When you see that screen, press A+B+C. If it's S1, you get the ongoing Bonus Spheres game. If you do it with any other cart, you get a single stage and a password that you can stick in the S1 version to play that same level.

As far as I know, the only effect any other games give you is a 'random' Blue Sphere stage derived from the GM number - that's also how it detects S1 (for the ongoing Blue Spheres game), S2, and S3. The 'any cart' version of the game also gives you a password that you can plug in to the S1 version to play that same level. For them to have included support for Knuckles in other games, they'd essentially have to write an upgraded version of the other game (such as Spinball), and do something similar to the behavior exhibited with S2 - and it was probably only cost effective to have one 'hidden' ROM. Remember, the game code in the S2 and S3 carts are effectively useless when running on the lock-on port. All game logic is contained within the S&K cart. The only thing the S2 and S3 carts are used for is art, and maybe the sound data (I haven't looked that deeply at it yet).

It's a hack, of sorts. The S&K cart holds 2304K of ROM - the first 2MB is the S&K game itself, and the other 256K is what we call "S&KUPMEM". If you've inserted S3 into the lock-on, it appears in the upper 2MB of the Genesis memory, and the game runs from the S&K cart, referencing the S3 graphics as needed, with S&KUPMEM completely hidden. If you've inserted S1, the same thing happens, except you get the NO WAY screen, and if you press the right buttons (I forget for sure, but it's something like Up+A+B+C), then you enter an endless set of Blue Sphere bonus stages. If you've inserted any other cart other than S2, you get a single Blue Sphere level based on the GM code of the inserted cart. If you insert S2, then S&KUPMEM is enabled, the S2 cart appears right above the 2MB S&K game, and the S&KUPMEM appears above that (at $300000). When the S&K game detects Sonic 2 in the lock-on, it jumps to $300000, and Knuckles in Sonic 2 runs entirely off that 256K code, referencing the S&K cart for Knuckles mappings and art, and the S2 cart for all the S2 tiles and data.

There's a slight chance that PS2 controller won't work with your particular adaptor - I have the one that Radio Shack sells/sold, and I bought a Pelican Real Arcade Universal stick to use with it, but was unable to get it to work (the adaptor works perfectly with a DualShock2). In this instance, I ended up buying a 4-port XBox adaptor, and using the XBox connector on the universal. Just a possible caveat to be aware of. Other than that, if you can get the controller working period (it shows up in the joystick properties, and the on-screen display responds to your button presses), then it will most likely work with MAME (and for that matter, any other Windows emulator that works with the standard controller services provided by the OS) once configured correctly.