Jump to content

Eckhard Stolberg

Members
  • Posts

    957
  • Joined

  • Last visited

1 Follower

Contact / Social Media

Profile Information

  • Gender
    Male
  • Location
    Germany

Recent Profile Visitors

13,827 profile views

Eckhard Stolberg's Achievements

Dragonstomper

Dragonstomper (6/9)

46

Reputation

  1. Yes, I still have all my old code. But the latest version contains code to read Boulder Dash, so I have to be very carefull with whom I can share it. 😉 I don't think bankswitching hotspots are random enough to be detected that way. Even if the switch would happen in the middle of the data transfer, the value in both banks usually would be the same anyway. You'd probably get 0xff in most of the reads.
  2. I think that's the only version of the source code that I published. I changed the connection to an FTDI cable and added some more bankswitching types when needed later, but I think I only posted the binaries for those versions. You read the code correctly. First, two 4K banks get read, like for normal F8 bankswitched games. Note that I'm skipping the bankswitching hotspots in both banks to avoid having to reset the bank and to deal with possible random values for these addresses. I do that for all bankswitching types and RAM setups. I simple fill the ROM image with 0xff for all those addresses, since that is what ROM chips usually have for unused bytes. I don't think that ever caused a problem with any game. Then 0xff gets written to 0xf050 and 0x07 gets written to 0xf058. That sets to first data fetcher in the DPC to the highest address in the graphics ROM (0x07ff). That way we can read the full 2K of graphics ROM data from the first data fetcher at 0xf008. Finally we write 0x00 to 0xf070. That resets the pseudo random number generator, so that we can read the full 256 byte sequence from 0xf000. We probably could have added the algorthithm for that to the emulator instead, but it was easier this way, and I'm lazy. 😉 Yes, I guess I should have commented testtype.das a lot more. 🤔 IIRC, when we have established that we have F8 bankswitching without SuperChip RAM, the test for Pitfall II simply is to reset the random number generator and read several values from 0xf000 in a row. If they change, we assume it's Pitfall II.
  3. Hey Mitch, thanks for the welcome. Nice to see you are still around. 🙂 Unfortunately I don't have any of the nessessary tools installed on my computer anymore, and my Atari stuff is packed away, so a x64 exe is probably not going to happen anytime soon. Sorry.
  4. I don't know about all the modern ARM based cartridges, but all the data in the Pitfall II ROM image that Stella can play is available through the cartridge port. The 7800 DevOS cartride dumper can read the Pitfall II ROM just fine. I'd have to dig out the source code to see how exactly to access the graphics ROM and the random number generator, but I don't remember it being that complicated. If the cartridge dumper in the 2600+ is able to write data to the cartridge, it should be able to read the Pitdfall II ROM as well.
  5. 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.
  6. 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
  7. 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.
  8. 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.
  9. 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?
  10. 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.
  11. 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
  12. 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.
  13. 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.
  14. 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. --- "
  15. 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.
×
×
  • Create New...