It works but there is something I do not understand.
here the CopyRamToVram definition :
CopyRamToVram(void *SrcRamAddress, unsigned int DestVramAddress, unsigned int Length);
the new SetSpritePattern will now looks like this
void SetSpritePattern( char pattern_no, char* p_pattern, char s_size ) { DisableInterrupt(); CopyRamToVram(p_pattern, Peekw( 0xF926 ) + (pattern_no << 3), s_size); EnableInterrupt(); }
It works for MSX2 but not for MSX1
I have to transform the function like this for MSX1
void SetSpritePattern( char pattern_no, char* p_pattern, char s_size ) { DisableInterrupt(); CopyRamToVram(p_pattern, 0 + (pattern_no << 3), s_size); EnableInterrupt(); }
As the pattern area is at 0x3800, I do not understand how it can works when setting the Dest Address to 0 ! ?
Does Peekw(0xF926) return 0x3800 ?
In examples/printTextGraphic.c and examples/RamVramCopy.c I see:
CopyRamToVram(start_adr,&buff, 2048);
and
CopyRamToVram(&buff, start_adr, 2048);
Which is the correct one?
@Eric ;
void SetSpritePattern( char pattern_no, char* p_pattern, char s_size ) { DisableInterrupt(); CopyRamToVram(p_pattern, Peekw( 0xF926 ) + (pattern_no << 3), s_size); EnableInterrupt(); }
will work for MSX1 and MSX2, as PATBAS (0xF926) is a parameter present in both configurations.
But VpokeFirst is used in PutSprite and Vpoke functions too!
@Grauw
The definition of CopyRamToVram arguments is (start_RAM_address, start_VRAM_address, size)
I also noticed that function Screen(n) sets DPPAGE and ACPAGE to 0
;; void Screen( unsigned char mode ); _Screen:: xor a ld hl, #0xFAF5 ;; DPPAGE ld (hl), a inc hl ;; ACPAGE ld (hl), a ld hl, #2 add hl, sp ld a, (hl) ;; mode ld hl,#0xFCAF ;; Save current mode to FCAF ld (hl),a push ix ld ix, #0x005f ;; chgmod on bios ld iy, (0xfcc0) ;; iyh <= (0xfcc1) : EXPTBL(MAIN-ROM SLOT) call 0x001c ;; CALSLT ld ix, #0x0072 ;; inigrp on bios ld iy, (0xfcc0) ;; iyh <= (0xfcc1) : EXPTBL(MAIN-ROM SLOT) call 0x001c ;; CALSLT pop ix ret
@akumajo About Screen. I think that DPPAGE and ACPAGE set to 0 when you are calling Screen, is something normal.
Finally I found the reason that makes register 6 set to 0 after VpokeFirst function.
In fact, the function tries to write on the good video page and for this modifies the register 14 of the VDP to reach the desired memory address. However for a TMS9918 the register 14 (0b1110) does not exist, there are only 8 registers and 0b1110 becomes 0b0110, the register 6.
Something like that should do the trick :
void VpokeFirst( unsigned int address ) { if ( Peek( SCRMOD ) >= 7 ) { VDPwriteNi( 14, (address >> 14) | (Peek( ACPAGE ) << 2) ); } else if ( Peek( SCRMOD ) > 2 ) { VDPwriteNi( 14, (address >> 14) | (Peek( ACPAGE ) << 1) ); } OutPort( 0x99, (unsigned char)address ); OutPort( 0x99, ((unsigned char)(address >> 8) & 0x7F) | 0x40 ); }
I thought I'd rebuild the fusion.lib ibrary with the VpokeFirst as suggested above. I copy and pasted that into vpoke.c , ran build_lib and recompiled my game. It broke it. On the MSX2 emulator it just exits. On the MSX1 emulator it hangs. It didn't change to screen 2 and do the rest of my game.
It seemed like a good idea, but I'll be reinstating the original now.
Good thing I saved the original fusion.lib, as when I rebuilt it with the original vpokefirst reinstated, and recompiled my code that didn't work either.
If I build it it is 260Kb. The original is 239Kb. There is something I'm missing rebuilding it. Doesn't matter, I'll wait for Fusion 1.3 for running my game on MSX1.
I will make some fix in the sprite, and Vpoke system soon.
@MattyT. Continue to code your game, and testing it on MSX2. Once fixed version of Fusion-c 1.2 will be operational I will send you a version for testing purpose.
I will make some fix in the sprite, and Vpoke system soon.
@MattyT. Continue to code your game, and testing it on MSX2. Once fixed version of Fusion-c 1.2 will be operational I will send you a version for testing purpose.
Yep, will do. And I'm happy to test when the time comes. (Test analyst is also my day job)
I was too shy to write you before and I shouldn't Eric.
Make your work easier to developing fusion would be a pleasure.
Here you have a mini crap project I used to use for some tests to fusion-c while I'm learning to make bigger things.
It worked with the environment configuration you propose in the book. After making some test in blueMSX I can see It works in MSX2 but not in MSX1.
I hope It helps you to debug fusion, I'd be happy to help you
@MattyT
I sent you a fix. Let me know if it work well.