senior_falcon

No, the XB/TML code with the error that I posted that you said crashed the computer. Here is the program modified to avoid having to use COS. Here it is compiled and you can see it is a bit less leisurely.This is running at normal speed, not CPU overdrive. But of course, although it works the same, it is no longer the same program. 100 DIM SINE(11) 110 FOR I=1 TO 11 :: READ SINE(I):: NEXT I 120 CALL SCREEN(2):: PD=1 130 A=0 135 IF PD=1 THEN CALL LINK("PENHUE",3+INT(RND*14),2) 140 FOR I=1 TO 11 150 CALL LINK("PUTPEN",100,120,A) 160 W=A/180*SINE(I) 170 R=9+A/18 180 CALL LINK("PU"):: CALL LINK("FWD",R-W/200) 190 IF PD=1 THEN CALL LINK("PD")ELSE CALL LINK("PE") 195 CALL LINK("FWD",W/100) 200 A=A+3 :: IF A>1453 THEN 230 210 NEXT I :: GOTO 140 230 PD=PD+1 :: PD=PD AND 1 :: GOTO 130 240 DATA 0,51,97,136,164,178,178,164,136,97,51,0

Don't know why it would not work for you. I just copied and pasted the code above and it works fine.

How funny! I never noticed that before. Looking at the code it is obvious it was done on purpose. It falls right in the middle of some DATA bytes.

The RND in BASIC is over 5x faster than RND in XB. Both RXB and XB2.9 G.E.M. now use the faster TI BASIC random number routine. I have a feeling that it may not be as random as the XB one though. Random numbers in a compiled XB program are different than they are in a BASIC/XB program. Compiled code can only use integer arithmetic. That is a problem, because in BASIC a random number is from 0 to .9999999 The work around is to multiply the random number by another number. i.e. instead of: 10 IF RND<.5 THEN 100 ELSE 200 you would use 10 IF RND*2<1 THEN 100 ELSE 200 RND*2 gives a random integer from 0 to 1 RND*6 gives a random integer from 0 to 5 and so on....

If you came up with a programming language like that, you would be a VERY wealthy man!

I think that is right. I must have gone dyslexic for a moment. Now I am totally baffled as to why my way would work at all!!! I am tempted to compile this, but it would have to be converted to integer math. Maybe I will get around to it.l

Not trying to hijack the thread, but I couldn't resist seeing this in The Missing Link. This is in CPU overdrive on my geriatric Dell computer. It takes about 2.5 minutes at normal speed. 5 CALL LINK("COLOR",3,2):: CALL SCREEN(2) 10 FOR A=0 TO 1440 STEP 3 20 CALL LINK("PUTPEN",96,120,A) 23 W=(A/180)*COS(A*5.5*180/PI) 25 R=9+A/17 26 CALL LINK("PU"):: CALL LINK("FWD",R-W) 27 CALL LINK("PD"):: CALL LINK("FWD",W*2) 30 NEXT A 40 GOTO 40

Haven't forgotten you. I have been sidetracked by the XB256 sound player, but that's wrapping up and I should get back to this soon.

I have ironed out all of Cheung's problems and now his sound lists play properly when running in XB256 and when compiled. The hardest problem to fix was getting the XB 2.9 G.E.M. version to handle CALL LINK("XB256",1905) so it actually worked as described to save a 1905 byte long buffer for the sound list. This took days of head scratching but it finally has been fixed so it now behaves the same as the disk version. Another "bug" was that F3 did not work to disable the interrupt driven autocomplete routine. As it turns out, I changed that key to ESC or F9 but forgot that I did that. I found this out by reading the manual! I am now working on the docs to make them a little clearer. Using sound lists is a bit tedious, but the versatility and compactness is worth it.

I was surprised to find that you can get printed circuit boards that match breadboards. So if you can get your project to work on a breadboard, you can put in the components into the same places on the breadboard and solder them in. Of course, a custom circuit board would be more compact, and complicated circuits like a disk controller could not be done on a breadboard.

Yes, that might help. Until someone comes along with 25 entries in the list. Best approach is to fix it properly.

With that bug removed, now SLCOMPILER makes playable sound lists. The next problem is a minor one. When COMPRESS is saving a sound list, line 30001 is created containing the names and addresses of the various entry points in the sound list. But your sound list has too many entry points to fit into line 30001, and there is no provision for additional lines. I will try to work this out tomorrow. Also, I need to clarify a few points in the manual.

I have looked at this and see a few problems that I will need to address: In the XB 2.9 G.E.M. cartridge 1 - When running the XBGDP you should be able to push Fctn 3 to escape the autocomplete routine that loads, saves, saves in merge format, and runs the load program. For some reason that does not work. 2 - CALL LINK("XB256",1905) should save 1905 bytes in the VDP ram for the sound list. That does not work, so you cannot reserve the necessary space for your sound list If you use standard XB, then XB256 is loaded from disk and the problems mentioned above do not happen. When I got things working using the standard XB cartridge, I found that some of the sound lists played properly, while others failed. THEME played fine, but INTRM failed. Looking at the sound list created by the compiler, I could see that some of the durations were for 0/60 of a second, and those are the sound lists that failed In SLCOMPILER, the durations are rounded up or down to the nearest 60th of a second. Some of your durations in the XB program are very short. 1, 2, and 5 milliseconds are used. These all round down to 0/60 of a second. I think this is the main problem. I will make some adjustments to SLCOMPILER to keep that from happening and then try again.

After a quick look it seems to be OK. I will take a closer look tonight.

Making some good progress on this. There is not really that much code to do, it's just that I am not very fast at it. I wanted to copy the LSB of a memory address to the MSB, so the same byte was in both. With R1 pointing to the address, I did this: MOVB @WKSP+3,*R1 And then wondered why it didn't work. What I should have done, of course, is: MOVB @1(R1),*R1

Good question. It would have been easier to make the duration in 60ths of a second, which would require no conversion. I would guess they thought it would be easier for us humans to get the timing we want by using milliseconds. To me 400 milliseconds seems easier than 24/60 of s second. Maybe they intended to have an OS for europe that divided by 50?

Making S L O W but steady progress on this. I wrote the compiler compatible code for the sound list player 2 nights ago, thinking to test it last night. Last night, I spend well over an hour just to get the code loaded so I could test it. And then of course, it crashed. Tonight I worked out what was wrong, and now can play a sound list from compiled XB/TML. The good news is that it works. The bad news is that it is very sluggish. It turns out that when I converted TML for compatibility with the compiler, I took out the LIMI 2 and LIMI 0 that were in the pixel routine. So the only LIMI's were when it returned to the compiler. When printing a long line, the interrupts don't happen as often as they should, and sounds/sprites do not get updated fast enough. Tursi's player uses the interrupt too, so that would be a problem there as well. But at least fixing TML should be easy. Once it is working reliably, there are a number of things that must happen to make it more fool proof. And then of course, trying to document it in an intelligible way.

I worked out most of the bugs and now can play a sound list while running The Missing Link. Here is a simple demo that runs under TML. It does polyspirals, and while doing them, it plays a scale up an octave, then back down. If you press any key it plays "charge" without interrupting the scale being played. The sound list is the same format as those created by SLCOMPILER and SLCONVERT in the JUWEL package. Now to get it to work with compiled XB and TML... POLYSOUND 3 CALL LOAD(8192,255,178) 4 CALL LINK("PLAY","SCALE") 5 CALL LINK("CLEAR"):: CALL LINK("PUTPEN",92,120,0):: ANG=90+RND*180 6 FOR I=1 TO 100 :: CALL LINK("FWD",I,ANG) 20 CALL KEY(0,K,S):: IF S=1 THEN CALL LINK("PLAY","CHARGE") 25 NEXT I 30 GOTO 5

The sound lists consist of bytes from 0 to 255. As far as I know, when you paste into Classic99, it works the same as if you had typed the characters on the keyboard. But the sound list data statement has many characters that cannot be entered via the keyboard, hence the error messages. When you merge the file, no error checking is done, so it just works.

What you are doing will only work in uncompiled TML running in XB. I am still working out the details on how to make it run with a compiled program. Some minor changes must be made in the assembly code, and some changes to the compiler. This will take a few days or more to iron out. I am trying to make it as simple and versatile as possible. As part of this effort, I am almost done making it so TML can use sound lists in high memory, which is a different approach to making music. I will post a simple program demonstrating this in the next couple of days.

Another possibility just occurred to me. You don't have to program GPL to use the grom memory. So, if you are running low on memory in the 32K ram, you could load the groms with character definitions or other data. Reading data from a grom can be done from assembly and is pretty much the same as reading bytes from VDP ram. Of course, if you can fit it all into 32K, that would be the easiest and best approach.

I took a look with the debugger to get an idea of what was in the TOD module. I wondered if there was assembly code that is copied to 32K like the LOGO cartridge, but that doesn't seem to be the case. There is nothing in the expansion ram. Looks like there are 5 groms and at 6K each that is 30K of gpl code. In general, gpl code is around 2/3 the size of assembly, so that would be around 45K of assembly code which is quite a bit more than the 32K expansion. I see the ways around this to be: 1 - a banked rom cartridge, which would have plenty of room 2 - a hybrid cartridge, using grom for the parts that do not need speed and assembly for the actual game play. You could copy code into the 32K and run it from there, or use banked rom. 3 - Sams might work, but you would have to store the code in rom (or disc) and copy it to sams. Then the sams would have to be banked as the program runs, so that may be no better than a banked rom cartridge, except that variables and data could be kept in ram instead of vdp ram. Sounds like an interesting challenge, and a good one too. But it has to be somebody else, not me. (As Bert Williams sang)

A quick test shows that you can play a sound list from vdp using The Missing Link. The real problem is that there is not a lot of room in VDP for the sound list. I found 254 bytes that might be OK to use as long as you do not load pictures or use disk access. If you do not use sprites, the sprite pattern table (256 bytes) would be available. What can you do with 256 bytes? In my test, adapted from the XB256 demo, there is a scale that goes up an octave, then back down an octave, then repeats. This takes 86 bytes. So 256 bytes might be able to play some simple music, but there is not a lot of room there. It would probably be better to use a custom player for the sound list that reads the bytes from cpu memory and puts them into the sound generator. It is hard to believe it would take more than 100 bytes or so for the player, and the data is already in the program as a data statement. So that might be a simpler approach. I understand that Tursi's player is more sophisticated than the player built into the TI, so that is almost certainly the way to go. However, the player takes about 1000 bytes, and if the music data requires more memory than a normal sound list, that might be a problem for you.

When you list that one line program, you will only see that line. But there is more to the program than that. All the data for the music player is included in that program - you just cannot list it. Even though the program does not look like much, you have to add the lines to it. OLD DSK1.PROGRAM or RUN "DSK1.PROGRAM" will just overwrite it. The CALL LOAD in line 3 is important. You can make it a different line number, but the CALL LOAD must be performed before any CALL LINK. There are a few ways to add XB lines to this program with the embedded music. Assuming your program is called TMLPROG, 1 - before you use HMLOADER, type OLD DSK1.TMLPROG. Then SAVE "DSK1.TMLPROG-M,MERGE" Then use HMLOADER to load your music files, then MERGE DSK1.TMLPROG-M 2 - Using Classic99, before you use HMLOADER, type OLD DSK1.TMLPROG. Then LIST "CLIP" This copies the program to the clipboard. You can paste this into a text editor if you want, which lets you look at it and make changes. Then use HMLOADER to load your music files, then at the top bar, choose EDIT, then PASTE XB. 3 - There are other tools such as Stevie or TIDBIT that let you program XB using a text editor. Once you have added the lines of XB code, you can edit the program normally. When you have saved the program with the embedded music files, then when you OLD DSK1... or RUN "DSK1..." the music files are part of it and will be loaded along with the XB code. It sounds like you intend to have a number of programs, with each one running another. You can embed just the desired music needed for each program. You don't need to included unused music. Whatever method you choose, the principle is always the same. First load the music files with HMLOADER, then add the XB lines to the program created by HMLOADER. I would be cautious when using RESequence with embedded code. There may be sequences of bytes that RES changes because it decides they are line numbers. If you do resequence, back up your work so you can recover the XB part of the program if necessary. As mentioned above, another option would be to use a sound list in VDP. There are some small areas of VDP ram that can be used. I will do some research to see if this can be done. I see that HMLOADER is not part of the JUWEL package. In my next release (hopefully soon) I will be sure that it is included.

I should be able to give some more definite information soon. So far what I have written is from memory, which as we all know, can be fallible.