Glitch City Laboratories Archives

Glitch City Laboratories closed on 1 September 2020 (announcement). This is an archived copy of a thread from Glitch City Laboratories Forums.

You can join Glitch City Research Institute to ask questions or discuss current developments.

You may also download the archive of this forum in .tar.gz, .sql.gz, or .sqlite.gz formats.

Generation I Glitch Discussion

Converting Z80 assembly to something I can use. - Page 1

Converting Z80 assembly to something I can use.

Posted by: GreenGriffin5
Date: 2017-12-29 08:28:54
So, I have seen some uses of TAS to program Gen 1 games into something completely new, but I personally have no way to interact with the cartridge.  I am planning to use an in-game RAM writer I have come across to implement it from the inside, but all I have is the source code, in Z80 assembly, which I don't understand.  Is there a way to convert these assembly programs to addresses and the values to write to them, or am I going to have to learn assembly? *shudder*

Re: Converting Z80 assembly to something I can use.

Posted by: Couldntthinkofaname
Date: 2017-12-29 09:16:36
I think you're a little bit confused as to what assembly actually is. Assenbly only translates to Hexadecimal, or "values", not addresses to write them to.

But yeah, if you want to convert gbz80 into Hexadecimal, you can do so with GBZ80aid. This will give you the Hexadecimal (values) of the pragram, but chances are you're still going to need to know a bit of ASM to understand what you're doing.


or am I going to have to learn assembly? *shudder*


Don't shudder, gbz80 is not hard :). There might seem like a lot to know but basically it's a simple matter of taking values and moving them around. If you would like to start learning, we have a guide here

Re: Converting Z80 assembly to something I can use.

Posted by: GreenGriffin5
Date: 2017-12-29 09:34:21

I think you're a little bit confused as to what assembly actually is. Assenbly only translates to Hexadecimal, or "values", not addresses to write them to.


So the instructions can be written anywhere there's free space?  The setup I'm trying to do at the moment is MrCheeze's virus 2.0, and that affects specific room scripts, so I assumed data needs to be put in precise locations.  Is this usually not the case?

Re: Converting Z80 assembly to something I can use.

Posted by: Couldntthinkofaname
Date: 2017-12-29 09:46:19
Mr.Cheese's virus? Yeah, that's an RCE hack, which requires a specific Pokemon setup, meaning the payload has to be written both at Red's name and at Pokémon data.

Is this usually not the case?


Usually it is not the case as most decelopers write large programs at empty/currently empty space, so long as they have a bootstrapper to this code. Usually, it's $D901, but RCE works a lot differentlly then normal ACE.

Re: Converting Z80 assembly to something I can use.

Posted by: GreenGriffin5
Date: 2017-12-29 09:52:46

RCE works a lot differentlly then normal ACE.

But can it still be implemented and written in the same way?  Sorry, I am very new to this scene, and RCE is something I have yet to dabble in.  For now, all I intend to do is copy this existing program.  How would I go about this if it's different to ACE?

Re: Converting Z80 assembly to something I can use.

Posted by: Couldntthinkofaname
Date: 2017-12-30 09:56:07
Hi! Sorry for the late response.

RCE is very complicated, especially if you're new to the ACE scene. To explain this, i'll give you a basic rundown of what exactly happens when Mr.Cheese's virus is traded with (Note: I will be reffering to the virus as "Master", and the victim gameboy as "slave")
<Master + Slave>: Joins trade center
<Master + Slave>: Initiates trade
<Slave>: Attempts to display Master's party. By doing so, a buffer overflow occurs, and the name of Pokemon $CE is written to a specific part in Slave's stack
<Master>: Attempts to display own party. It also buffer overflows, writing glitch Pokemon $F1's name to it's own stack
<Slave + Master>: Name displaying buffer hits $FF terminator, buffer attempts to return.
<Slave>: Corrupted return signal forces Slave to return to $D7A3
<Master>: Corrupted return signal (due to stack corruption) forces Master to return to $D730
<Slave>: NOP slides into Master's name. Calls synchronizing function, and displays "Waiting!" on the screen
<Master>: Executes pre-written code at $D743, calls same function. Displays "Waiting!"
<Slave + Master>: Once both are synchronized, the each call a delay function at $3DD7
<Slave>: Jumps to a payload written by Master at Pokemon party data
<Slave>: Initiates data transfer at master. Requests $110 bytes of data, promises garbage in return
<Master>: Throws garbage sent by slave in an otherwise unnecessary graphics buffer, sends payload to slave.
<Slave>: Receives payload, writes it to $DC00
<Slave>: Filters out $FD bytes sent by master
<Slave> Executes $DC00
<Slave> Requests save data from master, promises garbage in return
<Master>: Sends save data, discards garbage in a graphics buffer

This repeats until save data is finished transferring.

<Slave> Copies save data into own SRAM
<Slave> Reboots

I'm a little bit busy at the moment, but i'll finish this comment with how to write this when I get free time. :)

Re: Converting Z80 assembly to something I can use.

Posted by: GreenGriffin5
Date: 2018-01-04 07:17:10
Hi!

Sorry for the stupid question.

Again, I am very new to this, but where it says "requests save file" and "sends save file", are we talking about copying the whole thing?  Because the one I'm trying to write is the Virus 2.0, not the first one, and as far as I'm aware, the 2.0 only sends the room scripts, and the HRAM routine to patch them.  Does the "Send save file" only mean a small part of it that contains this code?  Sorry if I'm missing something here.

Re: Converting Z80 assembly to something I can use.

Posted by: Couldntthinkofaname
Date: 2018-01-04 08:48:02

Again, I am very new to this, but where it says "requests save file" and "sends save file", are we talking about copying the whole thing?


Good question, you're right in the fact that the program only transfers a small portion of the save file, specifically $01:A500-$01:B700. Since there isn't too much free space in WRAM, the virus sends this portion in smaller portions at a time, as opposed to sending the whole save file.

If you would like to view Mr.cheese's source code, it's here :)