Writing a Program for the ST -- Whoops!

[SoulBlazer]

Was checking out a site tonight about old computers and ran into this tale that someone recalled from working on a Atari ST, and thought I'd share it here for the laugh.

 

Fred Butzen writes:

 

"Here's one of my stories. Not really old school, but it's funny.

 

In the mid-80s, MWC wrote one of the first C compilers for the Atari ST -- the "Jackintosh", so called because Jack Tremiel (formerly of Commodore) designed it with Atari as a rip-off of the Macintosh. It had a GUI built around Digital Research's GEM interface. It had two floppies, a 68000 CPU, and 512 kilobytes of RAM -- which in those days was a lot of memory. To save money, the hardware was totally sleezy. From time to time it would simply stop working, and you'd have to open up the unit and reseat all of the chips in their sockets. If you were in a hurry, you'd just lift up the unit about six inches and drop it. A total piece of junk.

 

Part of the savings was that the machine had no MMU and no parity on the memory. This meant that the machine was totally unreliable; however, it also meant that a kid hacker could do anything to the hardware, and there's no way the machine would stop him. (Mind you, that anything included smoking the tube, but that's another story.) For example, I wrote a little program that reset the base address of video memory to zero, which was where the operating system lived. (Video used RAM, of course, rather than memory on a separate card.) It was kind of cool, because when you ran a program that allocated memory -- say, a sort program, you could see the memory being allocated and deallocated on the screen. The difference between qsort and shellsort was really obvious just by the patterns they drew on the screen.

 

Anyway, as a programming exercise I wrote a version of the game of life for this machine. It ran fine; however, I made one mistake: I forgot to set the clipping rectangle around the screen. So, the first time I built a glider gun, the glider went creeping off the screen, and just kept on going, crashing through memory. Mind you, there's no MMU, so the machine is still running while the glider is rampaging through memory. Because the 68000 used memory-mapped ports for its hardware, you could see where the glider was going because the disk drives starting running, the lights flashed on the keyboard, the tube blinked, and so on. Finally, the glider hit something really vital and the machine died with "streaky bombs" -- a sign that the operating system was really, really sick.

 

Of course, I had to show this to all the other guys. We laughed ourselves sick watching that happen."

[Rybags]

Practically no modern home-based machine uses CRC, ECC or parity on RAM.

 

The Amiga didn't have a proper MMU. I highly doubt the Mac had a proper MMU either, it didn't have proper multitasking until System 7 came along which was 1993 or something like that. PCs didn't have the basis of what's neeeded for multitasking until the '386 came along.

 

"Ripoff of the Mac" - there's a laugh, considering Jobs stole the whole GUI idea from Xerox.

[+poobah]

The story, for more reasons than I care to enumerate, has to be completely apocryphal, particularly the "glider" bit.

[SoulBlazer]

Mind you, I said nothing if it was TRUE or not. I don't even understand what half of it MEANS.

 

It was presented as a true story, and I got a laugh out of it, so I was just sharing it as such.

[carmel_andrews]

Perhaps this was Fred (and Landon's) as well as the other warners Atari people that bothered to stay, way of telling Tramiel to 'F Off'

[Ato]

For example, I wrote a little program that reset the base address of video memory to zero, which was where the operating system lived

Right. Set LogBase and PhysBase to $0. Where is the magic?

 

the lights flashed on the keyboard

Booooo-gus. What lights? If I remember correctly and interpret the lack of LEDs for CAPS/NUM/etc. in my Falcon and my Mega ST correctly, one cannot toggle any LEDs on the KBD because there are none. I believe that the power LED on Falcon/Mega/[TT?] KBDs is wired to power (5V?) straight through.

 

My opinion:

Goodness, what a bunch of crap. But unfortunately it is well written and therefore has been made believable but nonetheless it represents improper spreading of false facts.

 

Please correct me if I am wrong. My knowledge might be quite rusty.

 

Cheers,

T.

Edited February 10, 2011 by Ato

[Christos]

Yeah you are right.

Edited February 10, 2011 by Christos

[+rdemming]

the lights flashed on the keyboard

Booooo-gus. What lights? If I remember correctly and interpret the lack of LEDs for CAPS/NUM/etc. in my Falcon and my Mega ST correctly, one cannot toggle any LEDs on the KBD because there are none. I believe that the power LED on Falcon/Mega/[TT?] KBDs is wired to power (5V?) straight through.

 

The STF(M), STE and Falcon have the drive led on the keyboard. You can turn that on and off by writing the port A register in the YM2149 soundchip that generates the drive select signals. Writing #$000E to $FF8800 selects the port A register and then writing to $FF8802 will set the value of port A. The drive led can be turned on by setting bit 1 of port A to 0.

 

Since the YM2149 is the only chip that is repeated in the memory map (but not on Falcon) (in other words writing to addresses $FF8804, $FF8808, $FF880C will be the same as writing to address $FF8800), I can imagine that a writing function overflowing in this memory area might flash the drive led as long as often the value #$xxxE is written at long word boundaries.

 

Robert

Edited February 10, 2011 by rdemming

[+poobah]

For example, I wrote a little program that reset the base address of video memory to zero, which was where the operating system lived

Right. Set LogBase and PhysBase to $0. Where is the magic?

 

the lights flashed on the keyboard

Booooo-gus. What lights? If I remember correctly and interpret the lack of LEDs for CAPS/NUM/etc. in my Falcon and my Mega ST correctly, one cannot toggle any LEDs on the KBD because there are none. I believe that the power LED on Falcon/Mega/[TT?] KBDs is wired to power (5V?) straight through.

 

My opinion:

Goodness, what a bunch of crap. But unfortunately it is well written and therefore has been made believable but nonetheless it represents improper spreading of false facts.

 

Please correct me if I am wrong. My knowledge might be quite rusty.

 

Cheers,

T.

 

Try writing to 0x000000... =P

Try reading or writing to the memory that doesn't exist between the current screen and the I/O region....

[+rdemming]

Try writing to 0x000000... =P

Try reading or writing to the memory that doesn't exist between the current screen and the I/O region....

 

Bus error! A program overflowing the screen memory would already bomb out before reaching the IO area. So the part of the "glider gun" rampaging through ram and then IO area is bogus unless his code that overflows the screen memory 'magically' skipped the non used parts of the memory map or if he redirected the bus error handler vector to a routine that does an "return from exception (RTE)".

 

Robert

[Rybags]

In theory they might have trapped such exceptions.

 

Problem is though, a game of "Life" can hardly waltz through memory that doesn't exist. I'd say the algorithm would just break down if you pointed it somewhere that couldn't be altered and just returned constant values.

 

 

As "bad" as the ST might have eventually been regarded as (this guy actually sounds more like a PC snob of the time than a Mac user), IBM clones had nothing on it until the '386 era, and even at that didn't have anything resumbling a useful GUI until Windows 3.1 came along.

 

Both those were well after 1985.

Edited February 10, 2011 by Rybags

[Ato]

Since the YM2149 is the only chip that is repeated in the memory map (but not on Falcon) (in other words writing to addresses $FF8804, $FF8808, $FF880C will be the same as writing to address $FF8800), I can imagine that a writing function overflowing in this memory area might flash the drive led as long as often the value #$xxxE is written at long word boundaries.

 

Oops. You are quite correct. Forgot about that one because on my Falcon it does not work. <- Lame excuse but true. Good catch, thanks for correcting me!

 

Cheers,

T.

[ijor]

Try writing to 0x000000... =P

Try reading or writing to the memory that doesn't exist between the current screen and the I/O region....

 

Bus error! A program overflowing the screen memory would already bomb out before reaching the IO area.

 

I agree that the story doesn't sound completely true. However, a few things do make some sense.

 

Resetting the video address (physbase) to zero is valid. It won't produce any bus errors as long as only physbase (and not logbase) is changed, because in this case you don't write to address zero. SHIFTER would gladly read from address zero (the true address zero) without problems. Of course, you won't get a "nice" display, but that's not the point.

 

Another (minor) point, is that bus error happens only beyond the 4MB address range. Accessing the area between end of screen or end of RAM (assuming the computer has less than 4MB RAM) and the 4MB address doesn't produce a bus error.

[+rdemming]

Another (minor) point, is that bus error happens only beyond the 4MB address range. Accessing the area between end of screen or end of RAM (assuming the computer has less than 4MB RAM) and the 4MB address doesn't produce a bus error.

 

Very true, and thats the reason quite a few programs don't work with 4MB while they work with less memory.

Often caused by a badly programmed loop to clear the memory that just overflows one byte (e.g. because using a smaller equal comparison instead of smaller than comparison, or using a counter one too big).

Usually end addresses used are just after the last byte instead of the last byte itself.

 

 

e.g.

 

; Clear memory using comparison (wrong and not tested)
lea start,A0 ; Start address of memory to clear
lea end,A1 ; End address of the memory to clear (just after the last byte to clear)

loop:
clr.b (a0)+
cmp.l A0,A1
bls.s loop ; Loop when lower or same (Wrong!) does one byte too much. Use blo (lower) or better bne (not equal) instead.

 

 
; Clear using counter (wrong and not tested)
lea start,A0 ; Start address of memory to clear
move.l #end,D0 ; End address of the memory to clear (just after the last byte to clear)
sub.l A0,D0	; Number of bytes to clear (Wrong!) does one byte too much. Must decrement one (add 'subq.l #1, D0' or change the previous line to 'move.l #end-1,D0')
loop: 
clr.b (a0)+ 
dbra.s loop

 

Robert

Edited February 14, 2011 by rdemming

[+poobah]

Another (minor) point, is that bus error happens only beyond the 4MB address range. Accessing the area between end of screen or end of RAM (assuming the computer has less than 4MB RAM) and the 4MB address doesn't produce a bus error.

 

Very true, and thats the reason quite a few programs don't work with 4MB while they work with less memory.

Often caused by a badly programmed loop to clear the memory that just overflows one byte (e.g. because using a smaller equal comparison instead of smaller than comparison, or using a counter one too big).

Usually end addresses used are just after the last byte instead of the last byte itself.

 

 

e.g.

 

; Clear memory using comparison (wrong and not tested)
lea start,A0 ; Start address of memory to clear
lea end,A1 ; End address of the memory to clear (just after the last byte to clear)

loop:
clr.b (a0)+
cmp.l A0,A1
bls.s loop ; Loop when lower or same (Wrong!) does one byte too much. Use blo (lower) or better bne (not equal) instead.

 

 
; Clear using counter (wrong and not tested)
lea start,A0 ; Start address of memory to clear
move.l #end,D0 ; End address of the memory to clear (just after the last byte to clear)
sub.l A0,D0	; Number of bytes to clear (Wrong!) does one byte too much. Must decrement one (add 'subq.l #1, D0' or change the previous line to 'move.l #end-1,D0')
loop: 
clr.b (a0)+ 
dbra.s loop

 

Robert

 

It's not really an overflow, it is the 68K's pre-fetch operation that does it.

[oky2000]

 

As "bad" as the ST might have eventually been regarded as (this guy actually sounds more like a PC snob of the time than a Mac user), IBM clones had nothing on it until the '386 era, and even at that didn't have anything resumbling a useful GUI until Windows 3.1 came along.

 

Both those were well after 1985.

 

You mean Win95 surely, Win 3.1 was no better a GUI than Win286 and ALL pale into insignificance compared to GEM and OS/2 on PCs

[+rdemming]

It's not really an overflow, it is the 68K's pre-fetch operation that does it.

 

AFAIK, the 68000 only has instruction pre-fetch and not data pre-fetch. So unless you have an instruction at the last word in RAM, it will not pre-fetch and instruction beyond the available memory. The changes to have an instruction at the last word in memory would be quite slim since usually program code is before the data section and bbs section.

 

Robert

[ijor]

It's not really an overflow, it is the 68K's pre-fetch operation that does it.

AFAIK, the 68000 only has instruction pre-fetch and not data pre-fetch. So unless you have an instruction at the last word in RAM, it will not pre-fetch and instruction beyond the available memory. The changes to have an instruction at the last word in memory would be quite slim since usually program code is before the data section and bbs section.

 

I think both of you are right, both cases exist. The samples shown by Robert are, clearly, an overflow. But there are also cases with code at the end of RAM producing the bus error because of the prefetch mechanism.

 

Robert, it is true that programs are usually organized with code at the start. But some programs relocate a small routine at the end of RAM (at the unused bytes beyond the end of the screen).