Gameboy Development Forum

Discussion about software development for the old-school Gameboys, ranging from the "Gray brick" to Gameboy Color
(Launched in 2008)

You are not logged in.

Ads

#1 2020-07-27 13:27:53

bbbbbr
Member
Registered: 2019-03-04
Posts: 71

z88dk adds support for Game Boy

Related to the SDCC updates Toxa posted about, there is other tool chain news for the gameboy.

z88dk posted that they added support for the Game Boy earlier this year. I haven't given it a try yet, but it's encouraging to see. Other folks may already know this, but I haven't seen mention of it yet here.
https://www.z88dk.org/forum/viewtopic.php?id=11182

Another year has passed, so it must be time for a new z88dk release!

Despite the project being almost 22 years old we're still making major changes and improvements

This release of z88dk sees support for two new processors:

- gbz80: zsdcc, sccz80 and classic now support gbz80 machines
- 8080/5: sccz80 and classic now support 8080/5 machines

Support for the following machines has been added:

- Nintendo Gameboy
....

Some discussion on support:
https://github.com/z88dk/z88dk/issues/1275
https://github.com/z88dk/z88dk/issues/1287

https://github.com/z88dk/z88dk/issues?q=gbz80

It looks like they imported GBDK support from GBDK-N

And some general benchmarks for the tools (generic z80, not gameboy specific)
https://github.com/z88dk/z88dk/wiki/Benchmarks

Offline

 

#2 2020-08-04 17:27:40

dom
New member
Registered: 2019-10-10
Posts: 3

Re: z88dk adds support for Game Boy

I posted about it back when I imported support last year: https://gbdev.gg8.se/forums/viewtopic.p … 3781#p3781

I've added some gbz80 specific benchmarks here: https://github.com/z88dk/z88dk/wiki/Cla … ies#n-body - I managed to port a full floating point library onto the gbz80 which admittedly is probably fairly pointless but an interesting exercise none-the-less. Sadly the IEEE754 libraries make extensive use of the z80's alternate registers so won't be available.

As far as I can tell everything is working as it should do, including banked calls. We'll pull in the latest sdcc (and look at the new way of doing banked calls) when we've got to the bottom of the sdcc issues that affect z80 projects.

Offline

 

#3 2020-08-05 06:12:54

toxa
Member
Registered: 2020-02-13
Posts: 158

Re: z88dk adds support for Game Boy

how do you test performance for GB target?


dom wrote:

As far as I can tell everything is working as it should do, including banked calls.

in the release of z88dk, or when building it yourself from the trunk? if later, then patches became not compatible with the latest sdcc trunk. in what configuration banked calls are working for gbz80 target?

ps: ah, i see, you are fixing that at the linking stage the same way GBDK-2020 far_fixer patch for link-gbz80 does. however, banking support was fixed recently, and that is no longer needed.

Last edited by toxa (2020-08-05 07:10:12)

Offline

 

#4 2020-08-05 06:35:02

toxa
Member
Registered: 2020-02-13
Posts: 158

Re: z88dk adds support for Game Boy

also, why do you patch sdcc to make it something different, instead of adding new features into the base? for example breaking the compatibility with asxxxx https://github.com/z88dk/z88dk/blob/mas … tch#L9-L12 instead of modifying _z80asm_mapping and so on?

Last edited by toxa (2020-08-05 06:39:00)

Offline

 

#5 2020-08-05 13:44:57

dom
New member
Registered: 2019-10-10
Posts: 3

Re: z88dk adds support for Game Boy

Performance is tested using z88dk-ticks - basically a headless CPU emulator that's grown a fair bit.

It's definitely working from latest, I do remember getting it working in the release, but I think it might have been a bit clunky how it was done.

I've not really worked on the zsdcc variant, the diff is slowly becoming smaller as features are mainlined so one day it will go away. I think the main things left are the set of peephole rules and changes to support those - for example to improve the generated code for 64 bit integers amongst other things.

As I understand it, the z80asm generator inside sdcc is incompatible with the peepholer, so we had to switch away from using the z80asm syntax and use the asxxxx output and transforms it as a post-process stage, I suspect the labeldef stuff is an issue with the scope of local labels that can't be fixed up in the postprocess transform - given all it does is change the scope of label to file from function local I'm not sure how it breaks asxxxx.

I'll be adding support for the alternate calling method when we can upgrade - I'm interested in how the bank is resolved without involving the linker which seems to be what you're suggesting.

Offline

 

#6 2020-08-05 16:37:11

toxa
Member
Registered: 2020-02-13
Posts: 158

Re: z88dk adds support for Game Boy

dom wrote:

I've not really worked on the zsdcc variant, the diff is slowly becoming smaller as features are mainlined so one day it will go away. I think the main things left are the set of peephole rules and changes to support those - for example to improve the generated code for 64 bit integers amongst other things.

1. peephole rules may be external - that works fine: https://github.com/basxto/gbz80-ph
2. built in peephole rules were enhanced much in the latest releases

dom wrote:

As I understand it, the z80asm generator inside sdcc is incompatible with the peepholer, so we had to switch away from using the z80asm syntax and use the asxxxx output and transforms it as a post-process stage, I suspect the labeldef stuff is an issue with the scope of local labels that can't be fixed up in the postprocess transform - given all it does is change the scope of label to file from function local I'm not sure how it breaks asxxxx.

i suggest you to post-process sdas assembler code then and translate it into z80asm dialect. yes, that is a big problem that sdcc has no intermediate representation for optimizers, which is target asm-independent. maybe make some patch towards this?

dom wrote:

I'll be adding support for the alternate calling method when we can upgrade - I'm interested in how the bank is resolved without involving the linker which seems to be what you're suggesting.

sdcc defines a name b<Symbol> which contains the bank number:

Code:

    ld    e, #b_output_picture
    ld    hl, #_output_picture
    call    ___sdcc_bcall_ehl

and in the other place:

Code:

    .area _CODE_1
    b_output_picture    = 1
_output_picture::
...
ret

Last edited by toxa (2020-08-05 16:42:17)

Offline

 

Board footer

Powered by PunBB
© Copyright 2002–2005 Rickard Andersson