Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.sys.sinclair > #647

Re: RFC: ULA Replacement for ZX Spectrum SE

Show all headers | View raw

one last try
so if there are 224 tstates per line and 192 lines is that
192x224=
43,008
x50=
2,150,400
so theres still another 3,500,000-2,150,400
1,349,600 tstates per second or
/50=
26,992 per frame+43,008=
70,000x50 = 3,500,000?

26,992/204=132x16=
2117 bytes transfered but not read form a port which is even slower?
is it 16 tstates to read a single byte from a port into ram?
1687 bytes could be read from a port
flip there just isnt enough tstates per dframe to deal with the speccy
screen fro simple hi colour timex samode2 screen$ or interlaced stuff
is there?
especially as none of the mass media storage or lan specranet network has a DMA
which would be 2tstates per byte read from a port - so technically even in the
26992/2
13496 - almost long enough to trasfner two frames awith 13824=2 speccy
mode one screen$ so fgarily close and leaves plenty of time for
decompression or other fafflike you r 256 ham colour mode for ula +

velesoft reckons they have rip processor for 7mhz would give 448
tstates per line so it should be possible with that unless the
contention slows it when writing to video ram? 
interlaced is 50 hz on 128 only need to write one port each 50hz?
but mutlichrome timex hi colour samode2 without the extra ram is a
real fiddle requiring dma
unless you went for 8x4 - so only two attributes - you could flip on
a 128 between two screen$
need to do this every four pixel lines - each screen would only need
four pixel rows and attributes? must be easier than your 48 routines
and less processor consuming?
two screens would make a big difference?
time wise? 

Back to comp.sys.sinclair | Previous | Next | Find similar | Unroll thread

Thread

Re: RFC: ULA Replacement for ZX Spectrum SE rogerjowett@gmail.com - 2012-02-08 02:37 -0800

csiph-web