Subject: Re: [TI994A] Evidently my link skills really suck so do this

From: Owen Brand <[email-masked]>
Date: Sun, 10 Jan 2010 13:12:17 -0500

Marc, I'm making progress... I found a good link for a tutorial on how  
to acces the .MUS data files on a PC... If I can get the data in a  
readable format, it will be easy to transfer.... Don't know what you  
plan to do with it once you get to the TI side, but hey... That's the  
fun if it, isn't it?  :)

Owen Brand
**Oprysoft**
Opry99er.com

On Jan 8, 2010, at 7:48 PM, "Marc H" <[email-masked]> wrote:

> google CGSC sid and look for a link to a zip file of the same name.  
> DL and unzip that bastage and listen to the songs. The files in the  
> folders with names are .MUS files. See if you can transfer one of  
> those beeoches to the TI... LIFE SHOULDN"T BE THIS DAMN DIFFICULT !!
>
> I'm gonna have a couple more dozen beers.... let me know if this  
> works.
>
>

---

From: mark wills <[email-masked]>
Date: Sun, 10 Jan 2010 10:59:44 -0800 (PST)

The question is what format will you make them on the TI side?

The .MUS files are presumably just raw data... Bytes, not displayable data. Therefore I would suggest creating them on the TI end as either program image (#5) or IF128.

Mark

>
>From: Owen Brand <[email-masked]>
>To: "[email-masked]" <[email-masked]>
>Sent: Sun, 10 January, 2010 18:12:17
>Subject: Re: [TI994A] Evidently my link skills really suck so do this
>
> >
>
>
>
>
>  >
>>      
> 
>Marc, I'm making progress... I found a good link for a tutorial on how to acces the .MUS data files on a PC... If I can get the data in a readable format, it will be easy to transfer.... Don't know what you plan to do with it once you get to the TI side, but hey... That's the fun if it, isn't it?  :) 
>
>Owen Brand
>**Oprysoft**
>Opry99er.com
>
>On Jan 8, 2010, at 7:48 PM, "Marc H" <marc.hull@sbcglobal .net> wrote:
>
>
>>>
>>
>>
>>  >>
>>
>> 
>>>>      
>> 
>>google CGSC sid and look for a link to a zip file of the same name.  DL and unzip that bastage and listen to the songs.  The files in the folders with names are .MUS files.  See if you can transfer one of those beeoches to the TI... LIFE SHOULDN"T BE THIS DAMN DIFFICULT !!
>>
>>>>I'm gonna have a couple more dozen beers....  let me know if this works.
>>
>>
>

---

From: Insane Multitasker <[email-masked]>
Date: Sun, 10 Jan 2010 13:15:37 -0600

If the files are indeed raw data and do not need to be 'massaged', then DF128 may be beneficial in that Fred's program TIDIR as well as most terminal emulators will transfer the file from PC to DF128, with no additional conversion required. 

To: [email-masked]
From: [email-masked]
Date: Sun, 10 Jan 2010 10:59:44 -0800
Subject: Re: [TI994A] Evidently my link skills really suck so do this

Mark

Owen Brand
**Oprysoft**
Opry99er.com

  

 		 	   		  
_________________________________________________________________
Hotmail: Trusted email with Microsoft’s powerful SPAM protection.
http://clk.atdmt.com/GBL/go/196390706/direct/01/

---

From: Marc Hull <[email-masked]>
Date: Sun, 10 Jan 2010 11:21:48 -0800 (PST)

They should be raw binary files.  They catalog as program files on the C=64.

--- On Sun, 1/10/10, Insane Multitasker <[email-masked]> wrote:

From: Insane Multitasker <[email-masked]>
Subject: RE: [TI994A] Evidently my link skills really suck so do this
To: [email-masked]
Date: Sunday, January 10, 2010, 1:15 PM

  

      

To: TI994A@yahoogroups. com
From: markrobertwills@ yahoo.co. uk
Date: Sun, 10 Jan 2010 10:59:44 -0800
Subject: Re: [TI994A] Evidently my link skills really suck so do this

Mark

From: Owen Brand <owenbrand@opry99er. com>
To: "TI994A@yahoogroups .com" <TI994A@yahoogroups. com>
Sent: Sun, 10 January, 2010 18:12:17
Subject: Re: [TI994A] Evidently my link skills really suck so do this

Owen Brand
**Oprysoft**
Opry99er.com

  

 		 	   		  
Hotmail: Trusted email with Microsoft’s powerful SPAM protection. Sign up now.

---

From: mark wills <[email-masked]>
Date: Sun, 10 Jan 2010 11:12:38 -0800 (PST)

Oroginal source: http://sidplayer.org/about.html

Note: I have also attached the text below to this mail as a txt file, but I was running linux at the time of writing this, which has different line ending conventions to windows. So if the file is garbage in Windows (assuming you use Windows) just go to the web site and download it from there ;-)

BTW: Remember, when reading this, our bits are numbered the other way 'round ;-)

It looks simple enough a format...

Hope this helps

Mark

               Sidplayer Music File Contents
                      by Dick Thornton

Sidplayer music files are prOgRAM type files which contain the musical notes &
command directives for playing a song, as well as the text lines intended for
the song name & credit lines for the composer & sid arranger.

On disk, the file consists of one or more sectors written in standard prOgRAM
format. Characteristics of this file type can be found in your disk manual, or
other books on disk file management. From here on, we will consider the file
data as it resides in memory after being loaded. the general format of the .mus
file in memory is:

  (1) Two-byte length of voice 1 in low-byte, high-byte form.
  (2) Two-byte length of voice 2 in low-byte, high-byte form.
  (3) Two-byte length of voice 3 in low-byte, high-byte form.
  (4) The data for voice 1 always ending with a hlt command.
  (5) The data for voice 2 always ending with a hlt command.
  (6) The data for voice 3 always ending with a hlt command.
  (7) The text lines for song name, etc. THere are five lines, each
      containing 0-32 bytes and ending with a carriage return. The text
      data information is in upper-case Commodore pet ascii. A hex zero byte
      follows the last byte of the last line of text.

The effect of this is that each .mus file is actually four files packed end
to end in a single prg file with three little two-byte lengths in the front to
help you find things. Voice 1 begins at the sixth byte of the data file as
loaded into memory. Voice 2 starts at a point 6 + length of voice 1 from the
beginning of the file in memory. Voice 3 is at 6 + length of voice 1 + length
of voice 2 from the file start, and the text lines begin at 6 + length of voice
1 + length of voice 2 + length of voice 3. Each voice ends with a hlt command
(hex 014f), & if there is no data for a voice that is all it will contain. The
text area ends with a hex zero after the carriage return for the final line.

Each voice contains data in two-byte pairs that contain the musical notes &
commands needed to play the song. The first byte of each pair will have bits
1 and 0 both set to zero if the byte pair describes a musical note otherwise
the byte-pair describes a sid chip command or sidplayer command.

In the following, commands are identified by the three character abbreviation
used by the sid editor program described in the books All about the Commodore 64
Volume 2, and Compute!'s Music System for the Commodore 128 & 64. Both books
are published by Compute! Books.

     Musical Note Data Pairs

Musical note data pairs will contain 00 in the lower-order two bits of the
first byte of the pair. Each musical note byte-pair contains duration in its
first byte, & frequency (pitch) in the second. This data is coded as follows,
where the parenthetic number following a bit number is the hex value of that
bit:

               Byte 1 - Tie and Duration

  bit 7 (80)     always 0
  bit 6 (40)     1=tie to next note. 0=not tied
  bit 5 (20)     1=dotted note duration. 0=not dotted
  bit 4 (10)     bits 4 3 2  note duration
  bit 3 (08)     .    1 1 1    32nd note
  bit 2 (04)     .    1 1 0    16th note
                 .    1 0 1    8th note
                 .    1 0 0    quarter note
                 .    0 1 1    half note
                 .    0 1 0    whole note
                 .    0 0 1    utility duration
                 .    0 0 0    absolute pitch
  bit 1 (02)     always 0 for note pairs
  bit 0 (01)     always 0 for note pairs

               Byte 2 - Frequency (Pitch) and Rests

  bit 7 (80)     bits 7 6    pitch modification
  bit 6 (40)     .    1 1      flatted note
                 .    1 0      natural note
                 .    0 1      sharped note
  bit 5 (20)     bits 5 4 3  octave number
  bit 4 (10)     .    1 1 1    octave 0
  bit 3 (08)     .    1 1 0    octave 1
                 .    1 0 1    octave 2
                 .    1 0 0    octave 3
                 .    0 1 1    octave 4
                 .    0 1 0    octave 5
                 .    0 0 1    octave 6
                 .    0 0 0    octave 7
  bit 2 (04)     bits 2 1 0  note letter identifier
  bit 1 (02)     .    1 1 1    b note
  bit 0 (01)     .    1 1 0    a note
                 .    1 0 1    g note
                 .    1 0 0    f note
                 .    0 1 1    e note
                 .    0 1 0    d note
                 .    0 0 1    c note
                 .    0 0 0    rest

                   Command Data Pairs

Commands contain information other than musical note pitch and duration. For
commands, the low-order two bits of the first byte are not 00. A whole set of
commands are identified with a first byte value of hex 01. For these commands the low-order four bits of the second
byte can be used as a gross identifier, while the high order four bits often
contain a numeric value. These commands are described by their second bytes
below:

               Commands With First Byte = hex 01

  * byte2 *   hex  command  value
  7654 3210        name
  nnnn 0000   n0   dcy      bits 7654 contain a value, 0-f
  nnnn 0010   n2   cal      bits 7654 contain a value, 0-f
  0000 0011   03   bmp      up
  0001 0011   13   flt      no
  0010 0011   23   rng      no
  0011 0011   33   snc      no
  0100 0011   43   f-x      no
  0101 0011   53   3-0      no
  0nnn n100        atk      bits 6543 contain a value, 0-f
  1nnn n100        sus      bits 6543 contain a value, 0-f
  nnnn 0110   n6   def      bits 7654 contain a value, 0-f
  nnn0 0111   n7   wav      bits 7 6 5  waveform

    0 0 0  noise
                                 0 0 1  triangle
                                 0 1 0  sawtooth
                                 0 1 1  triangle + sawtooth
                                 1 0 0  pulse
                                 1 0 1  pulse + triangle
                                 1 1 0  pulse + sawtooth
                                 1 1 1  puls+triang+sawtooTH
  nnn1 0111   n7   f-m      bits 7 6 5  filter mode
                                 0 0 0  off

             0 0 1  low pass
                                 0 1 0  band pass
                                 0 1 1  low + band
                                 1 0 0  high pass
                                 1 0 1  high + low
                                 1 1 0  high + band
                                 1 1 1  high + band + low
  nnnn 1000   n8   rls      bits 7654 contain a value, 0-f
  nnnn 1010   na   res      bits 7654 contain a value, 0-f
  0000 1011   0b   bmp      down
  0001 1011   1b   flt      yes
  0010 1011   2b   rng      yes
  0011 1011   3b   snc      yes
  0100 1011   4b   f-x      yes
  0101 1011   5b   3-0      yes
  nnnn 1110   ne   vol      bits 7654 contain a value, 0-f
  0000 1111   0f   tal      n/a
  0010 1111   2f   end      n/a
  0100 1111   4f   hlt      n/a

          Commands Whose First Byte is Not Hex 01

This group of command pairs generally has a first byte that defines the
command, and the second byte gives a numeric value from hex 00 to ff (decimal
range 0 to 255). There are a few variations, however, where the value range
exceeds 255 (dtn and por), and where negative values must be available (aut,
p-s, tps, and dtn).

  byte1  * byte2 *   cmd
   hex   7654 3210   name value

    n2   nnnn nnnn   p-w  the 12-bit number composed of byte 1, bits 7-4 and
                          all 8 bits of byte 2 give a range oF 0-4,095.

    06   nnnn nnnn   tem  if the second byte is zero, it is replaced by 256
                          (hex 100). the second byte value is then divided
                          into 14,400. the whole number quotient is the number
                          of quarter notes per minute.

    16   nnnn nnnn   utl  second byte is the value.

    26   nnnn nnnn   pnt  second byte is the value.

    36   nnnn nnnn   hed  second byte is the value.

    46   nnnn nnnn   flg  second byte is the value.

    56   snnn nnnn   p-s  second byte contains the value as a signed number
                          with range -127 (hex 81) to +127 (hex 7f)

    66   snnn nnnn   f-s  second byte contains the value as a signed number
                          with range -127 (hex 81) to +127 (hex 7f)

    76   0nnn nnnn   vdp  byte 2 bits 6-0 contain the value, 0-127.

    86   nnnn nnnn   vrt  second byte is the value.

    96   snnn nnnn   aut  second byte contains the value as a signed number
                          with range -127 (hex 81) to +127 (hex 7f)

    a6   hhhh ooos   tps  the second byte contains the number of half-steps
                          to transpose, from -95 to +95. bit 0 is the sign,
                          0=+. 1=-. bits 3-1 give the number of whole
                          octaves for negative values. For positive numbers,
                          the number of octaves is 7 minus the number in bits
                          3-1. bits 7-4 give the additional halfsteps less than
                          an octave (0- 11) for positive numbers. for negative
                          numbers, the excess half-steps are 11 minus the
                          number in bits 7-4.

    b6   nnnn nnnn   aux  second byte is the value.

    0e   nnnn nnnn   f-c  second byte is the value.

    ne   nnnn nnnn   mea  the 10-bit number composed oF bits 7-6 of the 1st
                          byte and all 8 bits of the second byte give a value
                          of 0-1,024. bit 5 and 4 are always 01 for this 
                          command, so the first byte may be 1e, 5e, 9e, or de.

    na   nnnn nnnn   dtn  the 11-bit number composed of byte 1, bits 7-5 and
                          all 8 bits of byte 2 produces a value of 0-2,048. if
                          byte 1, bit 4 is 1, the number is negative, and is
                          reduced by 2,048 for an effective range of -2,048
                          to +2,048.

    nn   nnnn nnnn   por  the 14-bit number composed of byte 1, bits 7-3 and
                          all 8 bits of the second byte. value range is 0 to
                          16,383. bits 1 and 0 of byte 1 are always 11 for
                          this command, all other bits may be any value.

---

From: Owen Brand <[email-masked]>
Date: Sun, 10 Jan 2010 14:47:09 -0500

What I need is a C-64 emulator and a C64-Dir program.  :). I can see  
the data--- I'm getting it into a transferrable program now--- I'll  
send you the TIFILES SID file a little later. :)

Owen Brand
**Oprysoft**
Opry99er.com

On Jan 10, 2010, at 2:21 PM, Marc Hull <[email-masked]> wrote:

> If the files are indeed raw data and do not need to be 'massaged',  
> then DF128 may be beneficial in that Fred's program TIDIR as well as  
> most terminal emulators will transfer the file from PC to DF128,  
> with no additional conversion required.
>
> The .MUS files are presumably just raw data... Bytes, not  
> displayable data. Therefore I would suggest creating them on the TI  
> end as either program image (#5) or IF128.
>
> Mark
>
>
>
> Marc, I'm making progress... I found a good link for a tutorial on  
> how to acces the .MUS data files on a PC... If I can get the data in  
> a readable format, it will be easy to transfer.... Don't know what  
> you plan to do with it once you get to the TI side, but hey...  
> That's the fun if it, isn't it?  :)
>
> Owen Brand
> **Oprysoft**
> Opry99er.com
>

---

From: Owen Brand <[email-masked]>
Date: Sun, 10 Jan 2010 14:52:01 -0500

Mark---this is the same stuff I found.  I used Notepad to paste the  
data, and then used TI99Dir to change the format... It looks good---  
but I don't know how to translate anything to usable data.  Your info  
you pasted into your post is what I'm looking at to try to decipher  
the order and format... Fun stuff, but no way to know if I have been  
successful in getting the entire file.  I'll know more as I learn  
more.  There is some great documentation online on SID and .MUS files.

Owen Brand
**Oprysoft**
Opry99er.com

On Jan 10, 2010, at 2:12 PM, mark wills <[email-masked]>  
wrote:

> [Attachment(s) from mark wills included below]
> Note: I have also attached the text below to this mail as a txt  
> file, but I was running linux at the time of writing this, which has  
> different line ending conventions to windows. So if the file is  
> garbage in Windows (assuming you use Windows) just go to the web  
> site and download it from there ;-)
>
> command
>  directives for playing a song, as well as the text lines intended for
> Each voice contains
>  data in two-byte pairs that contain the musical notes &
> where the parenthetic number following a bit number is the hex value  
> of
>  that
> bit:
>
> commands are identified with a first byte value of hex 01. For these  
> commands the low-order four bits of the second
>    hex   7654 3210   name
>  value

---

From: Owen Brand <[email-masked]>
Date: Sun, 10 Jan 2010 14:53:29 -0500

yep... DF128

Owen Brand
**Oprysoft**
Opry99er.com

---

From: mark wills <[email-masked]>
Date: Sun, 10 Jan 2010 12:06:49 -0800 (PST)

Looks like CCS64 is your best bet. I just installed it. Nice.

I remebered the border and screen colour addresses after all these years (about 25 years!)
POKE53280,x
POKE53281,x

Ah, the memories!

Anyway, that's enough of that C64 rubbish!

>Sent: Sun, 10 January, 2010 19:47:09
>What I need is a C-64 emulator and a C64-Dir program.  :). I can see the data--- I'm getting it into a transferrable program now--- I'll send you the TIFILES SID file a little later. :)
>
>Owen Brand
>**Oprysoft**
>Opry99er.com
>
>On Jan 10, 2010, at 2:21 PM, Marc Hull <marc.hull@sbcglobal .net> wrote:
>
>
>>>
>>
>>
>>  >>
>>
>> 
>>>>      
>> 
>>--- On Sun, 1/10/10, Insane Multitasker <insane_m@hotmail. com> wrote:
>>
>>
>>>From: Insane Multitasker <insane_m@hotmail. com>
>>>To: ti994a@yahoogroups. com
________________________________
>>>________________________________
Hotmail: Trusted email with Microsoft’s powerful SPAM protection. Sign up now. >>>

---

From: mark wills <[email-masked]>
Date: Sun, 10 Jan 2010 12:11:36 -0800 (PST)

There is a windows SID player, as an open project on Source Forge: http://sidplay2.sourceforge.net/

Looks like the developer will let interested parties see the source if they ask. Would be useful if porting to the 9900. Probably written in C but I didn't notice anything on the site.

Mark

>Sent: Sun, 10 January, 2010 19:52:01
>Subject: Re: [TI994A] .MUS file format
>
> >
>
>
>
>
>  >
>>      
> 
>Mark---this is the same stuff I found.  I used Notepad to paste the data, and then used TI99Dir to change the format... It looks good--- but I don't know how to translate anything to usable data.  Your info you pasted into your post is what I'm looking at to try to decipher the order and format... Fun stuff, but no way to know if I have been successful in getting the entire file.  I'll know more as I learn more.  There is some great documentation online on SID and .MUS files.
>
>Owen Brand
>**Oprysoft**
>Opry99er.com
>
>On Jan 10, 2010, at 2:12 PM, mark wills <markrobertwills@ yahoo.co. uk> wrote:
>
>
>>>
>>
>>
>>  >>
>>
>> 
>>>>              
>>      
>> 
>>Oroginal source: http://sidplayer. org/about. html
>>
>>                                 1 1 1  puls+triang+ sawtooTH

---

From: Owen Brand <[email-masked]>
Date: Sun, 10 Jan 2010 15:12:55 -0500

I'll take a look.  :). Thanks.  And Marc (with a C)--- are you wanting  
to emulate your development or are you planning to work with these  
files on your real deal?

Owen Brand
**Oprysoft**
Opry99er.com

On Jan 10, 2010, at 3:06 PM, mark wills <[email-masked]>  
wrote:

>> then DF128 may be beneficial in that Fred's program TIDIR as well  
>> as most terminal emulators will transfer the file from PC to DF128,  
>> how to acces the .MUS data files on a PC... If I can get the data  
>> in a readable format, it will be easy to transfer.... Don't know  
>> what you plan to do with it once you get to the TI side, but hey...  
>> Sign up now.

---

From: Owen Brand <[email-masked]>
Date: Sun, 10 Jan 2010 15:13:53 -0500

..... And if you're wanting to do it on the real deal, would you like  
me to put several SID files onto a floppy and mail it to you....

Owen Brand
**Oprysoft**
Opry99er.com

---

From: Owen Brand <[email-masked]>
Date: Sun, 10 Jan 2010 15:18:19 -0500

I think Marc said something like that.  It would be much too intense  
of a program to "compile," but certainly learning how the "reader"  
reads the bytes would be most useful.

Owen Brand
**Oprysoft**
Opry99er.com

On Jan 10, 2010, at 3:11 PM, mark wills <[email-masked]>  
wrote:

> Looks like the developer will let interested parties see the source  
> if they ask. Would be useful if porting to the 9900. Probably  
> written in C but I didn't notice anything on the site.
>
> Mark
>
> but I don't know how to translate anything to usable data.  Your  
> info you pasted into your post is what I'm looking at to try to  
> decipher the order and format... Fun stuff, but no way to know if I  
> have been successful in getting the entire file.  I'll know more as  
> I learn more.  There is some great documentation online on SID  
> and .MUS files.
>
> Owen Brand
> **Oprysoft**
> Opry99er.com
>
>> file, but I was running linux at the time of writing this, which  
>> has different line ending conventions to windows. So if the file is  
>> Sidplayer music files are prOgRAM type files which contain the  
>> musical notes
>>  &
>> command
>> text area ends with a hex zero after the carriage return for the  
>> final
>>  line.
>>
>> Each voice contains
>> where the parenthetic number following a bit
>>  number is the hex value of
>>  that
>> bit:
>>
>>                  .
>>  0 1      sharped note
>> commands, the low-order two bits
>>  of the first byte are not 00. A
>>  whole set of
>> commands are identified with a first byte value of hex 01. For  
>> these commands the low-order four bits of the second
>>                           numbers, the excess half-steps are 11
>>  minus
>>  the
>>                           number in bits 7-4.
>>

---

From: mark wills <[email-masked]>
Date: Sun, 10 Jan 2010 12:34:54 -0800 (PST)

Yeah, though looking at the file format, it doesn't look too difficult. It should be possible to write a player by hand.

In fact, it might even be possible to write a player for the TI sound chip to play those files. Ok, the TI sound chip is quite primitive, and cannot reproduce the waveforms that the SID can (though it could possibly get close with software manipulation of the envelopes), but it could certainly decode and play the files.

SID rocks though!

Mark

>Sent: Sun, 10 January, 2010 20:18:19
>I think Marc said something like that.  It would be much too intense of a program to "compile," but certainly learning how the "reader" reads the bytes would be most useful.
>
>Owen Brand
>**Oprysoft**
>Opry99er.com
>
>On Jan 10, 2010, at 3:11 PM, mark wills <markrobertwills@ yahoo.co. uk> wrote:
>
>
>>>
>>
>>
>>  >>
>>
>> 
>>>>      
>> 
>>There is a windows SID player, as an open project on Source Forge: http://sidplay2. sourceforge. net/
>>

---

From: mark wills <[email-masked]>
Date: Sun, 10 Jan 2010 12:39:10 -0800 (PST)

>
>----- Forwarded Message ----
>From: mark wills <[email-masked]>
>Sent: Sun, 10 January, 2010 20:32:18
>Subject: Importing MUS files...
>
>
>Owen,
>
>Don't know if this will help, but:
>
>I just imported a MUS file into a Win994A "disk" using TI99Dir
>
>I checked the original PC file and the imported file side by side using Notepad++ in hex view mode, and the hex viewer built into TI99Dir. They were identical.
>
>So, if you have trouble, it's perfectly possible to create a Win994A Disk and import the files onto this 'disk'. Then you just need to transfer that disk (and it's contents) to a real TI disk. I'm not sure how you would do that though!
>
>But, here's what I did in TI99DIR:
>
>1) Get the directory with the MUS files on the left, and the DISKS directory of Win994A on the right.
>2) Double click on one of the disks (or create a disk with Win994A disk manager and select that)
>3) Click on
> the file on the left to transfer
>4) Right click it
>5) Select Copy File(s) from the menu
>6) Click Copy in the dialog box that opens up
>7) Select PROGRAM format from the drop list of file types
>8) Make sure the Add 3 Words check box is NOT checked
>
>Click OK, and bang, it's a byte for byte perfect copy on the Win994A disk. As an added bonus, it's in EA5 format, which is the easiest format to deal with if you are programming in assembly, as it is literally just a stream of bytes, thus the data can be loaded into TI memory with no translations, and with the minimum of assembly code.
>
>Now, what you end up with is a Win994A disk (or a .DSK file, they TI99DIR doesn't seem to care) on the PC... How do you transfer the "files" on this disk to a real TI disk?
>
>Mark
>
>
>._,___

---

From: mark wills <[email-masked]>
Date: Sun, 10 Jan 2010 12:32:18 -0800 (PST)

Owen,

3) Click on the file on the left to transfer

Mark

>Sent: Sun, 10 January, 2010 20:11:36

---

From: Owen Brand <[email-masked]>
Date: Sun, 10 Jan 2010 16:08:16 -0500

Once the files are in the .DSK, they are easy to extract and transfer  
individually... I'm thinking Win994A might be the best route here....  
Just don't know anything about it.  Sounds like you've already got it  
done... Send me the .DSK in an email and I'll knock this out.

Owen Brand
**Oprysoft**
Opry99er.com

On Jan 10, 2010, at 3:32 PM, mark wills <[email-masked]>  
wrote:

> I checked the original PC file and the imported file side by side  
> using Notepad++ in hex view mode, and the hex viewer built into  
> TI99Dir. They were identical.
>
> So, if you have trouble, it's perfectly possible to create a Win994A  
> Disk and import the files onto this 'disk'. Then you just need to  
> transfer that disk (and it's contents) to a real TI disk. I'm not  
> sure how you would do that though!
>
> Click OK, and bang, it's a byte for byte perfect copy on the Win994A  
> disk. As an added bonus, it's in EA5 format, which is the easiest  
> format to deal with if you are programming in assembly, as it is  
> literally just a stream of bytes, thus the data can be loaded into  
> TI memory with no translations, and with the minimum of assembly code.
>
> Now, what you end up with is a Win994A disk (or a .DSK file, they  
> TI99DIR doesn't seem to care) on the PC... How do you transfer the  
> "files" on this disk to a real TI disk?
>
> Mark
>
>
>
>>   (7) The text lines for song name, etc. THere are
>>  five
>>  lines, each
>>
>>   nnnn 0110   n6   def
>>     bits 7654 contain a
>>  value, 0-f
>>                                  1 1 0  high
>>  + band

---

From: mark wills <[email-masked]>
Date: Sun, 10 Jan 2010 13:11:42 -0800 (PST)

Ok,

I'm getting flak for being on the computer all day, so I'll import some MUS files onto a DSK file for you later on and email it to you. So, hold fire for now, don't do any more file stuff ;-) Go have a beer ;-)

Mark.

>Sent: Sun, 10 January, 2010 21:08:16
>Subject: Re: [TI994A] Importing MUS files...
>
> >
>
>
>
>
>  >
>>      
> 
>Once the files are in the .DSK, they are easy to extract and transfer individually. .. I'm thinking Win994A might be the best route here.... Just don't know anything about it.  Sounds like you've already got it done... Send me the .DSK in an email and I'll knock this out.
>
>Owen Brand
>**Oprysoft**
>Opry99er.com
>
>On Jan 10, 2010, at 3:32 PM, mark wills <markrobertwills@ yahoo.co. uk> wrote:
>
>
>>>
>>
>>
>>  >>
>>
>> 
>>>>      
>> 
>>Owen,
>>
>>>From: mark wills <markrobertwills@ yahoo.co. uk>
>>>>>Sidplayer music files are prOgRAM type files which contain the musical notes
>>>>>
>>>>> &
>>>>>command

---

From: tursi <[email-masked]>
Date: Sun, 10 Jan 2010 19:47:55 -0800 (PST)

> The .MUS files are presumably just raw data... Bytes, not displayable data. Therefore I would suggest creating them on the TI

Guys, the standard for non-TI files on the TI is DF128. Use that if you 
are for some reason doing it by hand? Otherwise, transfer via XModem or 
TI99Dir should take care of it automatically.

(I'm pretty sure it's display, not internal, because no translation is 
intended.)

I know I've missed half this conversation... so maybe you have a reason 
for not doing that.

---

From: tursi <[email-masked]>
Date: Sun, 10 Jan 2010 19:51:01 -0800 (PST)

> They should be raw binary files.  They catalog as program files on the C=64.

DF128 is a raw binary file. The 128 byte records are ideal for being 
exactly 1/2 of a sector, giving you 2 records per sector, in a format that 
is easy to read entry by entry.

As alwys, don't get hung up on the terminology. This is the standard 
format for third party binary files. If you select any other format, then 
other people will need to use a converter to load their own files.

---

From: Owen Brand <[email-masked]>
Date: Sun, 10 Jan 2010 22:53:56 -0500

Nope... That's it.  Mark Wills has put it into a .DSK and I'm simply  
going to extract it and transfer it to a 3.5.  DF128 is the format and  
it is easily manipulated in TIDir... I will have it on a 3.5 for  
testing purposes, but the majority if this development (I'm assuming)  
will be emulated.  I will have SID files on my site in TIFILES DF128  
format available for DL as soon as I can.  We can't do s*** with it  
yet, but the format looks easily discernable enough... This is gonna  
be fun.  :)

Owen Brand
**Oprysoft**
Opry99er.com

---

From: tursi <[email-masked]>
Date: Sun, 10 Jan 2010 20:02:29 -0800 (PST)

> it is easily manipulated in TIDir... I will have it on a 3.5 for testing 
> purposes, but the majority if this development (I'm assuming) will be 
> emulated.  I will have SID files on my site in TIFILES DF128 format 
> available for DL as soon as I can.  We can't do s*** with it yet, but 
> the format looks easily discernable enough... This is gonna be fun.  :)

That's the part that is confusing me. If you take a SID file on your PC, 
and XMODEM it to the TI, it will already be saved in DF128 format. That is 
the default format when no TIFILES header is present, so no intermediate 
translation stage should be necessary.

I suppose I'm confused about what you guys are doing. :)

---

From: Insane Multitasker <[email-masked]>
Date: Sun, 10 Jan 2010 22:04:25 -0600

It's confusing as to what you and Owen are trying to do -- transferring the C64 file to the TI c/should be a matter of transferring it with the raw DF128 format. Your program would then interpret the raw data as needed.  Am I missing something here?  

To: [email-masked]
From: [email-masked]
Date: Sun, 10 Jan 2010 11:21:48 -0800
Subject: RE: [TI994A] Evidently my link skills really suck so do this

  

Mark

Owen Brand 
**Oprysoft**
Opry99er.com

  

 		 	   		  
_________________________________________________________________
Hotmail: Free, trusted and rich email service.
http://clk.atdmt.com/GBL/go/196390708/direct/01/

---

From: Owen Brand <[email-masked]>
Date: Sun, 10 Jan 2010 23:21:26 -0500

No.  That's what I'm saying.  It's THAT simple.  The only thing that  
originally had me confused was the format.  I did not know if the  
files were in a readable format, and they ARE.  Now it's just a matter  
of transferring them. That's it.  Easy as pie.  XModem individual  
files saved to DF128.  Sorry for the confusion.

Owen Brand
**Oprysoft**
Opry99er.com

On Jan 10, 2010, at 11:04 PM, Insane Multitasker  
<[email-masked]> wrote:

> It's confusing as to what you and Owen are trying to do --  
> transferring the C64 file to the TI c/should be a matter of  
> transferring it with the raw DF128 format. Your program would then  
> interpret the raw data as needed.  Am I missing something here?
>
>
> Hotmail: Free, trusted and rich email service. Get it now.
>

---

From: mark wills <[email-masked]>
Date: Mon, 11 Jan 2010 03:29:46 -0800 (PST)

It doesn't sound right using DISPLAY fomat for raw files. Surely it will mean that records will be split wherever it comes across an ASCII 13 in the stream? Totally not what you want!

Hence my suggestion to use Internal format, since no translation will take place at all.

:-)

>
>From: tursi <[email-masked]>
>Sent: Mon, 11 January, 2010 3:51:01

---

From: ti99_forever <[email-masked]>
Date: Mon, 11 Jan 2010 03:33:47 -0800 (PST)

Nope, TI's do not *translate* carriage returns and line feeds. There are no special characters in TI files.
DIS/FIX 128 is the common format for data interchange. INT/FIX 128 will work in assembly, but INTERNAL is just a flag anyway. For BASIC it means every record has a length byte for every field.

Stick with DISPLAY, I suggest you read the manual on the formats.

--- On Mon, 1/11/10, mark wills <[email-masked]> wrote:

From: mark wills <[email-masked]>
Subject: Re: [TI994A] Evidently my link skills really suck so do this
To: [email-masked]
Date: Monday, January 11, 2010, 6:29 AM

 
 
:-)

---

From: mark wills <[email-masked]>
Date: Mon, 11 Jan 2010 03:33:16 -0800 (PST)

AH! So I don't need to do anything, yes?

Still doesn't sound right, display format files... Oh well!

>Sent: Mon, 11 January, 2010 4:21:26
>No.  That's what I'm saying.  It's THAT simple.  The only thing that originally had me confused was the format.  I did not know if the files were in a readable format, and they ARE.  Now it's just a matter of transferring them. That's it.  Easy as pie.  XModem individual files saved to DF128.  Sorry for the confusion.    
>
>Owen Brand 
>**Oprysoft**
>Opry99er.com
>
>On Jan 10, 2010, at 11:04 PM, Insane Multitasker <insane_m@hotmail. com> wrote:
>
>
>  
>>From: marc.hull@sbcglobal .net

---

From: mark wills <[email-masked]>
Date: Mon, 11 Jan 2010 03:37:51 -0800 (PST)

OK, thanks. Do you mean the ED/AS manual or the Basic manual?

Mark

>
>From: ti99_forever <[email-masked]>
>Sent: Mon, 11 January, 2010 11:33:47
>--- On Mon, 1/11/10, mark wills <markrobertwills@ yahoo.co. uk> wrote:
>
>
>>>From: tursi <yahoogroup@harmless lion.com>

---

From: ti99_forever <[email-masked]>
Date: Mon, 11 Jan 2010 03:48:36 -0800 (PST)

The best one on the subject is the Yellow/Green Basic reference manual.

Just do not let its description of INTERNAL format to cloud your mind - INTERNAL means "Internal to the application", implying there is a format to the data you may not be aware of. In Basic, that means that numbers are stored in floating point, with a length byte, strings are stored with a length byte, and that there is no way in Hell itself that you can safely expect to read another program's INTERNAL file in Basic because of that definition.Try to read Multiplan Internal format files, for example, and that "length byte" bytes you, literally.

The most important part is that all records have a record length, implied by the record length on the file for FIXED and just before the record ("out of band" might be a good term here), and that no editing or interpretation of the record is done (this is not true for records from the RS232, though).. The lengths in INTERNAL files in Basic are stored inside the record returned by the DSR (therefore they are in-band).

Forget the manual, I think I covered most of it ;) - jk, there is some interesting stuff there about pending inputs & prints, besides there are diagrams as well.

From: mark wills <[email-masked]>
Subject: Re: [TI994A] Evidently my link skills really suck so do this
To: [email-masked]
Date: Monday, January 11, 2010, 6:37 AM

 
Mark

  

 
 
:-)

---

From: ti99_forever <[email-masked]>
Date: Mon, 11 Jan 2010 03:55:11 -0800 (PST)

should say "and just before the record for Variable files" - for some reason , Yahoo! shitmail would not even allow me to edit the text before sending it...

BTW:  Read the RS232 manual for that one, there editing exists with the DEL (chr$(127)) character, with ECho on, a ctrl-R will redisplay the record, almost VAXen-like - so those characters ARE edited. BS (chr$(8)) would've been a better choice than DEL, but things were not *quite* standardized in 1980 or so. I remember patching the RS232 in PC99 and changing DEL to BS. Old TI BBSes often had to "clean up" messages that had embedded BS in them. If you output such a message to another terminal, you'd actually see the text, plus the error, and the cursor backing up to fix it... since BS was acted on in the terminal program, but not the DSR that received the record...

--- On Mon, 1/11/10, ti99_forever <[email-masked]> wrote:

From: ti99_forever <[email-masked]>
Subject: Re: [TI994A] Evidently my link skills really suck so do this
To: [email-masked]
Date: Monday, January 11, 2010, 6:48 AM

 

The most important part is that all records have a record length, implied by the record length on the file for FIXED and just before the record ("out of band" might be a good term here), and that no editing or interpretation of the
 record is done (this is not true for records from the RS232, though). The lengths in INTERNAL files in Basic are stored inside the record returned by the DSR (therefore they are in-band).

        

Mark

  

--- On Mon, 1/11/10, mark wills <markrobertwills@ yahoo.co.. uk> wrote:

 
 
:-)

---

From: tursi <[email-masked]>
Date: Mon, 11 Jan 2010 07:15:23 -0800 (PST)

> It doesn't sound right using DISPLAY fomat for raw files. Surely it will mean that records will be split wherever it comes
> across an ASCII 13 in the stream? Totally not what you want!

"Display" is not the same as C's "text mode". Display on the TI is 
actually the untranslated, while internal is meant for information that 
may need translation.

However, as far as the disk system is concerned, it's just a flag. It 
doesn't do anything with it.

Don't add an extra step into the process. Don't "choose" a format. Just 
use the default. If it caused any translation issues, GIF Mania wouldn't 
have worked, neither would PC-Text, or any of dozens of other programs.

---

From: Marc Hull <[email-masked]>
Date: Mon, 11 Jan 2010 11:17:46 -0800 (PST)

Any development would have to eventually occur on the real equipment because the SID chip and support circuitry do not exist in the emulate world.

--- On Sun, 1/10/10, Owen Brand <[email-masked]> wrote:

From: Owen Brand <[email-masked]>
Subject: Re: [TI994A] Evidently my link skills really suck so do this
To: "[email-masked]" <[email-masked]>
Date: Sunday, January 10, 2010, 2:12 PM

  

      I'll take a look.  :). Thanks.  And Marc (with a C)--- are you wanting to emulate your development or are you planning to work with these files on your real deal?

Owen Brand**Oprysoft**Opry99er.com
On Jan 10, 2010, at 3:06 PM, mark wills <markrobertwills@ yahoo.co. uk> wrote:

    

Ah, the memories!

 

Owen Brand**Oprysoft**Opry99er.com
On Jan 10, 2010, at 2:21 PM, Marc Hull <marc.hull@sbcglobal .net> wrote:

    

 

      

Mark

Owen Brand
**Oprysoft**
Opry99er.com

---

From: Marc Hull <[email-masked]>
Date: Mon, 11 Jan 2010 12:09:33 -0800 (PST)

Good find Mark.  I have seen this document and it is the cause of most of my angst.  The way the file is structured is easy enough to see and the duration, note and octave scheme is equally apparent.  The problem is that there are scores (I have waited a life time to use that term ;-)  of embedded player commands.  Some are fairly evident as to their meaning  (atk, dcy etc)  but others I have no clue as to what they do.  This is the reason I think a 6502 coder is needed.

I have a feeling that some of these commands invoke internal loops, sweeps or god knows what else.  I have bought the original SID Player.64 reference book and am waiting ever so patiently (a back story in it's own right) for it to arrive.  It should offer at least some insight as to what these commands do in a larger sense.

If the text's ever arrive I'll see about disseminating info to any interested parties.

--- On Sun, 1/10/10, mark wills <[email-masked]> wrote:

From: mark wills <[email-masked]>
Subject: [TI994A] .MUS file format [1 Attachment]
To: [email-masked]
Date: Sunday, January 10, 2010, 1:12 PM

  

      Oroginal source:  rel="nofollow" target="_blank" href="http://sidplayer.org/about.html">http://sidplayer. org/about. html

Hope this helps

Mark

     

Each voice contains

             
     Musical Note Data Pairs

Musical note data pairs will contain 00 in the lower-order two bits of the
first byte of the pair. Each musical note byte-pair contains duration in its
first byte, & frequency (pitch) in the second. This data is coded as follows,
where the parenthetic number following a bit number is the hex value of
 that
bit:

  bit 7 (80)     always 0

  bit
 5 (20)     bits 5 4 3  octave number

                   Command Data Pairs

commands, the low-order two bits of the first byte are not 00. A

  nnn0 0111   n7   wav   
   bits 7 6 5  waveform
                             
    0 0 0  noise
                                 0 0 1  triangle
                                 0 1 0  sawtooth
                    
             0 0 1  low pass
                                 0 1 0  band pass
                                 0 1 1  low + band
                                 1 0 0  high pass
                                 1 0 1  high + low
                                 1 1 0  high + band
                                 1 1 1  high + band + low

  byte1  * byte2 *   cmd
   hex   7654 3210   name
 value

                         

                          numbers, the excess half-steps are 11 minus
 the
                          number in bits 7-4.

---

From: mark wills <[email-masked]>
Date: Mon, 11 Jan 2010 14:15:18 -0800 (PST)

Yeah, cool, i'd be interested in getting further info. If I can help any I'd be glad to get stuck
in with you. 

Mar[k] :-)

>
>From: Marc Hull <[email-masked]>
>Sent: Mon, 11 January, 2010 20:09:33
>--- On Sun, 1/10/10, mark wills <markrobertwills@ yahoo.co. uk> wrote:
>
>
>>Oroginal source:  rel="nofollow" target="_blank" href="http:/ /sidplayer. org/about. html">http://sidplayer. org/about. html
>>
>> whole set
>>                                 1 1 1  high + band +
>> low
>>   hex   7654 3210  
>> name