News: 11 March 2016 - Forum Rules, Mobile Version
Current Moderators - DarkSol, KingMike, MathOnNapkins, Azkadellia

Author Topic: How were early 8 and 16-bit games programmed?  (Read 3544 times)

pianohombre

  • Full Member
  • ***
  • Posts: 224
    • View Profile
    • My personal website of short stories and comics
Re: How were early 8 and 16-bit games programmed?
« Reply #40 on: November 26, 2017, 07:34:18 pm »
Done at least by 2013
https://www.youtube.com/watch?v=Mr7U9pQtwq8

Off-topic yes, but seemingly 100x more important than 8-bit and 16-bit videogames. That Baxter robot took over 1 minute for just 1 t-shirt. For the average load of laundry that would take 30 minutes for a triple load. Hardly efficient, and you would need to lay out each article in front of the robot. It would be more tedious than just folding it yourself. I was talking about a separate machine, where you could dump in your entire basket and it would spit out folded clothes in 10-15 minutes total for the entire load. I have been following the news on such devices, and there is one in development, that is supposed to be the ideal laundry-folding machine, that is supposed to hit limited markets in 2018-19, at a ridiculously overpriced price of $700.

Edit: The machine is called a Foldimate, and set to launch in 42 days (according to their website). At $7-800 I'd expect there to be maybe one per 10,000 people, meaning most laundromats won't purchase one for at least 10 years. I've never seen a chain of laundromats. Perhaps if there was a successful laundry corporate office I'd get to use one in every 100-mile radius. The thing is the size of a refrigerator.
« Last Edit: November 26, 2017, 09:28:28 pm by pianohombre »
One small step for man,
one giant leap for mankind. -Neil Armstrong

jonk

  • Sr. Member
  • ****
  • Posts: 259
    • View Profile
Re: How were early 8 and 16-bit games programmed?
« Reply #41 on: November 26, 2017, 08:33:22 pm »
I find this hard to believe. Not the computer built from tin-foil, and recycled jock straps of dead football players, but that you were able to build a multi-threaded OS in less than 2 days. How many years has Torvalds worked on the kernel for Linux? Maybe that bare-bones OS I've seen that could still fit on a floppy disk (I don't recall the name), but it had issues with plug N play Wi-Fi connection.
I took a morning flight and arrived fairly early to work on Monday, that day. I had a hotel, but really nothing much to do so I spent relatively long hours that day at work. The following day started early and it wasn't until late afternoon before I was done. So it was close to 20 hours of work. Give or take.

I've had a lot of experience doing O/S work. My first operating system project was the HP2000F timesharing system (I still have the listings sitting here next to me about 5' away!) In 1975, I wrote and added a new assembler tool (it didn't support timeshared assembly, only BASIC) and linker tool so that I could code and run assembly for the machine as a time-shared user. I also learned C and worked on Unix v6 kernel in 1978; worked to extend DOS in the early to mid 1980's, developed an operating system for a stand-alone MIPS R2000 processor board in 1987; worked on BSD386 in the late 1980's; and I've been doing O/S work pretty much all of my life for various embedded instrumentation, much of which actually needs multi-threading. I've also been employed doing chipset work as an Intel employee.

The above project was in the late 1990's, so I'd had decades of regular, routine experience with operating systems by then.

One of the projects I did in the early to mid 1990's was medical instrumentation for helping doctors determine when they'd unplugged an artery during an operation. If you have any idea about some of the software requirements for critical medical instrumentation, you will know that EVERY SINGLE LINE of code must be proven through testing. This includes ALL library code and ALL operating system code. Which pretty much means you cannot use off-the-shelf libraries or operating systems of ANY KIND. You must own and write every single line of code for that piece of equipment so that you can see and then validate every single branch edge (if statement) and line. You must have 100% coverage, and no exceptions. Most folks aren't involved at this level of detail in this kind of work.

In this case, though, the relatively simple project also used an x86 core and the Microsoft C compiler, both of which I knew quite well by then. I didn't need full processes, just threads. Pre-emption of the libraries (which weren't all designed for pre-emption) would have been difficult, so I simply arranged to trigger process switching at "convenient" times to avoid that problem. So this is actually quite easy to write. I needed only three queues, operated as a circular buffer: a run/ready queue, a sleep queue, and an available queue (where new threads were created.) The hardware, other than the Intel CPU was merely the Intel 8253/8254 timer and the Intel 8259 PIC. I think I had to write a serial port driver, as well. Probably a 16550, memory serving.

I've been coding x86 assembly code for almost two decades by then, as well as having worked at Intel doing chipset testing and validation, so mixing assembly and C was no trouble at all.

I'd be happy to look for and try to post up the essential parts of the code. I think I may still have it laying on a disk somewhere. I think most people could read it reasonably well. It's not complex. And if you saw the source code, you'd probably see how it could have been typed in as quickly as I said. This was one of those cases where I didn't have to sit down and design. I just needed to code fast and then validate the results. That's all. This is not a Linux system.

By the way, I've also worked with Douglas Comer (XINU.) So as I said, long experiences with O/S coding. Seriously, two days is what I allocate for myself if I'm just doing a simple XINU style O/S. If you haven't read the original "red" book of Dr. Comer's, then you've never had a chance to see just how simple and easy all this can be. Tannenbaum's O/S books are a nightmare, by comparison.

Oh. I suppose it might do to tell you that I taught a class called "Operating Systems and Concurrent Programmming" as a 3rd year course at the largest university in my state, where I worked as an adjunct professor also teaching three other classes (class sizes of about 75 students each, back then.)

I have some modest experience in the area.

I think I've heard of M-theory in the past, yet I don't remember the premise. Does it have anything to do with 8-bit and 16-bit programming? Can a star cluster fit into an Atari, or does Galaga count? Yes, apparently computers have to do with physics, and math, and engineering, and art unfortunately. How useful are modern computers anyways? (Let me know when they make an affordable machine that will fold your laundry after it dries).
Dr. Sirag is my contact on this topic. And while I do find some interesting parallels between error-checking and correction techniques used in computers (ECC) -- Hamming distance, Hamiltonian hypercube walks, and packing spheres -- M-Theory is mostly just a hobby interest of mine because I happen to like mathematics. He started me with Coxeter's "Polytropes" and Gilmore's "Lie Groups and Algebras" as a segue.

None of this has much to do with Atari, as I'm sure you know.

« Last Edit: November 26, 2017, 08:57:07 pm by jonk »
An equal right to an opinion isn't a right to an equal opinion. -- 1995, me
Saying religion is the source of morality is like saying a squirrel is the source of acorns.  -- 2002, me

pianohombre

  • Full Member
  • ***
  • Posts: 224
    • View Profile
    • My personal website of short stories and comics
Re: How were early 8 and 16-bit games programmed?
« Reply #42 on: November 27, 2017, 05:29:31 pm »
Hi jonk,
It's good that someone with your experience is on this website. Appreciate your feedback on these comments. I have only briefly programmed threads, pipes, and processes for an upper-level GE course, but have never been able to implement it in my code. Even many of the things we learned about classes (in C++) seemed more like fancy kick-flips, and tricks, when it was easier to do an ollie. I'm just saying it seemed like a complicated way to do something when there was an easier way, that made more sense and was simpler (I'm talking about extends, operator overloading, try/catch, linked lists, and abstract structs).
One small step for man,
one giant leap for mankind. -Neil Armstrong

FAST6191

  • Hero Member
  • *****
  • Posts: 2219
    • View Profile
Re: How were early 8 and 16-bit games programmed?
« Reply #43 on: November 27, 2017, 07:33:19 pm »
I have met several times now parts of education in general, though computing is current main case for it, where people are taught things not because they have to use them but because it enables their actual work to be better. Normally we see it in things like teaching people assembly and hopefully then causing them to get a better grasp of types, why calling function within a function is not ideal, to truly grasp pointers if they are a thing, back on types then why you might want to limit sizes and not make everything a float.... You may have experienced the same thing.

"a complicated way to do something when there was an easier way"
You may have received poor instruction or suffered poor course design. In this case they probably did the here is the concept, here is a simplistic implementation (possibly using some maths as it is nice and clear) and neglected the "here is the real world example where it makes your life 50 times easier" part. Think the occasion where you might have all had to code something and did fine, however you failed to build in any great level of extensibility and then when the instructor said "great, now do it for this 500 times bigger data set, and also do this extra thing".

jonk

  • Sr. Member
  • ****
  • Posts: 259
    • View Profile
Re: How were early 8 and 16-bit games programmed?
« Reply #44 on: November 28, 2017, 02:33:29 am »
It's good that someone with your experience is on this website. Appreciate your feedback on these comments. I have only briefly programmed threads, pipes, and processes for an upper-level GE course, but have never been able to implement it in my code. Even many of the things we learned about classes (in C++) seemed more like fancy kick-flips, and tricks, when it was easier to do an ollie. I'm just saying it seemed like a complicated way to do something when there was an easier way, that made more sense and was simpler (I'm talking about extends, operator overloading, try/catch, linked lists, and abstract structs).
I use threads almost entirely because they greatly improve the readability and maintainability of the source code over the long term AND because they provide methods that one actually NEEDS for robust, well-performing code. They are decidedly NOT complicated. They do not need to use complex structures, even. Nothing more than simple, fixed-sized arrays of integers is enough. One can use two arrays no more complicated than N[MAXTHREAD] and P[MAXTHREAD] as the 'previous' and 'next' pointers, for example. Fixed size arrays, no heap involved, no malloc() or free() needed. Seriously. This is dead easy stuff.

Let me relate a genuine story to make the point.

I was hired as a consultant for a company making instrumentation. They had exactly one programmer in their 20-person company, named "Bill." (I was hired in 1988.) Bill had managed to write all of the source code for an instrument they were selling, but his code was getting too complex for him to maintain and continue to improve as time went on. I was hired to write the PID controller software as an added feature to his code. But, once I was digging into his source code I realized that he'd done EVERYTHING without any threads, at all. It was all just 'big loops' of code, effectively just main() running around calling functions, plus some timer code.

A lot of his code did a bunch of math, table lookups, ADC reading, DAC writing, etc. And there was a lot of floating point code and library use. Since this was a 4MHz 8088 processor without an FP unit, it was quite slow. In order to monitor the user keypad, he had to poll it a lot. But his math wasn't done by the time he needed to re-poll the keypad, so he "salted" calls to the polling routine here and there and everywhere. Over time, as his other code grew, so also did he then find that the keypad was "non-responsive" at times, too. And so then he would ferret out where to salt in some more calls to the polling code to fix that problem. This was a never-ending process. He would change the main code doing the main work, adding more cpu processing, and ruining the keypad polling timing in the process. Then he'd fix that by packing in more calls to the polling code, etc. In an endless loop of creating and then hunting down problems just so the keypad would work right.

His keypad polling routine also had to deal with "shift" keys. So it had various states. Each time it was called to poll the keypad, it also had to remember where in all of its IF statements it was last at, the last time it was called, so that it could pick up where it left off. By the time I saw this code, it was ... very large, very ugly, and very hard to maintain, as well.

Interrupt handling was a possibility for this, but even so this would not fix the ugly code that had to handle the last known state of the scanning. So the interrupt code (which was already being used for other purposes) would soon acquire all of the terrible and ugly code that he'd developed for the keypad scanning.

Bill had NEVER programmed code to create threading before. So I sat down with him and spent one day explaining to him how to achieve it (and then went back the next day to working on my PID code.) That next day, in the afternoon, Bill came running into my office and told me that he'd "done it." It was working!! Bill, with zero experience to draw on and only my teaching him for a day, had sat down and written his own code to do cooperating threading and was fast on his way to fixing the problems in his code.

The cool thing about having a thread is that its state is retained when it switches away. It has its own stack. So, after polling the keypad and, perhaps, discovering a "shift" key had been hit, the code inside the IF statement that found this could simply "switch away" by calling switch() and give up its time. When the task switching code returned, it would return from the switch() call, returning exactly where it was with all the local variable state intact.

This shrunk the code down and made it very, very much more understandable and maintainable. It removed a lot of random boilerplate code that had been salted all over the place before. Etc.

The point here is that you want threads because they make your code EASY TO READ, EASY TO UNDERSTAND, EASY TO MAINTAIN, and they do NOT add any excess burdens. The only thing you need is a little RAM for the stack space and a tiny array to keep the last stack pointer for each thread. The switch() function itself is perhaps a dozen lines of assembly code. The whole thing takes almost no time at all to write and it "just works."

In my case, the O/S I'd mentioned earlier was 10 years later than this story above and had to be more complicated as it was destined to run a FAB process for making ICs. So it took me perhaps 20 hours of experienced effort. But it also just worked, supported thread messaging and per-thread exception handling, as well. Written in a mix of C and assembly in a small number of hours. Time that paid for itself over and over and over again as I continued writing the final application code to operate the FAB processes.

I think those people who LACK the familiarity and comfort in just "writing an O/S" on the fly, when needed, have a serious hole in their skill sets. At least, for embedded work. It's just too important a skill to have. Suppose someone facing the problem of sorting an array of numbers only knew how to attack the problem with a big subroutine with IF statements and no ability to use or understand LOOP constructs? Sure, to sort 100 numbers they could hard-code 100's of IF statements to achieve it. But it would be a horrible waste of effort and very hard to maintain, or extend if the need arose.

Sure, you can write a lot of useful code without being able to rapidly code up a thread-based system to simplify the problems ahead. But why go there? The code winds up being a horrible waste of extra effect, is very hard to maintain, and very difficult to extend when the needs arise. Being able to do so, means the rest of the code is maintainable, extensible, and easy to read and understand. It's night and day. Just as would be the case between that cumbersome sort routine by someone who didn't know how to use looping to help out vs someone who could. And writing a multithread O/S isn't hard to do. So it's just ALWAYS better to have the skill in your toolbox and pull it out when the problems reach the point where it makes sense (which is almost always, if the application is non-trivial.)

There are times where this is "more difficult." For example, the Microchip PIC16C54 has exactly four memory locations for storing the return address of a function call. And these stored return addresses cannot be read out by code. They also have 25 bytes of RAM, total. So this does complicate the idea of a multi-threaded system. It's not impossible. But it's almost never worth the benefits in a CPU this constrained for memory and lack of access to the return address stack. But for the 6502 or 65816 or 8080/8085 or even the 8051, it's quite doable. And easily done. (I just completed, a few years ago, a project written for the 8051 core (the SiLabs C8051F061 chip) where I implemented and used a multi-threaded O/S. That system took in 16-bit ADC data at a full 1 MHz rate, processed it, and generated accurate measurements with precision timing. And the code was far more maintainable because of the few days I spent implementing a small O/S on it.

What saddens me a bit is that anyone considers it hard to do. Because that means they will go to the ends of the Earth not to do it and will use all manner of ugly and hard to maintain code to "get by" without access to the sheer beauty that having multiple threads offers.

Again, to any and all, go get Douglas Comer's first XINU book: "Operating System Design: The Xinu Approach" dated 1984. NOT the 2nd edition, either. The 1st edition. There is a much later LinkSys version which I also enjoyed reading but he leaves out some very important ideas those decades later on. The first edition is the one to start with. It's very very easy to read and understand and provides exactly the kind of simple walk through someone would want when first learning to do a simple O/S. Nothing better!
« Last Edit: November 28, 2017, 02:46:21 am by jonk »
An equal right to an opinion isn't a right to an equal opinion. -- 1995, me
Saying religion is the source of morality is like saying a squirrel is the source of acorns.  -- 2002, me

FAST6191

  • Hero Member
  • *****
  • Posts: 2219
    • View Profile
Re: How were early 8 and 16-bit games programmed?
« Reply #45 on: November 28, 2017, 03:42:52 am »
"to re-poll the keypad, so he "salted" calls to the polling routine here and there and everywhere. Over time, as his other code grew, so also did he then find that the keypad was "non-responsive" at times, too"
and then we have the therac 25
http://courses.cs.vt.edu/professionalism/Therac_25/Therac_1.html

Jorpho

  • Hero Member
  • *****
  • Posts: 3707
  • The cat screams with the voice of a man.
    • View Profile
Re: How were early 8 and 16-bit games programmed?
« Reply #46 on: November 28, 2017, 09:27:24 am »
but that you were able to build a multi-threaded OS in less than 2 days.
That was standard business for computer science students learning about operating systems back when I was in university around twenty years ago.  (Not that I was CS student; I just talked with them.)

Quote
How many years has Torvalds worked on the kernel for Linux?
Linux changes with the times and with the introduction of new features for new hardware.  That's hardly relevant.

Quote
Maybe that bare-bones OS I've seen that could still fit on a floppy disk (I don't recall the name), but it had issues with plug N play Wi-Fi connection.
The QNX Demo floppy comes to mind, though I'm sure similar feats have been accomplished.  (I've seen a rather dysfunctional Windows 3.x install that fit on a floppy.)  It's not easy dealing with the huge variety of wifi hardware out there, especially since so many wifi adapters have closed-source proprietary drivers.
This depresses me. I feel like a goldfish right now...

jonk

  • Sr. Member
  • ****
  • Posts: 259
    • View Profile
Re: How were early 8 and 16-bit games programmed?
« Reply #47 on: November 28, 2017, 03:36:32 pm »
and then we have the therac 25
http://courses.cs.vt.edu/professionalism/Therac_25/Therac_1.html
From your link, it appears to say that their fault tree analysis had made the following points:
  • Programming errors have been reduced by extensive testing on a hardware simulator and under field conditions on teletherapy units. Any residual software errors are not included in the analysis.
  • Program software does not degrade due to wear, fatigue, or reproduction process.
  • Computer execution errors are caused by faulty hardware components and by "soft" (random) errors induced by alpha particles and electromagnetic noise.
The problem with (1) is obvious. "Extensive testing" doesn't mean anything, unless it is quantitatively specified (as it is, these days, in critical medical equipment rules.) It's just a silly phrase, otherwise. "Field conditions" also doesn't mean anything, for similar reasons. And I don't have any real clue about what "residual software errors" means. But somehow it doesn't sound encouraging the way that's phrased.

(2) is wrong. I can't count the number of times that I've seen errors in copying software into ROMs. Also, all re-writable memory has threshold problems. It's possible to write a "weak 0" that reads correctly for a week or two, but then flips to a "weak 1" later and stays there, getting stronger over time. I've seen that happen, too. I always include code designed to detect these cases at startup, including code that is designed to detect when the detection code itself fails to properly execute. I also include code to test the CPU, its RAM, and so on. In one case, circa 1992, we received a shipment of ADSP-2111 processors from Analog Devices where 50% of them failed my testing. We'd been receiving and using them for years. But this shipment failed my test code, demonstrating that there was a CPU problem. Analog Devices demanded my code, wrote back admitting the failure, and explained it was due to the fact that they had moved manufacturing to a different FAB. 5 weeks later we got a replacement shipment and the parts worked.

(3) Execution errors can occur because of stack and heap collisions, code generation errors in the compilers that cannot be seen in the source code, and other reasons. But it's not limited to hardware and other "soft" errors such as cosmic rays. By the way, I was involved in working on O/S code designed for operation on a satellite and where one of the requirements is that it detect and immediately correct for a cosmic ray event that might, for example, change the program counter at random! I won't go into the details involved, here. But do you (collective you) have any idea what is involved in writing an O/S that is robust against random PC-change events? Or random register value changes? It's a serious pain to even consider detection, let alone correction and recovery.

In the medical equipment I worked on, which was 10 years later, I was required to create all the needed conditions in testing to provably exercise each and every single line of code I wrote. There could not be any conditional code present that didn't have a purpose and couldn't be triggered by the right combination of events. And I had to demonstrate that those combinations of events could occur and that the code would be executed when they did. This actually meant I could not consider the use of any commercial O/S, any specialized O/S, etc., for which I didn't have complete access to all of the source code AND ALSO for which I was willing to create all of the necessary conditions to demonstrate the execution of every single line of O/S code present there.

In addition, I validated every single individual subroutine by feeding it every possible input parameter value. For example, I had to write a logarithm function (this was on an ADSP-2111 processor.) I had to supply every possible input value, generate every possible output value from that, and demonstrate the monotonicity of the behavior, as well as the worst case deviation from known accurate results. And that was just one function.

This meant that there was not a single line of code, not a single function of any kind, that I didn't actually need. The cost of just hauling in a library package or hauling in an O/S was way too expensive, in terms of testing requirements not to mention the paperwork.

I'm not saying that these processes make software provably safe to use. They don't. But they help move in the right direction. In the above case, that medical equipment has been in use for 20 years now and there have been no faults traced to the software I wrote. And the mandated procedures  surrounding these devices require tracing problems to their root causes, with complete documentation demonstrating that the cause was in fact identified, is supported by and supports all of the known facts in the situation, and has been corrected. I have a separate bit of software involved in calibrating medical infusion pumps, which had slightly different software development requirements. But there also have been no traceable problems found in that software, either. So I think when the right combination of procedures are followed, it's possible to field relatively robust software.

My son is working on the Game Boy Advanced version of Dungeons & Dragons: Eye of the Beholder (which came out later and was written by a small 3-member team back in the early 2000's -- no longer in business.) It's filled with an almost unlimited number of bugs and flaws. For example, the ability values of enemies are kept in ROM. Any permanent damage spell (like "poison") doesn't work in the game, because although the software attempts to write to ROM, it can't actually change the values. So the result is "no effect." Regarding "poison" on a character in the game, it works just fine since it's in RAM. And, because the subroutine used doesn't even look at the basic stats of a character when "lesser healing" is applied, even though it's supposed to, the use of "lesser healing" cannot restore the damage done by "poison" on your character. There is only one way to fix it, and that's to visit a "full healer" NPC because the subroutine invoked then actually does look at the basic character stats and restore from those values. This is only scratching the surface of the idiotic errors in this game. I've almost been curled up in a ball laughing at times as Lee lays out bug after bug he's been finding in this code. The manual also describes things that are not in the actual game, at all, and doesn't describe things that are in the game. And what it describes, it often gets wrong, anyway. It's hilarious just how badly things can go awry and I can't understand how anyone could have released this as it is. But they did.
An equal right to an opinion isn't a right to an equal opinion. -- 1995, me
Saying religion is the source of morality is like saying a squirrel is the source of acorns.  -- 2002, me

FAST6191

  • Hero Member
  • *****
  • Posts: 2219
    • View Profile
Re: How were early 8 and 16-bit games programmed?
« Reply #48 on: November 28, 2017, 04:40:32 pm »
Wow, I was not expecting a breakdown. It was more the input polling thing reminded me of the times I sat there tapping things in while waiting for a buffer or thread handler to catch up, and that was the ultimate failure of that sort of thing (those exacerbated by lack of a lot of other things).

ECC (not the crypto) was something I looked into at a few points, more for security than some kind of fault tolerance and/or high availability. It is when the finance types want that but also real time that it gets really fun.

I have had to think in the medical style way you describe -- having your $100K CNC crash and both ruin an expensive part (probably one in the finishing stages too) and hold up your process because no sanity checks or a variable sent the wrong way would not endear you. Fortunately gcode ( http://reprap.org/wiki/G-code ) is not so bad when all is said and done.

Don't think I have looked at that GBA game. Though anything that is not Infinity Engine (gate, dale, planescape..) or Dark Alliance I tend to dismiss as at best a buggy mess, and with D&D not being a thing I ever really paid attention to I don't tend to delve into them. That said that sounds like a special case of screw up, though if it started life as a DOS/amiga affair I can see a path to that (I would have thought they would have gone in for a port of the SNES edition but who knows). That said I am going to have to go have a look at the Sega CD version as apparently Yuzo Koshiro (Streets of Rage) did the soundtrack for that one.

pianohombre

  • Full Member
  • ***
  • Posts: 224
    • View Profile
    • My personal website of short stories and comics
Re: How were early 8 and 16-bit games programmed?
« Reply #49 on: November 28, 2017, 05:58:00 pm »
Jorpho, the OS I was talking about is KolibriOS (also coincidentally the name of the smallest gun in the world).

Yes, loops versus if statements. I remember the Big O(n) graph. If statements execute 1:1. Loops execute 1:n, and embedded loops are the slowest (though this is cleaned up by recursion).

We had to write sorting functions from scratch using data structures filled up with random values. Then write the sorting functions using recursion. We tested several types quicksort, bubble sort, and a couple others. I'd have to review heap I don't remember what it is off the top of my head. But our classes were full to the brim of students, no tutors around, the textbooks had errors. This wasn't easy stuff to learn. I wrote down the name of that book. I'll try and take a look at it since I'm working on a program that uses C++, and might benefit from threads and pipes.
One small step for man,
one giant leap for mankind. -Neil Armstrong

jonk

  • Sr. Member
  • ****
  • Posts: 259
    • View Profile
Re: How were early 8 and 16-bit games programmed?
« Reply #50 on: November 28, 2017, 09:57:58 pm »
But our classes were full to the brim of students, no tutors around, the textbooks had errors. This wasn't easy stuff to learn.
When I taught, I kept office hours and the students also had tutors available for other times. But students can also form into study groups. So that might be a way to compensate for otherwise bad textbooks and poor access to tutors and teachers.

Sorry to hear that happened to you, though.

I wrote down the name of that book. I'll try and take a look at it since I'm working on a program that uses C++, and might benefit from threads and pipes.
Douglas Comer's first edition stands apart from everything else I've ever read, as far as helping to ease someone into writing their own O/S or else understanding the basics, well. Nothing comes close. It also introduces some very important ideas that are quite useful.

The two things that taught me something completely new was memory marking and his method for designing a sleep queue using his delta queue technique. Beautiful ideas. In fact, it was my writing to him about these two ideas that first put me into contact with him. It turns out that these two ideas were his "big research ideas" that he felt he'd contributed and he was very much surprised by the fact that the two things I picked out of his book as being special to me also happened to be the two things he'd personally invented. Started us on a nice conversation over time.

But don't worry about those two things. They are just details I enjoyed as I read that book back in 1984. But I was experienced, too, so took note of them. For you, it's the elegant progression of the book from simple ideas to make something interesting in the end. It's truly easy to read.

Sadly, his later books become more burdened down with stuff people wanted to add and by the time the LinkSys edition came out, there wasn't even a single mention of memory marking. However, if you downloaded the source code, you'd see it there. But I considered this a sad loss. His response to me in 2014 was, "I wanted to get the Linksys edition out the door quickly, and decided I didn't have time to include it." Which is partly why I am NOT recommending that you consider getting any of his editions except the first.

If you have questions about the book as you read it, please feel free to ask. It could either be a letter to me or else just a new programming question here that others could read and comment about. Your call. I'm just an occasional guest here, so to speak, and don't really know the better way to go for something like this.

Best wishes!
An equal right to an opinion isn't a right to an equal opinion. -- 1995, me
Saying religion is the source of morality is like saying a squirrel is the source of acorns.  -- 2002, me

pianohombre

  • Full Member
  • ***
  • Posts: 224
    • View Profile
    • My personal website of short stories and comics
Re: How were early 8 and 16-bit games programmed?
« Reply #51 on: December 19, 2017, 06:24:12 pm »
Well, it looks like Comer's books are reviewed better than Tannenbaum's, when I searched online. I also found an article on polytopes, so I don't necessarily have to buy the book to learn about this odd concept of polygons. There is even an Ebook version, of Operating System Designs, that is less expensive than the print edition.
One small step for man,
one giant leap for mankind. -Neil Armstrong

jonk

  • Sr. Member
  • ****
  • Posts: 259
    • View Profile
Re: How were early 8 and 16-bit games programmed?
« Reply #52 on: December 20, 2017, 04:44:45 am »
Well, it looks like Comer's books are reviewed better than Tannenbaum's, when I searched online. I also found an article on polytopes, so I don't necessarily have to buy the book to learn about this odd concept of polygons. There is even an Ebook version, of Operating System Designs, that is less expensive than the print edition.
Hopefully, it was polytropes, not polytopes!!
An equal right to an opinion isn't a right to an equal opinion. -- 1995, me
Saying religion is the source of morality is like saying a squirrel is the source of acorns.  -- 2002, me

Squall_FF8

  • Jr. Member
  • **
  • Posts: 60
    • View Profile
Re: How were early 8 and 16-bit games programmed?
« Reply #53 on: December 30, 2017, 12:40:33 pm »
Most guides say they were written in Assembly, ... I really find it hard to believe every game in the 80's and 90's was created by scratch, in ASM

Why is that? It sounds like writing in ASM is a nightmare?

I started right in the middle of the said period - around 1989, no net, no books, just a manual that came with the newly bought computer Pravetz 8D (it is a clone of Oric Atmos, with 6502 processor) costing 2 monthly salaries to my parents at that time. At school I had access to clone of Apple II (e or +). Luckily for me both had 6502 as CPU. There were zillion of titles for Apple II and just few for Oric, mainly in French.

I got extremely lucky, because there was a macro-assembler (recently converted from Apple to Oric). That is when the universe opened for me - it was much easier to code for that macro-assembler, rather build in BASIC - defining labels, local labels, macros,... if you ever used macro-assembler you know what I'm talking about - its almost like coding in higher level (C or Pascal). I could use .include so I could organize the code I have previously experiment with to library for easy reuse.
In a just few months with the extreme limited access to other people's work I was able to make graphic editor similar to the one for Apple II (considered the Photoshop at that time for Apple). I was able to make music player, editor, that could use Apple music format of 2 channels (I forgot the name). I was able to use Apple vector graphic format (forgot the name) and display it in Oric (and later integrate it in the graphic editor).

Even to this day I consider as a jewel in a crown a game that I wrote from scratch ... it was copy of a my fav game on arcades - you have a car that jumps, paints the road, catch balloons to go on next stage, ... (sorry even till today I don't know the name of that game).

In short - a young 16 year boy, born in ex-communist country, 0 access to the world, 0 access to computer books, no IT education. Just a home-target computer and a macro-assembler. To make a whole game from a scratch (to reproduce what he plays on arcade). If I could that in these extreme conditions, how much easier should be for people that have studied, have access to what is considered top-notch software and computers, have years of experience???

Jorpho

  • Hero Member
  • *****
  • Posts: 3707
  • The cat screams with the voice of a man.
    • View Profile
Re: How were early 8 and 16-bit games programmed?
« Reply #54 on: December 30, 2017, 01:23:12 pm »
Even to this day I consider as a jewel in a crown a game that I wrote from scratch ... it was copy of a my fav game on arcades - you have a car that jumps, paints the road, catch balloons to go on next stage, ... (sorry even till today I don't know the name of that game).
I can't resist: Bump 'n' Jump?  City Connection?
This depresses me. I feel like a goldfish right now...

Squall_FF8

  • Jr. Member
  • **
  • Posts: 60
    • View Profile
Re: How were early 8 and 16-bit games programmed?
« Reply #55 on: January 02, 2018, 03:49:31 pm »
I can't resist: Bump 'n' Jump?  City Connection?
OMG the game is City Connection. Jorpho THANK YOU VERY MUCH!!!!
I'm looking to find that name for ... at least 15 years, THANK YOU again!!!

   
O boy looking in that picture ... so many memories and emotions ...

pianohombre

  • Full Member
  • ***
  • Posts: 224
    • View Profile
    • My personal website of short stories and comics
Re: How were early 8 and 16-bit games programmed?
« Reply #56 on: January 18, 2018, 02:03:38 pm »
City Connection is definitely something special, Squall.
One small step for man,
one giant leap for mankind. -Neil Armstrong

Squall_FF8

  • Jr. Member
  • **
  • Posts: 60
    • View Profile
Re: How were early 8 and 16-bit games programmed?
« Reply #57 on: January 19, 2018, 07:05:38 am »
City Connection is definitely something special, Squall.
Very special indeed, pianohombre!

Our parents were giving money to eat at school. Instead we were spending all on arcades (mainly this one for me). Eventually the money thrown there paid off, because in the end I was able to play for 2-3 hours for a just a single coin. There were many kids that liked the game but they were able to play just a minute or two for a coin. So it became a trend - he will use a coin, I will drive, he will shoot. With some we made a good team, while others were just shooting all the oil cans :D Well, it was win-win situation so nobody was complaining: Long play for them (we could play for probably an hour) and a free play for me  :happy: