4 ms·

Even when the OS was loaded off of a hard drive, the boot time was still about 2-3 seconds (I did measure this). Not really exceptional. It took maybe a minut

by kabdib 7y ago

Even when the OS was loaded off of a hard drive, the boot time was still about 2-3 seconds (I did measure this). Not really exceptional. It took maybe a minute to load off floppy disk. That is STILL shorter than the POST time for every machine I work with these days, with the possible exception of the Raspberry Pi in the closet.

cmrdporcupine 7y ago
All of Atari ST TOS is 192KB. On a floppy that would take a while to load. Off a hard drive, sure, not too bad.
- kabdib 7y ago
  About 60-70 seconds, IRRC. It's been a while since I measured it. We did some optimizations, other folks did a better job (e.g., optimally skewing physical sectors so that they'd be hit nearly immediately after a head seek).
  - cmrdporcupine 7y ago
    Hah, I didn't notice it was you who I was responding to. How nice of me to tell you the size of the OS you helped write ;-)
    - kabdib 7y ago
      That deserves a story, too. Why not? [Note: this is the early 80s. A computer with a large amount of memory might have 64K in this period. I think a 64K ROM cost about four dollars, and 64K of RAM was about fifty bucks] The Atari ST's operating system (TOS, and no I don't want to talk about what that stands for) was written in C and assembly language. Initially the ST was going to have 128K of ROM; we wanted to one-up the Macintosh (which hadn't shipped yet, but there were rumors and we had copies of Inside Macintosh that were simply fascinating to read) and put both our OS and a version of BASIC in ROM. Most home computers at the time came with some version of BASIC, and the Mac did not; we were hoping that would be a differentiator. Trouble was, nobody had actually sized our software yet (the only things even remotely running were on the 8086, not the 68000 we were going to use, and Digital Research wasn't exactly forthcoming about details anyway). So mid-October (the project started in earnest in July 1984, and FWIW we shipped in late May 1985, a whole new platform starting from zero in less than ten months) we realized that just the OS and GUI would be 128K, and that the BASIC we were thinking of using was like 80K (but could probably be shrunk). So the hardware guys added two more ROM sockets, for 192K of ROM. A month went by. Wups! -- it turned out that the OS and GUI would be like 170K, with little hope of shrinkage. No, make that 180K. Would you take 200K? The code topped out at 210K or so, and that wouldn't even fit into the six ROM sockets we now had. No chance in hell of getting another 64K of ROM -- that stuff costs real money -- so we shrunk the code. The team from Atari came from a background of writing things that fit into really tiny amounts of ROM, so we went about this with a fair amount of glee. We got about 1K per programmer per day of tested code savings by ripping out unused functions, fixing all the places where people had "optimized" things by avoiding the expense of strlen or whatever, and coding some common graphics calls with machine trap instructions instead of fatter JSRs. For about a week, the hallway in engineering was full of people calling out to other offices, "Wow, get a load of this stupid routine!" and in a codebase that had been tossed together as quickly as GEM/TOS had been, there was no lack of opportunity for improvement. We found a fair number of bugs doing this, too. Additionally, the C compiler we were using was not very good, and even its "optimized" code was terrible. Fortunately it had an intermediate assembly language stage, so we wrote some tools to optimize that intermediate code (mostly peephole stuff, like redundant register save/restores) and got a relatively easy 10-12 percent savings. I think we had a few hundred bytes of ROM left on the first release. I remember that 192K pretty darned well. Though they're fun to talk about, I honestly don't miss those days much; today I wrote the equivalent of void *p = malloc( 1024 * 1024 * 1024 ); and I didn't even feel bad.
      - cmrdporcupine 7y ago
        Funny, the EmuTOS guys are _still_ finding stuff in the original DRI sources to clean up. They've managed to stay within the 192KB budget as well. It's interesting that the original plan was to get a BASIC in there, because IMHO that really was a weak point of the ST for its target market -- which I guess included my 13 year old self. At least for the first couple years.
DanBC 7y ago
Are the post times modifiable? I'm using a Dell E7440 and it's pretty quick to boot from powered off. I have a bunch of stuff turned off in the bios. It's my machine on my home network, it's not a corporate machine with all the corporate stuff. But maybe that's the lever we need to get change: 30 seconds extra for 1000 people over 250 working days a year is over 2000 person hours being spent waiting for machines to boot. And that wait time for the corporate stuff is something that real people talk about. Here are a few twitter threads about people in different NHS organisations. Some people are waiting 3 to 10 minutes, a few are waiting even longer(!!) https://twitter.com/griffglen/status/1066043840497360897?s=20 https://twitter.com/griffglen/status/1066043840497360897?s=2... https://twitter.com/bengoldacre/status/1038329028623716358?s=20 https://twitter.com/bengoldacre/status/1038329028623716358?s... https://twitter.com/dannyjpalmer/status/1123604293251158016?s=20 https://twitter.com/dannyjpalmer/status/1123604293251158016?...
- kabdib 7y ago
  For database servers with multiple TB of RAM, 10-15 minutes is not unusual for POST. It's nuts. The memory was fine the last time it was tested (30 minutes ago, on the last reboot). Let's just train some buses, probe some address spaces and go, okay?

by kabdib 7y ago

cmrdporcupine 7y ago

All of Atari ST TOS is 192KB. On a floppy that would take a while to load. Off a hard drive, sure, not too bad.

kabdib 7y ago
About 60-70 seconds, IRRC. It's been a while since I measured it. We did some optimizations, other folks did a better job (e.g., optimally skewing physical sectors so that they'd be hit nearly immediately after a head seek).
- cmrdporcupine 7y ago
  Hah, I didn't notice it was you who I was responding to. How nice of me to tell you the size of the OS you helped write ;-)
  - kabdib 7y ago
    That deserves a story, too. Why not? [Note: this is the early 80s. A computer with a large amount of memory might have 64K in this period. I think a 64K ROM cost about four dollars, and 64K of RAM was about fifty bucks] The Atari ST's operating system (TOS, and no I don't want to talk about what that stands for) was written in C and assembly language. Initially the ST was going to have 128K of ROM; we wanted to one-up the Macintosh (which hadn't shipped yet, but there were rumors and we had copies of Inside Macintosh that were simply fascinating to read) and put both our OS and a version of BASIC in ROM. Most home computers at the time came with some version of BASIC, and the Mac did not; we were hoping that would be a differentiator. Trouble was, nobody had actually sized our software yet (the only things even remotely running were on the 8086, not the 68000 we were going to use, and Digital Research wasn't exactly forthcoming about details anyway). So mid-October (the project started in earnest in July 1984, and FWIW we shipped in late May 1985, a whole new platform starting from zero in less than ten months) we realized that just the OS and GUI would be 128K, and that the BASIC we were thinking of using was like 80K (but could probably be shrunk). So the hardware guys added two more ROM sockets, for 192K of ROM. A month went by. Wups! -- it turned out that the OS and GUI would be like 170K, with little hope of shrinkage. No, make that 180K. Would you take 200K? The code topped out at 210K or so, and that wouldn't even fit into the six ROM sockets we now had. No chance in hell of getting another 64K of ROM -- that stuff costs real money -- so we shrunk the code. The team from Atari came from a background of writing things that fit into really tiny amounts of ROM, so we went about this with a fair amount of glee. We got about 1K per programmer per day of tested code savings by ripping out unused functions, fixing all the places where people had "optimized" things by avoiding the expense of strlen or whatever, and coding some common graphics calls with machine trap instructions instead of fatter JSRs. For about a week, the hallway in engineering was full of people calling out to other offices, "Wow, get a load of this stupid routine!" and in a codebase that had been tossed together as quickly as GEM/TOS had been, there was no lack of opportunity for improvement. We found a fair number of bugs doing this, too. Additionally, the C compiler we were using was not very good, and even its "optimized" code was terrible. Fortunately it had an intermediate assembly language stage, so we wrote some tools to optimize that intermediate code (mostly peephole stuff, like redundant register save/restores) and got a relatively easy 10-12 percent savings. I think we had a few hundred bytes of ROM left on the first release. I remember that 192K pretty darned well. Though they're fun to talk about, I honestly don't miss those days much; today I wrote the equivalent of void *p = malloc( 1024 * 1024 * 1024 ); and I didn't even feel bad.
    - cmrdporcupine 7y ago
      Funny, the EmuTOS guys are _still_ finding stuff in the original DRI sources to clean up. They've managed to stay within the 192KB budget as well. It's interesting that the original plan was to get a BASIC in there, because IMHO that really was a weak point of the ST for its target market -- which I guess included my 13 year old self. At least for the first couple years.

DanBC 7y ago

Are the post times modifiable? I'm using a Dell E7440 and it's pretty quick to boot from powered off. I have a bunch of stuff turned off in the bios. It's my machine on my home network, it's not a corporate machine with all the corporate stuff. But maybe that's the lever we need to get change: 30 seconds extra for 1000 people over 250 working days a year is over 2000 person hours being spent waiting for machines to boot. And that wait time for the corporate stuff is something that real people talk about. Here are a few twitter threads about people in different NHS organisations. Some people are waiting 3 to 10 minutes, a few are waiting even longer(!!) https://twitter.com/griffglen/status/1066043840497360897?s=20 https://twitter.com/griffglen/status/1066043840497360897?s=2... https://twitter.com/bengoldacre/status/1038329028623716358?s=20 https://twitter.com/bengoldacre/status/1038329028623716358?s... https://twitter.com/dannyjpalmer/status/1123604293251158016?s=20 https://twitter.com/dannyjpalmer/status/1123604293251158016?...

kabdib 7y ago
For database servers with multiple TB of RAM, 10-15 minutes is not unusual for POST. It's nuts. The memory was fine the last time it was tested (30 minutes ago, on the last reboot). Let's just train some buses, probe some address spaces and go, okay?