senior_falcon

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.