Eckhard Stolberg
-
Content Count
953 -
Joined
-
Last visited
Posts posted by Eckhard Stolberg
-
-
Any chances in positioning the sprites at equal distances? You could create nice grid-like graphics then.It is possible to position the sprites at equal distances, but you'd either have to increase the gap between them a bit or fill the entire line using 9 copies of each player. Increasing the gap might be too much for a nice looking grid. But it has the advantage that the sprites could be disabled individually. Christopher Tumber uses this in his game Space Instigators.
Filling the entire line with 18 spites allows you to display a nice grid. But there isn't enough time to update the graphics and colours for both players in each scanline. I posted some experiments with this effect to the [stella] mailing list about 10 years ago. Multi5.bin displays a screen filling pattern. Grid2.bin displays a grid that you can scroll left and right. And extra18.bin displays 18 sprites that you can hide with the joystick. The sprites in the last one aren't positioned at equally distances though.
multi5.binGRID2.BINEXTRA18.BIN
Ciao, Eckhard Stolberg
-
PD means "public domain". Basically when you release a ROM to the public through, say, the Atari Age forums, you are giving people permission to copy it and publish it elsewhere. That's what I understand "public domain" to mean. What you are not doing is giving people permission to profit from it. So, I agree with Thomas -- be happy it's being distributed. There's lots of my stuff floating around; I don't worry about it.I don't know the intellectual property laws in Australia, but I think your interpretation of the term "public domain" is wrong. Public Domain means that no-one has any rights to the game and that therefore anyone could do what he likes with it - including distribution for profit. See wikipedia's entry on public domain for more details.
Luckily simply posting a binary in a message board doesn't make it public domain. Infact it doesn't give anyone any rights at all (except maybe the right to download the binary). If you wanted to allow people to make copies of your game or even to play it on an emulator or a RAM cartridge, you'd have to include a license text which allows that. Otherwise no-one could legally do anything with your game.
Ciao, Eckhard Stolberg
-
I was trying to figure out how a game reads the light gun (what memory addresses for the screen location and triggers). I even looked at the source for crossbow but for some reason it seems to be eluding me..
IIRC correctly the pin for "joystick right" goes low when the lightgun trigger gets pulled. The pin for the joystick button goes low when the lightgun is pointed at something bright. When the lightgun trigger gets pulled, the game waits for the next frame to start and then displays one frame filled completely with a bright colour. During this frame the game "races the beam" so to speak, as it keeps polling INPT4 in a short loop untill it goes low. Since a loop like that could only cover very few possible hit spots in a line, the game will repeat the loop in the next couple of lines after a 'hit' detection but shifted by one CPU cycle in each line.
If you want to emulate the lightgun, you need to have the DMA cycle stealing work properly, so that the IPT4 reads happen at the right screen position.
Ciao, Eckhard Stolberg
-
I understand that the Supercharger is capable of multiloads as small as a single page (256 bytes) and I think it can place a page of data into any page in its RAM as they are loaded. However, all multiload binaries that I've tried load the entire 6k. Does anyone know of any multiload binaries that load less than the entire 6k?I need it as a test binary for a new board. I can write my own of course, but it would be easier to work with something that's already out there.
IIRC Escape from the Mindmaster part 2 and 3 and Dragonstomper part 2 should load less than 6K. I'm not sure if they use any of the data that doesn't get replaced though.
Ciao, Eckhard Stolberg
-
Big, huge thanks to Shadow460, and Mitch who made this possible. Please note that you will have to manually force it to FE bankswitching in Z26 to work, but the newer versions of Stella should auto-detect it as FE bankswitching right away. If you have an older version of Stella again force it FE bankswitching so that it recognizes it.The FE bankswitched rom belongs to the earlier picture label carts. These text labels were later releases by Activision. I wonder if there is a regular F8 bankswitched PAL Space Shuttle out there waiting to be dumped? Anyone know?
z26 automatically detects the FE version of Space Shuttle too, which means that the binary must have been available for quite a while already.
And while I dodn't have a text label PAL Space Shuttle to test, I know that the HES release of PAL Decathlon uses F6 bankswitching. Whether that was done to make the game work on the newly released PAL 7800 or just because it was easier for HES to manufacture carts with F6 bankswitching I don't know.
Ciao, Eckhard Stolberg
-
Well I just dumped three different Space Shuttles (two white labels, and a similar blue text label). All were F8. When I forced my dumper to FE I got garbage. I'm pretty sure this was only released as F8.The PAL version of Space Shuttle uses FE bankswitching, so the original NTSC version probably did too. But that would have to be one of the older picture label carts instead of the newer text labels.
Ciao, Eckhard Stolberg
-
- Jinks - I know there's the XE version that was unreleased. Was this on anything else?
Jinks was originally a C64 game and probably got ported to other home computers too.
Ciao, Eckhard Stolberg
- Jinks - I know there's the XE version that was unreleased. Was this on anything else?
-
Is there anything different about this version other than the BIOS it's looking for?The only change I made to POLE278.bin was that I'm skipping the BIOS part and jump to the game code directly. I also added an instruction to lock the console into cartridge mode, so that the binary wouldn't crash when being executed as a cartridge instead of a BIOS.
As for changes between the proto and the final release, I didn't look into those. But I suspect they were all releated to seperating the BIOS and the game part only. (adding proper startup code for a game, sepearating the graphics for both parts etc.)
Ciao, Eckhard Stolberg
-
Think you can inject the pp2 into the asteroids bios you think?Yes, you could do that. Infact in the Pole Position II ROM there is even enough room to fit the entire NTSC BIOS in. That BIOS also includes the cartridge test. But since there is no game in the BIOS to start if no cartridge was found, the BIOS just sets the 7800 into 2600 mode. I guess that means that Pole Position II was originally meant to be part of the BIOS.
Ciao, Eckhard Stolberg
-
OK, I tried out the Asteroids BIOS in that 7800 and it comes up fine with no cart. I put the Pole Position 2 BIOS back in and it doesn't work unless I put a cart partially in. It seems like there is something else it's detecting or not detecting that's making it not work correctly.Maybe that's why it was never released.
Mitch
Are you using the same type of EPROM for both BIOSs? The first test is for floating data lines and IIRC there were issues with the first version of 2600 Reindeer Rescue depending on whether the game used a NMOS or a CMOS EPROM. Due to a bug the game was relying on the state of the floating TIA pins on a read instruction, and one of the EPROM types was pulling those pins high. Maybe there is a similar issue with your BIOS EPROMs.
Ciao, Eckhard Stolberg
-
Hi MitchWould be great,if we could get it work on a CC2.
greetings Walter
I doubt it's possible without a major rewrite of code since it's currently designed to run as a 7800 BIOS.
I don't know if it has any PAL code in there either but probably not.
Mitch
Actually skipping the BIOS part and starting the game directly would be pretty easy. But then all you'd get would be a normal NTSC Pole Position II.
Ciao, Eckhard Stolberg
-
Dunno, the count is at only 32, hardly worth even investing hundreds of dollars in it.But the people who voted "yes" would probably buy a copy of Plutos and Sirius, so their vote should probably count twice too.
And maybe you should mention this poll in the Plutos/Sirius thread. Not everyone asking for cart versions of those games being made might know that a 128K + 16K RAM PCB needs to be developed for that to happen.
Ciao, Eckhard Stolberg
-
PS Any chance of a picture?Maybe someone else can figure out what you need to do to trigger the built-in game.
Congrats Walter, it looks like you have the long lost Pole Position 2 BIOS proto.
Why someone stuck it on a cart board is odd, I guess they didn't know what they had.
The code to trigger the build-in game is the same as in the NTSC and in the Asteroids BIOS. (The NTSC BIOS would enable 2600 mode when no cartridge was found.) Pole Position 2 should start when no cartridge is inserted. Maybe it's a problem with your modifications to the console. Does Asteroids start when you install the Asteroids BIOS on the same chip in this 7800 console?
Good work identifying the proto as a BIOS, BTW. Maybe someone put the code on a cartridge because Pole Position 2 wouldn't start from the BIOS for him either.
Since it will be a couple of days before Walter gets his proto back, I'll post some pictures again.
Ciao, Eckhard Stolberg
-
Hey Walter:On quick glance, it looks like the binary is not signed. I don't have the necessary files here at work - if someone else doesn't try signing it I'll do it when I get home and see if it works then.
Bob
The first games that GCC did for the 7800 were created on modified 7800 consoles that had a special BIOS installed. It would allow transmitting data through one of the joystick ports. Walter's Pole Position II proto is switching to the BIOS several times, which is why I'm assuming that it was writtin for one of those GCC developer 7800s. Since Atari's BIOS doesn't have the code that the game expects, it wouldn't work on a normal 7800 even if the binary was signed.
Ciao, Eckhard Stolberg
-
Couldn't find the Ramona BIOS on this site:That's because the Ramona BIOS is just an ugly hack of the DevOS BIOS. I always wanted to change a couple of things before releasing it to the public, but never got around to actually do that. If you or anyone else decides to build a Ramona cart, feel free to contact me privatly, and I'll try to find the latest version of the Ramona BIOS and it's 7800CTRL program for you.
Ciao, Eckhard Stolberg
-
Now that I've read up a little more on the AVox, SpeakJet and FT232R UART, I can explain this in better terms. The framework currently in place takes care of the bit-banging part on the emulation side. Bytes are being generated correctly, as I've visually inspected them, looked them up in the SpeakJet manual, and 'see' that they would make the sounds I hear (from the emulated SpeakJet). And in Linux, Stella can already 'see' the AVox adaptor, so it should just be a matter of sending those bytes to the adaptor, which sends them to the actual AVox.Ironically, Win32 and OSX support may prove more troublesome, since the required libs are closed source and can't be linked directly to Stella (due to the GPL under which Stella is released). I foresee possibly creating a 'stella-atarivox' application that communicates with Stella, but isn't linked to it. Incidentally, this is why I hate closed-source stuff; it just needlessly complicates things. Rant mode off
Isn't the AtariVox USB adaptor basically just a simulated serial port? If so, you could comunicate with the AtariVox through the normal serial functions of the OS without the need for any closed source libraries. That way Stella would also be able to access the AtariVox through the old serial port adaptor. You might not be able to access the SaveKey part of the AtariVox that way, but maybe that should better be simulated by a 32K file anyway, so that it would work for people who don't own an AtariVox too.
Ciao, Eckhard Stolberg
-
I purchased one of the CGE-released Snow White carts a while back. It's always bugged me that the F8 bankswitching wasn't used when these carts were made, so, when the cart is turned on, the title screen graphics are messed up.I asked someone to make me one using the proper bankswitching, which he did, but it's still not right. When I start it up, the title screen looks fine, but the little tune doesn't play and it glitches for a moment and then goes directly to gameplay without pressing the joystick button. I contacted him about the problem, but he doesn't know how to fix it.
So do any of you guys have a Snow White cart that works properly or are do they all have problems? It seems strange because the game works fine through the Cuttle Cart and an emulator, but I can't seem to get an actual cartridge for this game that works right.
Actually the CGE-released Snow White carts must use F8 bankswitching too, or they wouldn't work at all. The reason why the title screen is sometimes messed up is because the game was dumped incorrectly. For some reason the system vectors for both 4K banks were swapped. The system vector tells the VCS were to start with executing the code. Luckiely the incorrect system vector in one of the banks still points to valid code, so the game plays properly, if the game gets started in this bank. This is what the emulators and the Cuttle Cart do. On a real F8 bankswitching cartridge Snow White seems to start in the other bank most of the time though, which is why there are problems.
I don't know why your other cart doesn't work properly, but if you change the bankswitching for a game, problems are to be expected. If you want to make a properly working Snow White cartridge, you need to swap the last six bytes in both 4K banks of the binary and put that on a F8 bankswitching board.
Ciao, Eckhard Stolberg
-
There are plenty of graphic file converters out there that can handle PCX files. A free one that's available for many platforms is XnView.
Ciao, Eckhard Stolberg
-
Though as yet neither the X07 nor 0840 drivers include a feature I think should be added to future builds: when a condition arises which could cause a random bank switch, do a random bank switch. The notable cases occur with the following access sequences:0840: 0 1xxx xPxx xxxx -- Legitimate bank switch 1 1xxx xQxx xxxx -- Could leave either bank P or Q selected X07: 0 1xxx PPPP 1101 -- Legitimate bank switch x xxxx xxxx xxxx (something other than a legitimate bank switch) 1 1xxx QQQQ 1101 -- Could leave PPPP, QQQQ, or any 'mixture' thereof selected X07: 0 1xxx PPPP 1101 -- Legitimate bank switch x xxxx xxxx xxxx (something other than a legitimate bank switch) x xxxx xxxx xxxx (something other than a legitimate bank switch) 1 1xxx QQQQ 1101 -- Could leave PPPP, QQQQ, or any 'mixture' thereof selected
The remedy for the 0840 issue is to run all bank switch instructions either from RAM or from the bottom 2K of the selected bank. For X07, I would advise the same thing except that putting the instruction sequence "NOP $08xD / BRK" at address $1FF8 of a bank is safe (the BRK will generate fetches of $1FFB and $1FFC, but not $1FFD).
Does this affect all consoles or just those 7800's that have the 'Dark Chambers' fix? Also in your blog you mentioned that there is a chance of a random bank switch before the cart is set to a known state by the first bankswitching instruction. How likely is that to happen, and how many cycles could the game run before such a random switch is almost certain to have happened?
You are righ though. For programmers it would be good, if the emulator informs them when they are doing something that they shouldn't do or that might cause compatibility issues on certain consoles. It might even be a good idea to have a seperate TIA handler to emulate the TIA89 consoles (the ones that have problems with Kool Aide Man). But seeing how slow emulator development is these days, I wouldn't expect too many of these features to be included in the emulators anytime soon.
Ciao, Eckhard Stolberg
-
I didn't release it, so either it's a duplicate effort or he hacked into my computer
No idea who wrote it, I just saw who commited it. Maybe it even is yoursI guess nobody told him that I had already written a Stella X07 driver for testing the holiday cart...
Hm... now you're puzzling me. Eckhard is the #1 2600 guru on this planet to me, but even he can't write a X07 driver when you didn't at least provide him with the specs, no? Or were they published somewhere in a public area?
My theory is that he got ahold of Supercat's z26 code, and reverse-engineered it and adapted it to Stella.
But... it may be better this way, as my code probably isn't as good as his
There already was code for Stella and z26?
If you guys keep discussing emulator related things in the holiday cart forum and even improve the emulators there, I guess I should join too. So, how do I join the holiday cart programmers club, and what's the secret handshake? You and Supercat mentioned X07 bankswitching somewhere in the public discussion of the holiday cart, so I asked Supercat for details. And since I was helping Steve with 4A50 support for Stella anyway, I thought I'd add support for X07 too. Most of the work was spend in getting my old Stella programming setup to work again. Writing the actual X07 class was only a couple of minutes of mostly cut & paste. Sending you an email to ask for a copy of your code probably would have taken longer.
Ciao, Eckhard Stolberg
-
If the two halves weren't identical, one bit in one halve was different, then it would probably have been a cart that suffered from bit rot and then dumped, correct? I've seen this before.It could be bit rot. Or it could be a problem with the cart reader. Is the bit always different, even if you read the game several times with the alternative reading method?
First the 4k roms:file 1: Wizard (1980) (Atari, Chris Crawford) (Prototype) (4K) [a].bin file 2: Wizard (1980) (Atari, Chris Crawford) (Prototype) (4K).bin 07FE 00 13 0FFE 00 13
And then the 2k roms:
file 1: Wizard (1980) (Atari, Chris Crawford) (Prototype) [a].bin file 2: Wizard (1980) (Atari, Chris Crawford) (Prototype).bin 07FE 13 00
What's going on here? Is this a dumper putting in zeros instead of reading line 07FE and 0FFE?
The normal version of the 4K ROM is identical to the [a] version of the 2K ROM, and the [a] version of the 4K ROM is identical to the normal version of the 2K ROM. Therefore the two 4K ROMs are unnnessessary. The different byte in the two 2K ROMs is the low byte of the BRK vector. When the VCS executes a BRK instructions it reads the address where it's going to continue execution from the last two bytes in the ROM address space. So it might be possible, that these two binaries were indeed read from two different version of the prototype. Or maybe someone patched the binary to fix it.
Ciao, Eckhard Stolberg
-
1. There are some cart readers that read the de-soldered chip. Would one of those read the hotspots truly?2. If a game is 2k which half of the 4k rom is actually read? What is the address range of it?
3. Why does a hotspot need two bytes? I know a 4 bit hex address takes two bytes, but since the information at the location is disregarded it must be something else.
4. Commavid did some type of extra ram within a 4k chip. I think 2k rom, 2k ram. Would it be using a bankswitching hotspot to go back and forth? Is this the only example of bankswitching below 4k? If so then we only have to worry about these few Commavid roms and everything else that is greater then 4k.
1. That depends on the ROM type. If you have a prototype or a game from a smaller company that used EPROM chips for the game code, then the bankswitching logic is done with extra chips. Therefore unsoldering the EPROM chip will allow you to read out the ROM image entirely without having to deal with hotspots. If you have a maked ROM chip, then the bankswitchinglogic is build into the ROM chip directly, so unsoldering the chip won't help in this case.
2. 2K games have their data accessable at both halves of the 4K cartridge address space of the VCS. Therefore it doesn't matter which half you read out, as they are identical.
3. Hotspots don't need two bytes. In Atari's bankswitching (there are more complicated bankswitching formats by other companies) you need one hotspot for each bank that you want to map into the cartridge address space. But the hotspots are located in this address space too. You need to read the entire cartridge address space in order to read out a certain bank. Therefore the data for the hotspots will be missing in all banks that you read out.
4. CommaVid games don't use bankswitching, as there are no ROM banks to switch. The ROM fits entirely into the cartridge address space of the VCS. Therefore it doesn' t need any bankswitching hotspots. But two CommaVid games have 1K of RAM. If you read out these games as 4K images, you would also read out the RAM. Reading the RAM might get you random results, which means that you might get many different binaries that are functional identical too.
Ciao, Eckhard Stolberg
-
Too bad no one has a CV KidVid to try these out on. (Waiting for someone to prove me wrong...)Unfortunately, you would also need the tapes that (presumably) would have come with the games.
Would a special CV version of the KidVid really be nessessary? The KidVid player is pretty much just a normal tape player that connects it's headphone and microphone connector to the 2600 joystick port with a simple cable. Also the tapes don't have any 2600 specific code on them. The data track has a small code at the start so the game can detect which of the three tapes is currently playing. After that there are only codes to signal when a song has finished, so that the 2600 can pause the tape player through the microphone connector while the next game sequence is played.
I'm not sure if you could use the 2600 KidVid player directly on the CV, because there are some small differences in the pin usage on the joystick port. But I don't think it would take more that a different connector cable to use the 2600 KidVid player with the CV KidVid games. Maybe one of the CV programmers here could have a look at the code of the two prototypes to find out which pins on the joystick port are read and which are used for output. That might give us an idea how the CV KidVid cable would need to be connected.
Ciao, Eckhard Stolberg
-
well, I havent "met" one yetI have more than 380 carts and probably more than half of them are NTSC games
and none of them are B & W
do you know of any specific title that gives B & W ?
It depends on your TV too. For example I have tried a multi-standard TV with NTSC support, and that one will only show strange colours in the top third of the picture, when I play one of the problematical NTSC games on a PAL VCS.
The NTSC games that lose their colours when played on a PAL VCS and TV are the ones that display an odd number of scanlines. You could test that with an emulator. One of those games would be Combat. Also some of the badly hacked games on Atari's PAL 32-in-1 cartridge have this problem. IIRC the 32-in-1 version of Activision's Boxing will go B & W sometimes, while it does display colours in other situations.
Ciao, Eckhard Stolberg
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
2600 Rom Comparisions and Dumps
in Atari 2600
Posted
The differences in the bankswitching hotspots is what you might get when dumping the game with the first and second release of the DevOS 7800. Both versions skip over the hotspot bytes, so the values you'd get in the binary depend on the state of the reading buffer in the PC program. In the second version of 7800CTRL the buffer gets initialized to zero. In the first version however I didn't do that. So if you'd dump a 4K game before you dump a bankswitched game, the bytes at the hotspot addresses might get filled with proper 6502 code.
Ciao, Eckhard Stolberg