2068 Interface
4 messages · 2004-07-09 → 2004-07-21 · Yahoo Group era · View archive on archive.org
Participants: aralbrec, Jeff, Johnny Red
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. 2068 Interface
Jeff · Fri, 09 Jul 2004 15:10
Alvin and Jarek:
Starting at the top
1 and 2. I agree that all peripherals should be interrupt driven and
that an autonomous "DMA" engine that has access to all of the
physical expansion memory should be used for managing data flow
to/from the peripherals. I'd like this to be a relatively complex
FSM that would interleave Z80 accesses with the "DMA" accesses with
the Z80 having priority. This is one reason for the 32MHz oscillator.
3. Timers it is eminently possible to put a sync-stripper on the
board to gain access to a HSync signal. Additional timers are pretty
cheap.
4. I would suggest that we stick with a 2M space and that
the "dirty", "used", and "read_only" flags be in in a separate
register file. I'll have to look at the Altera (and perhaps Xilinx)
data but I believe the 10K20 memory can be configured as a 128X16bit
async dual port memory or register file. As such, the lower 8 bits
can be the address lines while the upper 8 bits can contain other
memory information. One could even use some of the upper bits to
designate which process owns that segment of memory (shades of a real
MMU). In addition, with 16 groups of 8 registers, context switching
could be as simple as changing one pointer that moves accesses a
different octet of the register file. BTW we could go to 4K pages if
we are willing to have 8 groups 16 mapping registers.
5 & 6. Yup and Yup
7. The AT29C040A utilizes a 256 byte page which is the smallest
available block. STM also makes a SPI serial 512KB flash in an SO16
package that might be useful for a flash drive.
8. Yeah, I prefer an FPGA. I selected the 10K20 because they are
free, available, and are +5V devices. We could use a Xilinx device.
A XC2S100-5PQ208I (100K gate) is $22.50 through Digikey. The
downside is that it is a 2.5V core with 3.3V (5V tolerant) I/O. This
is OK, but is a real pain because of the additional voltages. I
bring this up because I don't know if a 10K20 could do the job you
want. Also, a XC2S200-5PQ208C is about $35.00 and is large enough to
hold a Z80 core with much room to spare. :) I guess I'll need some
guidance on just how far overboard we should go. This might be OK
for we hardcore hackers but a bit much for other users of this board.
9. I prefer using the /ROSCS method, but the FPGA could have several
operating modes (those extra bits in the register file could help
here). In any case, you are correct about the dedicated memory bus.
Those lines will need to be as short as possible to maintain signal
integrity. Also, the flash has an access time of 120ns and the SRAM
can be as fast as 20ns (though we certaily won't be able to support
that speed). This means that the code in the flash should be
transferred to SRAM at boot to eliminate this bottleneck.
10. TI makes the TL16C552APN, a nice little dual UART and
bidirectional parallel port chip. The best clock frequency for this
device is 16MHz, yet another reason for the 32MHz oscillator. The
extra I/O lines would be pretty simple to implement using `245s
and/or `373s.
11. I think a floppy is pretty much useless today especially given
the ability to use CF cards as removeable storage. If we include
USB, then things get even more interesting
12. A 200K gate FPGA probably could do this. :)
13. NMI button should be no problem. As to a multitasking OS, we
can put this off until sometime later. Also, if we embed an enhanced
Z80 in a large FPGA, the 2068 and its processor would then be
basically an I/O processor and the FPGA would do most of the heavy
lifting.
15. We could add a YABUS interface to this board. I'll need to give
this some thought.
15. I'm also thinking in terms of making the PCB compatible with the
C64/C128 probably using an adapter board ("twister board"?).
Obviously, the FPGA is key here since the Commodore and Sinclair bus
and bus timing are very different. There is a "short bus" interface
for Commodore peripherals that would possibly confilict with the
YABUS but I think they could be made compatible.
2. Re: 2068 Interface
aralbrec · Fri, 16 Jul 2004 18:51
--- In [email], "Jeff" <jburrell7@y...> wrote:
> 3. Timers it is eminently possible to put a sync-stripper on the
> board to gain access to a HSync signal. Additional timers are
pretty
> cheap.
These can probably be implemented on the FPGA, which
can probably save an analogue section on the PCB
(maybe). The display timings can be derived from the
interrupt generated by the SCLD, which would mean there
would have to be a way to detect when the SCLD causes
an interrupt and not something else.
For a VGA interface, I'm not sure what you have
in mind -- whether it's a new display with new
resolution etc. or a new TS2068-size display or
a new display with the ability to have the
original display in a window. If it's one of the
latter two, having counters to determine the
position of the raster at any moment in the original
display would be quite helpful. A lot of Spectrum
games software depends on knowing where the raster
is to avoid flicker, etc. How that translates to
a VGA display with different vertical refresh is
not something I've thought about, but it is
something the emulator authors have thought about.
> 4. I would suggest that we stick with a 2M space and that
> the "dirty", "used", and "read_only" flags be in in a separate
> register file.
I'll agree with you -- there is no need to steal
bits and reduce the memory space. Having the
flash as memory mappable is also a good thing
despite it being much slower than the fast
SRAM -- logic on the FPGA can sort all of that
out. The register file window idea is a good one
for fast context switches.
Have you thought about how the machine will
boot up? I like the idea of storing the
FPGA configuration in the flash and booting
the FPGA from flash but this leaves us with a
chicken-and-egg problem. How do we get the
first FPGA configuration into the flash when
the logic to control the flash has to be in
the FPGA first?
Maybe another reason for a sister CPLD,
which could address the flash while
the FPGA configures itself?
Also, how many bits are required to store
the configuration for a 200K gate FPGA?
Do we have enough flash? There should
at least be some extra room in the flash
for an operating system boot-up sequence
stored starting at an exact 8K/4K page,
which might just involve fetching the o/s
from hard disk. The o/s can boot up
in an automatic manner if the register
files are suitably initialized in the FPGA
config.
I don't know if you had some
other purposes in mind for the flash.
> 15. We could add a YABUS interface to this board. I'll need to
give
> this some thought.
Also forgot about a mouse connector -- will
need that. Maybe a serial port suffices.
I prefer a device that can keep track of its
own position rather than one that needs to be
polled for every single 1 pixel movement.
A keyboard connector maybe as well? If the
connector runs through the FPGA, we can make
it so that it can seemlessly replace the
Spectrum keyboard. The ts2068 might be more
difficult as the SCLD and z80 bus are not
separated by resistors, so the keyboard logic
couldn't just place bytes on the bus when
port $fe is read. Will have to check.
To add to the free-for-all a spot for an
A/D , D/A combination? Output from the
D/A could be optionally connected to
the SOUND pin of the ts2068 to get 8-bit
sound out of the internal speaker, and
maybe it could be routed to a phono
connector. Maybe two for stereo? As long
as proposed specs are being discussed,
I'll just add :-)
There should be a means to add expansion
cards. The Yabus is an idea, something
that would sit on the z80 bus.
Alvin
3. Re: [ts2068] Re: 2068 Interface
Johnny Red · Mon, 19 Jul 2004 12:46
After reading this (I don't understand much of electronics), I keep
questioning my self, what is the "paper" of TS2068 in the middle of this?
In what part will I use the TS2068?
I read that a VGA interface need to be build (and I read that it would not
use the Spectrum screen "form", so why do we need SCLD?), a mouse
connection, a keyboard connection (so no use for the TS2068 keyboard), a Z80
with DMA, memory (not using the "internal" memory), etc etc.
Are "we" going to build a TS2068 interface or a new computer?
I already have a Timex computer controlling another computer.
I just need to look for a TC2048/2068 with a FDD system.
Even the Timex Terminal 3000 is a computer!
It have a Z80, a SCLD, RAM and ROM (FDD3000 supply the power and TT3000
generates video signal).
Johnny Red, Portugal
on 07/16/2004 19:51, aralbrec at [email] wrote:
> --- In [email], "Jeff" <jburrell7@y...> wrote:
>
>> 3. Timers it is eminently possible to put a sync-stripper on the
>> board to gain access to a HSync signal. Additional timers are
> pretty
>> cheap.
>
> These can probably be implemented on the FPGA, which
> can probably save an analogue section on the PCB
> (maybe). The display timings can be derived from the
> interrupt generated by the SCLD, which would mean there
> would have to be a way to detect when the SCLD causes
> an interrupt and not something else.
>
> For a VGA interface, I'm not sure what you have
> in mind -- whether it's a new display with new
> resolution etc. or a new TS2068-size display or
> a new display with the ability to have the
> original display in a window. If it's one of the
> latter two, having counters to determine the
> position of the raster at any moment in the original
> display would be quite helpful. A lot of Spectrum
> games software depends on knowing where the raster
> is to avoid flicker, etc. How that translates to
> a VGA display with different vertical refresh is
> not something I've thought about, but it is
> something the emulator authors have thought about.
>
>> 4. I would suggest that we stick with a 2M space and that
>> the "dirty", "used", and "read_only" flags be in in a separate
>> register file.
>
> I'll agree with you -- there is no need to steal
> bits and reduce the memory space. Having the
> flash as memory mappable is also a good thing
> despite it being much slower than the fast
> SRAM -- logic on the FPGA can sort all of that
> out. The register file window idea is a good one
> for fast context switches.
>
> Have you thought about how the machine will
> boot up? I like the idea of storing the
> FPGA configuration in the flash and booting
> the FPGA from flash but this leaves us with a
> chicken-and-egg problem. How do we get the
> first FPGA configuration into the flash when
> the logic to control the flash has to be in
> the FPGA first?
>
> Maybe another reason for a sister CPLD,
> which could address the flash while
> the FPGA configures itself?
>
> Also, how many bits are required to store
> the configuration for a 200K gate FPGA?
> Do we have enough flash? There should
> at least be some extra room in the flash
> for an operating system boot-up sequence
> stored starting at an exact 8K/4K page,
> which might just involve fetching the o/s
> from hard disk. The o/s can boot up
> in an automatic manner if the register
> files are suitably initialized in the FPGA
> config.
>
> I don't know if you had some
> other purposes in mind for the flash.
>
>> 15. We could add a YABUS interface to this board. I'll need to
> give
>> this some thought.
>
> Also forgot about a mouse connector -- will
> need that. Maybe a serial port suffices.
> I prefer a device that can keep track of its
> own position rather than one that needs to be
> polled for every single 1 pixel movement.
>
> A keyboard connector maybe as well? If the
> connector runs through the FPGA, we can make
> it so that it can seemlessly replace the
> Spectrum keyboard. The ts2068 might be more
> difficult as the SCLD and z80 bus are not
> separated by resistors, so the keyboard logic
> couldn't just place bytes on the bus when
> port $fe is read. Will have to check.
>
> To add to the free-for-all a spot for an
> A/D , D/A combination? Output from the
> D/A could be optionally connected to
> the SOUND pin of the ts2068 to get 8-bit
> sound out of the internal speaker, and
> maybe it could be routed to a phono
> connector. Maybe two for stereo? As long
> as proposed specs are being discussed,
> I'll just add :-)
>
> There should be a means to add expansion
> cards. The Yabus is an idea, something
> that would sit on the z80 bus.
>
> Alvin
4. Re: 2068 Interface
aralbrec · Wed, 21 Jul 2004 18:46
--- In [email], Johnny Red <timex.pt@m...> wrote:
> In what part will I use the TS2068?
>
> I read that a VGA interface need to be build (and I read that it
would not
> use the Spectrum screen "form", so why do we need SCLD?), a mouse
> connection, a keyboard connection (so no use for the TS2068
keyboard), a Z80
> with DMA, memory (not using the "internal" memory), etc etc.
>
> Are "we" going to build a TS2068 interface or a new computer?
I know where you are coming from. The VGA display
was proposed because people complain about poor
video quality from the 2068, and the fact that
VGA monitors are much more convenient than TV
sets for a computer setup. The PC keyboard connector
is there because it is something that people have
asked about and can buy for about $80 from Sintech.
The mouse is not really something new -- mice have
been available for the Spectrum even if they were
rare. I would probably be inclined to emulate
something like the Kempston mouse, for example,
which keeps track of the mouse's position in a
couple of registers that can be polled from
software.
My personal vision for the project would definitely
make it a peripheral, not a new computer. I'm not
so much interested in a cpu accelerator board or
a new VGA display (unless it's a simple 2068 display)
and I am mainly interested in making sure that the
result will still be compatible with existing
software, cartridges, etc. I do expect
the internal AY chip, keyboard, display RAM, etc.
will be used. I also expect that programs will
mainly run from the expansion RAM (this is hard
to avoid given there will be 2M of expansion RAM
and only 48K of internal RAM :-), including the
default BASIC of which you may have several BASIC
programs running at once. The idea of an
enhanced VGA display comes up again -- wouldn't
it be nice to have 5-10 basic programs (or other
programs) running at the same time displayed in
different windows?
The great thing about this project is that the
hardware being added is very powerful and is able
to accommodate everyone's vision of what this
peripheral should be. There might even
be different competing configurations to choose
from, though I expect the majority of the design +
software will be common among any alternative
configurations. The flexibility of any design
using an FPGA is also intriguing, opening up the
possibility of having one piece of hardware
connected to a number of retro computers without
any physical modifications, as Jeff has mentioned.
Alvin