Basic Questions & Answers thread

Assuming you mean for the Mega drive, and assuming you mean write mode, then KingofHarts has pretty much bumped it on the head.

 

I actually had that first, but it didn't work so I switched the last two bits. Well, at least now I know the mistake is somewhere else. Thanks!

 

Out of curiousity, what was your final result?

 

Nothing, I didn't get it to work.

 

Does anyone know how S3K manages shield overwriting? Say you bust open one shield monitor (which in my case is the blue shield), then bust open a different type (in my case the fire shield), or vice versa, which in my S2 hack, results in a crash.

I understand that the fire shield would be overwriting the blue shield at Sonic_Shield+id, but S3K seems to do that without any problems, though I do see that it uses move.l and an address (Obj_Fire_Shield) instead of an ID, but I wouldn't know what that means. Heck, I don't even understand how moving an ID to a RAM address actually loads the object. I thought using ObjectDelete and/or clearing Sonic_Shield+id would fix this, but my current implementations do nothing to prevent the error.

 

In Sonic 1 and 2, the first byte of an object is an ID number that the object manager uses as an index to a pointer table with pointers to code for each object. Generally an object uses the routine byte to determine which section of code to run, and when an object has just been loaded that byte is 0, which tells the object to run its initialization code. S3K has the first four bytes reserved for a pointer directly to the object's code address, and it might be that when it loads the shields, it points directly to an initialization routine instead of a main routine. You might be able to fix it by setting Sonic_Shield+routine to 0 when you change the id.

 

Hi

Is there anywhere a list of Sonic hacks that work on the Mega Everdrive?

I can't seem to find a proper list (I apologize if I have missed one somewhere).

Any help would be appreciated.

 

This would've been better suited for Basic Q&A... if not somewhere other than E&RE... Also the title is a tad misleading... I thought this had a list of such things, (which would've made it a little more worthy of this spot on the forum...)
My nitpicking aside, to the best of my knowledge, there is not... and there really should be. Perhaps this is something that could be added to the wiki for hacks, a table of some kind that notes which emulators/devices a hack is compatible with.

I'd suggest that this thread be moved to Site Affairs (or whichever appropriate place), and perhaps one of our Wiki Sysops could lay the groundwork for setting up a template that people could start editing. I've already got MOST of the hacks on the wiki (and some that are not...) on my PC and could begin testing compatibility with REGEN and GENS... I don't own an EverDrive though, so someone else would need to take on that task.

 

Ok sorry for the confusion, if thread could be moved that would be cool.

Just think an 'official' list thats easy to access would be great.

EDIT

I've edited the tittle to help.

 

Thanks, it worked like a charm! I see where I overlooked the problem: From what I can tell, in their native S3K form, the shields don't use the routine byte, instead they load sections of themselves into a0, but in my port, the routine system was reintroduced and the S3K one was scrapped. This would explain why my age old insta-shield port never worked, as I never did so.

 

So I'm having a small issue with working with VRAM in Sonic 1.

I would like to shift the animated art (MZ lava, GHZ flowers, SBZ smoke) to another area in VRAM. I know how to move the tiles themselves... BUT I don't know how to make said animated art read from the new position (if that makes sense)

Could anyone gimme a hand with that little bit?

 

Ah, now this IS a tricky one. The tools available, SonED and SonLVL, might not have the functions you need. I know SonED doesn't allow you to advance the tile ID beyond the total amount, I'm not sure about SonLVL though.

I can however give you "a" method. You'll need a hexadecimal editor, and a means of decompressing/recompressing the level data.

The part of the level data that is responsible for mapping the tiles themselves, is the 16x16 blocks. So if we decompress say GHZ's 16x16 blocks and have a look at it through a hex editor, we get:



Now notice, I've highlighted the first 8 bytes. This is block 000, the next 8 bytes is block 001, the next 8 is block 002, etc. So if you want to, you can use a level editor like SonED or SonLVL or whatever, and find the block of tiles you want to change. The GHZ star flower for example is made up of four blocks:

• Top left block = 1AB
• Top right block = 1AC
• Bottom left block = 1AD
• Bottom right block = 1AE

We'll edit the top left block for this example, block ID 1AB x 8 = D58. So at offset D58 we have:



The block is made up of 8 bytes, each two bytes grouped together to form four words, we have; tile 235C, tile 235D, tile 235E, and tile 235F. To understand the tile format, you need to look at each word in binary: PCCV HTTT TTTT TTTT

P = Priority (0 low plane | 1 high plane)
C = Colour palette line (00 Line 1 | 01 Line 2 | 10 Line 3 | 11 Line 4)
V = Vertical flip flag (0 upright | 1 upside-down)
H = Horizontal flip flag (0 normal | 1 flipped horizontally)
T = Tile index

So we'll take the tile 235C and look in binary, we get 0010 0011 0101 1100. Priority is low plane, colour palette line 2 is used, the tile is not flipped vertically or horizontally, and the tile index is 011 0101 1100. In hex that's 35C. Multiply that by 20 gives you 6B80, which is the VRAM location where the animated tile is.

Make your tile changes, save it, recompress it, and you'll be good to go.

---

If you mean the actual loading of the animated tiles into VRAM, then what you're looking for is (GHZ flower example):

Code (Text):

1. loc_1C0E8:
2.         lsl.w   #7,d0
3.         move.w  d0,d1
4.         add.w   d0,d0
5.         add.w   d1,d0
6.         move.l  #$6D800001,($C00004).l      ; <- this
7.         lea (Art_GhzFlower2).l,a1 ; load small flower patterns
8.         lea (a1,d0.w),a1
9.         move.w  #$B,d1
10.         bsr.w   LoadTiles
11.  
12. locret_1C10C:
13.         rts

I explained this a while a go here

The only difference is you won't need to have that DMA bit (z0) enabled.

 

Actually, SonLVL does, since it allows you to type in a tile number for blocks.

 

I'm trying to get the 2007 disassembly of Sonic 2 working, but my issue is applicable to the version on GitHub too because it's actually a problem with AS. The pack of precompiled Linux binaries on the Disassemblies page is a little stale (splitrom doesn't work, but recompiling that is trivial by comparison) and there's no Alfred-approved precompiled AS for Linux; when I compile it myself (using -O3 --fomit-frame-pointer -Wall) it produces a non-functional ROM, and when the option to assemble the Z80 sound driver manually is enabled spits the error

Code (Text):

1. overlapping strcpy() called from address 0x0x418d43, resolve this address with addr2line and report to author

at me a few times. addr2line is temperamental, but I've managed to coax it into giving up the origin of the strcpy() call - asmpars.c, line 1904.

I don't know C, so I can't debug this any further; how do I compile AS so it works correctly?

 

First off, the obligatory "why do you want to use the 2007 disassembly, it is outdated and disassembles several things wrong that have been fixed in the more recent disassemblies" question.

Anyway, back to your question: sometime ago, there was a thread* about that in the (then) SVN board where someone** published the source for a modified AS that worked correctly when compiled on Linux and Mac OS X. The Hg/GitHub disassemblies have even been modified to work correctly with case-sensitive assembly with this version, and I have been using it to build my hack. Anyway, here is the diff from the then-current version of AS to this modified, working version. Apply the patch, compile from scratch and give the finger to forget about Alfred-approved versions.

* I can't seem to find it, but I didn't try very hard.
** Can't remember who, sorry.

 

Same reason why anyone wants to use Microsoft Office 2003 compared to Office 2013, it's 200 times simpler (IMO) =P

 

The analogy with Office fails in so may levels I won't bother with it; but simpler? Don't make me laugh. Without looking anywhere, can you tell me what is stored in address $FFFFF654 in S2? What about sub_ABE2, do you know what it does? Compare with "PalCycle_Frame3" and "EndingSequence_LoadCharacterArt", from the newer disassembly; which one is easier to use and understand?

 

The lables, equates and stuff is OK. It's when comments, instruction indent positions, and seperation comment lines are all over the place, unaligned, and untidy, that I find the difficulty strikes in. It's the case of; opening the source, seeing a mess, and thinking, "oh god, I can't be bothered".

It's a matter of preferrence though, some people prefer the advances of equates, macros and more detailed routines. Others prefer a directly (although incomplete) tidier environment, and have worked with the older varients long enough to know what the RAM space F654 - 5 is used for, and what the routine at original offset 00ABE2 does. I do agree though, the analogy chosen there isn't exactly refined as accurate to the situation... BUT, who the fuck cares, it's not killing you.

 

It's more than likely because I am use to it. When I did my guides, I did guides for both versions, and I just couldn't get use to the SVN because there's too many macros and variables, sometimes I just want simple numbers. Also, most coding is in one nice ASM file whereas SVN has it in multiple files and have to find the right file. If I want to change all instances, I have to do it in several files. I know Sonic 2 isn't so bad for this but Sonic 1 is a pain in the ass, reason why I don't bother hacking it.

EDIT: BTW, I am at work so I can't actually answer your questions =P

Me and flamewing have argued about this before, lol. I respect his choice though, he gets on with SVN whereas Xeno is the one for me

 

I think most of the problems with the current disassembles are mostly directed at Sonic 1's in particular. It had a much more radical change than Sonic 2's with many labels being changed and older ones not being referenced which is a huge problem that is no doubt making people not want to touch it. Despite this version being released years ago, why hasn't anyone actually done something about it? You can't complain that people aren't using them when the core issues aren't dealt with.

There's also the split files that can be off-putting as well. I'm not exactly that bothered about the equates, I used the SVN disssembly to port from Sonic 1 to Sonic 2 simply because I can see what I need to change easier instead of just values. I have suggested to people about perhaps doing a rewrite of the 2005 disassembly to update it without having all the issues that people are not wanting to use it. There could be the equates, maybe the macros and perhaps the label changes as long as the old ones are referenced.