8
THE OPERATING SYSTEM
With every ATARI Home Computer System comes an ATARI 10K Operating System Cartridge. The importance of this cartridge is often overlooked. Without it, you have a lot of potential, but absolutely nothing else! This situation is not unique to the ATARI Home Computer System; It is encountered with all computers. A computer is, after all, merely a collection of hardware devices. A user must manage these resources to accomplish any task. If all programmers had to start from scratch on each program, we would have an even larger software shortage than we have today. The solution that has evolved over the years is to build in a program that manages the resources available to the system, and eases the programming burden required to control them. This program is known by various names: Operating System, Master Control Program, System Executive, System Monitor, etc. In the ATARI Home Computer System it is known as the Operating System or OS.
The first task facing the student of the Operating System, is to take an inventory of exactly what resources are available to the OS. These are:
-
6502 Microprocessor
RAM Memory (various amounts)
ANTIC LSI Integrated Circuit
CTIA LSI Integrated Circuit
POKEY LSI Integrated Circuit
PIA Peripheral Interface Adapter Integrated Circuit
By using these resources, the OS can interact with and control a wide variety of external hardware devices, including a television receiver/ monitor, keyboard, console speaker, console switches, joysticks, paddles, cassette recorder, disk drive, printers, RS-232 interface and modem.
The remainder of this subsection briefly lists the main elements of the OS. These elements are described in detail in following subsections.
MONITOR. The OS monitor is the system routine that is executed when the computer is turned on or the SYSTEM RESET] button is pressed. Through this routine the OS takes control of the system; It does not relinquish control unless control is taken away from it by the programmer. The Monitor sets up the memory management system, initializes the I/O subsystem, sets up system vectors and selects the execution environment after initialization is complete.
INTERRUPT PROCESSING STRUCTURE. The computer utilizes the standard interrupt processing structure of the 6502 microprocessor, with some external augmentation for enhanced flexibility. Interrupts are generated by numerous events, including keyboard keystrokes, the **BREAK** keystroke, some serial bus events, system timer timeouts, and the vertical blank interval on the television.
OS SYSTEM VECTORS. The system vectors provide a mechanism that allows users to access system routines, or customize the OS for special needs. The most frequent uses of the vectors are to call I/O system routines, set timers, and transfer control to different execution environments. System routines may be vectored to in one of two ways. ROM vectors are locations that contain JMP instructions to system routines and cannot be altered. RAM vectors are RAM locations that contain alterable addresses of system routines. The locations of both types of vectors are guaranteed to remain the same in future releases of the OS.
INPUT/OUTPUT SUBSYSTEM. The OS gives an application programmer access to the full capabilities of the computer's peripherals. The Input/Output subsystem is a set of routines that link high level I/O operations with device handlers that control the physical I/O hardware.
REAL TIME PROGRAMMING. The ATARI Home Computer is well equipped to deal with problems in the "real time domain". To facilitate this feature, the OS has two types of timers: hardware timers and system software timers. Hardware timers are countdown timers that can be used to time events with durations that range from half a microsecond to several seconds. System timers are software timers that tick at 60 Hertz, and can be used for applications as diverse as serial bus timing and sound effect generation.
ROM CHARACTER SET. The computer is equipped with what is known as a "soft character set", i.e., It can be changed. The ROM-based character set is used to provide a standard character set at power-up.
FLOATING POINT PACKAGE. The floating point package is a set of mathematical routines that extend the arithmetic capability of the system. The routines use binary coded decimal (BCD) arithmetic to provide standard mathematical functions (+, -, *, /), exponential and logarithmic functions as well as conversion from ATASCII to BCD and BCD to ATASCII.
The OS monitor is that portion of the OS ROM that handles both the power-up and SYSTEM RESET sequences. These sequences allow the OS to gain Initial control of the computer and ensure that everything is properly initialized before releasing partial control to an application program. Both sequences are similar in function and in fact share much of the same code.
The power-up routine (also known as Coldstart) is invoked either by turning on the computer or by jumping to COLDSV ($E477), a system routine vector. Important items to remember about the power-up sequence are:
- ALL of RAM memory is cleared except locations $0000-$000F.
- Both a cassette and disk boot are attempted. BOOT? ($0009) is a flag that indicates the success or failure of the boots. Bit 0 = 1 for a successful cassette boot; Bit 1 = 1 for a successful disk boot.
- COLDST ($0244) is a flag that tells the Monitor that it is in the middle of power-up. COLDST=0 means the [SYSTEM RESET] key has been pressed, whereas COLDST<>O indicates initial power-up. The COLDST flag can be used to gain a certain amount of program security. If COLDST is set to a non-zero value during program execution, then pressing [SYSTEM RESET] will initiate the power-up sequence. This will prevent the user from gaining control of the computer while the program is running.
Pressing the [SYSTEM RESET] key causes a SYSTEM RESET (also known as Warmstart). Some of the key facts to remember about the SYSTEM RESET sequence are:
- The OS RAM vectors are downloaded from ROM during both SYSTEM RESET and power-up sequences. If you wish to "steal" a vector, some provision must be made to handle SYSTEM RESET. See the MEMORY MANAGEMENT subsection of this section for suggestions on how this is done.
- MEMLO, MEMTOP, APPMHI, RAMSIZ and RAMTOP are reset during System Reset. If you wish to alter these RAM pointers to reserve some space for assembler modules called by BASIC, you must make some provision for handling SYSTEM RESET. Figure 8-3 provides an example of how to do this.
The next few pages present a detailed flowchart for the power-up and SYSTEM RESET sequences.
Figure 8-1.1 System Initialization
Figure 8-1.2 System Initialization
Figure 8-1.3 System Initialization
Figure 8-1.4 System Initialization
The fact that the OS is written for a 6502 microprocessor dictates a number of overall memory management decisions. In the 6502, there are three special regions in the memory address space. Page zero has crucial significance in that the use of data values on this page will result in tighter, faster executing code. Indeed, there are instructions that absolutely require page zero locations to work. Page one is special because it is used for the 6502 stack. Addresses $FFFA - $FFFF are also special because they are reserved for hardware reset and interrupt vectors.
Thus, the first task of memory management is to assign the OS ROM to the highest part of memory address space. The OS resides in the address space from $D800 to $FFFF. Just under this area is the space reserved for the hardware registers in ANTIC, CTIA, and POKEY. These reside in the $D000-$DFFF range.
At the other end of memory address space, the OS reserves half of page zero for its own use. Pages two, three, four and five are also reserved for OS usage. From a programming viewpoint, the usable memory area runs from $0600 to $BFFF.
When the system is powered-up, one of the first actions taken by the OS is to determine how much RAM memory is present. This is accomplished by checking the first byte of each 4K block of memory starting at $1000. The contents of this byte are read, complemented and an attempt is made to store the complemented value back out. If this attempt is successful, the temporary memory size counter is incremented by 4K. This process continues until a location is found that cannot be changed. Two variables, RAMTOP and RAMSIZ contain the number of RAM pages present. In addition to these locations, pointers MEMLO, MEMTOP, and APPMHI are maintained by the OS memory management routines. The relationships between these pointers are shown in Figure 8-2, a simple memory map.
MEMLO is a 2-byte location that the OS uses to indicate where an application program may begin. You can modify MEMLO to create reserved areas for assembly language routines that may be called from BASIC. BASIC uses the value In MEMLO to determine the starting location of a program (see Section 10 for a discussion of the structure of a BASIC program). If the value of MEMLO is changed to a higher address, it must be done before control is transferred to the BASIC cartridge. This is a tricky operation, because MEMLO is reset by both power-up and SYSTEM RESET.
If an application program is running in a disk drive environment, the AUTORUN.SYS facility can be used to change MEMLO to reserve space. However, DOS is also initialized during SYSTEM RESET via the DOSINI vector ($000C). This vector contains the address of the DOS initialization code called as part of the monitor system initialization. DOSINI is also the only point at which you can "trap" the SYSTEM RESET sequence. Since the DOS initialization must occur regardless of what is done to the MEMLO pointer, you must allow the normal initialization to occur before "stealing" the DOSINI vector. This may be done by moving the contents of DOSINI into the 2-byte address of a JSR information on the AUTORUN.SYS feature). Just after the JSR instruction, place the code which sets MEMLO to a new value. Follow this with a RTS instruction. DOSINI must then be reset to the address of the JSR instruction. When a SYSTEM RESET occurs, the new code sequence is called and the first instruction, JSR OLDDOSINI, initializes DOS. The remaining code is then executed which sets MEMLO to its new value and then rejoins the rest of the initialization sequence. Figure 8-3 presents an example showing how to do this.
The above technique can also be used with MEMTOP, the user high memory pointer. This pointer indicates the highest RAM address accessible to an application program. This RAM address differs from the highest physical RAM address because the OS allocates some RAM at the very top of RAM for its display list and display data. Space for assembly language modules and data can be set aside by lowering MEMTOP from the values set by power-up and SYSTEM RESET. Using MEMTOP instead of MEMLO to reserve space does create one problem. The value of MEMTOP depends on both the amount of RAM in the system and the graphics mode of the display. This makes it difficult to predict its value before actually examining the location unless you make assumptions about the system configuration. This uncertainty over the final location of the machine code forces the programmer to use only relocatable code.
APPMHI is a location that contains an address specifying the lowest address to which the display RAM may extend. Correctly setting APPMHI ensures that the display handler will not clobber some of your program code or data.
RAMSIZ, like MEMTOP, can also be used to reserve space for user routines or data. Since RAMSIZ is a single byte value that contains the number of RAM pages present (i.e., groups of 256 bytes), lowering its value by 1 will reserve 256 locations. The advantage of using RAMSIZ instead of MEMTOP is that the space saved by moving RAMSIZ down is above the display memory, whereas space saved by moving MEMTOP down remains below the display memory.
Figure 8-2 OS and BASIC Pointers (DOS present)
0010
; RESET THE MEMLO
POINTER
0020
;
0600 0030
START = $600
000C 0040
DOSINI
= $0C
02E7 0050
MEMLO = $2E7
3000 0060
NEWMEM = $3000 ;
THIS IS THE NEW VALUE FOR
MEMLO
0065
;
0070
; THIS ROUTINE RESERVES SPACE FOR ASSEMBLY
ROUTINES
0090
; BY RESETING THE MEMLO POINTER. IT RUNS
AS
0100
; AN AUTORUN.SYS FILE. IT ALSO RESETS MEMLO ON
[RESET].
0120
; MEMLO IS SET TO THE VALUE OF
NEWMEM.
0130
;
0140
; THIS PART IS PERMANENT, IE. NEEDS TO BE
RESIDENT.
0150
; THE SYSTEM DOSINI VECTOR HAS BEEN
STOLEN
0160
; AND STORED IN THE ADDRESS PORTION OF THE JSR
TROJAN
0170
; INSTRUCTION. SO WHEN [RESET] IS PRESSED, DOSINI
VECTORS
0180
; TO INITDOS, JSR TROJAN THEN CALLS THE DOS
INITIALIZATION
0185
; ROUTINES, MEMLO IS RESET TO NEW VALUE
AND CONTROL
0190
; RETURNS TO THE
MONITOR.
0000 0200 *=
START
0210
INITDOS
0600 200D06
0220 JSR TROJAN
DO DOS INITIALIZATION
0603 A900
0230 LDA #NEWMEM&255
0605
8DE702
0240 STA MEMLO
0608
A930
0250 LDA #NEWMEM/256
060A
8DE802
0260 STA MEMLO+L
0270
TROJAN
060D 60
0280 RTS
0290
; THIS PART IS EXECUTED AT POWER UP ONLY
AND
0300
; CAN BE DELETED AFTER
POWER-UP.
0330
; THIS ROUTINE STORES THE CONTENTS OF DOSINI INTO THE
JSR
0350
; TROJAN INSTRUCTION. IT THEN REPLACES DOSINI
WITH
0370
; A NEW VALUE, LOCATION
INITDOS.
0390
GRABDOSI
060E A50C
0400 LDA DOSINI ;
SAVE DOSINI
0610 8DO106
0410 STA INITDOS+1
0613
A50D
0420 LDA DOSINI+1
0615
8D0206
0430 STA INITDOS+2
0618
A900
0440 LDA #INITDOS&255 ;
SET DOSINI
061A 850C
0450 STA DOSINI
061C
A906
0460 LDA #INITDOS/256
061E
850D
0470 STA DOSINI+1
0620
A500
0480 LDA NEWMEM&255 ;
SET MEMLO
0622 8DE702
0490 STA MEMLO
0625
A930
0500 LDA #NEWMEM/256
0627
8DES02
0510 STA MEMLO+1
062A
60
0520 RTS
062B 0530 *=
$2E2
02E2 0E06
0540 .WORD
GRABDOSI ; SET RUN
ADDRESS
02E4 0550 .END
Figure 8-3 Reset MEMLO
Download / View CH8PRG1.SRC (Listed ASSEMBLY)
INTERRUPT PROCESSING STRUCTURE
The capability to selectively respond to special hardware and software events (i.e. interrupts), provides enormous flexibility to any computer system. As in any 6502-based system, there are two types of interrupt requests at the processor level, maskable (IRQ) and nonmaskable (NMI) interrupts. A higher level of interrupt control is provided by ANTIC, POKEY and the PIA chip. Each of these chips is responsible for mediating a number of events which could cause interrupts. If a particular interrupt is enabled at the level of the three guardian chips, then they allow the interrupt request to pass on to the 6502. ANTIC handles NMI requests, and POKEY and the PIA handle IRQ requests.
The following interrupt functions are available:
| Name (vector) | Type | Function | Used By |
|---|---|---|---|
| DISPLAY LIST (VDSLST) SYSTEM RESET (none) VERTICAL BLANK (VVBLKI,VVBLKD) SERIAL INPUT READY (VSERIN) SERIAL OUTPUT READY (VSEROR) SERIAL OUTPUT COMPLETE (VSEROC) POKEY TIMER 1 (VTIMR1) POKEY TIMER 2 (VTIMR2) *POKEY TIMER 4 (VTIMR4) KEYBOARD (VKEYBD) *BREAK KEY (BRKKY) SERIAL BUS PROCEED (VPRCED) SERIAL BUS INTERRUPT (VINTER) |
NMI NMI NMI IRQ IRQ IRQ IRQ IRQ IRQ IRQ IRQ IRQ IRQ |
Graphics timing System init. Graphics display Serial input Serial output Serial output Hardware timer Hardware timer Hardware timer Key pressed [BREAK] key Device proceed Device interrupt |
User OS OS,user OS OS OS User User User OS OS Unused Unused |
* This IRQ is vectored only in the Rev. B version of the OS
Section 6 of the OPERATING SYSTEM Manual contains more detailed information on interrupts. Extreme care needs to be taken in working with interrupts. For example, if you accidentally disable the keyboard IRQ interrupt, the computer will ignore all the keys except the [BREAK] key. Although this may be useful sometimes, it may make debugging your program a bit difficult!
The IRQ Interrupt Handler
The OS has an IRQ interrupt handler that processes the various IRQs. This handler has RAM vectors for all of the IRQs. (Note - the [BREAK] key IRQ is not vectored in the original version of the OS The IRQ vectors are set to their initial values during both power-up and SYSTEM RESET. The locations of the IRQ RAM vectors are described in the subsection on System Vectors.
IRQ vector functions are:
- VIMIRQ - Immediate IRQ vector. All IRQs vector through this
location. VIMIRQ normally points to the system IRQ handier. You can steal
this vector to do your own IRQ Interrupt processing.
VSEROR - Pokey Serial Output Needed IRQ vector. This normally points to the code to provide the next byte in a buffer to the serial output port.
VSERIN - Pokey Serial Input Ready IRQ vector. This points to the code to place a byte from the serial input port into a buffer.
VSEROC - Pokey Serial Output Complete IRQ vector. Normally this vector points to code that sets a transmit done flag after the checksum byte goes out.
VTIMR1 - Pokey Timer 1 IRQ vector. Initialized to point to a PLA,RTI instruction sequence.
VTIMR2 - Pokey Timer 2 IRQ vector. Initialized to point to a PLA,RTI instruction sequence.
VTIMR4 - Pokey Timer 4 IRQ vector. Initialized to point to a PLA,RTI instruction sequence.
VKEYBD - Keyboard IRQ vector. Pressing any key except [BREAK] causes this IRQ. VKEYBD can be used to preprocess the key code before it is converted to ATASCII by the OS. VKEYBD normally points to the OS keyboard IRQ routine.
BRKKY - [BREAK] key vector. In the Rev. B version of the OS, this IRQ has its own vector. It is initialized to a PLA,RTI instruction sequence.
VPRCED - Peripheral Proceed IRQ vector. The proceed line is available to peripherals on the serial bus. This IRQ is unused at present and normally points to a PLA,RTI instruction sequence.
VINTER - Peripheral interrupt IRQ vector. The interrupt line is also available on the serial bus. VINTER normally points to a PLA,RTI instruction sequence.
VBREAK - 6502 BRK instruction IRQ vector. Whenever a software break instruction is executed, this interrupt occurs. VBREAK can be used to set break points for a debugger, though it normally points to a PLA,RTI instruction sequence.
The IRQs are enabled and disabled as a group by the 6502 instructions CLI and SEI respectively. The IRQs also have individual enable/disable bits in POKEY. The programmer's reference card provided with this book shows the IRQs and their enable/disable bits.
The IRQEN register contains most of the IRQ enable/disable bits and is a write-only register. The OS keeps a shadow copy of IRQEN in POKMSK ($0010), but IRQEN is not updated from POKMSK during vertical blank. Each interrupt is enabled by setting the proper bit in IRQEN to a one. A zero is placed in a bit in IRQEN to clear interrupt status from that corresponding bit in IRQST. You might note that bit 3 in IRQST (Serial data transmission is finished) is not cleared by this process. This bit is simply a status bit and reflects the current status of the serial transmission register.
PACTL and PBCTL are used to enable and test the status of the IRQs handled by the PIA. Bit 0 of each of these registers is the interrupt enable for that port. Bit 7 represents the interrupt status. This bit is cleared whenever the PACTL or PBCTL registers are read.
Using The IRQs
The availability of the IRQ vectors means that you can tailor much of the system I/O to your liking. Currently, the OS does not provide for overlapping I/O with other processing. By redirecting the three serial I/ O interrupt vectors however, it is possible to rewrite portions of the I/O subsystem to allow for true concurrent processing.
The three timer interrupts can be put to use in any operation requiring precise timing control. These timers would normally be used when the 60-Hertz software timers are too slow. Refer to the subsection on Real Time Programming for more information on this topic.
Many applications require that programs be protected from user input error. A couple of the IRQ vectors can be used to provide extended input protection. The example in Figure 8-4 uses the VKEYBD IRQ vector to disable the control key. The routine also masks the [BREAK] key by stealing the VIMIRQ vector and ignoring the [BREAK] key interrupt. Though written for the original version of the OS, this routine will still work in Rev. B.
Two of the IRQs are handled by the PIA, VPRCED and VINTER. These are unused by the OS, and may be utilized to provide more control over external devices.
0010 10
POKMSK
= $0010
D209 20
KBCODE
= $D209
0208 30
VKEYBD
= $0208
D20E 40
IRQEN = $D20E
D20E 45
IRQST = IRQEN
0216 46
VMIRQ = $0216
0000 60 *=
$600
0600 78 80
START SEI
DISABLE IRQS
0601 AD1602
90 LDA
VMIRQ REPLACE THE IRQ VECTOR
0604
8D4D06
0100 STA
NBRK+1 WITH OUR OWN
0607 AD1702
0110 LDA
VMIRQ+1 ALL IRQS WILL
060A 8D4E06
0120 STA
NBRK+2 GO TO NBRK
060D
A945
0130 LDA
#IRQ&255
060F 8Dl602
0140 STA
VMIRQ
0612 A906
0150 LDA
#IRQ/256
0614 8Dl702
0160 STA
VMIRQ+1
0617 AD0802
0200 LDA
VKEYBD POINT KEY IRQ TO
061B 8D4306
0210 STA
JUMP+1 REP
061E AD0902
0220 LDA
VKEYBD+1
0621 8D4406
0230 STA
JUMP+2
0624 A939
0240 LDA
#REP&255 VECTOR KEY IRQ
0626 8D0802
0250 STA
VKEYBD LOW BYTE OF VECTOR
0629
A906
0260 LDA
#REP/256
062B 8D0902
0270 STA
VKEYBD+1
062E 58
0170 CLI
ENABLE IRQS
062F 60
0280 RTS
0290 *=$639
0639
AD09D2 0300
REP LDA
KBCODE ALL KEY IRQS COME HERE
063C 2980
0310 AND
#$80 CHECK IF CONTROL
HIT
063E F002
0320 BEQ
JUMP IF NOT HIT THEN
GO
0640 68
0330 PLA
ELSE IGNORE CONTROL KEY
0641 40
0340 RTI
0642 4C4206 0360
JUMP
JMP
JUMP THIS CALLS THE OLD KEY IRQ
0645 48 0375
IRQ PHA
ALL IRQS COME HERE
0646 AD0ED2
0380 LDA
IRQST CHECK IF [BREAK]
0649
1004
0390 BPL
BREAK IF [BREAK] IRQ,BRANCH
064B
68
0405 PLA
ELSE CALL OLD IRQ VECTOR
064C 4C4C06 0410 NBRK
JMP
NBRK CALL OLD IRQ
VECTOR
064F A97F 0430
BREAK LDA
#$7F HERE IF [BREAK]
0651
8D0ED2
0440 STA
IRQST SHOW NO [BREAK]
0654
A510
0450 LDA
POKMSK
0656 8D0ED2
0460 STA
IRQEN
0659 68
0462 PLA
065A
40
0464 RTI
RETURN AS IF NO
[BREAK]
065B 0470 *=
$02E2
02E2 0006
0480 .WORD START
Figure 8-4 Protecting Programs from User Input Error
Download / View CH8PRG2.SRC (Listed ASSEMBLY)
The NMI Handler
The OS has an NMI handler for handling the nonmaskable interrupts. Unlike the IRQs, the NMIs cannot be "masked" (disabled) at the 6502 level. All the NMIs except SYSTEM RESET can be disabled by ANTIC.
Two of the NMIs, the display list interrupt (DLI) and the vertical blank (VBLANK) interrupt, have RAM vectors that can be used. In fact, VBLANK can be intercepted in two places, immediate or deferred VBLANK. The NMI vectors are:
| Name | Vector |
|---|---|
| SYSTEM RESET DISPLAY LIST INTERRUPT VERTICAL BLANK IMMEDIATE DEFERRED |
none VDSLST ($0200) VVBLKI ($0222) VVBLKD ($0224) |
The SYSTEM RESET NMI doesn't have a RAM vector. SYSTEM RESET always results in a jump to the monitor warmstart routine. However.- the DOSINI RAM vector is used during the Warmstart process, and thus can be used to trap the [SYSTEM RESET] (see subsection on the Monitor).
The DLI vector is unused by the OS. Refer to Section 5, Display List Interrupts, for details on using this feature.
Vertical Blank Interrupt Processing
The vertical blank interrupt facility is an extremely valuable resource to a programmer. These interrupts are nonmaskable and occur at regular intervals based on the television signal standard (every 60th of a second for NTSC, every 50th for PAL). Just as importantly, these interrupts occur during that period of time when the screen has been blanked, so that changes made during this period will not be immediately seen on the display. This leads to a wide assortment of uses.
After a vertical blank interrupt has been recognized by the OS, the contents of the A, X, and Y registers are placed onto the stack. The system then vectors through the immediate vertical blank vector (VVBLKI) located at $0222. This vector normally points to the OS vertical blank interrupt service routine at $E45F. The OS uses this routine to increment the real time clock, to decrement the system timers, to do color attracting, to copy shadow registers,. and to update values from the input controllers. This routine terminates by jumping through the deferred vertical blank vector (VVBLKD) at $0224. This vector is initialized to point to a simple interrupt termination routine at $E462. Figure 8-5 illustrates this process.
Figure 8-5 Vertical Blank Interrupt Execution
These two vectors were put into RAM to allow programmers to trap the vertical blank service routine and use the 60-Hertz interrupt for their own purposes. The procedure to use them is straightforward. First decide whether the vertical blank interrupt (VBI) routine is to be an immediate VBI or a deferred VBI. In many cases it makes little difference which is chosen. There are some instances where it does matter. The first case arises when your VBI routine reads or writes to registers which are shadowed by the OS VBI routine. It might be necessary to write to the hardware registers after the OS VBI has written to them. He who writes last, writes best!
The second case arises when your VBI routine consumes too much processor time. The OS VBI routine may then be delayed beyond the end of the vertical blank period. This in turn may cause some graphics registers to be changed while the beam is tracing on the screen. The result may be unsightly. if this is the case, your VBI routine should be placed as a deferred VBI routine. The time limit for immediate VBI is about 2000 machine cycles; for deferred VBI it is about 20,000 cycles. However, many of these 20,000 machine cycles are executed while the electron beam is being drawn, so graphics operations should not be executed in extremely long deferred VBI routines. Furthermore, display list interrupt execution time comes out of the time available for this processing. Remember, VBI processing will cut down on the time available for mainline code execution.
The third case arises when your own VBI must be mixed with time- critical I/O such as to the disk or cassette. The OS immediate VBI routine has two stages, a critical and a non-critical stage. During time critical I/O, the OS immediate VBI routine aborts after stage one processing is complete. if you want your VBI to be executed during every vertical blank period, it must be defined as an immediate VBI. Be wary in this situation, for this may result in interference problems with time-critical I/O.
Once you have decided whether your VBI routine should be immediate or deferred, you must place the routine in memory (page six is a good place), link it to the proper VBI routine, and modify the appropriate OS RAM vector to point to it. Terminate an immediate VBI routine with a JMP to $E45F. Terminate a deferred VBI routine with a JMP to $E462. If you want to bypass the OS VBI routine entirely (and thereby gain processing time), terminate your immediate VBI routine with a JMP to $E462.
A common problem with interrupts on 8-bit micros arises when you try to change the vector to the interrupt. Vectors are 2-byte quantities; it takes two store instructions to change them. There is a small chance that an interrupt will occur after the first byte has been changed but before the second byte has been updated. This could crash the system. The solution to this problem has been provided by an OS routine called SETVBV at $E45C. Load the 6502 Y- register with the low byte of the address, the X-register with the high byte of the address, and the accumulator with a 6 for immediate VBI or a 7 for deferred VBI. Then JSR SETVBV and the interrupt will be safely enabled. The new VBI routine will begin executing within one 60th of a second.
A wide variety of operations can be performed with 60-Hertz interrupts. First, screen manipulations can be done during the vertical blank to ensure that transitions do not occur on the screen. Second, high speed regular screen manipulations can be performed. This can be very important in rhythmic animations where changes need to occur at a pace independent from other processing.
Another function of vertical blank interrupts is for real-time sound effects. The sound registers in the ATARI 400/800 allow control of frequency, volume, and distortion, but not duration. Duration can be controlled with a VBI by having a calling routine set some duration parameter which the VBI then decrements down to zero. This technique can be used to control the volume of the sound and so give attack and decay envelopes to sounds. Finer control of frequency and distortion is possible with extensions of this technique. The result can be very intricate sound effects. Since the VBI time resolution is only 1/60th of a second, VBls are not useful for the volume only mode of the audio channels.
VBls are also useful for handling user inputs. Usually, these inputs require little processing, but constant attention. A VBI allows the program to check for user input every 60th of a second without burdening the' program. It is an ideal solution to the problem of maintaining computational continuity without ignoring the user.
Finally, VBls allow a crude form of multitasking to take place. A foreground program can run under the VBI while a background program runs in the mainline code. As with any interrupt, careful separation of the databases for the two programs must be maintained. The power derived from the vertical blank interrupt is, however, well worth the effort.
One measure of the power of any operating system is its adaptability. Just how easy is it for a user to take advantage of the OS routines or modify and customize system routines?
In this regard, the OS for the ATARI Home Computer System would score well. In practically every instance where access to system routines could be beneficial, the OS has "hooks" where you can attach or replace system routines with your own.
This flexibility is provided by a combination of several different mechanisms. The first of these is a ROM table of JMP instructions to crucial OS routines. In future versions of the OS, the location of this Jump table will not change, although the values there probably will. Thus, if your software accesses the main OS routines via this table, it will also work on future versions of the OS. If your software does not use these ROM vectors, but instead jumps directly into the OS ROM, then it will almost certainly crash on future versions of the OS.
The second mechanism is a series of address vectors in RAM which link many of the interrupt processing routines together. To alter the handling of a particular interrupt, one need change only a single vector to point to the replacement code. The OS initializes these vectors as part of the power-up sequence. Again, though the initialized contents of these vectors may change, their location is guaranteed not to.
The third mechanism is the device handler table where vectors to specific device handlers (e.g. disk drive, printer,...) are stored. For a discussion of this facility, refer to the Centralized Input/Output subsection of this section.
| Name | Location | Use |
|---|---|---|
| DISKIV DSKINV CIOV SIOV SETVBV SYSVBV XITVBV SIOINV SENDEV INTINV CIOINV BLKBDV WARMSV COLDSV RBLOKV CSOPIV |
$E450 $E453 $E456 $E459 $E45C $E45F $E462 $E465 $E468 $E46B $E46E $E471 $E474 $E477 $E47A $E47D |
Disk handler initialization Disk handler vector Central I/O routine vector Serial I/O routine vector Set system timers routine vector System vertical blank processing Exit vertical blank processing Serial I/O initialization Serial bus send enable routine Interrupt handler routine Central I/O initialization Blackboard mode (Memopad) vector Warm start entry point (SYSTEM RESET) Cold start entry point (power-up) Cassette read block routine vector Cassette open for input vector |
Figure 8-6 ROM Jump Vectors
Since this ROM table is actually a table of three byte JUMP instructions, an example of using a ROM vector is:
JSR CIOV RAM VECTORS
| Name | Location | Value | Use |
|---|---|---|---|
| -- Page Two Locations -- | |||
| VDSLST VPRCED VINTER VBREAK VKEYBD VSERIN VSEROR VSEROC VTIMR1 VTIMR2 VTIMR4 VIMIRQ VVBLKI VVBLKD CDTMA1 CDTMA2 BRKKY |
$0200 $0202 $0204 $0206 $0208 $020A $020C $020E $0210 $0212 $0214 $0216 $0222 $0224 $0226 $0228 $0236 |
$E7B3 $E7B3 $E7B3 $E7B3 $FFBE $EB11 $EA90 $EAD1 $E7B3 $E7B3 $E7B3 $E6F6 $E7D1 $E93E $xxxx $xxxx $E754 |
Display List Interrupt NMI Vector Proceed Line IRQ Vector -- Unused at present Interrupt Line IRQ Vector -- Unused at Present Software Break Instruction IRQ Vector Keyboard IRQ Vector Serial Input Ready IRQ Vector Serial Output Ready IRQ Vector Serial Output Complete IRQ Vector POKEY Timer 1 IRQ Vector POKEY Timer 2 IRQ Vector POKEY Timer 4 IRQ Vector Vector to IRQ Handier Immediate Vertical Blank NMI Vector Deferred Vertical Blank Vector System Timer 1 JSR Address System Timer 2 JSR Address BREAK key Vector (** only Rev. B **) |
| -- Page Zero Locations -- | |||
| CASINI DOSINI DOSVEC RUNVEC INIVEC |
$0002 $000C $000A $02E0 $02E2 |
$xxxx $xxxx $xxxx $xxxx $xxxx |
Vector for bootable cassette program initialization Disk Initialization Vector Disk Software Run Vector DUP File Load and GO Run Vector DUP File Load and Go Initialization Vector |
An x Indicates that the contents of this location may vary
Figure 8-7 RAM Vectors
Unlike the ROM Jump tables, these vectors are true two byte address vectors. A typical calling sequence to use one of the RAM vectors might look like this:
JSR CALL
CALL JMP (DOSINI)
THE CENTRALIZED INPUT/OUTPUT SUBSYSTEM
One of the most taxing problems facing an operating system designer is how to handle input/output to the wide variety of peripherals that might be hooked up to the system. A few general philosophical guidelines to efficient I/O handling are:
- The transfer of data should be device-Independent.
- The I/O structure should support single-byte, multiple-byte, and record-organized data transfers.
- Multiple devices/files should be concurrently accessible.
- Error handling should be device-transparent.
- The addition of new device handlers should be possible without having to change the OS ROM.
The ATARI 400/800 OPERATING SYSTEM (OS) was designed to provide exactly these capabilities. The ATARI 400/800 OS uses a table- driven centralized input/output subsystem. From the OS standpoint, I/O is organized around the IOCB, or Input/Output Control Block. An IOCB is a standard table that specifies one complete input or output operation. Any of eight standard I/O operations can be executed through an IOCB. By changing an entry in the IOCB, the user can change the nature of the input/output operation, even the physical device which is the target of the I/O. Thus, a user can easily perform I/O to completely different devices such as the disk drive and the printer without having to worry about hardware details. Most I/O requires only that the user set up an IOCB with control data, and then pass control to the I/O subsystem.
Two types of elements make up the I/O subsystem: I/O system routines and I/O system control blocks. The I/O system routines include the central I/O routine (CIO), the device handlers (E:, K:, S:, P:, C:, D:, R:) and the serial I/O routine (SIO). The Handler Address Table (HATABS) plays a major role in linking CIO with the individual device handlers. The system I/O control blocks contain control data that is routed to the I/O subsystem. The user interface is the same for all devices (e.g., the commands to output a line to the printer (P:) or to the display editor (E:) are very similar).
Understanding the structure of the I/O subsystem will enhance your use of it. Figure 8-8 shows the relationship of the I/O system routines and the I/O system control blocks.
Figure 8-8 I/O Subsystem
I/O System Control Blocks
There are four types of control blocks:
- -Input/Output Control Block (IOCB)
-Zero-Page I/O Control Block (ZIOCB)
-Device Control Block (DCB)
-Command Frame Buffer (CFB)
The I/O system control blocks are used to communicate information about the I/O function to be executed. The control blocks provide the I/ O system routines with control information to perform the I/O function. Refer to the OPERATING SYSTEM Manual for information as to the detailed structure of the four types of control blocks.
Eight IOCBs in the OS are used to effect communication between user programs and CIO. Figure 8-9 shows the content of an IOCB for some common I/O functions. The IOCBs are:
| Name | Location, Length |
|---|---|
| IOCB0 IOCB1 IOCB2 IOCB3 IOCB4 IOCB5 IOCB6 IOCB7 |
[$340,16] [$350,16] [$360,16] [$370,16] [$380,16] [$390,16] [$3A0,16] [$3B0,16] |
A second type of control block, the ZIOCB [$0020,16], is used to communicate I/O control data between CIO and the device handlers. When called, CIO uses the value contained in the X-register as an index to which of the IOCBs (one of eight) is to be used. CIO then moves the control data from the selected IOCB to the ZIOCB for use by the appropriate device handler. The ZIOCB is of little interest unless you are writing a new device handler or are replacing a current one.
Device handlers that require I/O over the serial bus will then load control information into the DCB [$0300,12]. SIO will use the DCB information and return the status information in the DCB for subsequent use by the device handler. Figure 8-10 illustrates some common I/O functions and the contents of their associated DCBs.
The resident disk handler does not conform to the regular user-CIO- handler-SIO calling sequence. Instead, you use the DCB to communicate directly with the resident disk handler. Section 9, the Disk Operating System, contains more information on the resident disk handler.
The last type of control block encountered in the I/O subsystem is the Command Frame Buffer (CFB). This 4-byte table located at $023A is used by the SIO routine while performing the serial bus operations. The four bytes contain the device code, command code, and command auxiliary bytes 1 and 2. The data buffer that is transmitted is defined by two pointers BUFRLO [$0032,2] and BFENLO [$0034,2]. In general it is not recommended that the OS be used at this level. Other parameters have to be set, and extreme care must be taken in calling the proper sequence of subroutines. CIO and SIO were designed to be easily called by user programs. Use them --- but stay away from the command frame buffer!
IOCB CHART
| CALL | ICHID | ICDNO | ICCOM | ICSTA | ICBAL | ICBAH | ICPTL | ICPTH | ICBLL | ICBLH | ICAX1 | ICAX2 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| OPEN FILE-READ OPEN FILE-WRITE GET BYTES PUT BYTES GET RECORD PUT RECORD CLOSE FILE STATUS |
X X X X X X X X |
X X X X X X X X |
3 3 7 $B 5 9 $C $D |
note 1 note 1 note 1 note 1 note 1 note 1 note 1 note 1 |
$80 $80 00 00 00 00 X X |
06 06 06 06 06 06 X X |
X X X X X X X X |
X X X X X X X X |
X X $80 $80 $80 $80 X X |
X X 00 00 00 00 X X |
4 8 X X X X X X |
0 note 2 X X X X X X |
|
Note
1=The status of the I/O command is stored here and in the Y REG. on return
from CIO. Note 2=The Auxilary bytes of the IOCB's are used by some handlers to indicate special modes. X = Indicates ignore but do not change the current value. GENERAL NOTE: The above IOCB definitions assume:
|
Figure 8-9 Input Output Control Block (IOCB)
DCB CHART
| FUNCTION | NAME | LOCATION | DISK 810/815 | PRINTER 820 WRITE | |||||
|---|---|---|---|---|---|---|---|---|---|
| READ SECTOR | WRITE SECTOR | PUT | FORMAT | ||||||
| 810 | 815 | 810 | 815 | ||||||
| Serial Bus I.D. Device Number Command Byte Status Buffer Address Device Timeout Buffer Length |
DDEVIC DUNIT DCOMND DSTATS DBUFLO DBUFHI DTIMLO DBYTLO DBYTHI DAUX1 DAUX2 |
[$0300] [$0301] [$0302] [$0303] [$0304] [$0305] [$0306] [$0308] [$0309] [$030A] [$030B] |
$30 1-4 $52 $40 U U $30 $80 $00 2* 2* |
$30 1-8 $52 $40 U U $30 00 01 2* 2* |
$30 1-4 $57 $80 U U $30 $80 $00 2* 2* |
$30 1-8 $57 $80 U U $30 00 01 2* 2* |
$30 1-4 $50 $80 U U $31 $80/00 $00/01 - 2* - 2* |
$30 1-4 $21 $40 U U $130 - - - - |
$30 1 $57 $80 U U 5 $40 $00 1* 1* |
| 1*
= This bytes determines printer mode (see 820 manual). 2* = DAUX1 + DAUX2 specify sector for READ, WRITE (PUT), or WRITE verify. U = Indicates user-set address - = Indicates ignored |
Figure 8-10 Device Control Block (DCB)
Central I/O System Routine
The main function of CIO is to take control data from an IOCB and ensure that it is routed to the specific device handler needed, and then to pass control to that handler. CIO also acts as a pipeline for most I/O in the system. Most of the OS I/O functions use CIO as a common entry point, and all handlers exit via CIO. For example, BASIC will call CIO when performing an OPEN or a GRAPHICS statement. CIO supports the following functions:
| OPEN CLOSE GET CHARS READ RECORD PUT CHARS WRITE RECORD STATUS SPECIAL |
Device/file open Device/file close Read N characters Read next record Write N characters Write next record Get device status Device handler specific (e.g., NOTE for FMS) |
You may wish to make your own CIO calls. The calling sequence for CIO is:
;rem user has already set up IOCB
LDX #IOCBNUM ;set the IOCB
index (IOCB * 16)
JSR CIOV ;system
routine vector to CIO
BMI ERROR if
branch taken then CIO
returned
;error code in Y-register As shown in the above call, one of the IOCBs is used to communicate control data to CIO. You may use any one of the eight IOCBS. CIO expects the IOCB index to be in the X-register. Note that this value must be the IOCB number multiplied by 16. The reason is that CIO uses this value as a true index into the various IOCBs, and each IOCB is 16 bytes. Upon return, the sign bit of the 6502 is set to indicate success or error in the I/O operation. If the N-bit is clear (i.e., a zero) the I/O was done successfully, and the Y-register will contain a 1. If the N-bit is set, the I/O request resulted in an error; in that case the Y-register will contain the error code number. A BMI instruction to an error routine is the usual way to test for operational success. The error/success value is also returned in the IOCB byte ICSTA (see IOCB definition). Chapter 5 of the OPERATING SYSTEM Manual has a sample program segment that calls CIO to OPEN a disk file, READ some records., then CLOSE the file.
CIO copies the control data from the selected IOCB to the page zero ZIOCB. CIO then determines the device handler entry point and vectors to the appropriate device handler routine. Figure 8-11 is a flowchart of the CIO system routine.
Figure 8-11.1 CIO Routine
Figure 8-11.2 CIO Routine
The Handler Address Table
CIO calculates the device handier entry point in an indirect manner. First of all, an OPEN call must preceed any other I/O function to a device. While processing an OPEN command, CIO retrieves the device specification for the file being opened. The device specification is an ATASCII string pointed to by the buffer address portion of the IOCB. The first element in this string must be a one character device identifier (e.g., `D' for disk drive, `Pt for printer,...). CIO then searches for this character in a table of handier entry points called HATABS, which runs from $031A to $033B (Figure 8-12 shows the layout of HATABS). CIO begins the search at the bottom of HATABS and works upward until a match is found for the device identifier. The search is performed in this direction to facilitate the addition or modification of device handlers. During the initialization code, the HATABS table is copied from ROM down into RAM. Devices that are then booted (e.g. the disk drive, or RS-232 module) then add their handler information to the bottom of the table. There is room in the table for a total of 14 entries, 5 of which are set up during system initialization. If a new printer handier were added to the bottom of the table, CIO would find it before the one transferred from ROM. This allows new handlers to replace old ones.
After the device identifier has been located, CIO knows that the next two bytes point to the devices' entry point table. This is a table of addresses for the routines that handle each of the CIO functions. Figure 8-13 gives the layout of a typical entry point table.
To find which one of the handier entry points to vector through, CIO then uses ICCOM, the IOCB command byte, as an index into the entry table. The entry point tables for all of the resident device handlers can be found in the OS listing. The relative position of each of the vectors in an entry table have the same meaning from table to table. For example, the first position in all of the device handler entry point tables is the vector to the device handler OPEN routine.
You can take advantage of the flexibility of HATABS to add some new features to the OS. Figure 8-14 is an example of how to add a null handler. A null handler does exactly what its name implies: nothing. This can be useful in debugging programs. Instead of waiting around for 50,000 disk accesses to find a bug, output can be directed to the null handier. With a null handler, trouble spots in programs can be identified more quickly.
01 ; HANDLER ADDRESS
TABLE
E430 02
PRINTV =
$E430
E440 03
CASETV =
$E440
E400 04
EDITRV =
$E400
E410 05
SCRENV =
$E410
E420 06
KEYBDV =
$E420
07 ;
0000
08 *=
$031A
09
;
10 HATABS
031A
50 20
.BYTE 'P' PRINTER
031B
30E4 30
.WORD
PRINTV ENTRY
POINT TABLE
031D
43 40
.BYTE 'C' CASSETTE
031E
40E4 50
.WORD CASETV ENTRY POINT TABLE
0320
45 60
.BYTE 'E' DISPLAY EDITOR
0321
00E4 70
.WORD EDITRV ENTRY POINT TABLE
0323
53 80
.BYTE 'S' SCREEN HANDLER
0324
10E4 90
.WORD SCRENV ENTRY POINT TABLE
0326
4B 0100
.BYTE 'K' KEYBOARD
0327
20E4 0110
.WORD KEYBDV ENTRY POINT TABLE
0329
00 0120
.BYTE 0 FREE ENTRY 1
(DOS)
032A 00 00 0130
.BYTE 0,0
032C
00 0140
.BYTE 0 FREE ENTRY 2 (850
MODULE)
032D 00 00 0150
.BYTE 0,0
032F
00 0160
.BYTE 0 FREE ENTRY 3
0330
00 00 0170 .BYTE
0,0
0332
60 0180
.BYTE 0 FREE ENTRY 4
0333
00 00 0190 .BYTE
0,0
0335
00 0200
.BYTE 0 FREE ENTRY 5
0336
00 00 0210 .BYTE
0,0
0338
00 0220
.BYTE 0 FREE ENTRY 6
0339
00 00 0230 .BYTE
0,0
033B
00 0240
.BYTE 0 FREE ENTRY
7
Figure 8-12 Handier Address Table (HATABS)
Download / View CH8PRG3.SRC (Listed ASSEMBLY)
*=$PRINTV
E430
9E
EE .WORD PHOPEN-1
DEVICE OPEN
E432 DB
EE .WORD PHCLOS-1
DEVICE CLOSE
E434 9D
EE .WORD BADST-1 DEVICE
READ-NOT IMPLEMENTED
E436 A6
EE .WORD PHWRIT-1
DEVICE WRITE
E438 80
EE .WORD PHSTAT-1
DEVICE STATUS
E43A 9D
EE .WORD BADST-1 SPECIAL-NOT
IMPLEMENTED
E43C 4C 78 EE
JMP PHINIT DEVICE
INITIALIZATION
Figure 8-13 Printer Handler Entry Point Table
Download / View CH8PRG4.SRC (Listed ASSEMBLY)
0000 10
* =
$600
031A 20
HATABS = $031A
0600
A000 40 START LDY
#0
0602 B91A03 60 LOOP
LDA HATABS,Y
0605 C900
70 CMP
#0 ; FREE
ENTRY?
0607 F009
80 BEQ
FOUND
0609 C8
90 INY
060A
C8
0100 INY
060B
C8
0110 INY ;
POINT TO NEXT HATABS ENTRY
060C C022
0120 CPY
#34 ; AT END OF
HATABS?
060E D0F2
0130 BNE
LOOP ; NO ...
CONTINUE
0610 38
0140 SEC ;
YES... INDICATE ERROR
0611 60
0150 RTS
0160
;
0612 A94E 0180 FOUND LDA
#'N ; SET DEVICE
NAME
0614 991A03
0190 STA
HATABS,Y
0617 C8
0200 INY
0618
A924
0210 LDA
#NULLTAB&255
061A 991A03
0220 STA
HATABS,Y ; HANDLER ADDRESS
061D
C8
0230 INY
061E
A906
0240 LDA
#NULLTAB/256
0620 991A03
0250 STA
HATABS,Y
0623 60
0260 RTS
0270
0624
3206 0290 NULLTAB .WORD RTHAND-1
; OPEN
0626 3206
0300
.WORD RTHAND-1 ; CLOSE
0628
3406 0310
.WORD NOFUNC-1 ; READ
062A
3206 0320
.WORD RTHAND-1 ; WRITE
062C
3206 0330
.WORD RTHAND-1 ; STATUS
062E
3406 0340
.WORD NOFUNC-1 ; SPECIAL
0630 4C3306
0350
JMP RTHAND ;
INITILIZATION
0360
;
0633 A001 0380
RTHAND LDY #1
; SUCCESSFUL I/O FUNCTION
0635 60
0400
NOFUNC RTS
; FUNCTION NOT IMPLEMENTED
Figure 8-14 Null Handler
Download / View CH8PRG5.SRC (Listed ASSEMBLY)
The Device Handlers
The device handlers can be divided into resident and nonresident handlers. The resident handlers are present in the OS ROM, and may be called through CIO whenever the handier has an entry in HATABS. The nonresident handlers must first be loaded into RAM and have their entry placed into HATABS before they can be called from CIO. The resident device handlers are:
|
(E:) Display Editor (S:) Screen (K:) Keyboard (P:) Printer (C:) Cassette |
Although the nonresident handlers are not present in the OS ROM, nonresident handlers may be added by the OS during power-up or SYSTEM RESET. You can even add your own device handier during program execution. Figure 8-14 presents an example of adding a handier to the OS.
The device handlers use I/O control data passed by CIO in the ZIOCB. Data in the ZIOCB is used to perform I/O functions such as OPEN, CLOSE, PUT, and GET. Not all of the device handlers support all the I/O commands (e.g., trying to PUT a character to the keyboard results in an Error 146, Function Not implemented). Section 5 of the OPERATING SYSTEM Manual contains a list of the functions supported by each device handler, as well as complete operational details of the handlers.
Serial I/O Routine
SIO handles serial bus communication between the serial device handlers in the computer and the serial bus devices. It communicates with its caller through the device control block (DCB). SIO uses the I/ O control data in the DCB to send and receive commands and data over the serial bus. The calling sequence is:
;caller has
set up the DCB to do function
JSR SIOV ;system vector to SIO
BMI
ERROR ;N-bit set indicates error in I/O execution The DCB contains I/O control information for SIO and must be setup before the call to SIO. Figure 8-10 shows the contents of the DCB for some common I/O operations.
To send commands to SIO, you need to understand the structure of the DCB, which is described in Section 9 of the OPERATING SYSTEM Manual. Figure 8-15 demonstrates a simple assembly language routine to output a line to the printer by setting up the DCB and calling SIO.
0000 05 *=
$3000 ARBITRARY
START
10
;THIS ROUTINE PRINTS A LINE TO THE PRINTER BY CALLING SIO
E459
20
SIOV
= $E459 SIO
VECTOR
009B 30
CR
= $9B
EOL
0040 40
PRNTID =
$40 PRINTER SERIAL BUS
ID
004E 45
MODE
= $4E NORMAL
MODE
001C 50
PTIMOT =
$001C TIMEOUT
LOCATION
0300 60
DDEVIC =
$300 DEVICE SERIAL BUS
ID
0301 70
DUNIT =
$301 SERIAL UNIT
NUMBER
0302 80
DCOMND =
$302 SIO
COMMAND
0303 90
DSTATS =
$303 SIO DATA
DIRECTION
0304 0100
DBUFLO =
$304 BUFFER LOW
ADDRESS
0305 0110
DBUFHI =
$305 BUFFER HIGH
ADDRESS
0306 0120
DTIMLO =
$306 SIO
TIMEOUT
0307 0130
DTIMHI =
$307
0308 0140
DBYTLO =
$308 BUFFER
LENGTH
0309 0150
DBYTHI =
$309
030A 0160
DAUX1 =
$30A AUXILARY BYTE---PRINTER
MODE
030B 0170
DAUX2 =
$30B AUXILARY BYTE---NOT USED
0180
;
3000 455841 0190 MESS .BYTE
"EXAMPLE 12",CR
3001 4D504C
3005 452031
3009
329B
0200
;
300B A940
0220 LDA #PRNTID
SET BUS ID
300D 8D0003
0230 STA DDEVIC
3010
A901
0240 LDA #1 SET
UNIT NUMBER
3012 8D0103
0250 STA DUNIT
3015
A94E
0260 LDA #MODE
3017
8D0A03
0270 STA DAUX1
PRINTER MODE NORMAL
301A A901
0275 LDA #1
301C
8D0B03
0280 STA DAUX2
UNUSED
301F 8D0703
0290 STA DTIMHI TIMEOUT<256
SECS
3022 A51C
0300 LDA PTIMOT SET
SIO TIMEOUT FOR PRINTER
3024 8D0603
0310 STA DTIMLO
3027
A900
0320 LDA #MESS&255
3029
8D0403
0330 STA DBUFLO SET
MESS AS BUFFER
302C A930
0340 LDA #MESS/256
302E
8D0503
0350 STA DBUFHI
3031
A980
0360 LDA #$80 SET
SIO DATA DIRECTION FOR
3033 8D0303
0370 STA DSTATS PERIPHERAL
TO RECEIVE
3036 A957
0380 LDA #'W
SIO COMMAND WRITE
3038 8D0203
0390 STA DCOMND
303B
2059E4
0410 JSR SIOV CALL
SIO
303E 3001
0420 BMI ERROR
3040
00 0430 GOOD BRK
3041
00 0440 ERROR BRK
Figure 8-15 SIO Call to Dump Line to Printer
Download / View CH8PRG6.SRC (Listed ASSEMBLY)
SIO Interrupts
SIO uses three IRQ Interrupts to control serial bus communications with serial bus devices:
| IRQ | Location, Length |
Function |
|---|---|---|
| VSERIR VSEROR VSEROC |
[$020A,2] [$020C,2] [$020E,2] |
SERIAL INPUT READY SERIAL OUTPUT NEEDED TRANSMISSION FINISHED |
All program execution is halted while SIO uses the serial bus for communication. Even though nothing else is happening during a serial bus transfer, the actual I/O itself is interrupt driven. The method of communicating between SIO and the interrupt handlers is known as the semaphore method. The mainline code waits in a loop until the interrupt handlers signal it that they are finished. For instance, during output, SIO places a byte to be transferred into the serial output shift register located in POKEY. It then enters a loop and watches a flag which will be set when the requested I/O is completed. During this time POKEY is sending the bits out over the serial line. When the byte has been sent, a Serial Output Needed IRQ is generated. This IRQ then vectors to a routine which loads the next byte in the buffer into the serial output register. This process continues until the entire buffer has been sent. After taking care of checksum values, the interrupt handler then sets the transmit done flag. Meanwhile, SIO has been patiently looping, watching for this flag to be set. When it sees that the flag has been set, SIO exits back to the calling routine.
The SIO execution for input is similar. POKEY generates an IRQ (VSERIR) to inform SIO a byte has been received in the serial input shift register (SERIN). The interrupt handler for VSERIR then stores the byte in a buffer and checks whether the end of the buffer has been reached. If so, it sets the transmit done flag.
You may have noticed from the above explanation that SIO wastes some time idling while waiting for POKEY to send or receive information on the bus. Because the vectors for the three SIO IRQ service routines are RAM vectors, they can be used by your own handlers to improve system I/O performance. Indeed, this is how the ATARI 850 Interface Module is able to do concurrent I/O. That handler takes over the SIO IRQ vectors and points them to the module's own IRQ routines while in concurrent I/O. This allows the calling program to continue to execute while the interface Module sends commands and data over the serial line.
Using CIO from BASIC
Most of the CIO functions (OPEN, CLOSE, etc.) are available through calls from BASIC using the OPEN, GET and PUT statements. However, BASIC lacks one set of the functions of CIO, the ability to do non-record I/O more than a byte at a time (GETCHRS and PUTCHRS).
The ability to input or output a buffer of characters is a powerful asset. An assembly language routine can be loaded directly into memory from a disk file for instance. Or a high resolution graphics image can be loaded directly into the screen memory area. A common method of improving a BASIC language program's performance is to provide a machine language program to handle certain functions that BASIC executes slowly. Unfortunately, finding a place in RAM for such a routine can be a knotty problem. One solution is to place the routine into an area reserved for a string, and calling the routine with a USR call to ADR(string). Since the address of a BASIC string may shift during program editing, the assembly language routine must be relocatable. Therefore, unmodified memory reference instructions to addresses within the string will not work.
The subroutine in Figure 8-16 avoids the use of strings by loading a routine into Page 6 RAM. Thus the assembly language routine need not be relocatable. Control data is POKEd into an IOCB to read an assembly language routine directly into RAM at the address it was assembled. The BASIC subroutine in Figure 8-16 can also be used to output data directly from memory with the user specifying both the location and the length of the data buffer.
30 REM THIS PROGRAM LOADS PAGE 6 FROM THE FILE D:TEST
100 DIM
FILE$(20),CIO$(7):CIO$="hhh*LVd"
106 REM CIO$ IS PLA,PLA,PLA,TAX,JMP
$E456 (CIOV)
110 FILE$="D:TEST":REM - *FILE NAME
120
CMD=7:STADR=1536:GOSUB 30000
130 IF ERROR=1 THEN ? "TRANSFER
COMPLETE":STOP
135 ? "ERROR # ";ERROR;" OCCURRED AT LINE #
";PEEK(186)+256*PEEK(187)
200 END
300 REM _ CIO SETUP
SUBROUTINE
310 REM
30000 REM
30001 REM
30002 REM THIS
ROUTINE LOADS OR SAVES MEMORY FILE FROM BASIC
30003 REM BY SETTING UP AN
IOCB AND CALLING CIO DIRECTLY
30004 REM
30006 REM ON ENTRY CMD=7 MEANS
LOAD MEMORY
30008 REM
_ CMD=11 MEANS SAVE
MEMORY
30009 REM _ STADR=
THE ADDRESS TO LOAD OR SAVE MEMORY
30010 REM
_ BYTES= THE NUMBER OF BYTES
TO SAVE OR LOAD
30011 REM
_ IOCB= THE IOCB TO
USE
30012 REM _ FILE$=
DESTINATION FILE NAME
30013 REM _
30014 REM ON EXIT ERROR=1 MEANS
SUCCESSFUL COMMAND
30018 REM _
ERROR<>1 THEN ITS AN ERROR STATUS
30019 REM
30020 REM _ *** IOCB
EQUATES ***
30022 REM
30024
IOCBX=IOCB*16:ICCOM=834+IOCBX:ICSTA=835+IOCBX
30026
ICBAL=836+IOCBX:ICBAH=837+IOCBX
30028
ICBLL=840+IOCBX:ICBLH=841+IOCBX
30029 REM
30030 AUX1=4:IF CMD=11 THEN
AUX1=8
30035 TRAP 30900:OPEN #IOCB,AUX1,0,FILE$
30040 TEMP=STADR:GOSUB
30500
30090 POKE ICBAL,LOW:POKE ICBAH,HIGH
30100 TEMP=BYTES:GOSUB
30500
30130 POKE ICBLL,LOW:POKE ICBLH,HIGH
30140 POKE
ICCOM,CMD:ERROR=USR(ADR(CIO$),IOCBX)
30150
ERROR=PEEK(ICSTA):RETURN
30200 REM
30300 REM _ ***ROUTINE RETURNS
HIGH,LOW BYTE OF 16 BIT NUMBER
30400 REM
30500
HIGH=INT(TEMP/256):LOW=INT(TEMP-HIGH*256):RETURN
30550 REM
30600 REM
***TRAP HERE IF ERROR OCCURS DURING ROUTINE****
30900 ERROR=PEEK(195)
30920 CLOSE #IOCB:RETURN
Figure 8-16 BASIC Direct CIO Call
Download CH8PRG7.BAS (Saved BASIC)
Download / View CH8PRG7.LST (Listed BASIC)
Most of the time in programming we have the luxury of ignoring time considerations. Usually we don't care how long a program takes to run, or don't bother to measure precise timing values on subroutine execution. Sometimes, however, timing considerations play an important role in the performance of the program, and then we enter the world of Real Time Programming. Such cases arise often with the ATARI Home Computer System. Much more so than with most other small computers, this system thrives on real time control. The very time base upon which the internal circuitry operates was precisely chosen so that the computer hardware would be in complete synchrony with a specific signal - namely, the television signal.
In order to get clean, crisp graphics and special effects, the hardware in the ATARI Home Computer System is slaved to the local television signal. Unfortunately, there are several "standard" television signals in use in various countries. In the United States, the standard is the NTSC system: 60 frames per second, 262 horizontal lines per frame, and 228 color clocks per line. The 262 lines comes about only because the ATARI Home Computer System generates a non-interlaced signal; the real standard calls for 525 lines with half being shown each frame. Some European countries use a standard called PAL: 50 frames per second, 312 lines per frame. The result is that timing considerations are different on NTSC vs. PAL systems. Refer to Section 2, ANTIC and the Display List, for a more detailed discussion of the television signal. The remarks in this subsection are based on NTSC systems.
Synching to the Television Signal
The 6502 processor is synchronized to the television signal in two ways, a coarse and a fine synchronization. Coarse synchronization is derived by having the same signal that synchronizes television receivers to the transmitted television signal cause a system interrupt. This signal is called vertical blank, and in television sets it is the cue to turn off the electron beam and begin retracing to the top of the screen in preparation for another frame. This same signal is presented to the computer as a nonmaskable interrupt. To the programmer, this provides a regularly occurring interrupt that can be used for everything from sound and timing information to a crude multiprogramming method. For a detailed discussion of Vertical Blank processing, see the subsection on interrupt Processing Structure.
An even finer correlation between the 6502 processing and the television signal was achieved by setting the system clock rate to 1.79 MHz. This results in a direct relationship between the time it takes to execute a machine instruction and the distance the electron beam travels on the screen. For instance, during the time it takes to execute the shortest 6502 instruction (2 cycles), the beam moves four color clocks, or one OS mode 0 character width across the screen. This precise correlation of timing allows a skilful programmer to produce graphic effects in the middle of a single scan line. A note of caution is in order, however. ANTIC's direct memory access makes that this intraline timing very uncertain, and will vary depending upon the mode selected and other factors. In actual usage, this means that each intraline change must be dealt with and tested as a special case.
Hardware Timers
There are four countdown timers built into the POKEY chip. They function as reusable "hardware subroutines". The most common use of these timers is in conjunction with the audio channels for producing sound effects (see Section 7, Sound). They may also be used as straight countdown timers, since they generate an IRQ interrupt (see subsection on Interrupt Processing Structure). Each timer is associated with a frequency register which holds the initial value for the timer. When the hardware register STIMER is written to, this initial value is loaded and the countdown timer started. When the timer counts down to zero, an IRQ Interrupt request is generated. It is important to note that only timers 1, 2 and 4 have interrupt vectors for processing. The following steps must be taken to activate any of the timers.
- Step 1. Set AUDCTL [$D208] with proper value to select clocking
frequency for the desired timer.
Step 2. Set the volume output to 0 for the audio channel associated with the selected timer (AUDC1, AUDC2, AUDC4 [$D201, $D203, $D207]).
Step 3. Set AUDF1 , AUDF2 or AUDF4 [$D200, $D202, $D206] with the desired number of clock intervals to count.
Step 4. Set up routine to process timer interrupt.
Step 5. Change timer interrupt vector to point to processing code (VTIMR1, VTIMR2, VTIMR4 [$0210, $0212, $0214]). *** Note. Due to a bug in the source code, the original version of the operating system will never vector through VTIMR4. This has been fixed in Rev. B.
Step 6. Set bits 0, 1 or 2 in IRQEN and the OS shadow POKMSK [$D20E and $0010] to enable interrupts from timers 1, 2 or 4.
Step 7. Write any value to register STIMER [$D209] to load and start the count down timers.
One complication of working with these timers is that the 6502's response to them will be pre-empted and possibly delayed by ANTIC's direct memory access, display list interrupts or vertical blank processing.
Software Timers
There are 6 system software timers:
| Name | Location | Vector or flag |
|---|---|---|
| RTCLOK CDTMV1 CDTMV2 CDTMV3 CDTMV4 CDTMV5 |
[$0012,3] [$0218,2] [$021A,2] [$021C,2] [$021E,2] [$0220,2] |
none CDTMA1 [$0226,2] CDTMA2 [$0228,2] CDTMF3 [$022A,1] CDTMF4 [$022C,1] CDTMF5 [$022E,1] |
All of the system timers are decremented as part of the vertical blank (VBLANK) process. If the VBLANK process is disabled or intercepted, the timers will not be updated.
The real time clock (RTCLOK) and system timer 1 (CDTMV1) are updated during immediate VBLANK, Stage 1. RTCLOK counts up from 0 and is a three-byte value. When RTCLOK reaches its maximum value (16,777,216) it will be reset to zero. RTCLOK can be used as a real. time clock as Figure 8-17 shows.
Because the system timers are updated as part of the VBLANK process, special care is needed to set them correctly. A system routine called SETVBV [$E45C] is used to set them. The call to SETVBV is:
- REG :
X contains the timer value high byte
Y contains the timer value low byte
A contains the timer number 1-5
LDA #1 ;Set system timer
1
LDY #0
LDX #2 ;value is $200
VBLANK periods
JSR SETVBV ;Call system routine to set
timer
System timers 1-5 are 2-byte counters. They may be set to a value using the SETVBV routine. The OS then decrements them during VBLANK. Timer 1 is decremented during immediate VBLANK, Stage 1. Timers 2-5 are decremented during immediate VBLANK, Stage 2. Different actions are taken by the OS when the different timers are decremented to 0.
System timers 1 and 2 have vectors associated with them. When timer 1 or 2 reaches 0, the OS simulates a JSR through the vector for the given timer. Figure 8-7 gives the vectors for the two timers.
System timers 3-5 have flags that are normally SET (i.e. non-zero). When either of the three timers count to 0, the OS will clear (zero) that timer's flag. You may then test the flag and take appropriate action.
Timers 1-5 are general purpose software timers that may be used for a variety of applications. For example, timer 1 is used by SIO to time serial bus operations. If the timer counts to zero before an bus operation is complete, a "timeout" error is returned. Timer 1 is set to various values depending on the device being accessed. This ensures that, while a device has ample time to answer an I/O request, the computer will not wait indefinitely for a non-existent device to respond. The cassette handler uses timer 3 to set the length of time to read and write tape headers. Figure 8-18 shows an example using timer 2 to time a sound acting as a metronome.
The software timers are generally used when the time scale involved is greater than one VBLANK period. For time durations shorter than this, either the hardware timers or some other method must be employed.
1 POKE 752,1
3 ? "+":REM CLEAR SCREEN (+=ESC-CTRL-CLR)
4 ?
"HOUR";:INPUT HOUR:? "MINUTE";:INPUT MIN:? "SECOND";:INPUT SEC
5
CMD=1:GOSUB 45
6 ? "+";HOUR;" : ";MIN;" : ";SEC:? " ": ? " "
7
CMD=2:GOSUB 45
9 ? "";HOUR;":";MIN;":";SEC;" ":GOTO 7
10
REM THIS IS A DEMO OF THE REAL TIME CLOCK
20 REM THIS ROUTINE ACCEPTS AN
INITIAL TIME IN HOURS,MINUTES, AND SECONDS
30 REM IT SETS THE REAL TIME
CLOCK TO ZERO
40 REM THE CURRENT VALUE OF RTCLOCK IS USED TO ADD THE
INITIAL TIME TO GET
42 REM THE CURRENT TIME HOUR,MIN,SEC
45
HIGH=1536:MED=1537:LOW=1538
50 REM
60 REM ******ENTRY POINT****** 65
REM
70 ON CMD GOTO 100,200
95 REM
96 REM ****INITIALIZE
CLOCK*****
97 REM
100 POKE 20,0:POKE 19,0:POKE 18,0
105 DIM
CLOCK$(50)
106 CLOCK$=" "
107 GOSUB 300
110
IHOUR-HOUR:IMIN=MIN:ISEC=SEC:RETURN
197 REM
198 REM *******READ
CLOCK*****
199 REM
200 REM
201 A=USR(ADR(CLOCK$))
210
TIME-C(((PEEK(HIGH)*256)+PEEK(MED))*256)+PEEK(LOW))/59.923334
220
HOUR=INT(TIME/3600):TIME=TIME-(HOUR*3600)
230
MIN=INT(TIME/60):SEC=INT(TIME-(MIN*60))
235 SEC=SEC+ISEC:IF SEC>60
THEN SEC=SEC-60:MIN=MIN+1
236 MIN=MIN+IMIN:IF MIN>60 THEN
MIN=MIN-60:HOUR=HOUR+1
237 HOUR=HOUR+IHOUR
240
HOUR=HOUR-(INT(HOUR/24))*24
250 RETURN
300 FOR J=l TO 38:READ
Z:CLOCK$(J,J)=CHR$(Z):NEXT J:RETURN
310 DATA
104,165,18,141,0,6,165,19,141,1,6,165
320 DATA
20,141,2,6,165,18,205,0,6,208,234
330 DATA
165,19,205,1,6,208,227,165,20,205,2,6,208,220,96
Figure 8-17 Real Time Clock
Download CH8PRG8.BAS (Saved BASIC)
Download / View CH8PRG8.LST (Listed BASIC)
1 REM THIS IS A BASIC PROGRAM TO CONTROL THE RATE OF A
METRONOME
2 REM
3 REM
5 PRINT
"+":REM
CLEAR SCREEN
10
X=10:REM
INITIAL VALUE FOR RATE
20 FOR J=1 TO 10:NEXT
J:REM SOFTWARE
DELAY LOOP
50 IF STICK(0)=14 THEN X=X+1 :REM
STICK FORWARD MEANS SPEED UP RATE
51 IF STICK(0)=13 THEN X=X-1
:REM STICK BACK MEANS SLOW METRONOME RATE
52 IF
X<1 THEN
X=1:REM NEVER
GO BELOW ONE
53 IF X>255 THEN
X=255:REM OR
ABOVE 255
54
REM PRINT
BEATS/MINUTE
56 ? "";INT(3600/X);"
BEATS/MINUTES "
60 POKE
0,X:REM
LOCATION $0000 HOLDS THE RATE FOR
70 NEXT I
:REM THE
FOLLOWING ASSEMBLY ROUTINE
Figure 8-18 BASIC language Metronome Routine
Download CH8PRG9.BAS (Saved BASIC)
Download / View CH8PRG9.LST (Listed BASIC)
40
*=$600
50 ;METRONOME ROUTINE...USES $0000 TO PASS THE
METRONOME RATE
60 ;
70 AUDF1
= $D200 AUDIO FREQUENCY
REGISTER
80 AUDC1
= $D201 AUDIO CONTROL
REGISTER
90
FREQ =
$08 AUDF1 VALUE
0100
VOLUME =
$AF AUDC1 VALUE
0110
OFF
= $A0 TURN OFF
VOLUME
0120
SETVBV =
$E45C SET TIMER VALUE ROUTINE
0130
XITVBV =
$E462
0140
CDTMV2 =
$021A TIMER 2
0150
CDTMA2 =
$0228 TIMER 2 VECTOR
0160
ZTIMER =
$0000 ZPAGE VBLANK TIMER VALUE
0170 ;
0180
START
LDA #10
0190
STA ZTIMER
0200
; SET THE TIMER VECTOR
0220 ;
0230
INIT LDA #CNTINT&255
0240
STA CDTMA2
0250
LDA #CNTINT/256
0260
STA CDTMA2+1
0270 ;
0280
; SET THE TIMER VALUE AFTER THE
VECTOR
0290
;
0300
LDY ZTIMER SET TIMER TWO TO
COUNT
0310
JSR SETIME
0320
RTS
0340 ; METRONOME COUNT DOWN
VECTORS TO HERE
0380 ; SET UP AUDIO
CHANNEL FOR MET CLICK
0390
0400
CNTINT LDA #VOLUME
0410
STA AUDC1
0420
LDA #FREQ
0430
STA AUDF1
0435
LDY #$FF DELAY
0440
DELAY
DEY
0442
BNE DELAY
0450
STY AUDC1
0460
JMP INIT
0480 ;
0490
; SUBROUTINE TO SET TIMER
0500
;
0520
SETIME LDX #0 NO
TIME >256
VBLANKS
0530
LDA #2 SET
TIMER 2
0540
JSR SETVBV SYSTEM
ROUTINE TO SET
TIMER
0550
RTS
0560
*=$2E2
0570
.WORD START
0580
.END
Figure 8-19 Assembly language Metronome Routine
Download / View CH8PRG10.SRC (Listed ASSEMBLY)
The Floating Point Package (FPP) is a set of integrated routines that provide an extended arithmetic capability for the OS. These routines are combined in a separate ROM chip that is provided as part of the ATARI 10K OPERATING SYSTEM. The FPP is located at hexadecimal addresses $D800 - $DFFF. It has not been changed in the Revision B version of the OS. The following paragraphs detail the internal representation of numbers, the actual routines available for use, and their proper calling sequence. An assembly language program example is included to illustrate how to access the FPP from user programs.
Internal Representation
The FPP configures numbers internally as 6-byte quantities. Each number consists of a 1-byte exponent and a 5-byte mantissa in Binary Coded Decimal (BCD) format. This representation was chosen to minimize rounding errors that might occur in some math routines.
The sign bit of the exponent byte provides the sign of the mantissa, 0 for positive, 1 for negative. The least significant 7 bits of the exponent byte provide the exponent as a power of 100 in "excess 64 notation". In excess 64 notation, the value 64 is added to the exponent value before it is placed in the exponent byte. This allows the full range of exponents, positive and negative, to be expressed without having to use the sign bit.
The mantissa is always normalized such that the most significant byte is non-zero. However, since the mantissa is in BCD format, and the exponent represents powers of 100 and not 10, either 9 or 10 digits of precision may result. There is an implied decimal point to the right of the first mantissa byte so that an exponent that is less than 64 (40 hex) indicates a number less than 1.
EXAMPLES(Format values are in hex)
- Number: 0.02 2 * 100**-l
Format: 3F 02 00 00 00 00 (exponent= 40-1)
Number: -0.02 -2 * 100**-l
Format: BF 02 00 00 00 00 (exponent=
80+40-1)
Number: 37.0 = 37 * 100**0
Format: 40 37 00 00 00 00 (exponent= 40+0)
Number: -460312 = -46.0312 * 100**2
Format: C2 46 03 12 00 00
(exponent= 80+40+2)
The number zero is handled as a special case, and is represented as a zero exponent and zero mantissa. Either the exponent or the first mantissa byte may be tested for zero.
The dynamic range of numbers that can be represented by this scheme is 10**-98 to 10**+98.
Memory Utilization
Two areas of RAM memory are used in implementing the FPP. They are:
- $00D4 - $00FF in Page zero
$057E - $05FF in Page five
These areas are used both for control parameter storage and to simulate several floating point registers. The two pseudo-registers of primary interest are called FRO and FR1 (locations $00D4-$00D9 and $00EO- $00E5 respectively). Each of these pseudo-registers is six bytes in length and will hold a number in floating point representation. A two- byte pointer is used in pointing to a floating point number. This is called FLPTR and resides at $00FC.
Buffer areas must be provided for text strings in converting between floating point numbers and ATASCII text strings. The output buffer is called LBUFF, a 128 byte block from $0580 to $05FF. The input buffer is set by the two byte pointer INBUFF at $00F3. Also, a one byte index CIX at $00F2 is used as an offset into the buffer pointed to by INBUFF.
A typical sequence to use the floating point package from an assembly language routine would be as follows. First an ATASCII string that represents one of the numbers to be used by a math routine would be stored in a buffer anywhere in memory. Next, pointer INBUFF would be set to point to the beginning of this string. Also, the index value, CIX, should be set to 0. The number is then ready to be converted to a floating point representation, so routine AFP would be called. This would result in a floating point number being placed in FRO where it could be used in any of the FPP operations. After the conclusion of the mathematical operations, the floating result would be in FR0. Calling the routine FASC would convert this number to an ATASCII string located in LBUFF. Refer to Figure 8-21 for an example of this process.
To use 16-bit values with the FPP, place the two bytes of the number into the lowest two bytes of FRO ($D4 and $D5) and JSR IFP, which converts the integer to its floating point representation., leaving the result in FRO. Subroutine FP1 performs the reverse operation.
The chart on the next page lists the functions available, their ROM addresses, pseudo registers affected and approximate maximum computation time.
FLOATING POINT ROUTINES
| NAME | ADDRESS | FUNCTION | RESULT | MAX. TIME (microsec.) |
|---|---|---|---|---|
| AFP FASC IFP FPI FSUB FADD FMUL FDIV FLDOR FLDOP FLD1R FLD1P FSTOR FSTOP FMOVE PLYEVL EXP EXP1O LOG LOG10 ZFR0 AF1 |
D800 D8E6 D9AA D9D2 DA60 DA66 DADB DB28 DD89 DD8D DD98 DD9C DDA7 DDA8 DDB6 DD40 DDC0 DDCC DECD DED1 DA44 DA46 |
ATASCII to floating point Floating point to ATASCII Integer to floating point Floating point to Integer FR0-FR1 Subtraction FR0+FR1 Addition FR0*FR1 Multiplication FR0/FR1 Division Floating Load using X,Y Floading Load using FLPTR Floating Load using X,Y Floating Load using FLPTR Floating store using X,Y Floating store with FLPTR Move FR0 Polynomial evaluation Exponentiation - e**FR0 Exponentiation - 10**FR0 Natural logarithm Base 10 logarithm Set to zero Set register in X to zero |
FR0 LBUFF FR0 FR0 FR0 FR0 FR0 FR0 FR0 FR0 FR1 FR1 FR0 FR0 FR1 FR0 FR0 FR0 FR0 FR0 FR0 varies |
3500 950 1330 2400 740 710 12000 10000 70 60 70 60 70 70 60 88300 115900 108800 136000 125400 80 80 |
Figure 8-20 Floating Point Routines
0000 20
*= $4000 ; ARBITRARY STARTING
POINT
DDB6 30
FMOVE =
$DDB6
DA60 40
FSUB =
$DA60
0482 50
FTEMP =
$0482
DDA7 60
FSTOR =
$DDA7
D8E6 70
FASC =
$D8E6
0OF3 80
INBUFF =
$00F3
D800 85
AFP =
$D800
0OF2 90
CIX =
$00F2
0580 100 LBUFF =
$0580
009B 120 CR
=
$9B
0009 130 PUTREC
=
$09
0005 140 GETREC
=
$05
E456 150 CIOV
=
$E456
0342 160 ICCOM =
$0342
0344 170 ICBAL =
$0344
0348 180 ICBLL =
$0348
190 ;
200 ;
FLOATING POINT
DEMONSTRATION
210 ;
READS TWO NUMBERS FROM SCREEN
EDITOR,
215 ;
CONVERTS THEM TO FLOATING
POINT,
220 ;
SUBTRACTS THE FIRST FROM THE
SECOND,
225 ;
STORES THE RESULT IN
FTEMP,
230 ;
WHICH IS A USER DEFINED FP
REGISTER,
240 ;
AND DISPLAYS THE RESULT.
4000 205340 260 START JSR
GETNUM ; GET 1ST NUMBER FROM E:
4003
20B6DD 270 JSR
FMOVE ; MOVE NUMBER FROM FRO TO
FR1
4006 205340
280 JSR
GETNUM ; GET 2ND NUMBER FROM E:
4009
2060DA 290 JSR
FSUB ; FRO <--
FR0-FR1
400C 900A
300 BCC
NOERR ; SKIP IF NO ERROR
400E
A981
340 LDA
#ERRMSG&255 ; IF ERR., DISPLAY MESSAGE
4010 8D4403
350 STA
ICBAL
4013 A940
360 LDA
#ERRMSG/256
4015 4C3940
370 JMP
CONTIN
4018 A282 390 NOERR LDX
#FTEMP&255 ; STORE RESULT IN FTEMP
401A A004
400 LDY
#FTEMP/256
401C 20A7DD
410 JSR
FSTOR
420 ;
430 ;
CONVERT NUMBER TO ATACSII
STRING.
440 ;
FIND END OF
STRING,
445 ;
CHANGE NEGATIVE NUM. TO
POSITIVE,
450 ;
AND ADD CARRIAGE RETURN.
401F 20E6D8
470 JSR
FASC ; FP TO ATASCII, RESULT
IN LBUFF
4022 A0FF
480 LDY
#$FF
4024 C8 490 MLOOP
INY
4025 B1F3
500 LDA
(INBUFF),Y ; LOAD NEXT BYTE
4027 10FB
510 BPL
MLOOP ; IF POSITIVE, CONTINUE
4029
297F
520 AND
#$7F ; IF NOT, MASK OFF
MSBIT
402B 9lF3
530 STA
(INBUFF),Y
402D C8
540 INY
402E
A99B
550 LDA
#CR ; STORE CARRIAGE
RETURN
4030 9lF3
560 STA
(INBUFF),Y
570 ;
580 ;
DISPLAY RESULT
4032 A5F3
600 LDA
INBUFF ; GET BUFFER ADDRESS
4034
8D4403 610 STA
ICBAL
4037 A5F4
620 LDA
INBUFF+1
4039 8D4503 630 CONTIN STA ICBAL+1
403C
A909
640 LDA
#PUTREC ; COMMAND FOR PUT RECORD
403E 8D4203
650 STA
ICCOM
4041 A928
660 LDA
#40 ; SET BUFFER LENGTH =
40
4043 8D4803
670 STA
ICBLL
4046 A900
690 LDA
#0
4048 8D4903
700 STA
ICBLL+1
404B A200
710 LDX
#0 ; IOCB 0 FOR
SCREEN EDITOR
404D 2056E4
720 JSR
CIOV ; CALL CIO
4050
4CO040 730 JMP
START ; DO IT
AGAIN
740
750 ;
GET ATASCII STRING FROM
E:
755 ;
CONVERT TO FP, RESULT IN FR0
4053 A905
780 GETNUM LDA #GETREC ; GET
RECORD (ENDS WITH CR)
4055 8D4203
790 STA
ICCOM
4058 A980
800 LDA
#LBUFF&255 ; SET BUFFER ADDRESS = LBUFF
405A 8D4403
810 STA
ICBAL
405D A905
820 LDA
#LBUFF/256
405F 8D4503
830 STA
ICBAL+1
4062 A928
840 LDA
#40 ; SET BUFFER LENGTH
=40
4064 8D4803
850 STA
ICBLL
4067 A900
860 LDA
#0
4069 8D4903
870 STA
ICBLL+1
406C A200
880 LDX
#0 ; IOCB 0 FOR
SCREEN EDITOR
406E 2056E4
890 JSR
CIOV ; CALL CIO
4071
A980
900 LDA
#LBUFF&255 ; STORE BUFFER ADD. IN INBUFF
4073
85F3
910 STA
INBUFF
4075 A905
920 LDA
#LBUFF/256
4077 85F4
930 STA
INBUFF+1
4079 A900
940 LDA
#0 ; SET BUFFER
INDEX = 0
407B 85F2
950 STA
CIX
407D 200OD8
960 JSR
AFP ; CALL ATASCII TO
FP
4080 60
970 RTS
4081
45 980 ERRMSG .BYTE
"ERROR",CR
4082 52
4083 52
4084 4F
4085 52
4086
9B
1000
; ROUTINE START
INFO
4087 1020
* = $2E0
02EO 0040
1030 .WORD
START
02E2 1040
.END
Figure 8-21 Floating Point Example
Download / View CH8PRG11.SRC (Listed ASSEMBLY)
Return to Table of Contents | Previous Chapter | Next Chapter
