RFC: ULA Replacement for ZX Spectrum SE
Andrew Owen
that I have been slaving away on a new ROM set for the Spectrum. I still
need help but it is nearing completion. Anyway, rather than wait for someone
to create a magnificent new machine I have decided to do it myself (if only
in emulation to begin with). Here's the spex:
Bugfixed ROM set which is more compatible with the 48 than any other 128.
128k RAM, expandable to 512k, paged exactly the same as the Scorpion.
7.08Mhz processer, switched exactly the same as the Scorpion.
16 channel sound - handled by a GM-MIDI card plugged into the MIDI out.
There will be no contended memory and the ULA replacement will allow palette
switching to achieve a true 16-32 colours on screen from a palette of around
4,096 colours. What I need to know is, are there any OUT addresses free to
do this. What sort of palette range do people want. How should the palette
be handled.
My initial proposal was for 16 colours from 4,096 using two bytes.
Bit 1-4 is the number of the colour while the other 12 bits contain the
intensity of R,G, and B. The 16 colours refer to the standard 8 and their
bright equivalents, effectively giving two eight colour palettes.
But it would also be possible to have 32 colours by using the FLASH
attribute:
normal = 1-8, bright = 9-16, normal+flash = 17-24, bright+flash = 25-32.
This would sacrifice the standard use of the FLASH command.
The effect would be to have four palettes of 8 colours available at once:
no modifier = palette 1
bright = palette 2
flash = palette 3
bright+flash = palette 4
The normal restrictions on two colours per character cell would still apply
and you could not mix colours from different palettes in the same cell but
it would be relatively easy to modify existing software to take advantage of
the extended palette.
So what I want to know is:
Should we sacrifice FLASH to get 32 colours on screen?
(The more I think about it, the more I think it would be acceptable)
How should the palettes be selected (OUT commands etc?)
How big should the palette be?
3 bits per channel = 512
4 bits per channel = 4,096
5 bits per channel = 32,768
6 bits per channel = 262,144
7 bits per channel = 2,097,152
8 bits per channel = 16,777,216
I personally think 4,096 colours is plenty.
(it was enough for the Amiga and the STE)
-Andrew
p.s. You have until I have the ROM finished to decide. Then it gets coded
and, hopefully, becomes a new standard (and then Sonic ZX can take advantage
of it).
p.p.s As well as bugfixing the ROM I'm looking at making a few improvements
without sacrificing compatibility. I've figured out a way to make the DRAW
commands use the lower two lines of the screen without making existing
programs behave differently. I've extended the character set (comments
welcome) so:
CHR$ 24 = ae
25 = fs
26 = oe
27 = oe (alt)
28 = acute accent
29 = umlaut
30 = grave accent
31 = hachek (the Czech/Welsh character)
This means the lowercase versions of the most of the international
characters are available (due to the flexibilty of the replacement
characterset)
I've also replaced the memory test in ROM 0 with a memory wipe (much
faster).
I'm looking at making line 0 editable (to fix the line 0 bug in 128 BASIC)
and extending the range of possible line numbers up to 32,767.
Any other suggestions for improvements are welcome.
Equin0x
> 16 channel sound - handled by a GM-MIDI card plugged into the MIDI out.
Nice! Can you PLAY a$, b$,..., o$ ?
> Should we sacrifice FLASH to get 32 colours on screen?
Yes. Nobody's used FLASH seriously since 1983.
Would the FLASH command in BASIC work for accessing the extra colours?
> How should the palettes be selected (OUT commands etc?)
System variables? (I know there aren't technically any unused ones, but
since it's a custom ROM, there might be.)
> How big should the palette be?
> 3 bits per channel = 512
> 4 bits per channel = 4,096
> [...]
> I personally think 4,096 colours is plenty.
I think 512 is enough.
> [new chars]
Using OVER for the accents is great. I never liked the idea of having
separate characters for e', e`, etc., even though ANSI did it.
Eq.
--
Matthew Westcott
nice.
>> How should the palettes be selected (OUT commands etc?)
>
>System variables? (I know there aren't technically any unused ones, but
>since it's a custom ROM, there might be.)
I think I'd prefer OUT commands. The process of choosing colours is
external to the ROM, and it would be nice to have it handled by OUTs in a
similar way to the sound chip or the border colour. On the other hand,
using memory locations would make colour cycling easier (only slightly
easier though).
Oh, and it should be possible to change the palette while the screen is
being drawn, so that clever people can get more than the usual number of
colours on-screen at once. I like gimmicks :-)
--
Matthew Westcott
http://www.demo.eu.org/ - the home of the Spectrum demo scene
-------------------------------------------------------------
| "Meet James Ensor, Belgium's famous painter |
| Dig him up and shake his hand, experience the man" |
Vlada Stepanovic
"Andrew Owen" <ao...@brandnewco.org> wrote in message
news:B545AA0C.233%ao...@brandnewco.org...
> Those who have been following my posts over the last few months will know
> that I have been slaving away on a new ROM set for the Spectrum. I still
> need help but it is nearing completion. Anyway, rather than wait for
someone
> to create a magnificent new machine I have decided to do it myself (if
only
> in emulation to begin with). Here's the spex:
>
> Bugfixed ROM set which is more compatible with the 48 than any other 128.
> 128k RAM, expandable to 512k, paged exactly the same as the Scorpion.
> 7.08Mhz processer, switched exactly the same as the Scorpion.
>
palette
> switching to achieve a true 16-32 colours on screen from a palette of
around
> 4,096 colours. What I need to know is, are there any OUT addresses free to
> do this. What sort of palette range do people want. How should the palette
I just wonder how you think to write new ROM, if you didn't solved those
primary questions about hardware ???
Btw. there are still some free OUT adresses, but not much, sadly.
PP
Andrew Owen
Equin0x at y982...@cpca6.uea.ac.uk wrote on 15/5/00 1:31 pm:
>> 16 channel sound - handled by a GM-MIDI card plugged into the MIDI out.
> Nice! Can you PLAY a$, b$,..., o$ ?
All 16 channels are supported by 128 BASIC as standard.
>> Should we sacrifice FLASH to get 32 colours on screen?
> Yes. Nobody's used FLASH seriously since 1983.
Good. I don't mind the Manic Miner loading screen looking a bit strange if
you don't. For most games an acceptable compromise could be reached by
having the colours used by FLASH act the same as if INVERSE had been
selected.
> Would the FLASH command in BASIC work for accessing the extra colours?
Yes.
>> How should the palettes be selected (OUT commands etc?)
> System variables? (I know there aren't technically any unused ones, but
> since it's a custom ROM, there might be.)
Actually there is one unused system variable (the one that's supposed to be
unused in the manual but actually isn't) except that you can't use it
because lots of programs already use it because they think it's unused (if
you see what I mean. Hmm, "They think it's unused... it is now!"
>> How big should the palette be?
>> 3 bits per channel = 512
>> 4 bits per channel = 4,096
>> [...]
>> I personally think 4,096 colours is plenty.
>
> I think 512 is enough.
That would require a total of 14-bits for 32 colours from 512, (two bytes)
But to be honest if we're going to have 32 colours you really need a palette
of 4,096 so you can get a reasonable spread of mid-tones, unfortunately that
uses 17-bytes but I'll think of a solution.
>> [new chars]
> Using OVER for the accents is great. I never liked the idea of having
> separate characters for e', e`, etc., even though ANSI did it.
Of course it means I'll have to write a new font editor since you now have
104 characters instead of 96 to play with.
-Andrew
Andrew Owen
gas...@raww.org.RemoveThisBit.invalid wrote on 15/5/00 2:33 pm:
>>> How should the palettes be selected (OUT commands etc?)
>> System variables? (I know there aren't technically any unused ones, but
>> since it's a custom ROM, there might be.)
> I think I'd prefer OUT commands. The process of choosing colours is
> external to the ROM, and it would be nice to have it handled by OUTs in a
> similar way to the sound chip or the border colour.
I think using OUTs is also more practical from a hardware point of view but
I need to know which ones are not avaiable because they are already used by
other hardware (such as the AY, disk interfaces etc.)
> Oh, and it should be possible to change the palette while the screen is
> being drawn, so that clever people can get more than the usual number of
> colours on-screen at once. I like gimmicks :-)
As the video will be handled by something other than the ULA taking info
from the screen area to build the picture and OUTs to choose the palettes it
should be possible to create a kind of hold and modify mode to get all 4,096
colours on screen with certain restrictions.
-Andrew
Dominic Morris
> Actually there is one unused system variable (the one that's supposed to be
> unused in the manual but actually isn't) except that you can't use it
> because lots of programs already use it because they think it's unused (if
> you see what I mean. Hmm, "They think it's unused... it is now!"
As you said it is used..and it can be used by programs as well for almost
its original purpose:
10 FOR n=64 TO 71
20 POKE 23681,n
30 LPRINT "fish"
40 NEXT n
cheers,
d.
[procrastinating..what me?!?!]
Andrew Owen
pp...@soyaprotein.com wrote on 15/5/00 3:32 pm:
> I just wonder how you think to write new ROM, if you didn't solved those
> primary questions about hardware ???
It's not 100% new, just the original 128 ROM with all the bugs removed and
some minor improvements. The extra colour etc will not be handled by the ROM
but by hardware (or emulated hardware) so I can finish the ROM before I
decide how to implement the colour etc.
> Btw. there are still some free OUT adresses, but not much, sadly.
You wouldn't happen to know where they are would you?
-Andrew
Darren Salt
Andrew Owen <ao...@brandnewco.org> wrote:
[snip]
> I'm looking at making line 0 editable (to fix the line 0 bug in 128 BASIC)
> and extending the range of possible line numbers up to 32,767.
That latter change would cause problems with variable storage; the top three
bits of the first character of a variable name are used to encode the
variable type, with %000 and %001 being unused and thus free for use in line
numbers.
--
| Darren Salt anti-UCE | nr. Ashington, | d youmustbejoking,demon,co,uk
| Spec+3, Risc PC, A3010 | Northumberland | s zap,uk,eu,org
| BBC M128, Linux PC | Toon Army | @ retrospec,co,uk
| Z80Em and 6502Em Support Packs. AY sound support.
Idleness is leisure gone to seed.
kio (Günter Woigk)
Hello,
really, if we are about to add new screen modi, i would suggest to add
at least two:
- one high resolution mode, may be monochrome, for text output
- one high color mode for graphics.
flash bit:
if you like forget it. if sinclair only had made the pen color flash
only... flashing can be achieved by an interrupt routine, and most time
there is nearly nothing flashing on the screen. but i'd like to keep a
compatibility mode!
programming screen modi and color palettes:
please only by output! we could start collecting used out addresses and
then decide which one we'll use.
i suggest to use only one master address in the lower address byte with
fully decoded 8 bits for all screen related outputs and use the high
byte of the address as sub address to select the function and the data
byte to transfer data (hey, seems to be intended that way by the zilog
engineers :-)
so for the start ignore the master address issue until we have collected
enough addresses already used by other devices.
now asuggestion for a list of sub address functions:
[clut = color look up table = table for ink to color conversion]
[ink = index in clut]
%01xxxxxx set clut[data].red to %xxxxxx
%10xxxxxx set clut[data].green to %xxxxxx
%11xxxxxx set clut[data].blue to %xxxxxx
%00000000 select screen mode 0: classic specci (data ignored)
%00000001 select screen mode 1: hires text ""
%00000010 select screen mode 2: game mode 1 ""
%00000011 select screen mode 3: game mode 2 ""
special switches (see below) (ordered sub addresses starting from $04)
%00000100 select 3+3 bit inks + bright + flash (classic specci)
%00000101 select 4+4 bit inks
%00000110 select 3+5 bit inks
.... select 2+6 bit inks
... select 1+7 bit inks
... select 0+8 bit inks
.. trigger interrupt every [data] lines
.. set high bits for inks from screen memory to [data]
. lock all settings
. reset to classic specci (soft reset command)
. more switches
this would implement a clut with 256 inks with 6 bit components (262144
colors).
mode 0: (classic specci mode) 3-bit true color could be interpreted as
inks. then the clut should reset to the specci colors on reset. programs
could change inks to use own colors. bright and flash bit working.
some of the special switches select other attribute conversions: e.g.
2x4-bit inks or a 3-bit paper ink plus 5-bit pen ink with no bright and
flash bits. if 0+8 bit mode is selected, the paper color will always
come from ink 0. (6144+768 bytes)
mode 1: (text mode) could be 512x192 like Sam Coupé or Timex2068. How is
this screen organized im ram? color? layout? size?
mode 2/3: attribute table is expanded to hold 1 attribute byte per pixel
byte. attribute table has to go somewhere else in memory. [i would not
really like this mode] (12288 bytes)
mode 2/3: no attribute table but 4 bit per pixel indexed colors.
(24576 bytes)
mode 2/3: no attribute table but 8 bit per pixel indexed colors.
(49152 bytes)
special switch to enable interrupts at certain scan lines to make
switching the screen mode for split screens easy.
special switch to set the default value for inks: if we use ink sizes
less than 8 bit the unset upper bits come from this byte. this can be
used to implement multiple palettes with fast switching between them.
more special switches could be added on public request.
we need to decide how to organize the video ram in each mode. how is the
512x192 pixel mode on a Sam Coupé handled? this could serve as example.
how to handle border color? i suggest to interpret it's 3 bits as an ink
index too.
we could also add programming of the 'first scanline' and 'last
scanline' and even 'fist pixel column' and 'last pixel column'. this way
we could enlarge the writable screen. Cinemax display on a Specci :-)
all those special switches could be added step by step. so lets start
with the color palette thing first.
hey, i got fun thinking about it.
comments appreciated.
... kio !
--
http://little-bat.de
http://little-bat.de/zx_spectrum.html
k...@little-bat.de (private)
Matthew Westcott
was nice.
>i suggest to use only one master address in the lower address byte with
>fully decoded 8 bits for all screen related outputs and use the high
>byte of the address as sub address to select the function and the data
>byte to transfer data (hey, seems to be intended that way by the zilog
>engineers :-)
It still means hogging 256 addresses though - I propose a similar system to the
AY chip, namely to have one port to select a 'register' number and one port to
determine the value of that register.
I don't really agree with the idea of multiple screen modes - I think the aim
should be to give the Speccy a few bells and whistles, not to design something
that amounts to a whole new computer system. We've got the Sam Coupe for that
:-)
--
Matthew Westcott
http://www.demo.eu.org/ - the home of the Spectrum demo scene
-------------------------------------------------------------
| "Standing in my yard, where they tore down the garage |
| to make room for the torn down garage" |
Alvin Albrecht
> mode 1: (text mode) could be 512x192 like Sam Coupé or Timex2068. How is
> this screen organized im ram? color? layout? size?
In the ts2068 there are two display files: the normal one
at #4000 and a second identicaly formatted one at #6000.
In one mode, the active display file can be swapped as in
the 128k spectrum. In another mode, the pixel byte is
taken from the first display file and the corresponding
attribute is taken from the second display file. This
yields 256x192 pixels and 32x192 attributes. The 512x192
mode uses the first display for even columns 0,2,4,..,62
and the second display file for odd columns 1,3,5,..,63.
This way the SCLD (ULA) fetches alternating bytes from
the first display file and the second one with the address
for the second byte formed by setting bit 13.
> mode 2/3: no attribute table but 8 bit per pixel indexed colors.
> (49152 bytes)
> all those special switches could be added step by step. so lets start
> with the color palette thing first.
The problem with such a high resolution display is that
the spectrum is too slow to make use of it. Even doubling
the clock frequency won't help since this display requires
8 times as much processing. I think we should be thinking
in terms of hardware that will do all the work for us.
Alvin
Geoff Winkless
news:8F359FDD9ga...@163.1.2.7...
> On 15 May 2000, Equin0x wrote this message in comp.sys.sinclair. Which was
> nice.
>
> >> How should the palettes be selected (OUT commands etc?)
> >
> >System variables? (I know there aren't technically any unused ones, but
> >since it's a custom ROM, there might be.)
>
> I think I'd prefer OUT commands. The process of choosing colours is
> external to the ROM, and it would be nice to have it handled by OUTs in a
> using memory locations would make colour cycling easier (only slightly
> easier though).
The way the Sam Coupe handled it was BASIC kept a copy of the current
palette in memory but the actual palette was OUT only.
I often thought how nice it would have been to have been able to read the
palette with IN, but really it wouldn't have made that much difference...
On an aside, I have to say that it seems a tad ... pointless to reproduce
MGT's work, which appears (to me) to be what you're doing.
Geoff
Andrew Owen
geoff-at-far...@127.0.0.1 wrote on 17/5/00 10:10 am:
> The way the Sam Coupe handled it was BASIC kept a copy of the current
> palette in memory but the actual palette was OUT only.
Just out of interest, which OUT exactly and how did it work?
> I often thought how nice it would have been to have been able to read the
> palette with IN, but really it wouldn't have made that much difference...
We could do that with this project.
> On an aside, I have to say that it seems a tad ... pointless to reproduce
> MGT's work, which appears (to me) to be what you're doing.
How many SAMs are there out there, how many Spectrums? This idea will start
out as emulated hardware but I hope it will make it into a real hardware
board that you can plug into a real machine.
-Andrew
Geoff Winkless
> in article 8ftndk$neq$1...@soap.pipex.net, Geoff Winkless at
> geoff-at-far...@127.0.0.1 wrote on 17/5/00 10:10 am:
>
> > The way the Sam Coupe handled it was BASIC kept a copy of the current
> > palette in memory but the actual palette was OUT only.
>
> Just out of interest, which OUT exactly and how did it work?
Can't remember the exact details, but I _think_ there was a band of 16 OUTs
which corresponded to the 16 palette colours.
> > On an aside, I have to say that it seems a tad ... pointless to
reproduce
> > MGT's work, which appears (to me) to be what you're doing.
>
> How many SAMs are there out there, how many Spectrums? This idea will
start
> out as emulated hardware but I hope it will make it into a real hardware
> board that you can plug into a real machine.
Mmm. That was MGT's original idea too -- a board that plugged into a speccy.
Then they speeded up the processor, redesigned the BASIC, added in a new
sound chip, changed a few more bits and then thought, sod it, you've got so
much of a computer in here, you may as well go the whole hog...
that way lies madness...
To be honest the only real way to make it decent would be to up the speed of
the processor to 40MHz or something, that would make it capable of handling
a decent amount of reasonable quality graphics.
Geoff
kio (Günter Woigk)
Matthew Westcott <gas...@raww.org.RemoveThisBit.invalid> wrote:
> It still means hogging 256 addresses though - I propose a similar system
> to the AY chip, namely to have one port to select a 'register' number and
> one port to determine the value of that register.
not quite right ... the ay chip used 2 addresses in the major address
byte (the lower address byte) which probably was not even decoded fully,
so it probably actually required 32 addresses. my suggestion uses only
one address in the major i/o address byte.
> I don't really agree with the idea of multiple screen modes - I think the
> aim should be to give the Speccy a few bells and whistles, not to design
> something that amounts to a whole new computer system. We've got the Sam
> Coupe for that :-)
maybe i added too much in my enthusiasm. that's why i appended the
'let's start with the palettes first' at the end. finally, it's up to
andrew whether he'd like to include a new screen mode or something like
this in his version of a new rom. if it's not too weird i'd like to
support it.
ZX Spectrum SE ... is this another project or the latest name of the
former +4 ?
AndyC
On Mon, 15 May 2000, Andrew Owen wrote:
> 16 channel sound - handled by a GM-MIDI card plugged into the MIDI out.
Good idea, presuambly PLAY's support for MIDI would still work then.
> My initial proposal was for 16 colours from 4,096 using two bytes.
Sounds more than enough.
> Should we sacrifice FLASH to get 32 colours on screen?
> (The more I think about it, the more I think it would be acceptable)
Hmm. There is still some software that uses it which would look a bit odd
without it. But not much, I guess.
> How should the palettes be selected (OUT commands etc?)
OUT commands. Preferably locked at startup and requiring a special coded
sequence of OUTs to unlock the extra hardware for compatability (ala the
CPC+)
> How big should the palette be?
> I personally think 4,096 colours is plenty.
> (it was enough for the Amiga and the STE)
And the CPC+. :-) Although, 256 would be perfectly adequate and would
perhaps better suit an 8 bit machine.
> p.s. You have until I have the ROM finished to decide. Then it gets coded
> and, hopefully, becomes a new standard (and then Sonic ZX can take advantage
> of it).
Sounds good. Although it would be nice if Sonic ZX still ran on a "proper"
speccy.
AndyC
Andrew Owen
AndyC at a...@sys.uea.ac.uk wrote on 17/5/00 4:57 pm:
> On Mon, 15 May 2000, Andrew Owen wrote:
>> 16 channel sound - handled by a GM-MIDI card plugged into the MIDI out.
> Good idea, presuambly PLAY's support for MIDI would still work then.
Yes.
>> How should the palettes be selected (OUT commands etc?)
> OUT commands. Preferably locked at startup and requiring a special coded
> sequence of OUTs to unlock the extra hardware for compatability (ala the
> CPC+)
OK, but I still need to know which ports are free: does anything use:
00h, FFh, 4FFDh, FFFFh
These are some places we could put it if they don't clash.
>> How big should the palette be?
> 256 would be perfectly adequate and would
> perhaps better suit an 8 bit machine.
I don't think 256 is enough, it doesn't give a lot of shades of one colour.
>> p.s. You have until I have the ROM finished to decide. Then it gets coded
>> and, hopefully, becomes a new standard (and then Sonic ZX can take advantage
>> of it).
> Sounds good. Although it would be nice if Sonic ZX still ran on a "proper"
> speccy.
It will run on an unexpanded 48K machine but will take advantage of the
extra hardware if it's available.
-Andrew
Andrew Owen
k...@little-bat.de wrote on 17/5/00 4:08 pm:
> maybe i added too much in my enthusiasm. that's why i appended the
> 'let's start with the palettes first' at the end. finally, it's up to
> andrew whether he'd like to include a new screen mode or something like
> this in his version of a new rom. if it's not too weird i'd like to
> support it.
Well I was thinking about having a 512x192 screen mode using both screen
areas on the 128 in a way similar to that described by Alvin Albrecht.
Again, it would be handled externally, not by the ROM, thus not introducing
incompatibilities.
> ZX Spectrum SE ... is this another project or the latest name of the
> former +4 ?
Well, I already released a +4 ROM, so now I'm working on the ZX Spectrum SE.
You don't need to support the old +4, just the new SE as I found lots of
bugs in the +4 after I released it (although as I discovered recently it is
supported by MESS).
-Andrew
Alvin Albrecht
> OK, but I still need to know which ports are free: does anything use:
>
> 00h, FFh, 4FFDh, FFFFh
00: the ula responds to anything even
ff/ffff: if I remember right, Arkanoid uses this
ghost port to read screen bytes fetched by the
ula.
4ffd: did you check pera putnik's site? He has info there
on how the spectrum decodes xxfd.
As a matter of fact, Pera has a list of likely
candidates for port addresses.
Alvin
Andrew Owen
aral...@interchange.ubc.ca wrote on 18/5/00 6:37 am:
> Andrew Owen wrote:
>
>> OK, but I still need to know which ports are free: does anything use:
>>
>> 00h, FFh, 4FFDh, FFFFh
>
> 00: the ula responds to anything even
> ff/ffff: if I remember right, Arkanoid uses this
> ghost port to read screen bytes fetched by the
> ula.
> 4ffd: did you check pera putnik's site? He has info there
> on how the spectrum decodes xxfd.
Yeah I checked, but I'm still pretty much mystified.
> As a matter of fact, Pera has a list of likely
> candidates for port addresses.
Not on the site. Only the fact that whatever address you use the chances are
that all but three bits of the low-byte will trigger something else.
I guess it'll have to be one of the addresses 00-FF anyway so what about:
01 - Bound to be used by something
02?
31 - Evil Kempston joystick?
FD - I think it's used by some disk interfaces
What about E0 or E1?
-Andrew
Philip Kendall
> in article 392381B0...@interchange.ubc.ca, Alvin Albrecht at
> aral...@interchange.ubc.ca wrote on 18/5/00 6:37 am:
>
> > 00: the ula responds to anything even
>
> 01 - Bound to be used by something
Lots of bits low, so yes.
> 02?
See #00 comment above :-)
> 31 - Evil Kempston joystick?
Yep.
> FD - I think it's used by some disk interfaces
And by the 128Kb paging scheme (as in #7FFD, etc).
> What about E0 or E1?
#E0 is even. #E1 again has lots of bits low and will probably trigger
various things (eg Interface I, which is on bits 3 and 4).
I think you need to start thinking in terms of bit fields, rather than
simple numbers. The problem here, is that all the low 8 bits are taken
by something (ULA, 128Kb/Sinclair joysticks, disk interfaces,
Interface 1 x 2, Kempston x 3). To work out what's free, we're going
to have to find out the decoding schemes used by all these
interfaces...
OTOH, if we're not going to be writing large amounts of data to this
port, we could consider using one of the upper 8 bits of the bus, as
the extra set up time wouldn't then be important.
If we do want to use a port under #100, we may have to go for an Ugly
Hack solution of making it use either bit 2 or 3, and just say
`Sorry. You can't use this if you've got both a disk interface and an
If1 attached' -- what compatability problems are there between the
various disk interfaces and the If1 at present? For example, can you
use an MB02 with the If1?
Phil
--
/ Philip Kendall <p...@ast.cam.ac.uk> \
| New? Read the FAQ: http://www.kendalls.demon.co.uk/cssfaq/ |
\ Spread css-auth: http://www.ast.cam.ac.uk/~pak/decss.html /
Andrew Owen
p...@ast.cam.ac.uk wrote on 18/5/00 12:44 pm:
> I think you need to start thinking in terms of bit fields, rather than
> simple numbers. The problem here, is that all the low 8 bits are taken
> by something (ULA, 128Kb/Sinclair joysticks, disk interfaces,
> Interface 1 x 2, Kempston x 3). To work out what's free, we're going
> to have to find out the decoding schemes used by all these
> interfaces...
Acording to Pera's info bit 4, 2 and 3 are free. If IF1 uses 2 and 3 then
that leaves bit 4. I would have used the ULA's port but that also handles
the sound and load/save so that's not an option.
This would make port 88h a possible contender yes? What stuff uses bit 4 at
present?
> OTOH, if we're not going to be writing large amounts of data to this
> port, we could consider using one of the upper 8 bits of the bus, as
> the extra set up time wouldn't then be important.
It's not a lot of info but how do we do this without disturbing the lower
part?
> If we do want to use a port under #100, we may have to go for an Ugly
> Hack solution of making it use either bit 2 or 3, and just say
> `Sorry. You can't use this if you've got both a disk interface and an
> If1 attached' -- what compatability problems are there between the
> various disk interfaces and the If1 at present? For example, can you
> use an MB02 with the If1?
I don't know! :(
-Andrew
Philip Kendall
> in article ye8ln18...@cass52.hoyle.star.fleet, Philip Kendall at
> p...@ast.cam.ac.uk wrote on 18/5/00 12:44 pm:
>
> > I think you need to start thinking in terms of bit fields, rather than
> > simple numbers. The problem here, is that all the low 8 bits are taken
> > by something (ULA, 128Kb/Sinclair joysticks, disk interfaces,
> > Interface 1 x 2, Kempston x 3). To work out what's free, we're going
> > to have to find out the decoding schemes used by all these
> > interfaces...
>
> Acording to Pera's info bit 4, 2 and 3 are free. If IF1 uses 2 and 3 then
> that leaves bit 4.
It uses 3 and 4, not 2 and 3.
> This would make port 88h a possible contender yes?
No. Remember bit *reset* means active. #88 has 6 bits low! #FF-#88=#77
would be better :-)
But see below...
> What stuff uses bit 4 at present?
If1. Bit 2 is still apparently free though, but that is used by the ZX
Printer and the Disciple (see eg Ramsoft's Tech Guide, where all the
ports are listed as being #xB). I believe other disk interfaces use
the same bit...
According to Warajevo's docs, the Kempston joystick responds to all
ports with bit 5 reset. Traditionally, 31 is used for this purpose,
but this does apparently leave 6 and 7 free. Pera's docs list these as
`Kempston-soft', but I don't know what this really means -- anybody?
It does look like 6 and 7 might be available, though...
> > OTOH, if we're not going to be writing large amounts of data to this
> > port, we could consider using one of the upper 8 bits of the bus, as
> > the extra set up time wouldn't then be important.
>
> It's not a lot of info but how do we do this without disturbing the lower
> part?
Just make the port be of the form #xxFF -- then anything looking at
the LSB just sees all set and ignores it.
Important question time: is there a list out there of how various
peripherals decode the ports they're on?
Andrew Owen
p...@ast.cam.ac.uk wrote on 18/5/00 4:07 pm:
>> This would make port 88h a possible contender yes?
>
> No. Remember bit *reset* means active. #88 has 6 bits low! #FF-#88=#77
> would be better :-)
I knew I was missing somehthing. Right, I understand now. Thanks!
> But see below...
>
>> What stuff uses bit 4 at present?
>
> If1. Bit 2 is still apparently free though, but that is used by the ZX
> Printer and the Disciple (see eg Ramsoft's Tech Guide, where all the
> ports are listed as being #xB). I believe other disk interfaces use
> the same bit...
>
> According to Warajevo's docs, the Kempston joystick responds to all
> ports with bit 5 reset. Traditionally, 31 is used for this purpose,
> but this does apparently leave 6 and 7 free. Pera's docs list these as
> `Kempston-soft', but I don't know what this really means -- anybody?
>
> It does look like 6 and 7 might be available, though...
If I'm following this right, 6 is used by the Kempston mouse, which uses
FADF, FBDF and FFDF. It is also used by the Scorpion's Centronics interface
at FFDD. Bit 2 appears to be used by the Scorpion to switch in RAM banks
8-15.
>>> OTOH, if we're not going to be writing large amounts of data to this
>>> port, we could consider using one of the upper 8 bits of the bus, as
>>> the extra set up time wouldn't then be important.
>>
>> It's not a lot of info but how do we do this without disturbing the lower
>> part?
>
> Just make the port be of the form #xxFF -- then anything looking at
> the LSB just sees all set and ignores it.
So it's just a case of finding out which 'xx's have been used then.
> Important question time: is there a list out there of how various
> peripherals decode the ports they're on?
I've been looking but I can't find one.
What's the best way of passing 16-bits via an OUT as quickly as possible?
-Andrew
Andrew Owen
Assuming for the moment that nothing else uses these port addresses I
propose:
FEFF - Select colour to change (5 bits)
FDFF - Set Red Level (4 bits)
FCFF - Set Green Level (4 bits)
FBFF - Set Blue Level (4 bits)
Which means you can have up to 32 colours on screen (as discussed
previously) and palette manipulation becomes relatively easy. You could also
use the remaining three bits of the colour change to do things like reset
the palette, and possibly even enable/disable FLASH and BRIGHT for
compatiblity. Thoughts please.
-Andrew
Geoff Winkless
> in article ye8k8gr...@cass52.hoyle.star.fleet, Philip Kendall at
> p...@ast.cam.ac.uk wrote on 18/5/00 4:07 pm:
Decode the high byte of the address lines as the high byte of the value and
get the low byte of the value from the data lines. (Or the other way, if you
prefer)
Just decode the lower byte of the address lines to select the peripheral.
eg the keyboard uses this mechanism (but IN instead of OUT)
eg if you want to output HL to a peripheral on port (eg) 0x77
LD C, 0x77
LD B, H
OUT (C), L
Geoff
Philip Kendall
> > What's the best way of passing 16-bits via an OUT as quickly as possible?
> Scratch that, I've got a better idea.
>
> Assuming for the moment that nothing else uses these port addresses I
> propose:
>
> FEFF - Select colour to change (5 bits)
> FDFF - Set Red Level (4 bits)
> FCFF - Set Green Level (4 bits)
> FBFF - Set Blue Level (4 bits)
Personally, I think that's too many addresses -- the problems we're
having are because other peripherals have taken large chunks of the IO
space. There are only 256 of them in the #xxFF range, so why not just
take one and then send it a sequence of bytes, the first being a
command code and the rest being data bytes for that command.
Andrew Owen
p...@ast.cam.ac.uk wrote on 18/5/00 5:58 pm:
>> Assuming for the moment that nothing else uses these port addresses I
>> propose:
>>
>> FEFF - Select colour to change (5 bits)
>> FDFF - Set Red Level (4 bits)
>> FCFF - Set Green Level (4 bits)
>> FBFF - Set Blue Level (4 bits)
>
> Personally, I think that's too many addresses -- the problems we're
> having are because other peripherals have taken large chunks of the IO
> space. There are only 256 of them in the #xxFF range, so why not just
> take one and then send it a sequence of bytes, the first being a
> command code and the rest being data bytes for that command.
OK, lets say we send one byte to FEFF. We could store the RGB levels in a
register pair and just have the hardware read them from there. Then we could
have a reasonable number of commands as follows.
Bit 0-4 (a number from 0-31) - change that colour to the one stored in AF
Bit 5 - reset the palette to the Spectrum default (needed by NEW etc)
Bit 6 - switch FLASH on/off (enabling access to 32 colours instead of 16)
Bit 7 - swith 512x192 screen (uses both screens of 128) on/off.
Alternately, just send another two bytes with the 12-bit colour data after
the command.
Comments?
-Andrew
Alvin Albrecht
> According to Warajevo's docs, the Kempston joystick responds to all
> ports with bit 5 reset. Traditionally, 31 is used for this purpose,
> but this does apparently leave 6 and 7 free. Pera's docs list these as
> `Kempston-soft', but I don't know what this really means -- anybody?
I'm not sure either but he does plainly say that all
schematics he's seen show that only bit 5 is used in port
decode. However this & Warajevo's docs confuse me because
every schematic I've seen of the Kempston interface plainly
shows that bits 5,6 & 7 are all used for port decode (see
for example the schematic on WOS).
> Just make the port be of the form #xxFF -- then anything looking at
> the LSB just sees all set and ignores it.
Some software like Arkanoid won't be happy
with this. The programmers assume that port
#FF won't be connected to anything so they
can use it to scan screen bytes being read
by the ula.
> Important question time: is there a list out there of how various
> peripherals decode the ports they're on?
I sense it's time to expand the FAQ. Here are a few
contributions to get things started:
48K Spectrum:
1. Port # XXXX XXX0 RW, ula
On read, port address bits 15..8 select keyboard row
2. Port # 000X XXXX R , kempston joystick
3. Port # 1111 1011 RW, ts2040 / alphacom 32 printer
4. Port # XXXX X0XX RW, ZX printer
TS2068:
1. Port # 1111 1110 RW, see spectrum port #FE
2. Port # 1111 1111 RW, display mode
3. Port # 1111 0110 RW, ay data
4. Port # 1111 0101 W, ay register
5. Port # 1111 0100 RW, horizontal select register
AERCO CENTRONICS INTERFACE:
1. Port # 0111 1111 RW
JLO DISK INTERFACE:
1. Port # 1000 1111, RW, read status/write command reg
2. Port # 1001 1111, RW, read/write track reg
3. Port # 1010 1111, RW, read/write sector reg
4. Port # 1011 1111, RW, read/write data reg
5. Port # 1011 0111, W, drive/density/side select
Alvin
Alvin Albrecht
> > Assuming for the moment that nothing else uses these port addresses I
> > propose:
> >
> > FEFF - Select colour to change (5 bits)
> > FDFF - Set Red Level (4 bits)
> > FCFF - Set Green Level (4 bits)
> > FBFF - Set Blue Level (4 bits)
>
> Personally, I think that's too many addresses -- the problems we're
> having are because other peripherals have taken large chunks of the IO
> space. There are only 256 of them in the #xxFF range, so why not just
> take one and then send it a sequence of bytes, the first being a
> command code and the rest being data bytes for that command.
I don't think four addresses out of 256 is all that
bad personally. How many port addresses do you need?
Anyway, I'd go for two ports:
A: one port to select colour to change
B: one port to read / write a sequence of 8 bit RGB values.
An IN/OUT to port A resets the sequence counter.
A read/write to port B reads/writes current R/G/B value
and increases the sequence count. That way you can
read current RGB values or selectively change RGB values.
Alvin
Andrew Owen
aral...@interchange.ubc.ca wrote on 19/5/00 3:33 am:
>>> FEFF - Select colour to change (5 bits)
>>> FDFF - Set Red Level (4 bits)
>>> FCFF - Set Green Level (4 bits)
>>> FBFF - Set Blue Level (4 bits)
> Anyway, I'd go for two ports:
>
> A: one port to select colour to change
> B: one port to read / write a sequence of 8 bit RGB values.
Do we really need a palette of 16 million colours though?
> An IN/OUT to port A resets the sequence counter.
> A read/write to port B reads/writes current R/G/B value
> and increases the sequence count. That way you can
> read current RGB values or selectively change RGB values.
That sounds reasonable. FEFF and FDFF it is then.
>>Some software like Arkanoid won't be happy
>>with this. The programmers assume that port
>>#FF won't be connected to anything so they
>>can use it to scan screen bytes being read
>>by the ula.
The TS2068 has this problem doesn't it. There is a work around though isn't
there?
-Andrew
Philip Kendall
> Philip Kendall wrote:
>
> > Important question time: is there a list out there of how various
> > peripherals decode the ports they're on?
>
> I sense it's time to expand the FAQ. Here are a few
> contributions to get things started:
[snip]
Right -- first stab at this at:
http://www.ast.cam.ac.uk/~pak/ports.html
I know most of the links don't work :-)
What we need now is more information: can anyone settle the Kempston
decoding (are bits 6 and 7 used?), and other peripherals (decodings
for eg Sinclair joysticks, Disciple, +D, Betadisk, MB02, etc, etc).
Comments welcome...
Andrew Owen
[Peripherals section in FAQ]
> Right -- first stab at this at:
>
> http://www.ast.cam.ac.uk/~pak/ports.html
>
> I know most of the links don't work :-)
>
> What we need now is more information: can anyone settle the Kempston
> decoding (are bits 6 and 7 used?), and other peripherals (decodings
> for eg Sinclair joysticks, Disciple, +D, Betadisk, MB02, etc, etc).
The Russian machines FAQ on WOS has detailed port info for the Pentagon,
Scorpion, Kempston mouse and TR-DOS. I've found several sites about the IF1
but they seem to conflict, the same for the Kempston. I think John Garner's
got a few links to sites as well but I wasn't really keeping track when I
trawled through the other day.
-Andrew
Alvin Albrecht
> Right -- first stab at this at:
>
> http://www.ast.cam.ac.uk/~pak/ports.html
> Comments welcome...
Looks good. I like the idea of having a technical
ref link. That's a good place for putting a programming
reference or something.
Alvin
Alvin Albrecht
> > A: one port to select colour to change
> > B: one port to read / write a sequence of 8 bit RGB values.
>
> Do we really need a palette of 16 million colours though?
:-) No. But if the bits are there... On the other
hand any implementation that wants to stick with
5 bits can just ignore the top 3 bits.
> >>Some software like Arkanoid won't be happy
> >>with this. The programmers assume that port
> >>#FF won't be connected to anything so they
> >>can use it to scan screen bytes being read
> >>by the ula.
>
> The TS2068 has this problem doesn't it. There is a work around though isn't
> there?
With hacking, yes. Just as long as everyone
knows there are a handful of programs out there
that will have a problem. Of course, it seems
that no matter what port assignments you choose
there will be problems.
Alvin
Andrew Owen
>>> A: one port to select colour to change
>>> B: one port to read / write a sequence of 8 bit RGB values.
>> Do we really need a palette of 16 million colours though?
> :-) No. But if the bits are there... On the other
> hand any implementation that wants to stick with
> 5 bits can just ignore the top 3 bits.
If a program is expecting 0F 0F 0F to be bright white (4-bits) and then the
palette gets expanded to 8-bits some programs are going to have very dim
looking screens. We need to agree a standard. I'm don't think it should be
less than 4-bits (4,096 colours) but I think 5-bits may be a 'bit' excessive
(32,768 colours). Especially as you will only be able to display a max of 32
on screen at once.
[Arkanoid]
>>>> The programmers assume that port #FF won't be connected to anything
Well they should have thought of something else instead of screwing up 256
port addresses.
>> There is a work around though isn't there?
> With hacking, yes. Just as long as everyone
> knows there are a handful of programs out there
> that will have a problem. Of course, it seems
> that no matter what port assignments you choose
> there will be problems.
Then can we at least agree on using port FDFF and FEFF?
-Andrew
Andrew Owen
100% compatibility with everything while allowing 32 colours on screen from
a palette of up to 16million colours (although I think 4,096 would be
better). So here, at last, is my first draft for the new video hardware
(which will of course be emulated first and built later after the circuits
have been designed by someone other than me):
Basically the hardware will take data from the screen area to produce the
picture. This will be stored in the normal Spectrum format so that existing
programs will work without modification while the new functions will be
accessible from BASIC. When it is powered up it will default to the standard
palette with standard behaviour (support for BRIGHT and FLASH as normal). It
will also default to this if the PC goes to the NEW command in either ROM 0
or ROM 1 or if a RST 0 instruction is executed.
The video hardware is addressed by ports #FDFF and #FEFF.
#FDFF holds recieves the CONTROL instruction while #FEFF recieves the DATA.
instructions to #FDFF work as follows
BIT 7 6 5 4 3 2 1 0
| |
---------
|
With BIT 5-7 off, BIT 0-4 sets
the colour to change from 0-31
BIT 5-7 are read as a 3-BIT number with the following instructions:
0 - Select colour to change (colour info in BIT 0-4)
1 - Restore default Spectrum screen settings
2 - Flash On (16 colour mode). Colours 16-31 are not used.
3 - Flash Off (32 colour mode). All colours are available.
4 - 256x192 mode (normal Spectrum mode - reads from Screen 1 or 2)
5 - 512x192 mode (reads from Screen 1 and 2 to produce picture)
6 - 512x216 mode (uses both screen areas to store mono bitmap in series)
7 - Lock out (#xxFF behaves as normal until reset - support for Arkanoid)
DATA sent to #FEFF holds the colour info and advances the colour counter.
The colour counter starts on RED so sending data to the port changes the RED
value of the colour and advances the counter to GREEN and so on. Choosing a
new colour via #FDFF resets the counter to RED. Reading from port #FEFF will
give the current colour value and advance the counter.
I think 4-bits per colour (which would give a palette of 4,096) is plenty. I
think 3-bits (512) is too little. What do you think. Is 4,096 sufficient or
should we use 5-bits (32,768). By my calculations the most colours you could
possible hope to get on the screen at once using careful timing is 12,288.
Notes:
------
Screen 1 and 2 refer to the two screen ares on the 128. In 512x192 mode they
would simply be displayed side by side.
If people are not keen on 512x216 mono mode, it could be reserved for future
expansion (say support for 640x480x256 colour mode).
Ok, now it's time for your comments!
-Andrew
Andrew Owen
I recently lost a lot of data in a hard disk crash including all the
pictures I did for zxsp and zxsp itself. I'd appreciate it if you could send
them (including the ROMs) when you get a chance.
-Andrew
Andrew Owen
-Andrew
roger...@gmail.com
http://www.youtube.com/watch?v=EmwW_6kUdHw
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?
roger...@gmail.com
fat...@neonlite.me.uk
> Those who have been following my posts over the last few months will know
> that I have been slaving away on a new ROM set for the Spectrum. I still
> need help but it is nearing completion. Anyway, rather than wait for someone
> to create a magnificent new machine I have decided to do it myself (if only
> in emulation to begin with). Here's the spex:
>
> Bugfixed ROM set which is more compatible with the 48 than any other 128.
> 128k RAM, expandable to 512k, paged exactly the same as the Scorpion.
> 7.08Mhz processer, switched exactly the same as the Scorpion.
>
> switching to achieve a true 16-32 colours on screen from a palette of around
> 4,096 colours. What I need to know is, are there any OUT addresses free to
> do this. What sort of palette range do people want. How should the palette
> be handled.
>
> My initial proposal was for 16 colours from 4,096 using two bytes.
>
> Bit 1-4 is the number of the colour while the other 12 bits contain the
> intensity of R,G, and B. The 16 colours refer to the standard 8 and their
> bright equivalents, effectively giving two eight colour palettes.
>
> But it would also be possible to have 32 colours by using the FLASH
> attribute:
>
> normal = 1-8, bright = 9-16, normal+flash = 17-24, bright+flash = 25-32.
>
> This would sacrifice the standard use of the FLASH command.
>
> The effect would be to have four palettes of 8 colours available at once:
>
> no modifier = palette 1
> bright = palette 2
> flash = palette 3
> bright+flash = palette 4
>
> The normal restrictions on two colours per character cell would still apply
> and you could not mix colours from different palettes in the same cell but
> it would be relatively easy to modify existing software to take advantage of
> the extended palette.
>
> So what I want to know is:
>
> Should we sacrifice FLASH to get 32 colours on screen?
> (The more I think about it, the more I think it would be acceptable)
> How should the palettes be selected (OUT commands etc?)
>
> 4 bits per channel = 4,096
> 5 bits per channel = 32,768
> 6 bits per channel = 262,144
> 7 bits per channel = 2,097,152
> 8 bits per channel = 16,777,216
>
> I personally think 4,096 colours is plenty.
> (it was enough for the Amiga and the STE)
>
> -Andrew
> p.s. You have until I have the ROM finished to decide. Then it gets coded
> and, hopefully, becomes a new standard (and then Sonic ZX can take advantage
> of it).
>
> without sacrificing compatibility. I've figured out a way to make the DRAW
> commands use the lower two lines of the screen without making existing
> programs behave differently. I've extended the character set (comments
> welcome) so:
>
> CHR$ 24 = ae
> 25 = fs
> 26 = oe
> 27 = oe (alt)
> 28 = acute accent
> 29 = umlaut
> 30 = grave accent
> 31 = hachek (the Czech/Welsh character)
>
> This means the lowercase versions of the most of the international
> characters are available (due to the flexibilty of the replacement
> characterset)
>
> I've also replaced the memory test in ROM 0 with a memory wipe (much
> faster).
>
> I'm looking at making line 0 editable (to fix the line 0 bug in 128 BASIC)
> and extending the range of possible line numbers up to 32,767.
>
> Any other suggestions for improvements are welcome.
andrew, are you available to have a chat about this? thanks)