On Thu, Apr 19, 2012 at 6:17 PM, <firstname.lastname@example.org> wrote: >> With many other machines with their fancy BASIC, people got stuck with >> the BASIC. Thus, they never considered really learning about the inner >> parts of their machine. > > I second that with one exception. A built-in ML monitor definitely > wouldn't hurt. I started on a 4K PET down at the main library and a couple of years later, we got a 32K "upgrade BASIC" PET (3032 / 2001N). I knew about TIM, but didn't know (until I accidentally ran across it messing around) that TIM came in ROM on the newer machines. I typed in a lot of hex before buying a 2532 EPROM and getting someone at the local user group to burn a newer/better monitor on it. It used to be a necessity to be able to do at least rudimentary byte-level manipulation (load, save, alter) outside of BASIC. Apple had it, all PETs after the original 4K/8K PETs had it, and I was once again sad when it was removed from the C-64 (but I know there's a lot more stuff in the firmware than in the PET days, like the RS-232 routines). Even MS-DOS had it ("debug"), but most users only ever invoked it for jumping into a specific entry point of the hard disk ROMs to low-level format a disk. But having a low-level tool makes more sense when there's a fixed map of the machine. Starting with the Amiga, more recent OSes have gotten away from pegging strictures and entry points to specific versions of hardware and firmware and software. Now, you're likely as not do be doing process-level debugging, not machine-level debugging. That can be done within a running machine (unless you happen to be doing device driver work, then it's easy to crash the whole machine so badly that you won't be able to run an in-OS debugger). But back in the 8-bit world, yes, a ML monitor is more than a little useful. -ethan Message was sent through the cbm-hackers mailing listReceived on 2012-04-19 23:00:25
Archive generated by hypermail 2.2.0.