If memory serves, the system clock on the TRS-80 Models 1 through 4 were software based, updated by regular CPU interrupts. That meant that long periods with disabled interrupts, such a writing to cassette tape or floppy disk, could cause the clock to run behind. Always gotta serve the clock; the story of modern life.
When programming, it's usually easier for me to think in terms of — and keep track of — the overall project, not subroutines. I hate having to constantly jump around source code chasing down subs, so my programs are often large, monolithic main functions. My subroutines tend to be small, simple afterthoughts added to clean up the main. They're usually called by main and return quickly there.
There's nothing wrong with a "blocking" subroutine which hangs the program briefly while waiting for something, as long as the wait does not frustrate the user or cause other problems, but...
In the world of interactive software, that fall-thru method can be thought of as a form of multitasking, a way of keeping the program moving forward and keeping the user distracted so that small delays don't become annoying.
Speaking of falling through: In a prior life I spent 10 years as a control technician. My primary job was programming HVAC controllers using a stripped-down version of Pascal which had no looping mechanisms, so every program was fall-thru. As a program ran it would access the current state of things by reading temp sensors, pressure sensors, etc, then make subtle adjustments to get closer to the program's desired targets (the "setpoints").
(That Pascal variant also had no arrays, which was a major pain in the keester on a couple occasions.)
That version of Pascal did have functions & procedures, which were almost never used. If a program became large enough to need subs, then the program was split up into two or more simple, single-purpose programs.
Coming as I did from a world of "normal" computer programs, with no prior HVAC experience, it was fun getting to know that system. The first assignment my boss gave me was to improve the program which ran the building's problematic cooling towers. The program I submitted was a monstrosity of conditionals testing for every possible good or bad state... something I learned was unnecessary on that system. That beast of a program worked as intended, but it turned out that the real problem was not a software issue, but a hardware one. Those control panels had been incorrectly wired since day one!
When programming, it's usually easier for me to think in terms of — and keep track of — the overall project, not subroutines. I hate having to constantly jump around source code chasing down subs, so my programs are often large, monolithic main functions. My subroutines tend to be small, simple afterthoughts added to clean up the main. They're usually called by main and return quickly there.
There's nothing wrong with a "blocking" subroutine which hangs the program briefly while waiting for something, as long as the wait does not frustrate the user or cause other problems, but...
In the world of interactive software, that fall-thru method can be thought of as a form of multitasking, a way of keeping the program moving forward and keeping the user distracted so that small delays don't become annoying.
Speaking of falling through: In a prior life I spent 10 years as a control technician. My primary job was programming HVAC controllers using a stripped-down version of Pascal which had no looping mechanisms, so every program was fall-thru. As a program ran it would access the current state of things by reading temp sensors, pressure sensors, etc, then make subtle adjustments to get closer to the program's desired targets (the "setpoints").
(That Pascal variant also had no arrays, which was a major pain in the keester on a couple occasions.)
That version of Pascal did have functions & procedures, which were almost never used. If a program became large enough to need subs, then the program was split up into two or more simple, single-purpose programs.
Coming as I did from a world of "normal" computer programs, with no prior HVAC experience, it was fun getting to know that system. The first assignment my boss gave me was to improve the program which ran the building's problematic cooling towers. The program I submitted was a monstrosity of conditionals testing for every possible good or bad state... something I learned was unnecessary on that system. That beast of a program worked as intended, but it turned out that the real problem was not a software issue, but a hardware one. Those control panels had been incorrectly wired since day one!