Forums

Sega Master System / Mark III / Game Gear
SG-1000 / SC-3000 / SF-7000 / OMV
Home - Forums - Games - Scans - Maps - Cheats - Credits
Music - Videos - Development - Hacks - Translations - Homebrew

View topic - devkitSMS experimental branch

Reply to topic
Author Message
  • Joined: 05 Sep 2013
  • Posts: 3759
  • Location: Stockholm, Sweden
Reply with quote
devkitSMS experimental branch
Post Posted: Tue Nov 10, 2020 11:26 pm
Last edited by sverx on Tue Jan 05, 2021 6:27 pm; edited 1 time in total
SDCC version 4 is arrived and it's bringing banked code with it.

So I have created an experimental branch in devkitSMS and I'll be working on that... whenever possible.

In short: code can be written in separate source files that gets assembled in separate code banks. When calling a banked function, the code will trigger a slot-1 bank change (using trampolines that are 'hidden' in bank 0 code) and will restore the previous bank upon returning from called function.

This means that only code in bank 0 won't ever be paged out, but that means that there will no longer be code size restrictions to 32 KiB.

At the moment this is still very experimental, and a few things might change in the near future. But for now, if you're interested into this, this is what you need to know.

1st: you need at least SDCC 4.0.4 #11929. Get a recent snapshot from their website and you're good.

2nd: you need to compile each code bank into a specific separate code segment, for instance as in:
sdcc -c -mz80 --codeseg BANK1 banked_code_1.c

3rd: you need to use (the devkitSMS provided) crt0b.rel as the first module in your linker call

4th: you need to instruct the linker to place all the banked code at address 0x4000 + the virtual address of the bank, which is banknumber×2¹⁶ (so code segment BANK1 goes at 0x14000, code segment BANK2 goes at 0x24000 and so on...)
sdcc -o output.ihx -mz80 --no-std-crt0 --data-loc 0xC000 -Wl-b_BANK1=0x14000 crt0b_sms.rel SMSlib.lib main.rel banked_code_1.rel

5th: you need to use the newer makesms tool to convert the ihx output to the sms file (this works very differently compared to ihx2sms so that's why it's a separate tool)
makesms output.ihx output.sms


A simple example. Note how func_next is declared as __banked in both the source and the header file (this is very important as the caller needs to know that in advance). Also note how code can call 'local' functions within same code bank just regularly.

main.c:
//  SDCC banked code test

#include "banked_code_1.h"

#include "SMSlib.h"

void main (void) {
  unsigned char n=5;
  n=func_next(n);
}

SMS_EMBED_SEGA_ROM_HEADER_16KB(9999,0);


banked_code_1.h:
//  SDCC banked code test header file

unsigned char func_next (unsigned char num) __banked;


banked_code_1.c:
//  SDCC banked code test

unsigned char local_function (unsigned char num) {
  return (num+1);
}

unsigned char func_next (unsigned char num) __banked {
  // calls a local function
  return (local_function(num));
}


There's still a lot of work to be done but I hope you'll find this interesting.

Feedback appreciated. Questions welcome. :)
  View user's profile Send private message Visit poster's website
  • Joined: 29 Mar 2012
  • Posts: 879
  • Location: Spain
Reply with quote
Post Posted: Wed Nov 11, 2020 7:59 am
wow! seems really interesting, although I think I'll wait sometime before trying it :-)
  View user's profile Send private message
  • Joined: 05 Sep 2013
  • Posts: 3759
  • Location: Stockholm, Sweden
Reply with quote
Post Posted: Wed Nov 11, 2020 4:08 pm
I don't expect many people to really need this, anyway.

But Eruiz would find it handy :D
  View user's profile Send private message Visit poster's website
  • Joined: 29 Mar 2012
  • Posts: 879
  • Location: Spain
Reply with quote
Post Posted: Wed Nov 11, 2020 4:46 pm
I've a use case for this (more or less). I thought about having a game that at the end, will show fmv using the video player gligli created some time ago. So, it'll mean banking the player code in the slot 1 just at the end of the game and start banking the data on the slot 2.
  View user's profile Send private message
  • Joined: 05 Sep 2013
  • Posts: 3759
  • Location: Stockholm, Sweden
Reply with quote
Post Posted: Thu Nov 12, 2020 11:03 am
is that player code very big?
  View user's profile Send private message Visit poster's website
  • Joined: 29 Mar 2012
  • Posts: 879
  • Location: Spain
Reply with quote
Post Posted: Thu Nov 12, 2020 11:54 am
Not sure, but the "n*ked player code" should fit on 16kb, I don't think is such a monster to be 32kb...
  View user's profile Send private message
  • Joined: 28 Jan 2017
  • Posts: 541
  • Location: Málaga, Spain
Reply with quote
Post Posted: Sun Nov 22, 2020 12:27 pm
sverx wrote
I don't expect many people to really need this, anyway.

But Eruiz would find it handy :D


LOL...

In fact i was playing with some ideas ,thinking about this, when i entered in smspower page to check news... And voilá!

I have a game for msx (done with SDCC) which does code banking (it compiles several .c files mapped to the same address, and then link them all.. SDCC linker warns about this but it works. After the linking you have to separately link the bank, rel files to ihxs, fill those ihxs to 8kb each and do a binary copy to make the final rom file. You have to be careful but it works. I can prove it :) In fact, i was going to try this technique for SMS.

But if sdcc4.0 developers have done the work for me, it will be better for sure. So downloading now to check.!

Working on (maybe) new game for compo. First graphics and some music but i have tye idea (the most difficult part for sure)...

Regards!!!
  View user's profile Send private message
  • Joined: 05 Sep 2013
  • Posts: 3759
  • Location: Stockholm, Sweden
Reply with quote
Post Posted: Sun Nov 22, 2020 4:55 pm
eruiz00 wrote
if sdcc4.0 developers have done the work for me, it will be better for sure


they added that __banked keyword, and the trampolines that make the code bank switch possible

this is still pretty new and all WIP so it will improve in the coming months, I guess.
  View user's profile Send private message Visit poster's website
  • Joined: 28 Jan 2017
  • Posts: 541
  • Location: Málaga, Spain
Reply with quote
Flawless!!!
Post Posted: Fri Nov 27, 2020 11:53 pm
Ummmmm... After some hours changing the build script and the needed srcs , i have to say IT WORKS !!!!

I have been checking all the needed functions (zx7 unpacking to ram, vram tiles and tilemaps writing and background music & sound ) and i found that, if all the assets are in the same bank, ( and compiled with the source code) it just works.

I used the ctr0b file only, as the rest of smslib and psglib seems equal.

Now i can fit 85 minigames into a rom. Great!
  View user's profile Send private message
  • Joined: 05 Sep 2013
  • Posts: 3759
  • Location: Stockholm, Sweden
Reply with quote
Post Posted: Mon Nov 30, 2020 12:11 pm
assets handling with assets2banks it's still a bit of a mess with this experimental fork... you either put banked code in the banks after the assets ones or you use folder2c and you allocate assets in the banks following your code

I likely have to add a command line option to assets2banks to set the number of the first bank to be used. I will look into that when I get some free time.
  View user's profile Send private message Visit poster's website
  • Joined: 05 Sep 2013
  • Posts: 3759
  • Location: Stockholm, Sweden
Reply with quote
Post Posted: Tue Jan 05, 2021 4:31 pm
so I finally merged the experimental branch back into the master - banked code is now 'officially' supported.

as for assets2banks, I just uploaded version 2.5 - so it is now possible to use it to create banks starting from any number, so that you can skip as many as you wish, if you plan to use a few of them for code by using the new:

--firstbank=<number>[,<size>]

command line option, as in:

assets2banks assets --firstbank=8

and it's still possible to define the size of your first bank to be different from 16 KiB as in:

assets2banks assets --firstbank=1,8192

(which does the same as the old, now deprecated, --bank1size option)
  View user's profile Send private message Visit poster's website
  • Joined: 28 Jan 2017
  • Posts: 541
  • Location: Málaga, Spain
Reply with quote
Working on new game
Post Posted: Tue Jan 05, 2021 9:21 pm
Well......

I have been doing things using banked code last months, although i was not using the experimental branch (used the old good default version for sdcc from your repository) and i have to say it is posible to do this without the new feature, being careful with the banks, you can call unbanked code from banked code, and the first function in each .c file for a bank, from unbanked code (later you can call more functions inside the bank without troubles at all).

But i am going to try the feature tomorrow, to see how it works. Maybe one day we can work with code like we do today with assets (or even better). would be great!

Thanks!

BTW, running assets2banks.py under osx (high sierra) default python version you will find two errors related to character encoding, being easy to fix. I have returned to windows (definitely cannot work with finder :( and cannot tell you more, except for this errors i had.

Happy new year everyone.
  View user's profile Send private message
  • Joined: 05 Sep 2013
  • Posts: 3759
  • Location: Stockholm, Sweden
Reply with quote
Post Posted: Tue Jan 05, 2021 10:20 pm
if you were using SDCC 4.x and devkitSMS' crt0b_sms.rel, you were using the experimental branch anyway ;)

now SDCC 4.0 is officially required, SMSlib have been recompiled with it, and assets2banks (newer version 2.5) can be instructed to 'skip' as many banks as needed, so code bankswitching should be transparent and coding games that use banked code should be fairly streamlined...

... or at least I hope so. Let me know if something doesn't work as expected.

also, if you happen to see the python error again on Mac let me know the details, I'll see what I can do.
  View user's profile Send private message Visit poster's website
  • Joined: 05 Sep 2013
  • Posts: 3759
  • Location: Stockholm, Sweden
Reply with quote
Post Posted: Mon Jan 25, 2021 10:40 pm
I just updated both makesms and assets2banks tools.

the first had a stupid bug, the second was still creating object files in the old format when --compile output was requested
  View user's profile Send private message Visit poster's website
  • Joined: 05 Sep 2013
  • Posts: 3759
  • Location: Stockholm, Sweden
Reply with quote
Post Posted: Fri Apr 08, 2022 1:26 pm
... reviving this old topic as I have another experimental branch for devkitSMS for those of you brave enough ;)

so this time SDCC 4.2.0 arrived and it changed the default calling convention for functions, bringing with it improved code generation and speed

I took some time to update the asm functions in SMSlib and with the new calling convention they all became faster, some noticeably faster than before.

So if someone wants to help testing if everything still works correctly and even better than before, the experimental branch is here and since of course requires SDCC 4.2.0 make sure you have a backup of everything before you begin...

Feedback much appreciated :)
  View user's profile Send private message Visit poster's website
  • Joined: 12 Dec 2021
  • Posts: 43
  • Location: Melbourne, Australia
Reply with quote
Post Posted: Fri Apr 08, 2022 1:36 pm
I'm happy to take it for a spin. I'm kinda worried that 4.2.0 is going to break all the nice C debugging stuff in Emulicious more than anything, but at least it should be easy enough to go back if it all ends up on fire. Will let you know how things go!
  View user's profile Send private message
  • Joined: 05 Sep 2013
  • Posts: 3759
  • Location: Stockholm, Sweden
Reply with quote
Post Posted: Fri Apr 08, 2022 1:47 pm
darkowl wrote
I'm kinda worried that 4.2.0 is going to break all the nice C debugging stuff in Emulicious


I'm not experiencing problems debugging with Emulicious, but I'm not using Emulicious/VScode source level debugging features so I have no idea how that could be affected...
  View user's profile Send private message Visit poster's website
  • Joined: 28 Jan 2017
  • Posts: 541
  • Location: Málaga, Spain
Reply with quote
Error!
Post Posted: Fri Apr 08, 2022 2:45 pm
Maybe some error in the (downloaded today) github snapshot from your experimental branch or the (downloaded today) sdcc snapshot version (x86) ???

It seems the y coordinate for the sprites get lost...

Same code, build with old (sdcc 4.1, smslib one month ago version) is working well
greenberet-420.zip (54.65 KB)
Experimental compilation
greenberet.zip (54.84 KB)
Same code, old sdcc 4.1 + old smslib

  View user's profile Send private message
  • Joined: 05 Sep 2013
  • Posts: 3759
  • Location: Stockholm, Sweden
Reply with quote
Post Posted: Fri Apr 08, 2022 2:59 pm
I would say make sure you updated SMSlib.h too and rebuild any source file in your project

also, if this still fails, make sure you're using the official SDCC release 4.2.0 so that we can be sure we're in the same testing conditions

edit: OK I think I found the problem - you're using NO_SPRITE_CHECKS sprites - you should add

#define NO_SPRITE_CHECKS

before

#include "SMSlib.h"


I probably need to put a note in the header.
  View user's profile Send private message Visit poster's website
  • Joined: 28 Jan 2017
  • Posts: 541
  • Location: Málaga, Spain
Reply with quote
Yeah!!!
Post Posted: Fri Apr 08, 2022 3:13 pm
Last edited by eruiz00 on Fri Apr 08, 2022 3:20 pm; edited 1 time in total
Ummm.... Stupid me :(

I compiled your library with the -DNO_SPRITE_CHECKS
option and not used to build the game.

Now it (seems) to work. It should be faster? It seems smaller....

Thanks for all your work. My games would not exist without your (and other) libs and tools.

edit: this weekend will change the toolset to test the 3mb version of silvervalley I am working on. It is full of (banked by me) code (i learnt some time ago that banked code is ok if you don't switch bank from that code, although you can switch bank from a called function in unbanked space, from that banked code, if that function set the bank to the calling one before the return to the calling banked function... what a tongue twister!), so I think that will work too xD
greenberet420.zip (54.67 KB)
Working build

  View user's profile Send private message
  • Joined: 05 Sep 2013
  • Posts: 3759
  • Location: Stockholm, Sweden
Reply with quote
Post Posted: Fri Apr 08, 2022 3:19 pm
Thanks for the test!
Yeah I know it's not ideal, I'm trying to workaround a minor issue without slowing down the code... maybe I will find a better approach.
  View user's profile Send private message Visit poster's website
  • Joined: 12 Dec 2021
  • Posts: 43
  • Location: Melbourne, Australia
Reply with quote
Post Posted: Fri Apr 15, 2022 12:57 am
So I've tried out SDCC 4.2.0 and the SMSlib branch with my code... and everything broke. Hahaha, honestly I was kinda expecting that. I just get a black screen, and some minimal noise at the bottom.

I did a clean install of SDCC, re-copied the executable and lib files as per the SMSlib docs, updated the header and rel stuff in my own project... sadness.

Have to see if I can make a reductive case to get something working, but yeah...

edit

Okay yeah, SDCC 4.2.0 has broken a lot of things. The C debugging symbols that Emulicious bridges with VSCode are just completely stuffed.

for (i = 0; i < count; i++)


Very first iteration? It reports i as being set to 65,535. Yep. Other local vars just change randomly even when stepping through lines that don't change them. This is likely an issue between SDCC and Emulicious, but it's enough for me to return to 4.1.0.

Any of the effects where I've used inline assembly just fail - the aforementioned black screen. Don't know why they crash out yet. One effect that didn't use inline assembly seemed okay. Guessing this might be related to the function signature changes?

I know this seems more like problems with SDCC and Emulicious. But the bits that I got working that use SMSlib, did seem to be okay... as far as I could tell.

Anyway. Back to 4.1.0 for now...
  View user's profile Send private message
  • Joined: 05 Sep 2013
  • Posts: 3759
  • Location: Stockholm, Sweden
Reply with quote
Post Posted: Sat Apr 16, 2022 7:47 pm
darkowl wrote
Any of the effects where I've used inline assembly just fail - the aforementioned black screen. Don't know why they crash out yet. One effect that didn't use inline assembly seemed okay. Guessing this might be related to the function signature changes?


It might be related to the newest calling convention in SDCC 4.2.0: you could try compiling your sources with
--sdcccall 0
and see if it fixes the problem
  View user's profile Send private message Visit poster's website
Reply to topic



Back to the top of this page

Back to SMS Power!