[FAQ]
[Frequently Asked Questions]
[Resources]
[Emulators]
[Where Is...?]
[File Formats]
[Technical Information]
[Pinouts]
[Acknowledgements]
| 48K TECHNICAL INFORMATION |
|---|
This page last updated on 20 May 1999
[Z80 Tech Info] [48K Tech Info] [128K Tech Info] [Peripheral Ports]
[Z80 CPU]
[CB ops]
[ED ops]
[DD/FD ops]
[R reg]
[Undocumented flags]
[Interrupts]
[Channels & Streams]
[Hardware]
[Port FE]
[The 48K Spectrum]
[Contended Memory]
[Interface 1]
[Port E7]
[Port EF]
[Port F7]
[Joysticks]
[The 128K/+2 Spectrums]
[Memory]
[Keypad]
[Sound chip]
[The +2A/+3 Spectrums]
[Memory]
[Disk drive]
| CHANNELS & STREAMS |
|---|
The Spectrum has a surprisingly modern system of input and output when the age of the Spectrum is considered. However, what is more surprising is the fact that the Spectrum manual barely scratches the surface of what is possible.
I/O on the Spectrum is based on channels and streams. Since the standard Spectrum has only a limited range of I/O devices is makes sense that different commands are available for each I/O device. For example, PRINT is used to send output to the screen, whereas LPRINT is used to send output to the printer.
The extra devices catered for by Interface 1 (microdrives, RS232, and networking) reduced the practicality of continuing to invent new commands, although this was provided for in the case of the microdrives.
Streams and channels intuitively correspond to the software and hardware parts of I/O respectively. That is, a stream should be thought of merely as a collection of data going to or coming from a piece of hardware, and a channel should be associated with a particular piece of hardware such as a printer. On the Spectrum streams are numbered from 0 through 15, and their basic operations are reading and writing data.
The BASIC statement INPUT #s; <input-list> will read data from stream number s, 0 <= s <= 15, into the variables specified in the input-list. Conversely, the BASIC statement PRINT #s; <print-list> will write data to stream s, 0 <= s <= 15. In general both INPUT # and PRINT # can be used in the same way as their ordinary counterparts INPUT and PRINT. In particular all the normal complexity of a PRINT statement can be used equally well in a PRINT # statement. In each case the data sent to the stream is exactly the same as the data which would be sent to the screen by the PRINT statement. The INPUT # statement is slightly more complicated in that is can both read and write data, as in INPUT "What is your name? "; A$. In fact each stream really has two components, an input stream and an output stream. Data written to the stream by either PRINT # or INPUT # goes to the output stream while input comes from the input stream.
It is even possible to change streams part way through a PRINT statement, as in PRINT #3; "hello"; #6; "there". This is obviously fairly confusing though, so should probably be avoided unless their is a good reason for using this construct.
How do you know which stream numbers are associated with which channel? Before a stream is used it must be OPENed. Opening a stream serves two purposes. It associates the given stream with a particular piece of hardware (the channel), and actually signals the relevant device that it is going to be used. Stream are opened in BASIC using the syntax OPEN #s, c where s is the stream number being opened and c is a string specifying the channel to associate the stream with. Following this command any data sent to stream s will go to the specified channel. It is possible to open several streams to the same device, but each stream can only be associated with a single channel.
The statement CLOSE #s, c is used to end the association of stream s with channel c. It also informs that associated hardware that it is no longer required by stream s.
The unexpanded Spectrum supports four channels: "K" the keyboard channel, "S" the screen channel, "P" the printer channel, and "R" an internal channel used by the Spectrum to send data to the edit buffer. In practice the only channel that has both input and output of these is the keyboard channel. When the Spectrum is first powered up the following streams are opened automatically: 0: "K", 1: "K", 2: "S", 3: "P". Thus, the command LPRINT is really an alternative to writing PRINT #3. The "R" channel cannot be opened from BASIC. It is possible to redefine the standard channels, thus OPEN #2, "P" will cause output normally sent to the screen to be redirected to the printer.
For example, OPEN #5, "K" associates stream 5 with the keyboard, and thereafter INPUT #5; A$ would behave in an identical manner to INPUT A$.
The most important advantage of using streams is in the writing of device independent programs. Say that you wish to give the user the option of having all output go to either the screen or to the printer. Without using streams it is necessary then to have separate output statements for each device, as in
IF (output = printer) THEN LPRINT "Hello" ELSE PRINT "Hello"
but using streams we can just open a particular stream (say 4) to the desired output device and thereafter use only one output statement
PRINT #4; "Hello"
Obviously this will result is a much shorter program, particularly, if there are many output statements in the program. Further, it is an easy matter to add even further output devices if they become an option later in the programs development.
BASIC also allows LIST and INKEY$ to be used to streams. LIST #s will send a copy of the program to stream s; e.g. normally LIST #3 is the same thing as LLIST. However, on the standard Spectrum INKEY$ can only be used with the keyboard channel.
Technical section for machine code programmers.
Knowing about the actually layout of the stream records in memory is useful if you want to add your own hardware devices to the Spectrum, or if you which to make you own specialized streams. The information that defines each channel is stored in the channel information area starting at CHANS and ending at PROG - 2. Each channel record has the following format:
two-byte address of the output routine two-byte address of the input routine one-byte channel code letter
where the input and output routines are address of machine code sub- routines. The output routine must accept Spectrum character codes passed to it in the A register. The input routine must return data in the form of Spectrum character codes, and signal that data is available by setting the carry flag. If no data is available then this is indicated be resetting both the carry and zero flags. Stubs should be provided if a channel does not support either input or output (e.g. the stub may simply call RST 8 with an error code).
With Interface 1 attached an extended format is used. The above fields are followed by
two-byte address 8K error routine 40 two-byte address 8K error routine 40 one-byte length of channel descriptor
Data about which streams are associated with which channels is in a 38-byte area of memory starting at STRMS. The table is a series of 16-bit offsets to the channel record vectored from CHANS. A value of one indicates the channel record starting at CHANS, and so on. This accounts for 32 bytes of the 38. The remaining 6 bytes are for three hidden streams (253, 254, 255) used internally by BASIC. A zero entry in the table indicates a stream not open.
It is possible to redirect existing channels to your own I/O routines. This can be used among other things to cause LPRINT to use your own printer driver rather than the one provided in the ROM. It allows you to perform I/O for your own hardware devices, or for you to write your own handlers from PRINT and INPUT.
It is easiest to modify the existing "P" channel record. The "K" channel is not a good option for modification because its values are restored every time a INPUT statement is executed. It is possible to create new channel records elsewhere in memory, e.g. by changing the value of CURCHL. Another difficulty is that without Interface 1, OPEN will only work with K, S, and P and so it is necessary to provide some other way of opening your own channels.
To make space for a new record a call should be made to the ROM routine at 5717. This will allocate the requested space and alter any system variables affected by the change. The amount of space required is passed in BC, and the address of the first location to be allocated is passed in Hl. For example, LD BC, 100; LD HL, 23700; CALL 5717 will allocate 100 bytes starting at 23700. A new channel descriptor should start at one less than PROG.
| HARDWARE |
|---|
At the hardware level, the Spectrum is a very simple machine. There's the 16K ROM which occupies the lowest part of the address space, and 48K of RAM which fills up the rest. An ULA which reads the lowest 6912 bytes of RAM to display the screen, and contains the logic for just one I/O port completes the machine, from a software point of view at least.
| Port FE |
|---|
Every even I/O address will address the ULA, but to avoid problems with other I/O devices only port FE should be used. If this port is written to, bits have the following meaning:
Bit 7 6 5 4 3 2 1 0
+-------------------------------+
| | | | E | M | Border |
+-------------------------------+
The lowest three bits specify the border colour; a zero in bit 3 activates the MIC output, whilst a one in bit 4 activates the EAR output and the internal speaker. However, the EAR and MIC sockets are connected only by resistors, so activating one activates the other; the EAR is generally used for output as it produces a louder sound. The upper two bits are unused.
If port FE is read from, the highest eight address lines are important too. A zero on one of these lines selects a particular half-row of five keys:
IN: Reads keys (bit 0 to bit 4 inclusive)
#FEFE SHIFT, Z, X, C, V #EFFE 0, 9, 8, 7, 6
#FDFE A, S, D, F, G #DFFE P, O, I, U, Y
#FBFE Q, W, E, R, T #BFFE ENTER, L, K, J, H
#F7FE 1, 2, 3, 4, 5 #7FFE SPACE, SYM SHFT, M, N, B
A zero in one of the five lowest bits means that the corresponding key is pressed. If more than one address line is made low, the result is the logical AND of all single inputs, so a zero in a bit means that at least one of the appropriate keys is pressed. For example, only if each of the five lowest bits of the result from reading from port 00FE (for instance by XOR A/IN A,(FE)) is one, no key is pressed. A final remark about the keyboard. It is connected in a matrix-like fashion, with 8 rows of 5 columns, as is obvious from the above remarks. Any two keys pressed simultaneously can be uniquely decoded by reading from the IN ports. However, if more than two keys are pressed decoding may not be uniquely possible. For instance, if you press Caps , B and V, the Spectrum will think also the Space key is pressed, and react by giving the "Break into Program" report. Without this matrix behaviour Zynaps, for instance, won't pause when you press 5,6,7,8 and 0 simultaneously.
Bit 6 of IN-port FE is the ear input bit. The value read from this port is not trivial, as can be seen from the following program:
10 OUT 254,BIN 11101111
20 PRINT IN 254
30 OUT 254,BIN 11111111
40 PRINT IN 254
50 GOTO 10
For a correct test do not press any key while running, and have no EAR input.
Correctly responding emulators include R80, zx32 and xzx (All of these can do either Issue 2 or Issue 3 emulation). Also, ZXAM always behaves like an Issue 2 machine.
The ULA chip uses the same pin (28) for all of the MIC socket, EAR socket and the internal speaker, so bits 3 and 4 of an OUT to port #FE will affect bit 6 as read by an IN from port FE. The difference between Issue 2 and 3 machines is:
Value output to bit: 4 3 | Iss 2 Iss 3 Iss 2 V Iss 3 V
1 1 | 1 1 3.79 3.70
1 0 | 1 1 3.66 3.56
0 1 | 1 0 0.73 0.66
0 0 | 0 0 0.39 0.34
Iss 2 is value of bit 6 read by IN 254 after the appropriate OUT from an Issue 2, and Iss 3 is same for an Issue 3. Iss 2 V and Iss 3 V are voltage levels on pin 28 of the ULA chip after the OUT, with no input signal on the EAR socket.
From the above, it is clear that the difference between Issue 2 and 3 is:
Pera Putnik tested the level at pin 28 at which input bit 6 changes from 0 to 1 or reverse. This is exactly 0.70 Volts on both Issue 2 and Issue 3, with no inverting or hysteresis; this means that bit 6 is 1 if the voltage on pin 28 is over 0.70 V, and otherwise it is 0, on both Issues. At the hardware level, the only apparent difference between Issue 2 and 3 is that there are slightly higher voltages from Issue 2 machines. As can be seen from the table, the input combination '0 1' gives output voltages that are very close to the crucial 0.7 V.
The BASIC program used above is relatively slow, and for faster programs the situation isn't so simple, as there is some delay when output bit 4 changes from 1 to 0. To illustrate this, here are 2 short assembler routines:
ORG 45000
LD A,#18
OR #F8
OUT (254),A
LD A,#08
OR #E8
OUT (254),A
TIMING LD B,7 ;crucial value
DL LD IX,0
DJNZ DL
IN A,(254) ;query state
In this case IN A,(254), or output of this value sometimes gives 255 and sometimes 191. If you make the constant in the TIMING line smaller then result will be always 255, if delay is longer then result will be always 191. Of course, the effect occurs only for Issue 3 machines.
The situation is again slightly different for a longer duration of high output level on port 254:
ORG 50000
HALT ;synchronize with interrupts
LD A,#18
OUT (254),A
HALT ;wait 20ms
LD A,#08
OUT (254),A
LD B,107 ;crucial value
DL LD IX,0
DJNZ DL
IN A,(254)
As you can see, after a longer high level duration, the delay is also much longer. The delay varies from approximately 180 T states (about 50 microsec) to 2800 T states (about 800 microsec), depending from duration of high level on port 254. The explanation for this delay is that there are capacitors connected between pin 28 of the ULA and the EAR and MIC connectors, but note that there is no delay when bit 4 changes from 0 to 1.
The 'traditional' explanation of the difference between Issue 2 and 3 Spectrum (from techinfo.doc) is that PRINT IN 254 gives bit 6 reset on an Issue 3 and set on an Issue 2 machine occurs because, as PRINT IN 254 is typed at a BASIC prompt, the speaker is called for every keystroke, and the ROM beep routine contains a OR 8 before OUT (#FE),A, so bit 3 is always set, and therefore an Issue 2 machine will always return a set bit 6.
Bits 5 and 7 as read by INning from port #FE are always one. The ULA with the lower 16K of RAM, and the processor with the upper 32K RAM and 16K ROM are working independently of each other. The data and address buses of the Z80 and the ULA are connected by small resistors; normally, these do effectively decouple the buses. However, if the Z80 wants to read or write the lower 16K, the ULA halts the processor if it is busy reading, and after it's finished lets the processor access lower memory through the resistors. A very fast, cheap and neat design indeed!
If you read from a port that activates both the keyboard and a joystick port (e.g. Kempston), the joystick takes priority. Emulators known to have this feature correct are SpecEm, WSpecEm, x128 and xzx. This effect can be seen on Street Hawk and Command4.
| The 48K Spectrum |
|---|
If you run a program in the lower 16K of RAM, or read or write in that memory, the processor is halted sometimes, as the ULA needs to access the video memory to keep the TV updated; the electron beam can't be interrupted, so the ULA is given a higher priority to access the contended memory. This part of memory is therefore somewhat slower than the upper 32K block. This is also the reason that you cannot write a sound- or save-routine in lower memory; the timing won't be exact, and the music will sound harsh. Also, INning from port FE will halt the processor, because the ULA has to supply the result. Therefore, INning from port FE is a tiny bit slower on average than INning from other ports; whilst normally an IN A,(nn) instruction would take 11 T states, it takes slightly longer if nn=FE. See the Contended Memory section for more exact information.
If the processor reads from a non-existing IN port, for instance FF, the ULA won't stop, but nothing will put anything on the data bus. Therefore, you'll read a mixture of FFs (idle bus), and screen and ATTR data bytes (the latter being very scarce, by the way). This will only happen when the ULA is reading the screen memory, about 60% of the 1/50th second time slice in which a frame is generated. The other 40% the ULA is building the border or generating a vertical retrace. This behaviour is actually used in some programs, for instance, in Arkanoid.
Finally, there is an interesting bug in the ULA which also has to do with this split bus. After each instruction fetch cycle of the processor, the processor puts the I-R register "pair" (not the 8 bit internal Instruction Register, but the Interrupt and R registers) on the address bus. The lowest 7 bits, the R register, are used for memory refresh. However, the ULA gets confused if I is in the range 64-127, because it thinks the processor wants to read from lower 16K ram very, very often. The ULA can't cope with this read-frequency, and regularly misses a screen byte. Instead of the actual byte, the byte previously read is used to build up the video signal. The screen seems to be filled with 'snow'; however, the Spectrum won't crash, and program will continue to run normally. One program which uses this to generate a nice effect is Vectron (which has very nice music too, by the way).
The 50 Hz interrupt is synchronized with the video signal generation by the ULA; both the interrupt and the video signal are generated by it. Many programs use the interrupt to synchronize with the frame cycle. Some use it to generate fantastic effects, such as full-screen characters, full-screen horizon (Aquaplane) or pixel colour (Uridium for instance). Very many modern programs use the fact that the screen is "written" (or "fired") to the CRT in a finite time to do as much time-consuming screen calculations as possible without causing character flickering: although the ULA has started displaying the screen for this frame already, the electron beam will for a moment not "pass" this or that part of the screen so it's safe to change something there. So the exact time in the 1/50 second time-slice at which the screen is updated is very important. Each line takes exactly 224 T states.
After an interrupt occurs, 64 line times (14336 T states) pass before the byte 16384 is displayed. At least the last 48 of these are actual border-lines; the others may be either border or vertical retrace.
Then the 192 screen+border lines are displayed, followed by 56 border lines again. Note that this means that a frame is (64+192+56)*224=69888 T states long, which means that the '50 Hz' interrupt is actually a 3.5MHz/69888=50.08 Hz interrupt. This fact can be seen by taking a clock program, and running it for an hour, after which it will be the expected 6 seconds fast. However, on a real Spectrum, the frequency of the interrupt varies slightly as the Spectrum gets hot; the reason for this is unknown, but placing a cooler onto the ULA has been observed to remove this effect.
Now for the timings of each line itself: define a screen line to start with 256 screen pixels, then border, then horizontal retrace, and then border again. All this takes 224 T states. Every half T state a pixel is written to the CRT, so if the ULA is reading bytes it does so each 4 T states (and then it reads two: a screen and an ATTR byte). The border is 48 pixels wide at each side. A video screen line is therefore timed as follows: 128 T states of screen, 24 T states of right border, 48 T states of horizontal retrace and 24 T states of left border.
Now when to OUT to the border to change it at the place you want? First of all, you cannot change the border within a "byte", an 8-pixel chunk. If we forget about the screen for a moment, if you OUT to port FE after 14336 to 14339 T states (including the OUT) from the start of the IM 2 interrupt routine, the border will change at exactly the position of byte 16384 of the screen. The other positions can be computed by remembering that 8 pixels take 4 T states, and a line takes 224 T states. However, there are complications due to the fact that port FE is contended (as the ULA must supply the result); see the Contended Memory section for details.
| Contended Memory |
|---|
When the ULA is drawing the screen, it needs to access video memory; the RAM cannot be read by two devices (the ULA and the processor) at once, and the ULA is given higher priority (as the electron beam cannot be interrupted), so programs which run in the contended memory (from #4000 to #7FFF) or try to read from port #FE (when the ULA must supply the result) will be slowed if the ULA is reading the screen. Note this effect occurs only when the actual screen is being drawn; when the border is being drawn, the ULA supplies the result and no delays occur. The precise details are as follows:
Cycle # Delay
------- -----
14335 6 (until 14341)
14336 5 ( " " )
14337 4 ( " " )
14338 3 ( " " )
14339 2 ( " " )
14340 1 ( " " )
14341 No delay
14342 No delay
14343 6 (until 14349)
14344 5 ( " " )
14345 4 ( " " )
14346 3 ( " " )
14347 2 ( " " )
14348 1 ( " " )
14349 No delay
14350 No delay
etc., until the cycle #14463 (always relative to the start of the interrupt), in which the electron beam reaches the border again for 96 more cycles. And at cycle #14559 the same situation repeats. This is valid for all 192 lines of screen data. While the ULA is updating the border the delay does not happen at any time.
When counting cycles several things must be taken into account. One is the interrupt setup time; another one is the precise moment within an instruction in which the R/W or I/O operation is performed (see the table below). And one more thing: the fact that an interrupt can't happen in the middle of a instruction (and a HALT counts as many NOPs), so some cycles may be lost while waiting for the current instruction to end. That's an additional difficulty e.g. for byte-precision colour changes.
Now all that remains is to know exactly in which point(s) within an instruction is the R/W or I/O operation acting, to know where to apply the delay. That depends on each instruction. For those one-byte ops which do not perform memory or I/O access, the only affected point is the opcode fetch which happens at the first cycle of the instruction, and the address to test for contention is the current value of the program counter PC.
For example, for a NOP (4 cycles), only the first cycle will be affected and only if PC lies within the contended memory range. So if it's executed in contended memory at cycle #14334, no delay will happen and the next instruction will (try to) be executed at cycle #14338, but if the NOP is executed at cycle #14335, it will be delayed for 6 cycles thus taking 6+4=10 cycles so the next instruction will (try to) be executed at cycle #14345. This case will be annotated in the table below as pc:4, meaning that if PC lies within contended memory then the first cycle will be subject to delay and the remaining three will be free of delays.
The "try to" in the above paragraph is because, unless the NOP is at PC=32767, the next instruction will be subject to another delay when its opcode is fetched (the first cycle in an opcode fetch is always subject to delays) since the cycle number relative to the start of the frame is also delayed.
So an entry like 'hl+1:3' means that if HL+1 is in range 16384-32767 and the current cycle number is subject to delays, then the delay corresponding to the current cycle must be inserted before the number of T-states that figure after the colon.
Things get a bit more difficult with more-than-one-byte-long instructions. Here's the sample pseudocode to apply delays to an instruction with an entry in the table which reads 'pc:4,hl:3' (e.g. LD (HL),A):
If 16384<=PC<=32767 then
<Insert the delay corresponding to the current cycle,
relative to the start of the frame> (according to the above
table).
(end if)
Delay for 4 cycles (time after 'pc:').
If 16384<=HL<=32767 then
<Insert the delay corresponding to the current cycle...>
(end if)
Store A into (HL)
Delay for 3 cycles (time taken to store A)
Example 1: if PC = 25000 and HL = 26000 and the instruction at address 25000 is LD (HL),A and we're in cycle #14335:
Next opcode will be read at cycle #14352 (and 5 cycles will be inserted then for sure because PC=25001).
Example 2: same but PC=40000 (not contended):
If an entry in the table has something like 'io:5', it means that if the I/O port is even (bit 0 = 0, like port FEh) then it counts exactly like an address lying in contended memory.
The values for the registers listed in the table below are relative to the starting value of the register when the instruction is about to be executed.
In the table below:
For conditional instructions, entries in mean that they have only to be applied if the condition is met. If the instruction is not conditional (e.g. CALL nn) the entries in should be ignored.
The CB/ED/DD/FD prefixes count always as pc:4. It will not be counted in each instruction. Also, in places where HL appears we assume that it may be replaced by IX or IY (same for H and L alone) when valid. Timings for instructions with an operand of the form (IX/IY+n) have not been thoroughly tested.
In some read-modify-write operations (like INC (HL)), the write operation is always the last one. That may be important to know the exact point in which video is updated, for example. In such instructions that point is annotated for clarity as "(write)" after the address.
Instruction Breakdown
----------- ---------
NOP; pc:4
CB prefix;
ED prefix;
DD prefix;
FD prefix;
LD r,r';
alo A,r;
sro r;
BIT b,r;
SET b,r;
RES b,r;
INC/DEC r;
EXX;
EX AF,AF';
EX DE,HL;
DAA;
CPL;
NEG;
IM 0/1/2;
CCF;
SCF;
DI;
EI;
RLA;
RRA;
RLCA;
RRCA;
JP (HL)
LD A,I; pc:5
LD A,R;
LD I,A;
LD R,A
INC/DEC dd; pc:6
LD SP,HL
ADD HL,dd; pc:11
ADC HL,dd;
SBC HL,dd
LD r,n; pc:4,pc+1:3
alo A,n
LD r,(ss); pc:4,ss:3
LD (ss),r
alo A,(HL) pc:4,hl:3
BIT b,(HL) pc:4,hl:4
LD dd,nn; pc:4,pc+1:3,pc+2:3
JP nn;
JP cc,nn
LD (HL),n pc:4,pc+1:3,hl:3
LD A,(nn); pc:4,pc+1:3,pc+2:3,nn:3
LD (nn),A
LD dd,(nn); pc:4,pc+1:3,pc+2:3,nn:3,nn+1:3
LD (nn),dd
INC/DEC (HL); pc:4,hl:4,hl(write):3
SET b,(HL);
RES b,(HL);
sro (HL)
POP dd; pc:4,sp:3,sp+1:3
RET;
RETI;
RETN
RET cc pc:5,sp:3,sp+1:3
PUSH dd; pc:5,sp-1:3,sp-2:3
RST n
CALL nn; pc:4,pc+1:3,pc+2:3,pc+2:1,
CALL cc,nn sp-1:3,sp-2:3
JR n; pc:4,pc+1:3,pc+1:1,pc+1:1,pc+1:1,
JR cc,n pc+1:1,pc+1:1
DJNZ n pc:5,pc+1:3,pc+1:1,pc+1:1,pc+1:1,
pc+1:1,pc+1:1
RLD; pc:4,hl:7,hl(write):3
RRD
IN A,(n); pc:4,pc+1:4,io:3
OUT (n),A
IN r,(C); pc:5,io:3
OUT (C),r
EX (SP),HL pc:4,sp:3,sp+1:4,sp(write):3,sp+1(write):5
LDI/LDIR; pc:4,hl:3,de:3,de:1,de:1,de:1,de:1,de:1,
LDD/LDDR de:1,de:1
CPI/CPIR; pc:4,hl:3,hl:1,hl:1,hl:1,hl:1,hl:1,hl:1,
CPD/CPDR hl:1,hl:1,hl:1,hl:1
INI/INIR; pc:6,io:3,hl:3,hl:1,hl:1,hl:1,hl:1,hl:1
IND/INDR
Note: The next instruction is not very clear because of its
complexity - help on confirmation would be appreciated:
OUTI/OTIR; if last time or non-repeated version:
OUTD/OTDR pc:5,hl:4,io:3
if not last time (for repeated versions):
pc:5,hl:4,io:1,pc+1:1,pc+1:1,pc+1:1,pc+1:1,
pc+1:1,pc+1:1,pc:1
If anyone out there can further this information (especially about the effect of (IX+n) and (IY+n)), please contact Pedro Gimeno.
| INTERFACE 1 |
|---|
The Interface I is quite complicated. It uses three different I/O ports, and contains logic to page and unpage an 8K ROM if new commands are used. The ROM is paged if the processor executes the instruction at ROM address 0008 or 1708 hexadecimal, the error and close# routines. It is inactivated when the Z80 executes the RET at address 0700.
| Port E7 |
|---|
I/O port E7 is used to send or receive data to and from the microdrive. Accessing this port will halt the Z80 until the Interface I has collected 8 bits from the microdrive head; therefore, it the microdrive motor isn't running, or there is no formatted cartridge in the microdrive, the Spectrum hangs. This is the famous 'IN 0 crash'.
| Port EF |
|---|
Bit 7 6 5 4 3 2 1 0
+---------------------------------------+
READ| | | |busy| dtr |gap| sync|write|
| | | | | | | |prot.|
|---+---+----+----+-----+---+-----+-----|
WRITE| | |wait| cts|erase|r/w|comms|comms|
| | | | | | | clk | data|
+---------------------------------------+
Bits DTR and CTS are used by the RS232 interface. The WAIT bit is used by the Network to synchronise, GAP, SYNC, WR_PROT, ERASE, R/_W, COMMS CLK and COMMS DATA are used by the microdrive system.
| Port F7 |
|---|
If the microdrive is not being used, the COMMS DATA output selects the function of bit 0 of out-port F7:
Bit 7 6 5 4 3 2 1 0
+------------------------------------------+
READ|txdata| | | | | | | net |
| | | | | | | | input |
|------+---+---+---+---+---+---+-----------|
WRITE| | | | | | | |net output/|
| | | | | | | | rxdata |
+------------------------------------------+
TXDATA and RXDATA are the input and output of the RS232 port. COMMS DATA determines whether bit 0 of F7 is output for the RS232 or the network.
| JOYSTICKS |
|---|
The ports assigned to joysticks are:
#7F Fuller Box (FxxxRLDU, active low) #1F Kempston (000FUDLR, active high) #EFFE Sinclair1 (000LRDUF, active low, corresponds to keys '6' to '0') #F7FE Sinclair2 (000FUDRL, active low, corresponds to keys '1' to '5')
The TS2068 is slightly more complicated, as the joysticks attached to R14 of sound chip; the following code is typical for reading the joysticks:
LD A,7 OUT (#F5),A ;set R7 IN A,(#F6) AND #BF ;clear bit 6 to read from i/o port a - R14 OUT (#F6),A LD A,14 OUT (#F5),A ;set R14 LD A,3 ;(3=both joysticks, 2=left only, 1=right only) IN A,(#F6) ;(FxxxRLDU, active low)
This method ensures other sound chip functions aren't messed with.
[Z80 Tech Info] [48K Tech Info] [128K Tech Info] [Peripheral Ports]
This FAQ is maintained by Philip Kendall;
distribution is permitted only under the conditions specified in the
copyright notice.
Primary site
for this FAQ: http://www.ast.cam.ac.uk/~pak/cssfaq/index.html.