I don't know the exact details, but I know that it uses the Genesis's double-resolution mode (this is enabled by setting bits 1 and 2 of VDP register $C). I think Nemesis made a post about this a while back.
So I loaded a clean Sonic 1 ROM (it was a .gen file if that matters) into the editor and edited the first act of GHZ a bit. When I opened the edited rom in GENS all I got was a red screen. What did I do wrong and how do I fix this?
I seriously think we should bring this topic back to a place where it can be seen even by people who don't bother to search the forum. Unless keeping it hidden is part of a plan to find out lazy people. But I doubt so.
Ah, thanks. I'm kind of new at this. I know I should be starting with SonED but I hate the way it saves with project files. Plus I'm skipping the "oh shits I needs moar power" bit.
Dear christ, get your head out of your ass already. That said, the forum description says to read this forum and the archive below, which clearly had the answer to your question. There's a difference between confusion and laziness. Put a little effort into finding out the answer to a question before asking it—use the search function.
Also the Genesis DOES have "scaling" capabilities through the use of raster (I.e., line by line refreshing) effects. This is only possible for the non-sprite layers (I.e., the foreground and background), and isn't directly hardware related; it requires programming "tricks" in order to work. (Should be noted that similar effects can be done by writing to CRAM (color pallette) during line refreshes as well, theoretically allowing the entire color range of the MD on screen at once, though it's generally best used in modes where the screen is divided into horizontal sections as the normal palette restrictions still apply.)
ASM68K doesn't support the "align" directive natively, which is used to align some stuff (code, but more usually data) at a certain offset in the rom. This is useful for example to put sound banks in specific locations or something. So with this macro, which is defined at the beginning of the ASM file, you're making your ASM68K able to use the "align" directive, even if in a bastardized way. Some other assemblers, like AS (iirc) does not need this macro, as they natively support align.
To complement nineko's post... I suppose that ASM68k incorrectly assumes that MOVE, without an explicit size attribute, is a word-sized operation. However, the documentation clearly states that MOVE to USP (usp is the user stack pointer) is a long-sized operation. This is, I think, a small bug in the assembler, as other assemblers accept it just fine, but can be worked around by replacing move with move.l, as has been stated in the guide on the wiki (SCHG How-to:Convert the Hivebrain 2005 disassembly to ASM68K).
OK, Its another question from me about ASM, but I doubt this is possible, but I'd thought I'd ask. Is it possible to create random subroutine jumping in Assembly for Sonic 1? For example, is it possible to make some code so that there is a 50% chance of jumping to one Subroutine and a 50% chance of jumping to another subroutine? Thanks. EDIT: Fixed Crappy Grammar
Code (ASM): jsr RandomNumber andi.b #1,d0 tst.b d0 beq.s Routine bra.s OtherRoutine I believe that should work.
You don't need to put the TST here, as the ANDI instruction will set the flags the same way TST would, making the TST redundant. Also, you won't need the last BRA if the code is directly after.
Thanks Malevolence and FraGag for your help. I have 2 questions though. 1. Is it possible to have more than two outcomes? 2. What does the #1 mean? Thanks
It is possible to have more than one but you're going to have to make a whole table. The 1 makes sure that the result is either 1 or 0 (if you do an and 1 to the value of 0111 you'll get a 0001, if you do it to the value of 0110 you'll get a 0, and takes a value in binary and keeps all bits that are the same in both values).
You're confusing BTST and TST. TST will test the whole operand (according to its size attribute), while BTST will test a single bit, which is specified in the left operand. Anthall, if your number of outcomes is a power of 2 (2, 4, 8, 16, etc.), it's quite easy to set up: Code (ASM): jsr RandomNumber ; call the pseudo-random number generator andi.b #xx,d0 ; restrict the number to a valid range move.w RandomJumps(pc,d0.w),d0 jsr RandomJumps(pc,d0.w) ; call a random jump routine ; code continues here RandomJumps: dc.w RandomJump1-RandomJumps dc.w RandomJump2-RandomJumps dc.w RandomJump3-RandomJumps dc.w RandomJump4-RandomJumps RandomJump1: ; code here rts ; don't forget the rts! ; do the same for all other RandomJump routines In the code above, replace xx with (the number of outcomes - 1) * 2 (still assuming it's a power of 2), e.g. for 16 outcomes, use (16-1)*2 = 30 (or $1E in hex). If the number of outcomes isn't a power of 2, you'll have to use a modulo instead of ANDI; use the DIVU instruction for that (which is much slower).
