Problems with ET Book Cart

[simbalion]

I just received my ET Book Cart today and thought I would check it out on my heavy-sixer 2600. The game part works fine, but the book part soon becomes unstable and either becomes garbled or starts flipping. Also the flicker seems really bad. I initially thought it might be my heavy-sixer, so I also tried it out on my light-sixer. I got a bit less flicker, but the same problems with the screen destabilizing. Anyone have an idea what might be going on?

[Albert]

The flicker is normal, and that's how the cart displays so much text onscreen at once. Looks fine (and is readable) on my 1702, but it's not something I'd want to spend hours reading. As for the cart becoming unstable, that's unusual. One thing I did notice when I was testing is if I had a paddle controller plugged into the right controller port, the cartridge would not function properly. I didn't check to see what would happen if other controllers (joystick, driving, keyboard) were plugged into the right controller port, but it's something you could try.

 

..Al

[simbalion]

Hmm, I just had both regular controllers plugged in. It is readable until it starts either flipping or getting garbled. Wonder if it is my machines?

[SeaGtGruff]

Hmm, I just had both regular controllers plugged in. It is readable until it starts either flipping or getting garbled. Wonder if it is my machines?

Is it after you've played the game and are returning to the book cart, or while you're reading the book cart without having played the game?

 

Michael

[simbalion]

It's while I am reading the book cart.

[SeaGtGruff]

It's while I am reading the book cart.

Hmm, the only time the screen should "roll" at all is when you press RESET to return to the title screen, and it should roll for only 1 frame, then display a steady 262 lines after that. I checked the scan line counts with z26, and the only time I saw anything odd was after I'd been playing the game, then returned to the title screen-- the scan line count was wrong. So I fixed a problem with setting the timer, and after that I couldn't make the bug recur. But you say that it's when you haven't played the game in that session, it's when you're just reading the book cart? Is there any other information you can tell me, like what kind of TV/monitor you're viewing it on, does it seem to only happen under a certain kind of situation (e.g., when just beginning a selected chapter, or when returning to the table of contents after reading a chapter, etc.)?

 

Michael

 

PS -- And what do you mean by "garbled"? What does the screen look like, in what way is it "garbled"?

Edited January 9, 2007 by SeaGtGruff

[simbalion]

It's while I am reading the book cart.

Hmm, the only time the screen should "roll" at all is when you press RESET to return to the title screen, and it should roll for only 1 frame, then display a steady 262 lines after that. I checked the scan line counts with z26, and the only time I saw anything odd was after I'd been playing the game, then returned to the title screen-- the scan line count was wrong. So I fixed a problem with setting the timer, and after that I couldn't make the bug recur. But you say that it's when you haven't played the game in that session, it's when you're just reading the book cart? Is there any other information you can tell me, like what kind of TV/monitor you're viewing it on, does it seem to only happen under a certain kind of situation (e.g., when just beginning a selected chapter, or when returning to the table of contents after reading a chapter, etc.)?

 

Michael

 

PS -- And what do you mean by "garbled"? What does the screen look like, in what way is it "garbled"?

 

It tends to start rolling while I am reading. I was about halfway through a page at one time and it started to do that. I turned off the unit then turned it back on a few seconds later. Title screen looked fine, but as soon as the contents came up it started rolling again. The garbling I was talking about is the letters getting mixed up right before it started to roll. The TV I am using is a 13 inch Apex television set.

[Thomas Jentzsch]

The garbling I was talking about is the letters getting mixed up right before it started to roll.

Definitely not the TV. Either the cart is bad or your console (powersupply?).

[Cybergoth]

Either the cart is bad or your console (powersupply?).

 

Because it's 32K? Maybe it makes sense trying wether another 32K title like Fatal Run or Marble Craze is running?

And is a (preferably PAL) binary for this available? I could try it on my CC then.

[SeaGtGruff]

The garbling I was talking about is the letters getting mixed up right before it started to roll.

Definitely not the TV. Either the cart is bad or your console (powersupply?).

Based on simbalion's descriptions, I'm inclined to suspect a problem related to the bankswitching, but I'm not sure what that could be caused by-- ROM, RAM, or the bankswitching chip itself?

 

Michael

[+stephena]

Is there a ROM available for this cart; I'd like to add a properties entry to Stella for it. If no ROM is publicly available, could someone who does have it create a properties entry? Just start the game in Stella, edit whatever properties you want, and press 'Control s'. This will create a file called 'romname.pro'. I'd like to get this taken care of for the next release of Stella.

[SeaGtGruff]

Is there a ROM available for this cart; I'd like to add a properties entry to Stella for it. If no ROM is publicly available, could someone who does have it create a properties entry? Just start the game in Stella, edit whatever properties you want, and press 'Control s'. This will create a file called 'romname.pro'. I'd like to get this taken care of for the next release of Stella.

I promised Charles I wouldn't release the ROM files, otherwise I would certainly post them. I already have the properties entries created, so I can send them to you. There were three different release versions in all: the NTSC version, the PAL/60 version, and the PAL/50 version. There's also a "special edition" or "prototype" version that has slightly different text, no "Transmission," and no "Alamogorgo Landfill" game, which is designed to work with all three types of Atari 2600 consoles (NTSC, PAL, and SECAM). I abandoned the "one cart fits all consoles" approach when I incorporated the "Alamogordo Landfill" game into the cart. It's difficult to create a properties entry for the prototype version, because you can specify the cart type (F4 Atari 32K bankswitching), as well as the phosphor effect, but the display type (NTSC, PAL, and PAL/60) can change while the ROM is running-- plus, SECAM displays aren't supported by Stella (not yet, anyway, and perhaps not ever).

 

By the way, the 2.3 release (take two) was still having problems with the screen settings-- the YStart and Height. The 2.1 release handles them perfectly-- I can set YStart to 15, and the Height to 240 (for NTSC and PAL/60, and other values for PAL/50), and the ROMs will start up as desired. But if I try to set and save those properties in 2.2 and 2.3, they keep reverting back to the defaults (34 and 210). So if you want the properties settings to be included in the 2.4 (or 2.3.x) release of Stella, then you'll want to get YStart and Height working again.

 

Michael

[Albert]

It tends to start rolling while I am reading. I was about halfway through a page at one time and it started to do that. I turned off the unit then turned it back on a few seconds later. Title screen looked fine, but as soon as the contents came up it started rolling again. The garbling I was talking about is the letters getting mixed up right before it started to roll. The TV I am using is a 13 inch Apex television set.

I have personally not seen this behavior on the 4-switch 2600 I have been using for testing. It's possible there's a problem with your cart and I'd be glad to send you another one to see if a replacement works properly on your system. Please send me a PM if you'd like to go that route.

 

..Al

[+batari]

I'd suggest looking in the source code for a zero page load when immediate mode was intended. This has been the source of some really weird bugs lately.

[+stephena]

Is there a ROM available for this cart; I'd like to add a properties entry to Stella for it. If no ROM is publicly available, could someone who does have it create a properties entry? Just start the game in Stella, edit whatever properties you want, and press 'Control s'. This will create a file called 'romname.pro'. I'd like to get this taken care of for the next release of Stella.

It's difficult to create a properties entry for the prototype version, because you can specify the cart type (F4 Atari 32K bankswitching)

Just a note that the beta version (and next release) of Stella should autodetect the cart type.

By the way, the 2.3 release (take two) was still having problems with the screen settings-- the YStart and Height. The 2.1 release handles them perfectly-- I can set YStart to 15, and the Height to 240 (for NTSC and PAL/60, and other values for PAL/50), and the ROMs will start up as desired. But if I try to set and save those properties in 2.2 and 2.3, they keep reverting back to the defaults (34 and 210). So if you want the properties settings to be included in the 2.4 (or 2.3.x) release of Stella, then you'll want to get YStart and Height working again.

 

Michael

This should also be fixed in the beta version, which I believe you said you would test in another thread. Changing XStart/YStart/Width/Height now works, and will correctly load and save to the properties file. Another new feature is that the ROM won't be reset each time these values change, so you can enter a game and dynamically change the values, and see the screen actually resize itself on the fly (see the manual for which keys do this). If you change the values dynamically, make sure to either save the properties to a separate file (Ctrl-s) or into your personal stella.pro file (open the Game Properties dialog and click 'OK').

 

Also, in the process of testing and creating the properties entry for these ROMs, try to specify as little as possible and see if it works. Doing that will tell me if the autodetection is working correctly. You should only need to set 'Display.Format' to PAL60, and of course change the YStart/Height as required. It should autodetect the NTSC/PAL and F4 itself.

Edited January 11, 2007 by stephena

[Dusk2600]

my guess is mabye it is just a bad cart?

[SeaGtGruff]

I just got my "E.T. Book Cart" today. It definitely has a problem on my heavy sixer-- the title is fine, and the game is fine, but the screen starts rolling when I go to the table of contents or chapters.

 

I don't think it's the cartridge, because it works correctly on my 7800. And Albert said the carts work on his four-switch.

 

My best guess is that it's the program after all. I'm using BNE when I check the interval timer, which works great on the emulators and on my 7800. Are there any known quirks or issues with checking the interval timer on heavy and light sixers? Did anyone else with a six-switch buy it, and if so, does the screen roll?

 

After I get to the bottom of this and fix it, I'll buy replacement cartridges for anyone who's having a problem with it.

 

Michael

[supercat]

I'd suggest looking in the source code for a zero page load when immediate mode was intended. This has been the source of some really weird bugs lately.

 

I wonder if it might be useful to build a couple of 'special' socketed carts, one with 4.7K pullups on all the data wires and one with 4.7K pulldowns. It's doubtful any program with the 'immediate load' mistake would work with both.

 

As an alternative to using the pullups it may be possible to test the cart on a 7800; at least on mine there seem to be pullups on all the data wires.

[simbalion]

I just got my "E.T. Book Cart" today. It definitely has a problem on my heavy sixer-- the title is fine, and the game is fine, but the screen starts rolling when I go to the table of contents or chapters.

 

I don't think it's the cartridge, because it works correctly on my 7800. And Albert said the carts work on his four-switch.

 

My best guess is that it's the program after all. I'm using BNE when I check the interval timer, which works great on the emulators and on my 7800. Are there any known quirks or issues with checking the interval timer on heavy and light sixers? Did anyone else with a six-switch buy it, and if so, does the screen roll?

 

After I get to the bottom of this and fix it, I'll buy replacement cartridges for anyone who's having a problem with it.

 

Michael

 

Mine rolls on my light sixer as well. I'll have to try it on my 7800. Was there a difference between the 6 switch and 4 switch machines?

[SeaGtGruff]

Snap, it does look like a zero-page load instead of an immediate load! (Thank you, batari!) But I wonder why it's working on my 7800, on Albert's four switch, and on the emulators?

 

Michael

[supercat]

Snap, it does look like a zero-page load instead of an immediate load! (Thank you, batari!) But I wonder why it's working on my 7800, on Albert's four switch, and on the emulators?

 

In a classic microprocessor system (things like Pentiums and such get more complicated) the processor communicates with memory and I/O devices using a group of wires called the address bus, another group called the data bus, and a few individual wires which may be called control signals. In the case of the 6502, the primary control signals are called phi2 and R/W.

 

To read an address, the 6502 drives the address bus with the address it wants to read (e.g. if it wants to read address 1 0010 0011 0100, it will pull address lines 0, 1, 3, 6, 7, 8, 10, and 11 low (i.e. to ground), and address bits 2, 4, 5, 9, and 12 high (i.e. to a positive voltage--ideally +5, but in practice often more like +3.5) It also drives the R/W line high then some time later drives phi2 high.

 

The address bus and control signals are fed through some logic to determine which device should respond to that address. There should ideally be exactly one device responding to the requested address; it should drive the data bus with the requested data.

 

Some time after the 6502 drives the phi2 line low, it will latch the contents of the data bus wires and operate upon the data received. It will then drive phi2 low and begin the next cycle.

 

To write an address, the 6502 drives the address bus as before but it drives the R/W line low instead of high. Later, when the 6502 drives phi2 high, it will also drive the data bus with the data that it wants to write. This data will remain on the bus until very shortly after the processor drives phi2 low. Any device that wants to use the written data should latch it off the data bus when the phi2 signal goes low.

 

On the 2600, game cartridges don't have any connection to the phi2 and R/W signals, but this normally isn't a problem. The processor won't normally output any address in the range $1000-$1FFF except when reading from a game cartridge, and neither it nor anything else in the 2600 will mind if the ROM in a game cartridge starts driving its data on the bus as soon as the processor gives it the address (which is some time before the processor drives phi2).

 

The TIA chip in the 2600 will assume that the 6502 is talking to it if A12 and A7 are low. The RIOT chip will assume the 6502 is talking to it if A12 is low and A7 are high. Both devices are connected to all 8 bits of the data bus, but there's a little wrinkle when reading the TIA.

 

For a device to put data onto the data bus requires some moderately-beefy transistors. In designing the TIA, Atari only included output transistors for two of the data bus pins, D6 and D7. Consequently, when a read cycle is performed on the TIA, it's the only device that does anything with the data bus, and it only drives two of the bits. So what happens with the others? Nothing, at least not deliberately.

 

If a signal isn't driven high and it isn't driven low, what will happen to it is anyone's guess. It's possible to design a system so undriven signals will be weakly pulled high, or weakly pulled low, or weakly held in whatever state the seem to be in, but the 2600 doesn't do that. One might think of the state of an undriven wire as being like a feather sitting on the ground. If nothing disturbs it, it will remain wherever it happens to be. On the other hand, there's no particular assurance that nothing's going to disturb it.

 

In practice, undriven bits on the 2600 usually seem to keep the last state they were driven with. Many things can affect this, though, and good design must not rely upon such behavior. Otherwise, if using EPROMs, one may end up with things like games that work in with some brands of EPROM but not others, or even games that work the dark but not when the lights are on (light falling on an EPROM may slightly nudge undriven signals). Even if a game that relies upon such behavior seems to work today, there's no guarantee that it will work tomorrow.

[SeaGtGruff]

there's a little wrinkle when reading the TIA.

 

For a device to put data onto the data bus requires some moderately-beefy transistors. In designing the TIA, Atari only included output transistors for two of the data bus pins, D6 and D7. Consequently, when a read cycle is performed on the TIA, it's the only device that does anything with the data bus,

Your discussion is way over my head, but from the part I quoted above, it seems that trying to read the TIA can have unpredictable results. And that's exactly what I was (unintentially) doing:

 

bottom_active_length	   = 10
;
; ...
;
  LDA bottom_active_length
  STA TIM64T
;
; should have been LDA #bottom_active_length

So I was loading the contents of CTRLPF, or address $0A (that is, were it possible to read the TIA), and setting the timer to that value. I guess that when it works, it's because the value of the address is being used, instead of the value at the address?

 

Michael

[+batari]

I'd suggest looking in the source code for a zero page load when immediate mode was intended. This has been the source of some really weird bugs lately.

 

I wonder if it might be useful to build a couple of 'special' socketed carts, one with 4.7K pullups on all the data wires and one with 4.7K pulldowns. It's doubtful any program with the 'immediate load' mistake would work with both.

 

As an alternative to using the pullups it may be possible to test the cart on a 7800; at least on mine there seem to be pullups on all the data wires.

A hardware debug tool would be good, but what you suggest could also be emulated. I remember Eckhard built a special version of z26 that "drove" the floating bits to help track down those bugs. I don't recall if he actually released it though.

[supercat]

So I was loading the contents of CTRLPF, or address $0A (that is, were it possible to read the TIA), and setting the timer to that value. I guess that when it works, it's because the value of the address is being used, instead of the value at the address?

 

The basic sequence of events, if the code is at address $1234, would be as follows:

-First cycle-
Processor outputs $1234 on address bus, with R/W high.
Cartridge puts $A5 (1010 0101) on data bus.
Processor latches $A5 from data bus

-Second cycle-
Processor outputs $1235 on address bus, with R/W high.
Cartridge puts $0A (0000 1010) on data bus.
Processor latches $0A from data bus

-Third cycle-
Processor outputs $000A on address bus, with R/W high.
TIA outputs the state of paddle 2 on bit 7 of the data bus, and outputs a 0 on bit 6.  Other bits which were 00 1010 may remain that way.
Processor latches (whatever) from data bus

 

By your description of the code, the gotcha might be the behavior of bits 0-5, or it might be a result of leakage triggering the paddle input. Plugging a paddle into the right hand port would almost certainly cause the latter type of problem.

[Cybergoth]

bottom_active_length	   = 10
;
; ...
;
  LDA bottom_active_length
  STA TIM64T
;
; should have been LDA #bottom_active_length

 

I find it helpful to have constants use ALL_CAPS, as oposing to all other variables, so you can quickly scan through your code and identify such mistakes.

 

I think the ancient ones probably had some means of trapping unwanted reads, as you often find them writing to a different mirror of the TIA registers than where they're reading from, so there's clearly separated reading and writing ranges.

 

VCS.H is already prepared for this, you can define the constants

TIA_BASE_ADDRESS, TIA_BASE_READ_ADDRESS and TIA_BASE_WRITE_ADDRESS

for this purpose.

 

Maybe an emulator can be tweaked to trap reads in the wrong range with a certain developer option.