[Coco] Long: Semi-ontopic parallel ramblings of a drunk... (was: Any news on the so called CoCo4 or Next CoCo

[Roger Merchberger]

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 [1] (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 [2] 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? [4]

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'...

Laterz!
"Merch"

Bootnotes:

[1] PC BIOS flash "gone bad" -- doesn't happen often, but I was gosh 
darned happy the flash chip is socketed on Shuttle computers...

[2] 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. :-(

[3] 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.

[4] 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. ;-)