Re: about the plus4

From: Ethan Dicks <>
Date: Thu, 19 Apr 2012 18:29:13 -0400
Message-ID: <>
On Thu, Apr 19, 2012 at 6:17 PM,  <> 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.


       Message was sent through the cbm-hackers mailing list
Received on 2012-04-19 23:00:25

Archive generated by hypermail 2.2.0.