|
ForumsSega Master System / Mark III / Game GearSG-1000 / SC-3000 / SF-7000 / OMV |
Home - Forums - Games - Scans - Maps - Cheats - Credits Music - Videos - Development - Hacks - Translations - Homebrew |
Author | Message |
---|---|
|
Help understanding the meaning of ".enum $c000 export satbuf dsb 256"
Posted: Wed Sep 07, 2022 9:55 pm
|
I would like to understand the meaning of this code:
.enum $c000 export ; export labels to symbol file.
satbuf dsb 256 ; sprite attribute table buffer. ende Looking at WLA-DX docs, .enum $c000
while satbuf dsb 256
How does this translates into actual definitions? hang-on is using it in his "Create a Racing Game" tutorial, and I understand the SAT Buffer is made up of 256 bytes, starting at memory address $c000. I am trying to port this into VASM directives and this bit still confuses me. The aim is (as in the tutorial) to be able to use a SAT Buffer to update sprites' locations and copy it to the real SAT in VRAM only during VBLANK interrupt. hang-on's "ldsat" subroutine looks like: ldsat ld hl,$3f00 ; point to start of SAT in vram.
call vrampr ; prepare vram to recieve data. ld b,255 ; amount of bytes to output. ld c,$be ; destination is vdp data port. ld hl,satbuf ; source is start of sat buffer. otir ; output buffer to vdp. ret I am missing the link between updating each sprites' positions and the satbuf variable. I hope my question is kind of clear. If anyone can shed a light on this, that would be very much appreciated. DISCLAIMER: I am still sticking to VASM not because I don't like the idea of switching to WLA-DX, but mainly because at this stage it is forcing me to understand what all directives do. My aim is to learn for now, not to produce a game :) |
|
|
Posted: Wed Sep 07, 2022 11:55 pm |
Hi again @umbe1987, glad to see you're persisting with the learning, looks like you're making progress!
The .enum directive is really a convenient form of a regular define directive, the simple goal here being to assign the memory address of $c000 to the label "satbuf". This is used in hangon's statement that says: ld hl, satbuf
This is equivalent to writing ld hl, $c000
because the enum directive assigns the value of $c000 to satbuf. All assemblers have some form of definition directive, but they can work differently. Many assemblers implement defines as a pre-processor directive, which means that before the code is assembled the symbol (here "satbuf") is literally replaced with the text "$c000", but wla-dx doesn't work like that, it keeps its defines symbolic so they work a lot like variables in other languages. The difference in wla-dx between the .enum directive and the .define directive is that with .define you always have to keep specifying the value on the right hand side, whereas with .enum you just give it a start value and specify the sizes of each item and it works out the relative values automatically for you. So for example: .enum $c000 ; $c000 is the start value of our enum port_3e_status db ; db means one byte ptr_welcome_msg dw ; dw means two bytes satbuf dsb 256 ; dsb 256 means 256 bytes n_lives db .ende Is equivalent to writing this: .define port_3e_status = $c000 ; because of the start value .define ptr_welcome_msg = $c001 ; one byte later... .define satbuf = $c003 ; two bytes later... .define n_lives = $c103 ; 256 bytes later... (note the = symbol is optional in wla-dx and often not used, but I added it here for clarity) So you can hopefully see how .enum is quite useful for defining variables in RAM, or at least specifying the addresses of variables in RAM. There are also other more sophisticated ways to do this in wla-dx, notably the .ramsection directive. You could also use .enum to refer to addresses in ROM, for example if you had some constants or a constant data structure to reference. Again there are other more sophisticated ways to achieve those things. Hope that makes sense. |
|
|
Posted: Thu Sep 08, 2022 9:25 pm |
Hi,
willbritton is of course right, and I have nothing more to add :) I have not used enum in recent years, because I use .ramsection instead. If you have any more questions or comments on the Racer tutorial, don’t hesitate to post here on the forum. The Racer tutorial is exactly what it says it is: A snapshot of my approaches and skills at the time I made my first real SMS game. Not that I’m in any way a coding authority now, but I picked up quite a few refinements over the years, with the help from this commumity. Even though I would never build it anything like that today, as I look back on the Racer code, I can still appreciate it’s punk-rock direct approach - complete with strange variable names, hardcoded magic numbers and a fundamental disregard for making clean, easily maintanable code. |
|
|
Posted: Sun Sep 11, 2022 6:39 pm Last edited by umbe1987 on Mon Sep 12, 2022 8:44 pm; edited 1 time in total |
@willbritton
Thank you so much for your continuous support and essential help! @hang-on Although "outdated" (in the sense, compared to how you would code it nowadays), I am extremely grateful for your tutorial: it really helped me a lot. Thanks to you, I was able to refactor my ugly code into a new "somewhat not as ugly as it was before" working code. At least, I am now more confident to understand better what I am doing :) As for the .enum stuff, I am simply skipping it now since I am able to get track of all the addresses in my code so far. I will surely implement a strategy like .enum or even .ramsection as I move on. |
|
|
Posted: Sun Sep 11, 2022 7:11 pm |
I feel tempted to make a version of Racer with better labels… | |
|
Posted: Mon Sep 12, 2022 5:29 pm |
Thanks for the kind words, umbe! I’m very happy you find the tutorial useful… and @Maxim, I would feel honored if you decide to add to the tutorial and/or improve the Racer code someday. Even though I still like the rough aesthetics of labels like “upbuf” and the strange idea of individually naming the enemy cars… :) |
|