|
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 |
---|---|
|
Questions about Assembly
Posted: Thu Jan 13, 2022 6:51 pm
|
Hey all,
I've been playing around with learning Z80 Assembly. I'm starting to feel more confident in it since I started making Z80 programs for the TI-84+ calculators, and wanted to get back into the SMS. There's just a couple of things (at the moment) that I don't entirely understand. First of all, how do you know when your code is going to execute in relation to the raster beam drawing the screen? I understand that the "halt" command has us wait for vblank, but how do you know how much code you can get away with in that time? And also, when loading assets, what are the advantages and disadvantages of using .inc or .bin files? It seems like the .bin files are smaller, but the .inc files I can go into and make adjustments if need be, but I don't know if the size of these files makes a difference or not. Thanks |
|
|
Posted: Thu Jan 13, 2022 7:03 pm Last edited by Maxim on Thu Jan 13, 2022 9:21 pm; edited 1 time in total |
When the active area of the screen finishes being drawn, and if you've configured it right, a VBlank interrupt will jump execution to offset $38. Normally you would structure your code to put all the VRAM work at this point as you have much faster access.
You don't know how much code you can execute before VBlank happens. You can use Emulicious to see the "unused" time (especially if you halt) or to profile, or you can go old-school and change the palette to see how many "lines" different bits of code take. Your goal is to get everything done in good time, all the time, else you get slowdown. Includes and binaries result in the same binary data in the ROM. One is in a form the assembler can parse, one is raw binary. You might consider instead whether it's better to have compressed assets and decompress them on load, or to have them uncompressed. The latter is technically faster but results in bigger ROMs and more wasted space as the assets don't pack into ROM banks as easily. |
|
|
Posted: Thu Jan 13, 2022 7:58 pm |
Ideally I'd like to make a bigger game (some day) so that would definitely be something I'd want to learn how to do, I've just never dealt with compression myself. I know using your bmp2tile tool it's possible to save in various formats like psgaiden, I'm just not familiar with the decompression process in assembly |
|
|
Posted: Thu Jan 13, 2022 9:21 pm |
Whether it’s compressed or not, the code is going to set the source and destination and then call a function to do the necessary work. Compressed data often has the advantage that it knows its size implicitly too. | |
|
Posted: Fri Jan 14, 2022 11:31 am |
decompressors code snippets are available too, so you don't really need to understand how the compression works. if you anyway want to, here's the relevant page |
|
|
Posted: Fri Jan 14, 2022 1:18 pm |
Thanks! Understanding everything I write is important to me. I feel guilty using something that I don't understand on at least a basic level | |