Eckhard Stolberg
-
Content Count
953 -
Joined
-
Last visited
Posts posted by Eckhard Stolberg
-
-
I have a Frogger cartridge like this. Mine has a nice label, so I didn't open it to find out what the board looks like. As you can see, the label has the logo of Parker Brothers Germany (it reads "Weltbekannt durch Monopoly" under the normal Parker logo). Therefore I don't think it's a pirate. Maybe Parker couldn't produce enough PAL Frogger cartridges in their own factories to meet demand and had some cartridges manufactured elsewhere. Maybe these cartridges where made by ITT Family games or Homevision. They used similar cartridge shells with the same type of dust protector.
Ciao, Eckhard Stolberg
-
What would happen if a game called for a load out of sequence?Does Stella just blindly call the next sequential load regardless of the value of the load ID or does it interrogate the ROMs to try to find the right load?
This is very important for future games because the Supercharger can theoretically support random access loads. The Cuttle Cart made that practical for the first time by displaying the load ID (otherwise you'd be running blind unless a game manually displayed it before jumping to the BIOS ROM).
I'm not sure. If you can provide such sample ROM(s), I can test it and possibly add support for it before the next release.
I'm pretty sure that Stella already supports random access loads (as does z26). The additional loads for all the games have individual load numbers, so you'll have to check the load number byte in the headers to find out if the requested load is included in the binary anyway. And "Escape from the Mind Master" is skippping loads when you lose all your lives in an early level and then need to go to the evaluation screen in the last load.
But if you want to try out if it really works, you could create a new binary for "Escape of the Mind Master" where all the additional loads are in reversed order. If you could still play through several loads normally, then random access loads are working.
Ciao, Eckhard Stolberg
-
I used to have the wav file I sent to Eckhard and John for Z26 emulation. It would be easy enough to create another and then convert it to bin. I don't have the time right now.
Regards,
-Lee
I think I still have the binary and the commented source code I created from it. I think I even posted the source code to the Stella list a couple of years ago. The problem with the transfer protocol is, that the first thing it does is to overwrite parts of the loading routine with new code that contains information about how many data blocks to read from the demo unit and where to store them in the SC RAM. So in order to read out the data from the demo unit one would have to read out these small code blocks, analyze them and then adapt the transfer program to read the next blocks.
If I, or someone else who can program a 2600/7800 to PC communication, had physical access to a SC demo unit, it would be fairly easy to do that. But if I had to send the code to Lee and then get the resulting data block back and analyze it so that I can create a modified reading program for Lee to read the next couple of blocks, that would be a lengthy and tedious process. IIRC we never even tried it back then, because Lee was having problems with setting up his PC to use with the carrtridge reader.
Ciao, Eckhard Stolberg
-
Yes, generating a table for this would be a lot of work, because the final player shifting distance does not only depend on where in the line you do the HMOVE but also on where in the line the player was positioned before. And if the HMOVE clock pulses happen while the player is displayed, the graphics will be corrupted anyway. And since the mechanics behind this effect are already understood quite well, there is no point in generating a new table.
BTW, did you check when and where your problematical 2600 Jr. console was manufactured?
Ciao, Eckhard Stolberg
-
Hm... but thinking more about this, the bug in Simons demo resulted from a "deep" HMP1 write, at cycle 23. It worked fine on the (chinese?) Jr. but the sprite occasionally "jumped" on the 6er, as if certain HMP1 values were misinterpreted. Is that related somehow or just another phenomenon?It could be related. If the HMOVE occured right after the WSYNC, and the HMP1 value was $70 at that time, then overwriting it with something else at cycle 23 should cause the Cosmic Arc starfield effect for player 1. It would last until the next HMOVE. During that effect there would be a new HMOVE clock pulse every 4 pixels for player 1. On the newer Jr. that would result in lots of extra right shifts for player 1, while there would be only left shifts (or no extra shift, if the next HMOVE was already in the next scanline) on the 6er.
Well, at least you are asking at the right time.
We are currently trying to port z26 to C code, which is why there hasn't been a new version in such a long time. We'll probably have to redesign the TIA line rendering code to fix some other inacuracies anyway. So adding an optional "TIA89" mode might be possible. But all that testing for extra shifts while rendering each player pixel might slow things down a lot, so I'm not sure if the new mode would be worth that tradeoff. It should be really simple to add a special warning in the trace log every time you are going to create HMOVE pulses for the player graphics during the visible part of the scanline though.Ciao, Eckhard Stolberg
-
Thanks - this is going to be a real pain for 2600 development! At least I have one of the problem consoles to test things on. Does this happen with all Jr. consoles, or is is just the PAL ones? I will run your worm whomper demo after work and let you know the results. I also found Brad Motts Tool in the Stella archives and I will see if I can recreate the table for my Jr. I am hoping that there will be significant overlapFrom my experience, only consoles made in China in 1989 or later are affected by the different HMOVE behaviour. Unfortunately this includes all PAL 7800s. Older 2600 Jrs. should work just like the 6- and 4-switch models. At least it is like this with all my PAL consoles.
The difference is in HMOVE pulses that happen during the visible part of the scanline. As you might know, the TIA will generate a left-shift pulse every 4 pixels when you trigger a HMOVE. It will continue to do so until the motion counters for all movable objects have been matched with the HMOVE counter. When you trigger HMOVE at the start of VBLANK, all counters will usually have been matched by the end of VBLANK.
The only exceptions are when you trigger the Cosmic Ark starfield effect or when you trigger HMOVE during the visible part of the screen. The clock lines for the HMOVE pulses are used for different things during the visible part of the scanline, so the shifting pulses will be ignored on a normal VCS. This is why you get different shifting distances when you trigger HMOVE on different cycles. It depends on how many of the HMOVE pulses happen during VBLANK.
On the China-VCS the HMOVE pulses during the visible part of the scanline unfortunately overlap with the display clocks for the player graphics in such a way that those will be canceled out. As a result it will appear that the player graphics get shifted to the right by one pixel for every HMOVE clock. Since HMOVE pulses happen every 4 pixels, they can generate such a shift even in the middle of a player display.
So, if you want to keep your game compatible with both types of consoles, you need to avoid moving player graphics with HMOVEs that happen during the visible part of the scanline. But AFAIK only the players are affected by this. So Manuel's worm demo should work fine, since it only uses missiles and the ball.
Ciao, Eckhard Stolberg
-
The bug is with starting the game by pressing the fire button instead of reset. There is no bug that prevents you from finishing the game.
As I said a couple of years ago in this very thread: you have to make sure that you don't give away anything that you could use elsewhere (like on the troll bridge
) first. Also there are situations where you need to do more than one thing to solve a problem.Ciao, Eckhard Stolberg
-
1
-
-
Stella and z26 both use the SDL library for input and output, which helps with keeping the code easily portable between different systems. And if this library doesn't support any "real time multimedia" functions in it's sound subsystem, then the emulators won't be able to use them without making portability more difficult by adding special sound handlers for each supported platform.
BTW, if you have a fast computer, you can reduce the sound buffer size in z26 with the -s command line option. The default size is 4608. Maybe you can find a smaller number which still works on your computer. This should speed up the reaction time for sound changes.
Ciao, Eckhard Stolberg
-
In order to compile z26 or Stella you need to get a C(++) compiler and the nessessary libraries. For z26 you'd also need an assembler. And of course you need to get the source code of z26 and/or Stella.
The C compiler you can find at www.mingw.org. You'd need to get the latest stable version of MinGW. Also get the latest stable version of MSYS, which is a Unix command shell with the nessessary tools to use the C compiler.
z26 and Stella both need the SDL library. You can get it at www.libsdl.org. You need to get the latest (1.2.
development version for MinGW. I think Stella also needs libPNG and zlib, but I don't know where to download the nessessary files.For z26 you also need NASM for compiling the assembler parts. You can get the Windows version at nasm.sourceforge.net.
If you have installed everything properly, you can recompile the emulator by using "make" in the Unix command line shell while being in the source code directory of either z26 or Stella.
Ciao, Eckhard Stolberg
-
It has nothing to do with the playfield colour. It's just the normal offset for the positions of the objects. A RESP will set the objects position to the pixel at which the write happens. But the TIA needs a couple of cycles from the pixel clock to set up the actual output. Therefore all objects will be delayed by a couple of pixels.
The offset is 4 pixels for missiles and the ball, 5 pixels for single-width players, and 6 pixels for double- and quadrouple-width players. You need to take these offsets into account when calculating the position of an object.
Ciao, Eckhard Stolberg
-
I'm using WPLAYBIN. Though I'm thinking I may have to reexamine some of the header to make sure I didn't bump anything. How does the header in the BIN file compare with the headers of the tape blocks?The header format of both the SC tapes and the emulator binaries are described in Chris Salomon's text that batari linked to in his post above.
Counting address changes. Interesting. Does it look at the entire address (well A0-A12) when making the determination, so the sequence:Foo: LDA $F0xx,x NOP LDA MyAddress
is guaranteed to work for any value of MyAddress other than Foo+6 or Foo+7 [either of which would cause a write to address Foo+8]?
No, that would only work for Foo+6. When you access Foo+7 that already is the 5th different address after initiating the write. Therefore you would overwrite the opcode for the next instruction after LDA MyAddress.
Also worth noting is the fact that accesses to $F0xx during the writing process will not interrupt it. So
LDA $F012 NOP CMP $F034
will write $12 to $F034 without initiating a new write with the value $34.
If they're counting address changes, I wonder why they need the write pulse delay to be programmable? I would have guessed that they needed that to get suitable timing accuracy over a several-cycle period, but accuray within a single cycle shouldn't have been a problem.Acuracy within a single cycle can be a problem, if you don't have access to the clock line on your cart and therefore don't know when addresses are valid. I think Atari even changed the design of the 7800 because of this. On the older models some games with superchip RAM had problems.
That was just the first theory we came up with when we started analysing SC games. Back then we didn't know much about the inner workings of the 6507 opcodes. And since there is a memory access for every cycle, that was easy to confuse. We only noticed we were wrong when we actually tried to add SC support to the emulators.
Ciao, Eckhard Stolberg
-
-1- The program starts fine in emulation. On a real unit, however, it dies about 2/3 of the time on startup. My code turns on an audio beep before it does anything else, and the times that it dies (black screen) it does not beep, suggesting that it's dying before it starts executing my code. Is there a potential issue with the header information and such (which I don't really understand but just copied out of Stella-Sketch)?As batari mentioned, there is the write pulse delay, which might not be set correctly for your Supercharger. But I think the Stell-A-Sketch header leaves it to the SC to find the proper write pulse delay, so this is probably not your problem.
If your game crashes before it executes even a single instruction, I would suspect a loading problem. What are you using to transfer your binary to the SC? I think I have experienced a similar problem, if the footer tone after the binary transfer wasn't long enough.
The SC doesn't count cycles. It counts address changes. The write will go to the fifth different address after the access to $F0xx, but only if this address is in the ROM area and if writing is enabled. Writes to the control byte at $FFF8 will alway happen immediately. There is no address counting or RAM enable for this.
Ciao, Eckhard Stolberg
-
Since you mentioned that you have a 7800 with a socketed BIOS EPROM, I suppose that you haven't done any modifications to it, right? In that case a 2732 shouldn't work. You'd need to switch the jumper next to the EPROM socket, as Mitch suggested. A 27128 should work fine though.
To verify that the EPROM, that you want to use for DevOS, and your EPROM burner work properly, you could download the binary for the PAL 7800 BIOS and burn that on the EPROM. If it doesn't start with Asteroids, you'd know it's a problem with the EPROM. Otherwise it must be a problem with the DevOS image.
BTW, what exactly happens when you start your 7800 with a 27128 with DevOs in it?
Ciao, Eckhard Stolberg
-
Actually one of the chips is just your standard 8K ROM chip with F8 bankswitching build in. The other chip is the DPC, which provides more than just the sound samples. It also contains 2K of ROM which hold the graphics data for all the sprites. So if the hack changes any of that, you are out of luck. But if the hack only has changes in the first 8K of the ROM, you might be able to modify a Pitfall II cartridge
to play the new game.
Ciao, Eckhard Stolberg
-
Officially Bumper Bash is a paddle game. But it only uses the buttons. It does use both buttons at the same time though, which are the same as the left and right signals on the joystick. Therefore it might be easier to emulate Bumper Bash as a joystick game with all combinations of directions allowed. At least for the paddle simulation through the PC keyboard it might be better.
Ciao, Eckhard Stolberg
-
So, have you found any differences from the release versions yet? If so, I'm sure Tempest would love to have a look at the binaries. And if you need my help with reading out the ROMs (and you trust the Deutsche Post enough with sending parcels though Germany
), I'd be glad to help you out. Or, if you have a spare 7800 and a friend who can solder, you can of course build a simple cartridge reader for yourself.Ciao, Eckhard Stolberg
-
Try shooting and pressing both 'Up' and 'Down' at the same time. Sometimes, the Berzerker will lose his gun, and you have to grab it again before you can shoot. Is this an Easter egg, or just a bug in event handling (since under normal conditions, one should never be able to select opposite directions at the same time)?That's a bug in Berzerk. The bullet will move until it collides with something. And the game will remember the last direction before the shot was fired, and move the bullet one pixel in that direction in every frame. So if opposite directions are selected when the shot is fired, the game will move the bullet one pixel up and one pixel down in the same frame, and therefore not generate any movement at all. Only when the player or a robot runs into the bullet the game will sense a collition and reset the gun to be fired again. The same thing happens when you press left and right at the same time too.
Other games where pressing opposite directions can cause strange effects are Combat, where you can speed up your tank that way, and Boing, where you can accidently hop outside of the playing field.
So it would be good to prevent these conditions in the emulator. But you might want to allow them as an option for certain games. I think Bumper Bash needs left and right at the same time, so that you can use both paddles.
Ciao, Eckhard Stolberg
-
I'm currently trying to convert the other Activision FE game (Decathlon) which is turning out to be a real pain. It does work but has timing problems since they bankswitch several times in the middle of the display kernel
Hopefully I can fix this.Didn't Activision do this conversion themselves? At least the PAL re-release by HES uses F6 bankswitching. If there isn't a NTSC version already, it might be easier to take the HES version and convert it to NTSC colours and resolution.
Ciao, Eckhard Stolberg
-
OK, I have a new theory:
Could you change your graphics in such a way that the two pixels in 320 mode, that make up one pixel in 160 mode, don't both have colour 1? I think the problem might be that mode 320B uses the same write mode as mode 160B.
In mode 160B the low nibble of the graphics data bytes selects the palettes for the pixels, while the high nibble selects the individual colours in those palettes. So if bits D7 and D6 are both zero, the left pixel will be transparent. And if bits D5 and D4 are both zero, the right pixel will be transparent.
In your demo the graphic bytes, that contain the colour 1 pixels, have bits D7, D6, D5 and D4 all be zero. So if mode 320B uses the same write mode as mode 160B, it might be possible that your colour 1 pixels all are transparent, because they would be, if you used the same graphics data in mode 160B.
Could that be possible?
Ciao, Eckhard Stolberg
-
It would be nice if the emulators had a feature where they could take composite screenshots like that automatically...z26 can do that, if you use the phosphor effect and BMP screenshots. Also the emulator has to run in a high colour video mode. High colour video modes are -v10 to -v18 for windowed mode and -v20 to -v28 for fullscreen. These modes will use the colour resolution of your desktop. To set the phosphor effect to a maximum you need to use the -f99 command line switch. This will combine the two last frames into one. Also you need to use -B to enable BMP screenshots, because PCX screenshots can't handle the colour resolution nessessary for the phosphor effect. So a command line like
z26 -v20 -f99 -B gamename.bin
should allow you to generate nice screenshots of games flickering with 30Hz.
Ciao, Eckhard Stolberg
-
Actually, depending on which bank is currently mapped in and which bank the current state of the databus would select, a STA WSYNC would trigger a bankswitch on a 3F cart. That's why the Tigervision games access the TIA through addresses $0040 to $007C.
Ciao, Eckhard Stolberg
-
Yes, all colours should be visible in this example. This can't be the problem then. Did you already try different colours, just to make sure that your red isn't simply too dark on your TV?
Also it might be good, if you could post your source code. That would make it easier to look for other potential proplems. Looking at the binary, it seems that you have your DLL set to select palette 1. The manual says that in mode 320B only the most significant palette bit is read, and that you therefore can only choose between palette 0 and palette 4. Maybe setting a different palette can cause problems on a real 7800. Maybe that's why colour 1 doesn't get displayed?
Ciao, Eckhard Stolberg
-
I would dump my Robot Tank too but 7800Ctrl doesn't support that bank-switching...I was experimenting with Activision's FE bankswitching, but couldn't get the autodetection to work on the 7800. So I never put support for it into the release version of the DevKit. If you want, you could email me, and I could see, if I can still find a version of 7800CTRL with FE bankswitching as a command line override.
Ciao, Eckhard Stolberg
-
As Kevin Horton's bankswitching guide says, 3F games react to accesses to all addresses between $0000 and $003F. But the switch will only happen when this access is followed by an access to an address between $1000 and $1FFF. Did your hardware handle that as well?
I don't know if the games themselves are accessing the bankswitching addresses in a way that the next address on the bus in not $1000 or above. But maybe the VCS is accidently putting an address between $0000 and $003F on the bus for a short time. Maybe that's why Tigervision added the check for the $1xxx addresses?
As for extended 3F bankswitching, there are demos that have the 4th bank as the fixed bank and there are demos that have the last bank in the ROM as the fixed bank. If you are only able to add one version to your cart, you should use the last bank. That seems to be what a real cartridge would use, if anyone ever decides to write a full game for extended 3F bankswitching. The method with the 4th bank as the fixed bank was only used for some early demos, because the Cuttle Cart 1 supports it for up to 64K.
Ciao, Eckhard Stolberg
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Supercharger Basics
in Atari 2600 Programming
Posted
I think the problem is that you ORG bank 3 (which contains the actual code) to $2000. This isn't in the VCS cartridge space where the SC RAM is located. Therefore the game should crash immediately, because the startup address in the header points to $2000 too.
If you are using different SEGs for the different banks, you need to use ORG to place them in the binary and RORG to set the origin for the actual code/data in the banks.
Ciao, Eckhard Stolberg