[Coco] co80 and cowprs modules in NitrOS-9 [WAS: format problems]

[Gene Heskett]

On Sunday 20 January 2019 15:50:13 Tormod Volden wrote:

> On Sun, Jan 20, 2019 at 8:08 PM Gene Heskett wrote:
> > It sure does. and the subject being the wordpack cards which brings
> > up a question: early in the original co80 code is a 16 byte data
> > table, written to the cg chip in the wordpack, and I wondering if it
> > uses the oem values yet, or if my kit of changes was used. They had
> > the effect of giving it a 25 line display, about 1.5" larger overall
> > and considerably more readable than the oem version which gave a 24
> > line postcard in the middle of a 13" monitor. Wasted over half of
> > the monitors screen real estate, and burning into the screen in a
> > year or so.
>
> BTW, hereby hopefully a clarification on "co80", this name has been
> used for at least two different drivers, but the situation in NitrOS-9
> is this (and since of recently documented in the source file headers):
>
> level1/modules/co80.asm:
> * CO80 - CRT9128 80 Column Co-Driver for VTIO
> * This driver came with OS-9 Level One V2.00, but is not
> * written for the 6845-based WordPak RS (I/II).
> * It works with a rare CRT9128-based PBJ WordPak prototype.
>
> level1/modules/cowprs.asm:
> * COWP - PBJ WordPak RS Co-Driver for VTIO
> * Adapted from CO80 for the WordPak RS.
> * 2017/07/01 - Initial driver implementation from CO80 - lfantoniosi
>
> So, the original(?) co80 driver was for the 9128-based prototype, and
> we have kept the naming that way. The later PBJ cards (and branded
> "RS") are based on the 6845 chips and use the cowprs module.
>
> A few of us have the remake of the 9128-based prototype (thanks to Mr.
> CoCoDemus) and some even the original.  I wonder if anyone is using it
> with NitrOS-9. In the latest snapshot (just uploaded one now) the co80
> hardware address is no longer hardcoded in the driver, but is taken
> from the device descriptor. So please verify the descriptor if using
> this card.
>
> A lot more people have the RS version, I suppose. I would be
> interested in hearing how well both drivers work with the latest
> snapshots.
>
> Regards,
> Tormod

I have in front of me a PBJ WORD-PAK, in the white blow mold case, and 
the one I've hacked on for all this marked as a WORD-PAK RS, both have 
variations of the 6845 for the cg chip. Differing pcb, but both actually 
made by pbj. I see some wire wrap patches that look like address fixings 
on the rs, and it looks like some solder blobs on the older pbj for 
that, on top of the board.  The cg rom in the pbj claims 2/27/84 AA on a 
paper label. the RS has the same size rom with a piece of scotch 88 over 
the window, but I rewrote it because it was using the same gliph for a 1 
and an l. Thats a no-no so I fixed mine. On of the things the RS version 
did was to straddle 2 adjacent 4 byte blocks of IO. With the coco3's 
already screwed up IO decoding, that wasn't tolerated for more than 1/2 
hour to fix that and redo the driver. Killing the IO above $FF7C for 
coco3's memory management, without opening up some lower addresses with 
better address decoding was a money saver I'll never forgive the shack 
for when there is room for 14 more IO slots below the floppy at $FF40, 
forever wasted. But you've read this rant from me in more colorfull 
language many times in the past. what has amazed me is that no one has 
come up with a kit to fix that, taking 11 or 12 pieces of wire wrap wire 
and some trace cuts to install the 74ls138 it would take to fix it. 
Since theres no way to get its output into the mpi, it would take a 
second kit for it, but then even a 16 slot mpi would be practical.
Shoulda been done in '87.  Now?

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>