Playground

[Willsy]

Yes, I'd love to hear these samples also. You're far more clever than me. I've never been able to fathom it. It's black magic to me!

[Stuart]

Yes, in effect, I'm cycling through all the coefficient values, but I'm not comparing the actual sound, rather the error is a measure of how good the prediction is with the given set of coefficients. Also I'm not cycling through all possible combinations of coefficient values... that would take far too long.

 

Which recording would you need? I have the original samples, then the audio output of my program, the output of M.E.S.S. running the speech, and then I could probably record it from the real TI-99 (which I'd have to put up first and find a way to transfer the program... probably via the tape cord from the PC)

 

I think MESS has the most accurate simulation of the speech chip at the moment? So MESS would be fine if you haven't got the 'real iron' set up and handy.

[Kurt_Woloch]

I've now recorded MESS's output of my program for you. In order not to distort anything, I've only converted it to mono and normalized it, but not converted it to an MP3, hence the WAV file attached here.

 

I will also use this to fine-tune my program. The result actually seems a bit to bassy now compared to the original version, I wonder how it sounds on a real TI-99, but I think it will be similar to this.

 

Warofworlds_Mess.wav

 

For a comparison, here's the original version:

 

https://www.youtube.com/watch?v=OcbpvcHvci0

 

 

[Tursi]

Yes, in effect, I'm cycling through all the coefficient values, but I'm not comparing the actual sound, rather the error is a measure of how good the prediction is with the given set of coefficients. Also I'm not cycling through all possible combinations of coefficient values... that would take far too long.

I don't know if it will help -- I don't even know if it will work -- but I thought I had a potential solution for that. If you'd like to try it, ideas are free.

 

My thinking was that although a brute force combination of all coefficients is too large a search space, each coefficient seems like it might build off the previous once enough to do an incremental brute force search. The idea was to first check for silence, since that's a known frame. Then average the sample volume to generate an energy. Next set the K parameters to middle of the road defaults (or maybe 0), then brute force search them in order from K1 upwards, saving the best result for each. Can run through all unvoiced and voiced this way -- unvoiced should take 96 tests and voiced 168, because the size of each K parameter is added rather than multiplied if this approach works. (The parameters are tested by simulating their output and determining how close it sounds, seems you have a good approximation for that already!)

 

I've no idea if it would work. On paper it sounds like it might, but I didn't do more than write down the notes, so there could be huge pieces missing. Just a thought if it's helpful at all.

[Kurt_Woloch]

My thinking was that although a brute force combination of all coefficients is too large a search space, each coefficient seems like it might build off the previous once enough to do an incremental brute force search. The idea was to first check for silence, since that's a known frame. Then average the sample volume to generate an energy. Next set the K parameters to middle of the road defaults (or maybe 0), then brute force search them in order from K1 upwards, saving the best result for each. Can run through all unvoiced and voiced this way -- unvoiced should take 96 tests and voiced 168, because the size of each K parameter is added rather than multiplied if this approach works. (The parameters are tested by simulating their output and determining how close it sounds, seems you have a good approximation for that already!)

Well... I'm already looking for the coefficients like this. First K1 cycles through all values with K2 through K10 being 0 (that is value 0, not code 0), then K2 cycles through all its values with the best value of K1 being fixed by that point. And so on... However, I could try to use the values of the previous frame as the basis for the new frame instead of all 0's... maybe this would speed up the process since the changes from one frame to the next are often very small. And as I already said, I'll need to make it less bassy... but I also have other things to do in my life, I've spent already way too many hours on this last weekend and this Friday. :-)

Edited November 23, 2014 by Kurt_Woloch

[+OLD CS1]

I've now recorded MESS's output of my program for you. In order not to distort anything, I've only converted it to mono and normalized it, but not converted it to an MP3, hence the WAV file attached here.

 

I will also use this to fine-tune my program. The result actually seems a bit to bassy now compared to the original version, I wonder how it sounds on a real TI-99, but I think it will be similar to this.

 

In VLC Player, setting the equalizer to "Ska" approximates, in my approximation, what it should sound like on a real machine.

[Tursi]

Sounds like you're already implementing most of my ideas. Congratulations on coming so far, and I hope you do continue to tune it a bit and release it.

[Gazoo]

Has anyone used the Playground to make an EA5 program loader? That is, you run the Playground program and when it loads, it asks you to enter an EA5 filename to run.

I know there was source for an EA5 loader created within the past few years, and could probably put together what's needed, but it would be easier if someone has already done it.

 

Gazoo

[Gazoo]

Hmm.... No one responded to my inquiry, so I looked over the Playground docs and noticed that the 32k Ram is turned off and the program is stored in VDP instead. For the EA5 loader program I'm looking to create, the 32k would need to be on. I'm in need of an EA5 loader that runs from Basic with no cartridge in the slot to complete my current project.

 

Anyone?

 

Gazoo

[+Ksarul]

I haven't seen one as of yet, Gazoo--and my programming skills are insufficient to the task, unfortunately.

[Gazoo]

I found a lead that might be exactly what I'm looking for, anyone know anything about the program described below?

 

"E/A#5 loader for TI BASIC -- 26 Apr 09"

I seem to remember Bill Sullivan was working on this in the Old Yahoo Group, but never knew what became of it, or if it was ever completed.

Gazoo

[+Lee Stewart]

 

I found a lead that might be exactly what I'm looking for, anyone know anything about the program described below?

 

"E/A#5 loader for TI BASIC -- 26 Apr 09"

I seem to remember Bill Sullivan was working on this in the Old Yahoo Group, but never knew what became of it, or if it was ever completed.

Gazoo

 

 

Tony, would the loader need to provide the E/A routines (KSCAN, VMBR, etc.) in the usual places in low RAM?

 

...lee

[+Ksarul]

I remember that one--he was looking for it as part of his conversion of his version of Forth from the Geneve to to the TI-99/4A. I think that The Insaneone was part of that effort. . .so you may find out more if you direct a question his way.

[Gazoo]

 

Tony, would the loader need to provide the E/A routines (KSCAN, VMBR, etc.) in the usual places in low RAM?

 

...lee

 

No, the EA5 program is completely self sufficient. It just needs to load from TI BASIC with no cartridge in the slot and no other 'helper' device such as a ramdisk. Two segments will need to be loaded, at >A000 and >BFFA. Start address >A000.

[senior_falcon]

Hmm.... No one responded to my inquiry, so I looked over the Playground docs and noticed that the 32k Ram is turned off and the program is stored in VDP instead. For the EA5 loader program I'm looking to create, the 32k would need to be on. I'm in need of an EA5 loader that runs from Basic with no cartridge in the slot to complete my current project.

 

Anyone?

 

Gazoo

This should be pretty easy for you. First, the 32K is not turned off. If it is present it can be used. You can write a program for playground that uses BSS to reserve space for the loader program segments at >A000 and >BFFA. (It might help to label the buffers with something like TEXT "BUFFER1" and TEXT "BUFFER2" so you can easily find them. The actual code that would run under playground would probably only require one page. It would simply use the playground equivalent of VMBR to read the code out of the buffers in VDP and into >A000 and >BFFA and then B @>A000. Figure out where the buffers are and make a note of it. Save this program per the instructions as DSK1.LOADER. You then need to write a simple AL program that uses VMBW to copy the code at >A000 and >BFFA into the buffers in VDP. AORG this to a safe place in low memory.

Then:

OLD DSK1.LOADER

load the AL program to low memory

Then load the AL loader program (but don't run it).

Run the AL program in low memory to copy the code in high memory into the VDP buffers.

SAVE DSK1.LOADER and you should be good to go.

[Gazoo]

This should be pretty easy for you. First, the 32K is not turned off. If it is present it can be used. You can write a program for playground that uses BSS to reserve space for the loader program segments at >A000 and >BFFA. (It might help to label the buffers with something like TEXT "BUFFER1" and TEXT "BUFFER2" so you can easily find them. The actual code that would run under playground would probably only require one page. It would simply use the playground equivalent of VMBR to read the code out of the buffers in VDP and into >A000 and >BFFA and then B @>A000. Figure out where the buffers are and make a note of it. Save this program per the instructions as DSK1.LOADER. You then need to write a simple AL program that uses VMBW to copy the code at >A000 and >BFFA into the buffers in VDP. AORG this to a safe place in low memory.

Then:

OLD DSK1.LOADER

load the AL program to low memory

Then load the AL loader program (but don't run it).

Run the AL program in low memory to copy the code in high memory into the VDP buffers.

SAVE DSK1.LOADER and you should be good to go.

 

This looks as if you're saving the entire contents of the 2 EA5 program segments in the BASIC program itself. There won't be room for that as it would use nearly all of the 16k of VDP, with no room to do anything else. My intent is for the BASIC program to just be a loader for the EA5 program and when it runs it loads the files DSK1.UTIL1 and DSK1.UTIL2 and executes the program. I'll have to study the rules of Playground a bit to see how to do this. Thanks for providing the info that the 32k remains turned on.

 

Gazoo

[senior_falcon]

What are UTIL1 and UTIL2? Are they the loader that you want to run from >A000 and >BFFA?

[Gazoo]

What are UTIL1 and UTIL2? Are they the loader that you want to run from >A000 and >BFFA?

 

They are the EA5 Program files to be executed, one EA5 program in 2 segments. I want the BASIC program to load and run them.

 

For example;

You have the EA5 program Disk Manager 1000 on DSK1. The filenames for the program are MG which loads at >A000, and MH which loads at >BFFA.

You would normally run this program by selecting 5 from the EA cart menu and typing DSK1.MG, then pressing enter. The EA cart loads the files and branches to >A000, where the Disk Manager 1000 program executes from.

 

I want to load to load Disk Manager 1000 from BASIC instead, so from the BASIC command line I would enter OLD DSK1.LOADER and press enter. Then I would type RUN and press enter. The BASIC program 'LOADER' would then run, load the 2 files DSK1.MG and DSK1.MH, and branch to >A000 to start the program the way the EA cart would.

 

That's the BASIC program in it's simplest form. One could get fancy and prompt for the EA5 filename to run, but I don't really need that option.

 

 

Gazoo

[senior_falcon]

Probably your best bet is to write your own loader (or adapt one) that loads somewhere in low memory. Check that out to be sure it loads DM1000 the way you want it to. Then follow my recipe above to embed the loader you just wrote into VDP ram following the recipe above. That should work for you.

[Gazoo]

BASICloader.dsk

 

I have source and object code on the attached disk, along with DM1000 in the form of UTIL1 and UTIL2.

 

The code is >AORG'd in low memory at >3000 as suggested. The code has no dependencies on the EA cart. When the object code is loaded with TI BASIC through CALL INIT, CALL LOAD("DSK1.OBJECT"), and CALL LINK("START"); it loads and runs DM1000 correctly.

 

However, when I try to make a BASIC program with the object code embedded per the Playground directions, I get strange objects on the screen and it obviously doesn't work.

 

Any ideas?

 

Gazoo

 

[senior_falcon]

Will take a look tonight.

[Gazoo]

Will take a look tonight.

 

Thanks, Falcon.

 

You've helped me do weird things in the past to get the results I'm looking for. This is one of those times.

I'm not trying to load DM1000, but something else. But you've probably guessed that.

 

Gazoo

[senior_falcon]

Attached is a TI BASIC program that does what you want. Add this to the disk image you posted above. Type OLD DSK1.DM1000BX and then RUN and it will put your loader into memory at >3000 and run it to load DM1000. Here's how I did it:

The first step is to be sure your loader works in the TI BASIC environment using the EA cartridge, and of course, it does.

Next step is to find out how long the loader is. CALL LOAD("DSK1.OBJECT") will load it to >3000 where it was AORG'd. Take a look with the Classic99 debugger to be sure it is where it should be and then find the end of the program. Your source code shows the end of the program is >0800,>0000,>0000,>0000,>0000 and you must not ignore those trailing zeros. I found that the program goes from >3000 to >3771 for a length of >0772 bytes.

The first program below is to be used with playground. It is a short one page program that copies a >772 byte long buffer in VDP into CPU at >3000. Note the "STARTBUFFER" text at the beginning of the buffer. Save (as MOV2CPU.TXT) and assemble this program as MOV2CPU.OBJ.

Embed this in a BASIC program as described on page 4 of the Playground docs.

CALL INIT
CALL LOAD("DSKn.MOV2CPU.OBJ") this will load MOV2CPU starting at >A000 (The normal start of an assembly program in E/A)
CALL LOAD("DSKn.MAKEBX-O") this loads the code that will embed MOV2CPU in a BX program
CALL LOAD(-31804,240) this runs MAKEBX and creates the BASIC program.

I changed the REM in line 10 to briefly describe what the program does.

SAVE this program as DM1000BX, then look into VDP with the classic99 debugger. "STARTBUFFER" began at >3066 in VDP ram.

At this point you have created a BASIC language loader that contains a buffer long enough to hold the assembly code you want to load. You have found out where the buffer is in VDP ram, but it is empty. Next step is to copy the assembly code into the buffer.

The second program below will copy >0772 bytes from CPU ram starting at >3000 and put them into VDP ram starting at >0366, then return to BASIC. Save (as MOV2VDP.TXT) and assemble this as MOV2VDP.OBJ. This program is very short (22 bytes long) so it can be loaded into low memory using CALL LOAD and be well short of Gazoo's loader that is AORG'd at >3000.

The following lines will finish the job:

CALL INIT

OLD DSK1.DM1000BX (loads the playground program with the >0772 byte long buffer embedded)

CALL LOAD("DSK1.OBJECT") (loads the loader for DM1000) Gazoo's E/A5 loader program AORG'd to >3000

CALL LOAD("DSK1.MOV2VDP.OBJ") (loads the subroutine to copy loader to the playground program)

CALL LINK("MOVPRG") (now the loader is in the VDP buffer)

SAVE DSK1.DM1000BX and now the program is saved and ready for use

 

Edited June 8, 2015 - changes in blue.

*Move Loader from VDP to CPU for Gazoo, March 22,2015
        
WKSP	EQU >83A2			don't need the PAGE, SUB, SUBPAG equates
LD2CPU	DATA BUFFER-LD2CPS		Length of page to load to >8300
LD2CPS	LI R0,BUFFER-1
	A R13,R0			R0 will point to start of buffer in VDP
	LI R1,>3000			will move buffer to >3000 in CPU
	MOVB @WKSP+1,*R15		VDPWA is in R15
	MOVB R0,*R15
LDRLP	MOVB *R14,*R1+		Read the byte	
	CI R1,>3772			read them all?
	JNE LDRLP			no, keep looping
	B @>3000			done, start program
BUFFER	TEXT 'STARTBUFFER12345'  	>10 bytes long
	BSS >0762  			loader is >0772 bytes long  	
	
	END
**************************************************************
*this copies code from low memory into VDP buffer
	REF VMBW
	DEF MOVPRG

*found this address with Classic99 debugger after creating the playground program	
MOVPRG	LI R0,>3066	write to >3066 in VDP, start of the buffer
	LI R1,>3000	copying from >3000 in CPU
	LI R2,>0772	>772 bytes in the loader program
	BLWP @VMBW	copy program to vdp buffer
	CLR @>837C
	B *R11		back to BASIC
	
	END

DM1000BX.zip

Edited June 8, 2015 by senior_falcon

[+Ksarul]

Now that beautiful little program shows just how powerful the Playground environment can be. Many thanks for sharing it with us!

[Gazoo]

^ What ^ he ^ said ^. Thank you!