Forums

Maxim wrote

The C compilers seem to produce rather large code, and do not deal with paged code well. So it seems to become a struggle to fit the code in.

Dealing with paged code is identical to dealing with it in asm - there is no difference there. But if you're going to spill outside the bottom 32k you do have to plan out your memory layout just as you would with an asm program.

I can confirm that using --codesegsmc_user i have found 3kb additional for code whithout troubles.

eruiz00 wrote

I can confirm that using --codesegsmc_user i have found 3kb additional for code whithout troubles.

what does --codesegsmc_user do? I seem to fail at finding it myself :|

sverx wrote

what does --codesegsmc_user do? I seem to fail at finding it myself :|

The smc_* sections are self-modifying code sections in z88dk. Placing code there will cause z88dk to copy the code to ram at startup. In fact, the smc code is bundled with the program's data section.

I think eruiz's program has about 6k ram free so he's filling that up with this "smc" code.

The smc code and the data section are then stored in compressed form in the rom (compressed with zx7) and doing that will free more rom space in the bottom 32k. So the code space is effectively being increased at th expense of ram without having to split code across banks.

I have fullfiled the available RAM and now i have 3.5 kb free on Code segment :)

code in RAM! that's very cunning :)

edit: is the compressed code stored in 'low' ROM? Can it be stored in paged ROM instead (for instance in BANK2 so that it gets mapped at start in slot2)?

Read one AA post in this thread from august. I did follow that post! (Although it is not explained the -codesegsmc_user point)

Edit: Code in banks to data segment would be double cunning!!!!

Reedit: something about zx7 posible VRAM bug?
10kb depends on this (remember me invite you to dinner if someday go to canada :)

sverx wrote

is the compressed code stored in 'low' ROM? Can it be stored in paged ROM instead (for instance in BANK2 so that it gets mapped at start in slot2)?

Yes it is stored in low rom. This (a compressed stored data section) is a general feature across all z80 targets in z88dk so it only automatically works for the main 64k memory space, which in the sms's case is the 32k rom and the ram.

However, you can do what you're thinking with a little extra effort. You can compile code for a different address and have it stored in another bank. So you could compress that code and then insert some initialization that will page in that bank and decompress into ram.

There is a section "crt_code_init" defined that allows you to insert asm code into the crt just before main is called:

SECTION code_crt_init

;;; bank in rom holding compressed code here

ld hl,src_compressed ;; address in bank of compressed code
ld de,dst_ram ;; destination in ram
call asm_dzx7_standard ;; decompress

;; no ret!!

You would have that in a separate asm file and add it to the compile line. Then this code fragment will execute just prior to calling main.

If you (eruiz) would like to try it we can find a way to do it.

Quote

Reedit: something about zx7 posible VRAM bug?
10kb depends on this (remember me invite you to dinner if someday go to canada :)

Will do :D

I'm not finished looking but I am not seeing a bug in the vram decompress yet even with the binaries you sent, with and without vdp timing checks in emulicious.

However, you sent the compressed binaries only so I can't check the actual binary against the compressed binary (I am checking the uncompressed binary against the compressed binary) to rule out an error in zx7 itself. I'll post the code I am using to test in a bit.

Are you making sure you have sufficient room for the stack in ram? It's hard to say what you need but 256 bytes should be more than adequate.

Alcoholics Anonymous wrote

Yes it is stored in low rom. This (a compressed stored data section) is a general feature across all z80 targets in z88dk so it only automatically works for the main 64k memory space, which in the sms's case is the 32k rom and the ram.

I would say 'the 48K ROM' and the RAM. What I mean is that in crt0 mapper initialization we initialize the three SEGA mapper slots to banks 0, 1 and 2, thus we can safely assume that -before going to main()- we've got bank 2 mapped too. We could place the compressed data section he needs for both RAM variables initialization and RAM code in there, as we won't ever need that again. It might free some other KBs for the game :)

The test program I am using for the zx7 decompress into vram:
https://drive.google.com/file/d/0B6XhJJ33xpOWd0MweUNsMFNGcXM/view?usp=sharing

The compile line is at the top of the .c file. I didn't include any binaries but just copy your binary file to the same directory, compress it with "zx7 -f foo.bin" to make foo.bin.zx7, change RAWBIN_SIZE in binaries.h to the file size of the plain binary file, change binaries.asm to include the right files in the BINARY directives. Then compile and run.

sverx wrote

I would say 'the 48K ROM' and the RAM. What I mean is that in crt0 mapper initialization we initialize the three SEGA mapper slots to banks 0, 1 and 2, thus we can safely assume that -before going to main()- we've got bank 2 mapped too.

Yes I see what you mean. z88dk is using slightly different code but equivalent during startup; it separates the z80's page zero from the crt code so that programs can be written away from address 0 in case someone wants to put their own code at 0:

z88dk_devkitsms_page_zero (tries to fill holes with commonly required subroutines)

z88dk_devkitsms_crt

Quote

We could place the compressed data section he needs for both RAM variables initialization and RAM code in there, as we won't ever need that again. It might free some other KBs for the game :)

Yes you could do the decompression without switching banks first but otherwise there is no special need to have it in bank 2.

The issue bank 2 presents for the automatic decompression is that the sega headers are at the end of bank 1 so that bank 2 is not contiguous with bank 1 (there's a reserved hole there). The tools therefore treat bank 2 as a separate memory space. It's possible to get around this and there are probably three or four different ways to do this but all of them will require an extra step or two in the compile script.

Ummmmm

Your boring test program pass the three images i sent to you.

So it Must be my fault. Lets try some changes and Will tell you.

eruiz00 wrote

Ummm...

It fails with constraints and without them. Also it fails in fusion.

Though it could fail because of the interrupt handler, which is the next function:

// Handler de interrupciones
void InterruptHandler(void)
{
unsigned char oldbank=lastbank;

// Update music
if(musicbank)
{
   changeBank(musicbank);
   PSGFrame();
}

// Update sounds
if(PSGSFXGetStatus())
{
   changeBank(soundbank);
   PSGSFXFrame();
}

SMS_mapROMBank(oldbank);

numinterrupts++;
}

(note this function works perfect with psgcompr compressed tiles)

but not. It doesnt work even without these handler.[/code]

Try enabling the error breakpoint "Break on inconsistent state after interrupt" found in the Breakpoint Window of Emulicious.
If the glitches are related to interrupts the breakpoint should suspend emulation.

Ummmmm

Thanks calindro!

...but thats not the trouble. The debugger does not stop. I am debugging to see if gets corrupted on decompress or some part of the Game write on VRAM memory badly.

eruiz00 wrote

...but thats not the trouble. The debugger does not stop. I am debugging to see if gets corrupted on decompress or some part of the Game write on VRAM memory badly.

If you take a look at the compress.c test program you'll see this:

#include <intrinsic.h>

intrinsic_label(ZX7_TIMER_START);

This inlines an assembly label "ZX7_TIMER_START" into the c code. So from the map file you can see what the address is at that point and you can set a breakpoint on it. This might help you check the state of vram at some points in the program. Just make sure the label is different enough that it's not colliding with the compiler (do not start labels with _) or library.

Alcoholics Anonymous wrote

The issue bank 2 presents for the automatic decompression is that the sega headers are at the end of bank 1 so that bank 2 is not contiguous with bank 1 (there's a reserved hole there). The tools therefore treat bank 2 as a separate memory space. It's possible to get around this and there are probably three or four different ways to do this but all of them will require an extra step or two in the compile script.

Of course. I meant that you could place your "foo.bin.zx7" in bank 2, say fixed at 0x8000 for instance, and it'll be surely accessible when starting. So you will decompress that and page out the assets just like other assets (also, you won't need that one again). SEGA header doesn't get in the way absolutely, handling those data this way.

Author	Message
Alcoholics Anonymous Joined: 17 Nov 2015 Posts: 97 Location: Canada	Posted: Sun Oct 08, 2017 6:25 pm
	Maxim wrote The C compilers seem to produce rather large code, and do not deal with paged code well. So it seems to become a struggle to fit the code in. Dealing with paged code is identical to dealing with it in asm - there is no difference there. But if you're going to spill outside the bottom 32k you do have to plan out your memory layout just as you would with an asm program.

eruiz00 Joined: 28 Jan 2017 Posts: 556 Location: Málaga, Spain	Posted: Sun Oct 08, 2017 10:03 pm
	I can confirm that using --codesegsmc_user i have found 3kb additional for code whithout troubles.

sverx Joined: 05 Sep 2013 Posts: 3828 Location: Stockholm, Sweden	Posted: Mon Oct 09, 2017 8:09 am
	eruiz00 wrote I can confirm that using --codesegsmc_user i have found 3kb additional for code whithout troubles. what does --codesegsmc_user do? I seem to fail at finding it myself :\|

Alcoholics Anonymous Joined: 17 Nov 2015 Posts: 97 Location: Canada	Posted: Mon Oct 09, 2017 12:29 pm Last edited by Alcoholics Anonymous on Mon Oct 09, 2017 12:38 pm; edited 1 time in total
	sverx wrote what does --codesegsmc_user do? I seem to fail at finding it myself :\| The smc_* sections are self-modifying code sections in z88dk. Placing code there will cause z88dk to copy the code to ram at startup. In fact, the smc code is bundled with the program's data section. I think eruiz's program has about 6k ram free so he's filling that up with this "smc" code. The smc code and the data section are then stored in compressed form in the rom (compressed with zx7) and doing that will free more rom space in the bottom 32k. So the code space is effectively being increased at th expense of ram without having to split code across banks.

eruiz00 Joined: 28 Jan 2017 Posts: 556 Location: Málaga, Spain	Posted: Mon Oct 09, 2017 12:35 pm
	I have fullfiled the available RAM and now i have 3.5 kb free on Code segment :)

sverx Joined: 05 Sep 2013 Posts: 3828 Location: Stockholm, Sweden	Posted: Mon Oct 09, 2017 12:47 pm Last edited by sverx on Mon Oct 09, 2017 12:51 pm; edited 2 times in total
	code in RAM! that's very cunning :) edit: is the compressed code stored in 'low' ROM? Can it be stored in paged ROM instead (for instance in BANK2 so that it gets mapped at start in slot2)?

eruiz00 Joined: 28 Jan 2017 Posts: 556 Location: Málaga, Spain	Posted: Mon Oct 09, 2017 12:48 pm
	Read one AA post in this thread from august. I did follow that post! (Although it is not explained the -codesegsmc_user point) Edit: Code in banks to data segment would be double cunning!!!! Reedit: something about zx7 posible VRAM bug? 10kb depends on this (remember me invite you to dinner if someday go to canada :)

Alcoholics Anonymous Joined: 17 Nov 2015 Posts: 97 Location: Canada	Posted: Mon Oct 09, 2017 1:39 pm
	sverx wrote is the compressed code stored in 'low' ROM? Can it be stored in paged ROM instead (for instance in BANK2 so that it gets mapped at start in slot2)? Yes it is stored in low rom. This (a compressed stored data section) is a general feature across all z80 targets in z88dk so it only automatically works for the main 64k memory space, which in the sms's case is the 32k rom and the ram. However, you can do what you're thinking with a little extra effort. You can compile code for a different address and have it stored in another bank. So you could compress that code and then insert some initialization that will page in that bank and decompress into ram. There is a section "crt_code_init" defined that allows you to insert asm code into the crt just before main is called: SECTION code_crt_init ;;; bank in rom holding compressed code here ld hl,src_compressed ;; address in bank of compressed code ld de,dst_ram ;; destination in ram call asm_dzx7_standard ;; decompress ;; no ret!! You would have that in a separate asm file and add it to the compile line. Then this code fragment will execute just prior to calling main. If you (eruiz) would like to try it we can find a way to do it. Quote Reedit: something about zx7 posible VRAM bug? 10kb depends on this (remember me invite you to dinner if someday go to canada :) Will do :D I'm not finished looking but I am not seeing a bug in the vram decompress yet even with the binaries you sent, with and without vdp timing checks in emulicious. However, you sent the compressed binaries only so I can't check the actual binary against the compressed binary (I am checking the uncompressed binary against the compressed binary) to rule out an error in zx7 itself. I'll post the code I am using to test in a bit. Are you making sure you have sufficient room for the stack in ram? It's hard to say what you need but 256 bytes should be more than adequate.

sverx Joined: 05 Sep 2013 Posts: 3828 Location: Stockholm, Sweden	Posted: Mon Oct 09, 2017 1:56 pm
	Alcoholics Anonymous wrote Yes it is stored in low rom. This (a compressed stored data section) is a general feature across all z80 targets in z88dk so it only automatically works for the main 64k memory space, which in the sms's case is the 32k rom and the ram. I would say 'the 48K ROM' and the RAM. What I mean is that in crt0 mapper initialization we initialize the three SEGA mapper slots to banks 0, 1 and 2, thus we can safely assume that -before going to main()- we've got bank 2 mapped too. We could place the compressed data section he needs for both RAM variables initialization and RAM code in there, as we won't ever need that again. It might free some other KBs for the game :)

Alcoholics Anonymous Joined: 17 Nov 2015 Posts: 97 Location: Canada	Posted: Mon Oct 09, 2017 2:58 pm
	The test program I am using for the zx7 decompress into vram: https://drive.google.com/file/d/0B6XhJJ33xpOWd0MweUNsMFNGcXM/view?usp=sharing The compile line is at the top of the .c file. I didn't include any binaries but just copy your binary file to the same directory, compress it with "zx7 -f foo.bin" to make foo.bin.zx7, change RAWBIN_SIZE in binaries.h to the file size of the plain binary file, change binaries.asm to include the right files in the BINARY directives. Then compile and run. sverx wrote I would say 'the 48K ROM' and the RAM. What I mean is that in crt0 mapper initialization we initialize the three SEGA mapper slots to banks 0, 1 and 2, thus we can safely assume that -before going to main()- we've got bank 2 mapped too. Yes I see what you mean. z88dk is using slightly different code but equivalent during startup; it separates the z80's page zero from the crt code so that programs can be written away from address 0 in case someone wants to put their own code at 0: z88dk_devkitsms_page_zero (tries to fill holes with commonly required subroutines) z88dk_devkitsms_crt Quote We could place the compressed data section he needs for both RAM variables initialization and RAM code in there, as we won't ever need that again. It might free some other KBs for the game :) Yes you could do the decompression without switching banks first but otherwise there is no special need to have it in bank 2. The issue bank 2 presents for the automatic decompression is that the sega headers are at the end of bank 1 so that bank 2 is not contiguous with bank 1 (there's a reserved hole there). The tools therefore treat bank 2 as a separate memory space. It's possible to get around this and there are probably three or four different ways to do this but all of them will require an extra step or two in the compile script.

eruiz00 Joined: 28 Jan 2017 Posts: 556 Location: Málaga, Spain	Posted: Mon Oct 09, 2017 8:47 pm
	Ummmmm Your boring test program pass the three images i sent to you. So it Must be my fault. Lets try some changes and Will tell you.

Calindro Joined: 14 Apr 2013 Posts: 624	Posted: Mon Oct 09, 2017 8:51 pm
Calindro Joined: 14 Apr 2013 Posts: 624	eruiz00 wrote Ummm... It fails with constraints and without them. Also it fails in fusion. Though it could fail because of the interrupt handler, which is the next function: // Handler de interrupciones void InterruptHandler(void) { unsigned char oldbank=lastbank; // Update music if(musicbank) { changeBank(musicbank); PSGFrame(); } // Update sounds if(PSGSFXGetStatus()) { changeBank(soundbank); PSGSFXFrame(); } SMS_mapROMBank(oldbank); numinterrupts++; } (note this function works perfect with psgcompr compressed tiles) but not. It doesnt work even without these handler.[/code] Try enabling the error breakpoint "Break on inconsistent state after interrupt" found in the Breakpoint Window of Emulicious. If the glitches are related to interrupts the breakpoint should suspend emulation.

eruiz00 Joined: 28 Jan 2017 Posts: 556 Location: Málaga, Spain	Posted: Mon Oct 09, 2017 9:03 pm
	Ummmmm Thanks calindro! ...but thats not the trouble. The debugger does not stop. I am debugging to see if gets corrupted on decompress or some part of the Game write on VRAM memory badly.

Alcoholics Anonymous Joined: 17 Nov 2015 Posts: 97 Location: Canada	Posted: Mon Oct 09, 2017 11:25 pm
	eruiz00 wrote ...but thats not the trouble. The debugger does not stop. I am debugging to see if gets corrupted on decompress or some part of the Game write on VRAM memory badly. If you take a look at the compress.c test program you'll see this: #include <intrinsic.h> intrinsic_label(ZX7_TIMER_START); This inlines an assembly label "ZX7_TIMER_START" into the c code. So from the map file you can see what the address is at that point and you can set a breakpoint on it. This might help you check the state of vram at some points in the program. Just make sure the label is different enough that it's not colliding with the compiler (do not start labels with _) or library.

sverx Joined: 05 Sep 2013 Posts: 3828 Location: Stockholm, Sweden	Posted: Tue Oct 10, 2017 8:24 am
	Alcoholics Anonymous wrote The issue bank 2 presents for the automatic decompression is that the sega headers are at the end of bank 1 so that bank 2 is not contiguous with bank 1 (there's a reserved hole there). The tools therefore treat bank 2 as a separate memory space. It's possible to get around this and there are probably three or four different ways to do this but all of them will require an extra step or two in the compile script. Of course. I meant that you could place your "foo.bin.zx7" in bank 2, say fixed at 0x8000 for instance, and it'll be surely accessible when starting. So you will decompress that and page out the assets just like other assets (also, you won't need that one again). SEGA header doesn't get in the way absolutely, handling those data this way.

Forums

View topic - Sdcc vs z88dk and 3 main banks