Playing a module from INCBIN in AmiBlitz 3.8

[zooperdan]

I'm banging my head on this.

This code works in BB2.1 and plays the song, but in AmiBlitz3.8 the song isn't played. There are no errors, just quiet.

Any thoughts on this?

fastmem.b=AvailMem_(4) ; 4=fast, 2=chip

If fastmem ; is fastmem available? if so, better copy the module to chipmem
  music_length.l=?title_music_end-?title_music_start
  InitBank 0,music_length,2
  dn.l=0
  For dn=0 To music_length-1 Step 4
    Poke.l Bank(0)+dn, Peek.l(?title_music_start+dn)
  Next
  MTInit 0,0
Else ; if no fastmem is detected, the module must be in chipmem
  MTInit ?title_music_start,0,0
EndIf

MTPlay On

MouseWait

MTEnd

If fastmem
  FreeBank 0
EndIf

End

title_music_start:
IncBin "files/title.mod"
title_music_end:

[Nightshft]

Seems like (unlike in older versions of Blitz) now it's needed to use the MTInstall command before using the mtInit command.

mtInstall True;   true..pal  false..ntsc

Not sure why this is now needed. It fixed it here, can you confirm?

FreeBank throws a "Program Error 8000.002B" every time here.
Which is "Trap Vector. Pgm out of control." So I guess, we just omit it?

Oh, and maybe you should add something like "4" to music_length at InitBank to avoid overwriting unallocated memory in the loop...

Regards, Stefan

Edit: And also note that the vbr must not be moved IIRC, otherwise ptPlayer is muted/doesn't play. This did cost me a few hours in the past to find out.

[zooperdan]

Originally Posted by Nightshft

Seems like (unlike in older versions of Blitz) now it's needed to use the MTInstall command before using the mtInit command.

mtInstall True;   true..pal  false..ntsc

Not sure why this is now needed. It fixed it here, can you confirm?

I still can't hear anything even with MTInstall True. No errors either.

Originally Posted by Nightshft

Oh, and maybe you should add something like "4" to music_length at InitBank to avoid overwriting unallocated memory in the loop...

I will try this when I get home.

Originally Posted by Nightshft

Edit: And also note that the vbr must not be moved IIRC, otherwise ptPlayer is muted/doesn't play. This did cost me a few hours in the past to find out.

Sorry, but what do you mean by vbr?

Thanks for the reply.

[Nightshft]

Vbr is the (Interrupt) Vector Base. It is possible to move it from adress zero (chipram) to fastmem for some (small) speed gain.
Tools like vbrMove (link) do this.

When you compile and run a program in debug mode in AB3, the debugger complains if you don't have the vbr moved. That's why I have put vbrMove in my AB3 startup script in the first place.

But AFAIK there's a bug in the ptPlayer library (or core) and it's muted when the vbr-adress is moved, so it should just stay untouched/at the default zero adress when using ptPlayer.

Check if your debugger complains about the vbr. It should.

[phx]

Originally Posted by Nightshft

But AFAIK there's a bug in the ptPlayer library (or core) and it's muted when the vbr-adress is moved

It haven't seen the Blitz Basic layer for ptplayer, but I would guarantee that the player itself works with any VBR.

At the beginning you have to call _mt_install_cia with the VBR in a0 and a PAL/NTSC-flag in d0. The Blitz Basic MTinstall function probably passes the PAL-flag and calls that _mt_install_cia core function. But who knows what it passes for VBR...

[E-Penguin]

Originally Posted by phx

It haven't seen the Blitz Basic layer for ptplayer, but I would guarantee that the player itself works with any VBR.

At the beginning you have to call _mt_install_cia with the VBR in a0 and a PAL/NTSC-flag in d0. The Blitz Basic MTinstall function probably passes the PAL-flag and calls that _mt_install_cia core function. But who knows what it passes for VBR...

I don't know if this helps but the blitzbasic wrapper stuff is here

https://github.com/idrougge/blitz_ptplayer

[phx]

Originally Posted by E-Penguin

https://github.com/idrougge/blitz_ptplayer

Ok, as expected VBR is just assumed to be NULL. The following preamble was added by idrougge to the _mt_install_cia function in ptplayer.asm for Blitz support:

        movem.l a3-a6,-(sp)
        lea CUSTOM,a6
        move.l #0,a0

Ptplayer is not really intended to run with AmigaOS still alive, so the question is how to get the VBR, when Blitz Basic doesn't provide it with some function or variable?

Your only option would be to insert an Exec

Supervisor()

call here, to switch to supervisor mode and read the VBR with

movec

on 68010 and greater.

So it is a hack, but you could replace the code from above with this:

        movem.l a3-a6,-(sp)
        sub.l   a0,a0
        move.l  4.w,a6
        btst    #0,297(a6)              ; check for 68010
        beq     .novbr
        lea     getvbr(pc),a5
        jsr     -30(a6)                 ; Supervisor()
.novbr: lea     CUSTOM,a6

Additionally, insert the getvbr function somewhere else in the source:

        mc68010
getvbr:
        movec   vbr,a0
        rte
        mc68000

[BastyCDGS]

Originally Posted by zooperdan

Any thoughts on this?

fastmem.b=AvailMem_(4) ; 4=fast, 2=chip

If fastmem ; is fastmem available? if so, better copy the module to chipmem
...

FYI, this is the wrong way doing it. You should use TypeOfMem_ with the address of INCBIN'd ProTracker and check if it's in chip RAM using MEMF_CHIP.

There are multiple (though rare) occasions where your code will fail, e.g. running NoFastMem AFTER starting your program. In that case, your code and module will be in fast RAM, but AvailMem for MEMF_FAST will return 0, therefore not copying module to chip RAM, although it would be needed.

EDIT: Also note that your executable (and thus module) could be in chip RAM, even if there is fast RAM available. For example, there is only 40KB of continuous fast RAM available, but your executable needs, let's say 48KB of continuous memory, then it will be loaded to chip RAM, causing an unnecessary copy of the module.

[E-Penguin]

Originally Posted by phx

Ok, as expected VBR is just assumed to be NULL.

I rebuilt the library with this. I don't have an Amiga handy, could someone with a moved VBR have a go?

I updated the rest of the library to the latest 6.1 from aminet while I was at it.

https://github.com/E-Penguin/blitz_ptplayer

[E-Penguin]

So, yes, I can confirm the updated library no longer causes BB2 to crash at MTInstall.

The library is ~2kb larger than idrougge's, I dunno if that'd due to vasm options or because ptplayer has grown between v5 and v6.1

I used this to assemble it:

vasm -phxass -Faout ptplayer.asm

[Honitos]

It is possible to change the libnumber from #195 or #48?

The older release had that number when I remember correctly.

#195 is within a range of Lotan's blitzlib collection, in this case LotanArgs.

[phx]

Originally Posted by E-Penguin

The library is ~2kb larger than idrougge's, I dunno if that'd due to vasm options or because ptplayer has grown between v5 and v6.1

Yes, there are some new features in it.

I used this to assemble it:

vasm -phxass -Faout ptplayer.asm

There shouldn't be any PhxAss-dependency in the source.
Blitz Basic requires object files in a.out format, not hunk-format?

[E-Penguin]

Originally Posted by Honitos

It is possible to change the libnumber from #195 or #48?

The older release had that number when I remember correctly.

#195 is within a range of Lotan's blitzlib collection, in this case LotanArgs.

Sure just let me know the new number you'd like. It's easy enough to change.

Originally Posted by phx

Yes, there are some new features in it.

There shouldn't be any PhxAss-dependency in the source.
Blitz Basic requires object files in a.out format, not hunk-format?

a.out seems to work... I'm no expert, I spotted the vasm options in another thread and just copied.

I tried -Fhunk and it's smaller but it crashes WinUAE.

btw -Fhunkexe doesn't assemble.

I have to confess to being a monkey pushing buttons here, I'm not really sure what I'm doing.

[phx]

Originally Posted by E-Penguin

I tried -Fhunk and it's smaller but it crashes WinUAE.

Hmm...

btw -Fhunkexe doesn't assemble.

I don't see any reason to make it an executable file, but there is also no reason why it shouldn't assemble.

I have to confess to being a monkey pushing buttons here, I'm not really sure what I'm doing.

I have no experience with Blitz Basic, so I don't know what kind of file format it expects for such extensions. But using a.out is interesting.

[E-Penguin]

I got -Fhunkexe working, there were some undefined symbols in the original, and a whole load of missing stubs used to save/restore a3-a6 (which blitz needs to be unaltered).

However, I don't know what's going on now, nothing works and WinUAE crashes when I try to compile anything... I fear I've broken my install and will need to start again. Anyway, @Honitos I've changed the library number to 48.

-------------------------------------------
Edited to add; I found the magic sauce on a thread here, the correct vasm options are:

vasmm68k_mot.exe -devpac -Fhunkexe -kick1hunks -nosym  ptplayer.asm -o ptplayer.obj

With that, everything is working now and the library has no longer ballooned in size. The github is updated.

Whilst I was at it, I added blitz functions for _mt_loopfx (MTLoopFx) and mt_stopfx (MTStopFx). The former takes a SfxStructurePointer which is described in the source; I've not created a .res for it.

[Honitos]

Thanks!


Gesendet von meinem SM-P610 mit Tapatalk

[Zener]

Thanks for compilib the lib to Blitz, I am planning to use it for the next version of the Redpill game creator.

Everything goes smoothly except the MTStopFx function,which it's giving me some trouble when it's not in the main blitz source file. It's weird but maybe I am doing something wrong with deflibs...

Originally Posted by E-Penguin

I got -Fhunkexe working, there were some undefined symbols in the original, and a whole load of missing stubs used to save/restore a3-a6 (which blitz needs to be unaltered).

However, I don't know what's going on now, nothing works and WinUAE crashes when I try to compile anything... I fear I've broken my install and will need to start again. Anyway, @Honitos I've changed the library number to 48.

-------------------------------------------
Edited to add; I found the magic sauce on a thread here, the correct vasm options are:

vasmm68k_mot.exe -devpac -Fhunkexe -kick1hunks -nosym  ptplayer.asm -o ptplayer.obj

With that, everything is working now and the library has no longer ballooned in size. The github is updated.

Whilst I was at it, I added blitz functions for _mt_loopfx (MTLoopFx) and mt_stopfx (MTStopFx). The former takes a SfxStructurePointer which is described in the source; I've not created a .res for it.

[E-Penguin]

what errors are you getting? I have to confess I've not tried the two functions I added

[Zener]

Originally Posted by E-Penguin

what errors are you getting? I have to confess I've not tried the two functions I added

In the Editor both are recognized but when compiling it looks like it's not finding the Stop one. No problem with Loop or any of the other functions.

As said, it could be my fault at generating deflibs