Basic Questions and Answers Thread

Discussion in 'Discussion & Q&A' started by Malevolence, Jul 7, 2009.

  1. nineko

    nineko I am the Holy Cat Member

    Joined:
    Mar 24, 2008
    Messages:
    1,902
    Location:
    italy
    Semi-related, remember that there's a bug with the HUD in Sonic 1. It's quite easy to fix it, though. If you copy the code from the link above, make sure to remove the two instances of "playsound" (and the preceding $E2 moves), as I wrote it for someone who also wanted to speed up the music.
     
  2. Deactivated Account

    Deactivated Account Well-Known Member Exiled

    Joined:
    Aug 26, 2016
    Messages:
    244
    Thank you, the Zyrinx driver works with Advanced Z80, still, I'm searching how I can make to work the pitch bend passing the octave note. I'll try to test the pitch up bend.
     
  3. TheInvisibleSun

    TheInvisibleSun Visible Member

    Joined:
    Jul 2, 2013
    Messages:
    424
    Location:
    Western New York, USA

    I believe you're spot on, as there are many things I've come to only partially understand informally through tinkering around, leading to some important knowledge gaps. So some of the following may be a bit off or incorrect:

    There is limited space in the VRAM, into which art is loaded to via address. Every tile of art takes $20 bytes of VRAM. Nemesis compressed art is organized via the Pattern Load Cues, which are typically loaded to by objects.

    From what it looks like, Uncompressed art, Enigma, and Kosinksi get loaded by setting a VRAM location in the code, and loading the art directly.

    Mappings organize how the art tiles and sprite pieces are ordered laid out, and how they are positioned on screen.

    As for palettes, the Sega Genesis/Mega Drive can only display 64 colors at once. Each color takes 2 bytes of data, for a total of $7F bytes of space at a time. Normally in Sonic 1, palettes get loaded to their own given RAM address space during the 'init' code of each gamemode, but they can be loaded/switched out on the fly as well by editing the given address of the palette.

    I admit that I don't know much about the assembler itself, or how things are actually written to display on screen (like the horizontal interrupts and what not)

    Now, from what I can tell, the Hud object itself (Object 21) only loads the text (other than SCORE's 'E'). The 'E', Zero, and the other numbers' mappings and are loaded by Hud_Base. I'd like to replicate the latter function (as I was able to edit the Hud object to only show RINGS), but due to my lack of understanding of how it all really works, I cannot.

    Thanks for all of your patience with my ignorance, and your help.
     
    Last edited: Jun 21, 2020
  4. nineko

    nineko I am the Holy Cat Member

    Joined:
    Mar 24, 2008
    Messages:
    1,902
    Location:
    italy
    Technically, it's 61, because color 0 is solid only in one of the palette lines, and transparent in the other three.

    Of course, 61 only applies to the case where you don't use advanced H-int tricks (e.g. what happens in water levels).
     
    TheInvisibleSun likes this.
  5. MarkeyJester

    MarkeyJester ♡ ! Member

    Joined:
    Jun 27, 2009
    Messages:
    2,867
    I think you'll get it then based on what you currently know. I will try to keep the details low and get to the point. Let's start by setting the VDP.

    If you want to write data into VRAM, CRAM, VSRAM, or to one of the internal VDP registers, you have to move a word of data into the VDP control port at address C00004-C00005 or C00006-C00007:
    Code:
    		move.w	#$????,($C00004).l
    		move.w	#$????,($C00006).l
    Alternatively, you can move two words at a time via a long-word:
    Code:
    		move.l	#$????????,($C00004).l
    Now, we'll look at setting the VDP to VRAM write mode, here is an example:
    Code:
    		move.l	#$58600000,($C00004).l
    5B60 and 0000 are being moved into the VDP control port, to understand what these values are, we need to break them up into binary; 0101100001100000 0000000000000000, now some of these bits are setting the VDP into a specific mode, be it read, write, to/from VRAM, CRAM, VSRAM, etc, and some of these bits are the VRAM address we're writing to or reading from, below in a code table is our bits followed below it by a key system:
    Code:
    0101100001100000 0000000000000000
    MMAAAAAAAAAAAAAA --------MMMM--AA
    M = Mode
    A = Address
    - = Unknown/invalid (leave as 0)

    We'll start with the mode, I have numbered all of the M's below:
    Code:
    0101100001100000 0000000000000000
    10AAAAAAAAAAAAAA --------5432--AA
    Depending on which of these bits (0 - 5) are set, depends on what mode you are setting the VDP to, here is a table of possible modes:
    Code:
    543210
    ------
    000001 = VRAM Write Mode
    000011 = CRAM Write Mode
    000101 = VSRAM Write Mode
    000000 = VRAM Read Mode
    001000 = CRAM Read Mode
    000100 = VSRAM Read Mode
    Now our M bits are:
    Code:
    01-------------- --------0000----
    10AAAAAAAAAAAAAA --------5432--AA
    
    000001 -> VRAM Write Mode
    So this is setting the VDP up to write to VRAM, now we need the address; I have numbered all of the A's below:
    Code:
    0101100001100000 0000000000000000
    MMDCBA9876543210 --------MMMM--FE
    Now the bits (0 - F) represent the address, these together can make a word value from 0000 - FFFF, our A bits are:
    Code:
    --01100001100000 --------------00
    MMDCBA9876543210 --------MMMM--FE
    
    0001100001100000 -> 1860
    So this long-word is setting up the VDP to VRAM write mode at address 1860.

    --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- ---

    Now that the address/mode is set, the VDP data port address at C00000-C00001 and C00002-C00003 can be written to, again, you can do them as words, or as a single long-word, a long-word is preferable since it's smaller and quicker for the 68k CPU as an instruction:
    Code:
    		move.l	#$00000000,($C00000).l
    This has now moved 0000 and 0000 into the VDP FIFO, the VDP will then copy these words into VRAM 1860 - 1863, it will then automatically advance the address ready for the next words of data:
    Code:
    		move.l	#$045670FE,($C00000).l
    This has now moved 0456 and 70FE into VRAM 1864 - 1867, the address has incremented again. This is a repeating process, and so long as you keep moving data into the VDP data port (C00000 - C00003), the data will be copied into VRAM incrementally.

    Here is an example of writing a single tiles' worth of art into VRAM 1860:
    Code:
    		move.l	#$58600000,($C00004).l		; set VDP to VRAM write mode (address 1860)
    
    		move.l	#$AAAAAAAA,($C00000).l		; write pixels into VRAM
    		move.l	#$AA0000AA,($C00000).l		; ''
    		move.l	#$A0A00A0A,($C00000).l		; ''
    		move.l	#$A00AA00A,($C00000).l		; ''
    		move.l	#$A00AA00A,($C00000).l		; ''
    		move.l	#$A0A00A0A,($C00000).l		; ''
    		move.l	#$AA0000AA,($C00000).l		; ''
    		move.l	#$AAAAAAAA,($C00000).l		; ''
    You can probably tell, this is writing a tile square with an X in it, obviously, the 0's will use colour 0 in the palette, and A will use colour A in the palette, this is pretty bog-standard...

    Now, let's assume we load some uncompressed art (say your hud numbers) into VRAM; starting by loading the address of the art into an address register:
    Code:
    		lea	(Art_Hud),a0			; load address of uncompressed art to a0
    Now, we can set the VDP VRAM write address, and then copy the art out of the address using a0, and into the VDP data port, like so:
    Code:
    		move.l	#$58600000,($C00004).l		; set VDP to VRAM write mode (address 1860)
    		move.l	(a0)+,($C00000).l		; write first tile of uncompressed art into VRAM
    		move.l	(a0)+,($C00000).l		; ''
    		move.l	(a0)+,($C00000).l		; ''
    		move.l	(a0)+,($C00000).l		; ''
    		move.l	(a0)+,($C00000).l		; ''
    		move.l	(a0)+,($C00000).l		; ''
    		move.l	(a0)+,($C00000).l		; ''
    		move.l	(a0)+,($C00000).l		; ''
    Notice the a0 being bracketed, and being suffixed with a +, this will cause the address of a0 to advance to the next long-word after every move.

    We can go one step further by copying multiple tiles in a loop:
    Code:
    		lea	(Art_Hud),a0			; load address of uncompressed art to a0
    		lea	($C00000),a6			; load VDP data port address to a6
    		move.l	#$58600000,$04(a6)		; set VDP to VRAM write mode (address 1860) - a6 = C00000 plus the $04 prefix = C00004
    		moveq	#$08-1,d1			; set number of tiles to load (8 tiles)
    
    LoadTiles:
    		move.l	(a0)+,(a6)			; write a tile of uncompressed art into VRAM
    		move.l	(a0)+,(a6)			; ''
    		move.l	(a0)+,(a6)			; ''
    		move.l	(a0)+,(a6)			; ''
    		move.l	(a0)+,(a6)			; ''
    		move.l	(a0)+,(a6)			; ''
    		move.l	(a0)+,(a6)			; ''
    		move.l	(a0)+,(a6)			; ''
    		dbf	d1,LoadTiles			; decrease d1 and loop back to LoadTiles, until d1 has passed 0
    Evertime a tile is written, the dbf instruction will subtract 1 from d1, and as long as it hasn't gone below 0, it will jump back to "LoadTiles" over and over again, 8, 7, 6, 5, 4, 3, 2, 1, 0... Then it'll resume below and continue. Notice how the VDP data port was loaded into address register a6, when data is moved into a6 while it has brackets around it, the data is actually moved to the address that a6 has, so "move.w #$0123,(a6)" will move 0123 to address C00000.

    --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- ---

    Now, I noticed in some code before, you had the following line "locVRAM $F2E0 ; set VRAM address", so I assume by this, the VRAM address these ring numbers are meant to go at F2E0? I am also going to assume that object's sprites are already mapping these tiles on-screen, and that all we need to do is write the uncompressed art to this VRAM address and everything will be solid. If this is not the case, then we may have found yet another issue which needs resolving (you can write art into VRAM perfectly, but it means nothing if there are no sprites or planes mapping out those art tiles).

    For now, let's just look at loading the uncompressed numbers correctly into VRAM F2E0+.

    The ring count, lives counter, and score, are all hexadecimal/binary numbers, and are not decimal, but, we would like to display them as decimal since the average human (let alone player) deals with numbers on a base 10 system rather than base 2 or 16. So we need to convert the hex numbers into decimal.

    The subroutines in Sonic games for displaying the HUD numbers, don't just copy uncompressed number art into VRAM, they actually realtime convert the hex number into decimal while writing the numbers to VRAM. This is done by subtracting the decimal 100's, 10's and units from the hex number. Remember the Hud_100 that's loaded into a2 in your code?
    Code:
    Hud_100:	dc.l	100
    		dc.l	10
    		dc.l	1
    These are the decimal digit places, notice how they lack a $ sign these are decimal numbers, when the assembler goes to assemble these, it'll convert them to hex, so these numbers are actually:
    Code:
    Hud_100:	dc.l	$64
    		dc.l	$0A
    		dc.l	$01
    Now here's how it works... Let's say you have 619 rings. In RAM, this will be $26B, so we need to convert this hex number into decimal 619. Start by subtracting the 100 units (this is $64 in hex):
    Code:
    	26B - 64 = 207 x1
    	207 - 64 = 1A3 x2
    	1A3 - 64 = 13F x3
    	13F - 64 =  DB x4
    	 DB - 64 =  77 x5
    	 77 - 64 =  13 x6
    	 13 - 64 = -51 --- Too far
    It took 6 times to subtract 64 from the number until it went below 0, this 6 count just happens to be the first digit of our ring number (619), next we subtract the 10 units (this is $0A in hex):
    Code:
    	 13 -  A =   9 x1
    	  9 -  A =  -1 --- Too far
    This one took less time, only 1 which happens to be the second digit in our ring count (619), finally, we subtract the 1 units:
    Code:
    	  9 -  1 =   8 x1
    	  8 -  1 =   7 x2
    	  7 -  1 =   6 x3
    	  6 -  1 =   5 x4
    	  5 -  1 =   4 x5
    	  4 -  1 =   3 x6
    	  3 -  1 =   2 x7
    	  2 -  1 =   1 x8
    	  1 -  1 =   0 x9
    	  0 -  1 =  -1 --- Too far
    This took 9 times, the last digit in our ring count (619).

    Now, this conversion process is used for the score as well, which is why the table is larger than 100's, and why it goes up to as large as 100000:
    Code:
    Hud_100000:	dc.l 100000		; XREF: Hud_Score
    Hud_10000:	dc.l 10000
    Hud_1000:	dc.l 1000		; XREF: Hud_TimeRingBonus
    Hud_100:	dc.l 100		; XREF: Hud_Rings
    Hud_10:		dc.l 10			; XREF: ContScrCounter; Hud_Secs; Hud_Lives
    Hud_1:		dc.l 1			; XREF: Hud_Mins
    Same principle is used.

    --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- ---

    Now, keep in mind as you well know, the HUD humbers are two tiles tall, this means two tiles need to be copied per digit. Lucky for you, we can reuse Sonic 1's subroutine for rendering the ring numbers, however, the subroutine expects you to provide it some information first, here's how it works:
    Code:
    		lea	($C00000).l,a6		; load VDP data port address to a6
    		move.l	#$5F400003,d0		; prepare VDP VRAM write mode and address
    		moveq	#$00,d1			; clear d1 (clears entire long-word)
    		move.w	($FFFFFE20).w,d1	; load number of rings Sonic has to the lower word of d1
    		jsr	Hud_Rings		; convert hex to decimal, and dump the number art to VRAM address in d0
    The subroutine "Hud_Rings" needs a6 to have the address of the VDP data port, it needs d0 to have the long-word VDP VRAM write address inside of it, and it needs d1 to have the number to convert and display. The subroutine will move the long-word address from d0 into the VDP control port, and it'll then convert the value in d1 into decimal, and write the correct tile art depending on the digit, into the VDP data port inside a6.

    The jsr will jump to Hud_Rings, and then once the conversion and dumping is done, it will return back to just after the jsr, and continue going down. But... we'll cross that bridge once we get to it.

    This is by no means the solution to your problem, but it should supply you with at least a decent amount of understanding and make fixing it a little bit easier. Get back to me on things like, where in VRAM the numbers are being dumped to, and whether or not the sprites are setup to display those numbers and so on, I would also like to know where (VRAM addres) and how (68k code) exactly you loaded the "RINGS" text art, this could be important.
     
  6. TheInvisibleSun

    TheInvisibleSun Visible Member

    Joined:
    Jul 2, 2013
    Messages:
    424
    Location:
    Western New York, USA
    Thanks again for your reply; I'll have to give it a more detailed read when I have more time tomorrow. In the mean time, here's some of the information you requested.

    In order to load the 'RINGS' art, I first made modified versions of both the mappings and art for the HUD that only include the 'RINGS' portion, and 'included' them within 'sonic.asm' near the other HUD files.


    Then, I added a check to the beginning of the HUD object, to make it load the alternate mappings and art, if the current gamemode is 'Special Stage' (this causes a small cosmetic issue when the stage is completed, but I plan to also solve that afterward):


    Code:
    HUD_Main:    ; Routine 0
    
            cmpi.b    #id_Special,(v_gamemode).w ; is game on special stage?
            beq.w    SSRingHud
            addq.b    #2,obRoutine(a0)
            move.w    #$90,obX(a0)
            move.w    #$108,obScreenY(a0)
            move.l    #Map_HUD,obMap(a0)
            move.w    #$6CA,obGfx(a0)
            move.b    #0,obRender(a0)
            move.b    #0,obPriority(a0)
            bra.w    HUD_Flash
    SSRingHud:
            ;addq.b    #2,obRoutine(a0)
            move.w    #$90,obX(a0)
            move.w    #$108,obScreenY(a0)
            move.l    #Map_SSRingHUD,obMap(a0)
            move.w    #$570,obGfx(a0)
            move.b    #0,obRender(a0)
            move.b    #0,obPriority(a0)
            bra.w    DispHud
            
    HUD_Flash:    ; Routine 2
            tst.w    (v_rings).w    ; do you have any rings?
            beq.s    norings1    ; if not, branch
    DispHud:
            clr.b    obFrame(a0)    ; make all counters yellow
            jmp    DisplaySprite
    The value moved to 'obGFX(a0)' is the VRAM address I sent it to in the PLC's, divided by $20.
    The special stage's PLC is as follows:

    Code:
    ; ---------------------------------------------------------------------------
    ; Pattern load cues - special stage
    ; ---------------------------------------------------------------------------
    PLC_SpecialStage:    dc.w ((PLC_SpeStageend-PLC_SpecialStage-2)/6)-1
            plcm    Nem_SSBgCloud, 0    ; bubble and cloud background
            plcm    Nem_SSBgFish, $A20    ; bird and fish    background
            plcm    Nem_SSWalls, $2840    ; walls
            plcm    Nem_Bumper, $4760    ; bumper
            plcm    Nem_SSGOAL, $4A20    ; GOAL block
            plcm    Nem_SSUpDown, $4C60    ; UP and DOWN blocks
            plcm    Nem_SSRBlock, $5E00    ; R block
            plcm    Nem_SS1UpBlock, $6E00    ; 1UP block
            plcm    Nem_SSEmStars, $7E00    ; emerald collection stars
            plcm    Nem_SSRedWhite, $8E00    ; red and white    block
            plcm    Nem_SSGhost, $9E00    ; ghost    block
            plcm    Nem_HudRings, $AE00    ; 'Rings' Hud, substituting the unused W block space
            plcm    Nem_SSGlass, $BE00    ; glass    block
            plcm    Nem_SSEmerald, $EE00    ; emeralds
            
            
            ;plcm    Nem_SSZone1, $F2E0    ; ZONE 1 block
            ;plcm    Nem_SSZone2, $F400    ; ZONE 2 block
            ;plcm    Nem_SSZone3, $F520    ; ZONE 3 block
        PLC_SpeStageend:
            ;plcm    Nem_SSZone4, $F2E0    ; ZONE 4 block
            ;plcm    Nem_SSZone5, $F400    ; ZONE 5 block
            ;plcm    Nem_SSZone6, $F520    ; ZONE 6 block
    
    I reused the unused 'W' Block's VRAM space for the 'RINGS' text, allowing its 10 tiles to slip there nicely at $AE00, resulting in this:

    Special Stage.PNG

    The 'RINGS' art alone is fully functional.

    According to the SCHG, the numbers patterns use 24 tiles ($300 bytes), so I assumed that that they would fit where the unused 'ZONE 1-3' Blocks currently are, since those currently take up a combined total of 27 tiles ($360 bytes).

    That is why in the subroutine, I attempted to use 'locVRAM' (as honestly a bit of a shot in the dark there) to set the location for the art to $F2E0, where the free space is and dump it there, to no avail.

    I'll try again tomorrow though, using the new info provided above.
     
  7. CreepyMystery

    CreepyMystery Reminiscence and Semblance Member

    Joined:
    Oct 20, 2017
    Messages:
    36
    This is my last post before Prospect, I don't know if I will be thrown into Limbo for bumping a couple of old threads, but either way, I apologize for doing that, I didn't quite grasp the rules when I first joined.

    I am working on a Sonic 2 hack called "Sonic: Project Eternal", and I was trying to change the music of my first zone to Marble Garden Zone Act 1, because it fits the midnight theme for the zone, but when I converted the BIN file with SMPSConv, then tested the hack, it would display a "soundBank "blahblah" must fit in $8000 bytes but was "$9876". Try moving something to the other bank." error, but I commented it out, but I played my zone, and the Title Screen music just hung on a note and stayed there, even when I pause the game. I thought it was because it was too big, but I still don't know about my theory, if someone can help me with this problem, that would greatly help.

    Code:
    MusicPoint2:    startBank
    MusPtr_CNZ_2P:        rom_ptr_z80    Mus_CNZ_2P
    MusPtr_EHZ:        rom_ptr_z80    Mus_EHZ
    MusPtr_MTZ:        rom_ptr_z80    Mus_MTZ
    MusPtr_CNZ:        rom_ptr_z80    Mus_CNZ
    MusPtr_MCZ:        rom_ptr_z80    Mus_MCZ
    MusPtr_MCZ_2P:        rom_ptr_z80    Mus_MCZ_2P
    MusPtr_ARZ:        rom_ptr_z80    Mus_ARZ
    MusPtr_DEZ:        rom_ptr_z80    Mus_DEZ
    MusPtr_SpecStage:    rom_ptr_z80    Mus_SpecStage
    MusPtr_Options:        rom_ptr_z80    Mus_Options
    MusPtr_Ending:        rom_ptr_z80    Mus_Ending
    MusPtr_EndBoss:        rom_ptr_z80    Mus_EndBoss
    MusPtr_CPZ:        rom_ptr_z80    Mus_CPZ
    MusPtr_Boss:        rom_ptr_z80    Mus_Boss
    MusPtr_SCZ:        rom_ptr_z80    Mus_SCZ
    MusPtr_OOZ:        rom_ptr_z80    Mus_OOZ
    MusPtr_WFZ:        rom_ptr_z80    Mus_WFZ
    MusPtr_EHZ_2P:        rom_ptr_z80    Mus_EHZ_2P
    MusPtr_2PResult:    rom_ptr_z80    Mus_2PResult
    MusPtr_SuperSonic:    rom_ptr_z80    Mus_SuperSonic
    MusPtr_HTZ:        rom_ptr_z80    Mus_HTZ
    MusPtr_ExtraLife:    rom_ptr_z80    Mus_ExtraLife
    MusPtr_Title:        rom_ptr_z80    Mus_Title
    MusPtr_EndLevel:    rom_ptr_z80    Mus_EndLevel
    MusPtr_GameOver:    rom_ptr_z80    Mus_GameOver
    MusPtr_Invincible:    rom_ptr_z80    Mus_Invincible
    MusPtr_Emerald:        rom_ptr_z80    Mus_Emerald
    MusPtr_HPZ:        rom_ptr_z80    Mus_HPZ
    MusPtr_Drowning:    rom_ptr_z80    Mus_Drowning
    MusPtr_Credits:        rom_ptr_z80    Mus_Credits
    
     
  8. Samey

    Samey Le Bored Hedgie Member

    Joined:
    May 3, 2017
    Messages:
    57
    What program would I use if I wanted to edit the sounds in Sonic 1? Like the jump sound?
     
  9. Pacca

    Pacca Having an online identity crisis since 2019 Member

    Joined:
    Jul 5, 2014
    Messages:
    1,175
    Location:
    Limbo
    Sounds have different header data, but otherwise are identical to regular SMPS songs. I'm not sure if any programs actually support the SFX header format, but I imagine that there simply must be some sort of tool or guide to convert between them. Making new SFX should basically be exactly the same as making music, provided you find a way to convert the "music" data into SFX data with that custom header format.

    As for simply editing them, I'd recommend trying to install SMPS2ASM and using that to fiddle with the sound data. It makes things a lot more self explanatory if your only goal is to poke around and experiment (I made the Sonic Odyssey red ring sound effect this way; if that's what your trying to shoot for, you might have some fun doing it this way). If you want to be more serious about it, there's probably a program you could use to edit it, I'm just not sure what can edit raw SMPS files, especially with the SFX header.

    I'm sure someone who actually does music/SFX properly could give you some less vague and more helpful directions, my only experience is trial and error through minor conversions and SMPS2ASM edits...
     
  10. Samey

    Samey Le Bored Hedgie Member

    Joined:
    May 3, 2017
    Messages:
    57
    Ah, yeah. I did try s1smps2asm, but probably because of the sfx header my disassembly just spewed out errors.
    I'll try the other one though. :)
     
    Last edited: Nov 29, 2018
  11. Pacca

    Pacca Having an online identity crisis since 2019 Member

    Joined:
    Jul 5, 2014
    Messages:
    1,175
    Location:
    Limbo
    SMPS2ASMs' conversion program has a flag that needs to be set for it to detect SFX properly. "-s" will make it convert SFX instead of music.
     
  12. MainMemory

    MainMemory Well-Known Member Member

    Joined:
    Mar 29, 2011
    Messages:
    922
    Yes, your new song is too big. There are two sound banks in Sonic 2, at MusicPoint1 and MusicPoint2. MusicPoint1 contains only the continue music, while MusicPoint2 contains all the rest of the music and the sound effects. There are two ways you can try to fix your problem: you can move the new music file to the other bank, at which point you will also need to move the music pointer and change the entry in zMasterPlaylist to match the new bank; or you can make the sound effects their own bank by invoking the "startBank" macro on the line with the SoundIndex label, like MusicPoint1 and MusicPoint2 have.

    Also, just to be clear, when making music for Sonic 2, you either have to set the music's offset to $1380 and compress it with Saxman compression (with size), or include it as ASM and tell the driver it's uncompressed by adding 20h to the entry in zMasterPlaylist.
     
  13. BurningFlame

    BurningFlame Bang! Member

    Joined:
    Jan 1, 2017
    Messages:
    40
    Location:
    Vodkaland
    Where is BossMove routine located at GitHub disassembly? I'm trying to edit LZ's boss but can't find the BossMove routine (though there is a branch to it).
     
  14. SMS Alfredo

    SMS Alfredo Compact Disc Enthusiast Member

    Joined:
    Sep 3, 2018
    Messages:
    27
    Location:
    Little Planet
    Open up sonic.asm, then use your text editor's search function and type BossMove: in the search bar. It should be right after the BossDefeated subroutine.
     
  15. Samey

    Samey Le Bored Hedgie Member

    Joined:
    May 3, 2017
    Messages:
    57
    If it's the Github disassembly, try looking in incObj folder.
     
  16. B. Comet

    B. Comet Is fun still infinite? Member

    Joined:
    Aug 19, 2016
    Messages:
    83
    Location:
    South America Zone
    So, there is this small issue, when I port a block with 1 new tile to the rom:
    [​IMG] [​IMG]

    How I can fix or prevent this from happening?

    And I think I am back from the dead.
     
  17. MainMemory

    MainMemory Well-Known Member Member

    Joined:
    Mar 29, 2011
    Messages:
    922
    Well before you do any art editing, you should merge GHZ's art into one file and make the title screen use separate art (I believe there is a guide for it). That may solve your problem by itself.
     
    B. Comet likes this.
  18. Kilo

    Kilo Foxy Fren Exiled

    Joined:
    Oct 9, 2017
    Messages:
    391
    Location:
    A warm and lovely place~
    So, I'm trying to make my hack play 2 different samples on the Sega screen, 1 is the default. The second is played when the player soft resets 5 times. For some reason it doesn't seem to be working, thoughts?:
    Code:
    Sega_WaitPallet:
    ;...
            cmpi.b    #5,($FFFFF5C0).w
            beq.s    Chant2
            add.b    #1,($FFFFF5C0).w
            moveq   #$FFFFFF84,d0
            jsr     PlaySample
            move.b    #$14,($FFFFF62A).w
            bsr.w    DelayProgram
            move.w    #$9F,($FFFFF614).w
            bra.s    Sega_WaitEnd
    Chant2:
            clr.b    ($FFFFF5C0).w
            moveq   #$FFFFFF85,d0
            jsr     PlaySample
            move.b    #$14,($FFFFF62A).w
            bsr.w    DelayProgram
            move.w    #$9F,($FFFFF614).w
    
    Sega_WaitEnd:
    ;...
     
  19. CreepyMystery

    CreepyMystery Reminiscence and Semblance Member

    Joined:
    Oct 20, 2017
    Messages:
    36
    EDIT: This problem has been solved, you can trash the post.
     

    Attached Files:

    Last edited: Dec 14, 2018
  20. RouRouRou

    RouRouRou Ain't no fun if the aliens can't have none. Member

    Joined:
    Nov 20, 2016
    Messages:
    97
    Okay, here's the rundown of my problem:

    I've added a 4th act to Molten Metro Zone (My Marble Clone) and it's mostly fine.
    One of the few issues I have is: It loads the pallet for act 3. (I have dynamic pallets installed.)

    I tried to edit the existing routine for LZ4 (SBZ3) but it never worked.

    Basically, I need to know how to get this level to load a unique pallet.
    I appreciate any help I get.

    P.S. Thanks for the HUD flicker MJ!