[Coco] Looking for I/O specs for DECB,Nitros,.....
Brett K Heath
hcmth019 at csun.edu
Tue May 2 06:59:00 EDT 2006
On Mon, 1 May 2006, John Hogerhuis wrote:
> Brett --
> The best resource for this kind of thing is the "Unravelled" series.
Thank you, Thank you, and again I say Thank You. That makes for one hell
of a start!
I have heard of the unravelled series of course, but god knows (apologies
to Brother Jeremy) how long it wouid have taken me to make the connection
to my specific needs.
> Good luck with F83. Curious: why F83 and not an ANS standard Forth?
> You could start with 6809 CamelForth. I made a rudimentary port of the
> Z80 version to the Tandy WP-2 sometime back.
Asking why F83 is a loaded question:-)
I've been trying to restrain myself from making an all out sales pitch on
the virtue and incomparable utility of having a version of F83 available
to everybody running a coco, and then you go and ask a question like that.
The short answer is that I started with F83 and have already translated
the kernel to 6809 assembly, (slightly) modifed the meta compiler
to a cross compiler, (slightly) modified Brad Rodriguiz' CHROMIUM 6809
Assembler and compile to disk routines, and already resolved numerous
other niggling details involved in porting from one platform to another.
That's the short answer.
A shorter but more cyptic answer is to ask you to look again at the
description of my "Development system". Plain vanilla F83 and an emulated
test platform running under simulated MSDOS. I think you would be hard
pressed to get similar functionality out of a single executable with a
comparable memory footprint.
I'm not going to burden the list with a detailed enumeration of all the
potential advantages imaginable (though it's tempting), but there are a
few points to be made.
Let's say you have a large and complicated binary that's a bit tedious to
compile from scratch but it does need a couple of minor patches. Let us
further say that you would like to test these patches without rebuilding
the whole thing from scratch. If you know what you're doing you can
assemble directly to a given memory (or disk) location from the F83
command line. I'm going to say that again, if you know what your'e doing
you can assemble directly to any given memory (or disk) address without
ever leaving the F83 command line. The same applies to compiling FORTH
Let's say that instead of patching an alreaty well developed application
you're trying to probe hardware for which you have an incomplete
specification (or which is a new design that you're trying to debug) and
you need to test it's response to certain input conditions. You can, from
the command line, write and read directly as many registers as you want
to. If the forth interpreter is too slow, you can compile and run forth
test routines. If the compiled forth is still too slow, you can assemble
ML prototypes either to be run individually or as part of a coompiled test
Bear in mind that we haven't yet left the command line or used any of
F83's capabilities beyond it's inherent Interpreter/Compiler and included
For a final and somewhat different example: Let's say that there is a
development environment that you are particularly fond of. Let us further
say that there is a target platform that intrigues you and for which
somebody has already conveniently provided an Assembler that is compatible
with your development toolkit. What would you do?.
> Anyway I'd be happy to see something reasonably useful like F83. I'd
> also like to see it ROMable though... no dependencies on the native
> ROM. I've always thought that 8-bit micros would have been much better
> off with a Forth ROM instead of BASIC.
Oh yeah! The shortest answer to your question about why F83 is because, as
far as i'm concened, in terms of actual "bang for buck" or "bang for byte"
it blows everything else completely out of the water.
It is of course possible (but unlikely;-) that I am slightly biased.
Brett K. Heath
More information about the Coco