[Coco] RE:Hardware stuff

[David Gacke]

Hi Frank,

Yes, currently the plan is to make a little daughterboard out of it.

I thought about doing it in an FPGA, but there really wouldn't be much
of a point. I can max out the bus with the dsPIC since it runs at 30
MIPs and the cost of the part is around $10 vs. the $38 for the Xilinx
FPGA I'd have to use to accomplish the same thing. (I have Xilinx tools,
so I stick to their parts) 

Anyway, this doesn't include the actual board cost, etc.

I've also been thinking about doing a GIME in FPGA. I thought about
spinning a similar small board but take an FPGA to emulate the GIME and
a small ARM7 microcontroller and have both a 6809 cpu emulation mode and
an arm mode.

This gives you the advantage of an emulated cpu banging against a real
piece of hardware so it'll emulate way faster, plus you can then get USB
host functionality, and even ethernet. Not to mention a C compiler,
ucLinux support, etc.

To be honest, you'd end up gluing an arm7 on a daughterboard to get USB
host support anyway, so why not use it as a pseudo 6809?

Dave



-----Original Message-----
From: coco-bounces at maltedmedia.com [mailto:coco-bounces at maltedmedia.com]
On Behalf Of farna at att.net
Sent: Friday, August 06, 2004 10:34 PM
To: coco at maltedmedia.com
Subject: [Coco] Re: Coco Digest, Vol 10, Issue 17

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

-- 
Coco mailing list
Coco at maltedmedia.com
http://five.pairlist.net/mailman/listinfo/coco