knudsen@ihwpt.UUCP (02/13/87)
I bought a blank PBJ upgrade daughter board for my Coco III
and put my own chips in it. Like, three different brands--
Western Electric, TI, and some Korean outfit.
It hardly worked at all. I had more Korean chips so I
made it all Korean (they should feel at home in there ;-) ).
Now it almost works -- fine as a Coco II, but usually
screws up if it tries to print much in WIDTH 40 or 80.
Not looking forward to running OS9-L2 on this....
The failures were "analog" in nature -- the more RAM chips
I replaced with Korean, the better it worked.
From this I conclude that some RAM chips must load down
(draw current from) the address and control (RAS, CAS)
and data lines than others. All these chips are 150 ns
(the PBJ instructions say to use 120ns, but their populated
boards come with 150 chips anyway!)
Originally the GIME chip must drive only 4 chips worth of
address & control, but you multliply this by 4x when you
upgrade. So I suspect the GIME, which uses wimpy (non-TTL)
CMOS logic, can't drive all those inputs.
Unless you're careful to use exactly the right make
& model of RAM chips. Anyone got any recommendations?
BTW, the power supply regulator (big heat sink) gets pretty
toasty. I intend to 'scope out the +5V supply to make
sure there's no ripple. And of course to view the signal
leads as well.
Cuda been worse -- I cuda soldered all those chips piggybacked
onto my DISTO Ramdisk (which works great, BTW). Or onto
an Atari 520ST... ... mike k
--
Mike J Knudsen ...ihnp4!ihwpt!knudsen Bell Labs(AT&T)
>>>DRUGS are for WIMPS who can't handle SCIENCE FICTION<<<pete@wlbreng1.UUCP (02/16/87)
In article <1404@ihwpt.UUCP> knudsen@ihwpt.UUCP (mike knudsen) writes: >I bought a blank PBJ upgrade daughter board for my Coco III >and put my own chips in it. Like, three different brands-- >Western Electric, TI, and some Korean outfit. >It hardly worked at all. I had more Korean chips so I >made it all Korean (they should feel at home in there ;-) ). >Now it almost works -- fine as a Coco II, but usually >screws up if it tries to print much in WIDTH 40 or 80. >Not looking forward to running OS9-L2 on this.... > >The failures were "analog" in nature -- the more RAM chips >I replaced with Korean, the better it worked. >From this I conclude that some RAM chips must load down >(draw current from) the address and control (RAS, CAS) >and data lines than others. All these chips are 150 ns >(the PBJ instructions say to use 120ns, but their populated >boards come with 150 chips anyway!) > >Originally the GIME chip must drive only 4 chips worth of >address & control, but you multliply this by 4x when you >upgrade. So I suspect the GIME, which uses wimpy (non-TTL) >CMOS logic, can't drive all those inputs. > >Unless you're careful to use exactly the right make >& model of RAM chips. Anyone got any recommendations? >BTW, the power supply regulator (big heat sink) gets pretty >toasty. I intend to 'scope out the +5V supply to make >sure there's no ripple. And of course to view the signal >leads as well. > >Cuda been worse -- I cuda soldered all those chips piggybacked >onto my DISTO Ramdisk (which works great, BTW). Or onto >an Atari 520ST... ... mike k >-- >Mike J Knudsen ...ihnp4!ihwpt!knudsen Bell Labs(AT&T) I have heard (from the product manager and Steve Bjork..) that the system requires either 150 NS >NEC< Drams, or 120 NS of any other kind. I have taken no chances and installed 120 NEC's. On another tack, has anyone else noted the 'snowflake effect' under level II? It seems to be that re-mapping of memory by the gime cause little white spots to appear on the monitors (all - I have tried 3 RGB's and 2 monochromes). It is very prominent under applications that use a lot of system calls (like I$getstt in a terminal program).. BTW - Level II was cleared through Q/A as of Tuesday of last week.. Pete -- Pete Lyall Usenet: {trwrb, scgvaxd, ihnp4, voder, vortex}!wlbr!wlbreng1!pete Compuserve: 76703,4230 (OS9 SIG Sysop) OS9 (home): (805)-985-0632 (24hr./1200 baud) Phone: (818)-706-5693 (work 9-5 PST) ----------------------------------------------------------------------
jlw@io.UUCP (02/19/87)
One problem you might be running into is a peculiarity of the WECo 256K DRAM. 256K DRAMs have A0-A8 strobed twice with CAS and RAS respectively. Since the architecture of a 256K chip is really a 4x64K only A0-A7 are active for refreshing. If your board design tri-states A8 of a WECo. 256K DRAM during refresh, your data will die. The real problem is that this is very hard to determine with standard memory check programs since they access the memory often enough to keep it refreshed. Then when you try to run real code.....boom...Panic Trap. Joe Wood io!jlw
jimomura@lsuc.UUCP (Jim Omura) (02/20/87)
In article <172@wlbreng1.UUCP> pete@wlbreng1.UUCP (0000-Pete Lyall) writes: >In article <1404@ihwpt.UUCP> knudsen@ihwpt.UUCP (mike knudsen) writes: >>I bought a blank PBJ upgrade daughter board for my Coco III ... >On another tack, has anyone else noted the 'snowflake effect' under >level II? It seems to be that re-mapping of memory by the gime cause >little white spots to appear on the monitors (all - I have tried 3 >RGB's and 2 monochromes). It is very prominent under applications that >use a lot of system calls (like I$getstt in a terminal program).. I noticed something in the way of noise on my cheap composite monitor, but noting extensive. >BTW - Level II was cleared through Q/A as of Tuesday of last week.. Does that mean it's almost in the stores? I heard "sometime in March for Canada", but you guys in the south usually get stuff a bit earlier than us. Any word on the new version of Deskmate? In case anyone's wondering (and to flesh out this message so the mailer doesn't dump it), I called J&M and they have not yet corrected the parallel port addressing problem on their top line controller. I then called CRC (Disto Super Controller) and they claim full CoCo3 compatibility. I bought the Disto--with my fingers crossed. :-) Cheers! -- Jim O.