[1"z In Search of Slower Time A Rambling Monologue by Rex Johnson In the beginning, (stop me if you have heard this before) I happily played with a C128D, totally oblivious to the greater world of Amiga. My interest in monitoring shortwave RTTY and facsimile transmissions well satisfied by the range of programs available or that I had produced myself. When an Amiga 500 was thrust in to my lap a quick look at the glossies assured me that this was the bottomless pit into which I should be pouring my loot and so I become a believer. One of the converted. A mouse master! And of course it would produce great RTTY copy, all I had to do was find a program, PD or commercial, and click it on the icon. Now I don't know about you, but I have never seen such an animal! Terminal programs for bulletin boards abound but none work below the 110 baud limit to the 45, 50 and 75 baud speeds where RTTY lives. The closest I have seen is a split speed 1200/75 baud Teletex interface that was recently advertised and unfortunately 75 baud is the send speed from an Amiga. And so the simple words were spoken. 'I will write one' I said. And should have known better. In the blissful state induced by ignorance, I proceeded in a suitably logical fashion with 'Step 1'. Find out how the machine produces its own timebase for serial operations above 110 baud and patch it to work at slower speeds. (Many manuals later.) The Rxd (Receive Data) and Txd (Transmit Data) lines on the serial port come from a UART (Universal Asynchronous Receiver Transmitter) in PAULA as shown in the A500 Introductory Guide, page A22. From the Hardware Reference Manual page 240 I found that the UART data registers which control its rate are 16 bits wide, that bit 15 is used as a flag to select either 8 or 9 data bits received, and the remaining 15 bits set the time interval between bits sent. The formula given is N+1 colour clock cycles (for NTSC 279.4 nS) per bit. If we make N as large as possible (all 15 bits set) we can find the slowest speed possible. 15 base 2 = 32768 decimal, so (32768+1)*279.4 = 9.155 mS per bit time. The baud rate equals data bits per second and 109 baud is the answer. (109 * 9.155mS = 1 second.) Not looking good. Check the PAL clock cycle at 281.9nS and get 108 baud. This explains why Preferences and all those terminal programs will only let you set speeds down to 110 baud. In fact the Libraries and Devices manual admits that they cheat a bit because by their calculations you can only set speeds between 112 and 292000 baud with anything over 32000 baud being considered ambitious, particularly on a busy system. Now if you are shattered by all this, so was I! There is no way I could patch this device anywhere near 45 baud. So much for bliss. And ignorance. So, slightly reluctantly, on to step 2. Figure out other ways of creating delays in the order of 22mS (for 45 baud) and 20mS (for 50 baud). Those BASIC programmers with their hands in the air shouting 'a loop, a loop, put in a delay loop' should hush up. Remember that this machine goes in for multitasking and, since it can't do two things at once, activities run in 'time-slices' with small parts of each activity performed in turn. These activities might include things you can't see from the Workbench screen, such as disk access's, clock updates, printer outputs and other sneaky things. And they don't even get an equal share of the time slots so that a loop could be fudged. There is a strict level of priorities enforced which allow important system tasks to proceed ahead of other tasks, whenever they feel like occurring. Thanks, but that is not the answer. In the C64/C128 I could use a hardware timer. Is there one in the Amiga? Back to the manuals. The introductory Guide on page A13 says yes, there are internal timers on two 8520 I/O chips and the Hardware Reference Manual on page F3 agrees giving the good news that there are four timers in there. The bad news however, is that you can't have them, they are in use. Well almost. Lets see. 8520A, timer A. Commodore serial communications. If no serial comms happening then timer becomes available. 8520A, timer B. Video beam follower. If no beam-synced blits are in progress, this timer will be available. 8520B, timer A. Keyboard. Used whenever system Exec is in control. 8520B, timer B. Virtual timer device. used continuously whenever system Exec is in control; used for task switching and interrupts. Curiouser and curiouser! I thought we had decided that PAULA was in charge of serial comms so what is the first timer A doing sticking its oar in? Looking at the wiring of that chip it seems to be more involved with printer signals than anything else. I confess to being baffled and can only assume another serial I/O software timing requirement is being met. But look at the second timer B! A virtual timer for programmers. Oh no, not the manuals again, sigh. Well, yes. Consulting the ROM Kernal Reference Manual: Libraries and Devices, page 247, it appears that a 'Timer Device' can provide a general time-delay capability and will signal when at least a certain amount of time has passed. To use it you open up a channel of communication with the device and send it a message saying how much time should elapse. At the end of that time, the device returns your program a message stating that at least that much time has passed. A warning is given in the manual that because of the multi- tasking system the message may arrive slightly late. There are two units in the Timer Device, UNIT_VBLANK which is triggered off the vertical blanking time (NTSC 16.67mS, PAL 20ms), and UNIT_MICROHZ which uses the 8520 timer noted above and has a precision down to about 2 micro-seconds with an accuracy within 5% depending on system loading. The UNIT_MICROHZ function is exactly the sort of thing I was looking for and is even the recommended method so of course this is not the approach I used. Being scared off slightly by the procedures outlined in the book for initiating and receiving time requests, I decided that to get the program going I would patch my delay time into the unused serial comms 8520 timer and set up a loop, a loop, a polling loop to tell me when the time was up. Naughty of me I know. When the BASIC programmers have stopped laughing, I will continue. Having sorted out the method I was going to use for getting my bit rate timing intervals, Step 3 was to make it work. The hassle with this was that all the examples in the manuals are given as 'C' routines and I didn't have, nor particularly wanted, a C compiler. Heretic, some might say, but in my opinion C is over-rated and has too many loose ends in it. Also, compilers are pricey. I had previously read a review of Chris Gray's DRACO language which is supposed to have all the good bits of C with the bad bits scrubbed out, so I nabbed a copy off the club Fish Disks (76 and 77) and dived in. Generally I was impressed by DRACO, with my main hassles being some trial and error to find which DRACO commands would emulate the C examples in the manual. And so I built up a list of personal 'firsts'. First time using DRACO, making screens, windows, menus, requesters etc. Really, these things are made so (relatively) simple by the forethought of the Amiga designers. Intuition provides the pigeon-holes and all you do is pop in the numbers and it works. Amazing. The stage I am at now is that my program, The Beadle, will copy 45, 50 and 75 baud baudot (verified on radio signals) and will allow up to 300 baud copy in either Baudot or ASCII (unverified at this stage, but fingers crossed, eh). Looking at the menus you will see all the good intentions I started with such as decoding cyrillic, ARQ, FEC, PACKET and Facsimile with features like signal analysis, a data clipboard and an operator logbook. Now I am not the greedy sort, so if anyone would like the source code or wants to collaborate on creating one of these modules, drop me a line saying 'I will write one.' It is really very easy to start, take it from one who knows. You lead off with 'In the beginning (stop me if you have heard this before) etc.