Koffi crash / Eprom Q's

[+Cafeman]

Last week before the Cinci Classic show, I made a number of small changes to my game Koffi: Yellow Kopter, mostly just title screen and "reward screen" graphical changes and the flow of when these load up before/after the real levels. However, I made the error of putting in all the changes and relying on the emulators (VSS and 800win 3.0) for the testing; when I finally burned an Eprom on Friday AM, I found Koffi's newly changed title screen is messed up and the game now crashes after I press Start.

 

[EDIT 10/10/2002 -- turns out all these symptoms were due to an incorrect setting on my Pocket Programmer, which I had inadvertently changed.]

 

(Click here to see how the Title Screen looks in VSS and 800Win. On the real 5200 though, the "Koffi" letters are now offset and jagged, as though the pixels aren't lined up correctly: http://cafeman.www9.50megs.com/atari/5200d...offiKopter.html )

 

I haven't started to go thru my code yet to figure out just what the heck I did, but I thought I'd ask a few general questions from you knowledgable folks.

 

1. What kind of error could I possibly be making that isn't really picked up on these emulators, but causes graphical problems (pixels in the wrong place) and crashes?

 

History: in the past, I forgot to pull the X register off the stack in the final DLI of the 4th stage ("Pyro's Mom").; This caused the effect of graphical problems in the draw routines of her face. VSS didn't catch it, 800win acted exactly like the real machine though. Note that by simply moving the JSR DrawFace to lower in code, that it worked 'better' even with the glitch in place!! Thanks to Dennis though, we found this bug and I fixed it, solving the problem. I've also noticed that if I exceed my cycles in a DLI, Atari800win "catches" this and acts the same as the real machine. Which is GREAT for testing!

 

2. Atari800win doesn't act exactly like the real machine with my recent changes, BUT it *is* giving me a kind of warning -- when I press the 5 key to turn on Coloring book Debug Mode, I notice that this emulator doesn't seem to read the next "5" press to turn it off. This is something new. Strange. Actually, the real machine is crashing AFTER the title screen, on the Load Level screen where Koffi flies by the Text that announces the name of the next level. (and yes, I made engine changes to that screen).

 

3. The majority of the changes I've made in this messed-up version were simple efficiencies -- I eliminated unneeded filler "$00" bytes from the stored graphics data, and instead of reading and writing the entire line of bytes I stop when the data is done and ADC a value to get to the next row in the proper column. I've done this tons of times, the code looks correct, and works on emulators. However, I also changed the Display List for the Title Screen and added several DLI's to the title screen. I also added a new VBI routine for the LoadLevel screen. But what did I mess up? Argh!!?!

 

I hesitate to really post this since I'm rambling a bit and it's hard to describe the problems this way. What I'd really like is for somebody to tell my THE KINDS OF THINGS that a coder can do wrong to possible cause problems like these ones.

 

 

Any ideas?

[calamari]

Cafeman--

 

Post your title screen Display List, DLI, VBI, and credit card number. We'll take care of it

 

calamari

[Heaven/TQA]

hmmm... messed up screen... haven't seen the image but you say that you build up the screen while jumping with ADC to the next...

 

did you cleared the video-ram??? the emulators clear the RAM when you bootup... but maybe on 5200 not??? maybe you test it with a clear-video-ram routine?

 

just an idea.

 

hve

[Heaven/TQA]

and do not forget:

 

clc

adc #value

 

if you have missed up one CLC and voila you get an extra offset... and if used this in vram this could be the reason for have characters one byte to the right on the wrong position.

 

and take one advice from an professional brand manager in games biz...

 

always take older builds from a game you want to show on a fair, f.e. ECTS, Games Convention or E3, as the newest build could have problems...

 

hve

[+Cafeman]

I do clear the RAM first. I am performing CLC to clear the carry bit.

 

Although this may not be the reason for the messed up screen, I just noticed that my title screen display list seems to be > 192 scanlines. Do you count the initial 24 blank lines? (I think you do, it has been a long time since I thought about it).

 

The screen doesn't roll or anything, but I have a couple extra Antic 2 lines (8scanlines each) at the bottom and I'm fairly sure the total is now > 192 scanlines. However, the emulators don't seem to notice and I'm not home right now to test it -- what would you expect to happen from this condition?

 

(If I can't figure this out tonight, I'll try to post the applicable code then)

[+Cafeman]

Last night on the 5200 machine, I noticed that if I pressed any keypad button on the title screen, the game would lock up & crash. This is something new. If I let the game sit there, the title screen will eventually lock up & crash in the same manner.

 

If I press Start right after boot-up, then I get thru the title screen but the next screen (the Load Level text screen) crashes.

 

It's like after a set amount of time, something is getting corrupted. Argh.

[Sheddy]

How many cycles is the new VBI. If it's a lot, maybe something is overrunning now? How far down is the last DLI - could it be holding back the VBI (probably can't be that far down.. but something to double check?)

 

What timers are you using. For something to take that long to crash it could be some code that happens only when your slower ones are doing things. (Does that make sense? I mean, maybe you have a timer that only does something every second. And that thing is what goes wrong. Either screws up the stack or overwrites or something..).

 

This doesn't explain why it works on the emus though. Atari800 is normally very good. It is only the exact horizontal scan-line timing it doen't emulate 100%.

 

Is there any way you could have got a bad burn on the EPROM? (I know nothing about doing them though)

 

 

Good luck. I hate it when something like that happens. I've had to go back to an earlier source and re-write the code again to get to the bottom of some strange errors.

[+Cafeman]

I'm starting to think this is a hardware failure of some sort. Still investigating, but even my old versions of Koffi crash now. Three possibilities: my pocket programmer isn't burning Eproms correctly; or my test board is failing; or my 5200 is failing.

 

Hard to believe its my 5200; other games play okay, and Koffi glitches on both my 2 port and 4 port. Still checking ...

[+Cafeman]

Good Lord. Koffi works. I proclaim myself King of Boneheads.

 

I evidently messed up a Pocket Programmer setting. I just selected the "27C256" setting instead of "27256" and .. Koffi works. (I don't know why though, embarassingly enough).

 

I had been messing around with 16K settings a week or two ago and must have set it to the wrong setting, and wasn't aware.

 

At least this explains why the emu's worked and the main system crashed it.

 

I'm tired... but happy.

[+Cafeman]

Well, it appears there still is a slight problem, but not as bad as before when I was using the 27256 setting on that eprom.

 

So I jumped the gun a bit thinking that's all it was .. back to the drawing board, they say ...

[+Cafeman]

Hello all you EPROM burning experts -- I will just add to this thread, I have a question or two.

 

I suppose you should ignore all my above theories about Koffi crashing. It turns out that there was never anything wrong with my code, but instead I was evidently getting bad Eprom burns. (Just like Sheddy suggested above -- GOOD CALL) Hence my questions ...

 

1. WHen I changed the Pocket Programmer setting from 27256 to 27C256, it caused that burn to work when it crashed before. My question: could somebody explain the difference between these two types of EPROMS? I notice that some of my Eproms are 27256 and some are 27C256. Prior to this week, I never had this problem before of this magnitude, although this might explain why some Eproms wouldn't seem to work at all.

 

2. Even though the above 27C256 setting worked, Koffi still crashes when it hits the main game loop. Mitch told me that it doesn't crash at all for him, and he's tested it several times. Thus, I must still have a bad burn to my Eprom in that section of code. Note that I only burned the file to that 1 Eprom and only 1 time, and haven't had time to try again. Maybe tonight. Mitch suspects that the Eprom might not have been fully erased, though the Pocket Programmer thinks it was erased. I have my erase time set for about 5 minutes right now. Please give me your opinions on these theories, and on suggested erase times. Is this a feasible idea, that the Eprom wasn't fully erased & had "dirty data" on it, and the burn failed, noticeable only when it hit that section of code?

 

Thanks in advance.

[CPUWIZ]

There is subtle differences in the programming algorithm used between those 2 EPROM's, the only thing I can suggest is dig up the datasheets for both of them and compare them.

 

As to the erase time, 5 minutes is not enough in my opinion, I use 15-20 minutes for batches of 5. I don't have the same programmer as you do but the software should have aborted if the EPROM wasn't blank.

[+Cafeman]

You're not the first to say 5 minutes is short. It has worked up till now though. I'll bump it up.

 

Pocket Programmer will abort if it detects data, but some have told me that it often thinks of an Eprom is blank when it isn't. I'll try again.

[calamari]

Cafeman,

 

Erasing for 10-15 minutes with this Datarase II seems to do the job.

 

calamari

[+Cafeman]

Thanks all during my official "wild Koffi Goose Chase Week".

 

I had 2 problems it seems -- one was using 27256 setting for a 27c256 eprom. I'm using 10 minutes for my Datarase II now. Seems fine so far!

 

The other problem was ... a wire had disonnected from the back of my Eprom cart! I re-soldered it tonight .. no problems! Argh, I cannot believe the luck. I wasted an entire week on a wild goose chase, trying to find a problem in code that was never there.

 

Moving on, moving on....