Eckhard Stolberg

Yes, that code waits for the timer that I set up for the VBLANK period to expire and then sets up a new timer for the 199 scanlines of the lightgun position check. You also need the code after the CEndFrame label, because it waits for this timer to expire and discharges the capacitors for the lightgun sensor, which is needed, so that you can do another test later.

The lightgun test routine exits once it has detected the lightgun position. If you are pointing the gun at the top of the screen, that might be after 50 scanlines or something. This is not enough for a full frame and therefore the screen starts to roll. To compensate for that my program sets a timer before executing the lightgun test routine and waits for that timer to expire afterwards. After having a quick look at your code, it seems that you moved the timer handling code and forgot to set the timer to a proper value before calling the lightgun test subroutine.

No need to apologize as this part of the code was borrowed from Sentinel. Of course you could do it differently. But in oder to get a reasonably high horizontal resolution you need to be able to check the lightgun sensor as often as possible during a scanline. And if you try to avoid all unnecessary loops and checks to be able to fit in more reads of the lightsensor, the code can get a little messy. Also you might have noticed that the AdjustHpos subroutine only is 75 cycles long. That way the reads in the scanlines following the first hit detection always happen one processor cycle before the check in the last scanline. Since the lightgun sensor would register a hit for several scanlines, you can increase the resolution of the check to single cycle precision, which is the best you can achieve on the VCS. And since you have to make sure that the reads of the lightgun sensor always happen after the same number of cycles after the last read no matter which of the branches was takes, the code gets a little more messy.

The 2600 can display 160 pixels in about 200 scanlines, but unfortunately you can't poll the light sensor that often. Also the Atari lightgun isn't that acurate to begin with. So a lightgun resolution of 53 x 40 seems realistic. A couple of years ago I took the lightgun routine from Sentinel, changed the values a bit to work better on my TV and made a lightgun test program out of it. It displays a grid with a resolution of 53 x 38 squares. If you pull the trigger of the lightgun in the left controller port, a hit marker should appear in one of the squares. I adjusted to position values so that, if you press the gun directly against the screen of your CRT and position it over one of the squares, the hit marker should appear in that square when you pull the trigger. It works fine on my multi-standard TV. If the marker is off on your TV, you need to adjust the position values accordingly. guntest.zip

It's not quite true. The Arcadia 2001 and the VC4000 both use chipsets from Signetics that were also used in different consoles from different manufactures. Therefore there are compatible consoles to both systems. But the Arcadia 2001 and the VC4000 aren't compatible with each other, because the Arcadia uses a newer generation of Signetics chips than the VC4000.

That happens when your console (PAL or NTSC) has a TIA chip that was made in China after 1989. Unfortunately this includes all PAL 7800s. As you know, the starfield effect works by tricking the TIA chip to keep sending extra clock pulses to the position counter for one of the movable objects every four pixels during the invisible part of the scanline. The thing is that these extra clock pulses also happen during the visible part of the scanline. But here they usually overlap perfectly with the normal clock pulses that advance the position counters once every pixel, and therefore don't have any effect. On the TIA chips from 1989 the timing for the extra clock pulses is slightly off. Therefore they connect two of the normal clock pulses effectively canceling out one of them. Therefore you are seeing a shift to the right instead of the expected shift to the left, because the position counter doesn't get the normal 160 clock pulses it's supposed to get. If you play Kool Aide Man on these consoles, the player sprite will keep bouncing back and forth the the upper left corner, making the game unplayable. This is because the player objects in the score display overlap which constantly triggers the collision detection. The way Kool Aide Man positions the player objects for the score also accidentally triggers the extra clock pulses.

Yes, if the chip gets that hot, you probably have a short somewhere. If you can't find it by checking your connections again, it might be a good idea to solder a low-profile chip socket to the board and plug the RAM chip in there. That way you don't have to go as artistic with your soldering as you do now. My POKEY board has a chip socket, and I can easily fit in a RAM chip similar to yours, if I bend up the fat part of all the pins and then bend down the thin ends in the right distance to match the holes of the socket.

The capacitor is the same as the other two near the RAM and the POKEY. It's a "104" or 0.1 uF.

I had a quick look at my Ballblazer RAM board, and I noticed, that it has a capacitor bridging the middle and the right hole of C2. This seems to be missing from you board. It's been a long time, but IIRC Graham told me to add it, because I had problems getting my POKEY RAM cart to work at first too. Maybe that's you problem as well.

It's the Ballblazer board which can be configured by jumpers to use ROM, EPROM or EEPROM chips and is therefore quite easy to modify into a RAM cart. Graham Percy posted the plans for this on his Geocities site which unfortunately is down now. But there is a mirror here. The the OP: It's difficult to diagnose the problem with your cart with so little information. Maybe you could post pictures of your board, so we could check the wiring? And what command do you use to upload a program to the RAM cart, and what kind of error do you get?

I used my 7800 dumper and it worked fine on the first try. The Marine Wars cartridge was a tight fit though. I had to push it a bit harder to make it go in all the way and make good contact. Also I had taken the board of my 7800 out of it's case, because I had to fix something on it. That might have helped with fitting the cartridge into the slot as well.

If you can't find anyone locally, you could send the cartridge to me and I'd try it in my ROM dumper.

Which adresses does the XM use for it's control registers? The CC2 uses quite a lot of the non-cartridge space for it's registers. I'm not sure which of them are active on power-up, but there might be some potential conflicts. According to Chad Schell's CC2 tech docs it uses some addresses between $500-$57f for the POKEY and memory control, some addresses between $600-6ff for accessing the PSD and FPGA and the area between $800-$fff to store the CC2 settings in battery backed RAM. Also during the menu display the font data is mapped into $3800-$3fff. At least the last one would overlap with the HSC ROM, if it was enabled by the XM.

While Andrew's site unfortunately is down, DASM is still available on SourceForge.

Yes, that's how my carts look too..

Here's another one to remove from your list. Both of mine use blue clamshells that contain a standard HES cartridge with a monochrome CBS style label.

I'm only guessing here, but I suppose the code you posted is trying to sync the 6502 with the TIA and PIA. When switching to 2600 mode you are reducing the CPU clock speed from 1.79 MHz to 1.19 MHz. In 2600 Mode there is one CPU cycle for every three TIA cycles. I don't know how the TIA and PIA are clocked in 7800 mode, but it might be possible that they get out of sync with the 6502. The code you posted is switching back to 7800 mode twice to speed up the clock, so maybe it's trying to make sure that the CPU cycles happen at the same TIA/PIA cycle as it would on a real VCS.

Hello Stephen, I know exactly how you feel, because I've been there with z26 about seven years ago. The problem really is that love (and that includes the love for a hobby) only lasts five to seven years depending on how you are counting. For about two years you are getting the hormones to make everything feel new and exciting. Then for about three years everything feels nice and harmonic. And then the hormones stop and the love is over. But since the brain likes habits, it takes about another two years before you really can let go. During that time your subconscience is making up more and more reasons why things aren't as nice as they used to be. Judging from your post, that seems to be where you are now. You have just gone through you second period of love for Stella and now your subconscience is making up reasons why you want to quit. That's why you are focusing so much on the few negative comments that you get and why the release of z26 bothers you so much. You'll have to find other aspects of Stella development that make it feel new and exciting for you again. You have to WANT to work on these things no matter what others think about it. I hope that removing the inefficient old code and putting Stella on a new and improved base does that for you, because otherwise I fear that you will be abandoning Stella development soon, like we did with z26 seven years ago. And for z26: There really isn't that much new development. Most of the "new" code is something that we already wrote seven years ago but never released. It's still full of bugs and needs quite a lot of work before it's even at the level of the old assembler core let alone at the same level as Stella. I'm not sure if we are going to put that much work into it. I'm not even sure we are going to put any significant amount of work into z26 anymore. So we are definitely not going to compete with you. Then why did we release a new version? Well, one of the goals we had for porting z26 to C seven years ago was to be able to create a Mac version. I suppose when John decided to buy a Mac, he wanted to see if the code we already had was able to be used for that. And releasing a new version is just John's way of doing a backup.

I think both tapes would work on NTSC and PAL alike. If you look at the PictureMate tape inlay, it tells you to switch the CompuMate into graphics mode before loading something from the tape. Therefore you would only load a couple of pictures (of animals ?) into the graphics editor. And since the picture resolution is the same in the NTSC and PAL CompuMate, I don't think the TV format matters for this tape. I suppose it's the same for the SongMate tape, except that you load a couple of songs into the CompuMate's music editor.

It's been a long time since I looked into that for z26 and Stella, but IIRC it were mostly the multiload games and the playable demos that caused problems. Here is the player positioning code we use in z26: lda #$10 sta HMP1 sta WSYNC ldx #$07 dex Pos: dex bne Pos lda #$00 sta HMP0 sta RESP0 sta RESP1 sta WSYNC sta HMOVE We added it because of the problem in the Escape from the Mindmaster game over screen. I don't think any game relies on specific positions for the ball or the missiles. The x-register and the stack pointer are $ff, the y-register is $00 and IIRC the accu contains a fast running counter that gets used to seed a random number generator by some games. The TIA registers get cleared as does the RAM from $81 to $9d. RAM from $fa-$ff contains CMP $fff8 / jmp Start_of_new_load The last page of the first bank of SC-RAM is used by the starfield effect. So if a game doesn't reload it, it should contain random data. None of the existing games have problems with this, though. I think that's all we do in the emulator, and AFAIK all Starpath games work fine.

Your binary probably is fine. Some of the Starpath games rely on the fact that the SC BIOS sets the TIA into a certain state during the loading screen. In the case of the Escape from the Mindmaster game over screen it's the position of the player graphics. If the Harmony cartidge doesn't simulate the SC BIOS, you'll run into problems like the one you describe.

The game uses DPC (Pitfall 2) bank-switching. I'm not sure why Z26 doesn't like it (I haven't looked at the trace yet). The final 2K is unused, but it is required in the ROM image for Stella to detect it as a DPC ROM. Chris z26 doesn't autodetect the binaries as DPC games because they are 255 bytes too short. The Pitfall 2 binary has 8K of code 2K of graphics data and 255 bytes which contain the sequence of the pseudo random number generator. IIRC the emulator does use thie RNG data anymore, but the binaries must still be 10495 bytes large to be autodetected properly.

I think the first magazine to review the PAL 7800 in Germany was Joystick 6/89. And all of the PAL 7800s that I opened had a manufacturing date of 1989 or later. Also Peter Pachla once told me that he didn't have a PAL console when he ported Jinks to the 7800 in England in 1988/89. So a release date somewhere around mid to late 1989 seems plausible to me.

Yes, when we fixed the prototypes to work on ROM, I made them PAL/NTSC aware. Both games will show a stable centered picture on PAL, but the colours will be a bit off and they will play a little slower than on NTSC.

Versuch's doch mal bei www.kultpower.de. Selber hochladen geht da glaube ich zwar auch nicht, aber da die ein Heftarchiv haben und nach Hilfe suchen wird sich da vielleicht eher ein Weg finden um die Telematch Hefte online zu bekommen. Allerdings müsstest du dann wohl noch etwas Arbeit in die Aufbereitung der Hefte stecken, damit die in deren System passen.