#"Unused" 8085 opcodes
2 messages in this thread
Gary, I'm a CIS newcomer, so if you sell an M100 Forth, it's news to me –
interested in knowing more!
Comment: before I lost interest, I was implementing a TIL for the M100. HL
was the "natural" choice for the data stack pointer, UNTIL I doped out the
mystery opcodes: DE is a much better choice if you use 'em (leaves HL free for
arithmetic, and the D9 & ED opcodes allow DE to be used as an indirect adr for
full-word load/stores of HL). It is, I admit, frightening to have such a BASIC
design decision dependent on presumably unsupported features!… tim
*** There is a reply:
85504
Enter command, N for next
message or <ENTER> for menu:n
You've touched on a subject that can keep Forth designers awake nights! After
much thought, I ended up following a similar stack & reg. arrangement to that
used by the 8080 implementation of fig-Forth, i.e. {BC} => IP register, {SP} ==
Data Stack ptr, the Forth Return Stack Ptr is maintained in RAM. {HL} and {DE}
are scratch regs, except {HL} is frequently used for address calcs and JP (HL)
stuff, for example, {HL} is the routine's addr when entered because a JP (HL)
was used to get there.
rIOforth is not on the market yet, but I'll leave word here when it is! It is
runtime RELOCATABLE and intended to complement the M100 rather than impose
classic Forth OS restrictions — it works WITH the M100 OS rather than istead
of it. Also has a split dictionary structure, so you can remove all of the
assembler and compiler words from a run-only program, saving 2K+ on the program
size.
It will be a few months before I'm even ready to Beta test it. Other demands
keep getting in the way … like eating and paying for my house and toys.
Enter command, N for next
message or <ENTER> for menu:n