General Interface Stuff
3 messages · 2004-08-02 → 2004-08-05 · Yahoo Group era · View archive on archive.org
Participants: Jeff, aralbrec, Jarek Adamski
Preserved from the Timex/Sinclair 2068 Yahoo Group (2001–2019), which is no longer online. Text reproduced from the archive.org archive; email addresses masked.
Messages
1. General Interface Stuff
Jeff · Mon, 02 Aug 2004 17:25
All;
More up-to-date info:
I've been working on the schematics a little more lately and have
made one rather sigificant change to the memory. I have decided to
go with 30 pin SIMM modules. Given the price/density ratio they are
much better than the SRAMS. Additionally, they allow field
upgrades. I have included space for two of the modules so that, in
minimum configuration, 2MBytes can be installed and at max 16MBytes
can be installed. The most popular options would probably be 2M
(2X1M), 4M (1X4M), 8M (2X4M), and 16M (1X16M). I don't see any real
need to allow 32MBytes (two 16M SIMMS) because that would require
changes to the memory mapper in the FPGA. Besides, 32MBytes on a
2068 is just plain silly :).
The major problem with using DRAMs is in the refresh and speed
areas. Typical SIMM modules are 60ns (approx 16.66MHz) and would
probably need to be operated somewhat slower. Also, the refresh
cycles would eat into the raw access rate. It would also make
arbitrating the memory somewhat more complex and would make bringing
up the board a little more iffy - not just plug-n-play anymore. If
anyone has serious reservations about this, we can discuss them and
since I have kept all of the old files, it's easy to roll back the
design.
One of the reasons for more memory is for audio and video files for
games. Makes sense to buffer up the screens and music/sound effects
in main memory and DMA 'em to where they need to go.
I have inkluged PS2 mouse and keyboard connectors in the
interface. Nice idea, Alvin. I still expect the FPGA will
autonomously handle the keyboard and mouse interconnect.
I looked a the USBN9603 controller. Very nice part but I need to
determine if this thing can be a USB host. It says it's a "node
controller" so I'll need to re-read the USB spec to determine what
this moniker means.
I am converging on a solution for the ethernet solution that may be
controversial. I am thinking of using an RCM3700 module from Z-
World. This is an ethernet enabled Z80-ish embedded module. It is
$57 which is somewhat pricey but it only need be bought by those of
us who are truly crazy. Also, since it is a Z80-ish clone that runs
at 24MHz, it could address the desire for a higher speed
coprocessor. My desire is to allow the 2068 to connect to ethernet
not necessarily learn how to program NICs or write TCP/IP stacks or
other escoterica so this seems like a good solution to me.
As to programming the FPGA: I've also been considering how to get
the 2068 involved in this. First, I'm still a little abashed by how
expensive the configurators are, but $14/Meg a pop for a flash based
device isn't TOO bad. As to how to do it, I had been expecting that
a PC would be available for downloading the config information. We
could have the 2068 do it but the problem is mass storage - 1MBit on
tape would be a real mess to record and verify and reliability would
be very suspect. I still remember the problems with loading long
programs from tape. Let's not even talk about speed. If the
interface FPGA was somehow initially programmed and the TS could talk
to its hard drive, the joystick port could (perhaps, maybe, possibly,
conceivably) be used for this purpose. The AY chip could be
reprogrammed to allow the I/O lines to bit bash program the FPGA
config device(s). It might be a bit slow, but it would allow the
2068 to reconfig the FPGA. My guess is that it would take a bit of
extra circuitry on the interface board, but it would be small.
Enough for now.
2. Re: General Interface Stuff
aralbrec · Thu, 05 Aug 2004 09:35
--- In [email], "Jeff" <jburrell7@y...> wrote:
> I've been working on the schematics a little more lately and have
> made one rather sigificant change to the memory. I have decided to
> go with 30 pin SIMM modules. Given the price/density ratio they
Honestly I've been thinking the same thing so I'm fine
with that. I'd suggest moving the 512kx8 flash so that
it sits on the z80/host computer bus. It's just as slow
as the 2068 so this makes sense. A12..A0 come from the
cpu bus, D7..D0 to the cpu bus, A18..A13 from fpga,
ce/we/oe from fpga with a 4.7k pullup to 5V for /ce.
> As to programming the FPGA: I've also been considering how to
get
> the 2068 involved in this. First, I'm still a little abashed by
how
> expensive the configurators are, but $14/Meg a pop for a flash
based
> device isn't TOO bad. As to how to do it, I had been expecting
that
I think it's something that just has to be swallowed.
However, you could go for slave parallel configuration
using the already present 512kx8 flash. I did sketch
out a solution which would require a 40 pin PLD or
else a smaller PLD and a handful of TTL parts. I didn't
like that too much.
> a PC would be available for downloading the config information. We
> could have the 2068 do it but the problem is mass storage - 1MBit
on
I think that being able to set the configuration without
a PC is more like a requirement than a nice-to-have.
There will only ever be a handful of people who will
have the PC and the special cable to be able to set
the fpga configuration. I am certainly not planning
to go to everyone's house whenever an update
to the fpga firmware is made :-)
> tape would be a real mess to record and verify and reliability
would
> be very suspect. I still remember the problems with loading long
> programs from tape. Let's not even talk about speed. If the
I've never had much trouble with tape reliability on my
2068. The config file is < 165K in size for the 200k
gate Spartan II. Compression would likely help out a
great deal. The tape could load
in 10k (eg) pieces at a time -- I'd expect you could leave
the tape + computer running for 25 minutes and have the
job done. The necessary config tape file could easily
be obtained over the internet and recorded (or loaded
directly) from the sound card of a PC. Or an early
version could be delivered on physical tape with the
board.
This is just for the first configuration though.
That first config file might have support for
serial ports or other goodies from which a new
config file could be obtained quickly and programmed
into the serial eprom automatically by the 2068.
I think this is the only way that users will be
able to update their board's firmware as it
is developed. Even if tape is the only way
for users to do it, changing the config is
something that will happen infrequently so
leaving the computer to do its thing for 25 minutes
once in a while is not really a high price to pay
in my mind. I am not arguing against ISP -- that
needs to be available for anyone interested in
development.
As for how to do it, I'd swallow the cost of the
serial EEPROM and set the config in slave serial mode,
with a small PLD (again) controlling the whole
power-on/config logic and containing the logic to
program the EEPROM using ports mapped into the z80
i/o space. The PLD can do a couple of things:
if a disable switch is thrown (sampled when the
PLD comes out of reset), the fpga's /init
pin is held low so that the entire board remains
in reset. However the 2068 can boot up and program
the serial EEPROM. If the switch is not thrown,
the PLD can hold the 2068 in reset while the fpga
is configured and boots up.
I did sketch out a solution for this using the
2M-bit AT17LV002 and I'd guess it can be fitted
into a GAL26V10 if care is taken.
Alvin
3. Re: General Interface Stuff
Jarek Adamski · Thu, 05 Aug 2004 21:09
Hello,
--- In [email], "Jeff" <jburrell7@y...> wrote:
> I have decided to go with 30 pin SIMM modules.
Recently I've desoldered the memory chips from a 16MB
SIMM and put them on a board. Two such chips gave me
4MB DRAM.
http://www.zx.yarek.pl/upgrades/yabus.tf/
The YabusTFview4.jpg picture shows upgraded YABUS.TF
(extra board for Timex FDD 3000).
These chips can be also mounted in a 30 pin SIMM.
I didn't try to take SIMMs, as they take much space
and 4MB "should be enough for everyone". ;-)
> Besides, 32MBytes on a 2068 is just plain silly :).
Well, I have a 22MB movie made with BMP2SCR, that
could be loaded from a disk then played from memory.
But as LDI is almost fast as INI, there's no big
sense to wait to load whole movie, as it can be
played from HDD in real time. Besides, as the IDE
is supported with DMA, there's no need to preload
the movie at all.
> The major problem with using DRAMs is in the
> refresh
The DRAMs I've used have CBR refreshment with
internal counter and I made it with a 1k resistor,
100p capacitor and OR gate. Memory is refreshed by
Z80CPU, but its refresh counter is no more used.
> I have inkluged PS2 mouse and keyboard connectors in the
> interface. Nice idea, Alvin. I still expect the FPGA will
> autonomously handle the keyboard and mouse interconnect.
I'm going to produce soon YAMOD.ZXINPUT that will convert
PC keyboard and mouse. Expected price is below $30.
> We could have the 2068 do it but the problem is mass storage -
> 1MBit on tape would be a real mess to record and verify and
> reliability would be very suspect. I still remember the
> problems with loading long programs from tape.
This can be solved easy with audio CD - first goes short code
with turbo loading. Then all the data is in high speed. The
main problem with tape was the floating speed of signal. With
CD it is impossible. Should work at least 5 times faster.
Regards,
Jarek Adamski.