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.
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.

On 15 May 2000, Equin0x wrote this message in comp.sys.sinclair. Which was
nice.

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"        |

news:B545AA0C.233%aowen@brandnewco.org...

  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

in article Pine.OSF.4.05.10005151322300.10187-100...@cpca4.uea.ac.uk,
Equin0x at y9827...@cpca6.uea.ac.uk wrote on 15/5/00 1:31 pm:

All 16 channels are supported by 128 BASIC as standard.

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.

Yes.

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?

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.

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

in article 8F359FDD9gasmanraww...@163.1.2.7, Matthew Westcott at
gas...@raww.org.RemoveThisBit.invalid wrote on 15/5/00 2:33 pm:

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.)

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

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?!?!]

in article 8fp1pn$jf...@SOLAIR2.EUnet.yu, Vlada Stepanovic at
pp...@soyaprotein.com wrote on 15/5/00 3:32 pm:

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.

You wouldn't happen to know where they are would you?

-Andrew

In message <B545AA0C.233%ao...@brandnewco.org>
          Andrew Owen <ao...@brandnewco.org> wrote:

[snip]

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.

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)

On 16 May 2000, Günter Woigk) wrote this message in comp.sys.sinclair. Which
was nice.

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"                    |

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.

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

news:8F359FDD9gasmanrawworg@163.1.2.7...

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

in article 8ftndk$ne...@soap.pipex.net, Geoff Winkless at
geoff-at-farmline-dot-...@127.0.0.1 wrote on 17/5/00 10:10 am:

Just out of interest, which OUT exactly and how did it work?

We could do that with this project.

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

news:B54835DE.49F%aowen@brandnewco.org...

Can't remember the exact details, but I _think_ there was a band of 16 OUTs
which corresponded to the 16 palette colours.

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

Hi!

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.

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 ?

        ... kio !
--
http://little-bat.de
http://little-bat.de/zx_spectrum.html
k...@little-bat.de (private)

Good idea, presuambly PLAY's support for MIDI would still work then.

Sounds more than enough.

Hmm. There is still some software that uses it which would look a bit odd
without it. But not much, I guess.

OUT commands. Preferably locked at startup and requiring a special coded
sequence of OUTs to unlock the extra hardware for compatability (ala the
CPC+)

And the CPC+. :-) Although, 256 would be perfectly adequate and would
perhaps better suit an 8 bit machine.

Sounds good. Although it would be nice if Sonic ZX still ran on a "proper"
speccy.

AndyC

in article Pine.OSF.3.95.1000517165314.27660A-100...@humphrey.sys.uea.ac.uk,
AndyC at a...@sys.uea.ac.uk wrote on 17/5/00 4:57 pm:

Yes.

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.

I don't think 256 is enough, it doesn't give a lot of shades of one colour.

It will run on an unexpanded 48K machine but will take advantage of the
extra hardware if it's available.

-Andrew

in article 1eas2ua.1vg2ws11dr7xoN%...@little-bat.de, kio Günter Woigk at
k...@little-bat.de wrote on 17/5/00 4:08 pm:

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.

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

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

in article 392381B0.1B881...@interchange.ubc.ca, Alvin Albrecht at
aralb...@interchange.ubc.ca wrote on 18/5/00 6:37 am:

Yeah I checked, but I'm still pretty much mystified.

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

Lots of bits low, so yes.

See #00 comment above :-)

Yep.

And by the 128Kb paging scheme (as in #7FFD, etc).

#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 /

in article ye8ln18jd5c....@cass52.hoyle.star.fleet, Philip Kendall at
p...@ast.cam.ac.uk wrote on 18/5/00 12:44 pm:

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?

It's not a lot of info but how do we do this without disturbing the lower
part?

I don't know! :(

-Andrew

It uses 3 and 4, not 2 and 3.

No. Remember bit *reset* means active. #88 has 6 bits low! #FF-#88=#77
would be better :-)

But see below...

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...

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?

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 /

in article ye8k8grkicl....@cass52.hoyle.star.fleet, Philip Kendall at
p...@ast.cam.ac.uk wrote on 18/5/00 4:07 pm:

I knew I was missing somehthing. Right, I understand now. Thanks!

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.

So it's just a case of finding out which 'xx's have been used then.

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