Krdytkyu

The earliest innovator I know of was Manx. Manx made 'C' programming environments for early, low-cost computers like Apple ][, CP/M-80, MS-DOS, and Motorola 68000.

Manx Aztec C v1.06 had symbolic (source code) debugging support when released in early 1984. Manx provided a utility "SIDSYM", which was used along with their linker's ability to generate symbol tables, to feed source code and symbols into SID. SID was a debugger from Digital Research for CP/M-80 that supported symbol tables. The Aztec C data sheet from 1983 mentions this feature.

The system above was still pretty primitive by modern standards. The "killer feature" was a source-code level debugger that hid most of the machine code details and allowed you to interact with your 'C' code as written, and access run-time variables easily, and set conditional and regular breakpoints with ease. This is the basic user experience we all expect today in Visual Studio, etc.

Manx continued to evolve the source debugging feature. By 1988, their 'C' compiler for the Amiga included a fully visual GUI source debugger that was probably the most advanced for any low-cost PC or home computer at the time. The MS-DOS versions of Aztec 'C' for the 8086 also supported source debugging at the same time, but with a less advanced UI. This feature is described in the manual available online. This was before Borland first shipped their initial version of Turbo Debugger for MS-DOS, as an add-on product to their compilers. Other 3rd parties also made symbolic debuggers for Turbo Pascal, but none that I know of offered as advanced a solution as Manx Aztec C at the time.

Needless to say, Source-level debugging was a "killer feature" for low-cost development environments by 1989. It was not long after that the major players like Borland and Microsoft would catch up and begin offering compilers with IDE's and integrated source debugging as we know today.

You can download Manx Aztec C for various retro computers from the Aztec Museum.

Microsoft Codeview shipped in 1985 and has most of the features you're asking about (its been a while so I can't be certain it has everything e.g. call stack walking), when I was doing Turbo C support for Borland in 87/88 support for it was possibly the most requested feature.

You could do source level stepping with Turbo C & symdeb but it wasn't as nice.
Version 2 of Turbo C had a debugger (shipped late '88?) which used the 386 hardware support.

Both of these had dual monitor support which was nice.

This is less of a definitive answer than a musing about some seemingly underlying assumptions within the question. For the question itself Supercat has already given a near perfect answer. While it is of the typical kind where everyone know it's wrong, it does tick all boxes. I seriously would love to give it double points :)

Different Computer Classes

The most obvious issue with the question may be that it separates different 'classes' of computers - and more important implies important advancements made by them in prior. While it is true, that mainframes implemented many solutions first, they where still tied to their repertoire of tools - like command line operation on terminals in next to all cases. And even within the mainframe world solutions weren't developed for the fun of it, but when needed. Much like with minis and micros in parallel or later.

For example the AID facility of BS2000 (a /370ish OS) did already support quite complex interactive debugging in the early 80s. But all based on very cryptic command line arguments.

Need for more comfortable (I would prefer that term over 'advanced, which is more of a marketing blurb) debuggers grew out for one of more capable systems and more complex software, but more important due changes in software development. This includes especially the need to dive into large chunks of code generated by less then well known tools (compilers), imported from libraries or worst of all, inherited form prior developers.

This development happened independent of machine type or 'class'.

Source Level Debugging

Already early microcomputer systems offered basic debuggers that did go past all hex handling of Hex-Kits. For example the original Apple II Monitor included convenient single-stepping and breakpoints with disassembling the instructions. And with the introduction of disk drives and Assemblers many additional tools came to hand, including source level debuggers. That's the 1978..1980 time frame. Eventually with the ORCA system as a first plateau supporting very convenient Assembly as well as Pascal and C - noteworthy here, that is wasn't until the mid 1980s that C became a professional supported choice on Apple II (or similar) systems.

In general it was not only missing need, but more so missing capabilities of the systems in use that prevented the use of more comfortable features. To access join binary and source code the later needed to be at least indexed, a feature the quite limited memory of these systems could, if at all, only support for extreme small programs. Even more so if the source code had to be displayed. Impossible without multiple disk drives.

Beside Assembly (and the all omnipotent BASIC) PASCAL was the only other choice. Here the UCSD system was eventually the best known - and it made a great case how to provide high level support on small machines. The p-code did include many references to the source/module structure already by default, and due its module structure parts of the system could be swapped in on demand.

It wasn't until affordable machines by default had a RAM size of 512 KiB or more and hard drives that more comfortable features as requests became possible for most programming environments.

Workstations are Anything But PCs

When comparing machines, that have been sold as 'workstations' at their time, with other available it becomes clear, that there is no basic difference to other machines of the same time -- except they usually represent an upper end configuration.

A Sinclair QL of 1984 used a 7.5 MHz 68008 with 128 KiB RAM and micro-drives, while a SUN 2/50 of the same year had a 10 MHz 68010 with 8 MiB RAM and (at least) one HD. The same point can be made for any other computer sold as Workstation - not to mention todays Gamer PCs that outclass what many manufacturers sell as workstation :)

Home Computers are Computers at Home

While this sounds nice at first, it's a classic post-hoc fallacy. After all, that would make any computer someone may have at home a "home computer". Of course including any mainframe, mini or workstation running zOS or Unix. It's obvious this won't work as a portable classification - most definitely as porting the same computer into an office would right away turn it into an office computer - wouldn't it?

The location a computer is set up can not retroactive define a class.

Conclusion

The question contains a lot on unnecessary constrictions and implied assumptions that are neither clear nor helpful at all, and at the same time an unclear definition what environment exactly is asked for.

It may be useful to drop these restrictions and clarify what kind of functions and their representation is asked for.

I'm including this answer in response to a couple of suggestions, although it does not meet some of the criteria laid out in the question. DDT for the DEC PDP-1 has to be recalled as probably the very first interactive debugger, and most interactive debuggers that came later were indirectly inspired by DDT. (see DDT Writeup).

DDT was built in late 1961 or early 1962 at MIT shortly after the arrival of the PDP-1 (serial number two). The author was Alan Kotok, who later went on to be the principal engineer of the DEC PDP-10, one of the main timesharing systems before the microcomputer made a single user machine economical.

DDT allowed the user to set a breakpoint, examine variables in several convenient formats, alter variables, disassemble instructions, and patch code. This allowed the human to make efficient use of the very scarce machine time available. Some of the features mentioned in the question are lacking, but DDT was very advanced for its timeframe. A more advanced version of DDT was later built for the PDP-6 and the PDP-10. The VAX debugger was probably inspired by these.

The PDP-1 (wikipedia) was probably the first commercial interactive computer intended as such. Even though only 53 were built, it had an enormous impact on later industries like video gaming (see Spacewar), Word Processing (see Expensive Typewriter), and even computer hacking (see Hackaday).

Steve Russell, author of Spacewar, later introduced a couple of prep school kids (Paul Allen and Bill Gates) to the PDP-10.

The PDP-1 computer predates the microchip, which made mainstream computing viable. But mainstream computers of the 1970s and beyond owe an enormous debt to the PDP-1. Without it, mainstream computing might have taken a very different path.

THINK Pascal had an integrated debugger that meets all your criteria. You could mark stop points in the editor and then debug your compiled code using them. The debugger supported stepping, a meaningful call stack display, and a good list of the variables as structured typed information.

The extremely popular BBC Micro (1981-1986, still in retro use today) had an exceptionally powerful debugger, "Beebmon" by Watford Electronics, capable of breakpoints, IRQ trapping, code stepping, and so on. From a summary:

BEEBMON

A ROM based machine code monitor for BBC Micro.
It enables machine code programs to be debugged
and altered easily and quickly. Being a ROM, its
commands are always readily available and occupy no
user memory. Appears to take no base page and only one page of relocatable workspace (256 bytes) and
no more anywhere in RAM. Beebmon can do more than any other machine code monitors currently on the market. The special features include facilities like: TABULATE, MODIFY, FILL, COPY, COMPARE,
SEARCH (HEX & ASCII) CHECKSUM,
DISASSEMBLE, RE-LOCATE and, by emulating the 6502 processor, SINGLE STEP, BREAK POINTS ON
READ/WRITE/EXECUTE OF LOCATION. Also BREAKPOINTS ON A, X & Y REGISTERS are provided .
HAS WINDOWS INTO MEMORY & TEST WINDOWS. All this and more...

I used this to trace IRQ handling in the OS and other ROMs, and to reimplement disk and keyboard handlers for software which required modified handling. I think it came out very early on, around 1982, and certainly by 1983 (according to the source).

Description source: Watford Electronics flier, 1983, on 4corn.co.uk