Vortex Tracker pt3 player for Mockingboard

[vi...@pianoman.cluster.toy]

Hello

so my most recent project is getting some 6502 assembly that can play
Vortex Tracker II .pt3 files on the Mockingboard
http://www.deater.net/weave/vmwprod/pt3_player/

Sample video of the prototype:
https://www.youtube.com/watch?v=q4F2GTq6iks

Vortex Tracker is commonly used to create AY-3-8910 music for the
ZX Spectrum and Atari ST and a large number of pt3 files can be found
on the internet. It was a challenge writing the decoder as the documentation
is in Russian and the only source code examples were in uncommented z80
assembly or else Russian-commented Pascal.

Why not just play YM5 files, the raw-register captures that most Apple II
players currently support?

The issue is uncompressed YM5 files are really huge. So you have to
do some sort of decompression on the fly, and even then you are looking
at 32k+ or more. This might be fine on a IIe with 128k of RAM, but I am
targetting a II+ where I don't have that much available

A PT3 file is a tracker format, meaning a list of notes, patterns, and
ornaments and can be played in place. Once you load the music file and
the player, no additional RAM is needed at all. It does take more CPU
than playing a YM5 file.

Currently my player is around 4k, but I think I can easily get it about
half that size (a lot of RAM is taken by lookup tables, and I am not
using the zero page much at all yet).

Vince

[Antoine Vignau]

Nice work Vince.

IIRC, the French Touch did or was working on such a player.

av

[qkumba]

Great work.
You could save a cycle in your interrupt handler by self-modifying it:

update_time:
inc FRAME_COUNT+1 ; 6
FRAME_COUNT
lda #0 ; 2
eor #50 ; 2
bne done_time ; 3/2nt

sta FRAME_COUNT+1 ; 4

Also, at the point of key_space and key_R, the carry is set from the CMPs, so you can BCS instead of JMP.

In the player, a bit with value #$40 doesn't need the LDA. You'll get the overflow flag set accordingly and can branch on that result (same idea for value #$80, where you get the sign flag set).

If it's of interest, I'd be happy to look at it more closely and make a PR.

[schamp...@skynet.be]

On Tuesday, 14 May 2019 23:15:11 UTC+2, vi...@pianoman.cluster.toy wrote:
> Hello
>
> so my most recent project is getting some 6502 assembly that can play
> Vortex Tracker II .pt3 files on the Mockingboard
> http://www.deater.net/weave/vmwprod/pt3_player/

ahhh I'm most busy with my job but I'll sure use that in my next production (if I ever find the time to do one!)

Thanks for sharing ! Writing players is really tedious :-) Lots of work that I won't have to do myself !

stF

[vi...@pianoman.cluster.toy]

On 2019-05-15, qkumba <peter....@gmail.com> wrote:
>
> If it's of interest, I'd be happy to look at it more closely and make a PR.

I'd be glad to have you make a pass over the code, though I do have a list of
things on my TODO list.

1. Merge some of the common code in decode_note()
2. Use a jump table for the two switch() statements in decode_note()
3. Make the frequency and volume table lookups use self-modify code
instead of checking which table to use at runtime
4. The time-length calculation can be much faster, it only needs to find
the length of one channel (not all three, right now re-using code)
5. I also should run some more PT3 files through to verify correctness,
I've only validated 3 so far.

some further out things

1. I think the z80 assembly version generates the lookup tables at startup,
potentially saving a lot of space
2. Each channel uses roughly 40 bytes of state, so 120 bytes total.
Putting that in the zero page will save a lot of space in the executable
(though wouldn't really help speed that much if I keep using index-X
addressing mode). I don't think game/demo authors would be excited
about giving up half the zero page though.

I'm not sure how much progress I'll make on this the next few days, especially
as I've gotten distracted with trying to get some visuals going with the player.

Vince

[vi...@pianoman.cluster.toy]

I've added some visualization to the pt3 player:

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

It's doing some PSX Doom style fire. Frame rate is still too low, even
after spending a bunch of time optimizing. It's subtle, but the fire
is split in 3rds and each part gets higher when the corresponding music
channel gets louder.

At the top the music notes from the tracker are also shown. I was hoping
to do some 3D-style effects there, but I'm going to have to free up some
more cycles first.

Vince

[fatdog projects]

This is awesome Vince! Is there any way to develop PT3 or YM5 on modern PC's, similar to OpenMPT?

[fatdog projects]

I now see the link to VortexTracker, sorry for the distraction :)

[vi...@pianoman.cluster.toy]

On 2019-05-17, fatdog projects <fatdogp...@gmail.com> wrote:

>> This is awesome Vince! Is there any way to develop PT3 or YM5 on
>> modern PC's, similar to OpenMPT?
>
> I now see the link to VortexTracker, sorry for the distraction :)

Yes, VortexTracker II is the tool most people use to make pt3 files.
It works reasonably well, though there is a bit of a learning curve
on some of the features.

It's a windows program, but I run it under Wine on Linux and it runs
fine that way.

Vince

[vi...@pianoman.cluster.toy]

so it turns out that FrenchTouch did have a working PT3 player that I
wasn't aware of.
https://www.youtube.com/watch?v=rD9yGx396Ek
and of course their interlaced GR images are much better than the ones I
came up with.


In any case I am almost done the first pass through the optimization of
my PT3 player. It should be possible to hit 3k / 20% of CPU. It could
be a bit smaller/faster by using 128 bytes of the zero page, but for now
I am trying to avoid that so the code can be used in other projects.

For reference the z80 implementation fits in roughly 2200 bytes. Part
of that is the better addressing modes and much easier 16-bit math.

Vince

[qkumba]

I have a PR open now.
envelope sliding seems to have a bug which I marked.

[Cyril Lambin]

This is an amazing achievement. I also wasn't aware that FT did a player.

This is really a game changer for future prods, for Latecomer I had to come with my own YM5 player (with a rebuilt packed partition)... but Vortex Tracker... all current AY composers know it :)

Thanks so much for this.

I tried it on my Apple IIc last night and it crashed, I'll try to check the code as soon as I have some time to figure out what's happening. If I find something I'll let you know.

[schamp...@skynet.be]

Well I actually used it :-)
I had to rip the player apart to just keep the core lib, took me an hour.
Maybe you could publish a bare minimum player so that anyone can pick it up more easily ?

Just to help others, here's my code :



.segment "CODE"

begin:
JSR load_the_song
jsr pt3_init_song
JSR init_the_player
funny:
;; do nothing while playing

NOP
JMP funny

RTS

PT3_LOC = $4000

.include "pt3_player/zp.inc"
.include "pt3_player/mockingboard_a.s"
.include "pt3_player/pt3_lib.s"
apple_ii: .byte $0


open_file_param:
.byte 3 ; three params
.word filename_bfr
.word $5000
ref_num0: .byte 0
filename_bfr: .byte 4 ; length
.asciiz "SONG"

read_file_param:
.byte 4 ; three params
ref_num1: .byte 0 ; ref_number
.word PT3_LOC
.word 20000
.word 0 ; actual length


load_the_song:
jsr $BF00 ; ret code in A
.byte $C8 ; OPEN
.word open_file_param

LDA ref_num0
STA ref_num1

jsr $BF00 ; ret code in A
.byte $CA ; READ
.word read_file_param

RTS






init_the_player:
;=======================
; Check for Apple II/II+
;=======================
; this is used to see if we have lowecase support

lda $FBB3 ; IIe and newer is $06
cmp #6
beq apple_iie

lda #1 ; set if older than a IIe
sta apple_ii
apple_iie:

;===============
; Init disk code
;===============

;; jsr rts_init

;===============
; init variables
;===============

lda #0
sta DRAW_PAGE
sta DONE_PLAYING
sta WHICH_FILE
sta LOOP

;=======================
; Detect mockingboard
;========================

; Note, we do this, but then ignore it, as sometimes
; the test fails and then you don't get music.
; In theory this could do bad things if you had something
; easily confused in slot4, but that's probably not an issue.

; print detection message

; lda #<mocking_message ; load loading message
; sta OUTL
; lda #>mocking_message
; sta OUTH
; jsr move_and_print ; print it

jsr mockingboard_detect_slot4 ; call detection routine
cpx #$1
beq mockingboard_found

; jmp forever_loop ; and wait forever

mockingboard_found:
; lda #<found_message ; print found message
; sta OUTL
; lda #>found_message
; sta OUTH
; inc CV
; jsr move_and_print

;============================
; Init the Mockingboard
;============================

jsr mockingboard_init
jsr reset_ay_both
jsr clear_ay_both

;=========================
; Setup Interrupt Handler
;=========================
; Vector address goes to 0x3fe/0x3ff
; FIXME: should chain any existing handler

lda #<interrupt_handler
sta $03fe
lda #>interrupt_handler
sta $03ff

;============================
; Enable 50Hz clock on 6522
;============================

sei ; disable interrupts just in case

lda #$40 ; Continuous interrupts, don't touch PB7
sta $C40B ; ACR register
lda #$7F ; clear all interrupt flags
sta $C40E ; IER register (interrupt enable)

lda #$C0
sta $C40D ; IFR: 1100, enable interrupt on timer one oflow
sta $C40E ; IER: 1100, enable timer one interrupt

lda #$E7
sta $C404 ; write into low-order latch
lda #$4f
sta $C405 ; write into high-order latch,
; load both values into counter
; clear interrupt and start counting
; 4fe7 / 1e6 = .020s, 50Hz

CLI
RTS



TIME_OFFSET EQU 13



;; ------------------------------------------------------------

interrupt_handler:
; pha ; save A ; 3
; A is saved in $45 by firmware
txa
pha ; save X
tya
pha ; save Y



; inc $0404 ; debug (flashes char onscreen)

bit $C404 ; clear 6522 interrupt by reading T1C-L ; 4

lda DONE_PLAYING ; 3
beq pt3_play_music ; if song done, don't play music ; 3/2nt
jmp check_keyboard ; 3
;============
; 13

pt3_play_music:

; decode a frame of music

jsr pt3_make_frame

; handle song over condition
lda DONE_SONG
beq mb_write_frame ; if not done, continue

lda LOOP ; see if looping
beq move_to_next

lda pt3_loop ; looping, move to loop location
sta current_pattern
lda #$0
sta current_line
sta current_subframe
sta DONE_SONG ; undo the next song

beq done_interrupt ; branch always

move_to_next:
; same as "press right"
ldx #$20
jmp quiet_exit

;======================================
; Write frames to Mockingboard
;======================================
; for speed could merge this into
; the decode code

mb_write_frame:


tax ; set up reg count ; 2
;============
; 2

;==================================
; loop through the 14 registers
; reading the value, then write out
;==================================

mb_write_loop:
lda AY_REGISTERS,X ; load register value ; 4

; special case R13. If it is 0xff, then don't update
; otherwise might spuriously reset the envelope settings

cpx #13 ; 2
bne mb_not_13 ; 3/2nt
cmp #$ff ; 2
beq mb_skip_13 ; 3/2nt
;============
; typ 5
mb_not_13:


; address
stx MOCK_6522_ORA1 ; put address on PA1 ; 4
stx MOCK_6522_ORA2 ; put address on PA2 ; 4
lda #MOCK_AY_LATCH_ADDR ; latch_address for PB1 ; 2
sta MOCK_6522_ORB1 ; latch_address on PB1 ; 4
sta MOCK_6522_ORB2 ; latch_address on PB2 ; 4
lda #MOCK_AY_INACTIVE ; go inactive ; 2
sta MOCK_6522_ORB1 ; 4
sta MOCK_6522_ORB2 ; 4

; value
lda AY_REGISTERS,X ; load register value ; 4
sta MOCK_6522_ORA1 ; put value on PA1 ; 4
sta MOCK_6522_ORA2 ; put value on PA2 ; 4
lda #MOCK_AY_WRITE ; ; 2
sta MOCK_6522_ORB1 ; write on PB1 ; 4
sta MOCK_6522_ORB2 ; write on PB2 ; 4
lda #MOCK_AY_INACTIVE ; go inactive ; 2
sta MOCK_6522_ORB1 ; 4
sta MOCK_6522_ORB2 ; 4
;===========
; 62
mb_no_write:
inx ; point to next register ; 2
cpx #14 ; if 14 we're done ; 2
bmi mb_write_loop ; otherwise, loop ; 3/2nt
;============
; 7
mb_skip_13:


;=================================
; Finally done with this interrupt
;=================================

done_interrupt:




;=================================
; Handle keyboard
;=================================

check_keyboard:
quiet_exit:
;; jsr clear_ay_both

;ldx #$ff ; also mute the channel
;; stx AY_REGISTERS+7 ; just in case

done_key:
exit_interrupt:

; pla ; restore a ; 4

pla
tay ; restore Y
pla
tax ; restore X
lda $45 ; restore A


rti ; return from interrupt ; 6

;============
; typical
; ???? cycles

[schamp...@skynet.be]

hmmm, juste to be clear : "my" code means I wrote it, but 90% of it comes from the original player, so "my" contribution is very little here :)

[vi...@pianoman.cluster.toy]

On 2019-06-04, Cyril Lambin <lam...@gmail.com> wrote:
> I tried it on my Apple IIc last night and it crashed, I'll try to
> check the code as soon as I have some time to figure out what's
> happening. If I find something I'll let you know.

yes, let me know. I test on the II+ and IIe but I don't have any
IIc hardware.

Two guesses. One the mockingboard code pokes around Slot4, not sure
if that will upset whatever is there on a IIc.

The other thing is the interrupt handling. The pt3 player just slaps
its interrupt handler at the vector, it doesn't do any chaining. It
also assumes the interrupt firmware acts like II+/IIe.

Vince

[vi...@pianoman.cluster.toy]

On 2019-06-04, schamp...@skynet.be <schamp...@skynet.be> wrote:
> Well I actually used it :-)
> I had to rip the player apart to just keep the core lib, took me an hour.
> Maybe you could publish a bare minimum player so that anyone can pick
> it up more easily ?

yes, the plan was hopefully to release something a bit easier to drop
into projects once the optimization is done. I wasn't expecting people
to start using it so quickly. Glad it worked!

We've got the code/memory usage down to about 2.75k now.
A few correcntess bugs were also fixed, depending when you grabbed the code.
I also should be running more files through my validation tests.

If you really want speed/size benefits though, there will have to be
different versions of the player. You can get it smaller if you use
1/2 of the zero page but I'm guessing the casual user won't want to do that.

Also one of my goals is to get the player so it can play 6-channel pt3
files, but that will complicate the code a lot so would probably be
a separate fork of the code.

Vince

[Cyril Lambin]

Le mercredi 5 juin 2019 16:36:29 UTC+2, vi...@pianoman.cluster.toy a écrit :
>
> yes, let me know. I test on the II+ and IIe but I don't have any
> IIc hardware.

I cloned the repository but I have yet find out how to compile the project on Windows 10 :)

I took a quick glance but it's a big project so I need more time. So far what I can see is that your code is a lot more cleaner than mine XD

> Two guesses. One the mockingboard code pokes around Slot4, not sure
> if that will upset whatever is there on a IIc.

The Mockingboard 4c is located in slot #4 and works the same way as a regular MB. For Latecomer I took the MB detection code from FT's Pure Noise (in boot.a).

The official documentation of MB4c states that if not detected, the MB4c can be enabled by poking those two addresses to make sure the mouse firmware in slot#4 gets disabled:
STA $C404
STA $C405
But I can do that in the monitor and it didn't change anything. It looks like the player crashes once the file is loaded, just after the first graphic effects refresh.

> The other thing is the interrupt handling. The pt3 player just slaps
> its interrupt handler at the vector, it doesn't do any chaining. It
> also assumes the interrupt firmware acts like II+/IIe.

The IIc ref manual doesn't point any difference, the user interrupt is located at $03fe.

But I can say that since I'm new to Apple 2 dev, I didn't succeed in using this vector, so for Latecomer I disabled the ROM and slapped my handler at $fffe.
I think that's more due to my inexperience than any compatibility issue :)

From what I can see, the IIc is not really different than an Enhanced IIe (65C02 etc.).
The two specifics of the IIc are the hardwired slots of course, and the VSYNC that doesn't work like on other models.

Also the IIc can do double buffering in DHGR, and I have no confirmation that it is possible on IIe (the IIe tech ref seems to say that it's not).

[Anthony Adverse]

> I tried it on my Apple IIc last night and it crashed, I'll try to check the code as soon as I have some time to figure out what's happening. If I find something I'll let you know.

Isn't the mouse going to be hiding in slot 4 somewhere? Or is that neither here nor there?

A

[schamp...@skynet.be]

> yes, the plan was hopefully to release something a bit easier to drop
> into projects once the optimization is done. I wasn't expecting people
> to start using it so quickly. Glad it worked!

The magic of Internet :-)

>
> We've got the code/memory usage down to about 2.75k now.

That's really small.

> If you really want speed/size benefits though, there will have to be
> different versions of the player. You can get it smaller if you use
> 1/2 of the zero page but I'm guessing the casual user won't want to do that.

Yeah. But here you're entering the realm of "finding the right balance", which will be different for many projects.

The real added value of your player, even if it sounds obvious, is the fact that it exists. That alone is enough to live with the lack of a super optimized version. Moreover, the size of the player is really tiny so it's already fit for a lot of purposes. So again, the value of the player, its small size, its ease of use are already so much worthy that any inconvenience such as "not that much optimized" are mostly irrelevant.

>
> Also one of my goals is to get the player so it can play 6-channel pt3
> files, but that will complicate the code a lot so would probably be
> a separate fork of the code.

I share that thought. Moreover, playing 6 tracks tunes may have an effect on performances as well.

thx again for having made it, as Cyril pointed, a good, easy to use player was much needed.

Stefan

[Cyril Lambin]

Le jeudi 6 juin 2019 05:33:51 UTC+2, Anthony Adverse a écrit :
> > I tried it on my Apple IIc last night and it crashed, I'll try to check the code as soon as I have some time to figure out what's happening. If I find something I'll let you know.
>
> Isn't the mouse going to be hiding in slot 4 somewhere? Or is that neither here nor there?

Yup, that's why you need to write to the slot#4 to enable Mockingboard, by default it's disabled for the mouse card to work worrectly.

From the Mockingboard 4c manual:

"Mockingboard 4c need to use the Slot#4, but, APPLE //c already using it, So, Mockingboard 4c can't use the slot#4 permanent and switching the Slot#4.
if you write to C403 address(In fact C400-C4ff) the Mockingboard awake and take the area of slot#4"

The manual states that it can be enabled manually by doing
*C403: FF FF

In Pure Noise French Touch does this with
STA $C404
STA $C405

I just tested with my demo, when I remove those two instructions, FrenchTouch's MB detection fails.

So that's something that should be added for the PT3 player to work on IIc in any case.

That said I'm not sure that's why the PT3 player crashes. Just after the tune's scan is done, it plots the first 4 lines of the fire effects, and gives me this:
C4DE- A=00 X=00 Y=00 P=76 S=50

[vi...@pianoman.cluster.toy]

On 2019-06-06, Cyril Lambin <lam...@gmail.com> wrote:
>
> That said I'm not sure that's why the PT3 player crashes. Just after the tune's scan is done, it plots the first 4 lines of the fire effects, and gives me this:
> C4DE- A=00 X=00 Y=00 P=76 S=50

I think it probably is an interrupt handler issue.

The address C4DE I think is in the slot 4 firmware.

I really don't know much about the IIc, but I'm guessing for things to work
proper interrupt chaining has to be implemented. The II+ and IIe typically
don't have any interrupts going on a freshly booted system, but maybe
the IIc is different.

Vince

[Antoine Vignau]

Whenever you access $CSxy, slot S is activated.
So, xy can be anything,
av

[vi...@pianoman.cluster.toy]

I was just reading up in the Apple IIc reference manual and am now more
confused than when I started.

It sounds like the IIc doesn't store the accumulator to $45 on interrupt?
That could break things, but I'm not sure how that would cause a jump
into the firmware at C4DE.

It might be useful to look at the French Touch code interrupt handler
and see if anything special is done there.

Vince

[vi...@pianoman.cluster.toy]

In comp.sys.apple2, you wrote:
> Le mercredi 5 juin 2019 16:36:29 UTC+2, vi...@pianoman.cluster.toy a écrit :
>>
>> yes, let me know. I test on the II+ and IIe but I don't have any
>> IIc hardware.
>
> I cloned the repository but I have yet find out how to compile the
> project on Windows 10 :)

the whole repository is big because I stick all of my Apple II projects
in one place. The pt3_player code should be fairly self contained in
the one directory.

The problem is it assumes you are building on Linux using ca65, and
also using my dos33fsutils to create the disk images. Not sure how
that would all work on Windows 10, but maybe if you installed the
Linux subsystem.

Vince

[Cyril Lambin]

Le jeudi 6 juin 2019 22:19:36 UTC+2, vi...@pianoman.cluster.toy a écrit :
>
> I was just reading up in the Apple IIc reference manual and am now more
> confused than when I started.
>
> It sounds like the IIc doesn't store the accumulator to $45 on interrupt?
> That could break things, but I'm not sure how that would cause a jump
> into the firmware at C4DE.
>
> It might be useful to look at the French Touch code interrupt handler
> and see if anything special is done there.

There is no active interrupt that I know of when the IIc boots up. There is a builtin mouse card but you need to activate it. The Vsync interrupt is also disabled by default.

It could also be because of an incorrect MB detection, maybe in that case some uninitialized variables make the memory corrupt and the CPU running junk code? I don't know. It shouldn't be trying to run something at $0C4x.

I just had a look at FT's code, and now I remember that I noticed that in the earliest version of his YM player he was using $03FE, and later he switched to $FFFE except when a IIgs is detected.

So I took his code and I stuck to $FFFE for Latecomer.


This is the code (you can safely ignore the 65C02 stack instructions in the handler of course)

; -----------------------------------------------------------
; mise en place de l'interruption
SEI ; inhib
lda $c08b ; disable ROM
lda $c08b
; vecteur
LDA #<PLAYERYM
STA $FFFE
LDA #>PLAYERYM
STA $FFFF
; interruption - TIMER 1 6522
LDA #%01000000 ; continuous interrupt / PB7 disabled
STA $C40B ; Auxiliary Control Register

LDA #%11000000 ;
STA $C40D ; interrupt flag register (Time Out of Timer 1/Int)
STA $C40E ; interrupt Enable register (Timer 1 + Set)

; 50 Hz = 20 ms = 20 000 microsecond = 20 000 tick environ (1 Mhz d'holorge) = $4E20

LDA #$20
STA $C404 ; T1C-Lower
LDA #$4E
STA $C405 ; T1C-High
; -----------------------------------------------------------


(...)

PLAYERYM
php
pha ; on sauve A
phx
phy
BIT $C404 ; Clears interrupt (T1CL)

(player...)

PLY
PLX
PLA
PLP

RTI

[qkumba]

I build on Windows with no problem.
First is to have a binary of CA65 for Windows.
CA65 builds cleanly in Visual Studio via the project files.
To add to the disk image, I use CiderPress.

[vi...@pianoman.cluster.toy]

On 2019-06-06, Cyril Lambin <lam...@gmail.com> wrote:

> I just had a look at FT's code, and now I remember that I noticed that
> in the earliest version of his YM player he was using $03FE, and later
> he switched to $FFFE except when a IIgs is detected.

yes, I think the IIc you can put interrupt handlers at AUX address $fffe,
but that's not something you can really do on a II+ or regular IIe
(well, I guess you could if you had a language card configured).

> PLY
> PLX
> PLA
> PLP
>
> RTI

so the code isn't using $45 to restore the accumulator, interesting.
I wonder if it would work at all on a II+.

Anyway I managed to get a IIc emulator going (MAME) and can reproduce
the issue you are seeing. It's definitely something with the interrupt
handler (or the music playing), as if I turn off interrupts it doesn't
crash. However things do get corrupted, but I should probably apply
qkumba's most recent patches before tracking this down more as I think
he fixed some graphics corruption issues.

Vince

[vi...@pianoman.cluster.toy]

OK, I've spun off a separate "pt3_lib" directory that has a bare-bones
PT3 player implementation that should be easier to include in other code.

I've kept "pt3_player" separately, and that's where I'll keep the over-the
top optimization work going.

I also got IIc support working for the "pt3_lib" code.

Indeed the fix was moving the IRQ handler to $fffe. I think on the IIc
the firmware makes a lot of assumptions about the IRQs. My turning off ROM
and putting your interrupt handler at $fffe it bypasses all the firmware
nonsesne.

And actually, it might make sense to do this on IIe too, as the IIe firmware
also spends a lot of time doing stuff we don't really need before passing
off to $03fe.

Vince

[Cyril Lambin]

Le vendredi 7 juin 2019 22:09:42 UTC+2, vi...@pianoman.cluster.toy a écrit :
> OK, I've spun off a separate "pt3_lib" directory that has a bare-bones
> PT3 player implementation that should be easier to include in other code.

Great!

I tried to compile on Windows, indeed it works with Ubuntu subsystem. It's just not really convenient because the linux configuration is not complete yet (for example I work on network drives that don't mount automatically).
I retried tonight to make the last version with mingw/msys and pt3_player fails:
../dos33fs-utils/dos33 -y pt3_debug.dsk BSAVE -a 0x1000 PT3_DUMPER
Error! First char of filename must be ASCII 64 or above!

> I also got IIc support working for the "pt3_lib" code.
>
> Indeed the fix was moving the IRQ handler to $fffe. I think on the IIc
> the firmware makes a lot of assumptions about the IRQs. My turning off ROM
> and putting your interrupt handler at $fffe it bypasses all the firmware
> nonsesne.

That may be why I didn't succeed in using $03fe... of course with 48k you don't have any choice.

Aaaand... it WORKS on may PAL IIc. Thank you so much! I'm looking forward to use the player in my next projects :)

Cyril

[cybernesto]

> I retried tonight to make the last version with mingw/msys and pt3_player fails:
> ../dos33fs-utils/dos33 -y pt3_debug.dsk BSAVE -a 0x1000 PT3_DUMPER
> Error! First char of filename must be ASCII 64 or above!

You will want to change the makefile line 14 to:
$(DOS33) -y -a 0x1000 pt3_lib.dsk BSAVE PT3_TEST

getopt seems to work differently on mac OS as well, since it expects all options to be entered after the command.