Bruce Tomlin
-
Content Count
3,690 -
Joined
-
Last visited
Posts posted by Bruce Tomlin
-
-
There could be other reasons. Maybe the way the NES does graphics is less efficient for some reason. Maybe it's because they had to have that separate CHR ROM. Though with what I know about the way the 7800 stores its graphics, I'd be surprised if it was more efficient.
-
Okay, now that Sega CD titles are being listed, you should be ashamed of yourselves for not yet having mentioned Keio Flying Squadron! It's a really good alternating shooter/platformer (of which I'm not all that great at either). And it's got that Parodius feel to it.
http://www.workingdesigns.com/museum/sega_...ftware/keio.htm
-
Wow, definitely the real thing, can't mistake that Atari case styling. Congratulations, you have one of the few Atari 5200 systems that isn't as big as a house. :-)
I'd like to see what a 2600 adapter looks like on one of those things. It doesn't look so big on a regular 5200, but it's gotta be half as big as this one.
P.S. A mod needs to go and delete all those double posts. Especially the first one.
-
There are sveral step up/down chip regulators if the operating voltage is a problem on a newer more current chip.The problem with FPGAs is, if you change chips, you almost certainly have a different gate layout, and all those nice bankswitching files will need to be completely different, so there will be two of each to keep track of. There were also some issues Chad didn't want to worry about with regards to TTL level bus signal compatibility.
-
I'm going to add another vote for Zombies Ate My Neighbors. Lots o' fun.
-
Google for "sio2pc cable". Why not turn your PC into a big Atari disk drive?
-
It's kind of hard to figure out what you've got without pictures.
-
Gauntlet IV, definitely.
I've heard that Flicky is good if you like Mappy, but (even though I did eventually find a copy) I still haven't played it yet.
And you probably shouldn't bother with the Sega CD add-on unless you can find some of the ten or so good games (mostly RPGs translated by Working Designs) for it. Or unless serious homebrew activity happens with it. (I'm pretty sure the CD games aren't copy protected, just region-protected.)
-
Two really bad ports:
Xenophobe for NES. That was so bad that (back in the early to mid '90s), I traded away the first copy of it that I found. I do have a copy now, but that's because I'm on a slow quest to collect NES games. The controls are all wrong, and it's like whoever wrote it only had ad copy of the original arcade to work from. The 7800 conversion is much better, except I remember there's a bug when you only play player 2 that starts player 1 after like 15 minutes.
Missile Command/Centipede (and maybe something else?) for Genesis. I first saw this on a demo unit at a Toys R Us. It was such a bad port, it almost stank up the whole aisle.
-
Yes, you need a burner. And it will not read CD-RW disks, so buy a spindle of the cheapest CD-Rs you can find until you've figured it out.
The general overview of the process is, you have to burn a spacer track of 4 minutes audio, figure out what the number of the next block is (it may be off by 2, depending on burner and software), then build the data image using that number and burn it as the second track. That data image will need something called "IP.BIN" merged into it after mkisofs and before burning. There is also a file usually called "1ST_READ.BIN", which must be scrambled (not encrypted, just scrambled) to be loadable. Usually it's pre-scrambled when you download it.
I suggest you start with http://www.dcemulation.com/ for info.
-
I'm sure Atari wasn't very keen on the idea of a 512K byte cartridge. Especially since I noticed in the Devcard documentation where it says that Atari policy was that no more new games would have RAM in them. If they were too cheap to spring for some RAM, they would also be too cheap to spring for a ROM of sufficient density to have 512K on a single chip.
Besides, the Super Cart board only has room for a 28-pin ROM chip. I just opened a Commando cart and was surprised to see 32 holes on the board for the ROM. Which makes Commando the only production cartridge able to support 512K bytes of ROM.
-
And I think the ComMander is for C64. IIRC, the second button isn't wired up like either the CV or 7800 expect it.
-
But a hack usually implies that something noticable is changed, like the graphics or game play. Going from 5200 <-> XE isn't enough of a change to be a hack, in my opinion, just a port.
-
I've never seen any noticable problem with scrolling on the 7800 version (having not gone far enough for enemies to slow things down with the "Space Invaders effect"), so I suspect that the way 7800 display lists work means that the scrolling is much more efficient.
It should be possible to verify this now that the source code has been released, but if the display lists are rebuilt every frame (which is the way I plan to do a project I'm working on), it's not really scrolling, it's just putting things in a different location on the screen. Sort of like how the Amiga Bounce demo works... it just changes a few registers ever frame, and the graphics chips simply read the data at a different time.
-
As for a second run, the waiting list is no where near long enough to do one. And I was just informed today that one of the parts in the CC2 has been discontinued. So I have to say it doesn't look very good.That sucks most mightly. The FPGA, I presume? I recall you mentioning that it was already obsolete, but that it was important because it was one of the few 5 volt FPGAs still available. That would be the trickiest of the three parts (FPGA, flash, RAM) to replace.
-
If I was rigging up batteries like that, I'd probably use four NiMH D-cells and wire it to the back-end of the power supply, bypassing the regulator entirely. When using batteries of the correct voltage range, the regulator is nothing more than a space heater.
I'm not sure about the 7800, though, as I recall that its power supply is more complicated and parts may depend on having the unregulated 9V available.
-
Unless you're really in love with Robot Tank or Decathlon, there isn't a lot of need to do this. If it ain't broke for you, don't fix it. All I care is that it's not a problem with the CC2. (The reason is because as a 7800 cart, it can use the phase 2 clock input for timing instead of guessing when to switch banks.)
-
No, because 1) the only two games that know how to use it already have one, and 2) some carts put RAM at that address and wouldn't be able to handle the conflict.
Not sure what folks without a CC2 are going to do if someone creates a homebrew with Pokey support, but let's see a few 7800 homebrews actually get written first.
-
It should be possible to use the second button of a 7800 joystick (and maybe even the second button of a Colecovision joystick) as long as you set up the 6532 properly. No circuitry was changed inside the console to make this work, just in the joystick itself, by rigging resistors from the fire buttons to the paddle inputs.
In fact, exactly the same code should work for both 2600 and 7800 mode. But right now I don't know where any sample code is for doing this.
The real problem is that you then condemn people to using those damn Prolines if they don't have imported joypads or modded sticks/pads. I still have yet to convert a Wico stick, mostly because I'd like to find a way that works with both the 7800 and Colecovision. (I want the switch on the sticks to swap the base and stick buttons, so I can't use that as a mode control.)
-
Weight is the best way to be sure in many cases. Usually the chip in a 2600 cart was a mask ROM with a positive chip select. Standard EPROMs have a negative chip select, and need a 7404 inverter to work in a 2600. The weight of the extra chip (and the extra weight of a ceramic EPROM's case) would be rather difficult to hide. 2600 supercart games should also have a distinctive weight with two 24-pin chips on the board.
On the other hand, many really rare games (and protos!) were made with an EPROM and a 7404, so you can't always be sure.
And then there's the 7800 carts, where carts with a supercart board can be recycled easily for a repro. But 7800 supercart games used 28-pin mask ROMs, and because of the programming input, 128K-byte EPROMs are in 32-pin chips. So even 7800 repros can often be found out by their extra weight.
One thing that could help is if a repro is put in a modern transparent case. But that doesn't stop someone from taking it apart and putting into in a salvaged Atari case.
And of course, if the PCB is red, it's probably a repro. :-)
-
Mask-ROMs may die, just as any chip might, but they won't rot like EPROMs do. Even fuse-PROMs and fuse-PALs can suffer from rot, if the blown fuses start to re-crystallize just enough to conduct randomly.
-
On the subject of MMC cards, I noticed the other day when I was at Fry's, that they had a new endcap display for Palm. There were carded versions of memory cards, which while Palm branded, were apparently (due to the way things were worded on the package) all MMC cards. This even though all the Palm PDAs in that display were apparently capable of using SD cards.
The interesting part is that there was a 256MB card for $99.
-
The impression I got when reading that a couple of months ago was that something was screwed up about the bank switch logic in the Dark Chambers 2600 cartridge. So they did something (which apparently already had been accounted for in the logic board design, but diked out in the first revision to be manufactured) which made that cartridge work, but Robot Tank and Decathlon would fail. These problems are apparently due to the electronics of the actual cartridge itself, which is why the Cuttle Cart 2 doesn't have special problems with these games.
The rest of the problems are mostly due to the slightly different geometry of the cartridge port plastics. And then there are a couple (like Space Shuttle) which depended on the B&W switch being a switch and not a button.
-
Yep, it's 8-bit. Which has nothing to do with why the graphics are so primitive. That's because the TIA is a 1-dimensional graphics chip. Yep, 1D. It only remembers enough information for a single scan line. That's why a locked up 2600 will display a lot of vertical lines.
-
1
-
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
New digital signature generator
in Atari 7800
Posted · Edited by Bruce Tomlin
It's a direct translation of the 68000 code into C. The only way in which the signature is different is in the choosing of the "wildcard" byte to find a valid solution. The original utility added together a bunch of assorted numbers to determine its starting point, when it really didn't matter. If one in four solutions work, there could be over sixty valid signatures. I could theoretically make the code take five minutes finding every one of them, and let you choose the most asthetically pleasing combination of hexadecimal numbers, but that would be silly.
It's in the documentation. It looks at $FFF9.Which doesn't help much at all when using the real hardware all the time. I use a hacked 7800 which ignores the result of the decryption. And I now have a clamp-on LCD screen.
I'm not entirely impressed with emulators anyhow. I just tried my current project with MESS 0.70 (the current Mac OS X version), and it completely duffed the emulation of 320B video mode. There's no way could I have gotten as far as I have by relying on an emulator. :-)