USB
10 messages · 2004-07-19 → 2004-08-04 · Yahoo Group era · View archive on archive.org
Participants: aralbrec, Jeff, James Diffendaffer, Jeff Burrell
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. (no subject)
Jeff · Mon, 19 Jul 2004 03:35
Alvin;
Lots of catsup, ketchup, catch up or whatever.
Timers - I expect that any and all logic of any consequence will be
incorporated into the FPGA.
The VGA interface would be a separate board on the expansion bus
(YABUS or whatever) that would basically be an I/O device. I don't
envision the Z80 having direct access to the video memory via a
dual port or pseudo dual port memory arrangement. The memory would
be accessed by I/O to a dedicated set of interface registers. This
makes some level of intellegence in the video controller chip
vital. I agree that the sync signals from this board should be made
available to the expansion interface FPGA.
I guess I wasn't clear about the various memory devices:
AT29C040A - program storage only. Possibly used in part for a flash
disk.
AT17XXXX - flash based serial configurator for the FPGA. A 200K
gate FPGA will need 4Mbits of configuration memory. This
configurator will automagically configure the device when the
interface is powered up so no other logic will be needed.
AT45DB0XX - SPI serial flash device. Could be used for flash disk.
These devices CANNOT be used to configure the FPGA.
Keyboard and mouse ports:
I was hoping to use the proposed USB interface for these functions,
but it would cost little to add them to the board.
I was expecting that once the interface was built, we would start
changing the 2068 firmware to support these devices. I thought that
there would be a "compatibility mode" which would use the resident
firmware and would provide maximum compatibility for legacy software.
If the user wanted to use any of the expanded features, other
firmware would be activated.
I haven't given much thought to an IBM compat keyboard interface, but
there is no reason it could not be included on the PCB. I would
prefer to have a FSM handle the peripherals and allow the processor
to just read a series of registers to determine mouse position or
keyboard status.
ADCs and DACs? 8 bits? How many? What sample rate? Easy to add
but providing the PCM data could be challenging until the background
DMA controller is complete. Maybe these could be on an expansion
card.
I am not too concerned about making the PCB work first time around.
The FPGA is designed to operate with 5V systems so the data busses
are the major concern. A previous email has already mentioned the
74HCT245s for the data bus. Most of the other signals from the
computer are input only so should not be a problem. The other signals
are interrupts and control signals that can operate through pull-ups
and so should be OK.
We could use a CPLD instead of discrete logic, but I am concerned
about the voltage levels into/out of the CPLD. I can look into this.
Your idea of using this for the twisting is very intriguing.
Unfortunately, the higher density parts are only available in PQFP or
similar packages. 144 pin and 160 pin sockets are available at $27
or more per. I think that the Xilinx parts only come in the 208 and
144 pin packages. One major item will be the number of pins needed
for all of the functionality. My preliminary design calls for the
processor, memory, IDE, and expansion bus (YA or short bus) to all
have dedicated non-overlapping pins. This is to allow maximum
flexibility for multi-tasking by the hardware. For instance, it
would be theoretically possible for the 2068 to be running code from
the onboard RAM and communicating with the an expansion bus peripheral
while the FPGA DMA controller is simultaneously transferring data from
the IDE interface to the expansion board RAM. Also, dedicated pins
make routing and loading much less of an issue.
All of this is a long winded way of saying that we probably won't
have a socketed chip and that blowing it up will require replacing it.
The Xilinx free tools will target even the 200K gate Spartan II. I've
already tried fitting a Z80 core into one (used only about 40% of the
chip).
I am afraid we will need an external supply. The current needed by
a full up interface just can't be supplied by a stock 2068.
As for booting the machine: The FPGA will probably take 200 to 400ms
to configure. During this period, the 2068 will probably have come
out of its reset and will be booting up. After the FPGA is
configured, it will probably need to issue a reset to the 2068 again
via a FSM in the FPGA. After this second reset, the FPGA will have
control via the /BE signal and the machine will start booting from
the firmware on the expansion. I haven't looked into this too
deeply, but I think that there is and FPGA signal that could be used
to hold the 2068 in reset until after the FPGA has been configured.
I like the reset FSM because it gives us more control over the
behaviour of the machine during reset. I fully expect the 2068 never
to need the home bank EEPROMs when the expansion is attached and would
argue that it not be used.
One of the problems with doing these types of designs is limiting the
possibilities to a sufficiently small set that will not paralyze
implementing this thing. One example is the flash. I am planning on
using an AT29C040A for holding the firmware. The only problems with
doing this is that they are much slower than the RAM and they take
part of the address space. If we have a boot FSM in the FPGA another
option becomes available. We could replace the '040 with another SRAM
(now a total of 2M bytes of SRAM) and put a AT45DB0XX on the board.
The boot FSM could then keep the 2068 in reset while the boot code
is read from the AT45 and placed in SRAM. This neatly finesses
the need for the slower '040 and also provides the possibility of
2M bytes of flash storage as solid state disk drive on the board.
That much storage would probably hold a good fraction of all of the
available 2068 progams ever sold.
2. (no subject)
aralbrec · Wed, 21 Jul 2004 18:10
--- In [email], "Jeff" <jburrell7@y...> wrote:
> Alvin;
> Lots of catsup, ketchup, catch up or whatever.
This cleared up a lot. Especially the FPGA
config -- I thought you were trying to config
the chip in an unusual manner. I'll have to
fetch some datasheets and then offer up comments.
About audio: I would like the option of 44kHz
sample rates @16 bits total (one 8-bit
channel for L/R). Realistically, it'll probably
be 8kHz audio most of the time as there's only
2Mish of RAM. The application I have in mind is
something that can play Amiga mod files. I don't
know how this affects the short bus (from your
comments it sounds like you've done some figuring
on the bus's throughput and load). As you say
it might be a candidate for a plug-in board.
In the meantime while I digest your schematics,
have you got a little info on the origins of
the short bus? I know it comes from the C64
side, but I'm just curious as to its intended
use.
Alvin
3. ethernet
aralbrec · Thu, 22 Jul 2004 20:31
Hi Jeff,
I'm just going over the schematics one item at a time,
starting with the 91C96. It looks mostly correct
to me, just a couple of things:
- POWRDN must be grounded, not pulled high, for
normal operation.
- nEN16, nXENDEC can be left open as they have
weak pullups already; just something that might
help simplify layout in a small way.
- As far as I can tell, nMEMR is only there
to allow access to an attached configuration
PROM/EEPROM. I don't think it's needed at
all and could be left open.
- I don't think BALE is needed either and
can be left open.
- No receive LED :-) If you only have two
I guess you have to make a choice.
- What is the purpose of the DIP switches?
I see that the ethernet chip is connected
directly to the FPGA (I assume the 95144
is only a relic); that's good. On first
inspection, you had the short bus in there
and I was thinking you had usb, ethernet
and other things on a single bus. I gather
the short bus is just the standard C64
expansion bus.
Alvin
4. Re: [ts2068] ethernet
Jeff Burrell · Fri, 23 Jul 2004 13:29
Alvin;
Thanks for the extra eyes. I'll check out your observations.
The ethernet and USB schematics are set up as separate daughter boards with
a CPLD for glue/interface logic.
The DIP switches allow for I/O address selection.
The short bus is a (relatively) standard C64 peripheral bus. I expect the FPGA will handle the bus translation.
aralbrec <[email]> wrote:
Hi Jeff,
I'm just going over the schematics one item at a time,
starting with the 91C96. It looks mostly correct
to me, just a couple of things:
- POWRDN must be grounded, not pulled high, for
normal operation.
- nEN16, nXENDEC can be left open as they have
weak pullups already; just something that might
help simplify layout in a small way.
- As far as I can tell, nMEMR is only there
to allow access to an attached configuration
PROM/EEPROM. I don't think it's needed at
all and could be left open.
- I don't think BALE is needed either and
can be left open.
- No receive LED :-) If you only have two
I guess you have to make a choice.
- What is the purpose of the DIP switches?
I see that the ethernet chip is connected
directly to the FPGA (I assume the 95144
is only a relic); that's good. On first
inspection, you had the short bus in there
and I was thinking you had usb, ethernet
and other things on a single bus. I gather
the short bus is just the standard C64
expansion bus.
Alvin
Yahoo! Groups SponsorADVERTISEMENT
---------------------------------
Yahoo! Groups Links
To visit your group on the web, go to:
http://groups.yahoo.com/group/ts2068/
To unsubscribe from this group, send an email to:
[email]
Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
---------------------------------
Do you Yahoo!?
New and Improved Yahoo! Mail - Send 10MB messages!
5. oscillators + fpga config
aralbrec · Sat, 24 Jul 2004 08:49
It's possible to derive all clock signals from
a single 60MHz (eg) oscillator. The Spartan II
has DLLs on chip that can synthesize various
clocks by multiplying by 2 and dividing by 1.5,
2, 2.5, 3, 4, 5, 8, 16. You can also cascade
DLLs to get all sorts of combinations. With
a 60MHz oscillator attached to the fpga,
it's a simple matter to get 20MHz for the
ethernet chip and 12MHz for the USB. The
quick clock on the fpga chip is likely needed
to generate proper timing for read/write/cycle
time etc. for attached ethernet, etc.
It's always nice to get rid of extra crystals
that can inject noise everywhere.
For fpga configuration, it *is* possible to
use the 512kx8 AT29C040 part if the fpga
is configured in slave parallel mode. The
arrangement I am thinking of again uses
the CPLD (aside from its other possible
uses as level converter between fpga and retro
computers and signal router so that the same
physical board can be attached to any number
of retro computers). The 8-bit data bus
used during fpga config can double as the
fast SRAM bus (if the flash sits in the 2MB
space) or it can be used as a dedicated bus
attached to slower flash. The CPLD would run
the slave parallel config, using the clock
generated by the attached retro computer
(in the 2068's case, the 3.5MHz clock).
In this scenario, the CPLD would also contain
the RESET FSM you have spoken of, making sure
the expansion board starts up in an orderly
fashion and isolating the board from the
computer if necessary, or possibly holding
the computer in reset until the expansion
board is ready to go. Perhaps the CPLD
could be written a command to perform
a reset and config of the attached board
at any time.
Now, here is what I like about this. Using
the usual config arrangement, one needs a PC
to program the FPGA config into the attached
flash at least for the first time the board
is used. Once the config is in there one
should be able to program the config flash
without the PC. Unless you make a mistake
in which case you're back to the PC.
However, by giving the CPLD access to the
config flash and the responsibility for booting
up the board, you can use it to program the
flash without actually configing the fpga first.
I would attach a disable switch whose intention
is to disable the expansion board. If the
switch is not asserted, the CPLD would boot
up everything as usual. If it is asserted
it keeps the expansion board in reset and
releases the computer's reset so that
it can boot up. A computer program
can then use the CPLD to program an
fpga config into the flash. This brings
visions of distributing the expansion board
with a tape containing a 256K config program
(in pieces, of course) and if that isn't ironic
in some way, I don't know what is :-)
Alvin
6. (no subject)
aralbrec · Wed, 28 Jul 2004 19:16
--- In [email], "Jeff" <jburrell7@y...> wrote:
> Keyboard and mouse ports:
> I was hoping to use the proposed USB interface for these functions,
> but it would cost little to add them to the board.
...
> I haven't given much thought to an IBM compat keyboard interface,
but
> there is no reason it could not be included on the PCB. I would
> prefer to have a FSM handle the peripherals and allow the processor
> to just read a series of registers to determine mouse position or
> keyboard status.
I've been going through the SL811HS and related datasheets
and it looks like I'll have to read through the USB spec
to understand completely how everything works. But it
appears to me that usb communication will involve a lot
(relatively) of processor intervention and might mean
tracking key presses and mouse movements would have to
be done in software. Correct me if I'm wrong. (I've
also been looking at NatSemi's USBN9603 usb controller.
Have you checked that out?)
For that reason, I'd prefer to use dedicated ports for
mouse/keyboard. Two PS/2 connectors? One for keyboard
and one for mouse. They're straightforward to add
and the serial protocols are easy to handle in the FPGA.
Each PS/2 port needs two lines (data, clk) run to the
FPGA, with both having 4.7k pullups. A PS/2 mouse port
is preferred because PS/2 mice run on 5V but other
serial mice sometimes expect +-12V. The other PS/2
port could be an AT keyboard connector instead; maybe
that's better because then it's clear which is which.
Alvin
7. (no subject)
aralbrec · Fri, 30 Jul 2004 07:57
--- In [email], "aralbrec" <aralbrec@i...> wrote:
> About audio: I would like the option of 44kHz
> sample rates @16 bits total (one 8-bit
> channel for L/R). Realistically, it'll probably
Don't know why I didn't think of this sooner,
but a couple of PWM D/As generated by the
FPGA is practically free. Two channels
for stereo to some RCA connectors just needs
two output pins and a couple of op-amps. I'd
also like the combined output to be optionally
played through the 2068's internal speaker,
which can be done with another op-amp + diode
connection to the SOUND pin (or maybe the EAR
pin, if that's possible, for the sake of spectrum
compatibility). One more FPGA pin is needed
to turn this op-amp on/off.
I think a single 1-bit ADC would also be
helpful.
Alvin
8. USB
James Diffendaffer · Tue, 03 Aug 2004 16:01
Pardon my intrusion.
Most USB chips require you manage most of the details the USB protocol
which has quite a bit of CPU overhead. It also requires a lot of code
to support. Actually, some USB "modules" use an 8 bit CPU just to
manage the protocol.
There is one chip I looked at for a project that handled a lot of the
USB protocol chores itself and for a low end machine you'd definately
want that. The company patented the technology so they should be the
only ones with it. I *think* TransDimension is the manufacturer but
I'm not sure... it's been a while.
--- In [email], "aralbrec" <aralbrec@i...> wrote:
> --- In [email], "Jeff" <jburrell7@y...> wrote:
>
> I've been going through the SL811HS and related datasheets
> and it looks like I'll have to read through the USB spec
> to understand completely how everything works. But it
> appears to me that usb communication will involve a lot
> (relatively) of processor intervention and might mean
> tracking key presses and mouse movements would have to
> be done in software. Correct me if I'm wrong. (I've
> also been looking at NatSemi's USBN9603 usb controller.
> Have you checked that out?)
>
> For that reason, I'd prefer to use dedicated ports for
> mouse/keyboard. Two PS/2 connectors? One for keyboard
> and one for mouse. They're straightforward to add
> and the serial protocols are easy to handle in the FPGA.
> Each PS/2 port needs two lines (data, clk) run to the
> FPGA, with both having 4.7k pullups. A PS/2 mouse port
> is preferred because PS/2 mice run on 5V but other
> serial mice sometimes expect +-12V. The other PS/2
> port could be an AT keyboard connector instead; maybe
> that's better because then it's clear which is which.
>
> Alvin
9. Re: USB
Jeff · Wed, 04 Aug 2004 01:54
James;
No need to apologize. One of the problems with designing something
is knowing what parts are available.
You are correct about the CPU overhead for USB. Given the number
of peripherals available (and the fact that I've wanted to play with
USB drivers out of the Windows environment) I thought a USB host
would make a good addition to the interface. It's probably not the
best use of board space in general but ...
The TransDimension UHC124 is a very interesting chip. I'm just
starting to look into it and haven't determined how to get my hands
on one yet.
--- In [email], "James Diffendaffer"
<jdiffendaffer@y...> wrote:
> Pardon my intrusion.
>
> Most USB chips require you manage most of the details the USB
protocol
> which has quite a bit of CPU overhead. It also requires a lot of
code
> to support. Actually, some USB "modules" use an 8 bit CPU just to
> manage the protocol.
>
> There is one chip I looked at for a project that handled a lot of
the
> USB protocol chores itself and for a low end machine you'd
definately
> want that. The company patented the technology so they should be
the
> only ones with it. I *think* TransDimension is the manufacturer but
> I'm not sure... it's been a while.
>
>
> --- In [email], "aralbrec" <aralbrec@i...> wrote:
> > --- In [email], "Jeff" <jburrell7@y...> wrote:
> >
> > I've been going through the SL811HS and related datasheets
> > and it looks like I'll have to read through the USB spec
> > to understand completely how everything works. But it
> > appears to me that usb communication will involve a lot
> > (relatively) of processor intervention and might mean
> > tracking key presses and mouse movements would have to
> > be done in software. Correct me if I'm wrong. (I've
> > also been looking at NatSemi's USBN9603 usb controller.
> > Have you checked that out?)
> >
> > For that reason, I'd prefer to use dedicated ports for
> > mouse/keyboard. Two PS/2 connectors? One for keyboard
> > and one for mouse. They're straightforward to add
> > and the serial protocols are easy to handle in the FPGA.
> > Each PS/2 port needs two lines (data, clk) run to the
> > FPGA, with both having 4.7k pullups. A PS/2 mouse port
> > is preferred because PS/2 mice run on 5V but other
> > serial mice sometimes expect +-12V. The other PS/2
> > port could be an AT keyboard connector instead; maybe
> > that's better because then it's clear which is which.
> >
> > Alvin
10. Re: USB
James Diffendaffer · Wed, 04 Aug 2004 20:47
I had to ask for a referal to a local rep. They could get samples and
such. That was as far as I got with it though.
--- In [email], "Jeff" <jburrell7@y...> wrote:
> James;
> No need to apologize. One of the problems with designing something
> is knowing what parts are available.
>
> You are correct about the CPU overhead for USB. Given the number
> of peripherals available (and the fact that I've wanted to play with
> USB drivers out of the Windows environment) I thought a USB host
> would make a good addition to the interface. It's probably not the
> best use of board space in general but ...
>
> The TransDimension UHC124 is a very interesting chip. I'm just
> starting to look into it and haven't determined how to get my hands
> on one yet.
>
> --- In [email], "James Diffendaffer"
> <jdiffendaffer@y...> wrote:
> > Pardon my intrusion.
> >
> > Most USB chips require you manage most of the details the USB
> protocol
> > which has quite a bit of CPU overhead. It also requires a lot of
> code
> > to support. Actually, some USB "modules" use an 8 bit CPU just to
> > manage the protocol.
> >
> > There is one chip I looked at for a project that handled a lot of
> the
> > USB protocol chores itself and for a low end machine you'd
> definately
> > want that. The company patented the technology so they should be
> the
> > only ones with it. I *think* TransDimension is the manufacturer but
> > I'm not sure... it's been a while.
> >
> >
> > --- In [email], "aralbrec" <aralbrec@i...> wrote:
> > > --- In [email], "Jeff" <jburrell7@y...> wrote:
> > >
> > > I've been going through the SL811HS and related datasheets
> > > and it looks like I'll have to read through the USB spec
> > > to understand completely how everything works. But it
> > > appears to me that usb communication will involve a lot
> > > (relatively) of processor intervention and might mean
> > > tracking key presses and mouse movements would have to
> > > be done in software. Correct me if I'm wrong. (I've
> > > also been looking at NatSemi's USBN9603 usb controller.
> > > Have you checked that out?)
> > >
> > > For that reason, I'd prefer to use dedicated ports for
> > > mouse/keyboard. Two PS/2 connectors? One for keyboard
> > > and one for mouse. They're straightforward to add
> > > and the serial protocols are easy to handle in the FPGA.
> > > Each PS/2 port needs two lines (data, clk) run to the
> > > FPGA, with both having 4.7k pullups. A PS/2 mouse port
> > > is preferred because PS/2 mice run on 5V but other
> > > serial mice sometimes expect +-12V. The other PS/2
> > > port could be an AT keyboard connector instead; maybe
> > > that's better because then it's clear which is which.
> > >
> > > Alvin
Indexed under
Pico / modern interfaces (UnoDos, etc.) · Hardware projects & new boards