Jump to content

Eckhard Stolberg

Members
  • Content Count

    953
  • Joined

  • Last visited

Community Reputation

39 Excellent

1 Follower

About Eckhard Stolberg

  • Rank
    Dragonstomper

Contact / Social Media

Profile Information

  • Gender
    Male
  • Location
    Germany

Recent Profile Visitors

12,758 profile views
  1. I bought that trakball in the late 1990 in a small store that specialized in used and NOS Atari ST stuff. They were doing repairs in the back, so it is very well possible, that my cx80 was modified there. Or it might have been modified by the previous owner, since it was a used device. This is a picture of the board inside my trakball. I hope it's detailed enough.
  2. In case you haven't found this yourself already: We have recently discussed this problem in this thread http://atariage.com/forums/topic/242264-help-with-dumping-fe-carts-for-clone-project/?do=findComment&comment=3313924
  3. A12 is used as a chip select line for the cartridge ROM on the VCS. Therefore the cartridge shouldn't be driving the data bus when you feed it addresses below $1000.
  4. I always assumed that FE bankswitching would trigger on address changes in the stack area. If you look at the internal structure of the JSR and RTS instruction, you'll notice that in both cases there are two consecutive accesses to the stack before the high byte of the destination address will be on the data bus after the next address change. Since one bank resides in $fxxx, while the other is in $dxxx, that means that D5 could be used to select the bank. So if you feed addresses $01fd, $01fe and $01ff directly one after the other into the cartridge while bit D5 on the data bus is set to the bank number you want to switch to, that should allow your cartridge reader to access both banks in a FE game.
  5. Now I see. The same thing seems to happen with your Missile Command trak-ball hacks and to a lesser extend in Indy 500 when using the mouse to emulate the driving controller. Is this Windows specific, or does it happen on Linux and MacOS too?
  6. It isn't really a bug. It's a feature, as this bias exists on real paddles too. A paddle game would discharge a capacitor at the start of the frame, and then measure how long it takes to recharge the capacitor through the potentiometer in the paddle by polling a certain memory location once every scanline. Due to the limiters in the paddle it provides about a 270 degree angle. When the paddle is turned all the way to the upper end of the potentiometer, it takes about 600 scanlines for the capacitor to recharge. As a result a game that measures the paddle during the 200 scanlines of the visible part of the frame (as most games do) would use about a 90 degree angle on the paddle, which is easy to control. But it also means that the dead zone on the lower end of the potentiometer is much smaller than on the higher end. Since Stella emulates the full range of the paddle, you are experiencing the bias problem when you use the mouse or the keyboard to emulate the paddle. It would be possible to have user controlled limits for the upper and lower end of the paddle range in Stella, but it would have to be on a per game basis, as each paddle game uses a slightly different part of the paddle range. IIRC some games even use different ranges during different game variations. And messing with a all the possible input combinations for the paddle emulation would probably be kind of pointless, as the reason why games are more difficult to control on the emulator and a LCD TV than they are on a CRT TV is probably the lag of at least one frame that is inherent to how the emulator and the LCD TV work. This is true for any kind of VCS controller. Stella needs to read the input on the PC before it can render a frame. And it can display a frame only after it has been fully rendered. So there is always a delay of at least one frmae between when you move the controller and when you see the result on the screen. On a real VCS connected to a CRT TV the controllers are read while the image is being displayed. A LCD TV would need to buffer at least one frame from the analog input, so that it's video processor could scale the image to it's native resolution. Therefore there is also a lag that makes controlling the game more difficult.
  7. I did infinite lives hacks of both games when we were fixing the protos so we could see how many levels there were and if the games were stable enough. Maybe CPUWIZ would replace your cartridges with ones that have these binaries on them, if you ask him nicely. Or maybe he'll just create a Game Genie 7800 for you, as messing with circuits would probably be much more fun to him than having to deal with the post office twice. ZombiePlutosSirius.zip
  8. Here is the fixed binary I did in 2003. IIRC, I removed several unnecessary writes to INPTCTRL in the startup code. That seems to have fixed the issue on real consoles. I think if you access INPTCTRL too soon after you locked the console mode, it might lock up the 7800. KLAXfix2.bin BTW, it seems that you forgot to update the signature key in your binaries.
  9. Softgold has nothing to do with Graftgold. Softgold GmbH was a German publisher who bought Raibow Arts, the company that published the original C64 version of Jinks. Peter Pachla programmed the 7800 version of Jinks at US Gold. At least he says so in this post on rec.games.video.classic. https://groups.google.com/forum/#!original/rec.games.video.classic/zThMgq_ZPZo/sx-9ZLUomeIJ US gold also had the rights to the home versions of Gauntlet, so I suppose when Peter experimented with using digitized sounds in Jinks he probably just had the Gauntlet samples already available in a usable format. That's probably how they ended up in Jinks.
  10. Since I'm the one who wrote the cartridge reader software and therefore am responsible for the layout of those two ROMs, maybe I should explain why I chose the bank order to be the way it is. At the time I didn't have either game, so I had a friend who did, dump the entire ROM space from $4000 to $ffff for me. I then had a look at the code and found that they both do sta $ff80,x in the initialization routine, which I assumed would trigger the bankswitching. So I had the friend dump the entire ROM space from $4000-$ffff again while writing to $ff8x first. I had a look at the 16 resulting ROM images and found that only 8 of them were different, and that the difference was always at $a000-$dfff. Therefore I wrote the cartridge reader routine for 78AC bankswitching to read 8 banks from $a000-$dfff, simply because it was easier to read 16K in one go than to read 2 times 8K. Yes, I'm that lazy. Of couse it's entirely possible that the ROM in the cartridge has the 8K parts of each bank reversed from what DevOS returns. And from your research it's very likely that the bankswitching logic would react to any address above $8000. The games only use $ff8x though. And from my experience they both are 128K. If you can come up with a bankswitching logic that uses the inputs and outputs you found on the PLD that maps bank 6 at $4000-$7fff, the lower half of bank 7 at $8000-$9fff, the higher half of bank 7 at $e000-$ffff, the higher half of each bank at $a000-$bfff, and the lower half of each bank at $c000-$dfff, then that would probably be pretty close to what the PLD really does. But if you really want to be sure, you could try to find Kevin Cooper and ask him. From the Rampage ROM: "RAMPAGE - Trade Mark and Copyright Bally Midway --- Ported to Atari 7800 by Spectral Dimensions, Inc. EngineeringDesign Services - Atlanta, GA (404)442-8025 --- Programming by Bill Hawkins and Clay Turner of Spectral Dimensions, With many thanks to all the great people at Mediagenic/Activision - Tom Sloper and Perry Rodgers for their guidance and ideas - Glyn Anderson for his fine technical reference - Kevin Cooper for his novel bank switching design, as well as prototype RAM and EPROM cartridges - Steve Snyder for his artwork - Steve Imes for his in-depth testing which revealed more bugs than I care to admit. - and Luis Rivas, whose bulletin board service saved us untold dollars in Federal Express fees. -- Also Dave Staugas of Atari for the many software tools used in this development - and Jose Valdes of Atari for the design of the supercart development board. --- "
  11. I don't think this is the reason either. Both the NTSC and the PAL 7800s were made in China. The PAL 7800s were shipped to Europe directly, so Atari wouldn't have been exporting any consoles from the USA. And the BIOS code with the signature check had been exported years earlier for the NTSC version. I suppose it simply was cheaper to strip the BIOS code to the bare minimum and add the game code to it then it was to include a free game cartridge with every console. After all everyone who wanted to make games for the 7800 would still have to get a signature key from Atari to sell the NTSC version in the USA, so the key check wasn't really necessary in the PAL console.
  12. I don't think they are messing with the back of the tape player to switch games. It just looks that way, because the tape player and the console are standing very close together, and the host of the show is holding his arm over the tape player while he is actually swapping game cartridges on the console, when they go from the plane game to the horse game and then to the boxing game. Also I think the video is cut. You can see how the monitor loading screen comes up when the RAM cartridge is inserted in to the console. Then the engineer starts the loading process on the console and as he proceeds to press the play button on the tape player they cut to the start screen of the music program. So it seems that they cut out the actual loading process from the video.
  13. That's a music cassette player. Signetics, the company that made the 2650 and 2536 chips was owned by Philips at the time. Elektor magazine published a series af articles in 1979 (that later tured into a book) about a DIY computer based on the Signetics chips. In the book Philips is credited with helping with the hardware design and the monitor software. The computer basically consist of the signetics chips, a tape player interface, 2K RAM and a monitor ROM, that allowed you to type in HEX numpurs with the keypad and access the tape player. In the video there is a large cartridge plugged into the Interton VC4000. That probably is a variation of the Elektor computer. So the box that the cartridge is connected to most probably is a tape player from where the demonstrated programs were loaded into the cartridge RAM. It's only 37 bytes. The 2536 has all the RAM in the system. It contains 32 bytes for general purpose use and some memory for defining the sprites and the background graphics. Since tehre are 2+2+1 bytes of RAM unused in the sprite / background area, that makes a total 37 bytes of RAM that a programmer could use for the games data.
  14. The two bankswitched games by UA Limited use $0240 and $0220 for their hotspots. Maybe there is some connection between these two companies.
  15. I don't think this is possible. IIRC, one of the tests for 2600 games in the 7800 BIOS is for cartridge size. If you leave the extra address lines for 7800 carts unconnected, the BIOS will detect that and lock the console into 2600 mode. Since the PAL 7800 doesn't check for the signature key in the ROM, this is actually the main test for detecting 2600 games there.
×
×
  • Create New...