[Coco] Re: Coco Digest, Vol 10, Issue 17

[farna at att.net]

1. Thanks for being patient with your answers John! I understand most of the concepts, but have no indepth knowledge of chips and their limitations. Thanks for the explanations. I know just enough to grasp what you're saying and doing! It looks like a truly useful small board computer could be made with the 6309 and GIME in FPGA. 

There was once a mini board PC (XT and AT compatibles, not sure if a 386 version was ever made) that was on a board the size of a 5.25" floppy drive. The main board had a floppy controller and serial I/O, along with memory and other essentials like keyboard and I think CGA video... but video may have been on a daughter board for the first models. There was a daughter board that stacked on top of the main board. IIRC the connector was along an edge and was a row of pins. The daughter board had the the male pins and a matcing female socket on the other side of the borad so a third board could be stacked on too, but I don't recall any third boards. It was made this way so the entire computer could be housed in a single full height floppy case, which would hold one half high floppy and the two necessary boards for a fully functioning XT or AT computer. A case that staked two full height floppies would be needed to use a hard drive. The board was designed to screw to the top of the floppy drive. I'm sure a fully functioning CoCo with all necessary I/O could be built on one 5.25" floppy size board, even with full IDE and floppy controllers (using one of the super I/O chips). It could probably be done on a 3.5" floppy size board if it stuck with USB I/O for everything (at least mass storage -- a PS/2 keyboard connector would be nice, but that could be USB as well under OS-9, DECB might be a problem, but maybe not for some of you guys! I just do a little line number BASIC... or rather DID!!). If it's easy to interface to and program, and inexpensive but more powerful than the Stamp or PIC computers, I think it would be a winner. 

One reason I said keep the joystick type ports (wouldn't have to be for joysticks) is because they are D/A converters. I worked up a prototype "glass dashboard" in BASIC using the joystick ports for inputs. I forget what I used the button inputs for, I'm thinking as counters for the speedo and tach -- it was a logn time ago. The pot ports were used for variable resistance type sending units -- fuel and temp gauges, as well as oil pressure. Just had to know the range of the stock automotive sending units. There wasn't an adequate display to use, and the CoCo board is a bit big to mount under a dash. Now there are $100 5" LCD displays with composite inputs... still, the board is to big and a PIC or Stamp doesn't seem to have the easy to program I/O. Maybe if I took the time to learn more about them, but the project died for me a long time ago. Now I'd reconsider, but don't want to learn totally new systems like the Stamp. A digital dash could be retailed for around $500 that would blow anything currently available out of the water! I had envisioned two modes: "performance" with a digital representation of analog gauges, and "cruising" with simple number displays and trip computer type info. All I ever programmed was the basic "cruising" display without the trip computer -- just inputs that would display labeled numbers when the sending units changed. I didn't quite figure out what to use for a tach signal, but used a magnetic switch for the speedo input (with a magnet on the driveshaft, like cruise control). 

2. Dave, that "daughter board" CPU enhancement sounds fantastic! I'm assuming you would eventually make a board that would just stick down into a socket where the 6809 was anyway, even for your own project. If you're not interested in pursuing that any further than something for yourself, how about passing the info to Mark for possible development? Mark doesn't make much from any of the projects he does, it's mostly a hobby that at least pays for itself (like my AMC magazine), and provides other enthusiasts access to neat hardware they otherwise couldn't get. 

3. If you're using this for telescope control (the FPGA thing), why worry with VGA output? Why not limit it to composite (NTSC)? There are inexpensive NTSC signal LCD displays out now, check in automotive video catalogs/stores. Would they have enough resolution?? Coding would be easier and less complicated. 


--
Frank Swygert 
Publisher, "American Independent 
Magazine" (AIM) 
*Elite* publication for those 
interested in all 
aspects of AMC 
history,performance,restoration,etc 
. 
(AMC,Rambler,Nash,Hudson,Jeep,etc.) 
http:farna.home.att.net/AIM.html 
(free download available!) 



-------------- Original message from coco-request at maltedmedia.com: -------------- 

> Message: 5 
> Date: Fri, 06 Aug 2004 21:44:33 -0400 
> From: jdaggett at gate.net 
> Subject: Re: [Coco] Re: Coco Repack 
> To: CoCoList for Color Computer Enthusiasts 
> Message-ID: <4113FBC1.17752.123ED8 at localhost> 
> Content-Type: text/plain; charset=US-ASCII 
> 
> Frank 
> 
> The 6809E and 6309E are pure digital curcuits. The limiting factor 
> for speed is load capacitance for various logic gates. 
> 
> True the CMOS parts as well as the Motorola NMOS parts are 
> limited to not much more than 4 to 5 MHz. The 6809 might squeeze 
> out a bit more if you raise the VCC up to 6 to 6.5 VDC and heat sink 
> the chip. The biggest concern is switching speeds is to get the heat 
> off the die. The injection molded plastic packages do not do as good 
> a job as the older ceramic packages did. 
> 
> Overall I do agree that around 6 to 8 MHz is the ultimate limit. 
> 
> james 
> 
> > > Message: 3 
> > > Date: Fri, 06 Aug 2004 11:30:48 -0400 
> > > From: jdaggett at gate.net 
> > > Subject: Re: [Coco] Re: Coco Repack 
> > > To: CoCoList for Color Computer Enthusiasts 
> > > Message-ID: <41136BE8.14904.E66F7 at localhost> 
> > > Content-Type: text/plain; charset=US-ASCII 
> > > 
> > > Frank 
> > > 
> > > You are ringt if a FPGA version of the 6x09 were incorporated 
> > > along with an FPGA version of the GIME chip, breaking the 10 MHz 
> > > barrier will be no problem. Speed control can be done with external 
> > > clock ship. One by ICT can derive 1000's of frequencies from a 
> > > single crystal frequency. In fact the one chip that I was looking 
> > > at, from a 28.6868 MHz cyrstal I can derive over a 1000 different E 
> > > and Q Clocks for the CPU from 400 KHz to 19 MHz. 
> > > 
> 
> ------------------------------ 
> 
> Message: 7 
> Date: Fri, 6 Aug 2004 20:54:49 -0500 
> From: "David Gacke" 
> Subject: RE: [Coco] Re: Coco Repack 
> To: "'CoCoList for Color Computer Enthusiasts'" 
> Message-ID: <000b01c47c21$89207ff0$677ba8c0 at BITHERDER> 
> Content-Type: text/plain; charset="us-ascii" 
> 
> It's funny that all this talk about new CPUs and GIMEs got started. I've 
> been working on a new CPU of sorts for the CoCo in my limited spare 
> time. 
> 
> I've taken a Microchip dsPIC microcontroller and wired it into the 6809 
> socket. 
> 
> I've got the thing all wired up and communicating properly through the 
> 6809 CPU socket and am working on subroutines for the opcodes 
> themselves. 
> 
> This was the reason for my 0xABCD endian questions the other night. 
> 
> As far as I can tell, I should be able to complete all 6809 instructions 
> in 1 clock cycle after being loaded, plus throw in some new opcodes for 
> MMX-like functionality. 
> 
> Anyway, it's kind of a pet project currently. 
> 
> If anyone wants to see pics sometime, just drop me a note, I'll try to 
> throw them up on my website. 
> 
> 
> Dave Gacke 
> 
> ------------------------------ 
> 
> Message: 8 
> Date: Fri, 06 Aug 2004 22:15:03 -0400 
> From: jdaggett at gate.net 
> Subject: Re: [Coco] Re: Coco Repack 
> To: CoCoList for Color Computer Enthusiasts 
> Message-ID: <411402E7.10472.2E29BF at localhost> 
> Content-Type: text/plain; charset=US-ASCII 
> 
> Mark 
> 
> The MMU is real simple. It is basically a 2 to 1 4 bit wide multiplexor that 
> feeds a 
> 16x8 ram. The GIME chip uses a 16x6 ram. Most likely the package was limited to 
> 68 pins by Tandy and cost factors. Next standard size up is 84 pins in a PLCC 
> package. Given that during the 80's it was around 10 cents a pin for package 
> cost, 
> another 16 pins would have meant another $1.60 for the part. 
> 
> I really believe that many of the limitations of the GIME chip is solely due to 
> keeping 
> costs to a bare minimum. 
> 
> The VGA portion is tough to code and will occ py the most territory. That will 
> determine how big the FPGA is and how much any project like th is will 
> eventually 
> cost. Most of the free VGA cores are more modern and do not cover CGA 
> resolutions. Or they are very generic and need more work to make them compatible 
> to 8 bit buss. One of the nice things is that the software to design the logic 
> and 
> program the FPGA is free. Right now I am designing the logic for the two 
> registers 
> at $FF92/3. These registers do a dual purpose. They enable interrputs and also 
> act 
> as interrupt flags. When you read the register, the flags are cleared while the 
> interrupt remains enabled. Not a simple D-FlipFlop latch. Most of the rest of 
> the 
> registers are just that, D flipflop latches. 
> 
> Then there will be the 2 to 1 (21) bit wide multiplexor to switch between video 
> memory and program/data memory. The hardest part is keeping remebering that 
> the 6809 latches data out of the CPU on the falling edge of the Qclk and latches 
> data in to the CPU on the falling edge of the Eclk. Have to keep in mind when 
> the 
> data needs to be presented to the CPU and when the CPU is passign data to 
> external devices. After all that the first half of the Eclk cycle is doing 
> display. 
> 
> Mark, like I stated in the beginning, I got started with this to use the Coco as 
> a 
> postion controller and database for my telescopes. One thing that I wanted was 
> to 
> be able to drive an LCD panel of some type and have OS9 boot from a flash card 
> or 
> flash memory. I wanted at least 2 megs of sram and not dram. IDE interface and 
> at 
> least 4 mbytes of flash for storage. 
> 
> Real pipe dreams was to add firewire or USB and a parallel port to control a CCD 
> camera for astronomy. 
> 
> So this will start as a home project and I have no idea of where it will go. I 
> have 
> toyed with the thought of a FPGA version of the 6309 and run it at say around 15 
> to 
> 25 MHz. These are future t hings to work on. I am right now having fun with it 
> and 
> learning VHDl in the same time frame. It is amazing what you can do with CPLDs 
> and FPGAs. Some of the software development boards that I designed years ago 
> would be more flexable and easier had I done a lot of the simple glue logic in 
> these 
> devices. 
> 
> james 
> 
>