senior_falcon

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.