(REQUEST) routines for writing in the ZX Spectrum border...
Rui Tavares
to "mature" on it, I became a real Computer Science student,
and never got time to study it. Anyway, here are my suspicions
on how to do it (all in machine code, of course):
1. some hidden ports with "special" properties
(I believe there is a manual with undocummented
stuff somewhere, but I never managed to get my
hands on it - uugghh).
2. "outing" in the FE port(s) in some misterious-
-and-most-difficult-to-find cycled fashion.
2.1 (this is a new one) ever considered the
possibility of using strange attractors?...
Rui Tavares
ps: there is a list of books about spectrum available; it would be a
good idea to include it in the FAQ. (whoever has it).
.
Arnt Gulbrandsen
Close, but no cigar. The only special property is that many port
numbers have the same function.
> 2. "outing" in the FE port(s) in some misterious-
> -and-most-difficult-to-find cycled fashion.
Yep.
The vital point is that for each function, there are many valid port
addresses since some bits of the address are ignored. The routines
I've seen that write on the border (Starion, notably) use OTDR or
OTIR to repeatedly OUT from (HL) to a port equivalent to FE. Port
FF can be used to sync with the horizontal retrace; read it again
and again until FF is read.
--Arnt
Calum Benson
>In article <1994Jan3.1...@di.fc.ul.pt>,
>
>The routines
>I've seen that write on the border (Starion, notably) use OTDR or
>OTIR to repeatedly OUT from (HL) to a port equivalent to FE. Port
>FF can be used to sync with the horizontal retrace; read it again
>and again until FF is read.
Incidentally, the author of Starion, David Webb, gives you all the code for
drawing graphics to the border in his book 'Advanced Spectrum Machine
Language', published by Melbourne House. Doubtless out of print now, but
you might be able to get it from your library. I've still got a copy too,
if anybody's looking for the ISBN or anything (but don't expect me to
post large chunks of it to the net for you...!)
Calum
+---------------------------------------+----------------------------+
|Calum Benson | email: cal...@logcam.co.uk |
|Logica Cambridge (User Interface Div.) | Tel: (0223) 66343 x4825 |
|Betjeman House +------------------+----------------------------|
|104 Hills Road | " I just wouldn't know a single word to say |
|Cambridge CB2 1LQ | If I flattened all my vowels and I threw |
|UK | the R away." (The Proclaimers) |
+--------------------+-----------------------------------------------+
Emil Obermayr
the I/O-addresses. I'll try to do some explanation.
The point with the port adresses is that the Spectrum just decodes
one address line of the lower half of the 16Bit-I/O-address as low
(The upper half is used only for keyboard scan).
(I will use an "/" for negative logic)
It's (A0 or /RD = low) to read from the ULA. The other address lines will
be ignored by the ULA. (A5 or A6 or A7 or /RD = low ) will get
the Kempston joystick. If you read with address lines A0, A5, A6
and A7 low there will be collision on the data bus between the
Kempston-IF and the ULA which will be won by the joystick, because
the ULA has got decoupling resistors in series with the data lines.
If no address line is zero, no port will answer to the IN command
or will get the data from the OUT command. So you can monitor the
data stream from the 16k-RAM to the ULA through the resistors
which will enable you to synchronize your program
with the line scan.
By the way: there is no need to do this to synchronize
with the start (top) of the picture: you can use
HALT (or PAUSE 1 in BASIC). Don't use
HALT with disabled interrupts (DI)! It's a good idea always
to use EI just before HALT. The code after HALT will be started
immediatly after the vertical sync to the monitor (or TV).
Bye,
Emil Obermayr
Teichmuellerstr. 2
D-38114 Braunschweig
Germany Tel.: +49/531/ 50 37 99
Mars Bar
> In article <1994Jan3.1...@di.fc.ul.pt>,
> Rui Tavares <r...@di.fc.ul.pt> wrote:
> > 1. some hidden ports with "special" properties
>
> Close, but no cigar. The only special property is that many port
> numbers have the same function.
Ahhhh... I think he means that on the Speccy you could play around with the `i'
register (not absolutely sure about this) and get the display to do horrible
things. That was pretty much undocumented.
Anyone like to explain that bit a little more scientifically?
Geoff
__ __ __ Like a soul without a mind|ga...@minster.york.ac.uk (INET)
|\ /|| || ) ( _) In a body without a heart |ga...@uk.ac.york.minster (JANET)
||\/|||--||-( _\\ I'm missing every part... | These opinions are my own. If
|| ||| || \(__/ (Massive Attack) |anyone agrees, more fool them.
Mars Bar
> numbers have the same function.
>
> addresses since some bits of the address are ignored. The routines
> I've seen that write on the border (Starion, notably) use OTDR or
> OTIR to repeatedly OUT from (HL) to a port equivalent to FE. Port
> FF can be used to sync with the horizontal retrace; read it again
> and again until FF is read.
Actually, this is a crap idea. Using otir is nowhere near as fast as actually
setting up out (c),r repeatedly where r is either a or b... if you set up b as
0... do this:
ld bc,0x00fe
out (c),a
out (c),b
out (c),b
out (c),a
etc etc etc
This will then give you on-off `pixels' in the border.
If you're really clever you can make it do a text scroller. (Well done Cookie).
If you're really *really* clever, you can make it do a text scroller which only
uses a tiny amount of processor time, by giving the `out' code lots of space
and calling that code at a different position each time - thus you only have
to change the bytes at the end of each line. (Well done me :-)
Of course, I'm sure cookie will now explain his much-improved technique... I'm
not convinced it looks any better, to be honest Si...
Cheers
AMCCS
>>> 1. some hidden ports with "special" properties
>>
>> Close, but no cigar. The only special property is that many port
>> numbers have the same function.
>
>Ahhhh... I think he means that on the Speccy you could play around with
the `i'
>register (not absolutely sure about this) and get the display to do
horrible
>things. That was pretty much undocumented.
>
>Anyone like to explain that bit a little more scientifically?
I don't know any scientific explanation, but I can tell you exactly when
it happened, at least if I remember well.
The I register must be set in the 16K-32K range, and the Z80 must be in
the IM2 mode. I noticed this when trying to write an interrupt routine
that would first call the keyboard reading routine in the ROM, and then do
various other things. I was very surprised when the screen started to
flicker, without any other disturbance. It was like the screen output was
delayed by one byte, at random intervals. To make it clearer, let's look
at the K cursor (when inverted):
********
* ** ***
* * ****
* *****
* * ****
* ** ***
* *** **
********
On the screen it would look like this:
********
* ** ***
* * ****
* *****
* * ****
* ** ***
* *** **
********
The delayed lines would randomly change at each frame, making the screen
flicker.
I checked the screen memory, and I found nothing special as expected.
I guess the IM2 mode changes the behaviour of the memory in some strange
way, and the ULA has to wait an extra clock cycle before being able to
read the memory. Of course the screen spot still moves, which makes the
screen look like if it flickered.
I really don't know if this explanation is valid in any way. I'm not good
at all in hardware, and I don't see anything that could overcome the ULA's
priority to delay it when accessing the display RAM.
Anyway, I don't think you can control this delay in order to use it.
Sebastien Bauer
SL COOKE
>etc etc etc
>Cheers
>Geoff
[wunnerful, amazing sig. deleted]
My method of doing it is twofold (on the SAM Coupe, this is folks... Speccy
users please ignore).
One way is using the palette colours...
LD BC,&00F8
LD D,nn
OUT (C),D
OUT (C),0
OUT (C),0
OUT (C),D
etc etc... D holds the palette colour... the OUT (C),0 is of course the &
ED71 undocumented opcode. (But damn well documented now :-) )
To scroll, I just scroll the opcodes... which is a quite interesting way of
doing it... I also add new forms of the opcodes at the end of each screen
line, and change the value of D for each line. People who've seen my SCPDU 6
Advert demo will know what I mean - it has multicoloured VU bars in the
border and a 32 pixel high border scrolly in shades of blue.
The other technique can produce (instead of the 16 pixel wide colours in the
border that you usually get) 1/2 size pixels. That's 1/2 the size of a mode
3 pixel, folks!
What you do to produce these is this:
You must have colour 15 set to 127 (WHITE) or you'll get very, very dim
pixels.
LD BC,&00FE
LD D,%10100111
LD E,%00000000
OUT (C),D
OUT (C),E
And that's it (of course, the OUT (C),E can be replaced with OUT (C),0 if
you prefer). What it does is to set the SAM border to bright white, at the
same time turning the screen off. Then you turn the screen back on, and the
border to black.
Due to a quirk in the ASIC (even Bruce Gordon - designer of it - was
surprised to find out this little quirk), the border colour change occurs 1
clock pulse before the screen is turned off. Thus, you get a pixel 1 clock
pulse wide in the border area... Nice, eh?
Simon Cooke
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
My email address is: Internet: C...@fs2.ee.umist.ac.uk,
Janet: C...@uk.ac.umist.ee.fs2
I'm a freelance journalist, programmer, juggler, conjurer, general
layabout (I study physics at Uni), and hopefully a nice guy. Who could
ask for anything more? (except for a shorter sig...)
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
"My God - could it be? Your Sinclair's art editor is Number two?"
Simon Cooke, April 93 issue, Your Sinclair magazine.
Does this mean I'm one of the only people on usenet to finish off by
quoting themselves??? :-)
Med Hynek (IN), UID=10091
>etc etc etc
Well, I made a non-shaking border text scroller once, and must say that the
only instruction you can reasonably use is a 16-clock one called OUTI. The
others aren't dividable by 4 and the image shakes. With this instruction and
right timing you can use any "graphics" in border area with the smallest
"point" 1 pixel high and 4 attrs long, and you can place it anywhere
(smallest step is 1 attr).
Hynek
--
Mars Bar
> Well, I made a non-shaking border text scroller once, and must say that the
> only instruction you can reasonably use is a 16-clock one called OUTI. The
> others aren't dividable by 4 and the image shakes. With this instruction and
> right timing you can use any "graphics" in border area with the smallest
> "point" 1 pixel high and 4 attrs long, and you can place it anywhere
> (smallest step is 1 attr).
Ummm... what?
See that out (c),r? See that 12 T-state instruction?
Now unless my maths has gone up shit creek, 12 is divisible by 4, right?
So that's not the reason OUTI is the only way to do it.
I have to admit, though, that my version works on the Sam, but not the
Spectrum, but I think it could be changed to work if you insert a few
nops at scan-flyback time.
Admittedly outi allows you to use more colours per line, but if you use all the
registers you can get 6 colours (8 if you include C but that has to be the
output port) and black.
ie
out (c),a
out (c),b # Note -- on the sam, if you're using c as the palette output
# you should set up the border colour to the value that you
# want b to hold here
out (c),c
out (c),d
out (c),e
out (c),h
out (c),l
out (c),(hl) -- undocumented out (c),0
You could also do an exx at the scan flyback - another 4-tstate instruction -
to swap a `palette' if you like.
But, I admit, outi is much much easier :-)
Mr C. Smith
: In article <7578146...@minster.york.ac.uk> ga...@minster.york.ac.uk
: >>> 1. some hidden ports with "special" properties
: >>
: >> Close, but no cigar. The only special property is that many port
: >> numbers have the same function.
: >
: >Ahhhh... I think he means that on the Speccy you could play around with
: the `i'
: >register (not absolutely sure about this) and get the display to do
: horrible
: >things. That was pretty much undocumented.
: >
: >Anyone like to explain that bit a little more scientifically?
: I don't know any scientific explanation, but I can tell you exactly when
: it happened, at least if I remember well.
: The I register must be set in the 16K-32K range, and the Z80 must be in
: the IM2 mode. I noticed this when trying to write an interrupt routine
: that would first call the keyboard reading routine in the ROM, and then do
: various other things. I was very surprised when the screen started to
: flicker, without any other disturbance. It was like the screen output was
: delayed by one byte, at random intervals. To make it clearer, let's look
: at the K cursor (when inverted):
Right !
Technical Explanation :
You cannot vector an interrupt routine into the bottom 16K of RAM
(ie 16K to 32K) - if you do you get contention between the Z80 and the
ULA Video DAM which causes the Video picture to break up.
------ Short and Sweet yeah ? ---------
It doesn't have any real use. I once used it to check my interrupt routine
was running, by vectoring it into the bottom 16K.
Chris ;-)
--
+--------------------------+-------------------------+
| Name : Chris Smith | University of Liverpool |
| Email: | Dept of Electrical and |
| ced...@liverpool.ac.uk | Electronic Engineering |
+--------------------------+-------------------------+
| Plan: If it doesn't work then hit it hard, charge |
| the customer $0.1 for the labour and $300 |
| for knowing where and how to hit it. |
| Its always a 'mechanical' fault anyway. |
+----------------------------------------------------+
The views expressed above reflect those of my private thoughts.
They do not directly mirror the views of this establishment.