# Tanenbaum/Minix/Debugging



## ProphetOfDoom (Aug 11, 2022)

_View: https://youtu.be/86_BkFsb4eI_

Hi,
In this video the creator of Minix describes how, late into Minix’s development, the computer kept triggering interrupt 15 for no obvious reason. After trying everything else to debug the problem, the professor was forced _to write an x86 emulator _(no small feat) and run Minix on that, to find out what was wrong.
I won’t post any spoilers but this leads me to my question...
As a programmer, what do you do if, on Friday morning your product seems finished, and by Friday afternoon you’ve realised “oh heck, I need to write an x86 emulator (or something similarly taxing)!”
I find this kind of situation often comes up with code, certainly a lot more than with other art forms. Obviously it isn’t always a huge problem, but it might be if you have an employer and/or a deadline.
I’m curious because I’m a hobbyist and have never worked in the industry. Does anyone have any stories about this kind of scenario?
(Apologies if I don’t follow up on this post as I’m suffering from about a dozen illnesses currently, I will at least read any replies with interest...)


----------



## ccammack (Aug 12, 2022)

Nothing so complicated, but my team once added an unplanned instant-replay feature to a console game in order to track down a rare crash bug that we were unable to reproduce for several weeks. The code was simple: seed the random number generator with a known value at startup and then save a timestamp and the current controller state on each update out to a file. The next time someone on the team encountered the crash, we played their gameplay file back in the debugger and it immediately crashed in the same place. We got a lot of use out of that feature and eventually left it in the game as an _attract mode_ to show prerecorded gameplay behind the main menu.


----------



## Jose (Aug 12, 2022)

Excellent video, thanks! The only thing I have to contribute is having to teach myself the basics of parsers and parser generators in 20 hours to troubleshoot a customer problem. It was hard, but also very rewarding, and led me down super interesting rabbit holes like Ragel.


----------



## eternal_noob (Aug 12, 2022)

Nice thread, i like!

Last week i had to teach myself https://threejs.org/ within a day because we needed a 3d model viewer in our product asap. The ones readily available had several issues, so i wrote a cool one.


----------



## cy@ (Aug 12, 2022)

Geez. This reminds me of the good old days, putting in 16-18 hours a day programming. I was working on a JES/2 extension to MVS (IBM mainframe). This required running in key 0 supervisor state (kernel mode). But, this was a production environment. The company I worked for was too cheap to get another mainframe for development so we developed code, risky kernel code at that, on a production machine.

I was too afraid to crash the machine with my code. So I wrote a stripped down MVS kernel emulator with just enough calls to let me debug my code. (It was a dynamic file allocator in JES/2 which was easy enough to emulate in userspace.) It wasn't perfect as user code allocated memory from bottom up while the kernel allocated memory in the reverse direction -- I discovered an address arithmetic error that had the arguments reversed.

That company is defunct now. I still have the code in a directory on my FreeBSD laptop. Brings back fond memories of a younger me enjoying kernel programming on the IBM mainframe. I miss those days.


----------



## _al (Aug 12, 2022)

Computing conversations, Charles Severance, University of Michigan


----------



## ProphetOfDoom (Aug 12, 2022)

Thanks for the interesting replies!
ccammack that sounds like a nightmare bug. What kind of game was it? Game programming (2D) is one of my areas of interest, although I’ve not written anything beyond a simple asteroids clone (the physics was the hardest part and I had to saturate my brain in textbooks for several years before I truly understood it).
Jose wow, 20 hours?! Again this topic has required a lifetime of saturation for me... I was always an arty person at school not a science-y so absorbing something like parser-generators has really required me to go against my nature/temperament. I had not even heard of Ragel and it looks kinda intimidating TBH but I’m actually working on a similar project myself, however it compiles parsers to bytecode not a HLL.
eternal_noob thank you. That’s impressive, I’ve always shied away from 3D stuff but it’s something I have some (largely unread) books on, I should probably revisit them now I’m more knowledgable. It’s funny, I’ve learned that studying one technology can help you in a completely unrelated area further down the line. For example learning Haskell has helped my C programming, learning assembly has helped me with basically everything. Actually I have a great Latin textbook that claims Latin will help you with all other subjects by teaching you _how to think_. I don’t doubt it.
cy okay, those are god-level skills right there. I’ve never even tried to program in kernel space. I often wonder how people who work on embedded stuff for airliners etc., manage to sleep at night. I suppose they ask the plane to land first and then have a bash at it. 
Andrey Lanin interesting article. I think I have Tanenbaum’s book somewhere and on the last attempt managed about 50 pages lol.
This is all really interesting stuff and you guys all have the same areas of interest as me. This forum has such intelligent people!


----------



## Jose (Aug 13, 2022)

Oh, I didn't master it in 20 hours, far from it. I learned barely enough of the concepts and of the Bison syntax to be able to understand the file where I knew the problem lay. The bug was obvious once I had that basic understanding. It kindled an interest in parsers and state machines that lasts to this day. I stumbled onto Ragel a couple of years later, when I was trying to figure out what all the fuss about Ruby on Rails was about.


----------



## drhowarddrfine (Aug 13, 2022)

The things we used to do in the 70s and 80s. To this day I don't know how we found the time to do what we did but we did them.

Had a TRS80 computer that has to be interfaced to the only printer we had but I don't think that had a printer port. I hand wired the circuit board to an EEPROM circuit I built, somehow manually burned the EEPROM with code to do some translation, and wired that to a printer connector and it worked on the first try


----------



## Crivens (Aug 13, 2022)

We once upon a time had a hardware design that stopped working after about 1 million clock cycles. About, not exactly. No exceptions, no errors, just the CPU stopping instruction fetches somewhere in the boot ROM. At different places. Maybe I write about that one when I have time.


----------



## mer (Aug 13, 2022)

I had one of the original Macs, the beige ones with the 9inch b&w screen, 3.5 inch floppy and I think 128K of RAM.  Upgraded to 256 or something, had to open it up, which was cool because the molds had the signatures of the engineers that created the Mac and have fun with soldering irons.


----------



## Jose (Aug 13, 2022)

drhowarddrfine said:


> The things we used to do in the 70s and 80s. To this day I don't know how we found the time to do what we did but we did them.


There was no World Wide Web. We were bored all the time.



drhowarddrfine said:


> Had a TRS80 computer that has to be interfaced to the only printer we had but I don't think that had a printer port. I hand wired the circuit board to an EEPROM circuit I built, somehow manually burned the EEPROM with code to do some translation, and wired that to a printer connector and it worked on the first try


I was too chicken to try hardware stuff like this. The hardware was expensive, and my paper route money only went so far.


----------



## cy@ (Aug 13, 2022)

Jose said:


> There was no World Wide Web. We were bored all the time.


There was Gopher. It was a simpler time and, yes, more time to code and do productive things.



Jose said:


> I was too chicken to try hardware stuff like this. The hardware was expensive, and my paper route money only went so far.


Back in the day when I was 15 or 16 I had a paper route. What money I did make I spent at the university on their mainframe (there was no such thing as a personal computer then) writing and debugging programs. After a semester of learning how to code in COBOL in high school, I went on to teach myself FORTRAN, and IBM 360 Assembler that summer. Terminal access at the university was expensive so I used punched cards most but not all times instead. Terminal access was billed by the minute with CPU, I/Os and disk space used charged for. While small batch jobs using punched cards were a flat rate of 10 cents per job. That's where my paper route money went.


----------

