WO1997020297A1 - Computer based karaoke system - Google Patents

Abstract

A computer based audio/video playback system (100) stores compressed audio, compressed video, and text information in a computer accessible memory (310). The system (100) includes a central server (110) which has access to all of the songs stored in the memory (310), while local servers (120) in communication with the central server (110) are used to decompress the compressed audio and video information for playback to a karaoke customer (425) over speakers (470) and a video display screen (440). In one embodiment, a custom designed user input device (140) is used to manage the input of song selections by the user (425).

Description

COMPUTER BASED KARAOKE SYSTEM

Background Of The Invention Field Of The Invention

The present invention relates to karaoke entertainment systems. Description Of The Related Art

Karaoke is a form of entertainment which has gained wide popularity in recent years. A karaoke system provides background music, microphones, amplifiers, and voice enhancement circuitry which allow a customer to sing to music of his or her choice. Some of the more advanced karaoke systems also provide a video clip which is shown on a TV set or video screen and which is appropriate to the song being played while displaying the words to the song on the screen.

Karaoke systems are commonly found at restaurants, bars, fashion malls, and other public places so that amateur singers are given an opportunity to sing their favorite songs in a public setting Typically, a library of video discs is provided for selection by the customer so that the customer is able to select his or her favorite music together with the appropriate video and words displayed on the display screen. A recent development in the karaoke entertainment business has been the provision of karaoke boxes. A box is a commercial space, usually provided in a shopping center, that has rooms rented by the hour Each room provides karaoke services.

There are two basic ways in which the karaoke services are provided within the rooms. One method employs an autochaπger system, while the other method uses a karaoke jockey (sometimes referred to as "KJ"). An autochanger is a machine that stores a number of laser discs (e.g., 72 laser discs wherein each disc has 28 songs) and automatically plays a selected song from one of the stored discs. Typically, the user inputs a code through a remote control unit and the machine plays the background music and the video for the customer in the selecting box In a karaoke |ockey system, the song is ordered through a telephone intercom and a person (usually in another room) finds the appropriate disc and manually loads it into a video disc player. Both types of systems usually employ microphones and amplifiers with reverberation and other special features for voice enhancement.

Present karaoke systems still have a number of significant limitations. For example, with the increasing number of popular songs, both old and new, it is becoming increasingly unlikely that the particular songs offered for selection in a present karaoke system will satisfy the needs of all karaoke customers Furthermore, when there are a number of boxes to be serviced by an autochaπger, the cost of such a system becomes increasingly expensive, since each box typically contains its own autochanger. In the event that a karaoke jockey is used, more than one jockey may be necessary for a multiple box system. Furthermore, when new songs need to be added, additional laser discs must be bought for each box in present systems.

Summary of the Invention According to the teachings of the present invention, a computer based karaoke system includes a hard disc array which stores digitized and compressed audio and video data which is transferred from a laser disc system Furthermore, the digitized audio and video information is divided into segments, wherein each segment represents a song and corresponding video to be played. Each song is assigned a number which a customer may key in via a hand-held remote control unit. An in-room receiver picks up and transmits the order to a client (i.e., a networked computer workstation), the client then opens up a file on the server (i.e., the central computer system) and reads a compressed, digitized audio and video data file. A decompression chip in the client decompresses the audio and video data and converts the data to analog waveforms to be played through the speakers and displayed over the video screen within the box.

According to a further aspect, the hard disc storage also has database management system tied to a publishing type software to produce accurate song books.

Brief Description of the Drawings Figure 1 is a system overview which depicts a schematic block diagram of the computer based karaoke system of the present invention.

Figure 2 is a schematic overview which shows the connections of a local area network used to implement the computer based karaoke system of the present invention.

Figure 3 is a schematic block diagram which details the main structural and functional elements of the video file servers depicted in Figures 1 and 2.

Figure 4 is a schematic block diagram which shows the main structural and functional elements of the video client stations shown in Figures 1 and 2.

Figures 5A and 5B are a detailed overall system block diagram showing each of the main elements of the computer based karaoke system of the present invention. Figure 5C illustrates an encoding station constructed in accordance with one preferred embodiment of the invention.

Figure 6 is a simplified block diagram showing the main elements of the customer input unit of Figures 1, 4 and 5A.

Figures 7A and 7B illustrate flow charts which detail the general method for managing communication between the customer input unit and the client server of Figures 1 , 4 and 5A.

Detailed Description of the Invention Figure 1 is a schematic system overview of the computer based karaoke system 100 of the present invention. The system 100 includes a central digital karaoke server 110. The central server 110 communicates with a plurality of digital karaoke subsystems or "clients" 120 via high speed data network links (e.g., an ETHERNET datalink) 130. As shown in Figure 1, each of the digital karaoke client subsystems 120 connects to respective user input and control units 140 via respective serial control lines 150. The user control input unit 140 is depicted in greater detail below with reference to Figure 6. In addition, each client server 120 communicates with a respective audio/video output terminal 160 via a respective audio cable 162 and a respective video line 164.

In general operation, a customer within a karaoke box selects a song from a list which may be printed on a sheet, or which may be displayed as a menu on a video screen within the audio/video output terminal 160. The songs are advantageously listed by artist or title, or both. The customer then inputs a song selection via one of the user control input devices 140. For example, a user may use a hand-held remote control which forms part of the customer input unit 140 in one embodiment to seiect from the list of possible song selections. Each song advantageously has an associated number which the customer enters to select the corresponding song and video. The song selection is transmitted to the digital karaoke client 120 via the serial connection 150. In one advantageous embodiment, the serial connection 150 comprises an RS-232 serial cable with appropriate interfaces in the client 120 and input unit 140. The requested song is then opened on the central server and the contents (encoded video/audio data (e.g., compressed data)) are transmitted over a high speed ETHERNET datalink 130, and then decoded in real-time by the client 120 for playback through a speaker and video monitor (see Figure 5A) within the audio/video output terminal 160. While the music and video are being played for the customer, the customer sings the lyrics to the accompanying music into a microphone (not shown specifically in Figure 1 , but forming part of the input unit 140), or the like. The customer's voice is enhanced, mixed with the music, and output via speakers to produce a professional sounding rendition of the song with the customer as the "artist." In some systems, the songs sung by the customer are recorded on a cassette tape, or the like, for the customer's future enjoyment. Therefore, by means of the present invention, a customer sings along with the selected music, originally stored in memory as digital data, together with the displayed video and lyrics, by means of a microphone and amplifier which are also tied into the speaker system.

Figure 2 is a schematic block diagram which shows a general overview of a local area network which is advantageously used to implement the computer based karaoke system of the present invention. As shown in Figure 2, audio/video server 110 connects with a plurality of hubs 220 via 10 megabit per second ETHERNET connections 210. It should be noted that the network may be expanded to include two or more servers 110 to increase the user capacity of the computer based karaoke system 100. In one embodiment, the servers 110 advantageously comprise 486DX2 66 computers having four EISA busmaster slots, a 25-megabyte RAM, and a 250-megabyte or greater hard drive. The servers 110 are capable of running STARWORKS 25 PC Version 1.7 video server software. Advantageously, the servers are available from Hewlett-Packard (HP Netserver) and/or DELL (Model Number 4066A). In one advantageous embodiment, each of the hubs 220 comprises a SMC Tiger 6 Port TP. Each of the hubs 220 connects up to six of the video clients 120 via 1.5 megabit per second ETHERNET connections 240 in the present embodiment. Each of the digital karaoke clients 120 advantageously includes a 486DX 33 MHz PC or a PC of higher performance, having at least 8 Mbytes of RAM and having at least a 250 Mbyte hard drive. Each server 120 is capable of running STARWORKS v2 and OPTIBASE PLAYS v 1.2.6 video server software. The hubs 220 act to divide the 10 Mbit/second signal into this 1.5 Mbitfsecond signals provided to the separate video clients 120. The ETHERNET connection 210, the hub 220, and the ETHERNET connection 240 together comprise the high speed communication link 130 of Figure 1.

In operation, the video clients 120 transmit requests to the video servers 110 via the hub controller connections 220 and the ETHERNET connection links 240, 210. The hub connectors 220 act as interface circuits which assimilate the data input on each of the 1.5 Mbps connection links 240 and output the assimilated data over the 10 Mbps ETHERNET communication links 210 to the servers 110. Conversely, the data provided from the audio/video servers 110 to each of the clients 120 is divided by each hub connector 220 into the respective data to be transmitted to the clients 120 over the ETHERNET links 240. The communication protocol between the clients 120 and the servers 110 is conventional for an ETHERNET link. Figure 3 is a schematic block diagram which shows in detail the main structural and functional elements of the central server 110 depicted in Figures 1 and 2. As shown in Figure 3, the audio/video server 1 10 comprises a main CPU 300 which, in one embodiment, is a 486DX2 66 EISA CPU with a 25 Mbyte RAM and a 250 Mbyte or larger hard drive. The server 110 advantageously runs DOS v6.2.2, LynxOS, and StarWorks 25M v2. The main server CPU 300 includes a small computer system interface ("SCSI"), two-cable connection 320 which connects the main CPU 300 with a memory storage system 310 via SCSI cables 330. In one advantageous embodiment, the memory storage system 310 comprises 14 Hewlett Packard C2490, two-gigabyte, SCSI drives in a SMARTstor intelligent, fault-tolerant subsystem. Thus, a total of 28 gigabytes of memory is provided by the storage system 320, which corresponds to enough capacity to store between 800 and 1,000 songs with their corresponding video data. Of course, it will be understood that the amount of memory storage required for each song varies as a function of the length of the song and the complexity of the accompanying video. On the average, approximately 29 songs, with accompanying video, can be stored within one Gigabyte. Such disc storage systems are available from StreamιngRAID^T¥/Media Integration.

The main server CPU 300 further includes an SMC Elite 32 dual port ETHERNET card 340 in a busmaster EISA slot. The ETHERNET card 340 communicates with one of the hubs 220 (see Figure 2) by means of a 10-base-T local area network cable. The hub 220 communicates with the client, as depicted in Figures 1 and 2.

In operation, the main server CPU 300 manages the storage and retrieval of compressed audio/video data.

A constant ETHERNET channel (sometimes called a "pipe") is maintained between the main server CPU 300 and each client 120. When the client 120 receives a song-request from the customer input unit 140, the corresponding file is opened up from the server and the encoded audio/video data within that file is sent over the ETHERNET pipe to the client 120 for decoding and subsequent playback to the user. It should be noted that all decompression is performed by the client 120 in real time.

Figure 4 is a schematic block diagram which depicts the details of the main structural elements of a client station 230 of Figures 1 and 2. The client station 230 is shown to include the client 120, the customer input unit 140, and audio and video output units. Specifically, Figure 4 depicts a client CPU 400 which connects to the customer input unit 140 via the serial cable 150 and a serial port connection 410. In one advantageous embodiment, the customer input unit 140 is specially designed for the present application, and is described in greater detail below with reference to Figure 6. The cable 150 preferably comprises an RS-232 serial cable, while the serial port 410 is a standard serial (COM) port.

The customer input unit 140, shown in Figure 4 to include an LCD display 418, receives instructions from a hand-held remote control unit 420 operated by a customer 425. The hand-held remote control 420 allows the customer 425 to select from a number of listed songs and corresponding videos by means of an infrared communication link.

An MPEG (Motion Picture Electronics Group) decompress card 430 (advantageously available from OBTIBASE PC MOTION) connects to a video monitor 440 via a cable 450. In one embodiment, the cable 450 comprises a coaxial NTSC cable for video transmission. The decompress card 430 also connects to an amplifier/harmonizer 460 via an audio cable 465. In one advantageous embodiment, the amplifier/harmonizer 460 comprises a karaoke system amplifier/harmonizer available from PIONEER. The amplifier/harmonizer 460 outputs signals to a speaker 470 via an analog audio cable 475. In addition, the amplifier/harmonizer 460 receives inputs from a microphone 480 via a microphone cable 485 and mixes the audio data provided by the client CPU 400 with the voice data provided via the microphone 480 to provide a combined audio signal which is sent to the speaker 470 over the cable 475.

In operation, the user 425 flips through a karaoke songbook (not shown), or the like, and finds a song he or she wants to sing. The user locates the song call number (i.e., the "file retrieval number") which, for example, may be adjacent to the song title on the printed page of the karaoke songbook. The user 425 then enters the call number into the hand-held remote 420. The customer input unit 140 receives the infrared signal from the hand held remote 420 and displays the entered call number, as the user enters them, on the LCD panel 418 on the user input 140.

The user input 140 locates the record for the entered call number from a song catalog export file held in random access memory (RAM) within the user input unit 140. The song catalog export file is an indexing file which contains a listing of the possible call numbers and the titles associated with each call number as printed in the karaoke songbook. The user input 140 subsequently displays the associated title on the LCD screen 418 so that the user may confirm that the correct entry has been selected. If the user did not correctly enter the desired song, the user 425 may opt to clear the entry using the remote control 420 and enter another call number.

The user input 140 adds the entered call number to a song queue (implemented as a memory buffer within the user input 140) which, in one embodiment, may hold as many as 99 song numbers at once in the present embodiment. While managing user inputs to the queue, the user input 140 converts the call number at the top of the queue into a formatted file name string (i.e., by inserting the required DOS pathname characters) to the client CPU 400 via the RS-232 serial connection 150 and the serial port 410. The client CPU 400 advantageously runs DOS v6.2.2, PLAYS by OPTIBASE, STARWORKS for PC Clients, and a special application execute file (KSM.EXE) designed by NESCO to manage the communication link between the user input 140 and the client CPU 400. The KSM.EXE file will be described in greater detail below with reference to Figures 7A and 7B.

The file designated by the transmitted pathname is then opened by the client CPU and decoded for playback along the audio/video channels 450, 465 via the MPEG decompressor 430. The decompressed video portion of the song is displayed on the video screen 440 while an introductory decompressed audio portion of the song is amplified and played via the amplifier 460 and the speakers 470. The user then reads the words from the video display screen 440 and begins to sing into the microphone 480 The audio portion of the decompressed song is amplified and harmonized with the users voice (provided via the microphone 480 and the line 485) within the amplifier/ harmomzer 460 to provide a blended musical output over the speakers 470.

Figures 5A and 5B are an overall system diagram which details each of the main elements of the computer based karaoke system 100 of the present invention. As depicted in Figures 5A and 5B, a karaoke room 500 includes the customer input unit 140, the speakers 470, the video display screen 440, and other local circuitry which can conveniently be located in the karaoke room 500 with the user 425.

An encoding station is depicted in Figure 5C. The encoding station 510 is used to encode audio and video data transmitted from content sources 520, 521 via a video line 525, an audio line 530. In one embodiment, the encoding is performed using the well known MPEG Lab Works compression algorithm performed using MPEGLab compression software. As is well known in the art, MPEG is a set of industry-wide standards for digitizing and compressing video (and audio/video files). MPEG Lab Works is a software application which comes standard with the OptiBase MPEG4000 encodmg board. The content sources 520, 521 may, for example, comprise audio and video recordings (such as found on compact disks, laser disks, and cassette tapes), or live performances, and other sources of audio and video. The audio data derived from the content source 521 enters the encoding station 510 and is encoded using a PCMotion Pro audio encoder and standard MPEG audio compression algorithms available from OPTIBASE, as represented in a block 540. The video data derived from the content source 520 is transmitted via the line 525 to the encoding station 510 where an OPTIBASE PMPEG4000 encoder 535 is used to encode the video data. The encoded audio and video data provided by the encoders 535, 540 are transmitted to the karaoke server 110 via a SMC ELITE- 16 ETHERNET connection 542, an ETHERNET line 210 and the ETHERNET hub 220. The central server 110 then stores the audio/video data in the array 310.

In one advantageous embodiment, the encoding station 510 comprises a Pentium™ 60 or faster CPU with a 25 megabyte RAM and a 250 megabyte hard disk or larger. In addition, the encoding station should run WINDOWS version 3.11, DOS version 6.22, MPEG LAB version 1.1 and STARWORKS CLIENT version 2 The encoder 510 uses the audio/video digitizer and compressor (OPTIBASE MPEG LAB PRO) to digitize and compress the source input audio and video signals, in addition to being sent to the server 110, the compressed, digitized audio/video files are archived to a CD-ROM Recorder 541 via a SCSI adaptor 320 in the encoding station 510.

Select songs (i.e., MPEG files) can be transferred to the karaoke server 110 via an ETHERNET connection (210 & 220). The customer song list database is compiled at this time, in concert with the encoding and archiving of the audio/video data. In the processes of encoding the audio/video data, the newly created MPEG files are given two digit file names (plus the standard DOS filename extension for MPEG files ".MPG") and organized into DOS sub-directories, also having two digit names. For example, the karaoke video file "You Light Up My Life" might get the file name "89.MPG" and be stored in a DOS sub-directory called "87", so that the full DOS pathname of that file would be "X:\87\89.MPG", where X represents the drive designation letter. Thus, the song retrieval code "8789" would be entered into the song list database, along with the Song Title, Artist and Category. This information is then used to generate both the "SONGS.TAB" file, which is downloaded to the user input device 140 (Figure 5A), and the user song list 5 The SONGS.TAB file, a copy of which resides on each client 120, is loaded in memory (RAM) at startup. This is an ASCII, tab delimited file listing the numeric code and song title for each song file on the server. Because both the SONGS.TAB file and the user song list 5 are generated from the same source, all information is in agreement Therefore, per the preceding example, if the user 425 selects "You Light Up My Life" from the song list and enters the numeric code "8789", the song title "You Light Up My Life" will be displayed on the K Master™ LCD screen (having been pulled from the SONGS.TAB file residing in user input device 140 RAM) and the MPEG file "X.\87\89.MPG" will be opened up for playback from the server 110.

Referring again to Figures 5A and 5B, songs ordered from the central server 110 are sent in compressed digital form to the client 120 via the ETHERNET link 210 and the ETHERNET hub 220 The client 120 then decompresses the audio and video data using an OPTIBASE PCMOTION PRO MPEG decoding card and transmits this data to the playback equipment 460, 440 via a video cable 552 and an audio cable 554 It will be appreciated that the audio line 554 will typically include separate lines for the left and right stereo speakers 470.

In certain applications, it may be desirable to "retrofit" the computer based karaoke system of the present invention to accommodate pre-existing audio video equipment at the installation site. For instance, a jukebox, or other audio/video equipment could be connected to the amplifier 460 and the video display 440 via a switching box (not shown) and a switch matrix (also not shown) could be used to connect the client 120 to the switching box

Figure 6 is a highly simplified block diagram showing the main internal elements of the customer input unit

140. The input unit 140 is shown in Figure 6 to include an infra red receiver 600 which receives optical signals from the remote 420 (not shown in Figure 6) and converts these signals into electrical signals for transmission to a processing unit 610. The processing unit 610 advantageously comprises an erasable, programmable, read-only memory (EPROM) which is programmed during the manufacture of the input unit 140. Of course, other processing devices such as a microprocessor, a PAL, or the like could be used in place of an EPROM. The programming code used to "burn" the EPROM 610 is attached herewith as Appendix A.

As described in greater detail below with reference to Figure 7A, the processing unit 610 manages the reception of signals from the remote 420 and the output of data to the client 120 as well as to the LCD 418 The processing unit 610 receives power (at ± 15 volts and 5 volts) from an internal power supply 620.

A serial port 630 provides a link, via the RS-232 connection 150, between the processor 610 and the client 120. In one advantageous embodiment, the serial port 630 is a standard 25 pin (0B-25F) port available from DIGI-KEY. A conventional key change connector 640 provides a connection by which the user can transmit signals to the amplifier 460 to modify the key of the music being played, in accordance with well known techniques Briefly, the remote 420 includes buttons for changing the key of the song being played The signals which produce this key change are transmitted to the amplifier 460 which is specially adapted to modify the key of the music being played in response to the received signals. It should be noted that changing key is conventional In one preferred embodiment, the key change connector comprises a 15-pιn connector, available from PIONEER

The processor unit 610 outputs information to be displayed to the user to a next song display 650, a song stack display 655, and a song input display 660. The next song display 650, a song stack display 655, and a song input display 660 are all part of the LCD 418 In one embodiment, the next song and song input displays 650, 660 are LCDs capable of displaying two lines of twenty letters each, while the song stack display comprises two seven-segment LEDs.

Figures 7A and 7B are flow charts which detail the general method of operation for the customer input unit 140, as well as the method for managing communication between the customer input unit 140 and the client 120 of Figures 1, 4 and 5A. It should be understood that the method described below with reference to Figure 7A is executed primarily under software control within the user input unit 140, while the method described with reference to Figure 7B is executed primarily under software control within the client station 120, unless otherwise noted.

The application KSM.EXE, residing on the hard drive of the client 120, loads at start-up (boot) The song file (SONGS.TAB), also located on the client hard drive, is transferred into memory (RAM). Infrared signals are received by the user input device 140 and interpreted by the internal logic of the user input device 140. Playback control codes and numeric song codes are sent from the user input device 140 to the KSM.EXE file via the RS 232 connection 150. Song titles are retrieved from the song list in client RAM and sent from the KSM.EXE file to the user input device 140 for display on the LCD 418. Song codes are translated by the KSM.EXE file to file names for playback. In this manner, control of the decoder (PCMotion) is performed by the KSM.EXE file based on signals from the user input device 140.

As a general overview of the method executed within the user input unit 140, the user may enter a four-digit song number, one digit at a time, via the infrared remote. Once the four digit song number has been keyed in, the user presses ENTER to actually select the song. The user then has the option of entering "clear" if the user later decides that this is not the song that he desires to listen to or "start" to begin playing the song. Once the song is playing, the user may enter a pause, resume, or stop command in order to pause a song that is playing, resume playing a paused song, or stop a song that is playing.

As depicted in Figure 7A, the user input unit 140 waits in an idle state, as represented by a block 700, until the user inputs information via the infrared remote 420. Once the user has input information via the infrared remote 420, the user input device logic determines whether or not the input mformation is a number, as represented in a decision block 702. If the user input device logic determines that the user has keyed in a number, then a test is performed to determine if the number is the fourth number that has been entered, as represented within a decision block 704. If the fourth number has not yet been entered, then the keγed-ιn number is added to the end of the LCD display, as represented in an activity block 706, and the user input device 140 reenters the idle state 700. However, if it is determined that the fourth number has been keyed in, then the song title is retrieved from the KSM.EXE file, as represented within an activity block 708 Thereafter, the song title that was retrieved is displayed on the LCD 660, as represented in an activity block 710. The user input unit 140 then returns to the idle state 700.

Once the user has keyed in a four-digit number so that the corresponding song title is displayed on the LCD screen 660, the user need only press ENTER to select the song for play. Thus, if within the decision block 702 it is determined that the keyed in command was not a number, a test is performed to determine if the user has keyed in the ENTER command, as represented within a decision block 712 If the user input device logic determines that the user has keyed in the ENTER command, then a further determination is made if the queue that holds the songs to be played (i e , in the server 110) is full, as represented in a decision block 714 As discussed above, the queue advantageously holds a total of 99 songs, so that the queue is considered full if more than 99 songs have been selected to be played. It has been found that a queue of this size is sufficient to service 10 or more karaoke boxes at once. If it is determined that the queue is full, then the song is not entered, and the user input 140 reenters the idle state 700. However, if it is determined that a queue is not full, then the song on display (i.e., on the LCD screen 660) is placed at the end of the queue The user input unit 140 thereafter enters the idle state 700.

Once the user has entered a song, the user has many options, such as the option to clear the song, to start a new song, to pause in the middle of a currently playing song, to resume playing a song, or to stop a currently playing song. Thus, if it was determined within the decision block 712 that the user did not key in an ENTER command, a new test is performed to determine if the user has entered the CLEAR command, as indicated within a decision block 716. If it is determined within the decision block 716 that the user has entered the CLEAR command, then the number in the display 660 is deleted, as represented within an activity block 720, and the user input unit 140 reenters the idle state 700. If it is determined within the decision block 716 that a CLEAR command was not entered by the user, then a test is performed to determine if a START command was keyed in by the user, as represented within a decision block 724.

If it is determined that the user has keyed in a START command, a test is performed to determine if a song is currently playing, as represented within a decision block 726. If within the decision block 726 it is determined that a song is not currently playing, then a PLAY command is sent, together with the song at the top of the queue, to the KSM.EXE file, as represented within an activity block 728. Subsequently, the user input unit 140 reenters the idle state 700. It should be noted here that while the user input device is in the idle state 700, or any other state represented m the flowcharts of Figures 7A and 7B, the KSM.EXE file is continuously executing in the background, as represented by a loop 729 in dashed lines, so that a song can be played concurrently with the operation of the user input device 140. Thus, so long as the queue is not empty, or the user has not paused the song, music is continuously being played by the computer based karaoke system 100.

If it is determined within the decision block 726 that a song is currently playing, then a RESTART command is sent to the KSM.EXE file, as indicated within an activity block 730. The RESTART command causes the currently playing song to start over from the beginning as soon as the RESTART command is executed. The user input unit 140 thereafter enters the idle state 700. If it is determined within the decision block 724 that the user has not keyed in a START command, then a test is performed by the user input device logic to determine if the user has keyed in a PAUSE command, as represented within a decision block 732. If it is determined within the decision block 732 that the user has entered a PAUSE command, then the user input unit 140 sends a pause code to the client to cause the song being played to pause until a RESUME command is sent. This is represented within an activity block 734 Thereafter, the user input unit 140 reenters the idle state 700. If it is determined within the decision block 732 that the user has not keyed in the PAUSE command, then a determination is made if the user has keyed in a RESUME command, as represented within a decision block 736. If the user has entered a RESUME command, then the RESUME command is sent to the KSM.EXE file, as represented within an activity block 738, and the user input unit 140 reenters the idle state 700. The RESUME command causes the song which is currently paused to resume from where the music left off. If the RESUME command is inadvertently entered when a song is not paused, then the RESUME command is ignored. However, if it is determined within the decision block 736 that the user has not keyed in a resume command, then this indicates that the user has entered a STOP command. Consequently, the STOP command is sent to the KSM.EXE file, as represented within an activity block 740, and the user input unit 140 sends a PLAY command and the song at the top of the queue to the KSM.EXE file to initiate playing of the next song, as represented within the activity block 728.

Figure 7B is a flowchart that gives a general overview of the method used by the KSM.EXE file to control playback of the selected songs and also to retrieve the selected song titles As depicted in Figure 7B, the method begins by loading the SONGS.TAB file into the RAM of the central server 110. The SONGS.TAB file includes a listing of each of the song titles and their associated call numbers. Once the SONGS.TAB file is loaded into the RAM of the central server 110, as represented within the block 750, the central server 110 is placed in an idle state wherein the server 110 waits for an input via the command port (ι.e., from the user input unit 140), as represented within a block 753. Once an input has been detected, a decision is made, as represented within a decision block 756, if the input is the numeric song code. If it is determined that the input is the numeric song code, then this entered code is matched to the song title, as represented within an activity block 759, and the title is sent to the customer iπtput unit 140 (also referred to herein as the K-MASTER device) (see Figure 6), as represented within an activity block 762. Thereafter, the central server 110 reenters the idle state 753 to wait for further inputs from the command port.

Once an input is received that is not a numeric song code, then a test is performed to determine if the input is a play command accompanied by the file name, as represented within a decision block 765. If it is determined that the input is a play command accompanied by the file name, then the play command and file name are sent to the PCMotion decoder 430 to initiate playback of the selected song, as represented within an activity block 768 Thereafter, the server enters the idle state 753 while transmitting the audio and video data corresponding to the selected song to the client for playback. If it is determined within the decision block 765 that the input received via the command port is not a PLAY command, then a determination is made if the received input is a RESTART command, as represented within a decision block 771. If the received input is a RESTART command, then the RESTART command is sent to the PCMotion decoder, as represented within an activity block 774 The RESTART command will cause the decoder to begin decoding at the start of the song file again so that the currently playing song is restarted and the user at the client end hears the beginning of the same song again. While the song is being played from the beginning again, the client server reenters the state 753. If it is determined within the decision block 771 that the input command is not a RESTART, then a test is performed to determine if the input is a PAUSE command, as represented within a decision block 777. If the received input is a PAUSE command, then the PAUSE command is sent to the PCMotion decoder 430 to cause the decoder 430 to cease decoding until a RESUME command is received, as represented within an activity block 780. Thus, the user at the user input unit 140 will hear a pause in the music, since the PCMotion decoder 430 is no longer transmitting audio data to the speakers 470 or video data to the video display 440. The client 120 thereafter enters the state 753 to wait for further inputs via the COM port 410.

If it is determined within the decision block 777 that the received input is not a PAUSE command, then a test is performed to determine if the input is a RESUME command, as represented within a decision block 783. If it is determined within the decision block 783 that the received input is a RESUME command, then the RESUME command is sent to the PCMotion decoder, as represented within an activity block 786. When the RESUME command is sent to the PCMotion decoder, this causes the decoder to continue decoding the song data where it left off in response to the PAUSE command. Thus, the user at the client 120 will hear the song resume piaying from the point where the song was paused. Thereafter, the server 110 reenters the state 753 to wait for additional inputs via the COM port. If within the decision block 783 it is determined, however, that a RESUME command was not input, then it is concluded that a STOP command was input, as represented within an activity block 789. Thus, as represented within an activity block 792, the STOP command is sent to the PCMotion decoder to cause the decoder to stop decoding the current song. Thereafter, the central server 110 reenters the state 753 to wait for an additional input via the COM port. As discussed above with reference to Figure 7A, a PLAY command will be sent immediately after the STOP command is received so that the next song in the queue will immediately begin playing after the STOP command has caused the PCMotion decoder to stop decoding the last song. In this manner, continuous playback of each of the songs in order in the song queue is accomplished under the control of the KSM.EXE file.

Although the preferred embodiment of the present invention has been described in detail above, many alterations and modifications could be made to the system described above without departing from the spirit and essential characteristics of the invention. For example, The client workstation 120 and the user input unit 140 could be integrated into a single chassis where only the essential elements of the client 120 for running the computer based karaoke system are incorporated into the single chassis. Therefore, the scope of the present invention should be interpreted in light of the following claims. APPENDIX A

$ NO OD51 PL(5B) mods

Program KSTRT.A51 rph 03/03/95 - reordered pitch codes rph 01/24/95 - new combo of C_STARTUP & KARB rph 01/16/95 - new, setup for Karaoke (KARB.A51) sir 08/21/89 - new, setup for gpcll (C_STARTUP) NAME KSTRT

;515 TYPE REGISTERS $ INCLUDE (C:\C51\ASM\REG515.INC) linkages to C code

EXTRN CODE disable_interrupts)

EXTRN CODE _enable_ie0_in )

EXTRN CODE _enable_tf0_int)

EXTRN CODE _enable_tf2exf2_int)

EXTRN CODE enable_interrupts)

EXTRN CODE _babcock_delay)

EXTRN CODE _babcock_clear)

EXTRN CODE _stxd)

EXTRN CODE _smsg)

EXTRN CODE ?C_START)

PUBLIC bit_counter, int_counter PUBLIC code_ready, rem_code PUBLIC delay_count _/Delay count

PROG SEGMENT CODE CODES SEGMENT CODE PAGE LVARS SEGMENT DATA BITVARS SEGMENT BIT XVARS SEGMENT XDATA

EXT INT 0 ENTRY POINT

CSEG AT 0003H

JMP SVCO

; TIMER 0 INT ENTRY POINT

CSEG AT 00BH

JMP TOINT

ACTUAL INTERRUPT SERVICE int_counter is interrupt counter bit counter is bit counter after start bit

RSEG PROG

SVCO: PUSH DPL SAVE REGISTERS

PUSH DPH

PUSH PSW

PUSH ACC

ORL PSW, #18H SET REG BANK 3

MOV A, THO UPPER TIME BYTE

ADD A, #OECH NEW CODE IF > 5 M

JC SVC00 YES

SVC1: MOV A, int_counter; INT COUNTER

INC int counter INCREMENT IT

JZ ZTMRO EXIT IF 1ST INTPT SLIPPED THROUGH DJNZ ACC, SVC2 SEE IF IT WAS 1 MOV A, THO YES, IT WAS ADD A, #0F1H MUST BE > OEH JC ZTMRO YES, ZERO TIMER

SVC3 : DEC int_counter NOISE, START OVER JMP EXIT

SVC2: INC bit_counter MOV A, THO ;TIMER VALUE ADD A, #0FDH ;CHK IF 1 OR 5 JNC STORE1

STOR01: MOV A, #1 CJNE A, bit_counter , STR01A ;SEE IF BIT NR 1

SVC00: MOV int_counter, #01H ;1ST INT OR BAD BIT 1 MOV BIT_COUNTER, #00H ;ZERO COUNTERS

ZTMRO: JMP ZTMR ;AND TIMER

STR01A: CLR A CALL SHIFT ;SHIFT 0 INTO CODE INC bit_counter

STORE1 MOV A, #1 CALL SHIFT SHIFT 1 INTO CODE MOV A, bit_counter NOW CHECK IF ADD A, #0D0H 48 BITS RCVD JNC ZTMRO NOT YET

;NOW CHECK CODE PREAMBLE

LKUPC: MOV DPTR, #MCODE + 1

MOV R4, #00H

MOVX A, @DPTR

XRL A,#0ABH

CALL CNT1S

INC DPTR

MOVX A, ODPTR

XRL A, #6BH

CALL CNTIS

INC DPTR

MOVX A, @DPTR

XRL A, #0DBH

CALL CNTIS

MOV A, R4

JZ LKUP1

DEC A

JZ LKUP1

MOV SBUF, #' *' ; :PPRREEAAMMBBLLEE ERROR

JMP ZREG

;NOW LOOK UP CODE

LKUP1 INC DPTR

MOVX A, @DPTR ;F F:IRST CODE BYTE

MOV RO, A

MOVX A, ©DPTR

MOV Rl, A ;2 21ND

INC DPTR

MOVX , OdPTR

MOV R2, A ;3 31RD

MOV DPTR, #CDTBL

MOV R4, #0 ;N N1UMBER OF CODES

DILP CLR A

MOV R4, A ;Z ZIERO DIST COUNT

MOVC A, OA+DPTR

XRL A, RO

CALL CNTIS

INC DPTR

CLR A

MOVC A, ©A+DPTR XRL A, Rl

CALL CNTIS

INC DPTR

CLR A

MOVC A, ©A+DPTR

XRL A, R2

CALL CNTIS

INC DPTR

MOV A, R4

JZ GDCD

DEC A

JZ GDCD

INC DPTR

INC R5

CJNE R5, #34, DILP

MOV SBUF, #' &'

JMP ZREG ;BAD CODE

3DCD: MOV rem_code, R5 /CODE NUMBER

SETB code ready

PUSH DPH ;SAVE DPTR

PUSH DPL

MOV R5, #1 ;DISP NULINE

MOV R3, #5 ;IN CODE

MOV R2, #HIGH NULIN

MOV Rl, #LOW NULIN

CALL smsg

POP DPL RESTORE DPTR

POP DPH

MOV R5, #1

MOV R3, #5

MOV R2, #HIGH CSTRT

CLR A

MOVC A, ©A+DPTR

MOV Rl, A

CALL smsg ;DISP CODE

ZREG: CLR EXO ;TURN OFF EXT INTO

SETB ETO ;WAIT TMRO 65 MS

MOV delay count, #4 ;X 16 = 1 SECOND

MOV int_counter, #00H ;ZERO REGS

MOV bit counter, #00H

ZTMR: MOV THO, #00H ;ZERO TIMERS

MOV TLO, #00H

EXIT: POP ACC

POP SW

POP DPH

POP DPL

RETI _/RETURN FRM INTRPT /SUBROUTINE TO SHIFT CODE

SHIFT: MOV DPTR, #MCODE+6

RCC A

SHIF1: MOVX A, ©DPTR

RLC A

MOVX ©DPTR, A

DJNZ DPL, SHIF1

RET

_/SUBROUTINE TO COUNT ONES IN ACC /ADDS COUNT TO R4

CNTIS: MOV R6, #8

CNT1S0 : RCC A

JNC CNT1S1

JNC R4

CNT1S1 : DJNZ R6 , CNTIS0 RET

/TIMER 0 INTERRUPT SVC AFTER 65 MS

TOINT: DJNZ delay_count, TOINT1 CLR ETO _/TURN OFF TIMER INTPT SETB EXO /AND TURN ON EXT INT 0

TOINT1 RETI

/REMOTE CODE TABLE

CDTBL:

DB OFEH, OAAH, OABH, LOW CODO

DB 7FH, 6AH, OABH, LOW COD1

DB OBFH, 5AH, OABH, LOW COD2

DB 5FH, OBAH, OABH, LOW COD3

DB ODFH, 56H, OABH, LOW COD4

DB 6FH, 0B6H, OABH, LOW COD5

DB OAFH, OAEH, OABH, LOW COD6

DB 57H, ODEH, OABH, LOW COD7

DB OEFH, 55H, OABH, LOW COD8

DB 77H, 0B5H, OABH, LOW COD9

DB 0B5H, OABH, 77H, LOW CODA

DB 5AH, 0D7H, 77H, LOW CODB

DB 0D5H, OAAH, 0F7H, LOW CENT

DB 6AH, 0D6H, 0F7H, LOW CCLR

DB 56H, OEFH, 6BH, LOW CSTRT

DB OADH, 0D7H, 6BH, LOW CSTOP

DB 56H, 0D7H, 0B7H, LOW CS3

DB 0F6H, OAAH, OB7H, LOW CF4

DB OADH, OABH, 0B7H, LOW CS2

DB 7BH, 5AH, 0B7H, LOW CF3

DB 6DH, OADH, 0B7H, LOW CS1

DB ODBH, 55H, 0B7H, LOW CNORM

DB 5DH, OAEH, 0B7H, LOW CF1

DB OBBH, 56H, 0B7H, LOW CF2

DB OEBH, 55H, 77H, LOW CS4

DB ODBH, OABH, 6BH, LOW CSKB

DB 5DH, ODDH, 6BH, LOW CSKF

DB 7BH, 0B5H, 6BH, LOW CSCB

DB 0F7H, 55H, 6BH, LOW CSCF

DB OEBH, OAAH, OEBH, LOW CPAUS

DB OBBH, OADH, 6BH, LOW CMU E

DB OFDH, 55H, 57H, LOW CDISP

DB OBEH, OADH, 57H, LOW CAUD

DB 7EH, 0B5H, 57H, LOW CDA

REMOTE MONITOR CODES

RSEG CODES

CSTRT : DB START' , 00H

CSTOP: DB STOP' ,00H

COD1 DB 1' , 00H

COD2 DB 2' , 00H

COD3 DB 3' , 00H

COD4 DB 4' , 00H

COD5 DB 5' , 00H

COD6 DB 6' , 0OH

COD7 DB 7' , 00H

COD8 DB 8' , 00H

COD9 DB 9' ,00H

COD0 DB 0' ,00H

CODA DB A' , 00H

CODB DB B' ,00H

CCLR DB CLEAR' , OOH CENT DB 'ENTER' , 00H

CS1 DB SHARP 1 , 00H

CS2 DB SHARP 2 , 00H

CS3 DB ' SHARP3 ' 00H

CS4 DB ' SHARP4' 00H

CNORM DB NORMAL' 00H

CF4 DB 'FLAT 4' 00H

CF3 DB ' FLAT 3 ' OOH

CF2 DB ' FLAT 2' 00H

CF1 DB 'FLAT 1' OOH

CSKB DB 'SKIP BACK' , OOH

CSKF DB 'SKIP FORWARD' , OOH

CSCB DB 'SCAN BACK' ,00H

CSCF DB ' SCAN FORWARD' , 0OH

CPAUS DB 'PAUSE' ,00H

CMUTE DB 'MUTE' ,00H

CDISP DB 'DISPLAY' , OOH

CAUD: DB 'AUDIO' , OOH

CDA: DB 'DIGITAL/ANALOG' , OOH

NULIN: DB 0DH,0AH,00H

SELECT DB 'Select now, Master', OOH

BADCOD DB 'Bad Code' , OOH

RSEG BITVARS code_ready: DBIT 1

RSEG LVARS int_counter: DS 1 Interrupt ctr bit-_counter: DS 1 Bit counter rem_code: DS 1 Remote code delay_count : DS 1 Delay counter

/STORAGE FOR CODE

RSEG XVARS

MCODE: DS 7

END /* kmnl_5.C C programs for Karaoke Songmaster interrupt service and Babcock and multiplexed LED drivers. mods rph 04/25/95 Fixed enter after play bug rph 03/27/95 Recognize "Not Available" rph 03/22/95 Preserve song_code thru playsong rph 03/03/95 Added Restart and fixed key change rph 01/27/95 Version 1.2 (init Songmaster, lv partial nr) rph 01/24/95 Version 1.1 release rph 01/23/95 removed IEX0 to assy lang kstrt.aSl rph 11/14/94 displays "Songmaster" at end rph 11/03/94 implemented key change rph 11/03/94 7-seg LED as song counter rph 11/01/94 added duart clear via Pl.l rph 10/26/94 added 7-seg LED driver rph 10/22/94 took out no interrupt vectors rph 10/07/94 added comm to player (kbadrvl.c) rph 09/27/94 new (kintrps.c, kopdrvr. now kabdrvO .c)

*/

#include <io515.h>

#include <stdio.h>

#include <string.h> ffinclude <f_inter.d>

#include <babcock2.d> /* for 2-babcock I/O */

#include <f_sio.d>

#include <f_buffer.d> unsigned char rem_cont code [7] ; unsigned char data xor^~array{3] ,- unsigned char data digit_count,- unsigned char data led_tens, data led_units; unsigned char data stack_size; unsigned char tmr_array[64] _/

#define XBYTE ((unsigned char*) 0x20000L)

#define FREEZE 10

#define UNFREEZE 11

#define ENTER 12

#define CLEAR 13

#define START 14

#define STOP 15 extern char data bit_counter, data int_counter,- extern char data rem_code, delay_count,- extern bit code_ready,- int xdata song_stack[100] / int song_hed_ptr, song_tail_ptr/ unsigned char PORT_0_STATUS = 0/ int song_code, temp_song_code, i, j ; unsigned char letter,- char song_name[4-] , temp_song_name [40] ,- char asc_song_code [4] / char play_song_code[10] = "p ## ##\r\n" / char name_Song_code[9] = "t ####\r" / bit song_plaing, valid_code/ play_song() ,-

/* tf2_int, timer 2 interrupt every 10 ms used to switch multiplexer on the two 7-segment displays.

Port assignment (all active low, A - G are cathodes) -. PORT 4.7 4.6 5.6 5.5 5.4 5.3 5.2 5.1 5.0 LCD SEG AN1 AN2 A B C D E F G

*/ void tf2_int (void) interrupt 5 using 1 static char code led Seg_table [10] 0x01, 77o (ABCDEF-) 0x4F, //l (-BC ) A 0x12, 112 (AB-DE-G) 0x06, //3 (ABCD--G) F| IB 0x4C, //4 (-BC--FG) G 0x24, ll (A-CD-FG) 0x20, /is (A-CDEFG) E| |C OxOF, 111 (ABC ) D 0x00, lie (ABCDEFG) 0x04 l/s (ABCD-FG)

} static bit mux_sense;

IRCON = 0x00/ //clear EXF2 & TF2 led_tens = stack_size/l0/ led_units = stack_size % 10/ mux_sense = !mux_sense;

P4_7_bit = mux_sense,-

P4_6_bit = !mux_sense/ if ( mux_sense )

P5 - led_seg_table [led_units] ; else

P5 = led seg table [led tens] /

} ^{" "} main 0 using 0

{ unsigned char bab code ,- disable_interrupts ( ) ,- Pl_l_bit = 1, /^♦reset duart*/ Pl_l_bit = 0, Pl_2_bit = 0, /^♦enable I/O*/ sio_init(2, 4800, 'N' , 8, 2, 'N' , 0) ,- TMOD = 0x29/ /*tmrl: no gate, mode 2 t rO : gate, mode 1*/

SCON = = 0xC8_/ /*9-bit, 2 stop, var br*/

TCON = = 0x51/ /^♦tmrs run, ieO edge*/

THI = 0xE6/ /*1200 baud on ser port*/

TL1 = 0

THO = 0 /* clear timer 0 */

TL0 = 0

TF0 = 0 /* clear timer ovf flag*/

IEO = 0 /*and ext into 0 flag*/

TRCON = Oxll /*T2 autoreload & intrpt */

CRCL = OxFO/ /*every 10 ms*/ CRCH = 0xD8/ TF2 = 0/ P5 = 0x01/ /^♦segments for 0*/ P4 = OxCC/ /*no led, normal key*/ led_tens = 0; /♦reset LEDs*/ led_units = 0/ stack_size = 0,- song_head_ptr = 0/ song_tail_ptr = 0; song_playing = 0; song_code = 0/ valid_code = 0/ SBUF = 0x01/ /^♦reset babcock VF dispO*/ babcock_delay(1000) //^♦wait 13 ms

P4_5_bit = 1/ /♦select babcock displ*/ SBUF = 0x01/ babcock_clear(0) / babcock_delay(1000) babcock_clear(1) / babcock_delay{1000) bit_counter = 0 /♦initialize decoder*/ int_counter = 0 delay_count = 1 digit_count = 0 enable_ie0_int ( 3, 0 ) / enable_tf0_mt (1) / IRCON = 0x00/ enable_tf2exf2_int (0) / smsg("Make selection now" , babcock_delay(1000) / smsg( "Songmaster", 1 )_/ babcock_delay(1000) / enable_interrupts () / for( / /) if ( code ready)

{ code_Ready = 0 _/ if ( ( 0 < = rem code ) St.Sc ( rem code <= 9 ) )

{ babcock_clear ( 0 ) ; song_code = 0 ,- valid code = 0

} bab_code = rem_code + 0x30 ; / /convert to ascii asc_song_code [digit_count] = bab_code stxd (bab_code , 0 ) ; babcock_de lay ( 1000 ) ; song_code = (song_code * OxOA) + rem_code; digit_count++_/ if (digit count == 4)

{ while (dio(2, 't' ) != 't' ) / babcock_delay(7700) //1100 ms . delay while (dio(2, ' ' ) != ' ' ) ; ford = 0/ i <= 3/ i++)

{ babcock_delay(7700) ; letter = asc_song_code [i] ,- while (dio(2, letter) != letter) ;

} babcock_delay (770) ; while (dio(2, OxOD) != OxOD) ; i = 0_/ song_name [ 0] = 0 ,- do

{ if ( code_ready && ( rem_code == CLEAR) ) brea/ letter = dio (2, OxFF) /

} while ( letter != 0x40)_/ //discard up to © do

{ if ( code_Ready && ( rem_code == CLEAR) ) break/ letter = dio (2, OxFF) / if (letter != 0) song_name [i++ [ = letter/ while (letter != OxOD) / song_name [i - 1] = 0 ; babcock_clear(0) ; babcock_delay(1000) / smsg(song_name, 0); babcock_delay(1000) ; if(strcmp (song_name, "Not Available") != 0! valid_code = 1/ else song_code = 0; digit count = 0/ } else if (rem_code == FREEZE) msg{2, "f \r\n")/ else if (rem_code == UNFREEZE) msg(2, "g \r\n" ) ; /*(go)⁺/ else if (rem code == ENTER)

{ ^" if (!valid_code | ] (song_code == 0)) song_code [i - 1] = 0 ; babcock_clear(0) ,- babcock_delay(1000) / smsg("Make selection now", 0) ; babcock_delay(1000) ,- digit count = 0;

} else if ( stack size == 99 )

{ babcock_clear (0) ; babcock_delay(1000) ; smsg ("Song stack full", 0) ; babcock_de lay ( 1000 ) / else

{ stack_size++; song_stack[song_tail_ptr++] = song_code,- if ( song_tail_ptr == 100 ) song_tail_ptr = 0_/ if ( stack size == 1 )

{ babcock_clear(1) / babcock_delay(1000) ,- smsg(song_name, 1) ; babcock_delay(1000) ,-

babcock_clear (0) / babcock_delay(1000) _/ smsg(song_name, 1) / babcock_delay(30000) _/ babcock_clear(0) / babcock_delay(1000) / smsgC'Make selection now", 0) ; babcock_delay(1000) ,-

}

} else if (rem code == CLEAR) /*clear*/

{ babcock_clear(0) / digit_count = 0; babcock_delay(1000) _/ smsg("Make selection now", 0) ,- babcock delay(1000) /

} else if (rem code == START)

{ if ( !song_playing) play_song(),- /*start*/ else msg(2, "m \r\n") ,- /♦restart^/ else if ( rem code == STOP)

{ msg(2, "q \r\n" ) / /*stop*/ babcock_clear(0) / babcock_delay(1000) ,- song_playing = 0,- digit count = 0/

} else if ( (16 <= rem_code) && (rem_code <= 24) )

{ /*pitch change*/ letter = P4/ if ( rem_code == 16 )

P4 = letter & 0XF0; /*sharp3*/ else /*sharps & flats⁴/

P4 = (letter x OxFO) j ( (rem_xode - 1) & 0x07 | 0x08;

) /^♦cable all screwed up*/ else

{ babcock_clear ( 0 ) ,- babcock_de lay ( 1000 ) ,- digit count = 0 , ^■ i = 0 / song name [0] = 0 smsg ( "Look for this new feature soon ! " , 0 ) ; babcock Delay ( 1000 ) / if ( dio ( 2 , -xFF) == ' * ' )

{ song_playing = 0/ babcock_delay( 1000 )/ play_song() /

/*

Play song from song stack

*/ play song()

T if ( stack size != 0 )

{ temp_song_code = song_stack[song_head_ptr++] / if ( song_head_ptr == 100 ) song_head_ptr = 0/ stack_size-- ,• play_song_code [6] = 0x30 + (temp_song_code % 10) temp_song_code = temp_song_code/10/ play_song_code [5] = 0x30 + (temp_song_code % 10) temp_song_code = temp_song_code/lO/ play_song_code [3] = 0x30 + (temp_song_code % 10) temp_song_code = temp_song_code/10; play_song_code [2] = 0x30 + temp_song_code; if ( stack size == 0 )

{ babcock_delay(1000) / babcock_clear(1) / smsg( "Songmaster", 1 ) ; babcock delay(lOOO) /

} else

{ /*next song*/ temp_song_code = song_stack[song_head ptr] ,- name_song_code [5] = 0x30 + (temp_song_code % 10) temp_song_code = temp_song_code/l0/ name_song_code [4] = 0x30 + (temp_song_code % 10) temp_song_code = temp_song_code/10; name_song_code [3] = 0x30 + (temp_song_code % 10) temp_song_code = temp_song_code/l0; name_song_code[2] = 0x30 + temp_song_code; babcock_delay(1000) ; msg(2, name_song_code) ,- temp_song_name [0] = 0; i = 0; do

{ if ( code_ready && ( rem_code == CLEAR) ) break; letter = dio(2, OxFF) ;

} while (letter != 0x40)/ //discard up to © do

{ if ( code_ready && ( rem_code == CLEAR) ) break; letter = dio (2, OxFF) / if (letter != 0) temp song name[i++] = letter,-

} ^{" ~} while (letter != OxOD) / temp_song_name [i - 1] = 0 babcock_clear (1) ; babcock_delay (1000) ,- smsg ( temp_song_name , l ) / babcock_de lay (1000) ,- msg ( 2 , play_song_code ) _/ song_j?laying = 1/ if ( digit_count == 0 ) babcock_clear (0) / babcock_delay (1000) / smsg ("Make selection now", 0) babcock_delay (1000)

/* babcock2.c - C routines to interface the GPC11 to 2 BABCOCK vacuum fluorescent displays in the ADS Songmaster using the MCS51 serai port (P3.1) and P4.5 selector mods rph 11/01/94 - changed selector from P5.7 to P4.5 rph 10/26/94 - added second display rph 09/28/94 - new

*/

#include <io515.h. /*SFR definitions*/

/* babcock_delay, delay between babcock commands

*/ void babcock_delay ( unsigned int wDelay ) ,- void babcock delay ( unsigned int wDelay )

{ unsigned int i; for ( i = 0/ i < wDelay/ i++ )

/* babcock_clear, reset babcock and clear screen of VF display.

*/ void babcock_clear(disp_num) unsigned char disp_num; if ( disp_num == 0 ) P4_5_bit = 0; else P4_5_bit = 1; while ( !TI ) {}

SBUF = 0x01/ /*display reset*/ babcock_delay(1000) ; while ( !TI ) {}

SBUF = 0x15/ /*display clear*/ babcock delay(lOOO),-

} /* serial transmit serial data to disp (disp_num)

*/ void stxd(dat, disp_num) unsigned char dat, disp_num; if ( disp_num == 0 ) P4_5_bit = 0/ else P4_5_bit = 1; while ( !TI )

SBUF' = dat/ babcock_delay(64) / //add extra stop bit

TI = 0;

} /* serial transmit message endig with 00 through serial port. */ void smsg(msgdat, disp_num) char *msgdat ; unsigned char disp_num,- while ( *msgdat )

{ stxd (msgdat , disp_num) ,-

++msgdat ; }

/ * f_buffer.c - simple ring buffer routines. mods sir 01/18/90 - changed routines to handle struct pointers. sir 01/15/90 - added BUFFER_REMAINING to stat_buffer to return buffer FULL for buff_remam less than BUFFER_REMAINING. If buffer_end > buffer_start, buff_remam = BUFFER_SIZE - buffer_end + buffer_ start. If buffer_start > buffer_end, buff_remaιn = buffer_start - buffer_end. sir 01/10/90 - new

*/

#mclude <ιo515.h.> /* required header for sfr's and bits */

/* max buffer size is 65536 */ idefine BUFFER_SIZE 128

#defme BUFFER_REMAINING 16 /* spaces left m the buffer before

XOFF ^♦/ ttdefme BUFFER_EMPTY 0 #def ιne BUFFER_FULL 1 #def me BUFFER_OK 2 struct buf fer struct

{ unsigned char buffer[BUFFER_SIZE] unsigned int buffer_start; unsigned mt buffer end/

}; void txd_buffer(struct buffer_struct ^♦,unsigned char),- unsigned char rxd_buffer(struct buffer_struct *) / unsigned char stat_buffer(struct buffer_struct ^♦),-

/* txd buffer, have to check if buffer full before calling

^♦/ void txd_buffer(bp,dat) struct buffer_struct ^♦bp/ unsigned char dat,

{

(*bp) .buffer[ (*bp) .buffer_end++] - dat, if ( (*bp) .buffer_end == BUFFER_SIZE) (*bp) buffer_end = 0_/

/* rxd buffer, have to check if buffer empty before calling

*/ unsigned char rxd_buffer(bp) struct buffer struct ♦bp,

{ unsigned char return_value ,- return_value = ( ⁺bp ) . buf f er [ ( ^♦bp) buf fer_start+₊] , if ( ( *bp) buf fer_start == BUFFER_SIZE ) ( *bp ) buf fer_start = 0 ; return return_value / }

/ *. buffer status, returns 0 buffer empty, 1 buffer full, and 2 if OK to read or write

*/ unsigned char stat_buffer(bp) struct buffer struct ^♦bp,-

{ unsigned char return value,- if ((^♦bp) .buf fer_start == (⁺bp) .buffer_end) return_value = 0 ,- else if ( ( ( (^♦bp) .buffer_end . (^♦bp) .buf fer_start) && (BUFFER_REMAINING >=

BUFFER_SIZE - ( ^♦bp ) ,. buf f e r_end +

(*bp) ,buffer_start) ) I I (( (*bp) .buff er_s art > (^♦bp) .buf fer_end) && (BUFFER REMAINING >=

(♦bp) .buffer_start - (♦bp) .buffer_end) ) ) return_value = 1 ,- else return_value = 2_/ /♦ buffer ok to read or write ^♦/ return return value / }

/* f_sio.c - serial communications functions for gpcll mods sir 01/18/90 - disabled RI and TI interrupt at the end of int_sio_0 ( sir 01/17/90 - txd() , rxd( ) , and dio() , for XON_XOFF. sir 01/11/90 - cannot read IMR register, took out read. sir 01/10/90 - added rxd_stat (port) and txd_stat (port) functions, added 'M' , no handshaking on

88C681 DUART, txd is not controlled by

CTS. sir 08/21/89 - Franklin C compatibility conversion, sir 03/29/89 - new

#include <io515.h> /^♦ required header for sfr's and bits ♦/

/* */

#define XON_XOFF 1

/* */

#ifdef X0N_X0FF ttinclude <f_buffer.d>

#define XON_XSTAT 1 #define XOFF_STAT 0 xdata struct buffer_struct port_buffer [2] / unsigned char xxstat_txd[2] / unsigned char xxstat_rxd[2] ,- unsigned char xxget_char(unsigned char)/

#endif

#define TRUE 1

#define FALSE 0

#define YES 1

#define NO 0

#define XON 17 #define XOFF 19

/^♦ status defintions ^♦/

#define BUSY 0 #define NOT_BUSY 1 ttdefine XBYTE ((unsigned char ^♦) 0x20000L)

/^♦ duart register addresses ♦/

#define MR1A XBYTE [OxAOOO] /^♦ mode register IA: read/write

*/ #define MR2A XBYTE [OXAOOO] /* mode register 2A: read/write

*/ #define SRA XBTTE[0XA001] /* status register A: read ^♦/ #define CSRA XBYTE [OxAOOl] /^♦ clock select register A: write */ #define ISRM XBYTE [0xA002] /* interrupt status register masked: rea #define CRA XBYTE [0xA002] /* command register A: write */ #define RHRA XBYTE [0xA003] /* Rx holding register A: read

* / #define THRA XBYTE [OxAO03] /* Tx holding register A: write

*/

#define IPCR XBYTE [0xA004] /^♦ input port change register: read ♦/

#define ACR XBYTE [OxA004] /^♦ auxiliary control register: write ♦/

#define ISRU XBYTE [0xA005] /* interrupt status register unmasked: r

#define IMR XBYTE [0xA005] /^♦ interrupt mask register: write */

#define CTU XBYTE [0xA006] /* counter/timer upper byte: read */

#define CTUR XBYTE [0xA006] /^♦ counter/timerupper register: write */

#define CTL XBYTE [0xA007] /^♦ counter/timer lower byte: read ♦/

#define CTLR XBYTE [0xA007] /^♦ counter/timer lower register: write ♦

#define MR1B XBYTE [OxAOOΘ] /^♦ mode register IB: read/write

^♦/

#define MR2B XBYTE [OxAOOΘ] /^♦ mode register 2B: read/write

#/

#define SRB XBYTE [0xA009] /* status register B: read */ #define CSRB XBYTE [0xA009] /^♦ clock select register B: write ♦/

#define CRB XBYTE[OxAOOA] /* command register B: write ♦/ ttdefine RHRB XBYTE[OxAOOB] /^♦ Rx holding register B: read

*/ ttdefine THRB XBYTE [OxAOOB] /^♦ Tx holding register B: write

*/

#define IVR XBYTE [OxAOOC] /^♦ interrupt vector register: read/write

#define INPORT XBYTE [OxAOOD] /^♦ input port: read ♦/ #define OPCR XBYTE [OxAOOD] /^♦ output port configuration register: w

#define STARTCC XBYTE [OxAOOE] /♦start counter command: read ♦/ #define SOPBC XBYTE [OxAOOE] /^♦ set output port bits command: write ^♦

#define STOPCC XBYTE[OxAOOF] /^♦ stop counter command: read ^♦/ #define ROPBC XBYTE [OxAOOF] /^♦ reset output port bits command: write void sio init (unsigned char, unsigned long, char,unsigned char,unsigned char, char,unsigned char)/ void txd (unsigned char, unsigned char) / unsigned char rxd (unsigned char) / unsigned char dio (unsigned char, unsigned char) ; void txd sio 0 (unsigned char, unsigned char)/ unsigned char rxd_sio_0 (unsigned char) / unsigned char rxd_0()/ void int_sio_0 () / void msg (unsigned char, char*)/ void print_bin(unsigned char, unsigned char) / unsigned char rxd_stat (unsigned char) ; unsigned char txd_stat (unsigned char) ; extern unsigned char PORT_0_STATUS;

#ifdef XON_XOFF /* XON_XOFF protocol */

/* get character with XON_XOFF buffering and put into buffer,

01/17/90 return 1 if character rxded otherwise 0.

Pl_2_bit must be low when xxget_char is called.

*/ unsigned char xxget_char (port) unsigned char port,- data unsigned char data_in/ data unsigned char return_value = 0 ; bit continue_on_l = 1_/ bit continue_on_2 = 1_/ bit write buffer = 1/ if (port == 1) while (continue on 2)

{ ^{" "} continue_on_l = 1,- while (continue on 1)

{ ^{" ~} while ( ! (SRA & 0x01) ) data_in = RHRA/ if (data_in == XOFF) xxxstat_rxd[0] = XOFF_STAT_; else if (data in == XON)

{ ^" xxstat_rxd[0] = XON_STAT; if ( ! (SRA & 0x01) ) i f ( s t a t_bu f f e r ( &po r t_buf f e r [ 0 ] )

BUFFER EMPTY)

{ write_buffer = 0 ; continue_on_l = 0 / return value = 0 /

} else

{ write_buffer = 0/ continue_on_l = 0/ return value = 1;

} } else

{ continue_on_l = 0; return value = 1/

if (write buffer)

{ txd_buffer(&port_buffer [0] , data_in,- if (stat buffer(&port buffer [0]) == BUFFER_FULL)

{ ^" xxstat_txd [0] = XOFF_STAT / while (!SRA i 0x04)) /* transmit XOFF */

THRA = XOFF; }

} if (xxstat rxd[0] == XON STAT) continue on_2 = 0;

} else while ( continue on 2 ) { continue_on_l = l; while (continue on 1

{ ^{" "} while( ! (SRB & 0x01) )

7 data_in = RHRB / if ( data_in == XOFF) xxstat_rxd [ l] = XOFF_STAT ; else if (data in == XON)

{ ^" xxstat_rxd[l] = XON_STAT_/ if ( ! (SRB & 0x01) ) if (stat_buffer(&port_buffer[1] )

UFFER EMPTY)

{^" write_buffer = 0_/ continue_on_l = 0; return value = 0,-

} else

{ write_buffer = 0_/ continue_on_l = 0; return value = 1/ } } else

{ continue_on_l = 0 return value = 1/

if (write buffer)

{ txd_buffer(&port_buffer[1] ,data_in) _/ if (stat_buffer(&port_buffer [1] ) BUFFER FULL)

{ ^~ xχstat_txd[l] = XOFF_STAT/ while{!(SRB & 0x04)) /♦ transmit XOFF ♦/

THRB = XOFF/

if (xxstat rxd[l] == XON STAT) continue on 2

return return value;

serial receive and transmit with out waiting port 1 and 2, XON_XOFF version. 01/16/90

*/ unsigned char dio(port, data_out) unsigned char port, data_out; data unsigned char data_in; bit Pl_2_bit_status,-

Pl 2 bit status = Pl 2 bit _/ Pl_2_bit = 0; if (port == 1)

{ if (data out == OxFF) /♦ rxd ^♦/

{ if ((! (SRA S 0x01) ) && ( stat_buf f er port_buf f er [0] ) ==

BUFFER_EMPTY) ) data_in = 0 ; else

{ if (SRA & 0x01) /^♦ DUART has character ^♦/

{ if ( !xxget_char(port) ) data_in = 0; else

{ data_in = rxd_buffer (&port_buffer[0] ) / if (xxstat_txd[0] == XOFF_STAT) if (stat_buffer(^Aport_buffer [0] ) == BUFFER_EMPTY) xxstat_txd[0] = XON_STAT; while (! (SRA & 0x04)) /* transmit XON */

THRA = XON; } } } else ?* buffer has character */

{ data_in = rxd_buffer( port_buffer[0] ) ; if (xxstat_txd[0] == XOF_STAT) if (stat_buffer(&port_buffer[0] ) == BUFFER_EMPTY) xxstat_txd[0] = XON_STAT_; while (! (SRA & 0x04)) /* transmit XON */

THRA = XON_/

else /* txd ^♦/

{ if (SRA Sc 0x01) /♦ byte received */ xxget_char(port) / if ( ! (SRA 0x04) ) data_in = 0; else

{

THRA = da a_out/ data in = data out;

} else /* port 2 ^♦/ if (data out == OxFF) /^♦ rxd ^♦/

{ if ((! (SRB Sc 0x01) ) ScSc (stat_buffer (&port_buf f er [1] ) ==

BUFFER_EMPTY) ) data_in = 0 ; else

{ if (SRB & 0x01) /+ DUART has character */ { if ( ! xxget_char (port ) ) data_m = 0 / else

{ data_in = rxd_buf fer ( &port_buf f er [ 1] ) ,- if (xxstat_txd[l] == XOFF_STAT) if (stat buffer(&port bufferil]) == BUFFER EMPTY)

{ xxstat_txd [l] = XON_STAT ; while(! (SRB & 0x04)) /* transmit XON */ THRB = XON_/

} else

{ data_in = txd_buffer(&port_buffer[1] ) ; if (xxstat_txd[l] == XOFF_STAT) if (stat buffer(Sport buffer[1]) == BUFFER EMPTY)

{ xxstat_txd [l] = XON_STAT ,- while (! (SRB & 0x04)) /* transmit XON */

THRB = XON_/

els ,e ^■ ' ' /* txd */

{ if (SRB & 0x01) /* byte received ♦/ xxget_char(port) / if ( ! (SRB & 0x04) ) data_in = 0/ else

{

THRB = data_out; data in = data out;

} if (Pl_2_bit_status) Pl_2_bit = 1/ return data in;

/ }* serial receive port 1 and 2; XON_XOFF version. 01/16/90

*/ unsigned char rxd(port) unsigned char port;

{ data unsigned char data_in; bit Pl_2_bit_status;

Pl_2_bit_status = Pl_2_bi ;

Pl_2_bit = 0; if (port == 1)

{ if ( (SRA Sc 0x01) | ] (stat_buffer ( Sφort_buf f er [0] ) =

BUFFER EMPTY) )

{ ^" while ( ! xxget_char (port ) ) data_in = rxd_buffer(&port_buffer [0] ) ,- if (xxstat_txd[0] == XOFF_STAT) if (stat buffer(&port buffer[0]) == BUFFER EMPTY)

{ xxstat_txd[0] = XON_STAT; while (! (SRA & 0x04)) /^♦ transmit XON */

THRA = XON; } } else /* buffer has char and no char rxded by DUART */ data_in = rxd_buffer(&port_buffer[0] ) ; if (xxstat_txd[0] == XOFF_STAT) if (stat_buffer (&port_buffer[0] ) == BUFFER_EMPTY) xxstat_txd[0] = XON_STAT; while(! (SRA c 0x04)) /* transmit XON */

THRA = XON,-

}

}

} else /* port 2 */

{ if ((SRB Sc 0x01) | | (stat_buffer(&port_buffer[l] ) ==

BUFFER EMPTY) )

{ ^" while ( !xxget_char(port) ) data_in = rxd_buffer(&port_buffer[1] ) / if (xxstat_txd[l] == XOFF_STAT) if (stat_buffer(&port_buffer[l] ) == BUFFER_EMPTY) xχstat_txd[l] = XON_STAT; while (! (SRB & 0x04)) /♦ transmit XON ^♦/

THRB = XON;

else /♦ buffer has char and no char rxded by DUART ^♦/

{ data_in = rxd_buffer(&port_buffer[1] ) / if (xxstat_txd[l] == XOFF_STAT) if (stat_buffer(&port_buffer [1] ) == BUFFER_EMPTY) xxstat_txd[l] = XON_STAT; while(! (SRB & 0x04)) /♦ transmit XON ♦/

THRB = XON;

if (Pl_2_bit_status) Pl_2_bit = 1; return data in;

/ }* serial transmit port 1 and 2, XON_XOFF version. 1/16/90

void txd(port,dat) unsigned char port; { bit Pl_2_bit_status;

Pl_2_bit_status = Pl_2_bit;

Pl_2_bit = 0/ if (port == 1)

{ if ((SRA Sc 0x01) /* byte received */ xxget_char(por ) / while( ! (SRA & 0x04) )

THRA = dat;

} else /* port 2 */

{ if (SRB Sc 0x01) /* byte received */ xxget_char(port) / while( ! (SRB & 0x04) )

THRB = dat;

} if (Pl_2_bit_status) Pl_2_bit = 1/

#endif /* end XON XOFF protocol */

/_* serial receive status port 1 and 2

serial treansmit status port 1 and 2

*/ unsigned char txd_stat (port) unsigned char port;

{ data unsigned char return_value/ bit Pl__2_bit_status/

Pl_2_bit_status = Pl_2_bit/

Pl_2_bit = 0/ if (port == 1) return_value = (SRA Sc 0x04) / else return_value = (SRB Sc 0x04) ; if (Pl_2_bit_status) Pl_2_bit = 1; return return value;

} serial receive and transmit with out waiting port 1 and 2

*/ unsigned char dio (port , data_out) unsigned char port , data out

{ data unsigned char data_ιn_/ bit Pl_2_bιt_status/

Pl_2_bιt_status = Pl_2_bιt;

Pl_2_bit = 0; lf (port == 1)

{ if (data out == OxFF)

{ if ( ! (SRA Sc 0x01) ) data_m = 0; else data in = RHRA;

} else

{ if ( ! (SRA Sc 0x04) ) data_m = 0 ; else

{

THRA = data_out; data in = data out;

else

{ if (data out == OxFF)

{ if ( ! (SRB Sc 0x01) ) data_m = 0; else data in = RHRB;

} else

{ if ( ! (SRB Sc 0x04) ) da a_m = 0,- else

{

THRA = data_out; data m = data out;

if (Pl_2_bit_status) Pl_2_bit = 1; return data in;

/ }* serial receive port 1 and 2

*/ unsigned char rxd(port) unsigned char port;

{ data unsigned char dat; bit Pi_2_bιt_status;

Pl_2_bιt_status = Pl_2_bιt;

Pl_2_bιt = 0; if (port == 1) { while ( ! (SRA & 0x01) ) dat = RHRA/

} else

{ while( ! (SRB & 0x01) )

/ dat = RHRB;

} if (Pl_2_bit_status) Pl_2_bit = 1/ return dat,-

}

/* serial transmit port 1 and 2

void txd(port,dat) unsigned char port,dat;

{ bit Pl_2_bit_status;

Pl_2_bit_status = Pl_2_bit;

Pl_2_bit = 0; if (port == 1)

{ while ( ! (SRA & 0x04) )

THRA = dat;

} else

{ while ( ! (SRB & 0x04) )

THRB = dat;

} if (Pl 2 bit status) Pl 2 bit = 1; } - ~ ^"

#endif /^♦ end no XON_XOFF protocol */ /* serial transmit port 0

*/ void txd_sio_0 (ad, dat) /* ad address-data for multidrop

*/ unsigned char ad,dat; /* ad=l send address bit */

{ bit Pl_2_bit_status,-

Pl_2_bit_status = Pl_2_bit;

Pl_2_bit = 0;

ROPBC = 0x14/ /* set RS485 in transmit mode */ if (Pl_2_bit_status) Pl_2_bit = 1/ if (ad)

TB8 = 1; /♦ set address bit ♦/ else TB8 = 0; /♦ clear address bit ♦/

SBUF = dat; /^♦ output character ♦/

/* serial receive port 0 wait until specified character received */ unsigned char rxd_sio_0 (ad) /^♦ ad address-data for multidrop

*/ unsigned char ad /^♦ ad=l waiting for multidrop ^♦/ data unsigned char data_in; if (ad) /^♦ waiting for multidrop address ^♦/ while (PORT_0_STATUS != 2)

PORT_0_STATUS = 0; data in = SBUF/

} else /^♦ waiting for data ^♦/

{ while (PORT_0_STATUS != 1)

serial receive port 0 wait until any type of character received

*/ unsigned char rxd_0 () while ( !PORT_0_STATUS) return SBUF;

/ }* serial interrupt port 0

*/ void int sio 0 ()

{ ^{" "} bit Pl_2_bit_status; if (RD

{ if (RB8)

PORT_0_STATUS = 2; else PORT_0_STATUS = 1; RI = 0;

} if (TI)

{Pl_2_bit_status = Pl_2_bit;

Pl_2_bit = 0

SOPBC = 0x14; /♦ set RS485 in receive mode ^♦/ if (Pl_2_bit_status) Pl_2_bit = 1;

TI = 0;

/ i*¹ serial communication initialization

^♦ / v o i sio_init (port , baud, parity, data_length, stop_bitε , protocol , reg_imr ) unsigned char port ; unsigned long baud; char parity; unsigned char data_length; unsigned char stop_bits; char protocol/ unsigned char reg imr;

{ bit Pl_2_bit_status/ xdata unsigned char reg_mrl = 0 xdata unsigned char reg_mr2 = 0 xdata unsigned char reg_csr = 0 xdata unsigned char reg_cr = o _/ xdata unsigned char reg_acr = 0 _/ xdata unsigned char reg opcr = 0 _/

Pl_2_bit_status Pl 2 bit; Pl_2_bit = 0; if (port == 0)

{ if (baud == 4800 I I I I baud == 187500)

PCON = 0X00/ /^♦ set SMOD to 1 ^♦/ else

PCON = 0x80/ /* set SMOD to */ if (baud == 4800 I 1 baud == 9600)

{

BD = 1/ /* enable baud rate generator ^♦/

SMO = 1; /* set mode to 3 ^♦/ SMI == 1;

} else

{

BD = 0; /* disenable baud rate generator ^♦/ SMO = li /* set mode to 2 ^♦/ SMI =

} REN = 1 /* enable serial receiption ^♦/

SOPBC = 0x14; /* set RS485 in receive mode ^♦/

} if ( (port I I I I (port == 2) )

/^♦ txd and rxd have same baud rate ^♦/ if baud 300) reg_csr = 0x44_/ if baud 600) reg csr = 0x55; if baud 1200) reg_csr = 0x66, if baud 2400) reg_csr = 0x88, if baud 4800) reg_csr = 0x99; if baud 9600) reg_csr = OxBB, if parity == 'N reg_mrl = reg_mrl 0x10 if parity == 'E' ) reg_mrl = reg_mrl 0x00 if parity == 'O' ) reg_mrl = reg_mrl 0x05 if data_length == 5) reg_mrl = reg_mrl I 0x00 if data_length == 6) reg_mrl = reg_mrl j 0x01 if data_length == 7) reg_mrl = reg_mrl ! 0x02 if data_length == 8) reg_mrl = reg_mrl j 0x03 if stop_bits == 1) reg_mr2 = reg_mr2 | 0x07; if stop_bits == 2) reg_mr2 = reg_mr2 | 0X0F; if protocol == 'X'

{ reg_mrl = reg_mrl 0x00; reg mr2 = reg mr2 0x00_/

} if (protocol == 'H' reg_mrl = reg_mrl 0x80 ; reg mr2 = reg mr2 | 0x10/

} ^" if (protocol == 'N') reg_mrl = reg_mrl j 0x00/ reg mr2 = reg mr2 \ 0x00;

} ^" reg_cr = 0xB5,- reg acr = 0x30;

} ^" if (port == l)

{

MR1A = reg_mrl;

MR2A = reg_mr2,

CSRA = reg_csr;

CRA = reg_cr;

CRA = reg_cr & OxOF; /^♦ need to be NULL COMMAND ♦/

ACR = reg_acr,-

OPCR = reg_opcr/

SOPBC = 0x01/

IMR = reg_imr/

#ifdef XON_XOFF port_buffer[0] .buffer_start = 0; port_buffer[0] .buffer_end = 0; xxstat_txd[0] = XON_STAT; xxstat_rxd[0] = XONJSTAT; #endif

} if (port == 2)

{

MRIB = reg_mrl;

MR2B = reg_mr2;

CSRB = reg_csr;

CRB = reg_cr;

CRB = reg_cr & OxOF; /♦ need to be NULL COMMAND ♦/

ACR = reg_acr;

OPCR = reg_opcr;

SOPBC = 0x0/

IMR = reg_imr/

#ifdef XON_XOFF port_buf fer [ 1] . buf f er_start = 0 / port_buf fer [1] . buf fer_end = 0 / xχstat_txd [l] = XON_STAT ; xxstat_rxd [l] = XON_STAT _; #endif

} if (Pl 2 bit status) Pl 2 bit = 1; } ^{" "} - /* print message string to serial port 1 or 2

*/ void msg(port,msgdat) /^♦ port 1 and 2 only */ unsigned char port/ char *msgdat/ while(*msgdat)

{ txd(port, *msgdat) ,- ++msgdat;

}

}

print 8 bit binary to serial port 1 or 2

*/ void print_bin(port,dat) unsigned char port,dat/

{ if (dat Sc 0x80) txd(port, 'l' ) ,• else txd(port,' 0') ; if (dat & 0x40) txd(port, '1' ) ; else txd(port, ' 0' ) ; if (dat & 0x20) txd(port, ' 1' ) ; else txd(port, ' 0' ) / if (dat Sc 0x10) txd(port, ' 1' ) / else txd(port,' 0' ) / if (dat Sc 0x08) txd(port, ' 1' ) ; else txd(port, ' 0' ) _/ if (dat Sc 0x04) txd(port, ' 1' ) / else txd(port, ' 0' ) / if (dat Sc 0x02) txd(port, ' 1' ) / else txd(port,' 0' ) _/ if (dat Sc 0x01) txd(port, ' 1' ) / else txd(port,' 0' ) /

} f_inter.c - interrupt routines for gpcll mods rph 09/24/94 - added REGISTERBANK(3) sir 08/21/89 - Frankling C compatibility conversion. sir 04/28/89 - new

*/

#pragma REGISTERBANK(3! #include <I0515.H> /* required header for sfr's and bits */ void disable interrupts (

{ EAL 0; /* disable all interrupts */

} void enable interrupts ()

{ EAL 1; /* enable all interrupts */

} void disable tfO int ()

{ ^{" ~}

ETO = 0 ; / * disable timerO interrupt */ void enable_tf0_ιnt (priority) unsigned char priority,-

{ unsigned char ιp0_mask, ιpl_mask; if ( (priority == 0) (priority 2) ιp0_mask = 0x00, else ιp0_mask = 0x02, if ( (priority == 0) (priority == 1) ) ιpl_mask = 0x00; elso ιpl_mask = 0x02, IPO = ( (IPO Sc OxOFD) ιp0_mask) , IP1 = ( (IP1 Sc OxOFD) ιpl_mask) / ET0 =/ /* enable time 0 interrupt */

void disable tfl int() {

ET1 = 0/ /* disable t emrl interrupt */ } void enable_tfl_mt (priority) unsigned char priority,-

{ unsigned char ιp0_mask, ιpl_mask/ if ( (priority == 0) | (priority == 2) ιp0_mask = 0x00/ elso ιp0_mask = 0x08/ if ( (priority == 0) | (priority == 1) ιpl_mask = 0x00_/ else ιpl_mask = 0x08/ IPO = ( (IPO & 0xOF7) ιpo_mask) / IP1 = ( (IP1 Sc 0xOF7) ipl_mask) / ETI = 1/ /* enable timer l interrupt */

} void disable tf2exf2 ιnt(;

{

ET2 = 0_/ /* disable tιmer2 interrupt ^♦/

} void enable_tf2exf2_mt (priority) unsigned char priority,- unsigned char ιp0_mask, ιpl_mask/ | (priority == 2)) | (priority == 1) )

p0_mask) /

ιpl_mask) ; ET2 = 1_/ /♦ enable timer 2 interrupt ♦/

void disable πti mt

{ ^{" "}

ES = 0; /^♦ disable CPU SIO interrupt */

} void enable_rιtι_mt (priority) unsigned char priority,-

{ unsigned char ip0_mask, ipl_mask; if ((priority == 0) | | (priority == 2)) ip0_mask = 0x00; elso ip0_mask = 0x10; if ( (priority == 0) | | (priority == 1) ) ipl_mask = 0x00; elso ipl_mask = 0x10;

IPO = ( (IPO & OxOEF) ip0_mask) ,- IP1 = ( (IP1 Sc OxOEF) ipl_mask) / ES = 1; /^♦ enable CPU SIO interrupt */

void disable ieO int()

{

EX0 - 0; /* disable external interrupt 0 */

void enable_ie0_int (priority, level) unsigned char priority, level; unsigned char ip0_mask, ipl_mask; if ((priority == 0) j | (priority == 2)) ip0_mask = 0x00; else ip0_mask = 0x01; if ( (priority == 0) | | (priority == 1) ) ipl_mask = 0x00; else ipl_mask = 0x01; IPO - ((IPO Sc OxOFE) j ip0_mask) ,- IP1 - ((IPO & OxOFE) j ip0_mask) ; if (level)

ITO = 0; /* INTO (low) level activiated */ else ITO = 1; /♦ INTO negative transition ^♦/

EX0 = 1; /♦ enable external interrupt 0 ^♦/

} void disable_iel_in ()

EX1 = 0; /♦ disable external interrupt 1 ^♦/

} void enable_iel_int (priority, level) unsigned char priority, level; unsigned char ip0_mask, ipl_mask; if ( (priority == 0 I (priority == 1) ) ipl_mask = 0x00; else ipl mask = 0x00 if ( (priority == 0) j | ((ppirriioorrity == 1) ) ipl_mask = 0x00/ else ipl mask = 0x04;

IPO = ( (IPO Sc OxOFB) iipp0 0__mmaask) /

IP1 = ( (IP1 & OxOFB) iippll__mmaask) ; if (level)

IT1 = 0/ /* INT1 (low) level activiated ^♦/ else IT1 = 1/ /* INT1 negative transition ^♦/

EX1 = 1/ /* enable external interrupt 1 ♦/

} void disable iex2 int ()

{

EX2 = 0; / /*♦ disable external interrupt 2 ^♦/ } void enable_ιex2_mt (priority,positive) unsigned char priority,positive, unsigned char ιp0_mask,ιpl_mask, if ((priority == 0) (priority == 2) ) ιp0_mask = 0x00/ else ιp0_mask = 0x02; if ( (priority == 0) j j (priority == 1) ) ιpl_mask = 0x00/ else ιpl_mask = 0x02/ IPO = ( (IPO Sc OxOFD) ιp0_mask) , IP1 = ( (IP1 Sc OxOFD) ipl mask) ; if (positive)

I2FR = 1, /* INT2 postive transition */ else I2FR = 0/ /* INT2 negative transition */ EX2 = 1; /* enable external interrupt 2 */

} void disable lade mt()

{ ^{" "}

EADC = 0; /* disable A/D interrupt */

} void enable_ιadc_mt (priority) unsigned char priority;

{ unsigned char ιp0_mask, ιpl_mask; if ((priority == 0) | j (priority == 2) ιp0_mask = 0x00; else ιp0_mask = 0x01; if ( (priority == 0) | | (priority == 1) ιpl_mask = 0x00; else ιpl_mask = 0x01; IPO = ( (IPO Sc OxOFE) ιp0_mask) / IP1 = ( (IP1 Sc OxOFE) ιpl_mask) / EADC = 1; /♦ enable A/D interrupt ♦/

} void disable ιex3 mt ()

{ ^{" "}

EX3 = 0; '♦ disable external interrupt 3 ♦/

} void enable_ιex3_mt (priority, positive) unsigned char priority, positive /

{ unsigned char ιp0_mask, ιpl_mask/ if ( (priority == 0 I I I I (priority == 2] ιp0_mask = 0x00/ else ιp0_mask = 0x04/ f ( (priority == 0 I| jI (priority == 1) ιpl_mask = 0x00, else ιpl_mask = 0x04

IPO = ( (IPO Sc OxOFB) ιp0_mask) /

IP1 = ( (IP1 Sc OxOFB) ιpl_mask) ; if (positive) I3FR = 1, /* INT3 positive transition */ else I3FR = 0, /* INT3 negative transition */

EX3 = 1_/ /* enable external interrupt 3

*/ void disable iex4 int ()

{ ^{~ "}

EX4 = 0; /* disable external interrupt

4 */

} void enable_iex4_int (priority) unsigned char priority; unsigned char ip0_mask, ipl_mask; if ((priority == 0 j j (priority == 2)) ip0_mask = 0x00; else ip0_mask = 0x08; if ((priority == 0 | | (priority == 1)) ipl_mask = 0x00; else ipl_mask = 0x08; IPO = ((IPO Sc 0x0F7) ip0_mask) ; IP1 = ((IP1 & 0x0F7) ipl_mask) ; EX4 = 1; /* enable external interrupt 4 */

void disable iex5 int ()

{ ^{" "}

EX5 = 0_/ /* disable external interrupt 5

*/

} void enable_iex5_int (priority) unsigned char priority/ unsigned char ip0_mask, ipl_mask; if ((priority == 0 jj (priority == 2)) ip0_mask = 0x00; else ip0_mask = 0x10; if { (priority == 0 j j (priority == 1) ) ipl_mask = 0x00; else ipl_mask = 0x10 ; IPO = {(IPO & OxOEF) I ip0_mask) ; IP1 = ((IP1 Sc OxOEF) I ipl nask) ; EX5 = 1; /* enable external interrupt 5 */

} void disable iex6 int ()

{ ^{" "}

EX6 = 0; /* disable external interrupt 6

*/

} void enable_iex6_int (priority) unsigned char priority;

{ unsigned char ip0_mask, ipl_mask; if ((priority == 0 j j (priority == 2)) ip0_mask = 0x00; else ip0_mask = 0x20/ if ((priority == 0 j j (priority == 1)) ipl_mask = 0x00/ else ipl_mask = 0x20/ IPO = ( (IPO Sc OxODF) ip0_mask) ; IP1 = ( , (IP1 Sc OxOD _F_). ipl_mask) ;

EX6 = 1 _/ / * enable external interrupt 6 * / void disable t2 xreloadO

{

EXEN2 = 0; /^♦ disable timer2 external reload */

void enable t2 xreloadi

{

EXEN2 = 1; /^♦ enable timer2 external reload

*/

SCJ- SOU . p 022797

Claims

WHAT IS CLAIMED IS:

1. A computer based karaoke system comprising:

a central server having access to a data storage unit which stores audio data; and a plurality of client stations in communication with said central server so that said central server can download said audio data to said client stations, each of said client stations comprising:

a client server;

a convertor for converting said audio data into first analog audio signals, each voice input device to generate second analog audio signals;

an amplifier/harmonizer in communication with said client server and said voice input device to receive said first and second audio signals therefrom, and to mix and amplify said audio signals to provide an amplified output audio wave; and

an audio transducer in communication with said amplifier/harmonizer to produce audio sound in response to input of said amplified audio wave.

2. A computer based karaoke system as defined in Claim 1, further comprising:

a data storage unit which stores video data, and which is in communication with said central server;

a convertor within each said client server which converts video data received by said client server from said central server into analog video signals; and

a video display unit which displays a video image in response to input of said video signals from said convenor.

3. A computer-based karaoke system comprising:

a source of audio signals wherein said audio signals are grouped into songs; a digitizer which converts said audio signals into digital data;

a data storage unit which stores said audio data in song files wherein each file corresponds to a different song;

a central server which downloads said song files to a client server upon request from said client server;

a digital to analog convertor in communication with said client server and which converts said digital data stored within said song files into audio music signals;

an audio harmonizer which receives said audio music signals and further receives voice signals to mix said music and voice signals; and

an audio transducer which outputs said music and voice signals.

4. A computer-based karaoke system as defined in Claim 3, wherein said digitizer further encodes said audio signals.

5. A computer-based karaoke system as defined in Claim 4, wherein said digitizer further encodes video signals as digital video data, and wherein said song files include both encoded audio and video data.

6. A computer-based karaoke system as defined in Claim 5, further comprising a video display screen which receives video signals, converted from digital to analog by said digital to analog convertor, and displays said video signals.

7. A method of accurately publishing song books for a karaoke system comprising the steps of: storing audio or video data which encode a plurality of songs within a memory system;

storing a plurality of unique call numbers associated with said audio or video data for each of said songs;

storing a plurality of titles associated with each of said call numbers and each of said songs; retrieving said titles and said call numbers associated with said titles;

storing said titles and associated call numbers within a text file; and

printing said text file containing said titles and associated call numbers to provide an accurate karaoke song book.