ARM Club 1

home *** CD-ROM | disk | FTP | other *** search

/ ARM Club 1 / ARM_CLUB_CD.iso / contents / apps / desktop / d / datasuite / Docs_DtVoxHelp < prev

Wrap

Text File | 1994-01-01 | 65.7 KB | 1,443 lines

DataVox Help File. ================== NB If you are using this module under Risc OS kernel version 2.00 then you must have IRQutils module v0.9 or greater loaded! This is because DataVox makes heavy usage of transient call backs and the 2.00 kernel routines have an error in them that IRQutils fixes. Failure to load this module can result in address exceptions and your machine crashing! This module will play chunks of memory through the sound system with the emphasis on being able to customise dynamically how it plays. It provides several SWI's and * commands for it's control. It is to be noted that while the voice can handle a large variety of types of data it cannot handle 16 bit data *only* 8 bit data. If demand is high enough I will update this module to handle 16 bit data but it will increase its size somewhat dramatically! (Which is why I have not included it...) The newest feature of this module is complete system speed independance of playing of sounds. Code has been written into this module to ensure that it will always *attempt* to play a sound at its correct pitch no matter what the system speed (in micro seconds) is set to. Due to hardware and software limitations this will not always sound terribly good but at least it tries. This means your sample set to play nicely at the default 48 micro seconds (20.833 kHz) will still sound fine when a sound tracker is playing, which bumps the system speed up to 34 micro seconds (29.411 kHz). As far as I am aware this is the first ever module on the Arc to attempt this. To use this module you use the SWI "DataVox_SetMemory" to set a channel up for playing and issue sound commands after setting the appropriate data type using SWI "DataVox_Type". Easy eh? Nope? Well that is why I have bundled this module with its companion 'DataLoad' which provides a nice OSCLI command interface for convienance. See the file DtLdHelp for more information. The Concepts of DataVox ======================= DataVox is a module exclusively designed to play chunks of memory through the sound system of the Arc. DataVox has no concept of files or *anything* other than memory when it comes to playing and it has been heavily geared towards this. The abstraction of files and loading/ saving of them etc.. has been kept away from DataVox for two reasons :- Size - Every effort has been made to keep DataVox as small as possible while still retaining a friendly user interface. The other side effect is that it helps to keep DataVox as fast as possible. Flexibility - Because DataVox has no concept of files etc... an application can, with very little effort, bend DataVox to play files in any manner it sees fit. This allows applications to do things like playing compressed samples,playing from disk or just plain having all the sound data to be played memory resident. As you can see this leaves DataVox a very flexible module, part of what I set out to do with it. The sound system provided on the Arc has two major concepts in it. That of a channel and of a voice. DataVox provides a sound system *voice* that provides an extra layer to the *channel* system. DataVox's voice allows you to play differing things depending on what sound system channel is attached to it and to this end provides it's own internal channel system. A DataVox channel is a channel internal to DataVox and must not be confused with a sound system channel. Each DataVox channel is fully independant of all the other DataVox channels and there is a direct one-to-one correspondence between DataVox channels and sound system channels. That is from the sound system only Operating System sound channel 1 can, when assigned to the DataVox Voice, access DataVox channel 1, also OS channel 2 can only access DataVox channel 2,etc.... The layering goes something like this :- OS sound channels -----> Voices (of which there are WaveSynth-Beep eight) ... Percussion-Noise DataVox-Voice ------> DataVox channels (of which there are eight- to allow a 1-1 matching with the OS channels) Each DataVox channel has information about what memory it is to play etc.. and these settings apply only to that one channel. Some of this infor- mation is set out below. Channel Timed Pitched Type Start End Rpt Start Rpt End Rvse 1 No No Log &00000000 &00000000 &00000000 &00000000 No This is Does Does it The The start The end The start The end Does DataVox it use Type address address address address it channel play fixed of in memory in memory in memory in memory play and its in pitch Data of what of what of where of where the `master' timed play? to to play. to play. to begin to end Data channel. mode? Play. repeating repeating Back- play of play of wards? the Data. the Data. Rate &00 The rate in micro- seconds the Data is played at. All of the settings listed above are reported to you by the *DataVoxStatus command. Also stored about each channel is a key for multi-tasking access , an address for UpCall code associated with the channel, where the voice is up to in memory if the channel is playing & a toggling flag to indicate which buffer is in use. For more details about precisely what all these flags etc.. mean see the SWI command explanations. The various SWI's provided can be divided into several groups based on what there general function is. These groups are :- Setting Channel Data - DataVox_Type DataVox_Timed DataVox_Pitch DataVox_SetMemory DataVox_SetRepeat DataVox_SetReverse DataVox_UpCallHandler DataVox_SlaveChannel DataVox_AdjustMemory These SWIs are how applications set the DataVox channel settings. Reading Channel Data - DataVox_ReadType DataVox_ReadTimer DataVox_ReadPitch DataVox_ReadMemory DataVox_Repeat DataVox_ReadReverse DataVox_ReadMaster These SWIs are how applications read what the DataVox channel settings currently are. Monitoring Channels - DataVox_ReadAddress DataVox_ReadBufferFlag These SWIs provide the means by which applications can do real time monitoring of the play of data. Reading DataVox Status - DataVox_VoiceActive DataVox_SystemSpeed DataVox_Version These SWIs provide general status information about DataVox. Mulitasking Support - DataVox_AllocateChannel DataVox_DeAllocateChannel DataVox_RequestChannel DataVox_ChannelsFree DataVox_ChannelFreeMap These SWIs provide the multi-tasking support of DataVox for applications and should *always* be used by an application. See the section `Multi- Tasking and DataVox' for more details. Application Support - DataVox_PitchToSample DataVox_SampleToPitch DataVox_Duplicate DataVox_Unset DataVox_ConvertByte DataVox_ConvertArea And these SWIs provide application support to allow an application to make use of the system speed independance of DataVox and to generally make an applications life easier. Okay and that about wraps up all the essential concepts of DataVox. The whole idea of DataVox is to provide a consistant,multi-tasking & highly flexible system of playing sound data on the Arc. Hopefully the information I have given you here and a good reading of what is presented below will allow you to make full use of the power of DataVox. Multi-Tasking and DataVox ========================= This module has a set of four SWI's built into it to allow easy and smooth multitasking use of itself. These SWI's are AllocateChannel, DeAllocateChannel,RequestChannel & ChannelsFree. Three of them require the passing of a `Unique Key' to them. All this is is a 32 bit number of some kind that is used to provide a measure of allocation security. This ,when used wisely, allows an application to claim and use a channel happy in the knowledge that it is the only `official' user of that channel. It is recommended that the task handle number given to an application by the Wimp be used as the key as this will be unique to that particular instantation of the application. Of course if you have good reason not to use the task handle number then any number will suffice. However while an application can be reasonably secure in the knowledge that once it has been allocated a channel it is the only application that will `officially' own it, no such claims can be made on the settings of the channel. This is due to maintaining backwards compatability and problems with channel ownership by loader modules. The consequence of this is that an application must check the settings before each use of the channel. The exact strategy used will vary from application to application. The recommended procedure for applications using DataVox is as follows. For `fixed voice no.' applications :- START | Verify Sufficient channels are free for use. Claim these channels. | Verify channel Settings---+ Use channel | | | +-Loop as required------+ | Deallocate the claimed channels | END For `dynamic voice no.' applications :- START | Verify Sufficient channels are free.--+ Claim these channels | Use said channels | Release these channels | | | +-Loop as required------------------+ | END As can be seen the only major difference between the two application stratageys is when the voices are claimed and released. These minor shifts in place require radically different error handling and coding however as the dynamic voice application can never make any assumptions as to whether sufficient channels will be available for it to use at any given time. Both of these stratageys ensure that the application verifies the channels settings before use thus catering for possible interference with these settings between wimp polls. How often tasks need to verify that their channels are set correctly will vary according to what the task does. Two main strategys spring to mind 1) Check the settings every Wimp_Poll and reset them as needed. 2) Check the settings just before use is made of the channel (And not before). The second strategy is the prefered method as it requires less processor time to maintain. Finally some tasks will need a particular channel to operate properely and so the SWI RequestChannel has been provided. This allows an application to request for a particular channel rather than simply asking for one and getting any random channel back. Again the application will be turned down if they do not own the channel (if it is claimed) so applications must be prepared to cope with this. Other than these guidelines usage of the channel is up to the application involved. Not following these guidlines is not a good idea as this can result in applications `squabbling' over channels with the unpredictable results that can result in. Also in no way will DataVox ensure that the Arc's Sound System has a sufficient number of channels active or that those channels are assigned to it. This is the applications responsibility as the way the Sound System handles channels may be revised in future releases of the OS. This way the module will automatically cope with the new OS... N.B. I am well aware that the security afforded by the key system is ridiculously simple to circumvent. It is not intended to provide a secure system but is merely intended as an aid to tasks to allow them to share the module in a consistent and easy manner. It is unlikely that I will extend the security system to allow security over channel settings, as this will destroy the backwards compatability the module has with old code, unless I receive sufficient comment from people to justify this alteration. OSCLI Commands ============== *DataVoxPitch This sets the fixed pitch of the data being played. Once this is set any sound commands issued to this datachannel will be fixed at this pitch. To return to normal pitching enter 0 as the pitch. Syntax *DataVoxPitch <DataChannel> <-&7FFF-&7FFF>. *DataVoxStatus This shows the status of the DataVox channels and their various parameters. Syntax *DataVoxStatus. *DataVoxTimer This sets whether the Voice Generator ignores the duration parameter of the SOUND command. Enter 0 for no timer control and 1 for timer control. Syntax *DataVoxTimer <DataChannel> <0|1>. *DataVoxType This sets the type of data being played. Enter 0 for Logarithmic (Archimedes native format),1 for Linear Unsigned (Macintosh & IBM), 2 for Linear Signed (Armadeus,Atari St & Amiga) and 3 for Ulaw logarithmic format (Sun). Syntax *DataVoxType <DataChannel> <0|1|2|3>. *DataVoxReverse This sets the direction of play. On (1) for reverse play & Off (0) for normal play. Syntax *DataVoxReverse <DataChannel> <0|1>. *DataVoxDuplicate This copies a DataChannel's settings across to another channel. This allows you to have several channels sharing the same piece of sound data easily. Note it is invalid to try and duplicate to the same channel number. Syntax *DataVoxDuplicate <Source DataChannel> <Destination DataChannel>. *DataVoxUnset This unsets a DataChannel, destroying all settings for that channel. Syntax *DataVoxUnset <DataChannel>. SWI Commands ============ Here is the list of SWI commands provided by the DataVoxPlayer module. It is to be noted that when an error occurs R0 is always corrupted and not preserved as is indicated below. Also if you issue a SWI in the same chunk range as DataVoxPlayer but is an unrecognised SWI the error "Unknown DataVox operation" will be returned. For all of these SWI's the interupt status is unchanged,the processor is in SVC mode and they are not re-entrant. (Well actually some of them are but I haven't sorted out which are yet.) DataVox_Type On Entry:- R0 DataChannel R1 type to set it to On Exit:- R0 preserved R1 preserved Errors:- Bad Settype parameters. Use:- This SWI sets the data type for the DataVox channel passed to it. R1 should be 0 for logarithmic,1 for Linear Unsigned,2 for Linear Signed & 3 for Ulaw logarithmic. The new data typing will take effect at the next sound `start play' command. DataVox_Timed On Entry:- R0 DataChannel R1 On(1)/Off(0) flag On Exit:- R0 preserved R1 preserved Errors:- Bad Timer parameters. Use:- This sets whether the time parameter of a Sound command issued to the DataVox channel will be used or not. A Value of 1 will set it,0 will unset it. DataVox_Pitch On Entry:- R0 DataChannel R1 Pitch On Exit:- R0 preserved R1 preserved Errors:- Bad Pitch parameters. Use:- This sets the fixed pitch of the sound channel. The values accepted are the same as those used by the *SOUND command for pitch, -&7FFF-&7FFF. Passing 0 in R1 turns the fixed pitching off and then the Voice responds to *SOUND commands the same as normal. DataVox_ReadPitch On Entry:- R0 DataChannel On Exit:- R0 preserved R1 Pitch on exit Errors:- Bad Read Pitch Channel. Use:- Not unsurprisingly this reads the pitch value for a channel. A value of zero indicates no fixed pitching,any other value is the fixed pitch. DataVox_ReadTimer On Entry:- R0 DataChannel On Exit:- R0 preserved R1 Timer Setting on exit Errors:- Bad Read Timer Channel. Use:- This returns the setting of the timer flag for a chanel. 0 means no timing and any non zero value indicates that timing will be used. This means that,when set,the timing parameter of *SOUND commands will be used. Otherwise the sound will play until it reaches the end of playable data. DataVox_ReadType On Entry:- R0 DataChannel On Exit:- R0 preserved R1 pitch of channel Errors:- Bad Read Type Channel. Use:- This returns the type of data to be played by a particular channel. A value of 0 indicates Logarithmic data,1 Linear Unsigned and 2 Linear Signed. DataVox_SetMemory On Entry:- R0 DataChannel R1 DataStart R2 DataEnd On Exit:- R0 preserved R1 preserved R2 preserved Errors:- Bad Set Memory parameters. Use:- This sets the chunk of memory that the channel will play. The only check that this call makes is that the memory end pointer is indeed larger than the memory start pointer. This means that any area in RAM can be played . This call also resets the channels type to Logarithmic,timer to off, reverse to off,the repeat section to be all of the sample & to normal (unfixed) pitching. The voice fill code is in a privileged processor mode so *any* memory area can be played (Even the ROM space if you really want... :-) ). You must be careful to ensure that the memory to be played is always 'there' when the voice generator needs it. This means that under the multi tasking Wimp you must not store voice data in application space *unless* you do not call Wimp_Poll until the sound has finished playing. Even then you must ensure that no sound commands will be issued to that channel while your application is paged out. If a sound request is received while the memory is paged out an address exception will occur and the voice generator will halt play in an undefined way. It can range from hanging the machine to merely halting play! Of course if you *really* want to be a smart alec you can point it to physical memory which should always be there...but I don't recommend it as I haven't tried it and thus can't be sure it will work. DataVox_ReadMemory On Entry:- R0 DataChannel On Exit:- R0 preserved R1 Start address of channel. R2 End addresses of channel. Errors:- Bad Read Memory Channel. Use:- This reads the memory start and end address of the specified channel. See DataVox_SetMemory for a more detailed account of what the results mean. DataVox_ReadAddress On Entry:- R0 DataChannel On Exit:- R0 preserved R1 current address. Errors:- Bad Read Address Channel. Use:- This reads the current absolute address that the voice is currently up to. If the voice is not playing at the time the SWI is called it will return an address of zero. Address returned will *always* be between or equal to the voice start address and the voice end address. This SWI is a very useful one for timing programs. By waiting for the address returned to become zero programs can wait till a particular sound sample has played. It must be noted that the update of this address is only at the end of DMA buffer fills and thus will will jump up by the size of the DMA sound buffer instead of byte wise. It is, however, updated at the start of sound play immediately. DataVox_SetRepeat On Entry:- R0 DataChannel R1 Repeat Start address R2 Repeat End address On Exit:- R0,R1,R2 preserved Errors:- Bad Set Repeat Channel. Bad Set Repeat Memory - Start above End. Bad Set Repeat. Voice not active. Use:- This sets the Repeat address for the channel. Repeating occurs only when the timed flag is set and the voice is required to keep playing for longer than its play time by the time paramter sent via the sound command. When a repeat is neccessary play will start from the sections pointed to by these addresses. Note if play is set for reverse then any repeated sections will also be played in reverse. N.B. In an extension over older versions of DataPlay the Set Repeat SWI will no longer require that the addresses passed be inside those set by the Voice Start & End addresses. This is to allow you to perform buffering if you so wish. Read the description of the SWI ReadBufferFlag for more on this topic. DataVox_ReadRepeat On Entry:- R0 DataChannel On Exit:- R0 preserved R1 Repeat Start address R2 Repeat End address Errors:- Bad Read Repeat Channel. Use:- With this SWI you can read the repeat start and end addresses for the specified channel. DataVox_SetReverse On Entry:- R0 DataChannel R1 Bit Flag. 1 for reverse, 0 for normal play. On Exit:- R0,R1 preserved Errors:- Bad Set Reverse Channel. Use:- This sets the voice up to play the sound forwards or backwards. Flipping this quickly will result in the voice changing directions as it plays and it can be used to do `scratch' style sounds. DataVox_ReadReverse On Entry:- R0 DataChannel `On Exit:- R0 preserved R1 Status of reverse flag. Errors:- Bad Read Reverse Channel. Use:- This allows you to read whether a channel has been set to reverse play or not. DataVox_PitchToSample On Entry:- R0 Pitch R1 System Sample speed for pitch On Exit:- R0 Sample speed for pitch R1 preserved Errors:- Bad Pitch to Sample Pitch. Bad Pitch to Sample sample rate. Use:- This converts a pitch, with a given system speed in micro seconds, to a sample rate in micro seconds. When this is then fed to Sample to Pitch it gives you the system speed independance. It must be noted that this is a `lossy' conversion and exact pitching speeds will be lost. However most times the approximation will be so close no discernable difference will be observed. Giving a system speed of zero will cause DataVox to use its copy of what the system speed is. Read the comments on the next SWI for an explanation as to why this is important. DataVox_SampleToPitch On Entry:- R0 Sample Speed (micro seconds) R1 System Speed (mirco seconds) On Exit:- R0 Pitch (-&7FFF - &7FFF) R1 preserved Errors:- Bad Sample Speed. Bad System Speed. Use:- This converts a system speed and sample speed pair into a sound pitch value that will cause the sound to be played correctly at that system speed. The conversion is what gives DataVox its system speed independance. If the system speed is 0 then DataVox will use its own copy of the current system speed. Because DataVox only updates its copy of what the System Speed is everytime a sound is played then it can get very out of sync with what the real system speed is. The upshot of this is that if you use the Sample to Pitch SWI to get the right pitch to feed into DataVox you could end up setting the pitch (correctly for the current system speed) but have DataVox readjust it incorrectly when it recalibrates to adjust to the `new' system speed. So this giving a system speed of zero to this SWI automatically fills in the system speed for you with DataVox's copy of the system speed so that when it comes time to recalibrate DataVox will adjust everything correctly. When wanting to use DataVox's system speed independance it is reccomended that you use this SWI with the System Speed set to zero. Also setting R1 to zero recalibrates DataVox's copy of the System Speed. DataVox_Duplicate On Entry:- R0 Source DataChannel R1 Destination DataChannel On Exit:- R0,R1 preserved Errors:- Bad Duplicate Channel. Silly. Why are you trying to Duplicate to the same channel? Use:- This copies all the settings of one DataChannel to another. This allows you to easily have channels that share the same piece of sampled data without much mucking about. Especially given the fact that this will always copy any new flags/settings I may add in the future. DataVox_Unset On Entry:- R0 DataChannel On Exit:- R0 Preserved Errors:- Bad Unset Channel. Use:- This completely clears and blanks a channel. Upon exit the selected channel will not have any settings at all having returned to the default state. If the channel being unset is playing then play will be terminated. DataVox_ConvertByte On Entry:- R0 Byte to Convert R1 Datatype the byte is. (0,1,2 or 3 as per DataVox_Type) R2 Type to convert the byte to. (0,1,2 or 3 as per DataVox_Type) On Exit:- R0 The Converted Byte R1,R2 preserved Errors:- I can't convert this. It isn't a byte! Bad Convert Byte Source type. Bad Convert Byte Convert to type. Use:- This SWI converts a byte from a particular data type to another type. It is perfectly acceptable to specify identical types in R1 & R2, all that will happen is that you get the same byte back again. Please Note converting between a Logarthimic DataType and a Linear DataType is *lossy*. The converted sound will replay almost identically but it will not convert back to its original form! DataVox_ReadBufferFlag On Entry:- R0 DataChannel to read On Exit:- R0 The Flag in the lowest bit. Errors:- Bad Read Buffer Flag Channel. Use:- Every time the Channel loads the Repeat start and end pointers this flag will be toggled. Once the pointers are loaded they are stored in the Voices SCCB and so can be changed safely so that at next loading of them they can point to a new area. This SWI allows you to follow the loading of these pointers and if you wish to you can do some clever buffering for activities like playing samples from disk or playing compressed samples. *PLEASE NOTE* I make no guarantees that the bit you get back will be set or unset at any particular point in time. What I do guarantee is that the bit will change state as the pointers are loaded. DataVox_AllocateChannel On Entry:- R0 Unique key. On Exit:- R0 DataChannel assigned if succesful, 0 otherwise. Errors:- Bad Allocate Channel Key! Use:- This allows you to request a channel from DataVox that is free. If there are no free channels then 0 is returned. No assumptions can be made about which channel will be handed back as this will vary from moment to moment depending on how many other applications are using the module. Also DataVox will not ensure that the channel is active or assigned to itself by the Sound System of the Arc. That is comp- letely the applications responsibility as there are too many variables for this module to cater for in a tidy fashion. The Unique key is the key needed to DeAllocate or Request this channel again. This key is needed to do the deallocate or request simply to allow the application that has been allocated the channel the knowledge that it is, as far as DataVox is concerned, the only owner of that channel. It also prevents careless applications from deallocating another applications channel. This is crucial to the safe multi-tasking of this module as it provides a measure of security allowing an application to know for sure that it can do what it likes with the settings of a particular channel and not upset any other application's use of the module. Of course, due to other considerations, there is nothing to stop a badly programmed application from just using the SWI's to re-assign the other channels as it wishes so tasks *must* ensure their channel is set correctly before use. Whether this requires constant monitoring or simply checking just before use is application dependant. Due to problems of the ownership of channels by loading modules and maintaining backwards compatability this `hole' (More like a subway tunnel!) in channel security will *not* be fixed. DataVox_DeAllocateChannel On Entry:- R0 DataChannel to free R1 Unique key to channel On Exit:- R0 preserved R1 preserved Errors:- Bad DeAllocate Channel Channel. Bad DeAllocate Channel Key! Use:- This SWI will return, if the passed key is correct, the designated channel back to the free 'pool' of channels in DataVox allowing another application the chance to use it. This SWI will not disrupt the settings of the channel allowing applications to 'trade' channels if they so desire. Of course any such scheme must *not* rely totally on getting the channel and have code to cope with this contingency. DataVox_RequestChannel On Entry:- R0 DataChannel desired R1 Unique key for it On Exit:- R0 0 if request denied else preserved R1 preserved Errors:- Bad Request Channel Channel! Use:- If an application simply must have a particular channel then it can request for it. If the channel is free then the SWI will hand back the channel number and mark the channel as allocated with the key passed. If the channel is already allocated but the key passed matches the key given then the channel is handed back as DataVox considers that the application requesting it already `owns' it. Otherwise the request is denied by the SWI handing back a 0 as the channel. It is expected that applications be nice and actually respect this denial. DataVox_ChannelsFree On Entry:- R0 Undefined R1 Undefined On Exit:- R0 Number of unallocated channels available. R1 Number of allocated channels. Errors:- None Use:- What can be said about this one that isn't obvious? This returns the total number of free channels for use and the total number in use. DataVox_ConvertArea On Entry:- R0 Start Address R1 End Address R2 Datatype the byte is. (0,1,2 or 3 as per DataVox_Type) R3 Type to convert the byte to. (0,1,2 or 3 as per DataVox_Type) OR an address to a 256 byte lookup table. On Exit:- R0-R3 preserved Errors:- Your Start Address is below your End Address for conversion. Bad Convert Area Type. Bad Type to Convert Area to! Use:- This functions like Convert Byte only instead of converting a Byte it converts a chunk of memory at a go. This will be much faster then doing a byte by byte conversion of the area in your own code as it will not have to go through the high overhead that a SWI call entails for every byte. If you specify an address in R3 then the type in R2 is ignored and it is assumed that the lookup table is adjusted to cope with the datatype being converted. Please note R2 in this mode may be used at a later date by this code for a special meaning and should be by default set to zero in this conversion mode. The same comments about conversion restrictions in ConvertByte apply here. DataVox_ChannelFreeMap On Entry:- R0 undefined On Exit:- R0 Bitmap of the free channels. Errors:- None Use:- This SWI returns a bitmap of the free channels. If the bit is set then the channel is allocated else it is free. Bit Zero applies to channel 1, Bit One applies to channel 2 etc... I provided this SWI a) because I needed it for one of my applications, b) to allow an application to easily monitor the free channels & c) I realised that I had not provided any way of non-destructively querying whether a channel is free or not. As there are currently only 8 channels supported by the VIDC then only the low eight bits will hold meaningful values. However the higher bits are by default cleared and no assumptions about their state should be made in case a future machine is released with more sound channels supported. As an aside you can easily find out the total number of channels available by calling this SWI counting the number of bits set and the querying the number of channels free and totalling the two results. Of course it is far simpler to simply total the two registers passed back by ChannelsFree SWI. I consider it unlikely that more than 32 channels will ever be supported by future hardware I just hope Acorn don't take this as a challenge and provide more than 32 channels! :-) DataVox_UpCallHandler On Entry:- R0 DataChannel desired R1 Address (absolute) or the routine to be called.(0 to deinstall a handler) R2 Private word to be passed to the routine. On Exit:- R0 preserved R1 preserved R2 preserved Errors:- Bad UpCall Handler Channel! Use:- This SWI provides a means by which special code can be added to DataVox to allow precise control over the order in which sample buffers are played. The code is called under two circumstances - when a sound is started and when a buffer has been finished. Your code is expected to be :- a) FAST. Speed is *very* critical in this routine. Your code will called in IRQ mode with interupts shut off and so must be as fast as is possible to avoid problems. b) always terminate. There must be absolutely no way in which your code cannot terminate. If your code does fail to terminate then your machine will lock up! You have been warned... c) well behaved. Your code is being given access to the internal tables of DataVox and care must be taken not to damage any other channels table entries. Do *NOT* attempt to access any of the other channels data as this could cause your machine to crash. d) terminate cleanly. It is expected that your code generally obey the normal restrictions placed on interupt routines. Whatever you do do *not* turn interupts back on or exit back to DataVox in a processor mode different from that which DataVox called you in. The code calling mechanism is as follows. On Entry:- R0 reason for calling. (0-2 primary reason codes.) R1 pointer to word for the start of buffer address. R2 pointer to word for the end of buffer address. R3 channel number you are being called for. (0-7) R4 the private word passed to DataVox at installation. R5 pointer to the phase accumulator word used by the fill code. R6 #0 (Reason code 0 is an exception to this) R14 return address. On Exit:- R0 Return Code. (0 or 1) Registers R0-R6 can be corrupted and R14 contains the return address. The addresses passed in R1 & R2 are the addresses at which DataVox will *next* load the start & end addresses of the next buffer to be played. The passing of the channel number allows one chunk of code to handle mulitple channels simultaneously and accordingly your code must be re-entrant to handle this. (ie. keep your workspace seperate for each channel.) The private word passed in R4 is what you handed to DataVox when you installed the handler. This cannot be updated by any other means than reinstalling the handler. It is intended that routines put into modules use this word to point to their workspace... R5 is the phase pitch accumulator used by DataVox in fixed pitch play. Altering this word allows the UpCall code to alter the speed of sample play. The data format is that returned by the SWI "Sound_Pitch". IE a fixed point 32 bit number with an 8 bit integer and 24 bits fractional data. The reason code passed gives you an indication of why your code is being called. Code 0 indicates a start of sound synthesis/play. It is expected that your code set itself to appropriate default values upon receiving this call. Also in this reason code call *alone* R6 is loaded with DataVox's copy of what the system speed in micro seconds is. It is expected that UpCall code use this to decide if certain pitch tables need recalibrating for the system speed. Code 1 indicates a normal play call. Under a reason 1 call the return code has effect allowing the upcalled code control over when play will halt. Returning a value of 1 indicates to DataVox that it should play another buffer. Returning 0 indicates an immediate stop in play. Code 2 indicates that a timed play is underway. In this mode DataVox will ignore the return code completely as it has control over when the sound play will halt. It is still valid to pass a return code back though (It just isn't used thats all....). In this mode looping from the start may be neccessary and your code should have some method of coping with this. Of course not altering the start & end addresses simply means the last buffer played will be played again.... These three codes constitute the primary fill reason codes. All of these routines are *highly* speed critical and should not waste any time at all if possible! However the next few reasons codes are called in circumstances where speed is not so critical. Longer and more complex routines can be attempted here but again CallBack code writers should not waste time needlessly. Code 3 this is the system speed recalibration code. Your callback code will be called when DataVox detects a need to recalibrate the system speed and gives your code a chance to do likewise. It is expected that UpCall code will use this entry to recalibrate any internal pitch tables they have to the new system speed. It is also expected that the code will adjust the phase accumulator word and DataVox will *assume* that the UpCall code will keep it correctly calibrated for the current system speed. Registers:- R0 #3 R1 Old System Speed in micro seconds. R2 New System Speed in micro seconds. R3 Channel number (0-7) being recalibrated. R4 Private UpCall Data Word. R5 pointer to the phase accumulator word used by the fill code. R6 #0 R14 return address. No return code is expected and any returned will be ignored. Code 4 this is the channel assignment entry code. DataVox is informing your code of the fact that another DataVox channel has been assigned to this code. It is expected that the code prepares itself in whatever ways are needed to play the new channel. Registers:- R0 #4 R1 pointer to word for the start of buffer address. R2 pointer to word for the end of buffer address. R3 System Speed in micro seconds. R4 the private word passed to DataVox at installation. R5 pointer to the phase accumulator word used by the fill code. R6 #0 R14 return address. Code 5 DataVox is requesting that you return in R1 the sequence data the upcall code is currently at. Obviously this is highly dependant on how your Upcall code is organised but should usually consist of the sequence number your code is up to. It is perfectly valid for UpCall code to ignore this call in which case an Automatic default will be assumed. If you are ignoring it then do not corrupt the registers at all. On Entry:- R0 #5 R1 channel number (0-7) R2 #0 R3 #0 R4 #0 R5 #0 R6 #0 R14 return address. On Exit:- R1 UpCall pause data. Code 6 Here DataVox is instructing the UpCall code to commence play from a specified point, passed in R1. It is expected that the UpCall code will restart play from the information passed to it. If the information is invalid it is fine for the UpCall code to ignore it and simply play as normal. The pause data should only have effect at the *next* start of sound play and should then be discarded. On Entry:- R0 #6 R1 channel number (0-7) R2 UpCall pause word returned by reason code 5. R3 #0 R4 #0 R5 #0 R6 #0 R14 return address Your code should simply ignore any reason codes it doesn't understand and return back to DataVox doing nothing. If your code encounters an error it should simply unstack itself and exit cleanly rather than try to report an error. Any such attempts *will* fail.Also your code, if it is to be used in the Desktop, must always be paged in for DataVox to access. This means either that it must be stored in the RMA or that it only ever gets called while your application is currently paged in. And that about covers it. Please be very careful with this SWI as the potential for trouble with it is very high. DataVox_FlushKeys On Entry:- No parameters required. On Exit:- All registers preserved Errors:- none Use:- This SWI causes DataVox to DeAllocate all channels. This is a highly antisocial SWI and is provided only for development work. All finished applications should be tidy and be deallocating all their channels themselves anyway. However when developing new software channels can be left allocated causing DataVox to refuse to be killed. This means you have to hard reset your machine to get rid of it - very annoying. Under no circumstances should non-development code *ever* use this SWI. Use of this SWI totally destroys the multi-tasking coherency of DataVox and I will get extremely sad at code that does use it... DataVox_VoiceActive On Entry:- R0 0 to read 1 to read and set sound system. On Exit:- R0 Minimum number of sound channels needed active for DataVox. Errors:- none Use:- This SWI is provided to allow applications to keep the sound system at its minimum DMA level needed to support all assigned DataVox channels. If R0 is set to 1 on entry then not just will the minimum number be returned but DataVox will reconfigure the sound system to ensure the required number of voices is active. Please note it will *not* assign these channels to the DataVox voice - merely ensure that they are active for the application(s) to use. Applications that wish to be `social' should use this SWI to determine how many channels are needed and then query the sound system to see if sufficient channels are active already. If there are sufficient channels active then it should not alter the setting... DataVox_SystemSpeed On Entry:- R0 undefined On Exit:- R0 DataVox's copy of the system speed. Errors:- none Use:- The SWI returns to you DataVox's copy of what the system speed current- ly is. This is important because DataVox can be out of sync with what the system speed really is and an application needs to calculate some- thing like duration of play. This also will trigger a recalibration if one is needed. DataVox_Version On Entry:- R0 undefined On Exit:- R0 Version number of DataVox * 100. Errors:- none Use:- This SWI is for informational purposes to allow applications to determine what facilities are available from DataVox. This allows well written applications to be able to use old versions of DataVox and only allow/use the extended features of new versions of DataVox if they are available. DataVox_SlaveChannel On Entry:- R0 Channel to be slaved. R1 Channel it is to be slaved to. On Exit:- R0,R1 preserved. Errors:- You can't slave the same channel to itself. Bad channel number to slave. Bad channel number to be slaved to. You cannot have a slaved channel as a master channel! Use:- This allows you to link channels together. Please note the master channel is not allowed to be slaved to another channel to prevent circular list problems. Please note you should not slave any channels you have not claimed using DataVox_AllocateChannel or RequestChannel! Please note due to the fact that the linking code is executed by callback there will be a delay between channels linked. If you do not want this delay then it is expected that you will drive the channels yourself in unlinked mode. This linking is purely for wimp applications and command line users to use in non critical sound applications. (Like playing back their favourite stereo beeps...Something I am rather partial to.) DataVox_ReadMaster On Entry:- R0 Channel to read. On Exit:- R0 Master of this channel. 0 for no master. Errors:- Bad channel to read the master of! Use:- This reads the channels master and reports it back to you. It is purely for informational purposes. DataVox_ReadUpCallStatus On Entry:- R0 Channel to read. On Exit:- R0 The UpCall status/pause word as returned. Errors:- Bad channel number to read. No UpCall code to interrogate! Use:- This issues a type 5 reason code call to the UpCall code on the specified channel. If there is no UpCall code on the channel then the routine will error and R0 will be in an undefined state. Please note it is the UpCall code's choice as to whether to ignore this reason code or not so the results returned are subject to what kind of UpCall code is present. DataVox_SetUpCallStatus On Entry:- R0 Channel to affect. R1 UpCall status/pause word to write. On Exit:- Registers preserved. Errors:- Bad channel number to set. No UpCall code to call! Use:- Basically the opposite of a ReadUpCallStatus call this issues a type 6 reason code call to the UpCall code on the specified channel. Again it is at the UpCall codes discretion to acknowledge this call or not. DataVox_AdjustMemory On Entry:- R0 DataChannel R1 DataStart R2 DataEnd On Exit:- R0 preserved R1 preserved R2 preserved Errors:- Bad Adjust Memory parameters. Use:- This functions in an identical manner to SetMemory. However it does not reset the datatype, reverse, pitch, upcall code or any of the other myriad settings bar that of the Repeat start and end addresses. It is intended that this be useful for sound players that can addresses frequently. DataVox_SetInternalPitch On Entry:- R0 DataChannel R1 32 bit fractional step. On Exit:- R0 preserved R1 preserved Errors:- Bad Set Internal Pitch parameters. Use:- This SWI allows the user to fine tune the sample replay stepping rate. It only has effect when the fixed pitching mode is active and is superceded by any SetMemory or SetPitch commands. The number passed in R1 should be treated as 32 bit fixed point number comprising 8 bits integer, 24 bits fractional numeric representation. Use of this SWI is depreciated but may be necessary under extreme circumstances, I would prefer applications to go through SetPitch wherever possible. SWI Chunk numbering =================== Here is the table of DataVox's SWI chunk numbers on SWI names. Of course all names need to be preceded with `DataVox_' and the chunk range number is :- &44380 Chunk # | SWI name --------+------------------ 0 | Type 1 | Timed 2 | Pitch 3 | ReadPitch 4 | ReadTimer 5 | ReadType 6 | SetMemory 7 | ReadMemory 8 | ReadAddress 9 | SetRepeat 10 | ReadRepeat 11 | SetReverse 12 | ReadReverse 13 | PitchToSample 14 | SampleToPitch 15 | Duplicate 16 | Unset 17 | ConvertByte 18 | ReadBufferFlag 19 | AllocateChannel 20 | DeAllocateChannel 21 | RequestChannel 22 | ChannelsFree 23 | ConvertArea 24 | ChannelFreeMap 25 | UpCallHandler 26 | FlushKeys 27 | VoiceActive 28 | SystemSpeed 29 | Version 30 | SlaveChannel 31 | ReadMaster 32 | ReadUpCallStatus 33 | SetUpCallStatus 34 | AdjustMemory 35 | SetInternalPitch Error Messages ============== The Error range begins at &806100, ends at &80613F, and here is the error message list. Error # | Error Message --------+------------------------------------------------------------- 0 | DataVox is still being used! 1 | Unknown DataVox operation 2 | Bad Address Channel. 3 | Bad Timer parameters. 4 | Bad Reverse parameters. 5 | Bad Settype parameters. 6 | Bad Set Memory parameters. 7 | Bad Set Repeat Channel. 8 | Bad Set Repeat Memory - Start above End. 9 | Bad Set Repeat. Voice not active. 10 | Bad Read Pitch Channel. 11 | Bad Read Timer Channel. 12 | Bad Read Reverse Channel. 13 | Bad Read Type Channel. 14 | Bad Pitch parameters. 15 | Bad Read Memory Channel. 16 | Bad Pitch to Sample Pitch. 17 | Bad Pitch to Sample sample rate. 18 | Bad Sample Speed. 19 | Bad System Speed. 20 | Bad Duplicate Channel. 21 | Silly. Why are you trying to Duplicate to the same channel? 22 | Bad Unset Channel. 24 | I can't convert this. It isn't a byte! 25 | Bad Convert Byte Source type. 26 | Bad Convert Byte Convert to type. 27 | Bad Read Buffer Flag Channel. 28 | Bad DeAllocate Channel Channel. 29 | Bad DeAllocate Channel Key! 30 | Bad Request Channel Channel! 31 | Your Start Address is above your End Address for conversion. 32 | Bad Convert Area Type. 33 | Bad Type to Convert Area to! 34 | Bad UpCall Handler Channel! 35 | Bad Allocate Channel Key! 36 | Bad Request Channel Key! 37 | You can't slave the same channel to itself. 38 | Bad channel number to slave. 39 | Bad channel number to be slaved to. 40 | You cannot have a slaved channel as a master channel! 41 | Bad channel to read the master of! 42 | Bad channel number to read. 43 | No Upcall code to interrogate! 44 | Bad channel number to set. 45 | No UpCall code to call! 46 | Bad Adjust Memory parameters. Version History ========================================================================= |Version | Comments. | ========================================================================= | 1.00 | The first DataVox Module that supported only one file,timing | | | and data types. Released into the Public Domain. | | | (07-Nov-1990) | | 2.00 | Major re-write of code. Now it only plays chunks of memory | | | and doesn't handle the loading of the data. (15-Jan-1991) | | 2.01 - | Expanded support to handle eight independant channels from | | 2.05 | the one voice slot. Added the incidental code to control | | | this new feature. Tidied up the Voice Code too! | | | (16-Jan-1991 - 01-Feb-1991) | | 2.06 | Added the DataVoxStatus feature to show all the channels | | | status. (02-Feb-1991) | | 2.07 | Added the code to handle fixed pitch playing! Now all sounds | | | issued from the channel can be forced to play at a preset | | | pitch. This in particular allows voices to be slaved to | | | beep channel and for them to play correctly rather than | | | at a too fast rate. (03-Feb-1991) | | 2.08 | Optimised the buffer fill code and corrected for a possible | | | error to do with buffer exit fills. I suspect that I had | | | made a small error in the flush code that resulted in the | | | voice continuing to 'fill' the DMA buffer after the sound | | | data had finished but filling it with 0's,thus resulting | | | in no noise but heavy interupt overheads when there should | | | not have been... (24-Mar-1991) | | 2.09 | Added the DataVox_ReadAddress SWI at the request of Jason | | | Williams. And saved on 28 bytes of size due to duplicated | | | storage space that wasn't neccessary. (08-Jun-1991) | | 2.10 | Corrected the timer flag algorithm to allow for repeated play| | | of a sample up to the time limit specified. (19-Aug-1991) | | 2.11 | Allowed the addition of repeated play blocks. This allows | | | samples to have a lead in and then a long repeated section | | | if so desired. Useful for coding music players. | | | (19-Aug-1991) | | 2.12 | Added reverse play code! Now you can play your samples either| | | way! The repeat loops even will be played in reverse. | | | (20-Aug-1991) | | 3.00 | Finally got the errors, with Julians help, out of the system | | | speed independance code. Now you can screw with the system | | | speed (Yuck!) and it will attempt to play the sample at the| | | right pitch. (26-Aug-1991) | | 3.01 | Fixed a minor error in the Reverse play code. Now it reverses| | | properly if the sound is already playing. (28-Aug-1991) | | 3.02 | Added the Unset and Duplicate code. Now you can very simply | | | clear and copy the settings of any channel. (28-Aug-1991) | | 3.03 | Fixed an Underflow/Overflow error with the conversion SWI's. | | | now only sensible values can be returned by it. Before | | | values large and smaller than possible pitches were being | | | returned. (28-Aug-1991) | | 3.04 | Fixed an embarrising error in the `DataVox_SampleToPitch' | | | SWI.. guess who got a compare the wrong way round... | | | One of these days I guess I will just have to learn how to | | | code in assembler. :-). (28-Aug-1991) | | 3.05 | Removed an unnecessary SWI and upgraded two other SWI's to | | | take its place. (29-Aug-1991) | | 3.06 | Fixed a bug in the smooth update code :- There wasn't any! | | | This caused problems in the usage of volumes from &180 to | | | &1FF. (29-Aug-1991) | | 3.07 | Fixed a bug in the Set Repeat Code. (31-Aug-1991) | | 3.08 | Fixed a minor bug in the Set Pitch Code. It wasn't clearing | | | the sample rate table. Not harmful just untidy. | | | (31-Aug-1991) | | 3.09 | Added the ConvertByte SWI. My thanks to Edourard Poor & | | | Julian Wright for the algorithm for converting Logarithmic | | | to Linear samples. (01-Sep-1991) | | 3.10 | Extended the SetRepeat SWI to allow for clever buffering | | | tricks and added the ReadBufferFlag SWI to help with this. | | | (08-Sep-1991) | | 3.11 | Added the extra SWI's for multitasking support. This now | | | allows applications to `share' DataVox in a consistant | | | way. (14-Sep-1991) | | 3.12 | Added the ConvertArea SWI to allow fast Sample conversion | | | when needed. (03-Oct-1991) | | 3.13 | Added the ChannelFreeMap SWI to allow better channel | | | allocation monitoring by tasks. (11-Oct-1991) | | 3.14 | Adjusted the Type SWI to only have effect at the next start | | | of play buffer fill. This cures a few problems with file | | | overlay code... (12-Oct-1991) | | 3.15 | Added the UpCallHandler SWI. This now allows code quite fine | | | control over how sounds are played in DataVox. | | | (15-Oct-1991) | | 3.16 | Altered DataVox so that it now refuses to be killed till all | | | tasks using it have DeAllocated themselves. (15-Oct-1991) | | 3.17 | Extended the kill system to allow the module to be RMTidied | | | while tasks are using it while still remembering all the | | | data. (16-Oct-1991) | | 3.18 | Added the FlushKeys SWI for developers to use. This has | | | become rather neccessary when DataVox refuses to die until | | | all channels are deallocated. (16-Oct-1991) | | 3.19 | I quad word aligned the voice code to try and keep the IRQ | | | load down as much as possible. DataVox does tend to suck | | | bandwidth a bit... (17-Oct-1991) | | 3.20 | Further optimisations in the Fill code to keep the IRQ load | | | down. (17-Oct-1991) | | 3.21 | Fine tuning optimisation in the Fill code. Now the worst case| | | fill loop is five instructions per byte with the best case | | | four instructions per byte. This is about all the optimis- | | | ation I can make in the Fill code loop itself. | | | (17-Oct-1991) | | 3.22 | Extended the UpCall SWI to provide support for modules via | | | a private word. (17-Oct-1991) | | 3.23 | Extended the ChannelsFree SWI to be slightly more detailed. | | | (18-Oct-1991) | | 3.24 | Extended the UpCall to pass the internal phase accumulator | | | used by the fill code. (19-Oct-1991) | | 3.25 | Extended the Convert Area SWI to allow user defined lookup | | | conversion tables. (25-Oct-1991) | | 3.26 | Added the VoiceActive SWI to allow applications to ensure the| | | sound system is sufficiently active to support all DataVox | | | assigned voices. (02-Nov-1991) | | 3.27 | Added two very small SWI's that allow a little more status | | | reading of DataVox :- Version & SystemSpeed SWIs. | | | (03-Nov-1991) | | 3.28 | Corrected the Fill code to cope with timed play buffer sizes | | | smaller than the DMA buffer size. (03-Nov-1991) | | 3.29 | Extended the Reason 0 (Init) UpCall code to load R6 with the | | | system sample speed. (04-Nov-1991) | | 3.30 | We have now acheived *full* system speed independance! Now | | | the sound will adjust *with* the system if someone changes | | | it! (13-Nov-1991) | | 3.31 | Mu Law datatype play has been added giving a fourth type that| | | DataVox understands. Now if only I had a sample or two to | | | test these routines out on.... (14-Nov-1991) | | 3.32 | Added a small bit to the pitch recalculation routines to help| | | prevent it being used when it is an undefined state. This | | | should help with interupt usage of DataVox.... | | | (14-Nov-1991) | | 3.33 | Fixed the recalibration code to prevent it being called with | | | invalid speeds and thus corrupting the pitch tables.... | | | (15-Nov-1991) | | 3.34 | Corrected the Conversion code so conversion to and from Mulaw| | | now works properly. (16-Nov-1991) | | 3.35 | Added the SlaveChannel SWI and corrected a bug in the Reverse| | | SWI's code. (17-Nov-1991) | | 3.36 | Fixed the Slaving code to work and updated the DataVoxStatus | | | command to cope with it. Added the ReadMaster SWI to allow | | | apps to monitor/control the slaving. (18-Nov-1991) | | 3.37 | Fixed the VoiceActive SWI to correct a very embarrising | | | error with it... It now works properly! (23-Nov-1991) | | 3.38 | Adjusted the SampleToPitch SWI to recalibrate DataVox's | | | idea of what the system speed is if R1 is 0 on Entry. | | | (27-Nov-1991) | | 3.39 | Fixed the Unset SWI to halt play if the channel being unset | | | is playing at the time of being unset. (29-Nov-1991) | | 3.40 | Corrected a couple of errors in the unset code introduced in | | | version 3.39. (1-Dec-1991) | | 3.41 | Added two new reason codes to the UpCall system in prepera- | | | tion for a standard UpCall file format. (12-Dec-1991) | | 3.42 | Altered the fill code to fill in a byte wise fashion. This | | | should considerably improve repeating play performance. | | | (15-Dec-1991) | | 3.43 | Corrected a few minor errors in a data-table and corrected an| | | error in the style of coding in error reporting...which | | | saved some 200 bytes of space.... (16-Dec-1991) | | 3.44 | Fixed errors in the newer Upcall code sections. (13-Jan-1992)| | 3.45 | 'Fixed' an error in the Upcall code system introduced in | | | v3.42. However I am not happy with the fix as the code it | | | 'fixes' should work.... (16-Jan-1992) | | 3.46 | Corrected the Current Address routines to set the address up | | | at the start of sound play without waiting a DMA buffer | | | fill. (20-Jan-1992) | | 3.47 | Corrected an error in the Unset SWI routine that could have | | | caused trouble.... Also modified it to not call its own SWI| | | routines via a SWI call but via a BL. This should improve | | | its speed slightly. (2-Feb-1992) | | 3.48 | Various bug fixes to the UpCall code section. All now appears| | | to work as it should. (13-Feb-1992) | | 3.49 | Fixed a bug introduced by the UpCall code bug fixes.... Added| | | an upcall `pause` facility... (26-Feb-1992) | | 3.50 | Received the SWI, Error and Message chunk allocations and | | | coded them in. (18-Apr-1992) | | 3.51 | Fixed ConvertArea to full functionality. (14-Jun-1992) | | 3.52 | Fixed the dynamic system speed recalibration to working order| | | after the additions made in v3.15 broke it... (Dang!) | | | (28-Sep-1992) | | 3.53 | Added to verify that DataVox is installed as a voice when | | | AllocateChannel or RequestChannel is called. (09-Oct-1992) | | 3.54 | Added the AdjustMemory SWI with associated error message. | | | Minor change to the Repeating pitch refresh. Major | | | revamp of the play code to reduce bandwidth consumed by one| | | third. Also the play code now can stop and start on byte | | | boundaries rather than word boundaries.(02-Nov-1992) | | 3.55 | Added the SetInternalPitch SWI to allow for cases where | | | extremely fine control of the replay rate is needed. Fixed | | | smooth update to not generate clicks when there is nothing | | | playing to update. Removed a redundant error message. | | | Altered SampleToPitch to return negative pitches as needed.| | | SystemSpeed now recalibrates if needed. The internal fill | | | code now uses 32bit fixed point values for sample replay | | | improving the dynamic range coverage considerably. | | | This version may break some early upcall code. Fixed the | | | smooth update code to behave properly with respect to | | | updating the pitch.(08-Nov-1992) | | 3.56 | Fixed the pitching commands to now accept pitches in the | | | range -&7fff to &7fff. (26-Nov-1992) | | 3.57 | Fixed the Current Address update bug. (17-Apr-1993) | | 3.58 | Fixed an error in the BufferFlag updating. Correction to | | | buffer reloading code. (05-Jul-1993) | | 3.59 | Optimisations to the internal fill code. (2-Aug-1993) | | 3.60 | Corrections to the Fill stopping code to prevent sample | | | overflow. (7-Aug-1993) | | 3.61 | Adjusted the repeating code to clear the phase accumulator. | | | Corrected the fill code to correctly keep the phase | | | accumulator across buffer fills. Altered the fill code to | | | hopefully finally cure the overrun problem. A nice side | | | effect is that CPU loading is now lowered somewhat. | | | (12-Sep-1993) | | 3.62 | Altered the fill code to reduce the size of it at the cost | | | of one extra S cycle instruction. This allows a much | | | unrolling of the loop allowing up to 64 bytes of the DMA | | | buffer to be filled per loop pass. (compared to 16 bytes | | | with previous versions) A major side effect of which is | | | is further reduced CPU loading. (13-Sep-1993) | | 3.63 | Fixed minor error with reverse code. (18-Oct-1993) | | 3.64 | Corrected a few SWIs to return flags settings like they | | | should. (14-Dec-1993) | | 3.65 | Altered the GateOff code to return correct status bits. | | | Altered the fill code to remove a register stacking - minor| | | efficiency stuff. (02-Jan-1994) | =========================================================================