Skip to content

TS2068 Expansion Interface Specification

5 messages · 2004-07-08 → 2004-07-12 · Yahoo Group era · View archive on archive.org

Participants: Jack Boatwright, 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. TS2068 Expansion Interface Specification

Jeff · Thu, 08 Jul 2004 00:51

This is primarily for Alvin and Jack, but anyone else who is 
interested can chime in as well.

  I would like some input on the following specification for an 
expansion interface for the 2068.  I am looking to build up to 5 of 
these mostly because that is the minimum order from most PCB houses.  
The board will be 4 layers with silk and solder mask.  I won't charge 
for the board because I will need them for my own interface ;)

Definite:
1.  Interface logic Altera 10K20 204PQFP.  I can get 5 of these 
surplus from work.  The configuration device will be flash based to 
allow upgrading the logic.
2.  1M expansion memory expandable to 2M.  Base configuration will be 
512k Flash (AT29C040 120ns) and 512K RAM (70ns) and up to 1.5M static 
RAM in 512k increments.
3.  16 bit IDE interface for two drives
4.  Real-time clock
5.  32MHz oscillator for????

Options
1.  2@ Serial, 1 Centronics parallel port
2.  USB 1.1 host controller
3.  LAN91C96 10MBb ethernet controller with RJ45 interface
4.  Additional IDE interfaces
5.  Faster Z80/EZ80 co-processor
6.  If we are feeling froggy - 640X400 LCD display.  All Electronics 
has some of these in stock for less than 8 bucks per.  With a 32KX8 
dual port static RAM and a control FPGA you could do a B/W 
text/graphics display with rudementary BITBLT, scrolling, etc.

Add to the list of options if there is anything you think is missing.
I would appreciate if you would rank the options (if any) you want in 
order so that I can prioritize them.  There will only be a certain 
amount of surface area on the PCB, so not everything will fit.

Presently, the expansion memory would be located in the dock bank and 
consist of 8@ 8K pages.  Any of the pages could be assigned to any 
physical address in the memory space.  I expect that none of the TS 
memory would be used with the exception of the video RAM.  The OS 
would be run from the expansion memory and we would only page in the 
video RAM when needed.  Use of the dock bank is not definite, we 
could just as easily use the EXROM bank (although this would entail 
removing the EXROM chip) or the banking scheme built into the 2068.  
The main problem with the latter is that the TM is pretty cryptic on 
just how the banking scheme should be implemented.  One downside with 
using the dock bank is the inability to read cartridges.  This could 
be addressed by adding a cartridge port.

Cost is TBD but shouldn't be outrageous since most of the ICs are 
fairly cheap.  Obviously, one the hardware is done, the real job of 
writing the support software will begin.  It would be nice to use the 
Z88DK small C compiler for this especially if we could port it to the 
2068 to run natively.

2. Re: TS2068 Expansion Interface Specification

aralbrec · Fri, 09 Jul 2004 08:42

--- In [email], "Jeff" <jburrell7@y...> wrote:

Time to chime in with my wishlist.

- all peripherals are optionally interrupt driven
- all data movements optionally performed by DMA
  channels, but custom implemented ones, not the
  Z80 DMA.  As discussed in previous posts, I would
  like to operate the extended memory at high speed
  and grant access slots to the slower z80 so that
  DMA transfers can occur without slowing down the
  computer.  There should be at least one DMA channel
  capable of transfers to the slower internal memory
  of the ts2068 and this will likely result in halting
  the z80 as the z80-dma chip does.  Things to keep in
  mind: (a) refresh of internal drams and (b) the scld will
  halt the z80 clock when memory access conflicts occur.
  Jeff, the scld only fetches two bytes at a time
  from video memory (a pixel byte and an attr byte)
  and clock halting only occurs for that duration --
  DMAing to display memory will be a lot of stop.and.go.
- several timers, with the capability of syncing to
  the display.  I am thinking timers that can
  trigger when a horizontal scan line starts, etc.
  Timers might also be useful for setting baud rates,
  etc. for hw implemented on the FPGA/CPLD.  Perhaps
  these timers could also generate stop/go commands
  for the DMA channels -- haven't thought this through
  yet.
- I want to be able to write a modern, multitasking
  operating system.  I am thinking a memory expansion
  supporting the 8K segementation of the 64K space
  as Timex initiated (I think 16K as used in the
  128K Specs is too coarse and 4K pages might be
  too much to handle during context switches).  As
  you (Jeff) have already posted, during memory
  access times, A15..A13 is used to address a
  register file which will return a page number.
  That page number is augmented by the Z80's
  A12..A0 to access an extended memory space.  If
  the page number is 8 bits, we have access to
  256 pages of 8K each or 2MB memory.  Each 8k
  chunk in the Z80's 64K space can therefore
  contain any memory page and any memory page
  can appear in multiple 8k chunks at the
  same time.  To this, I want to add the ability
  to write protect a particular 8k chunk so that
  it behaves as ROM.  I would also like to add
  dirty bits and access bits for each chunk so
  that it is possible to implement a smart virtual
  memory scheme (this may never happen, but I would
  like the possibility there).  So the 8-bit page
  number, as stored in the register file addressed
  by A15..A13, loses a single bit to indicate write
  protect status, allowing 128 pages of 8K = 1MB
  memory.  Two extra i/o ports store dirty bits
  indicating when a particular 8K chunk is written
  to and access bits indicating when a particular
  8K chunk is read.  This description is not complete
  yet, as I have more modifications below.
- a 16-bit IDE interface supporting DMA modes for
  use with the internal DMA controllers.
- ethernet
- I like the idea of a respectable amount of flash
  to use as a RAMdisk.  I want a full 1MB of RAM,
  however, so I am thinking that the flash pages
  should be mappable into the 64K address space
  using a separate mechanism that takes priority
  over the extended memory mechanism.  What is
  the typical flash page size these days for
  cheap flash?
- FPGA much preferred over a CPLD, with plenty
  of room to spare for future upgrades.  A
  complicated device such as this one might be
  developed incrementally.
- I would prefer to leave internal memory alone
  and have the extended memory exist in the
  /BE space.  A couple of reasons: I want to
  maintain the option of applying upgrades to
  the machine such as Jarek's 128K spectrum
  compatibility mod, which would apply to
  internal memory only and should be disablable
  using /BE.  For the fast extended RAM, I
  am thinking of a SRAM directly connected to
  the FPGA on its own (little) bus.  Why?
  Because if those fast signals shoot down a
  pcb designed for 3.5MHz, we're going to see
  a lot of transmission line problems :-)
- a couple of serial ports.  A parallel port.
  Maybe some GPIO lines for a user port.
- I am a little divided on whether a floppy
  interface is even required if a hard drive
  is present.
- Extra logic on the FPGA to allow simulation
  of absent peripherals.  Eg: if I want to
  simulate a Kempston joystick using one of
  the ts2068's built-in joysticks, this can
  be done with a few inserted DMA cycles.
- An NMI button to bring up the operating
  system menu.
- To support a real multitasking operating
  system, I came to the conclusion several
  years ago that the NMI should be triggerd
  by a periodic interrupt.  With the NMI
  activated, the /BE hardware should have
  a separate register file containing
  operating system pages, if you see what I
  mean.  The operating system is paged in
  to deal with the interrupt.  I also
  decided that peripherals should not use
  IM2 but the NMI, with an 8-bit register
  containing one bit per peripheral to identify
  which peripheral(s) caused the interrupt.
  The operating system can then either field
  the interrupt or pass it on to a user
  process by simulating its IM mode (whether
  IM0, IM1 or IM2).
- There should be an operating system mode
  and a user mode where the operating system
  logic is not active.  Perhaps the interrupting
  peripherals would then work as normal z80
  interrupters in IM1,IM0,IM2.

Okay then :-)

>   I would like some input on the following specification for an 
> expansion interface for the 2068.  I am looking to build up to 5 of 
> these mostly because that is the minimum order from most PCB 
houses.  
> The board will be 4 layers with silk and solder mask.  I won't 
charge 
> for the board because I will need them for my own interface ;)
> 
> Definite:
> 1.  Interface logic Altera 10K20 204PQFP.  I can get 5 of these 
> surplus from work.  The configuration device will be flash based to 
> allow upgrading the logic.

I am just concerned these will be too small.  They
also don't have a lot of RAM blocks, if memory
serves?

> 2.  1M expansion memory expandable to 2M.  Base configuration will 
be 
> 512k Flash (AT29C040 120ns) and 512K RAM (70ns) and up to 1.5M 
static 
> RAM in 512k increments.
> 3.  16 bit IDE interface for two drives
> 4.  Real-time clock

How about an NVRAM replacement for the
EXROM with rtc?  A convenient place to
put it...  Such a project was done and
sold by Jack Dohany.

> 5.  32MHz oscillator for????
> 
> Options
> 1.  2@ Serial, 1 Centronics parallel port
> 2.  USB 1.1 host controller
> 3.  LAN91C96 10MBb ethernet controller with RJ45 interface
> 4.  Additional IDE interfaces

> 5.  Faster Z80/EZ80 co-processor
> 6.  If we are feeling froggy - 640X400 LCD display.  All 
Electronics 
> has some of these in stock for less than 8 bucks per.  With a 32KX8 
> dual port static RAM and a control FPGA you could do a B/W 
> text/graphics display with rudementary BITBLT, scrolling, etc.

With these last two, it starts not to feel like
a 2068 anymore.  Perhaps pieces of a standalone
computer?

> Add to the list of options if there is anything you think is 
missing.
> I would appreciate if you would rank the options (if any) you want 
in 
> order so that I can prioritize them.  There will only be a certain 
> amount of surface area on the PCB, so not everything will fit.
> 
> Presently, the expansion memory would be located in the dock bank 
and 
> consist of 8@ 8K pages.  Any of the pages could be assigned to any 
> physical address in the memory space.  I expect that none of the TS 
> memory would be used with the exception of the video RAM.  The OS 
> would be run from the expansion memory and we would only page in 
the 
> video RAM when needed.  Use of the dock bank is not definite, we 
> could just as easily use the EXROM bank (although this would entail 
> removing the EXROM chip) or the banking scheme built into the 2068. 

As I said above, I would prefer to leave all internal memory
alone.  I am still keen on an NVRAM cartridge with RAMdisk
capability.  The cart should be an LROS which boots up
and if it detects certain keypresses, it should bring
up a menu of what is stored in the cart's RAMdisk.  The
user could then select a configuration and the cart would
reconfigure itself and return to Basic.  If the magic
keys are not pressed, the cart keeps its last configuration.
Some proposed configurations: RAM pages, Spectrum
emulator, alternative Spectrum ROMs such as SE Basic and
Gosh Wonderful which allow single key entry, ts2068
cartridge software and a diagnostic program.

> The main problem with the latter is that the TM is pretty cryptic 
on 
> just how the banking scheme should be implemented.

Probably because Timex hadn't figured that out
for themselves either :-)  I'm not so sure they
were headed in the right direction anyway -- things
were getting complicated and in my experience that
means something's not right.

> One downside with 
> using the dock bank is the inability to read cartridges.  This 
could 
> be addressed by adding a cartridge port.

I am starting to think a PC interface connected to
a parallel port for reading carts and writing to an
NVRAM cartridge.

> Cost is TBD but shouldn't be outrageous since most of the ICs are 
> fairly cheap.  Obviously, one the hardware is done, the real job of 
> writing the support software will begin.  It would be nice to use 
the 
> Z88DK small C compiler for this especially if we could port it to 
the 
> 2068 to run natively.

Yes, it would :-)

Alvin

3. Re: TS2068 Expansion Interface Specification

Jarek Adamski · Fri, 09 Jul 2004 11:52

--- In [email], "Jeff" <jburrell7@y...> wrote:
> This is primarily for Alvin and Jack, but anyone else who is 
> interested can chime in as well.
I also would like to participate. ;)

> 2.  1M expansion memory expandable to 2M.  Base configuration
> will be 512k Flash (AT29C040 120ns) and 512K RAM (70ns) and
> up to 1.5M static RAM in 512k increments.
Small 4MB DRAM is available from 16MB SIMMs - I still wait for
boards to test this solution. But I've soldered the SIMM and
256kB of it worked correctly. Needs some address multiplexation
though.

> 4.  Real-time clock
Which one?

> Options
 0. One or two YABUS slots for e.g. PC Keyboard&Mouse
interface, FDC, etc. :-)
http://zx.yarek.pl/hardware/bus.yabus/

> 5.  Faster Z80/EZ80 co-processor
I vote for eZ80. Why don't make ZX Spectrum compatibility?
With external CPU there's no problem with memory switching
and occupied ports.


 6. Cartridge port - the short part of ISA 16b slot is
the best for that purpose!


> One downside with using the dock bank is the inability
> to read cartridges.
There must be a configuration ports that will select
between internal memory and cartriges.

> Obviously, one the hardware is done, the real job of 
> writing the support software will begin.
I can prepare CP/M and ZXVGS quite fast.
Also could cooperate to port UZI/UZIX.

Jarek Adamski.

4. Re: [ts2068] TS2068 Expansion Interface Specification

Jack Boatwright · Sat, 10 Jul 2004 00:08

Jeff,

I'm sorta like Scott stated, "on the side lines watching with
awe ..." most of the time.  :-O
Please consider me the hacker/lackey/go-fer type.

I'm lost during most of the coversations between you, Alvin and
Jarek.  However, I am VERY interested in this project and would
like to see some great enhancements come out for these computers.
I'm willing to learn, but I don't expect anyone to waste their
time teaching me, I'll pick up as much as I can as things
progress.  My prowess is adapting and figuring out how something
goes together and what can be done for repair, etc., etc.

Recently I've had all my stuff hooked up at one time or another
and that is a lot!  TS, TC, UK & Speccy.  Got 'em all and in
numbers.  I've been doing things like trying to get the IF1
working with the FDD/FDD3000, but thanks to Jarek and Johnny Red
saw the problems with that and have abandoned the effort, for the
time being.  I'm shortly going to try a network setup with IF 1
using one of each computer to see if I can, say, load something
from an FDD then send to a computer hooked to an IF1/Wafadrive
and save it.  This has probably been done in the past but I can
find no information about it so thought I should do something and
share with the group.

That's sort of where my recent projects came from ... I got tired
of looking at the Timex photo of the BEU, microdrives, 2080, etc.
and made my own.  Of course the BEU needs a lot of work still as
it is only cardboard at this point.

I have been researching old newletters lately about some of the
breakthroughs/breakouts in the early years.  Something I didn't
know until a few days ago is that an "Interface Zero" was the
first, or one of the first, "Twistors" (notice the spelling) made.
All references were for twistor, not twister.  The IF0 was for use
with the Rotronics Wafadrive/Interface 1.

The first "twistor" was made by Nazir Pashtoon of the L.I.S.T.
group in New York.  I talked to him the other day on the phone and
may have peaked his interest again, albeit maybe only for a short
time.  We had a nice conversation about a TC2048 (and many other
things) that was pictured in LISTing in July 1986.  This was an
NTSC 2048!  He is sending me some new colour photos soon to post
on the web site (and on the group site, here).

I also found that a fellow named Wes Brzyzowski (sp?) was nearly
finished designing a pcb for the BEU.  I have found no reference
that it was ever finished, or made available.  Ray Kingsley
corrected the bugs in the ROM and EXROM and put out these on eprom
for a while.  The late Bill Pederson (The WidJuP Co.) did a lot of
work correcting these as well, but reading his theses is like
reading some of the conversations between you, Alvin and Jarek.
;-)  BUT please don't come down to our level, make us come up to
yours!

Back to Topic ...

I think Jarek has a good point when he said don't make this for
the TS, make it for the Spectrum.  Don't get me wrong, I love
my TS but it's sorta the bastard child of the Sinclair-related
computers due to the buss.  It's so much easier using the Sepctrum
peripherals with the TC computers that I use them more now that
the TS.  The TC2068 is the best of both worlds, IMHO.  But I seem
to recall that the PAL SCLD is not conducive to bank-switching.
Don't remember exactly, but I think it was due to lack of some
signals on the buss, or on the chip itself (maybe a little of
each?).

I'll research that and report later.

Jack

----- Original Message ----- 
From: "Jeff" <[email]>
To: <[email]>
Sent: Wednesday, July 07, 2004 5:51 PM
Subject: [ts2068] TS2068 Expansion Interface Specification


> This is primarily for Alvin and Jack, but anyone else who is
> interested can chime in as well.
>
>   I would like some input on the following specification for an
> expansion interface for the 2068.  I am looking to build up to 5
of
> these mostly because that is the minimum order from most PCB
houses.
> The board will be 4 layers with silk and solder mask.  I won't
charge
> for the board because I will need them for my own interface ;)
>
> Definite:
> 1.  Interface logic Altera 10K20 204PQFP.  I can get 5 of these
> surplus from work.  The configuration device will be flash based
to
> allow upgrading the logic.
> 2.  1M expansion memory expandable to 2M.  Base configuration
will be
> 512k Flash (AT29C040 120ns) and 512K RAM (70ns) and up to 1.5M
static
> RAM in 512k increments.
> 3.  16 bit IDE interface for two drives
> 4.  Real-time clock
> 5.  32MHz oscillator for????
>
> Options
> 1.  2@ Serial, 1 Centronics parallel port
> 2.  USB 1.1 host controller
> 3.  LAN91C96 10MBb ethernet controller with RJ45 interface
> 4.  Additional IDE interfaces
> 5.  Faster Z80/EZ80 co-processor
> 6.  If we are feeling froggy - 640X400 LCD display.  All
Electronics
> has some of these in stock for less than 8 bucks per.  With a
32KX8
> dual port static RAM and a control FPGA you could do a B/W
> text/graphics display with rudementary BITBLT, scrolling, etc.
>
> Add to the list of options if there is anything you think is
missing.
> I would appreciate if you would rank the options (if any) you
want in
> order so that I can prioritize them.  There will only be a
certain
> amount of surface area on the PCB, so not everything will fit.
>
> Presently, the expansion memory would be located in the dock
bank and
> consist of 8@ 8K pages.  Any of the pages could be assigned to
any
> physical address in the memory space.  I expect that none of the
TS
> memory would be used with the exception of the video RAM.  The
OS
> would be run from the expansion memory and we would only page in
the
> video RAM when needed.  Use of the dock bank is not definite, we
> could just as easily use the EXROM bank (although this would
entail
> removing the EXROM chip) or the banking scheme built into the
2068.
> The main problem with the latter is that the TM is pretty
cryptic on
> just how the banking scheme should be implemented.  One downside
with
> using the dock bank is the inability to read cartridges.  This
could
> be addressed by adding a cartridge port.
>
> Cost is TBD but shouldn't be outrageous since most of the ICs
are
> fairly cheap.  Obviously, one the hardware is done, the real job
of
> writing the support software will begin.  It would be nice to
use the
> Z88DK small C compiler for this especially if we could port it
to the
> 2068 to run natively.
>
>
>
>       Yahoo! Groups Sponsor
>             ADVERTISEMENT
>
>
>
>
>
> ----------------------------------------------------------------
----------------
> Yahoo! Groups Links
>
>   a.. To visit your group on the web, go to:
>   http://groups.yahoo.com/group/ts2068/
>
>   b.. To unsubscribe from this group, send an email to:
>   [email]
>
>   c.. Your use of Yahoo! Groups is subject to the Yahoo! Terms
of Service.
>
>

5. Re: [ts2068] TS2068 Expansion Interface Specification

Jack Boatwright · Mon, 12 Jul 2004 10:06

Here's what I'm able to find about bank-switching on the TC2068.
This information is 18 years old and my be incorrect so take it
that way.

In the May/June 1985 LISTing Newsletter Nazir Pashtoon reports on
the TC2068 with the following:

" ... Later I discovered that the pinout on the PAL is different
than the SCLD.  Gone is also the small board in TS2068 which had
the 74LS00 for bankswitching.  This function may be incorporated
in the PAL design.   More importantly the 74LS245in TS2068 which
was used for buffering the three most significant address lines
and RD, WR, MREQ, RFSH, and IORQ is gone.  This should give us a
clue as to the future planning of TIMEX-P.  Namely the ambitious
plansof TIMEX-USA for the BEU are probably thrown out (I hope I am
wrong)."

In the article's suumary, while talking about the beneifts of
obtaining the TC machine he goes on to say, "I strongly urge you
to buy the TC2068.  The answer to the above question ... is a
qualified yes.  The qualification comes in because I think in the
TC2068 the capability of using 256 banks is suppressed.  As an
example the ROSCS signal even though available on the DOCK bus is
not brought out to the back, to the edge connector."

This information is equally related to the UK2086.

As stated at the beginning this information is from 1985 and
should be reviewed as such.  Many things could have changed over
the years.

Jack

----- Original Message ----- 
From: "Jack Boatwright" <[email]>
To: <[email]>
Sent: Saturday, July 10, 2004 12:08 AM
Subject: Re: [ts2068] TS2068 Expansion Interface Specification


> Jeff,
>
> I'm sorta like Scott stated, "on the side lines watching with
> awe ..." most of the time.  :-O
> Please consider me the hacker/lackey/go-fer type.
>
> I'm lost during most of the coversations between you, Alvin and
> Jarek.  However, I am VERY interested in this project and would
> like to see some great enhancements come out for these
computers.
> I'm willing to learn, but I don't expect anyone to waste their
> time teaching me, I'll pick up as much as I can as things
> progress.  My prowess is adapting and figuring out how something
> goes together and what can be done for repair, etc., etc.
>
> Recently I've had all my stuff hooked up at one time or another
> and that is a lot!  TS, TC, UK & Speccy.  Got 'em all and in
> numbers.  I've been doing things like trying to get the IF1
> working with the FDD/FDD3000, but thanks to Jarek and Johnny Red
> saw the problems with that and have abandoned the effort, for
the
> time being.  I'm shortly going to try a network setup with IF 1
> using one of each computer to see if I can, say, load something
> from an FDD then send to a computer hooked to an IF1/Wafadrive
> and save it.  This has probably been done in the past but I can
> find no information about it so thought I should do something
and
> share with the group.
>
> That's sort of where my recent projects came from ... I got
tired
> of looking at the Timex photo of the BEU, microdrives, 2080,
etc.
> and made my own.  Of course the BEU needs a lot of work still as
> it is only cardboard at this point.
>
> I have been researching old newletters lately about some of the
> breakthroughs/breakouts in the early years.  Something I didn't
> know until a few days ago is that an "Interface Zero" was the
> first, or one of the first, "Twistors" (notice the spelling)
made.
> All references were for twistor, not twister.  The IF0 was for
use
> with the Rotronics Wafadrive/Interface 1.
>
> The first "twistor" was made by Nazir Pashtoon of the L.I.S.T.
> group in New York.  I talked to him the other day on the phone
and
> may have peaked his interest again, albeit maybe only for a
short
> time.  We had a nice conversation about a TC2048 (and many other
> things) that was pictured in LISTing in July 1986.  This was an
> NTSC 2048!  He is sending me some new colour photos soon to post
> on the web site (and on the group site, here).
>
> I also found that a fellow named Wes Brzyzowski (sp?) was nearly
> finished designing a pcb for the BEU.  I have found no reference
> that it was ever finished, or made available.  Ray Kingsley
> corrected the bugs in the ROM and EXROM and put out these on
eprom
> for a while.  The late Bill Pederson (The WidJuP Co.) did a lot
of
> work correcting these as well, but reading his theses is like
> reading some of the conversations between you, Alvin and Jarek.
> ;-)  BUT please don't come down to our level, make us come up to
> yours!
>
> Back to Topic ...
>
> I think Jarek has a good point when he said don't make this for
> the TS, make it for the Spectrum.  Don't get me wrong, I love
> my TS but it's sorta the bastard child of the Sinclair-related
> computers due to the buss.  It's so much easier using the
Sepctrum
> peripherals with the TC computers that I use them more now that
> the TS.  The TC2068 is the best of both worlds, IMHO.  But I
seem
> to recall that the PAL SCLD is not conducive to bank-switching.
> Don't remember exactly, but I think it was due to lack of some
> signals on the buss, or on the chip itself (maybe a little of
> each?).
>
> I'll research that and report later.
>
> Jack
>
> ----- Original Message ----- 
> From: "Jeff" <[email]>
> To: <[email]>
> Sent: Wednesday, July 07, 2004 5:51 PM
> Subject: [ts2068] TS2068 Expansion Interface Specification
>
>
> > This is primarily for Alvin and Jack, but anyone else who is
> > interested can chime in as well.
> >
> >   I would like some input on the following specification for
an
> > expansion interface for the 2068.  I am looking to build up to
5
> of
> > these mostly because that is the minimum order from most PCB
> houses.
> > The board will be 4 layers with silk and solder mask.  I won't
> charge
> > for the board because I will need them for my own interface ;)
> >
> > Definite:
> > 1.  Interface logic Altera 10K20 204PQFP.  I can get 5 of
these
> > surplus from work.  The configuration device will be flash
based
> to
> > allow upgrading the logic.
> > 2.  1M expansion memory expandable to 2M.  Base configuration
> will be
> > 512k Flash (AT29C040 120ns) and 512K RAM (70ns) and up to 1.5M
> static
> > RAM in 512k increments.
> > 3.  16 bit IDE interface for two drives
> > 4.  Real-time clock
> > 5.  32MHz oscillator for????
> >
> > Options
> > 1.  2@ Serial, 1 Centronics parallel port
> > 2.  USB 1.1 host controller
> > 3.  LAN91C96 10MBb ethernet controller with RJ45 interface
> > 4.  Additional IDE interfaces
> > 5.  Faster Z80/EZ80 co-processor
> > 6.  If we are feeling froggy - 640X400 LCD display.  All
> Electronics
> > has some of these in stock for less than 8 bucks per.  With a
> 32KX8
> > dual port static RAM and a control FPGA you could do a B/W
> > text/graphics display with rudementary BITBLT, scrolling, etc.
> >
> > Add to the list of options if there is anything you think is
> missing.
> > I would appreciate if you would rank the options (if any) you
> want in
> > order so that I can prioritize them.  There will only be a
> certain
> > amount of surface area on the PCB, so not everything will fit.
> >
> > Presently, the expansion memory would be located in the dock
> bank and
> > consist of 8@ 8K pages.  Any of the pages could be assigned to
> any
> > physical address in the memory space.  I expect that none of
the
> TS
> > memory would be used with the exception of the video RAM.  The
> OS
> > would be run from the expansion memory and we would only page
in
> the
> > video RAM when needed.  Use of the dock bank is not definite,
we
> > could just as easily use the EXROM bank (although this would
> entail
> > removing the EXROM chip) or the banking scheme built into the
> 2068.
> > The main problem with the latter is that the TM is pretty
> cryptic on
> > just how the banking scheme should be implemented.  One
downside
> with
> > using the dock bank is the inability to read cartridges.  This
> could
> > be addressed by adding a cartridge port.
> >
> > Cost is TBD but shouldn't be outrageous since most of the ICs
> are
> > fairly cheap.  Obviously, one the hardware is done, the real
job
> of
> > writing the support software will begin.  It would be nice to
> use the
> > Z88DK small C compiler for this especially if we could port it
> to the
> > 2068 to run natively.
> >
> >
> >
> >       Yahoo! Groups Sponsor
> >             ADVERTISEMENT
> >
> >
> >
> >
> >
>
> ----------------------------------------------------------------
> ----------------
> > Yahoo! Groups Links
> >
> >   a.. To visit your group on the web, go to:
> >   http://groups.yahoo.com/group/ts2068/
> >
> >   b.. To unsubscribe from this group, send an email to:
> >   [email]
> >
> >   c.. Your use of Yahoo! Groups is subject to the Yahoo! Terms
> of Service.
> >
> >
>
>
>
>
>       Yahoo! Groups Sponsor
>             ADVERTISEMENT
>
>
>
>
>
> ----------------------------------------------------------------
----------------
> Yahoo! Groups Links
>
>   a.. To visit your group on the web, go to:
>   http://groups.yahoo.com/group/ts2068/
>
>   b.. To unsubscribe from this group, send an email to:
>   [email]
>
>   c.. Your use of Yahoo! Groups is subject to the Yahoo! Terms
of Service.
>
>

Indexed under

TS2068 / TC2068 · Hardware projects & new boards