Comments on: Why Take an Operating Systems Course? http://blog.regehr.org/archives/164 Tue, 07 Feb 2012 05:34:36 +0000 hourly 1 http://wordpress.org/?v=3.3.1 By: Neil Harding http://blog.regehr.org/archives/164/comment-page-1#comment-1062 Neil Harding Fri, 20 Aug 2010 16:43:48 +0000 http://blog.regehr.org/?p=164#comment-1062 The first commercial game I wrote for the Atari ST worked well, but a new version of the OS came out and it stopped working because the OS used more memory and there was not enough remaining (the base machine had 512K of RAM, but the OS used around 100K and slightly less if your program ran as a boot program, 60-70K if I remember correctly). I reduced the memory requirements, but didn't want it to happen again, so I decided to ditch the operating system. The next game I used, I used a routine to read from the disk directly by using the disk controller, which meant I could use 511K of the 512K available (the first 1K had hardware interrupt vectors), and they ran fine across multiple versions of the hardware that came out later. I could also use the same assembly program for the Atari ST and Commodore Amiga (the Amiga version used hardware for scrolling and blitting sprites, and DMA for sound playback), and added another 3 weeks to the program, so I basically had a micro OS that provided just the required facilities I needed for the game. The cartridge based consoles also had no operating system either, so those involved writing low level sound drivers that talked to the chips. One advantage of fixed hardware is that you can do far more than would be possible generically. I wrote a game for the Sega Master System, and you could download to the video controller during vblank at twice the rate as you could during non vblank. I was doing a game that required setting the hardware scroll register for each scanline (to shift the road with parallax, and as you went round a corner), so I had 229 cycles, so rather than wasting 219 of those cycles I wrote an extra 4 bytes to the video controller. The first commercial game I wrote for the Atari ST worked well, but a new version of the OS came out and it stopped working because the OS used more memory and there was not enough remaining (the base machine had 512K of RAM, but the OS used around 100K and slightly less if your program ran as a boot program, 60-70K if I remember correctly). I reduced the memory requirements, but didn’t want it to happen again, so I decided to ditch the operating system.

The next game I used, I used a routine to read from the disk directly by using the disk controller, which meant I could use 511K of the 512K available (the first 1K had hardware interrupt vectors), and they ran fine across multiple versions of the hardware that came out later.

I could also use the same assembly program for the Atari ST and Commodore Amiga (the Amiga version used hardware for scrolling and blitting sprites, and DMA for sound playback), and added another 3 weeks to the program, so I basically had a micro OS that provided just the required facilities I needed for the game.

The cartridge based consoles also had no operating system either, so those involved writing low level sound drivers that talked to the chips. One advantage of fixed hardware is that you can do far more than would be possible generically. I wrote a game for the Sega Master System, and you could download to the video controller during vblank at twice the rate as you could during non vblank. I was doing a game that required setting the hardware scroll register for each scanline (to shift the road with parallax, and as you went round a corner), so I had 229 cycles, so rather than wasting 219 of those cycles I wrote an extra 4 bytes to the video controller.

]]> By: Pradeep Padala http://blog.regehr.org/archives/164/comment-page-1#comment-544 Pradeep Padala Fri, 11 Jun 2010 13:28:33 +0000 http://blog.regehr.org/?p=164#comment-544 For me, the last part "computer system design" is the most valuable lesson from taking OS courses. As you say, it is more art than science, I hope more people spent their time in an OS course, than learning Java programming. I also completely agree with the assertion that motivated people can easily learn how to write an OS. For me, the last part “computer system design” is the most valuable lesson from taking OS courses. As you say, it is more art than science, I hope more people spent their time in an OS course, than learning Java programming.

I also completely agree with the assertion that motivated people can easily learn how to write an OS.

]]> By: The Ramblings of a Hatter › Delicious Bookmarks for June 8th through June 11th http://blog.regehr.org/archives/164/comment-page-1#comment-540 The Ramblings of a Hatter › Delicious Bookmarks for June 8th through June 11th Fri, 11 Jun 2010 08:05:41 +0000 http://blog.regehr.org/?p=164#comment-540 [...] Embedded in Academia : Why Take an Operating Systems Course? - I completely agree, the title should probably be "Why Take a Hands-On Operating Systems Course" - I had an OS course at University but it was a subset of a larger systems course and very high-level theory. Would have preferred a dedicated, hands-on, OS course. [...] [...] Embedded in Academia : Why Take an Operating Systems Course? – I completely agree, the title should probably be "Why Take a Hands-On Operating Systems Course" – I had an OS course at University but it was a subset of a larger systems course and very high-level theory. Would have preferred a dedicated, hands-on, OS course. [...]

]]> By: Adam Dunkels http://blog.regehr.org/archives/164/comment-page-1#comment-532 Adam Dunkels Wed, 09 Jun 2010 07:59:03 +0000 http://blog.regehr.org/?p=164#comment-532 I really like how you highlight the fact that there is "No Magic Here". For me, that was the greatest insight of learning how to write an OS: it is just another program. I really like how you highlight the fact that there is “No Magic Here”. For me, that was the greatest insight of learning how to write an OS: it is just another program.

]]>