Eckhard Stolberg
-
Content Count
953 -
Joined
-
Last visited
Posts posted by Eckhard Stolberg
-
-
(PS: if anyone has more information, please share, I will need it)
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
-
1
-
-
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.
-
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.
-
1
-
-
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?
-
1
-
-
It isn't really a bug. It's a feature, as this bias exists on real paddles too.I don't think stella needs improvement with lag issues. I think if we get the left-bias issue fixed that could improve things enough - because it makes moving in one direction slower than the other. I would like to dismiss it as a tracking problem, but it's too consistent.
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.
-
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.Still, I wish there was a "Game Genie" type device for the 7800. Since with both games you always respawn immediately whenever you lose a life, a simple "INF LIVES" code would let casual players plow through the whole game...
-
3
-
-
Any idea where one can get Eckhard's version? Google isn't showing the way, and the one in the AA database has the bug.
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.
BTW, it seems that you forgot to update the signature key in your binaries.
-
3
-
-
Getting somewhat back on track...Any insight as to why Gauntlet "clearly digitized straight from the arcade machine" effects were utilized at the Jinks title screen?
I couldn't find much on the developer "Softgold" other than being another name for "Graftgold". Graftgold's (published) game list does not show (a) "Gauntlet" (port) in any of its releases.
While hoping to find some ties to US Gold considering the number of Gauntlet related items under their belt, I almost forgot, we do have Gauntlet: The Third Encounter for the Atari Lynx right around the same period as 7800's Jinks; which, in turn, used the vertical mode of the Lynx. The only other game to do that under the Lynx is Klax - And we do have/found the Klax prototype for the 7800.
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.
-
1
-
-
Next step is to dump the ROM to see if it is really 64K or 128K.
In any case I have faith that RevEng an figure out the hotspot from the code, and the logic of bank-switching cannot be too complex after that, emulators got it wrong but likley only at 8K swapped pages so it should be possible to mock a compatible scheme that works with both games.
[who cares if it is the exact same or only good enough for those 2, there's no extra Activision game anyway]
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. --- "
-
The PAL 7800 doesn't have the cart signature check because the cryptographic check could not be exported outside the US, at the time it was released. Some PAL carts don't work in NTSC machines because the expected signature in the ROM image isn't correct.
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.
-
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.
-
I found a Swedish TV program from April 1979 where they visit Philips (!) research centre in Eindhoven, NL and talk about the future of video games. Throughout the video, one can see at least one or two VC-4000 consoles plus a number of games which clearly are for that system. However to the far left of the table, there is a such flat, square box that I can't identify.
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.
Does anyone have a certain answer on how much RAM the system has? I've heard 43 bytes but that makes no sense.
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.
-
2) The hotspots were changed to use a different logic chip to switch between banks.
- Bank 0 (normally $1FF8) ---> now is $02C0
- Bank 1 (normally $1FF9) ---> now is $02A0
The two bankswitched games by UA Limited use $0240 and $0220 for their hotspots. Maybe there is some connection between these two companies.
-
It should be possible to have the smaller board size and run in 7800 mode but it'd be a pain.
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.
-
1
-
-
Zu einem meiner Lieblings-Ruthe-Cartoons gibt's jetzt auch ein Video ...
-
1
-
-
That might have been an issue with the graphics you used. Mode 320B uses the same write mode as 160B. So if the pixels in your 320B graphics are set up in such a way that they would be displayed as transparent, if the data was used in mode 160B, they will show up transparent in mode 320B as well. Schmutzpuppe had that same problem while working on Froggie. See here: http://atariage.com/forums/topic/68549-320b-help/
I'm confused then. *Any* time I've tried to use that third color in 320B mode while using transparency it never shows up on the real thing. Is there something different you have to do (other than set the Write Mode and the DL header) in order for that third color to come out?-
1
-
-
The cartridge type auto detection can't detect how big the binary is that you transferred to the RAM cart. Also it works best when the 7800 has just been turned on. So in your case it's quite possible that a 32K RAM cart gets detected as a 48K cartridge. That's not indicating a problem with your RAM cart. If the binary that you transferred t the 7800 is 16K, then you need to use the -t7816 command line option when you read it back.
-
Can't help you with the hardware, but did you try reading back your binary after you have transferred it to the RAM cart? If it's not the same as the data you sent, this might help you figure out where the problem is.
-
It looks like Stella and Harmony both reveal the byte that is "under" the hotspot, which actually is $00 in all three banks.
If the Supercharger does not drive the bus, you might expect $FF (which would be the last value on the bus - CMP $FFF8 will fetch $2C, $F8, $FF.) So it's worth trying $1FF8, for instance, to see if this is true. This behavior can be simulated easily enough in Stella and Harmony, and this is a good time for Harmony as a BIOS update is in the works.
It seems to be a bit more complicated than that. If I do
ldx #$09
cpx $f000,x
lda $fff8
I get the value that is at address $fff8. But if I do
ldx #$09
cpx $f000,x
nop
lda $fff8
the SC will do a write to the RAM at address $fff8 too, even when writing is disabled. Therefore the the LDA will return the newly written value most of the time. Sometimes some bits are not set though. I haven't figured out why yet. It might be that I was switching the RAM bank that is mapped into $fff8.
-
Like I said, DevOS started out as a cartridge reader. And at supercharger audio speed it would have had to be silent for about 30 minutes while I recorded the 7800 beeping out the binary into a microphone. That's just not possible in our house.@Eckhard Stolberg: Why didn't you go the Starpath SuperCharger route? Loading games like a modem from a sound source? You could have saved millions of cassettes from the landfill!
-
1
-
-
I have a version of 7800CTRL, that uses one of those FTDI USB to 5V serial cables. Since it's library allows you to access all pins directly, I was able to implement the old protocol with it. But since the protocol transfers one bit at a time, and driver calls are slow on Windows, this version only works at a speed that is unusable for 7800 development. I only get 60 bytes per second instead of 6000 bytes per second on the old DOS parallel port version. So changing the BIOS to serial transfer might still be necessary.It may be possible to upgrade the parallel interface to USB with one of the new USB-to-FIFO bridge chips (here is a development module for one such chip). This would allow a more modern implementation of 7800CTRL on the PC side to use the same protocol, only through USB instead of through the parallel port. I started working on a Java-based replacement for 7800CTRL using the RXTX library, but I've long since lost the code.
-
1
-
-
Simplicity and me being bad a soldering basically.I would also be willing to help port the send/receive to a modern OS if nobody has done that yet. I haven't looked at it in years, but was there a reason it was done with parallel instead of serial?
The whole DevOS thing started out as a cartridge reader. The RAM carts came later. So at first we only needed to install the new BIOS, which is simple on some PAL systems, and a cable. Since the parallel port uses 5V like the 7800 joystick port, soldering the cable was simple enough for me to do it myself. Also I wrote the code while John did the testing and burned the final EPROMs for me. So having a simple but flexible transfer protocol that didn't need precise timing helped to speed up the development process.
I have some serial transfer routines halfway done. I know I always say I'll finish them every time this topic comes up and then never do that, but that is mainly because of all the 2600 dumping routines. Most of them run in the 128 byte RIOT RAM. For some of them space is tight and timing is difficult, so changing the transfer routine to serial might not be possible. That's why I usually give up pretty quickly. If the change is just for the RAMONA RAM cart BIOS, I might be able to finish them this time. Really.
-
No, the transfer cable connects the parallel port on the PC to the right joystick port on the 7800. There is no need to install a parallel port anywhere.From what I've read, the RAM cart has the Parallel Port installed on it. Has anyone instead mounted it and wired it to the 7800 instead?
And if you just want a RAM cart to test your own code without the need to read out the contends of existing 2600 and 7800 games, Graham Percy has designed a RAM cart with the transfer code build in, so you only need to modify the cartridge but not the console.
-
1
-
-
Here is the trick code:
This will triple the Cosmic Ark stars effect.
If you are triggering the Cosmic Ark effect on several or even all movable objects, wouldn't it be easier to use sta HMCLR instead, since it resets all objects at the same time?
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Atari 2600 Trak-Ball Games
in Atari 2600
Posted
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.