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

[Little John]

Roger,
We weren't actaully saying that we'd like to see the Parallel Port Vanish... 
only that we are surprised that it simpy hasn't.
But of course, in addition to what you mention, there are many industrial 
applications that still require the Parallel Port, ISA Slots and 9-Pin 
serial (or even 25-pin serial) ports. In fact, these industrial applications 
are the reason that you can still buy a CURRENT production core i5/7, or AMD 
motherboard with ISA slots - it is often cheaper to spend $400-$1000 on an 
actual new mobo w/isa slots, etc, than to replace all of that industrial 
control equipment with some that uses modern interfaces...
Plus, using the ISA slots does have some timing advantages for certain 
applications in the industrial world... or so I've been told.
JohnT

----- Original Message ----- 
From: "Roger Merchberger" <zmerch-coco at 30below.com>
To: "CoCoList for Color Computer Enthusiasts" <coco at maltedmedia.com>
Sent: Saturday, October 23, 2010 9:15 PM
Subject: [Coco] Long: Semi-ontopic parallel ramblings of a drunk... (was: 
Any news on the so called CoCo4 or Next CoCo


> 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. ;-)
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco