[Coco] Long: Semi-ontopic parallel ramblings of a drunk... (was: Any news on the so called CoCo4 or Next CoCo
zmerch-coco at 30below.com
Sat Oct 23 22:15:43 EDT 2010
On 10/23/2010 06:37 PM, Frank Swygert wrote:
[[ snippage ]]
> I really don't see why the LPT port hasn't vanished yet, hardly used
> except for a few legacy dot matrix printers that are required for
> multi-part forms.
Surely you jest, eh?
This is actually mostly-on, slightly-off topic... but I recently
purchased one of the Willem eprom programmers not long ago to reprogram
some Intel 82802's  (Firmware Hub -- Flash EPROMs plus hardware RNG)
-- the USB port on the board is *just for power* -- it's parallel port
for data access, and if you have to program "older" Eproms with a higher
Vpp you still have to add a (not included) 12V wall wart.
So -- I scrounged around and found the parallel cable to my Xeltec
Superpro/L EPROM programmer... and now I have to scrounge for the
programmer itself! Why?
Because - I've finally gotten 'round to teaching myself how to program
PLDs. After doing a bunch'o'research on Verilog vs. VHDL (and not keen
on either, due to my serious lack of intelligence) I finally stumbled
across CUPL, actually got it downloaded, installed & working  and I
think I have enough figured out to finally make some headway. [3 & 3b]
The whole reason I wanted to learn to make GALs was because of a circuit
board I designed for the CoCo long ago - kind of a "hardware hackers
paradise" and after figuring out what kind of and/or/nor/xor/d'ohred
gates it took for basic address decoding on a byte level, I realized 2/3
of the board would be basic gates & a ton of soldering. My brain says
"GALs are the answer!" but the brain wasn't smart enough to decipher
what it took to make them. ;-)
[[ I still have it -- it's in AutoCad format as that's what was most
comfortable to me at the time, but I may redesign it in PCB for Linux. ]]
My Xeltec Superpro/L will program PAL/GAL/PEELs if you feed it a JEDEC
file. Problem is (if it's a problem... I don't think it is) the Xeltec
is also a parallel port device.
Long story long (and gets longer... I type fast! ;-) ), why do you want
to take away a simple, straightforward hackable port like the parallel
port and replace it with something as obtuse as USB? 
Side note: I *think* that I've figured out enough to make a basic
8-channel inverter. The WinCUPL code compiled fine, but now I have to 1)
Set up a testing platform to test the rewritten GALs. That's done - I'm
using my old, trusty Heathkit ET-3200 analog/digital trainer. I've even
found my 3M branded 22AWG jumper wire kit. (Not that I couldn't hack up
24AWG solid Cat5 cable in a pinch... ;-) ) That part's done. 2) clean
off the wife's old computer desk - she uses a laptop exclusively now,
and finding old computer stuff in my house is much easier than cleaning
a spot to use it. That part's half-done. ;-) 3) Get the only WinXP box
with a parallel port (one and the same, I run Linux on the other 9 PCs
in the house) set up so the Xeltec has a "new home."
So, I thought I'd document my process of learning low-level PLDs and
make a webpage of "PLD programming when your IQ == your shoe size" for
others that want to use this for classic computers to save board space
(and have the ability to fix something through programming in addition
to soldering - I always love a "Plan B") and then I'm going to integrate
that into my design.
> The way you run Keil's emulator is similar to what I was talking about.
> If there was a bit more integration between the two it should run
> smoother and boot faster. That can't be done without either integrating
> OS functions in the emulator (ala DECB) or re-writing the emulator. Not
> sure which would be best, but just paring down FreeDOS to a bare minimum
> might be all that's needed. Just add some additional functions (such as
> an improved video mode) to the emulator to create a virtual CC4.
This is an idea I had long ago, but never had enough smarts to implement
it -- what if there was an OS/Emulator/Etc. that *fit in the BIOS* --
flash the BIOS with all the CoCo4 goodness, and it would boot instantly
into that environment. Get rid of the PC "personality" entirely, but
you'd still have access to all that nice fast hardware.
There is an opensource project called (IIRC) "OpenCore" that means to do
just that, but it's centered around Linux.
It would take people a *lot* smarter than me to take that idea and turn
it into "the ultimate CoCo4 emulator" ... but hey, I did say it was only
an idea... if PC's spoke 68ish instead of "Z80 on 'roid rage" ( ;-) )
I'd have attempted this long ago...
Personally, my "ultimate CoCo4" concept would probably center around the
Core processors used in the PS3, but either 1) a 6x09 emulation layer
built into the BIOS or 2) a Linux install that boots quick enough
straight into MESS that you don't see it. ;-) I'm just sayin'...
 PC BIOS flash "gone bad" -- doesn't happen often, but I was gosh
darned happy the flash chip is socketed on Shuttle computers...
 In a virtual WinXP environment running in VirtualBox on Linux...
Wasn't sure how the older software (designed for 3.1/95/98) was going to
deal with a virtual XP, but I did get it running. I think I could even
tell VirtualBox to "take over" the parallel port... if that PC had one. :-(
 I do plan on trying to figure out how to "step up" from CUPL to
Verilog or VHDL "someday" and assuming I'm smart enough to figure it out
(doubtful) that will get integrated into my tutorial... but that's
another show. ;-)
[3b] My hat's off to the guys who made the CoCo3FPGA; it's far beyond
what I can comprehend -- but most FPGA tutorials [ that I've found ]
start with "This is how you design a "simple" IDE interface in a 2500
bazillion logic block FPGA & have access to your own board fab" and I'm
completely lost already. I'm not looking at that level of device
programming - I just want to do some low level address decoding for my
CoCo board and want to deal with them in a low level manner.
 The few devices for USB interfacing that seem "simple" have included
_all_ the brains in the chipsets. Yes, that's a good thing, but it
doesn't mean that USB is simple, it's that someone figured out how to
make a complex interface issue simplistic enough for classic computers
(read: microcontrollers), probably through an FPGA that I'm not smart
enough to understand. ;-)
More information about the Coco