Share your coding nightmares.

[A Sprite]

Whether it's pouring over thousands of lines for the cure to an AI routine that murders itself instantly, a single exit that reboots the game, or the worst sounds to come out of a PC since the late 80's, programming isn't for the weak of heart.

 

The campfire has been lit, anyone got any good horror stories?

[+FujiSkunk]

Try learning the SCSI protocol in general, and persistent reservations in particular, and coding up tests to see if a particular piece of hardware actually follows the spec, all in about two weeks' time.

[JamesD]

I had to write a driver for a GPIB chip in an embedded system. Anyone ever read the specs for GPIB? EVIL!!!

[Mark2008]

I hate to say it, but when I think of programming nightmares...I don't think of the issue of tracing down a logic error before it went to production....I think more about, an error that was never caught, and did go into production.

 

I can think of someone programming a traffic light, that didn't work, and people died...some medical scanner that radiated someone to death...some military GPS system that accidentally sent a pilot into enemy anti-aircraft fire....

 

That's why I don't go near a Nuclear Power plant....

 

I'm not going to post my worst experience, except to say no one died... but programming can really suck,s ometimes...enjoy programming a game or two...I do.

[Tempest]

My boss asked me to bug fix and port a poorly conceived security system that was written in VB6 to C# and ASP.NET. I actually asked him if he was smoking crack...

 

Later on they decided to just port it to VB.NET which wasn't all that much better, but it did save my sanity. I left that position shortly after...

 

Tempest

[Trey]

I can think of someone programming a traffic light, that didn't work, and people died...some medical scanner that radiated someone to death...some military GPS system that accidentally sent a pilot into enemy anti-aircraft fire....

 

That's why I don't go near a Nuclear Power plant....

 

critical software systems undergo extreme scrutiny. even then, things happen. like when a f-22 crossed the international date line, the computer went into an infinite loop.

 

http://www.freerepublic.com/focus/f-news/1791574/posts

[sack-c0s]

2000-ish, platform game engine for the nintendo gameboy colour.

 

works fine, music plays, no graphical corruption.... oh wait.

 

player is running left.

 

so i went over the main loop, the input routines, checked the scrolling code for good measure and blew 2 days going mental at the z80-ish monstrosity I had created until i reached the point the music was making me borderline psychotic and commented it out.

 

problem solved.

 

reinstate music - problem reappears.

 

Turns out that after collecting the input, but before processing it the interrupt routine that called the music driver kicked in every frame. Guess which register I hadn't stacked on entry/exit?

[Gorf]

Anything you have to do on the Jaguar( hopefully only until the tools(SMAC/SLN) are finished.)

 

The biggest nightmare is hand coding for GPU main execution. SMAC helps a lot here. I still do

a lot by hand though.

Edited February 19, 2009 by Gorf

[Kurt_Woloch]

That reminds me of my attempted port of Tetrinet to the G7400 (the European, released version of the non-released Magnavox Odyssey^3).

The G7400 has multiple levels of memory with ascending size but, also, ascending difficulty of accessing it...

 

1. The 8048's registers (R0-R7)... always available

2. The 8048's internal RAM... 32 usable bytes, only accessible by pointing a register to the RAM location

3. External RAM... 128 bytes, only accessible by pointing a register to the RAM location, AND before doing that you have to set the port so that the write goes to the RAM (since the address space is shared with the external RAM, the video chip and the teletext chip, and you have to select where to read or write from first)

4. Video RAM... several kilobytes, but only accessable by defining characters or writing them to the screen on the Teletext chip - no way of accessing the memory directly

 

Because of those added difficulty levels, I tried to pack as many of the game variables as possible into the internal RAM. However, instead of displaying falling bricks as they should be, every time a brick came down to a halt, the program virtually "exploded", putting characters all across the screen. After a long time of debugging, it turned out to be the following error:

 

If a brick went down, the program went into a routine that brought up the next brick (the line checking wasn't implemented yet). However that routine took longer than usual, so processing time exceeded the time needed to draw a frame on screen (partially due to the slow access to the Teletext chip's screen RAM, where each access takes over 100 yS in average). Normally, I was waiting for the next frame to start and then executed the game calculations. However, in between that, the interrupt happened, and the interrupt routine got called, and also trashed some CPU registers and some internal RAM locations. As long as the game calculations didn't exceed the frame, it was all fine, but when they were not finished at the time the interrupt routine kicked in, some temporary variables (most notably a loop counter which counted down the bricks from 3 to 0... or up?) got trashed, and everything went mad from that on. The solution to that problem was:

1. not to use those locations which got trashed by the interrupt routine

2. to spread the long routine across several frames... which I planned to do, but then I didn't continue work on that game. However, this point would be necessary in order not to influence the speed of the game by the actions of one player, which would cause the game to run at an inconsistent speed for the other player for no apparent reason.

 

 

 

2000-ish, platform game engine for the nintendo gameboy colour.

 

works fine, music plays, no graphical corruption.... oh wait.

 

player is running left.

 

so i went over the main loop, the input routines, checked the scrolling code for good measure and blew 2 days going mental at the z80-ish monstrosity I had created until i reached the point the music was making me borderline psychotic and commented it out.

 

problem solved.

 

reinstate music - problem reappears.

 

Turns out that after collecting the input, but before processing it the interrupt routine that called the music driver kicked in every frame. Guess which register I hadn't stacked on entry/exit?

[roland p]

For PDF generation of one of my websites I use XSL, parse it with XML so I get XSL:FO which can be converter to PDFs.

 

XSL parsed with XML to ouput XSL:FO causes true pain:

- no error at line ...

- screw something up and you end up with an error like 'No flow in page-sequence'...

- no syles, the parsed XSL looks something like an html website without css with all styles written out... For example one line of a bullited list takes up about 15 lines of code..

- XSL is one of the most obfuscated way of programming. If you program a function 'replace', you end up programming a really fancy recursive routine, which nobody on earth can understand anymore.

- my way of solving bugs has become: remark everything, see if it works, remark less code, see if it works etc.

 

 

Replacing a line-break character with <br/> in xsl can look like:

<xsl:template match="text()">
  <xsl:call-template name="break">
</xsl:template>

<xsl:template name="break">
  <xsl:param name="text" select="."/>
  <xsl:choose>
  <xsl:when test="contains($text, '')">
  <xsl:value-of select="substring-before($text, '')"/>
  <br/>
  <xsl:call-template name="break">
	  <xsl:with-param name="text" select="substring-after($text,
'')"/>
  </xsl:call-template>
  </xsl:when>
  <xsl:otherwise>
<xsl:value-of select="$text"/>
  </xsl:otherwise>
  </xsl:choose>
</xsl:template>

Edited March 7, 2009 by roland p

[+karri]

The most scary coding nighmare I know about happened more than 30 years ago. The election in Finland was going to be broadcasted live (as a matter of fact everything was live then) and the big idea was to do the results calculation on a computer in real time.

 

When the broadcast started the host talked about all provinces that we will receive votes for. Suddenly the programmer realized that he forgot to type in Ahvenanmaa which is a separate island between Sweden and Finland. If we start getting votes for a province that does not exist it may crash everything. So he rushed to the machine and punched in an extra card to the program to add one more province. Everybody was nervous as we had never run the program with this added province before. But the machine did not crash and everything turned out to work ok.

 

--

Karri

[Wickeycolumbus]

I have two, sort of related ones:

 

When Thomas Jentzsch and I were writing code to dump 2600 games to a SaveKey a few weeks ago, I had to test each version like they did back in the day- I had to erase an EPROM for 15 minutes, then program the eprom for another 5 minutes, then test it and figure out what went wrong. Each version took about 30 minutes just to test a few lines of new code.

 

I have to do a similar thing for HyperScan development. I first have to write assembly code for an obscure 32 bit processor, then assemble it, transfer it to my other computer to burn it onto a CD, and then finally test it. It is a nightmare because there is absolutely no information about the processor, we had to figure it out ourselves.

[+FujiSkunk]

For PDF generation of one of my websites I use XSL, parse it with XML so I get XSL:FO which can be converter to PDFs.

 

Ooh, you can stop right there.

 

I set up some XSL files to turn custom XML into HTML for my video game web site project. XSL is this weird I-wanna-be-a-programming-language-except-really-I'm-not kind of thing, so I definitely feel your pain.

[landondyer]

Whether it's pouring over thousands of lines for the cure to an AI routine that murders itself instantly, a single exit that reboots the game, or the worst sounds to come out of a PC since the late 80's, programming isn't for the weak of heart.

 

The campfire has been lit, anyone got any good horror stories?

 

Developing a game on an Atari 800 with an 810 drive; source code disk is in the drive. The game crashes and somehow does a JMP to the "format floppy disk" routine in the ROM. The drive goes "tick tick tick...." and all the source code is vaporized.

 

This is why you keep backups.

 

[Didn't happen to me, but to a friend of mine, Jack Palevich. He was pretty miffed. I don't recall if he kept a backup.]

[+Allan]

Whether it's pouring over thousands of lines for the cure to an AI routine that murders itself instantly, a single exit that reboots the game, or the worst sounds to come out of a PC since the late 80's, programming isn't for the weak of heart.

 

The campfire has been lit, anyone got any good horror stories?

 

Developing a game on an Atari 800 with an 810 drive; source code disk is in the drive. The game crashes and somehow does a JMP to the "format floppy disk" routine in the ROM. The drive goes "tick tick tick...." and all the source code is vaporized.

 

This is why you keep backups.

 

[Didn't happen to me, but to a friend of mine, Jack Palevich. He was pretty miffed. I don't recall if he kept a backup.]

For those who think this name sounds familiar, Jack Palevich was the programmer of Dark Chambers and it's precursor, Dandy.

 

Allan

[+Allan]

http://www.atariarchives.org/APX/showinfo.php?cat=20210

 

I'm assuming the Landon in this story is you, Mr. Dyer. Sounds like fun times.

 

Allan

[kenfused]

Developing a game on an Atari 800 with an 810 drive; source code disk is in the drive. The game crashes and somehow does a JMP to the "format floppy disk" routine in the ROM. The drive goes "tick tick tick...." and all the source code is vaporized.

 

This is why you keep backups.

 

[Didn't happen to me, but to a friend of mine, Jack Palevich. He was pretty miffed. I don't recall if he kept a backup.]

I one time had a crash on a program I was working on, and hit reset, and heard the sounds of disk writes. Took me a few seconds to realize what I was hearing and powered off the computer but it did damage one of the source files

 

When my 800XL got upgraded to 256K I started using a RAMDISK. It only takes a crash or two that corrupts extended memory to learn to copy out changed files to a floppy frequently.

[supercat]

When my 800XL got upgraded to 256K I started using a RAMDISK. It only takes a crash or two that corrupts extended memory to learn to copy out changed files to a floppy frequently.

 

Did anyone engineer RAM disk units that included measures to prevent corruption by errant software? Depending upon what chip-select signals are available, things could be protected greatly by the addition of even one or two 74xx-series chips. Adding four or so would allow one to provide very effective protection. Did anyone do such things?

[EricBall]

In university I coded a trivial RTOS for the 68K in ASM. The demo app worked fine except it leaked memory. I finally found the problem by stepping through the code in debug mode and discovering the JSR free() was missing. It turns out I'd managed to hit backspace at the begining of the line, moving the JSR into the comment field for the previous line.

 

Then there was the C code I did which worked fine but crashed on exit. Finally tracked that down to a negative array index.

 

The Parallax Propeller has a really cool combo JSR+RET instruction (it modifies the RET to JMP PC+1 'cause it has no stack). The only problem is if you want a simple JMP, you have to code it as JMP #label (i.e. immediate valute). Otherwise you end up with an indirect JMP [label] which will then go off to never-never land.

 

And although I've never killed anyone with a coding error, the first cartridge release of Skeleton+ had a bug and the "You Won" screen would roll.

[Bryan]

Castle Crisis for the 5200 had a rather glaring error in the first version. I developed it using a 4-port machine and I had always assumed the 2-port machine would behave as a 4-port with controllers unplugged. I was wrong.

 

Atari's preferred method for multi-player 5200 games is to have the game ask for the number of players and restrict you to ports up to that number, but I wanted the "jump-in" method of the arcade game. I think Allan was the first to notify me that if a player joined on a 2-port machine, the game would think two players had joined. Apparently, Atari had saved a few cents on the 2-port by removing half the decoding logic for the controllers.

 

This hardware change doesn't affect the POT readings, so the solution was to quickly patch the game so it ignored button input from ports 3 and 4 unless there ware POT values for those ports.

 

Albert had already started shipping the buggy version and I ended up fixing a whole lot of cartridges for people.

 

Besides that, I almost lost a lot of work on the game in a hard drive crash.

Edited July 22, 2009 by Bryan