Game port prospect: Acorn Electron's Gunsmoke.

[Tursi]

I cheated a bit, but this works. It doesn't require a fixed workspace (and making that work revealed a tiny optimization for the asm player too)...

 

Anyway, this zip includes source code, but it also includes a disk image in the sample folder - boot from XB and it will load the player, load a song, and then let you mess around in XB while it plays on the interrupt. I don't know how nicely it will play with the compiler - I do maintain the existing interrupt hook but it will get called later.

 

The player is really basic, it just scans the DEF table for an entry called MUSIC, and assumes that's the music file to play.

 

In truth the player was never designed to play nicely with an environment we don't fully control, but... maybe this is still useful.

 

I didn't test the 30hz version, but it should also work with less of a CPU impact (and slightly less resolution).

 

vgmcomp_xb.zip

 

The main gotcha for using this, besides having enough RAM for your music, is prepping the music data to be loaded by XB. In the sample folder you'll see guile.a99 which I created with my own bin2inc tool in TI Assembly mode (https://harmlesslion.com/software/bin2inc), then I manually opened the file and added the DEF MUSIC at the top, and an END at the end to make the assembler happy. Then I just built it like any other source file with WinAsm99.

 

I provide some sample subroutines to patch the behaviour but I didn't build much more than start and stop in. It's enough to show it working and see whether it's going to be too much hassle to merge in...

 

[senior_falcon]

5 hours ago, Tursi said:

 

Does anything prevent use of the scratchpad workspace at >8300? (It looks busy, maybe >8320?)

 

Do you have a link to the current compiler manual? The copy I have in Classic99 is way out of date, and says assembly isn't allowed except for what's in XB256  Though mostly I just wanted to check the legal workspace...

 

The thread for XB Game Developer's Package has the most recent version in post #1

 

It is a little bit of wishful thinking to think the compiler would not use whatever space is available in the scratchpad. >8300 is the main workspace, >8320 is the BLWPWS, and >83A0 is used to handle things like sound lists, etc. GPLWs is a possibility.

[senior_falcon]

2 hours ago, Tursi said:

I cheated a bit, but this works. It doesn't require a fixed workspace I assume that means you are using the GPLWS (and making that work revealed a tiny optimization for the asm player too)...

 

Anyway, this zip includes source code, but it also includes a disk image in the sample folder - boot from XB and it will load the player, load a song, and then let you mess around in XB while it plays on the interrupt. I don't know how nicely it will play with the compiler - I do maintain the existing interrupt hook but it will get called later.

This should be fine.

 

The main gotcha for using this, besides having enough RAM for your music, is prepping the music data to be loaded by XB. In the sample folder you'll see guile.a99 which I created with my own bin2inc tool in TI Assembly mode (https://harmlesslion.com/software/bin2inc), then I manually opened the file and added the DEF MUSIC at the top, and an END at the end to make the assembler happy. Then I just built it like any other source file with WinAsm99.

 

I provide some sample subroutines to patch the behaviour but I didn't build much more than start and stop in. It's enough to show it working and see whether it's going to be too much hassle to merge in...

 

If you can fit everything into low memory from >24F4 to >3FFF then this should work. (Provided GUNSMOKE fits into high memory. ) There cannot be any funny business such as AORGing to high memory addresses.

You should be able to test it in XB to see whether it all works properly, then follow the steps in the manual to convert into a form that the compiler can interface with. If it works in XB but you cannot get it working with compiled code let me know.

[Tursi]

7 hours ago, senior_falcon said:

The thread for XB Game Developer's Package has the most recent version in post #1

 

It is a little bit of wishful thinking to think the compiler would not use whatever space is available in the scratchpad. >8300 is the main workspace, >8320 is the BLWPWS, and >83A0 is used to handle things like sound lists, etc. GPLWs is a possibility.

Not my wishful thinking, I never used to mix XB and Asm... it's still rather mysterious to me

 

Can't use GPLWS, though, the player needs a full workspace. I ended up shoving it in 8-bit RAM with the variables... it still runs well enough.

 

You should be able to test it in XB to see whether it all works properly, then follow the steps in the manual to convert into a form that the compiler can interface with. If it works in XB but you cannot get it working with compiled code let me know.

 

Already tested it in XB and posted a disk image - in fact you replied to that post.  I don't really have time to test it through the whole compiler chain right now. We'll leave that for Whoami

 

[whoami999ster]

Thank to all of you al always ... the most part of your comments is like sanskrit for me but I will try put everithing togher and finally put a sound track in the game  .... in case I just come back to you before hang me up... 

I didn't take into account too much things I believed that with the "sound table" and with the XB256 compiler I was OK ... anyway I'll keep you informed on my progress ... unfortnately vacation is over and I come back to work so time available is too few...

thanks once again

[whoami999ster]

On 9/4/2021 at 1:12 PM, Tursi said:

I cheated a bit, but this works. It doesn't require a fixed workspace (and making that work revealed a tiny optimization for the asm player too)...

 

Anyway, this zip includes source code, but it also includes a disk image in the sample folder - boot from XB and it will load the player, load a song, and then let you mess around in XB while it plays on the interrupt. I don't know how nicely it will play with the compiler - I do maintain the existing interrupt hook but it will get called later.

 

The player is really basic, it just scans the DEF table for an entry called MUSIC, and assumes that's the music file to play.

 

In truth the player was never designed to play nicely with an environment we don't fully control, but... maybe this is still useful.

 

I didn't test the 30hz version, but it should also work with less of a CPU impact (and slightly less resolution).

 

vgmcomp_xb.zip 40.85 kB · 7 downloads

 

The main gotcha for using this, besides having enough RAM for your music, is prepping the music data to be loaded by XB. In the sample folder you'll see guile.a99 which I created with my own bin2inc tool in TI Assembly mode (https://harmlesslion.com/software/bin2inc), then I manually opened the file and added the DEF MUSIC at the top, and an END at the end to make the assembler happy. Then I just built it like any other source file with WinAsm99.

 

I provide some sample subroutines to patch the behaviour but I didn't build much more than start and stop in. It's enough to show it working and see whether it's going to be too much hassle to merge in...

 

I'm still in open water with the file conversion using bin2.inc command 

I tried to convert the  guile_gb.vgz.sbf in the vgmcomp_xb.zip using  ./bin2inc.exe guile_gb.vgz.sbf guile.a99 TI but I alwayd s get an empty file

where is my mistake ... any idea ? 

Here attached my sbf that I would like to convert ... is it in the right source format for bin2.inc command 

bgm.sbf

[senior_falcon]

10 hours ago, whoami999ster said:

Thank to all of you al always ... the most part of your comments is like sanskrit for me but I will try put everithing togher and finally put a sound track in the game  .... in case I just come back to you before hang me up... 

I didn't take into account too much things I believed that with the "sound table" and with the XB256 compiler I was OK ... anyway I'll keep you informed on my progress ... unfortnately vacation is over and I come back to work so time available is too few...

thanks once again

I can understand conventional sound lists, but for me this is more like Swahili or perhaps Linear A.

All I can tell you is that if you can get the sound working running from low memory, then there is a good chance that it can be combined with your program.

Or you can use a conventional sound list and that will work.

[Tursi]

Yeah, it'll all work from low memory, as long as the music fits.

 

You're missing the name of the array in your bin2inc command

C:\Users\tursilion>d:\tools\bin2inc
bin2inc by Tursi - http://harmlesslion.com
d:\tools\bin2inc infile outfile array_name [TI/Z80]
C style is used unless you specify an alternate format:
  TI  - TI 9900 Editor/Assembler style formatting
  Z80 - SDCC Assembler style formatting

 

So, note the bolded word: bin2inc.exe guile_gb.vgz.sbf guile.a99 MUSIC TI

 

(If it is still not working, it won't be silent, so show the error message )

 

It has to be called "MUSIC" for it to be found. To make it assemble by itself, you have to open guile.a99 and make two edits:

 

*
* Data file guile_gb.vgz.sbf - Sep 04, 2021
*
    DEF MUSIC

MUSIC
  BYTE >0C,>CA,>0C,>DC,>1D,>00,>01,>00  * 00000000 ........ //

...

 

  BYTE >07,>08,>02,>0E,>08,>07          * 00000D10 ...... //

* Size of data in above array
SIZE_OF_MUSIC EQU 3350

    END
 

Add the bolded lines at the top and end of the file. The DEF makes "MUSIC" show up in the DEFs table when it's loaded, and END is just so your assembler doesn't complain.

 

[whoami999ster]

10 hours ago, Tursi said:

Yeah, it'll all work from low memory, as long as the music fits.

 

You're missing the name of the array in your bin2inc command

C:\Users\tursilion>d:\tools\bin2inc
bin2inc by Tursi - http://harmlesslion.com
d:\tools\bin2inc infile outfile array_name [TI/Z80]
C style is used unless you specify an alternate format:
  TI  - TI 9900 Editor/Assembler style formatting
  Z80 - SDCC Assembler style formatting

 

So, note the bolded word: bin2inc.exe guile_gb.vgz.sbf guile.a99 MUSIC TI

 

(If it is still not working, it won't be silent, so show the error message )

 

It has to be called "MUSIC" for it to be found. To make it assemble by itself, you have to open guile.a99 and make two edits:

 

*
* Data file guile_gb.vgz.sbf - Sep 04, 2021
*
    DEF MUSIC

MUSIC
  BYTE >0C,>CA,>0C,>DC,>1D,>00,>01,>00  * 00000000 ........ //

...

 

  BYTE >07,>08,>02,>0E,>08,>07          * 00000D10 ...... //

* Size of data in above array
SIZE_OF_MUSIC EQU 3350

    END
 

Add the bolded lines at the top and end of the file. The DEF makes "MUSIC" show up in the DEFs table when it's loaded, and END is just so your assembler doesn't complain.

 

  still empy file ... am i so stupid? I run the command in the directory c:\TI99\Tools\bin2inc ... maybe the command should be in C:\ ? 

 

[Asmusr]

It doesn't work for me either. I'm also getting an empty output file and no error.

[Tursi]

Interesting. I've used the tool for over 20 years on pretty much every machine I've ever written code on, both at home and work, so yeah. OS version?

 

No, it doesn't matter where the tool itself lives... you can see it got as far as opening the file. I'll look and see if there is a silent exit path, but I suspect it crashed on you.

 

FWIW, you don't /have/ to use my tool. Dozens of people have written tools that turn binary files into ascii-readable bytes that can be run through an assembly (you might just have to do some search and replace to make it work with the TI assembler.) I think the xdt99 tools can even import that binary raw?

 

But I'll check into this tonight.

 

[whoami999ster]

WE LIKE YOU TOOL .... BIN2INC FOR PREIDENT!

 

Edition    Windows 10 Enterprise
Version    20H2
Installed on    ‎12/‎05/‎2021
OS build    19042.1165
Experience    Windows Feature Experience Pack 120.2212.3530.0

 

Processor    Intel(R) Core(TM) i7-8650U CPU @ 1.90GHz   2.11 GHz
Installed RAM    16,0 GB (15,8 GB usable)
System type    64-bit operating system, x64-based processor
Pen and touch    Touch support with 10 touch points
 

[Tursi]

Downloaded all and confirmed your results. On my machine it hangs for a second before exiting.

 

Broken upload, I guess. Replaced it with my latest and it worked, so I just remade the zip and re-uploaded.

 

Sorry about the hassle - redownload bin2inc - https://harmlesslion.com/software/bin2inc

 

[whoami999ster]

EUREKA!!! IT WORK!!!

 

No apologize please ... that's me to say thank you ... above al for your patience ... 

 

thank and Ciao

Francesco

 

PS show must go on ... next level compile the soudtrack and add it to the game... 

[Asmusr]

8 hours ago, Tursi said:

Downloaded all and confirmed your results. On my machine it hangs for a second before exiting.

 

Broken upload, I guess. Replaced it with my latest and it worked, so I just remade the zip and re-uploaded.

 

Sorry about the hassle - redownload bin2inc - https://harmlesslion.com/software/bin2inc

 

Thanks for sharing this. I guess many of us who have been doing cross platform development for a while have a whole library of tools that we don't share because they are either too specific or because we don't want to support them. It looks like I have 17 different Java tools where I have only shared the one to revert the banks of a ROM. I guess my point is that if anyone is looking for a tool for a development task, you might get what you need by asking in this forum.

[whoami999ster]

Finally the sound table in assembly language is here ... but folliwng the XB256 Manual (from page 12 to page 21) I didn't find and understand how generate from my .txt file XB sound program...

manual say at page 21 :"Once created, the sound table should be assembled and loaded as described above in the SLCOMPILER tutorial." ... but obviously If I try with copy/paste my txt in XB I get only errors...

I'm missing a step ... which is the missing step?

a little hand would be appreciated  

bgm_xb.txt XB256.pdf

[Asmusr]

5 hours ago, whoami999ster said:

I'm missing a step ... which is the missing step?

You should follow Tursi's instructions in vgmcomp_xb instead of the XB256 manual.

[whoami999ster]

1 hour ago, Asmusr said:

You should follow Tursi's instructions in vgmcomp_xb instead of the XB256 manual.

I was able to play my "bgm" file with the Tursi's player in vgmcomp_xb ... so I could include that code in the XB pgm. of the game but I would like to avoid the CALL LOAD("DSK1.TISNONLY") and CALL LOAD("DSK1.GUILE")  and have only one pgm ... could you help me with this ? 

YYY.dsk

Edited September 9, 2021 by whoami999ster
errata corrige

[Tursi]

Well, since you have to assemble it anyway, you could just copy/paste tiSNOnly.a99 into the same file as Guile.a99 and build them together (just make sure there's only one "END" statement ). That will give you a single object file and should load fine. (I did a quick test here and it worked fine).

 

When you modify the XB side, just make very sure you keep the CALL LINK("STOPSN") after the load. That does some startup initialization on the player. (The earlier STOPSN is also important - if you run the program twice in a row, it makes sure that the interrupt is turned off before the CALL LOAD happens - otherwise you'll probably crash )

 

But yeah, just copy the code and data into the same assembler source file. Delete the extra END and it will work fine.

 

 

[Tursi]

Even though some of this discussion has moved over into the XB256 thread, I wanted to post the update here so it's all in one place.

 

To be clear to future generations reading this thread, the XB player is part of the VGMComp2 package and the latest version is also in that.

 

Anyway, this is an updated zip to help compatibility with the compiler - the only real change is that it recognizes both 'MUSIC' and 'music' as the DEF tag for the song, but this required changes to the TISNOnly.obj and the XB subroutines that were in the readme file. Everything XBish is still in this archive.

 

ti_xb.zip

 

 

[senior_falcon]

I have worked out how to include Tursi's music player in a compiled program.

The docs for the compiler do not properly describe how to include assembly subs with XB256 programs. Here's how to do it: (Throughout this I will assume all the files are all on DSK1. If they are on a different disk, then use that disk number)

First, you were able to use Tursi's software to create BGM_XB.TXT

This file contains the compressed sound data. You need to make one small modification to it:

Modify BGM_XB.TXT by removing AORG >A000 (or any other AORG)
Save the modified BGM_XB.TXT file

Now you must assemble the file. With XBGDP in DSK1:
Choose Assembler from menu
For SOURCE file name, use DSK1.BGM_XB.TXT
For OBJECT file name, use DSK1.BGM_XB.OBJ
Press ENTER three times. and BGM_XB should be assembled

 

Now you can test it out. Get into Extended BASIC, then:

CALL INIT
CALL LOAD("DSK1.TISNONLY.OBJ") This loads the player. Be sure to use the new version that Tursi just posted.
CALL LOAD("DSK1.BGM_XB.OBJ")  This loads the music file that you just assembled
CALL LINK("SONGGO") to play
CALL LINK("STOPSN") to stop sound

Now you must convert it so it is compatible with the compiler. From Extended BASIC:

CALL LOAD("DSK1.FIXAL")
CALL LINK("X")
LIST (optional) and you will see 10 CALL LOAD(8192,255,172):: CALL LINK("X")
SAVE DSK1.GAMEMUSICC

Now the compressed music and the player have been saved as an XB loader that will load the music and player to low memory when it is run.

 

(Edit) About 4K of memory is left that can be used for more music
When the game music is the way you like it, you do not have to repeat this step.

 

Now you compile the XB256 program:

QUIT; PRESS 2 FOR XB; and select XB256 at the menu. For testing I made a small XB program called HVTEST. This randomly uses HCHAR and VCHAR to put stuff on the screen.
OLD DSK1.HVTEST to load the program
Test it out, but remember you cannot use Tursi's sound player and XB256 at the same time.

They are built into the compiler so DO NOT use "UC2LC" to convert the CALL LINKs to lower case
Add a line to start the music:
90 CALL LINK("songgo")  this must be lower case. It should be at the place in the program where you want the music to start.
SAVE and compile as usual.

After the Compiler and Assembler have done their jobs you come to the lMUSICTEST.zipoader.
Enter Y for "Using Assembly Support?"
You are prompted for "Compiled file to load?" This should be the file you just compiled and assembled.
DSK1.HVTEST.OBJ
Then you are prompted "Assembly routines to load?"
DSK1.FILENAME
change this to DSK1.GAMEMUSICC
Press Enter when the cursor appears.
Then you can save as EA5: DSK1.HVTEST-E
And you can save as XB: DSK1.HVTEST-X
RUN lets you test out the hybrid A/L and compiled program.

EA5 programs need no modification. One more step is needed if you want to run the program from XB:
OLD DSK1.GAMEMUSICC
Modify line 10:
10 CALL INIT :: CALL LOAD(8192,255,172):: CALL LINK("X"):: RUN "DSK1.HVTEST-X"

Then: SAVE DSK1.HVTEST-AL
When you run DSK1.HVTEST-AL the assembly routines (in this case the music and player) are loaded to low memory, then the compiled program, DSK1.HVTEST-X, is loaded and run.

 

if you are running from XB and break the program with Fctn 4, the music hangs up on the last note. Press a letter, press enter, and the error message will clear the sound generator.

 

MUSICTEST.zip

 

 

Edited September 12, 2021 by senior_falcon

[Tursi]

Nice! An additional solution to the last note hanging is to just make sure your input song ends with a mute command. If it doesn't, you can manually add one to the psg file (the one you create with prepare4sn.exe) by adding one extra line with all the volumes set to 0xf:

0x00001,0xF,0x00001,0xF,0x00001,0xF,0x00001,0xF

 

[senior_falcon]

There is about 4K of memory left for more music. And also, I would think that being able to play different music at different places in the game would be desirable.

Edited September 13, 2021 by senior_falcon

[whoami999ster]

On 9/12/2021 at 12:41 AM, senior_falcon said:

I have worked out how to include Tursi's music player in a compiled program.

The docs for the compiler do not properly describe how to include assembly subs with XB256 programs. Here's how to do it: (Throughout this I will assume all the files are all on DSK1. If they are on a different disk, then use that disk number)

First, you were able to use Tursi's software to create BGM_XB.TXT

This file contains the compressed sound data. You need to make one small modification to it:

Modify BGM_XB.TXT by removing AORG >A000 (or any other AORG)
Save the modified BGM_XB.TXT file

Now you must assemble the file. With XBGDP in DSK1:
Choose Assembler from menu
For SOURCE file name, use DSK1.BGM_XB.TXT
For OBJECT file name, use DSK1.BGM_XB.OBJ
Press ENTER three times. and BGM_XB should be assembled

 

Now you can test it out. Get into Extended BASIC, then:

CALL INIT
CALL LOAD("DSK1.TISNONLY.OBJ") This loads the player. Be sure to use the new version that Tursi just posted.
CALL LOAD("DSK1.BGM_XB.OBJ")  This loads the music file that you just assembled
CALL LINK("SONGGO") to play
CALL LINK("STOPSN") to stop sound

Now you must convert it so it is compatible with the compiler. From Extended BASIC:

CALL LOAD("DSK1.FIXAL")
CALL LINK("X")
LIST (optional) and you will see 10 CALL LOAD(8192,255,172):: CALL LINK("X")
SAVE DSK1.GAMEMUSICC

Now the compressed music and the player have been saved as an XB loader that will load the music and player to low memory when it is run.

 

(Edit) About 4K of memory is left that can be used for more music
When the game music is the way you like it, you do not have to repeat this step.

 

Now you compile the XB256 program:

QUIT; PRESS 2 FOR XB; and select XB256 at the menu. For testing I made a small XB program called HVTEST. This randomly uses HCHAR and VCHAR to put stuff on the screen.
OLD DSK1.HVTEST to load the program
Test it out, but remember you cannot use Tursi's sound player and XB256 at the same time.

They are built into the compiler so DO NOT use "UC2LC" to convert the CALL LINKs to lower case
Add a line to start the music:
90 CALL LINK("songgo")  this must be lower case. It should be at the place in the program where you want the music to start.
SAVE and compile as usual.

After the Compiler and Assembler have done their jobs you come to the lMUSICTEST.zipoader.
Enter Y for "Using Assembly Support?"
You are prompted for "Compiled file to load?" This should be the file you just compiled and assembled.
DSK1.HVTEST.OBJ
Then you are prompted "Assembly routines to load?"
DSK1.FILENAME
change this to DSK1.GAMEMUSICC
Press Enter when the cursor appears.
Then you can save as EA5: DSK1.HVTEST-E
And you can save as XB: DSK1.HVTEST-X
RUN lets you test out the hybrid A/L and compiled program.

EA5 programs need no modification. One more step is needed if you want to run the program from XB:
OLD DSK1.GAMEMUSICC
Modify line 10:
10 CALL INIT :: CALL LOAD(8192,255,172):: CALL LINK("X"):: RUN "DSK1.HVTEST-X"

Then: SAVE DSK1.HVTEST-AL
When you run DSK1.HVTEST-AL the assembly routines (in this case the music and player) are loaded to low memory, then the compiled program, DSK1.HVTEST-X, is loaded and run.

 

if you are running from XB and break the program with Fctn 4, the music hangs up on the last note. Press a letter, press enter, and the error message will clear the sound generator.

 

MUSICTEST.zip 24.45 kB · 3 downloads

 

 

Dear friend ... where I can find FIXAL pgm? 

Thanks and Ciao

[tmop69]

2 minutes ago, whoami999ster said:

Dear friend ... where I can find FIXAL pgm? 

Thanks and Ciao

It's already included in the directory of the BASIC compiler if you are using the "JUWEL" version.