Account Options

  1. Sign in
The old Google Groups will be going away soon.
Switch to the new Google Groups.
Google Groups Home
« Groups Home
Message from discussion RFC: ULA Replacement for ZX Spectrum SE
The group you are posting to is a Usenet group. Messages posted to this group will make your email address visible to anyone on the Internet.
Your reply message has not been sent.
Your post was successful
 
From:
To:
Cc:
Followup To:
Add Cc | Add Followup-to | Edit Subject
Subject:
Validation:
For verification purposes please type the characters you see in the picture below or the numbers you hear by clicking the accessibility icon. Listen and type the numbers you hear
 
Andrew Owen  
View profile  
 More options May 15 2000, 3:00 am
Newsgroups: comp.sys.sinclair
From: Andrew Owen <ao...@brandnewco.org>
Date: 2000/05/15
Subject: RFC: ULA Replacement for ZX Spectrum SE
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.


 
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.