Eckhard Stolberg

I don't know if Suntek or Rainbow Vision ever released a version of Farmyard Fun, but I'm pretty sure it was originally created by/for ITT Family Games. In the early 1980s there was a German TV series for children called 'Pumuckl'. The main character in Farmyard Fun looks exactly like Pumuckl, and the game even plays the title melody from the TV series. I don't think the Pumuckl series got distributed much outside of Germany, and ITT Family Games seems to have had a license to produce games based on it. The player sprite in Zoo Fun also looks like Pumuckl. This game uses the same display kernel as Panda Chase by Homevision. Zoo Fun is not a hack of Panda Chase though. It seems to be done by the same programmer who used the same display code for both games. Therefore I think that both, Zoo Fun and Farmyard Fun, were written by Homevision to be included in ITT's Pumuckl game series. Ciao, Eckhard Stolberg

But you still have the problem that there are not enough address cycles between the two CMPs because the access to the 'write trigger address' is still the last cycle in the first CMP. Therefore the write would go the address of the opcode byte of the instruction after the second CMP. You either have to put a NOP between the two CMPs, or you have to use $10FF,Y on the first CMP and make sure that Y is never zero. Ciao, Eckhard Stolberg

Yes, you are right. The last thing the BIOS does is to place the control byte value in the write buffer and then jump to some code in RIOT RAM that accesses $1FF8 and then jumps to the game's start address from the header. So accessing $1FF8 indeed is harmless if your game hasn't accessed $1000-$10FF at all before. But like $1FF9 you probably wouldn't get the proper byte back from a read of $1FF8. Ciao, Eckhard Stolberg

No, Eric is right. These examples would only work if DESTINATION_ADDRESS was $1FF8, because writes to the SC config address will always happen immediately. And that's the only way writing is done this way in the Commie Mutants code too. There are several cases of the following code though: RAM = $F000 VALUE_TO_STORE = $80 DESTINATION_ADDRESS = $F100 (whatever) ;value comes from Y LDY #VALUE_TO_STORE CMP RAM+$FF,Y; preps the value for the write CMP DESTINATION_ADDRESS; does the write In this case you would write $7F to $F100. The reason for that is that the first CMP will need an extra cycle because it is crossing a page boundary for any Y-value other than $00. In this case the 6507 will first access $F07F (this will trigger the writing) and fix the high byte of the destination address. Then it will access $F17F. This is the extra address cycle that is needed for the access to DESTINATION_ADDRESS to be the 5th address cycle after the access to the writing trigger address. Ciao, Eckhard Stolberg

Accesses to $1FF8 will always change the state of the SC to whatever value was in the write buffer last. If $1000-$10FF wouldn't get accessed at all, that would be the initial value of the write buffer. But since the SC BIOS needs to access the 'load trigger' addresses during the loading process of the game, the value in the write buffer at the start of your game will depend on which byte was read from tape last. You are correct about $1FF9 though. That byte only returns the audio input in bit 7. Accessing it doesn't change anything in the SC config. I don't think there are any technical reasons for Starpath's choice of trigger addresses. They probably just were carefull when chosing only addresses in the cart's address space, since they had to reverse engineer the inner workings of the VCS and didn't know exactly what all those unused addresses in the lower half of the VCS's address space were doing. Ciao, Eckhard Stolberg

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

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

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. 913073[/snapback] 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 905016[/snapback] 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

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

From 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

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

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. 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. 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

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

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

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