Sound Conversion

[jacquesg]

This message makes reference to message 46 and perhaps it should refer to Rich's GPLHOW2 topic.

 

I downloaded Tursi's GPL-SOUND file with the intention of moving it my TI-99/4A which has an HSGPL card. After cleaning up the source files because they had some extraneous control characters I also had to make changes to the source files to match the Weiand GPL Assembler that I was going to use. I do not know which GPL Assembler Tursi was using but I am aware of at least 5 GPL assemblers and each has small differences from the others. I decided to use the Weiand GPL Assembler because it sits on my HSGPL card. I think that this is the same assembler that Rich is using in his GPLHOW2 series.

 

The GPL assembly went fine and then I used GPL*LOADER to place the object file in Bank 9 of my HSGPL card. GPL RAINBOW comes up as a menu item but this produces a steady ringing sound for about 5 seconds before stopping. Pressing QUIT exits the program.

 

I am not really looking for a solution. This message is just to report my experience. It had been a little while since I last assembled and loaded a GPL program to a bank of my HSGPL card.

[RXB]

This message makes reference to message 46 and perhaps it should refer to Rich's GPLHOW2 topic.

 

I downloaded Tursi's GPL-SOUND file with the intention of moving it my TI-99/4A which has an HSGPL card. After cleaning up the source files because they had some extraneous control characters I also had to make changes to the source files to match the Weiand GPL Assembler that I was going to use. I do not know which GPL Assembler Tursi was using but I am aware of at least 5 GPL assemblers and each has small differences from the others. I decided to use the Weiand GPL Assembler because it sits on my HSGPL card. I think that this is the same assembler that Rich is using in his GPLHOW2 series.

 

The GPL assembly went fine and then I used GPL*LOADER to place the object file in Bank 9 of my HSGPL card. GPL RAINBOW comes up as a menu item but this produces a steady ringing sound for about 5 seconds before stopping. Pressing QUIT exits the program.

 

I am not really looking for a solution. This message is just to report my experience. It had been a little while since I last assembled and loaded a GPL program to a bank of my HSGPL card.

 

Sorry but I use the Ryte Data GPL Assembler, the German Weiland has one extra file, ASSEM1, ASSEM2, and ASSEM3 are all the Ryte Data has, the Weiland has a ASSEM4.

I would use it but there is absolutely no documentation that I can find on the Weiand GPL Assembler. And the only Docs I have are in German I think so pretty much kills me ever using it.

Edited May 23, 2011 by RXB

[Tursi]

I downloaded Tursi's GPL-SOUND file with the intention of moving it my TI-99/4A which has an HSGPL card. After cleaning up the source files because they had some extraneous control characters I also had to make changes to the source files to match the Weiand GPL Assembler that I was going to use. I do not know which GPL Assembler Tursi was using but I am aware of at least 5 GPL assemblers and each has small differences from the others.

 

The one in my head - I hand-assemble most of my GPL code for the very reason you state - all the assemblers have slightly different syntax, and none of them take the one I learned via TI Intern. I tried to put the syntax as close to Rich's examples as I could but I expected anyone capable of assembling them would figure it out.

 

The GPL assembly went fine and then I used GPL*LOADER to place the object file in Bank 9 of my HSGPL card. GPL RAINBOW comes up as a menu item but this produces a steady ringing sound for about 5 seconds before stopping. Pressing QUIT exits the program.

 

The GROM code is AORG'd and though there are labels for the sound data, the cartridge header is all hard coded, it must load at >6000 in GROM space or it will not work correctly. I don't know the HSGPL banks real well, but make sure you load it at the right address?

 

(It was bad practice for me to do that, but I was just trying to get the example done quickly to demonstrate the usage of the sound lists, and so wanted to de-emphasize the cartridge header).

Edited May 23, 2011 by Tursi

[jacquesg]

Tursi wrote: "Sorry but I use the Ryte Data GPL Assembler, the German Weiland has one extra file, ASSEM1, ASSEM2, and ASSEM3 are all the Ryte Data has, the Weiland has a ASSEM4.

I would use it but there is absolutely no documentation that I can find on the Weiand GPL Assembler. And the only Docs I have are in German I think so pretty much kills me ever using it."

 

I think that we are both using the same GPL Assembler. The RyteData GPL manual refers to v2.1 (Weiand 1985) and my listing files produced by the assembly also shows the same reference.

 

The only changes that I made to your source listing was:

 

Changed AORG >6000 to GROM >6000

Changed I/O 0,SNDLST to I/O 0,@SNDLST

 

This was done to correct Fatal Errors during assembly.

 

Perhaps Rich will also try and assemble the source file and either have the same problem that I had or will be able to point out changes that I should make. I am still very much a novice GPL programmer.

 

Please accept my apologies if this message appears twice. I first tried to use Fast Reply but nothing seemed to show up.

 

Jacques

[Tursi]

Tursi wrote: "Sorry but I use the Ryte Data GPL Assembler, the German Weiland has one extra file, ASSEM1, ASSEM2, and ASSEM3 are all the Ryte Data has, the Weiland has a ASSEM4.

 

No, Rich wrote that. Tursi wrote that he hand-assembles his GPL code.

 

The only changes that I made to your source listing was:

 

Changed AORG >6000 to GROM >6000

Changed I/O 0,SNDLST to I/O 0,@SNDLST

 

Ah, good to know. Those seem like correct changes. And Bank 9 is >6000?

 

Please accept my apologies if this message appears twice. I first tried to use Fast Reply but nothing seemed to show up.

 

Yeah, the forums have been lagging badly for me too, mostly when I try to edit my posts.

[jacquesg]

Tursi wrote: "Sorry but I use the Ryte Data GPL Assembler, the German Weiland has one extra file, ASSEM1, ASSEM2, and ASSEM3 are all the Ryte Data has, the Weiland has a ASSEM4.

 

No, Rich wrote that. Tursi wrote that he hand-assembles his GPL code.

 

The only changes that I made to your source listing was:

 

Changed AORG >6000 to GROM >6000

Changed I/O 0,SNDLST to I/O 0,@SNDLST

 

Ah, good to know. Those seem like correct changes. And Bank 9 is >6000?

 

No, Bank 9 is not >6000. An HSGPL card can have up to a total of 16 banks >0 to >F and each bank can contain GROM >0000, >2000, >4000, >6000, >8000, >A000, >C000 and >E000 plus 4 ROM locations.

 

I chose bank 9 because it happens to be a free bank on my HSGPL card. The program appears in GROM location >6000 of bank 9. There are commands with an HSGPL card that allows you to place a specified bank as the first bank (>0) of the card. This allows GPL*Loader to properly load a GPL program to a bank other than the first bank. Usually my bank >0 contains Super Extended Basic.

[RXB]

Page 314 in the Editor Assembler manual shows a similar chart, but they show it as bit patterns instead of hex values, which is less clear.

 

You can also find the information laid out in a much more clear and comprehensive manner in the TI Tech pages, written and maintained by Theirry Nouspikel.

 

Main Page: http://www.nouspikel...titechpages.htm

Sound Chip: http://nouspikel.gro...i99/tms9919.htm

 

Adamantyr

 

Thank you very much. I normally tend to not seek info in Hardware manuals as they normally have zero info on programming.

Edited May 23, 2011 by RXB

[John Doe]

Edited February 22, 2014 by Tony Knerr

[John Doe]

Edited February 22, 2014 by Tony Knerr

[jacquesg]

Tursi wrote: "Sorry but I use the Ryte Data GPL Assembler, the German Weiland has one extra file, ASSEM1, ASSEM2, and ASSEM3 are all the Ryte Data has, the Weiland has a ASSEM4.

 

No, Rich wrote that. Tursi wrote that he hand-assembles his GPL code.

 

The only changes that I made to your source listing was:

 

Changed AORG >6000 to GROM >6000

Changed I/O 0,SNDLST to I/O 0,@SNDLST

 

Ah, good to know. Those seem like correct changes. And Bank 9 is >6000?

 

No, Bank 9 is not >6000. An HSGPL card can have up to a total of 16 banks >0 to >F and each bank can contain GROM >0000, >2000, >4000, >6000, >8000, >A000, >C000 and >E000 plus 4 ROM locations.

 

I chose bank 9 because it happens to be a free bank on my HSGPL card. The program appears in GROM location >6000 of bank 9. There are commands with an HSGPL card that allows you to place a specified bank as the first bank (>0) of the card. This allows GPL*Loader to properly load a GPL program to a bank other than the first bank. Usually my bank >0 contains Super Extended Basic.

 

Jacques,

 

I'm pretty sure you'll have trouble using a foreign (non-Hsgpl) loader with an HSGPL bank that uses a flash chip. Harald's loader uses a special routine to load 256 bytes at a time, and I believe there's a special timing involved with the flash chips. Have you tried it with the first Gram bank (>10)? I think you'll have a better chance of success with that. It's what my Hsgpl Loader program uses and there are no special timings involved.

 

Tony

 

In effect I am loading into GRAM >10 because before using the loader I enter:

 

CALL BANK(9)

CALL RAM6000 or CALL SCON I am not sure what is the difference but both seem to work.

 

Then I use either GPL*LOADER or Art Green's GLOAD program to load the gpl object file. The GLOAD is frustrating to use because keys tend to run on when entering the file name. The source code is on the snug site if anyone wants to try and correct this.

 

 

If I have a GK type set of files I first convert the files to SNUG format using the conversion program and then I can load the files directly to a selected HSGPL bank using the the HSGPL LOADER program.

 

I think that Harald's Loader expects to see a SNUG header on the file that is being loaded and the GPL-SOUND object file does not have this header or a GK header.

 

This has worked for years. I think that this GPL-SOUND program is properly loaded in my HSGPL card but emits a steady ring for about 5 seconds instead of playing 'Over the Rainbow'. The program is then silent for about 5 seconds again until it starts to emit noise. Pressing Quit exits the program.

 

Jacques

[John Doe]

Edited February 22, 2014 by Tony Knerr

[jacquesg]

 

In effect I am loading into GRAM >10 because before using the loader I enter:

 

CALL BANK(9)

CALL RAM6000 or CALL SCON I am not sure what is the difference but both seem to work.

 

Then I use either GPL*LOADER or Art Green's GLOAD program to load the gpl object file. The GLOAD is frustrating to use because keys tend to run on when entering the file name. The source code is on the snug site if anyone wants to try and correct this.

 

 

If I have a GK type set of files I first convert the files to SNUG format using the conversion program and then I can load the files directly to a selected HSGPL bank using the the HSGPL LOADER program.

 

I think that Harald's Loader expects to see a SNUG header on the file that is being loaded and the GPL-SOUND object file does not have this header or a GK header.

 

This has worked for years. I think that this GPL-SOUND program is properly loaded in my HSGPL card but emits a steady ring for about 5 seconds instead of playing 'Over the Rainbow'. The program is then silent for about 5 seconds again until it starts to emit noise. Pressing Quit exits the program.

 

Jacques

 

 

Interesting. Your steps 'shouldn't' put you into the Gram banks, but maybe somehow you are still getting there?

 

CALL BANK(9) moves the contents of Bank >9 into Banks >10 & >11.

CALL RAM6000 or CALL SCON enable Supercart memory (or cpu >6000->7FFF) and disable CPU >6000 bankswitching.

 

The CALL RAM6000 or CALL SCON is not necessary for running GPL code.

If you then typed CALL GRAM and then BYE, you would be operating in the GRAM banks. (>10 & >11)

But you somehow got there without the CALL GRAM, maybe CALL RAM6000 or CALL SCON has the same effect?

 

Harald's loader does indeed require a Snug header on the file, that's why only the most significant byte of the load

address is required, as it needs to load a 256 byte chunk at a time.

 

The process of getting oneself running in the GRAM banks should be better accomplished by the process:

CALL TIBASIC (loads both GRAM banks with GROM0 and TIBASIC)

CALL GRAM (Switches Banks >10 & >11 in to respond at >9800 (Bank >0) & >9804 (Bank >1))

BYE

 

Tony

 

Tony,

 

The program will not load if I use the CALL TIBASIC approach. I should not have left the impression that the program loads into bank 9. In fact it appears in bank >10 and I can copy it to bank 9 if I want it there.

 

Jacques

[matthew180]

Thank you very much. I normally tend to not seek info in Hardware manuals as they normally have zero info on programming.

 

Not so. I recommend you take a peek inside some of them. Your programs run on hardware and control the hardware, and the datasheets describe the hardware. Therefore, everything you need to know about programming the hardware is found in the datasheets. Take a look at the 9918A (VDP), SN76489 (sound chip), or 9900 (CPU) datasheets and you will see code examples, data formats, all the details about controlling the chip, and all the source material for what is found in the E/A manual.

 

IMO, if you want to be a better programmer you need to understand the hardware. To get useful information from a datasheet does not mean you have to understand electronics or know what all the electrical details mean, just a basic understanding of binary and hex, and the main parts of a computer, what they do, and how they typically go together.

 

GPL is the wrong language to use to if you want to ignore the technical parts of the computer. If you want to be insulated from all of that, use BASIC.

[Tursi]

n/a

Edited May 24, 2011 by Tursi

[Tursi]

Bank 9 refers to the Grom memory from >0000 to >FFFF accessed at Grom read address >9824. Included in that bank are four 8k pages of RAM at >6000.

 

Ah, now I follow it. Thanks Tony. Unfortunately I have no idea offhand if sound lists work in GROM bases other than 0. This point can be inconsistent at times.

 

Jaques, the interrupt routine is almost certainly executing garbage, but the program sounds like it worked. Before trying too complex a diagnosis, just try loading the program at its tested location of GROM >6000, base 0 (>9800).

 

Thank you very much. I normally tend to not seek info in Hardware manuals as they normally have zero info on programming.

 

I've been programming systems for better than 25 years and I find plenty of information in Hardware manuals. They often tend to be references more than tutorials, yes, but the information that you require IS in there. It's just up to you to put it together.

[RXB]

Thank you very much. I normally tend to not seek info in Hardware manuals as they normally have zero info on programming.

 

Not so. I recommend you take a peek inside some of them. Your programs run on hardware and control the hardware, and the datasheets describe the hardware. Therefore, everything you need to know about programming the hardware is found in the datasheets. Take a look at the 9918A (VDP), SN76489 (sound chip), or 9900 (CPU) datasheets and you will see code examples, data formats, all the details about controlling the chip, and all the source material for what is found in the E/A manual.

 

IMO, if you want to be a better programmer you need to understand the hardware. To get useful information from a datasheet does not mean you have to understand electronics or know what all the electrical details mean, just a basic understanding of binary and hex, and the main parts of a computer, what they do, and how they typically go together.

 

GPL is the wrong language to use to if you want to ignore the technical parts of the computer. If you want to be insulated from all of that, use BASIC.

 

 

That is not true at all. 90% of the world uses C or C++ or Objective C or Java and they NEVER have to know anything about hardware. (Libraries take care of all that for them)

 

For the TI yes I believe you are right I just do not have all the manuals that I used to have, I much prefer physical manuals to ones online as you can not have 2 open at the same time, let alone 6 and go back and forth to check data.

(Cut and paste is great, but information takes up to much screen space)

I do not learn things the same way as others, so on screen is a real pain for me to use. Wish I had never lost all of my manuals as I had almost everything you named. I do get your point.

Edited May 25, 2011 by RXB

[jacquesg]

Bank 9 refers to the Grom memory from >0000 to >FFFF accessed at Grom read address >9824. Included in that bank are four 8k pages of RAM at >6000.

 

Ah, now I follow it. Thanks Tony. Unfortunately I have no idea offhand if sound lists work in GROM bases other than 0. This point can be inconsistent at times.

 

Jaques, the interrupt routine is almost certainly executing garbage, but the program sounds like it worked. Before trying too complex a diagnosis, just try loading the program at its tested location of GROM >6000, base 0 (>9800).

 

Thank you very much. I normally tend to not seek info in Hardware manuals as they normally have zero info on programming.

 

I've been programming systems for better than 25 years and I find plenty of information in Hardware manuals. They often tend to be references more than tutorials, yes, but the information that you require IS in there. It's just up to you to put it together.

 

Instead of using the previous bank 9 I have now loaded the program using bank 0. The result is slightly different, rather than a steady ring you now get fluctuating sound that has some semblance to 'Over the Rainbow'. Tony might be able to give you a more technical explanation. My understanding is that with a HSGPL card you cannot directly load this object file into Bank 0 and must first load to GRAM >10. If the file had a GK header I could convert it to SNUG format and then load it directly into any bank I wanted. However I do not know how to give the file a GK header. Ihe HSGPL card is the only GRAM device that I have ever owned or used.

Edited May 25, 2011 by jacquesg

[matthew180]

That is not true at all. 90% of the world uses C or C++ or Objective C or Java and they NEVER have to know anything about hardware. (Libraries take care of all that for them)

 

That is unfortunately true (most people don't know a thing about hardware and are taught they don't need to know), however we are not programming modern hardware with a selection of languages. Also, I regularly have a lot displeasure working in some of the worst code on earth, code written by "educated professionals" who don't worry about the hardware or what their code is doing to the system. When people don't have a good grasp of the language they are using, what they are really doing, or what they are programming the computer to do, even with those "insulated" languages (of which I would not count C or C++) and libraries, they write nasty code.

 

Remember, this is just my opinion and we all have our own. To me, knowing the hardware makes a better programmer and there is no such thing as separating the two. *All* the information about a piece of hardware comes from two sources: 1. datasheets of the parts that make up the system, and 2. the schematics of that system. After that it is all just layers and abstractions.

 

For the TI yes I believe you are right I just do not have all the manuals that I used to have, I much prefer physical manuals to ones online as you can not have 2 open at the same time, let alone 6 and go back and forth to check data.

 

At least we have the manuals available in *some* form. I hear you though, sometimes you can't beat a paper manual or datasheet, and I collect as many as I can get my hands on. When I'm working on a circuit I'll have so many datasheets spread out on my bench that I sometimes lose my breadboard! But I selectively print pages from those datasheets to use on the bench, otherwise I read from the screen. If you don't already, I highly recommend a multi-monitor setup. I can't use a computer with less than two screens any more, and I'm getting ready to set up another 2 (total of 4) on my main computer.

[RXB]

At least we have the manuals available in *some* form. I hear you though, sometimes you can't beat a paper manual or datasheet, and I collect as many as I can get my hands on. When I'm working on a circuit I'll have so many datasheets spread out on my bench that I sometimes lose my breadboard! But I selectively print pages from those datasheets to use on the bench, otherwise I read from the screen. If you don't already, I highly recommend a multi-monitor setup. I can't use a computer with less than two screens any more, and I'm getting ready to set up another 2 (total of 4) on my main computer.

 

Yea that is true but ink is 10 times as expensive today as when I had the ol ribbon printers. Ink cost about the same as pure gold unless you buy in bulk. Put a ounce of printer ink on a scale and the gold cost less.

 

As for the multi-screens I am a gamer also (Crysis 2, Left4Dead, Unreal, CoD) so maybe I should opt out of the single big one for two smaller ones. (But wife may kill me)

[Tursi]

That is not true at all. 90% of the world uses C or C++ or Objective C or Java and they NEVER have to know anything about hardware. (Libraries take care of all that for them)

 

Then it's true in at least 10% of the world!

 

In the embedded development world, C programmers still need to know all about the hardware, because the libraries don't always exist. My last job was to create those libraries for a new board. I did it bit-by-bit, register by register, and all through the datasheets without example code.

 

C'mon, Rich, let's not waste time quibbling about whether you SHOULD read, just open it up and read! You'll learn either way!

[Tursi]

Instead of using the previous bank 9 I have now loaded the program using bank 0. The result is slightly different, rather than a steady ring you now get fluctuating sound that has some semblance to 'Over the Rainbow'. Tony might be able to give you a more technical explanation. My understanding is that with a HSGPL card you cannot directly load this object file into Bank 0 and must first load to GRAM >10. If the file had a GK header I could convert it to SNUG format and then load it directly into any bank I wanted. However I do not know how to give the file a GK header. Ihe HSGPL card is the only GRAM device that I have ever owned or used.

 

My understanding is that the GK header is just 6 bytes at the beginning of the file. Using a hex editor, just insert those bytes at the beginning of the file and you should be good to go?

 

I had a GRAM Kracker about 5 years ago but I sold it cheap to someone who wanted one more than me. Then I learned they were valuable.