WIP - Walkabout (z88dk)

If you like transforming your statements into code, this is the place for you

Moderator: Programming Moderators

JoeZX
Posts: 574
Joined: Mon May 29, 2017 9:11 pm
Location: Slovakia

Re: WIP - Walkabout (z88dk)

Post by JoeZX » Tue Jun 06, 2017 5:13 am

bob_fossil wrote:
Mon Jun 05, 2017 9:50 pm
JoeZX wrote:
Mon Jun 05, 2017 8:05 pm
Just one lil thing .. after entering a bad password /mismatch by accident/ player is than moved to the game, not to menu .. so w/out a QUIT key you have to killl yourself 3 times to get back to enter a new code.
You can press delete to remove a character if you've made a mistake whilst typing. The idea was that if you entered a blank or wrong level code that you start at the first level. In the main menu you'd previously selected the play game option so going into the game regardless made sense to me. I will look at adding in a quit key.
When entering the code to the fifth level I unwittingly mismatch one letter /memory failed, mine, not the speccy one/ .. and suddenly I am at level one .. ups .. have to kill myself to get back to code entering part .. so we need QUIT key or "WRONG PASSWORD" red flashing notification with 5 secs countdown till speccy destruction .. now seriously .. RE-ENTER code or back to the main menu, something like that.

Alcoholics Anonymous
Posts: 511
Joined: Mon May 29, 2017 7:00 pm

Re: WIP - Walkabout (z88dk)

Post by Alcoholics Anonymous » Tue Jun 06, 2017 6:40 am

bob_fossil wrote:
Mon Jun 05, 2017 9:33 pm
As for the other points with inline assembly usage, well - in my defence, the wiki entries for the stack frame and inline assembler don't mention that #asm and #endasm are deprecated, that the stack handling is compiler dependant or that you shouldn't really be using it in the first place. :)
You're right about the above. Z88DK has been around for 15 years at least and documentation was made at various stages in the last 15 years. The page you are looking at is the classic library's documentation (there are two libraries in z88dk) and that's a little older than the current state of things. I didn't mean to say you were doing things all wrong, I just wanted to make sure you were aware that that is an old style.

This page is more current and touches on assembly language.

The current best practice is to:

* Put asm in their own .asm files. Asm needs to be assigned to a section to be made part of the output binary. Use headers to communicate to the compiler how to call asm functions.

* Keep .c files pure C if possible. Each .c file should be destined for the same memory bank if you will be placing things in other banks. The reason for this is the compilers can only do bank placement on a file granularity. Asm has the SECTION directive to select active bank anywhere in asm source files.

* Communicate compile time settings through a separate file containing pragmas. (Things like initial stack location, org, whether interrupts are enabled, if you will be supplying a memory map, etc)

* If your function is in an asm file (and therefore not using a C wrapper) you can get the compiler to use different function call linkages like fastcall and callee that are more efficient than standard c linkage.

* zsdcc pushes parameters in right to left order whereas sccz80 pushes in left to right order. zsdcc also pushes char as one byte whereas sccz80 pushes char as two bytes. These affect how asm gathers parameters from the stack in a function call and the difference should be accommodated with appropriate IF..ELSE..ENDIF that tests what compiler is being used (__SDCC will be defined for zsdcc and __SCCZ80 will be defined for sccz80). If you're only going to use one compiler then you don't have to worry about the other one but it's pretty easy to accommodate both. (Your compile is using sccz80).

A small example is BlackStar. "zpragma.inc" holds the pragmas configuring the compile (optional and note that these are library specific and this example uses the new c library). "zproject.lst" lists all the source files in the project and can be handed to zcc to build (a Makefile or batch builder is an alternative). The source code in src/ contains a mix of asm and c with the asm interface defined in the corresponding header file.

Anyway I will shut up on this now and concentrate on the game instead. I enjoy this genre of games so I'll be going at it for the next several days.

adam
Posts: 18
Joined: Wed May 31, 2017 5:08 am

Re: WIP - Walkabout (z88dk)

Post by adam » Tue Jun 06, 2017 5:32 pm

bob_fossil wrote:
Sat Jun 03, 2017 11:23 am
wip001-1.pngI downloaded the z88dk last week and was looking for a simple project to start off with. I have done z80 assembly in the past but liked the idea of developing the bulk in C and then swapping any bits out with assembly equivalents
Good to see, as I'm hoping to take the same approach with z88dk.

Do you think the experiment was successful - would you work like this again? Did you end up having to implement many bits in asm? More/fewer than expected?
Cheers.

User avatar
bob_fossil
Posts: 30
Joined: Tue May 30, 2017 5:26 pm

Re: WIP - Walkabout (z88dk)

Post by bob_fossil » Tue Jun 06, 2017 9:02 pm

Alcoholics Anonymous wrote:
Tue Jun 06, 2017 6:40 am

The current best practice is to:

* Put asm in their own .asm files. Asm needs to be assigned to a section to be made part of the output binary. Use headers to communicate to the compiler how to call asm functions.

* Keep .c files pure C if possible. Each .c file should be destined for the same memory bank if you will be placing things in other banks. The reason for this is the compilers can only do bank placement on a file granularity. Asm has the SECTION directive to select active bank anywhere in asm source files.

* Communicate compile time settings through a separate file containing pragmas. (Things like initial stack location, org, whether interrupts are enabled, if you will be supplying a memory map, etc)

* If your function is in an asm file (and therefore not using a C wrapper) you can get the compiler to use different function call linkages like fastcall and callee that are more efficient than standard c linkage.

* zsdcc pushes parameters in right to left order whereas sccz80 pushes in left to right order. zsdcc also pushes char as one byte whereas sccz80 pushes char as two bytes. These affect how asm gathers parameters from the stack in a function call and the difference should be accommodated with appropriate IF..ELSE..ENDIF that tests what compiler is being used (__SDCC will be defined for zsdcc and __SCCZ80 will be defined for sccz80). If you're only going to use one compiler then you don't have to worry about the other one but it's pretty easy to accommodate both. (Your compile is using sccz80).
Thanks for this useful summary. I will be implementing the changes to try and cut down / eliminate my usage of inline assembly. It was just very handy to drop into asm directly from c when I was prototyping this.
A small example is BlackStar. "zpragma.inc" holds the pragmas configuring the compile (optional and note that these are library specific and this example uses the new c library). "zproject.lst" lists all the source files in the project and can be handed to zcc to build (a Makefile or batch builder is an alternative). The source code in src/ contains a mix of asm and c with the asm interface defined in the corresponding header file.
I shall check this out too.
Anyway I will shut up on this now and concentrate on the game instead. I enjoy this genre of games so I'll be going at it for the next several days.
Looking forward to see what you come up with. :)

User avatar
bob_fossil
Posts: 30
Joined: Tue May 30, 2017 5:26 pm

Re: WIP - Walkabout (z88dk)

Post by bob_fossil » Tue Jun 06, 2017 9:15 pm

adam wrote:
Tue Jun 06, 2017 5:32 pm
Do you think the experiment was successful - would you work like this again? Did you end up having to implement many bits in asm? More/fewer than expected?
Cheers.
I think it has been a success. I went from a proof of concept in after a couple of hours to a mostly functioning prototype in a couple of days which I then managed to turn into a fully fledged-ish game. I think the choice of project was just as crucial as the decision to use z88dk. The original game had readily available levels and a simple concept which made implementing the game logic not too difficult.

I would use this approach again. I'm looking at another game to port over. Early days though yet - still scribbling on paper at the moment and I need to tidy up and finish this off. :)

As you can see, there are a couple of functions in asm - the tile printing code (for the player, level and font), the sound effect code, the key scanner and scroller in the menu and some other graphics code (screen fade and screen colouring functions). z88dk made the more involved stuff like keyboard processing, multiple joystick handling and navigating the Spectrum's 'interesting' screen layout a doddle. The core game logic is all c and it seems to run nicely enough.

Alcoholics Anonymous
Posts: 511
Joined: Mon May 29, 2017 7:00 pm

Re: WIP - Walkabout (z88dk)

Post by Alcoholics Anonymous » Wed Jun 07, 2017 5:37 am

bob_fossil wrote:
Tue Jun 06, 2017 9:02 pm
I will be implementing the changes to try and cut down / eliminate my usage of inline assembly. It was just very handy to drop into asm directly from c when I was prototyping this.
It is useful but you do have to take care with it. The case where you're mixing asm and C statements in function do_scroll(), eg, will work fine with sccz80 as compiler but not necessarily with zsdcc. The reason is sccz80 generates code in a simpler manner where it picks up a task and completes it for each statement. So it's safe to put asm code pretty much anywhere including between C statements. However zsdcc is different as it's an optimizing compiler so it can assign variables to registers or create temps on the stack that are live across a lot of C statements. The compiler cannot read your inlined asm so if your inlined asm changes a register that zsdcc has stored a value in, the program will crash. And because zsdcc does these things, you can't know for sure if the current value of a variable or function parameter is on the stack or in a register when your inlined asm runs. So inlined asm as code interspersed between C statements is not really safe with zsdcc without your personally verifying in the generated asm that it is safe. And for functions completely implemented in asm with only a C wrapper, it's much more flexible to do as pure asm.
Looking forward to see what you come up with. :)
I've got some ideas but I've also got a long list of other tasks too (streamed disk io, socket interface, Next APIs, etc).

zyser
Posts: 3
Joined: Mon May 29, 2017 6:21 pm

Re: WIP - Walkabout (z88dk)

Post by zyser » Wed Jun 07, 2017 5:45 am

Thanks bob_fossil for this post and the code, very helpful!

User avatar
bob_fossil
Posts: 30
Joined: Tue May 30, 2017 5:26 pm

Re: WIP - Walkabout (z88dk)

Post by bob_fossil » Wed Jun 07, 2017 10:13 pm

You can now quit back to the main menu in game by pressing BREAK. There's quite a lot of under the bonnet changes which you can look at on the github page. I have removed the need for sjasmplus and put nearly all of the inline assembly into matching .asm files. So the inline functions that used to live in graphics.c are now defined in graphics.asm and so on.

I have updated the original attachment to include these latest set of changes.

Any one fancy doing a loading screen or some nice AY music for this? :)

JoeZX
Posts: 574
Joined: Mon May 29, 2017 9:11 pm
Location: Slovakia

Re: WIP - Walkabout (z88dk)

Post by JoeZX » Thu Jun 08, 2017 4:31 pm

Thanks for breaking the space.

User avatar
FrankT
Posts: 9
Joined: Tue Jun 06, 2017 8:10 pm
Location: UK
Contact:

Re: WIP - Walkabout (z88dk)

Post by FrankT » Thu Jun 08, 2017 5:54 pm

bob_fossil wrote:
Wed Jun 07, 2017 10:13 pm
Any one fancy doing a loading screen or some nice AY music for this? :)
I'll have a go at some AY music.

I write AY using Vortex Tracker. I'll just submit the .pt3 files, for title music, ingame music.

I have to start writing something appropriate first. Something cheerful and jolly?

Let me know if you have a particular style of music you want.

Edit: I read on your Github that this game is "A ZX Spectrum port of an old PC game POD which had been ported to the Commodore Amiga.".

I can easily do a cover of the original music if you can provide a link to it. Or an evolution of the original music.

Post Reply