Re: [colorforth] ForthBox and FPGA (was: Ideas)

["Samuel A. Falvo II" <kc5tja@xxxxxxxx>]

On Monday 01 March 2004 12:08 pm, Jecel Assumpcao Jr wrote:
> I wonder why you aren't thinking of a FPGA based solution like you
> mentioned in another thread? Don't let the high prices of development
> kits discourage you: I build a board with the same functionality as a
> nice $280 kit from Xess and it only cost me $30. This board started
> life as a ColorForth computer, though now it is a Smalltalk machine.

Because, well, it's expensive.  How did you pull off a $250 savings?  For 
me program an FPGA chip, I need the programming and simulation software 
to do it with.  That requires Windows.  There is not a single VHDL or 
Verilog simulation tool available for Linux that is in any way usable (I 
know, I tried).  Windows costs me money.  The programmer kit costs me 
money.  And for what, maybe 10 kits?  AT MOST?  It's a net loss.

Also, I'd like to see the average homebrewer these days hand-solder a 
*BGA* chip.  It's not going to happen.

I recognize this kind of thing is going to be a net loss for me anyway I 
slice it.  Once I saturate the quantum-sized market with 
slow-but-utterly-reliable-and-hackable computers, I won't have a market 
to sell any more to.  My goal is to *minimize* the losses.

Maybe using an FPGA is the solution to this.  Maybe it's not.  My initial 
estimates indicate it's not.  We'll see.

> Doing a new project around old technology is not a good idea unless
> you are only after a learning experience and don't mind spending more
> than you would for a better and more modern alternative. For example,

Old technology has a huge advantage over new: it's tangible.  You can 
touch it, play with it, probe it with oscilloscopes and voltmeters, and 
otherwise hack it however you want.  And you don't need expensive 
Verilog or VHDL programmers/simulators to do it with.

> the cheapest memory is currently the SDRAM chips which are very hard
> to interface to older microprocessors.

They are very hard to interface to ANY microprocessor.  I've reviewed 
their bus timings.  I can't fathom why Chuck would want to support them, 
with the sole exception of their ubiquity.  I wonder how much time he 
really spent getting SDRAM to actually work on his chips.

Which is why you use a 65816 coupled with a 512Kx8 SRAM chip.  It's not 
expensive, and it gets the job done.  I mean, we're talking about FORTH 
-- 512K of working RAM is insanely huge by Forth standards for most any 
task this box will be used for.  The exceptions are image processing, 
audio processing, and data acquisition, *none* of which this box is 
explicitly designed for anyway.

For me to support SDRAM, I'd need to implement something along the lines 
of a cache controller in that FPGA chip.  Ouch.  That's damn complex to 
do.  Why?  Because the instruction stream and the memory the CPU is 
reading/writing from/to are 99% likely to NOT be in the same DRAM line, 
much less the same page.  Thus, to get any kind of reasonable 
performance, I need to do really bizarre things, like write queues and 
such.  Icky.  I don't like it.  Software-managed memory hierarchy is 
invariably the least-complexity and minimum parts count solution.  It 
also results in the maximum software performance.

> A Xilinx Spartan IIe XC2S50E-6TQ144C costs $13.50 in single quantities
> and there are competitive alternatives from Altera and others. Since

I've researched these, and while they are rather cool, the idea of having 
someone build a computer as a *kit* requires these same people to feel 
comfortable soldering 50mil and 25mil wide pin pitches (1 mil = 0.001 
inch for those unfamiliar with the term 'mil').  And this is assuming a 
quad flat-pack design.  If it's J-lead, PGA, or BGA, things get hairly 
*real* quick.  Sockets aren't an option; besides introducing way too 
much capacitive loading (thus limiting the top frequency it can run at 
and making high-speed operation very flaky), the sockets are often times 
more expensive than the whole finished unit put together.

Moreover, the documentation involving the 6502 and 65816 already exists.  
No, it's not a MISC chip.  But it is available, and I don't have to 
write data sheets for it.  I don't have to write whole chapters on how 
to program the chip.  Etc.  The 6502/65816 already have tons of support 
chips on the market (they can directly use any support chip designed for 
the 68xx series of MPUs).  I don't need to make my own bus architecture.

> In my case a color TV output only cost 4 resistors and an RCA
> connector, while a VGA output was 12 resistors and a DB15 connector.

Are you doing PWM to get the color phase signals and lumanence signals in 
a 1-bit DAC-like construct?  That'd be impressive.  Otherwise, such a 
simple circuit would otherwise only be capable of monochrome (note: at 
the time I wrote this, I haven't checked out your link.  I'll do that 
afterwards); thus, you'll get better visual definition if you use a true 
monochrome TV (since they have a true 6MHz video bandwidth, and not 
4MHz).

Besides, I didn't say that a VGA's output circuitry involved less 
components.  I said it was simpler.  No composite waveforms to deal 
with.  Anyone looking at the circuit can understand exactly what's going 
on by inspection only.  It's trivial, despite the extra components.

Besides, there are MANY more VGA monitors in existance than TVs, *AND* 
they are universal, no matter what country you happen to reside in.  
Therefore, there is no NTSC, PAL, or SECAM contention to go around.  For 
me, supporting the VGA standard is a no-brainer.

--
Samuel A. Falvo II


---------------------------------------------------------------------
To unsubscribe, e-mail: colorforth-unsubscribe@xxxxxxxxxxxxxxxxxx
For additional commands, e-mail: colorforth-help@xxxxxxxxxxxxxxxxxx
Main web page - http://www.colorforth.com