[Coco] Current Status of the "Help Send A Fellow CoCoNut To This Year's CoCoFEST" Campaign

[Gene Heskett]

On Friday, February 20, 2015 03:50:08 AM Kip Koon wrote:
> Hi John,
> The RGB2VGA Converter is $58.50 total which includes the PCB fully
> assembled, a Coco 3 interface cable and shipping.  The Wordpak2+ is
> $86 fully assembled and includes shipping.  Thank you for your
> interest in helping to send a fellow CoCoNut to this year's CoCoFEST.
> The Wordpak2+ is a Video Display Generator expansion card for the Coco
> 1 or Coco 2 that uses the Yamaha V9958 VDG chip that has many display
> capabilities in addition to the 80x24 needed for the Coco 1 and Coco
> 2.  The VGA output frequency is the old 15KHZ not the current 31KHZ
> video standard.  You will need to use an old VGA monitor that accepts
> 15KHZ video signals or use the RGB2VGA converter that sits on top of
> the Altera DE-0 Nano board for proper operation to drive a modern VGA
> video monitor.  The RGB2VGA / Altera DE-0 Nano combo unit will convert
> the old 15KHZ Video from the Coco 3 or from the Wordpak2+ to the
> current 31KHZ video signal suitable for any of today's monitors be
> they flat screen or High Definition.  I don't know about the 4K Super
> HD TVs though.  The Wordpak2+ has drivers available for NitrOS-9 L1
> running on a Coco 1 or Coco 2 as that was the reason the Wordpak2+ was
> created in the first place.  The link for Luis' dropbox downloads with
> the drivers is https://sites.google.com/site/tandycocoloco/dropbox
> Click on the wordpak2+.zip file.  All of Luis Antoniosi's downloads are
> located at that link.  A full write up for the RGB2VGA Converter PCB
> has a link in the menu on the left of the page at the top of the page.
>  As far as I know, there is no link for a full write up on the
> wordpak2+.  I hope you will find all the information you need.  Thanks
> again for your interest.
> 
> Kip Koon
> computerdoc at sc.rr.com
> http://www.cocopedia.com/wiki/index.php/Kip_Koon
> 
> 
> 
> -----Original Message-----
> From: Coco [mailto:coco-bounces at maltedmedia.com] On Behalf Of John
> Robbs Sent: Thursday, February 19, 2015 8:18 AM
> To: CoCoList for Color Computer Enthusiasts
> Subject: Re: [Coco] Current Status of the "Help Send A Fellow CoCoNut
> To This Year's CoCoFEST" Campaign
> 
> Kip,
> I would love to have one of the RGB2VGA converters. I asked Roy Justus
> about it months ago and he said he was waiting for parts.  I don't
> know what the WordPak is. Do I want one of those, too? How much are
> they? John Robbs
> 
> On Feb 14, 2015 1:34 AM, "Kip Koon" <computerdoc at sc.rr.com> wrote:
> > Hi Everyone,
> > 
> > First of all, much thanks goes out to all those who have already
> > ordered either the RGB2VGA Converter or the Wodpak2+ or both fully
> > assembled PCBs. Every order will certainly help send a fellow
> > CoCoNut to this year's CoCoFEST - namely me!  :P  I do appreciate
> > everyone who has
> > participated so far.
> > 
> > I will be finalizing the PCB order with the fabrication house in the
> > next day or the day two, so if any of you who are interested but have
> > not yet ordered, please do so as soon as possible.
> > 
> > So far I have paid orders for 3 RGB2VGA Converters and 3 WordPak2+
> > fully assembled PCBs.  Thank you again for all who have ordered thus
> > far.  I'm sending in the PCB designs in tonight and will do the final
> > order probably Monday.  I was going to ordering from a Chinese PCB
> > Fabrication house, but they are having their New Year's Day
> > celebrations this month, so I'm going with my original plan to use
> > OSHPark.  After the PCBs' order is done Monday, I should have the
> > finished PCBs back in about 10 days.  By then, the parts orders
> > should be about ready to arrive as I will put together the finalized
> > orders for parts Monday and sending in those orders as well.
> > 
> > I'm delighted to put these PCBs together for you guys or should I say
> > for Y'all!  :)  To correctly pronounce Y'all, it should be held out
> > approximately 1 to 2 seconds.  :P  Thank you all again.  Take care my
> > friends.
> > 
> > 
> > 
> > Kip Koon
> > 
> >  <mailto:computerdoc at sc.rr.com> computerdoc at sc.rr.com
> >  
> >  <http://www.cocopedia.com/wiki/index.php/Kip_Koon>
> > 
> > http://www.cocopedia.com/wiki/index.php/Kip_Koon
Kip:  From the looks of the code in the repo, all of the initialization 
data poked into the chip at boot time appears to be from the original 
release.

That means that on a maggy pc monitor 80, a 13" amber screen, the usable 
area is about the same as laying a postcard center screen,  lots of unused 
screen real estate.  I have a different inittable in my own code that runs 
it in 25 line mode and expands the used screen by about 2" in both 
directions.

The downside of that code is that it ran the monitors scan rates up to 
about 18.5 kilohertz, with a vrate of around 56hz.  Definitely out of 
range for the typical old crt type tv.

When changing the scan rates (you have to tweak a coil in the Maggy to 
raise it in that monitor) unlike when driving them slower that designed 
for which will usually destroy the scan driver parts, you are free to 
raise it with no fear of damaging the monitor, but because of how the scan 
speed resonates, the developed crt anode voltage will drop a bit, dimming 
the display slightly.  The other side effect of the lessor high voltage is 
some of the sought after screen expansion.  The end result was a very 
usable 2nd monitor for my coco3, and it ran that way quite nicely all 
through the 90's until Boisy stripped that code clean out of the co80 
driver as part of his modularization.  I have no clue where that code 
might be in the repo, or even if it even exists.  Whats there now has the 
original timing initializers in it.

The original kit used a 2k (2048 byte) 6116 static ram, which did have 
room for the 25th line with a few bytes to spare. The 25th line brought 
its memory needs up to an even 2,000 decimal bytes. AIUI, you are using a 
different video chip than is in my WP-RS, so I've no clue if the screen 
expansion could be done on your newer hardware.  Given a big enough static 
ram, there is no reason that it couldn't be expanded to a 124 column 60 
line screen and still have ntsc compatible output timings.  The "dot" 
clock in the original is 4x subcarrier, or 14.3 mhz.  The WP-RS video out 
had nominally 40ns rise & fall times, so on a monitor with 15 to 20 mhz of 
working video bandwidth, which the amber screen Maggy did have, it was 
amazingly crisp.

Whats the dot clock crystal in yours, how many memory addressing pins are 
available on your chip, and how much ram is on your version?  I'm asking 
because it might be possible to expand its screen usable area considerably 
using some of what I did all those years ago.  Its all squirreled away 
someplace in the copy of that old Maxtor drive I made on the 1Gb drives I 
use now.  All I have to do is find it.  And then figure out a usable 
method of making vtio drive it given the mess our system ram is in today.

==========change of subject===========

One of the things that might help in that dept is that since (IIRC) 90% of 
the os9p1 stuff is duplicated in nitro.asm, we need to develop a 
conditional in the krn code that moves much of nitro.asm back into krn. As 
it is, its duplicated code taking up valuable sysram. I think that once L3 
is fully booted, all of nitro can be flushed from memory, but maybe not. 
I've never been able to make it boot for at least 2 reasons.

1, I believe that the nitro.asm code we have from Alan is incomplete, and 
2, so much has been moved around that I cannot get rid of the E$MNF 
errors.  That is I believe because I cannot find but one mapping switch, 
and its a one way switch! It never maps back to "the rest of the story".  
And that is the source of the E$MNF error as it tries to open its initial 
/Term screen.  Subject to inventing a better debugging method that does 
not go away (lda traceing char;jsr d.BtBug) the instant it tries to open 
the screen.  So the only window we have into what the heck its doing is 
destroyed by the attempt to open the first /Term screen.  At that point I 
threw up my hands figuring Curtiss B. had a better insight as he is a 
contemporary of Alan. However it appears he is as stymied as I am.

I really think it needs a fresh approach by someone with a clearer mind 
than mine is at 80yo. So there is your challenge, take the premise of 
separate 16k memory areas for scf stuffs, 16k for rbf stuffs, and the rest 
of the system, and make it work.  Obviously not on a 128k machine however.

The first thing to do is to allocate gime register images at $640-680 in 
gime block 0 memory. The current code uses only one such scratchpad 
located at $642 IIRC, a 2 byte block that maps 16k in the gime.  And 
another tally byte at $660 IIRC.  Its mapped in, and never mapped back 
out, or even overwritten by another memory request, it simply put, does 
not exist in the current code. Nitro.asm should, IMO, reserve a 16k block 
for the scf stuff, and tally internally that its been done.  The next _end 
module it encounters should cause it to do another 16k reservation for the 
RBF stuff, and keep track of that internally.  The second _end module it 
encounters should cause it to restore the original mapping back to what it 
found when it was first called so the rest of the boot can proceed.
That code is not there in what we have.

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>