[Coco] 3rdPart Editor

[Bill Gunshannon]

On 12/16/18 2:22 PM, Gene Heskett wrote:
> On Sunday 16 December 2018 13:52:56 Bill Gunshannon wrote:
>
>> On 12/16/18 1:19 PM, Gene Heskett wrote:
>>> On Sunday 16 December 2018 11:42:50 Bill Gunshannon wrote:
>>>> Just out of curiosity, has anyone ever built the version of the
>>>>
>>>> Unix editor "ed" that is in the 3rdparty/packages directory?
>>>>
>>>>
>>>> Additionally, is there any documentation on the "make"
>>>>
>>>> command packaged with the C Compiler?  It does not seem to
>>>>
>>>> take any syntax used by other versions of make.
>>>>
>>>>
>>>> bill
>>> That to me is an odd comment Bill, its the first make I ever used,
>>> and it always did what I asked. But it doesn't have all the bells
>>> and whistles the current *nix make has.
>> Odd comment?  Why?  I tried it with the "ed" editor.  Does
>>
>> a lot of weird stuff including inserting flags for the C Compiler
>>
>> that are not anywhere in the makefile itself.  Doesn't seem to
>>
>> recognize the section labels at all.  (Like all: clean:, etc. )
>>
>> Example:
>>
>>
>> make all
>>
>> make: Can't find source file to make "all.r"
>>
>>
>> It's fun to play with it again (I have my system running with two
>>
>> decent sized IDE disks!) but I am finding very little that works as
>>
>> expected.
>>
>>
>> Got "ed" built, but not using either the scripts or the makefile
>>
>> provided.  Working on SmallC.
> Part of that may be smallC, it would/could be a lot different from either
> of the K&R reference books.

Not a lot different. I've been using it since the original version

published in Dr. Dobb's lo those many years ago.


>                            The coco's C is pretty much the original K&R

The only C there is.  Everything else is a derivative and should

have been given a new name.  :-)


> minus much of the bit twiddling, meaning you have to write your own. Not
> a big deal. The 6x09's not having a "barrel shifter" makes the hand
> tweaks much more attractive as the default is a one bit at a time loop,
> eg long shifts take a long time. There are ways to throw away the time
> for 8 bit and up shifts. Paul Jerkatis was run off this list 20 years
> ago because his idiot of a CS prof said it couldn't be done. I sent a
> short 6 or 7 line code snippet as proof. He was determined there was a
> side effect, but the only side effect was doing an 8 bit shift in less
> time than the compilers default method for a 1 bit shift.
>
> That diff would be enough to chase me off of smallC

Can't imagine why.  It's still a fun compiler to play with.  It

takes C source and generates assembler.  The 6809 version

was for Flex so it will take a little work to get to the executable

stage, but I am seeing the results of the source compiled

using the OS9 C Compiler being pretty much non-functional

which is interesting because as I said, it really does nothing

but read in a text file and output a text file.  But it is unable

to parse even a simple 3 line C program.   And yet, it has

worked on all the other systems I have ever tried compiling

it on.

>                                                       regardless of the
> hardware you're useing, which I gather is not a real coco. What I'm
> writing here _always_ assumes its a real coco. I've never had the urge
> to try any of the emulators. My fault probably Bill, but there it is. :)


While I have used emulators (for a lot of different architectures)

I prefer the real thing and that is what I am running  on now.

COCO3 with 512M memory, SuperIDE with two drives, SDC, 2

floppies on an FD502 all plugged into an upgraded MPI.

I guess I just finding it interesting that so much stuff does not

seem to work either as advertised or as expected.  It took

a lot to get the IDE drives working and I still haven't got the

SCSI to work.  Drivewire is fun, but it requires a PC and if

your going to use a PC anyway, why bother with the COCO. :-)


Still, all good fun.


bill