[Coco] Word-PAK RS Clone

[CoCo Demus]

The fix to make it to respond only to FF78/79 would be: change the  74LS10

from:

NAND(
NAND( A3, ~A1, ~A2)
NAND( A3, ~A1, ~A2)
NAND( ~A3, A1, A2)
)

to:

NAND(
NAND( A3, A1, A2)
NAND( A3, A1, A2)
NAND( A3, ~A1, ~A2)

I could change that on the schematic but I don't want to produce a new
batch of boards. I have enough wordpaks for my needs :)


On Sun, Aug 13, 2017 at 10:26 AM, CoCo Demus <retrocanada76 at gmail.com>
wrote:

> just figured it out the board works from FF76-FF79 with these two decoders.
>
> On Sun, Aug 13, 2017 at 10:02 AM, CoCo Demus <retrocanada76 at gmail.com>
> wrote:
>
>> I had to se 24x80 because some monitors would not display the 25th line
>> due to overscan. Also not all R6545 are the same. I have two here and one
>> settings does not work with the other. So I came up with a settings that
>> works on both.
>>
>> Also I figured out how the FF76 is trapped with the 74LS10 and the
>> 74LS133 but the FF76+3 (used to write on the RAM chip) I still need to find
>> it...
>>
>>
>> On Sun, Aug 13, 2017 at 9:29 AM, Gene Heskett <gheskett at shentel.net>
>> wrote:
>>
>>> On Sunday 13 August 2017 11:25:27 retrocanada76 wrote:
>>>
>>> > i didnt changw because any mistake i would need to fab new boarda as
>>> > the design is a little more complex for my electronic skills. but why
>>> > you wod need a wordpak for cc3 anyway?
>>> >
>>> I was running 2 monitors on my cc3? An amber screen Maggy pc-80.
>>>
>>> But the wp-rs's actual used area of the 13" screen was about the size of
>>> a post card.  So I played with the init values in the driver until the
>>> image was big enough to be useful, adding a 25th line while I was at it,
>>> but the 6116 cannot do more as its within 20 bytes or so of full at 25
>>> lines.
>>>
>>> That code was submitted to the nitros9 repo, but in the grand re-write of
>>> all the scf stuff to modularize it, its was apparently considered to be
>>> junk code in co80 and friends that has been thrown away without even
>>> generating an email to me asking about it. One of the side effects of my
>>> screen expansion was that the h-sweep rate, originally in the 15750Hz
>>> rate range, was moved upward to a bit over 18 kilohertz, which the
>>> monitor could do but at reduced brightness due to the loss of a kilovolt
>>> or so of the crt's anode voltage.  The monitor was not endangered in any
>>> way otherwise since its going below the design frequency that allows the
>>> output transformer to saturate its ferrite core, in which event the
>>> currents reach part killing amperage in a microsecond or so since a
>>> saturated ferrite core effectively disappears along with the inductance,
>>> so the rate of rise goes up 10 to 100x.
>>>
>>> And that lets the magic smoke out and it doesn't work any more.
>>> >
>>> > Sent from my Samsung Galaxy smartphone.
>>> > -------- Original message --------From: Gene Heskett
>>> > <gheskett at shentel.net> Date: 2017-08-13  2:11 AM  (GMT-08:00) To:
>>> > coco at maltedmedia.com Subject: Re: [Coco] Word-PAK RS Clone
>>> >
>>> > On Sunday 13 August 2017 03:23:37 CoCo Demus wrote:
>>> > > Here, fresh from the press:
>>> > >
>>> > > https://sites.google.com/site/tandycocoloco/wordpak-rs
>>> >
>>> > Good for you! But your clone was too accurate.
>>> >
>>> > That $FF76 address means it straddles the boundary between 2 of the
>>> > coco3 std 4 byte blocks of i/o. The one I still have, has been moved
>>> > to $FF78, and my driver adjusted to compensate, so the offsets for the
>>> > various registers are not 0,+1,-1,-2 as in the OEM driver, but
>>> > 0,+1,+2,+3 which puts it all in one block of i/o, which the coco3 is
>>> > criminally short of.
>>> >
>>> > This is why I have gone off on a rant several times begging someone to
>>> > design an aftermarket decoder board kit to go into the coco3, freeing
>>> > up the space from $FF04-$FF1F, 7 4 byte wide blocks of i/o, and from
>>> > $FF24-FF3F, another 7 4 byte wide blocks of i/o.  Thats 14 more
>>> > accessory cards that could be built if their address decoding was full
>>> > to the 4 byte level, that could be designed, and plugged into the mpi
>>> > or a clone of it, without encountering the dreaded "but that address
>>> > is already used by card x" syndrome. Same idea with the floppy
>>> > controller, which in its current OEM configuration, needs a 5 byte
>>> > wide space, but that would free up 6 more 4 byte wide spaces. A better
>>> > FDC could probably fix that and with a 512 byte buffer, could allow an
>>> > FDC that could run at a megabaud, turning a QD 3.5" drive into a 2.88
>>> > megabyte drive. Floppys are essentially extinct since drivewire is
>>> > nearly as fast, and for nitros9 systems, there is no real size limit,
>>> > I've a 105 megabyte floppy image that DW has no problems with, it just
>>> > works. I haven't tested but using a cluster size some power of 2
>>> > greater than the default 1, could allow a "floppy" image in the 4
>>> > gigabyte area.
>>> >
>>> > Installing this "better address decoder" in the coco3 would not be for
>>> > the faint of heart as it would be a bit invasive with the trace
>>> > cutting and wire wrap wire for patches. But it could be done.
>>> >
>>> > Several of you have already demonstrated that you ARE capable of such
>>> > a thing.
>>> >
>>> > So whats stopping one of you from making that your next big thing?
>>> >
>>> > 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>
>>> >
>>> > --
>>> > Coco mailing list
>>> > Coco at maltedmedia.com
>>> > https://pairlist5.pair.net/mailman/listinfo/coco
>>>
>>>
>>> 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>
>>>
>>> --
>>> Coco mailing list
>>> Coco at maltedmedia.com
>>> https://pairlist5.pair.net/mailman/listinfo/coco
>>>
>>
>>
>