[Coco] f83 for the CoCo, Update and a laundry-list of questions.

[Brett Heath]

How can I put this?

It's working! It's working! (cue Mad Laughter:-).

In other words the kernel is basically done. It still needs some
clean-up and detailed testing
but it opens files and loads (compiles) source from them which is it's
purpose in life.

One of the first things it needs to load is the rest of the file
interface (Mainly creating and
deleting files). and that brings me to my first set of questions.

The intention is to have versions that are compatible with as many
set-ups as possible, so
to save headaches later it's a good idea to factor the code with an
eye to compatibility. With
one exception the file interface to Disk EDTASM and OS9 (and
presumably Nitros) looks to
be fairly straightforward. The exception is determining file size. The
only way I see to do this
in EDTASM DOS is to do repeated reads if increasing record numbers
until an error is returned, inelegant to say the least. I also didn't
see any way to directly query
OS9 for file-size.

Have I missed something?

A more fundamental problem is that I haven't found any way to find out
from RSDOS if
a diskette has been changed, and thus that the resident RAM copy of a
drive's FAT is no
longer valid.

Please tell me that I've missed something.

More generally, what other OS's exist for the Coco (1, 2, or 3), how
widely used are they,
and where can I find documentation on their system call conventions
(Disk and Console)?

Which leads me to my second set of questions, at first glance they may
seem random and
unrelated but they all represent potential solutions to a major
development bottleneck so
bear with me please.

Is there any way to get Vavasours Coco 2 emulator to treat the
bit-banger like a bidirectional
serial port (virtual or physical)?

Is there another way to get Vavasours Coco 2 emulator to do serial I/O?

Less important but very annoying, how can I get polcat to return a
control-code on the Coco
2 emulator?

Where does xmess 0.106 look for it's ROM images (Under Gentoo AMD64 2008.beta)
and does it support serial I/O (virtual or physical)?

Is there any hope of getting an 80 column screen on the Coco 2 emu (yeah yeah,
 I know, don't laugh;-)?

Has _anybody_ gotten either of the Keil emulators to run under dosemu,
or even tried?

Bearing in mind that I own neither a Coco 3, nor a Coco disk system
(other than the Glenside
IDE), nor a serial cartridge pak, is there another way to get serial
I/O (virtual or physical) and or an 80 column out of a Coco emulator
without breaking Intellectual property rights beyond
all recognition?

Some means of serial would be best, as it would solve several problems.

That's more than enough brain-picking for now.

\*** Teaser1
In the thread on optimizing Basic someone mentioned what a pain it
could be to find
variable declarations . In f83 you merely type 'view "name"' and it
lists the source screen
where "name" is defined, be it variable, constant, or command.

\*** Teaser2
The RPN syntax takes some getting used to, but it is more than made up
for by having
control structures built-in to the assembler. For example:

 0 \ Low-level disk buffer management                    08Nov08BKH
 1 HEX
 2 xasm09 LABEL >CHAIN?  ( uses X,Y,D returns X,D,CC Z-bit )
 3   X -2 , LDY, NE IF, D Y EXG, X D, LEAX, Y D EXG,  THEN, RTS,
 4 9code DRV-CTL?  (S drv dcb0 -- drv dcbn flag )
 5          U 0 , LDX, U 3 , LDA,
 6          BEGIN,  X 1 , CMPA,  EQ IF, U 0 , STX, YES BRA,
 7            THEN,  >CHAIN? BSR, EQ UNTIL,
 8          U 0 , LDX, U 3 , LDA, ( No match, any free? )
 9          BEGIN,  X 1 , TST,  MI IF, U 0 , STX, YES BRA,
10            THEN,  >CHAIN? BSR, EQ UNTIL, U 0 , STX, NO BRA, C;

And it's associated comment screen;

 0 \ Low-level disk buffer management                    08Nov08BKH
 1 >CHAIN? Subroutine to move to next DCB in chain if it exists,
 2         otherwise return current (last) dcb and set CC Z flag.
 3     Enter with DCB in X,.Alters Y and returns DCB address in X.
 4
 5 DRV-CTL? Scan the linked list of existing DCB's for one we
 6   can use. First we check them all for one already assigned to
 7   the  drive. If we find one,  we return the drive #, the dcb's
 8   address, and TRUE. If not we look for a free DCB to return.
 9   If we find neither we return the last DCB defined and FALSE.

Is much easier to decipher than a long list peppered with a dozen labels
(After you get used to it anyway).

Backslash and parenthesis denote comments, the line #'s are an
artifact of the editor
and not part of the source. 9code marks the beginning of a named
dictionary entry
which can be executed from the command line or included as part of high-level
source.

\*** Teaser3
The Interpreter and the Compiler use Identical syntax, so you could
type the above code
definition in at the terminal spanning multiple lines (but without
line numbers) and it would
be immediately available to execute from the command line or use in
subsequent high level
definitions. This makes prototyping and testing incredibly quick and easy.


Brett K. Heath