[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Apple II VGA Video Generator Card Project
Jorge Chamorro Bieling wrote:
> What's the size of these memories ?
The smallest Spartan 3 FPGA that costs about $10 has 8K of BRAM.
Should be only enough for a single HGR screen. The bigger XC3S200 (about
$15) has 24K of BRAM and enough gates to contain ALL of Apple 2
including the 6502. That's the one I've used in the FPGApple.
XC3S200 plus an old cache chip is probably the cheapest solution.
> 1.- Shared RAM access is constrained to certain time solts, and
therefore, both parts of the system must run synchronously which means
more design effort and multiplexing circuitry.
True, but very easy to do. Using the programmable logic all the
complexity boils down to a few lines of Verilog/VHDL.
You see it as: "Standard memory is cheaper, and there's a way to go with
it". And then you're right. still... hmmm I see the dual-ported ram
design as bright and clean, and the other as a pain to suffer because
the dual port ram happens to be so expensive.
If your goal is the "cleanest" design possible, I rest my case.
However I do design hardware for a living. For decades... And my goal is
always to get the right functionality out of minimum hardware both in
terms of cost and number of chips.
2.- The standard memory approach makes the design phase0-dependant, and
this means it won't neccesarily work in the Apple IIc+. At least without
additional care == design effort. And then only if it's worth it. And
what would happen if the Apple IIc+ was overclocked ?
Last time I looked at a IIc it didn't have any slots, so a "card" for a
IIc would have to be a separate design one way or the other.
Also it doesn't have to be phase0-dependant. Consider this design:
1. Regular memory is used with 20 nS access cycle - a dime a dosen.
2. We run a 28 MHz clock that doesn't have to be syncronized to phase0.
3. VGA uses 14 MHz shift clock in 40 char mode (and normal graphics
modes) and 28 MHz for 80 col/double HGR modes. Then it needs to read a
byte every 7 clocks. So we designate the first cycle out of every 7 for
video access. If the CPU wants to read/write memory at the same time, it
will have to "wait" at most 35 nS. Which means no wait at all - all done
in the same phase0 cycle. We want to latch the data read from RAM so
that it is stable when the CPU actually reads it.
This is very easy to implement even with standard 74xx parts.
-Alex.