[Coco] DECB on the COCO - (was: Why DECB is important to OS-9 folk.)
John E. Malmberg
wb8tyw at qsl.net
Fri Sep 9 21:29:46 EDT 2005
Stephen H. Fischer wrote:
> There is a big problem on this list for DECB folk.
My biggest problem is currently not having time to play with the COCOs
because other projects have a higher priority.
> The discussions we are having are so overwhelming about OS-9 that I suspect
> many DECB folk that are signed up for our messages have or are thinking
> about leaving as what is in their interest is discussed so little. I am
> revising my previous statement.
I would not assume that many of the people use exclusively one OS on the
> Being an OS-9 person, why am I working on one DECB project and
> investigating another?
A Challenge perhaps?
Don't sell the ROM interpreter short, if you understand how to use it,
it allows some pretty complex and compact programs to be easily written.
If some rather silly features were changed in the ROM interpreter, it
would be even better.
The first hack I would do is use one of the interrupts to poll the
keyboard in the background instead of polling between BASIC commands.
The next hack I would do is change ROM BASIC to use a memory manager to
swap the ROMS out of the way to allow a full 64K to be used. That part
would probably require a re-write from the ground up, mainly to make it
free of the copyrights that are in the current ROMS. And I would keep
in mind my end goals during the rewrite.
After that, I would have DISK ROM BASIC learn to only load in the
section of the BASIC program it is currently executing from the disk,
and manage the in swapping transparently.
Once that is working, then do the same for the string space, and finally
When I had the time to do that, what stopped me was I could not afford
the hard drive needed to make such a major project feasible.
> The previous time I worked on a DECB program many years ago I built and
> edited it on OS-9 and transferred it to a DECB disk for testing.
> Then I remembered the FLEX Basic preprocessor and realized that it would
> greatly simply the building and editing of the DECB program I had stopped
> working on.
You are aware that DECB can be easily made to run under FLEX-09 on a
COCO I or COCO II. There are no resource conflicts. Using the graphics
and sound functions may be a little tricky. It just takes a little
matter of assembly and a decoded listing of the BASIC ROMS so you know
where to put the patch vectors.
The people who wrote in the printed magazines that said there were
resource conflicts that prevented such operation were wrong.
The FLEX line mode editing makes editing basic programs easier, but the
only way I had to transfer programs back and forth between disks
formatted with ROM basic and disks formatted with Flex-09 was to pipe
them through the DECB interpreter while it was running under FLEX.
But it is nice having a 51 column screen on DECB.
My program currently only works on
A COCO III can not easily run DECB under FLEX-09 because it copies the
ROM into RAM which means that there are resource conflicts.
FLEX-09 does run on the COCO 3 though. Given enough time, I could
probably get the ROM basic to run under FLEX-09 using similar techniques
> When I got the "OS-9 as Replacement for DECB" Idea I realized that if it
> can be built it would be the best environment I would want for any DECB
> programs I would wish to write, should I want to write any. That is
> quite unlikely, but possible.
I have looked at getting the real DECB running under OS-9 on a COCO-I/II.
The main problem is that I could not figure out how to convince OS-9 to
switch the ROMS in and out at the right time.
What I would like to do if I had time is to write an interpreter for
DECB that would run under NITROS-9 and other platforms, yet
transparently take advantage of other things.
A DECB that ran under NITROS-9 could store the program and data in
simulated demand paged virtual memory.
To put that in simple terms, if properly done, when running the BASIC
that I want to write on a 128K COCO II, it would appear to the user that
the COCO III that it had over 1M for program and data including string
space in addition to having most of the physical memory available for
graphics, and that you could run multiple independent BASIC programs as
long as they did not conflict for graphics resources at the same time.
My next priority for a COCO program is to find an easy way to
interchange ROM basic formatted floppies on a modern computer that does
not allow setting the sector size to 512 bytes. My proof of concept
test showed that this project is practical.
Personal Opinion Only
More information about the Coco