D
Don Y
Guest
On 4/30/2023 1:48 PM, upsidedown@downunder.com wrote:
Intel made a development system (of sorts) called the MCS 4/40 -- along the
same lines as the MDS-800 (though much cruder). It was essentially an
SBC -- built on many cards! :> It supported a monitor that would
allow you to load/dump (BNPF) memory, edit it, as well as burn PROMs.
No disks (floppies) but you could support (external) PPT.
The 4004 was crude enough that one could \"hand-code\" applications
(with a \"pocket assembler\" :> )
With machines of this vintage, you approached development differently;
building complete images of a program was tedious so you wrote modules
and tied them together via jump tables (in each ROM device). This fit
neatly with the processor\'s page-constrained architecture (get a page
per ROM and \"link\" them manually through the jump tables)
Remember, an i4004 program was limited to 4K bytes of memory.
That\'s not really \"complex\" (though the details might be *tedious*)
The 8080/85 was probably the last generation where live symbolic
debugging wasn\'t really available. For the Z80 et al., the
processor could self-host tools with \"mass storage\". And, later,
3rd parties realized they could add a little hardware to an MPU
and let it act *as* an emulator:
- a couple of 256x8 bipolar RAMs for trigger logic
- more RAMs for a trace buffer
- buffers and addressing logic to allow these to overlay the \"target\"
[I had a uScope 820 which actually gave the illusion of being portable!
But, tools are shortlived when the technology is moving as fast as it
was!]
On Sun, 30 Apr 2023 03:02:34 -0700, Don Y
blockedofcourse@foo.invalid> wrote:
On 4/30/2023 1:54 AM, upsidedown@downunder.com wrote:
On Sat, 29 Apr 2023 08:15:25 -0700, Don Y
blockedofcourse@foo.invalid> wrote:
On 4/29/2023 7:59 AM, Martin Brown wrote:
I recall someone who still coded 6502 by hand in hex long after assemblers were
available and routine. I could never understand why...
(sigh) I had an employer who routinely started arguments about whether
or not Z80 code should be expressed in (split-)octal or hex. I just
looked at him, bewildered, and said \"Is there something wrong with
SYMBOLIC??\"
8080/Z80 are essentially octal machines and as such very easy to
program in octal (or binary). I still do not understand why later
tools went into hexadecimal.In octal, there is only a few opcodes you
have to remember, the register numbering was straight forward.
Why should you have to remember something as banal as an opcode map?
That\'s like committing to memory the integrals of all the oddball
functions instead of just looking them up (or, letting a symbolic
tool do that on your behalf).
Early 4 and 8 bitters had so little memory, so there was no way of
running a native assembler and even less a compiler. Later on with
Intellec/Excorciser it became possible to run them natively.
Intel made a development system (of sorts) called the MCS 4/40 -- along the
same lines as the MDS-800 (though much cruder). It was essentially an
SBC -- built on many cards! :> It supported a monitor that would
allow you to load/dump (BNPF) memory, edit it, as well as burn PROMs.
No disks (floppies) but you could support (external) PPT.
Until then you had to run some sort of cross-assemblers on a mainframe
or minicomputer. The licence could be quite expensive, assuming all
terminal is running the same assembler simultaneously. In some cases a
specific crossassembler was not available or could not be used e.g.
due to export regulations. I have written several crossassemblers for
various (some of which quite exotic)targets running on a mimicomputer.
The 4004 was crude enough that one could \"hand-code\" applications
(with a \"pocket assembler\" :> )
With machines of this vintage, you approached development differently;
building complete images of a program was tedious so you wrote modules
and tied them together via jump tables (in each ROM device). This fit
neatly with the processor\'s page-constrained architecture (get a page
per ROM and \"link\" them manually through the jump tables)
Remember, an i4004 program was limited to 4K bytes of memory.
That\'s not really \"complex\" (though the details might be *tedious*)
Why would you *want* to write code in ANY numeric form?
Why would you want to *recognize* opcodes in numeric form?
There were tools available that let you use symbolic instructions
and would display dumps as such.
The 8080/85 was probably the last generation where live symbolic
debugging wasn\'t really available. For the Z80 et al., the
processor could self-host tools with \"mass storage\". And, later,
3rd parties realized they could add a little hardware to an MPU
and let it act *as* an emulator:
- a couple of 256x8 bipolar RAMs for trigger logic
- more RAMs for a trace buffer
- buffers and addressing logic to allow these to overlay the \"target\"
[I had a uScope 820 which actually gave the illusion of being portable!
But, tools are shortlived when the technology is moving as fast as it
was!]