neals@tekigm.UUCP (Neal Sedell) (05/02/85)
Greetings 6809 fans.
While working on an OS9 driver on my Coco for subject two of this posting
I had made the unfortunate decision of rearranging the standard
ifp1
use /d0/defs/os9defs
use /d0/defs/rbfdefs
use /d0/defs/ramdefs
endc
Since I had wanted the ramdisk definitions to be defined first (just in case
it mattered) I ended up with the use rbfdefs line before the use os9defs line.
It assembled with no hint of anything wrong, but did not work at all. Upon
comparison of the previous (working) versions listing and the current one I
noticed that the offsets into the path descriptor were wrong. It was getting
late so I called it quits. After having a day to think, it dawned on me that I
had rearranged the "includes". After re-rearranging them everything was ok.
Inspection of rbfdefs revealed that it did use some definitions from os9defs.
For files as small as the driver the assembler spent most of its time reading
the os9defs and rbfdefs files anyway. So much for style.
Subject two: OS9 C compiler with the above ramdisk driver. The ramdisk
is a homebuilt ramdisk using a 74LS764 DRAM controller, a 74LS393 counter
(makes a nice autoincrementer for 256 byte sectors and 4 less pins than an
octal latch), a couple latches, an octal data buffer, a PAL and 8 256K rams.
The C compiler was purchased from Radio Shack but should be the same as the
"standard" Level 1 compiler.
One thing about the compiler really makes it a pain to use a ramdisk, and
that is that cc sets up a script that assumes the librarys and mandatory
runtime modules are on drive /d1. That would not be a problem if you os9gen'ed
the system so that the floppies are /d0 and /d2. Oh well, I haven't rewritten
my disk drivers to use 40 tracks or both sides yet. With Coco format 35 track
disks, the system disk is so full it cannot be os9gen'ed without fragmenting
the boot file which is not allowed. The way I get around the /d1 problem
currently is to go into debug and change the device descriptor string for
d1 and d2 (ramdisk). All you need to do is enter debug and type
L d1 (to locate the /d1 descriptor)
. .+22 (this will position you to the second char of the name string)
= B3 (to change to /d3. This is the ascii 3 or'ed with 0x80)
L d2 (to locate the /d2 descriptor)
. .+22 (this will position you to the second char of the name string)
= B1 (to change to /d1. This is the ascii 1 or'ed with 0x80)
Q (to return to OS9)
Note: this works with Radio Shacks device descriptor format. I can't vouch
for others, but since they are probably standard Microware descriptors...
Also, if you SAVE the modules to a disk file the CRC's will be wrong and OS9
will not accept them. You should use VERIFY with the U option to correct them.
Now for the nitty gritty. After copying the necessary commands to /d1/cmds
directory and definitions to /d1/defs from the two C compiler disks, here are
the results. Execution directory was changed to /d1/cmds so the floppys were
not used at all. Times are in seconds, size is in bytes (HEX). The -O columns
are with the optimizer turned off (I know, its bassackwards, but the default
is ON and -O turns it off in this case). My watch doesn't resolve below one
second so 24 is probably the same as 23 seconds.
file compile -O size -O run -O
------- ------- ---- ------ ------ ----- ----
hello.c 44 40 0E5B 0E5B
sieve.c 52 46 0F18 0F03 23 24
Timings for hello.c using floppy drives was 3:31 for 6mS tk-tk seek and
5:18 for the RS provided 30mS seek time. The C compiler is 6 passes (pre-
processor, pass1, pass2, optimize, asm and link). Using the ramdisk it
completes the first 3 passes for sieve.c in about 25 seconds. This is
quite tolerable compared to a floppy system. The clock speed of the Coco
is about 900 KHz. If I could just get my SAT-96 to run at 2MHz.....
Any SATers on the net? Is there a successor? Something with a 68010, maybe?
About the only other drawback I have run into using the C compiler is that
it is a memory hog. Any utilities you have LOADed so as to remain resident
in memory must be released before running the compiler or it will barf with
an out of memory error and die. Of course with the ramdisk it isn't
necessary to have anything resident. The compiled hello.c program will
load from the ramdisk, startup and complete in about 1.5 seconds. Most of
the OS9 utilities are a lot smaller and will start more quickly.
Now to add an observation about the possible Coco version 3. I updated
my OS9 in January of this year to 01.01.00 (I'm pretty sure that was when
it was). Radio Shack had sent me a blurb about improved screen driver,
ACIApack driver, etc. Other than a coupled changed revision levels and
module sizes, I didn't notice anything. Well, the other night when I was
digging into the /d0/defs directory, I listed the system definition file.
Besides the usual stuff, the following caught my eye:
"
.
.
COCOType set Original
.
.
ifeq COCOType-Delux
A.T2 set $FF3C 6551 Acia Internal
A.T3 set $FF68 6551 AciaPak
else
A.T2 set $FF68 6551 ACIA external
endc "
How do you like that. It's been there for all those months waiting to
be noticed. It seems like there was some discussion here about a year ago.
I seem to recall someone mentioning Motorola's RMS chip set. Well, a bench
neighbor just happen to have received the User's Manual and I was looking
through it. It has two modes, >>6883-6847 emulation<< and full featured
operation. This is just too many coincidents. The RMS will handle the 68008
but since the address in the sysdefs file is only 16 bits, the Delux Coco
must not be going to use it. Oh well. The only question probably is will
there be 64, 128 or 256k of memory. The RMS will support 4 banks of
up to 256K parts, but I doubt RS would put a meg in a Coco, especially if
they don't put a few more keys on the keyboard. I would guess there will be
one bank of rams, with another bank on a daughter board as a spendy (maybe
not in comparison to Apple's Mac upgrade) option. If they use 64K parts it
would be pretty easy to go to 256K....
I went out and ordered TS/Edit in January when I picked up the OS9 update.
Murphy really had a field day. When I finally got it in March, I found that
it really was like vi, as far as it went. The major limitation is that the
repeat count specified before a command is limited to a single digit (1
through 9). A minor gripe is that return does not move the cursor to the
first nonblank on the following line. This is the hardest one to get used to.
And deleting characters past the end of the line will eliminate the line
seperator and join lines together and start deleting from the second. Ask me
how I know. I really like it. It also has selectable screen format from 16x32
to 32x80, although anything beyond 24x60 on a green monitor was no fun. Color
(Commodore 1702) was limited to about 40 columns. It does have horizontal
scrolling selectable for some formats less than 80 columns. I usually use
the graphics mode 16x32 with scrolling. The lowercase, {, }, [, ] etc. being
displayed instead of inverse capitals, inverse (, etc. are really a
pleasant sight, especially when writing a C program.
If anyone would like the ramdisk driver posted let me know. All I will
have to do is get an uploader so's I can get it here. It would also be nice
if someone could post a downloader (RS Basic ok but OS9 preferred). I
provide the info if anyone would like to speed up their seek times by changing
one location in the CCDISK module.
Neal Sedell
wherever!tektronix!tekigm!neals
P.S. to james jones: I haven't received any mail in many moons. If you
are still active with OS9 please put me back on the list. Also, I never
saw you posting of make to net.sources.neals@tekigm.UUCP (Neal Sedell) (05/08/85)
Greetings 6809 fans.
While working on an OS9 driver on my Coco for subject two of this posting
I had made the unfortunate decision of rearranging the standard
ifp1
use /d0/defs/os9defs
use /d0/defs/rbfdefs
use /d0/defs/ramdefs
endc
Since I had wanted the ramdisk definitions to be defined first (just in case
it mattered) I ended up with the use rbfdefs line before the use os9defs line.
It assembled with no hint of anything wrong, but did not work at all. Upon
comparison of the previous (working) versions listing and the current one I
noticed that the offsets into the path descriptor were wrong. It was getting
late so I called it quits. After having a day to think, it dawned on me that I
had rearranged the "includes". After re-rearranging them everything was ok.
Inspection of rbfdefs revealed that it did use some definitions from os9defs.
For files as small as the driver the assembler spent most of its time reading
the os9defs and rbfdefs files anyway. So much for style.
Subject two: OS9 C compiler with the above ramdisk driver. The ramdisk
is a homebuilt ramdisk using a 74LS764 DRAM controller, a 74LS393 counter
(makes a nice autoincrementer for 256 byte sectors and 4 less pins than an
octal latch), a couple latches, an octal data buffer, a PAL and 8 256K rams.
The C compiler was purchased from Radio Shack but should be the same as the
"standard" Level 1 compiler.
One thing about the compiler really makes it a pain to use a ramdisk, and
that is that cc sets up a script that assumes the librarys and mandatory
runtime modules are on drive /d1. The preprocessor also assumes #includes
are on /d1. That would not be a problem if you os9gen'ed the system so that
the floppies are /d0 and /d2. Oh well, I haven't rewritten my disk drivers
to use 40 tracks or both sides yet. Actually the big headache would be
writing a new format routine. With Coco format 35 track disks, the system
disk is so full it cannot be os9gen'ed without fragmenting the boot file
which not only is not allowed, it doesn't figure this out until the old
boot file has been deleted and your disk is unbootable. The way I get
around the /d1 problem currently is to go into debug and change the device
descriptor string for d1 and d2. All you need to do is enter debug and type:
L d1 (to locate the /d1 floppy descriptor)
. .+22 (this will position you to the second char of the name string)
=B3 (to change to /d3. Ascii 3 or'ed with 0x80)
L d2 (to locate the /d2 ramdisk descriptor)
. .+22 (this will position you to the second char of the name string)
=B1 (to change to /d1. Ascii 1 or'ed with 0x80)
Q (to return to OS9)
Note: this works with Radio Shacks device descriptor format. I can't vouch
for others, but since they are probably standard Microware descriptors...
Also, if you SAVE the modules to a disk file the CRC's will be wrong and OS9
will not accept them. You should use VERIFY with the U option to correct them.
Now for the nitty gritty. After copying the necessary commands to /d1/cmds
directory and definitions to /d1/defs from the two C compiler disks, here are
the results. Execution directory was changed to /d1/cmds so the floppys were
not used at all. Times are in seconds, size is in bytes (HEX). The -O columns
are with the optimizer turned off (I know, its bassackwards, but the default
is ON and -O turns it off in this case). My watch doesn't resolve below one
second so 24 is probably the same as 23 seconds.
file compile -O size -O run -O
------- ------- ---- ------ ------ ----- ----
hello.c 44 40 0E5B 0E5B
sieve.c 52 46 0F18 0F03 23 24
Timings for hello.c using floppy drives was 3:31 for 6mS tk-tk seek and
5:18 for the RS provided 30mS seek time (five minutes of shear torture to
listen to the poor drives clunking away!) The C compiler is 6 passes (pre-
processor, pass1, pass2, optimize, asm and link). Using the ramdisk it
completes the first 3 passes for sieve.c in about 25 seconds. This is
quite tolerable compared to a floppy system. The clock speed of the Coco
is about 900 KHz. If I could just get my SAT-96 to run at 2MHz.....
Any SATers on the net? Is there a successor? Something with a 68010, maybe?
About the only other drawback I have run into using the C compiler is that
it is a memory hog. Any utilities you have LOADed so as to remain resident
in memory must be released before running the compiler or it will barf with
an out of memory error and die. Of course with the ramdisk it isn't
necessary to have anything resident. The compiled hello.c program will
load from the ramdisk, startup and complete in about 1.5 seconds. Most of
the OS9 utilities are a lot smaller and will start more quickly.
Now to add an observation about the possible Coco version 3. I updated
my OS9 in January of this year to 01.01.00 (I'm pretty sure that was when
it was). Radio Shack had sent me a blurb about improved screen driver,
ACIApack driver, etc. Other than a couple changed revision levels and
module sizes, I didn't notice anything. Well, the other night when I was
digging into the /d0/defs directory, I listed the system definition file.
Besides the usual stuff, the following caught my eye:
"
.
.
COCOType set Original
.
.
ifeq COCOType-Delux
A.T2 set $FF3C 6551 Acia Internal
A.T3 set $FF68 6551 AciaPak
else
A.T2 set $FF68 6551 ACIA external
endc "
How do you like that. It's been there for all those months waiting to
be noticed. It seems like there was some discussion here about a year ago.
I seem to recall someone mentioning Motorola's RMS chip set. Well, a bench
neighbor just happen to have received the User's Manual and I was looking
through it. It has two modes, >>6883-6847 emulation<< and full featured
operation. This is just too many coincidents. The RMS will handle the 68008
but since the address in the systype file is only 16 bits, the Delux Coco
must not be going to use it. Oh well. The only question probably is will
there be 64, 128 or 256k of memory. The RMS will support 4 banks of
up to 256K parts, but I doubt RS would put a meg in a Coco, especially if
they don't put a few more keys on the keyboard. I would guess there will be
one bank of rams, with another bank on a daughter board as a spendy (maybe
not in comparison to a certain CA company's) option. If they use 64K parts it
would be pretty easy to go to 256K....
I went out and ordered TS/Edit in January when I picked up the OS9 update.
Murphy really had a field day. When I finally got it in March, I found that
it really was like vi, as far as it went. The major limitation is that the
repeat count specified before a command is limited to a single digit (1
through 9). A minor gripe is that return does not move the cursor to the
first nonblank on the following line. This is the hardest one to get used to.
And deleting characters past the end of the line will eliminate the line
seperator and join lines together and start deleting from the second. Ask me
how I know. I really like it. It also has selectable screen format from 16x32
to 32x80, although anything beyond 24x60 on a green monitor was no fun. Color
(Commodore 1702) was limited to about 40 columns. It does have horizontal
scrolling selectable for some formats less than 80 columns. I usually use
the graphics mode 16x32 with scrolling. The lowercase, {, }, [, ] etc. being
displayed instead of inverse capitals, inverse (, etc. are really a
pleasant sight, especially when writing a C program.
If anyone would like the ramdisk driver posted let me know. I could
probably handle getting the source uploaded to our 4.2bsd system without
any file transfer program proper. It would be nice if someone could suggest
a means or a program that will run under OS9 to download programs.
I can dig up the info if anyone would like to speed up their floppy seek
times by changing one location in the CCDISK module.
Neal Sedell
wherever!tektronix!tekigm!neals
P.S. to James Jones: I haven't received any mail in many moons. If you
are still active with OS9 please put me back on the list. Also, I never
saw you posting of "make" to net.sources.neals@tekigm.UUCP (Neal Sedell) (05/08/85)
[ One more time. Maybe now it will make it onto the net. ]
Greetings 6809 fans.
While working on an OS9 driver on my Coco for subject two of this posting
I had made the unfortunate decision of rearranging the standard
ifp1
use /d0/defs/os9defs
use /d0/defs/rbfdefs
use /d0/defs/ramdefs
endc
Since I had wanted the ramdisk definitions to be defined first (just in case
it mattered) I ended up with the use rbfdefs line before the use os9defs line.
It assembled with no hint of anything wrong, but did not work at all. Upon
comparison of the previous (working) versions listing and the current one I
noticed that the offsets into the path descriptor were wrong. It was getting
late so I called it quits. After having a day to think, it dawned on me that I
had rearranged the "includes". After re-rearranging them everything was ok.
Inspection of rbfdefs revealed that it did use some definitions from os9defs.
For files as small as the driver the assembler spent most of its time reading
the os9defs and rbfdefs files anyway. So much for style.
Subject two: OS9 C compiler with the above ramdisk driver. The ramdisk
is a homebuilt ramdisk using a 74LS764 DRAM controller, a 74LS393 counter
(makes a nice autoincrementer for 256 byte sectors and 6 less pins than an
octal latch), a couple latches, an octal data buffer, a PAL and 8 256K rams.
The C compiler was purchased from Radio Shack but should be the same as the
"standard" Level 1 compiler. One thing about the compiler really makes it a
pain to use a ramdisk, and that is that cc sets up a script that assumes the
librarys and mandatory runtime modules are on drive /d1. That would not be a
problem if you os9gen'ed the system so that the floppies are /d0 and /d2.
Oh well, I haven't rewritten my disk drivers to use 40 tracks or both sides.
Actually the big headache would be writing a new format routine. With Coco
format 35 track disks, the system disk is so full it cannot be os9gen'ed
without fragmenting the boot file which not only is not allowed, it doesn't
figure this out until the old boot file has been deleted and your disk is
unbootable. The way I get around the /d1 problem currently is to go into
debug and change the device descriptor string for d1 and d2. All you need
to do is enter debug and type:
L d1 (to locate the /d1 floppy descriptor)
. .+22 (this will position you to the second char of the name string)
=B3 (to change to /d3. Ascii 3 or'ed with 0x80)
L d2 (to locate the /d2 ramdisk descriptor)
. .+22 (this will position you to the second char of the name string)
=B1 (to change to /d1. Ascii 1 or'ed with 0x80)
Q (to return to OS9)
Note: this works with Radio Shacks device descriptor format. I can't vouch
for others, but since they are probably standard Microware descriptors...
Also, if you SAVE the modules to a disk file the CRC's will be wrong and OS9
will not accept them. You should use VERIFY with the U option to correct them.
Now for the nitty gritty. After copying the necessary commands to /d1/cmds
directory and definitions to /d1/defs from the two C compiler disks, here are
the results. Execution directory was changed to /d1/cmds so the floppys were
not used at all. Times are in seconds, size is in bytes (HEX). The -O columns
are with the optimizer turned off (I know, its bassackwards, but the default
is ON and -O turns it off in this case). My watch doesn't resolve below one
second so 24 is probably the same as 23 seconds.
file compile -O size -O run -O
------- ------- ---- ------ ------ ----- ----
hello.c 44 40 0E5B 0E5B
sieve.c 52 46 0F18 0F03 23 24
Timings for hello.c using floppy drives was 3:31 for 6mS tk-tk seek and
5:18 for the RS provided 30mS seek time (five minutes of shear torture to
listen to the poor drives clunking away!) The C compiler is 6 passes (pre-
processor, pass1, pass2, optimize, asm and link). Using the ramdisk it
completes the first 3 passes for sieve.c in about 25 seconds. This is
quite tolerable compared to a floppy system. The clock speed of the Coco
is about 900 KHz. If I could just get my SAT-96 to run at 2MHz.....
Any SATers on the net? Is there a successor? Something with a 68010, maybe?
About the only other drawback I have run into using the C compiler is that
it is a memory hog. Any utilities you have LOADed so as to remain resident
in memory must be released before running the compiler or it will barf with
an out of memory error and die. Of course with the ramdisk it isn't
necessary to have anything resident. The compiled hello.c program will
load from the ramdisk, startup and complete in about 1.5 seconds. Most of
the OS9 utilities are a lot smaller and will start more quickly.
Now to add an observation about the possible Coco version 3. I updated
my OS9 in January of this year to 01.01.00 (I'm pretty sure that was when
it was). Radio Shack had sent me a blurb about improved screen driver,
ACIApack driver, etc. Other than a couple changed revision levels and
module sizes, I didn't notice anything. Well, the other night when I was
digging into the /d0/defs directory, I listed the systype system definition
file. Besides the usual stuff, the following caught my eye:
"
.
.
.
COCOType set Original
.
.
.
ifeq COCOType-Delux
A.T2 set $FF3C 6551 Acia Internal
A.T3 set $FF68 6551 AciaPak
else
A.T2 set $FF68 6551 ACIA external
endc "
How do you like that. It's been there for all those months waiting to
be noticed. It seems like there was some discussion here about a year ago.
I seem to recall someone mentioning Motorola's RMS chip set. Well, a bench
neighbor just happen to have received the User's Manual and I was looking
through it. It has two modes, >>6883-6847 emulation<< and full featured
operation. This is just too many coincidents. The only question probably
is will there be 64, 128 or 256k of memory. The RMS will support 4 banks of
up to 256K parts, but I doubt RS would put a meg in a Coco, especially if
they don't put a few more keys on the keyboard. I would guess there will be
one bank of rams, with another bank on a daughter board as a spendy (maybe
not in comparison to a certain CA company's) option. If they use 64K parts it
would be pretty easy to go to 256K....
I went out and ordered TS/Edit in January when I picked up the OS9 update.
Murphy really had a field day. When I finally got it in March, I found that
it really was like vi, as far as it went. The major limitation is that the
repeat count specified before a command is limited to a single digit (1
through 9) and the file can only be as big as free memory. A minor gripe is
that return does not move the cursor to the first nonblank on the following
line. This is the hardest one to get used to. And deleting characters past
the end of the line using 'x' will eliminate the line seperator and join
lines together and start deleting from the second. Ask me how I know.
It also has selectable screen format from 16x32 text mode to 32x80 graphic
mode, although anything beyond 24x60 on a monochrome monitor was a strain
but it would show what a full size screen would look like. My Commodore
1702 color monitor was limited to about 40 columns. It does have horizontal
scrolling selectable for in the 16x32 graphics display mode, which is the
one I usually use. The lowercase, {, }, [, ] etc. instead of inverse
capitals, inverse (, ), etc. are really a pleasant sight, especially when
writing a C program. All in all I do like it. Note that it will not work
with a serial terminal since it is specific to the console graphics hardware.
If anyone would like the ramdisk driver posted let me know. I could
probably handle getting the source uploaded to our 4.2bsd system without
any file transfer program proper. It would be nice if someone could suggest
a means or a program that will run under OS9 to download programs.
I can dig up the info if anyone would like to speed up their floppy seek
times by changing one location in the CCDISK module.
Neal Sedell
wherever!tektronix!tekigm!neals
P.S. to James Jones: I haven't received any mail in many moons. If you
are still active with OS9 please put me back on the list. Also, I never
saw you posting of "make" to net.sources.