Acmlm's Board - I2 Archive - Super Mario World hacking - Question about a program for ASM
| User | Post |
jman2050
Posts: 60/123 |
Some n00b is telling Parasyte of all people he can't program correctly? Ha ha ha, that's a good one... seriously, it's one thing to be clueless, misguided, and ignorant, but it is quite another to be just plain stupid. And that's exactly what you are, not knowing anything about the hardware you are trying to explain. And don't give this crap about "oh, but zsnes copies he rom into ram before running. So you're wrong, lol" because no one here gives two craps about the actual behavior of an emulator, since it is merely mimicing an existing system.
In short, your wrong, Parasyte is right, and we can all be happy, let this argument pass, and get back to helping the topic creator write ASM code. 'kay? |
Parasyte
Posts: 254/514 |
Originally posted by Atma X
Um dude, nothing runs directly from ROM.
The Information is copied from ROM to RAM, and then run from RAM (It makes an EXACT COPY of the program/game to RAM, so it can be run from RAM, because it cannot be run from ROM at all, for any reason) Easy concept to understand? I hope so, because it is.
I think you need to get your head out of the clouds. 
Btw, how do you program anything correctly when you don't even know that the Information needs to be copied from ROM to RAM in order to be run?
I tend to "program correctly" because I understand the machine I write programs for. In the case of x86-based machines, I am well aware of the fact that all code and data is available only in RAM during the life of the program. But that is not what we are discussing.
On SNES it is a fact that the ROM addresses accessed by the 65c816 are indeed ROM. The SNES begins running code from the reset vector which points to a ROM address. The 65c816 executes the code at the reset vector directly. That means it puts instruction data on the bus by initiating a read directly from ROM. The data sits on the bus and enters the cpu circuitry, where it is then decoded. Finally, the decoded instruction is "executed" via plenty more circuitry, where data is either input or output to the bus (or not at all) depending on the instruction. The 65c816 is a very simple CISC CPU with no means of instruction caching. Without an instruction cache, it does not copy the instruction data anywhere. If the instruction data is in ROM, it is run directly from ROM. If it is in RAM, it is run directly from RAM.
SNES has a very limited amount of RAM. You seem to be thinking something along the lines of, "Anything in SNES address space must be RAM." Well, you're wrong. SNES address space is mapped to hardware in a nasty array. In banks $00 - $3F, you have RAM at :0000 - :1FFF, some hardware I/O registers at :2000 - :5FFF, ROM at :8000 - :FFFF. SRAM at $70:0000 - $70:7FFF. And more RAM (albeit mapped in a stange manner) at $7E:0000 - $7F:FFFF. Obviously, not all of SNES address space is RAM. Namely the ROM banks at $00:8000, $01:8000, $02:8000, and etc. That is actual ROM, believe it or not. Any time a game executes code at $00:8000 (which is usually the reset vector for LoROM) the CPU is accessing the ROM chip on the cart directly. There is no copying going on. Therefore, it is said to be running directly in ROM. If you want to verify this, feel free to pull your cart out while the game is running. If the code were running in RAM, the game would not crash. A game like Super Mario World will just crash. N64, on the other hand (a console which actually does copy data into RAM before using it) will happily run without a cart until it tries to get more data from the cart. (Keep in mind that to do this on N64, you must hold reset before pulling the cart out. This will keep the hardware from checking for the cart. If it doesn't check for the cart, it won't know it's been taken out. Therefore it will not trigger an exception, which would "crash" the game.)
So yeah, that's how I can "program correctly". I do understand what is going on, deep down inside that hardware. But I hope you're learning something from all of this. You seem to be making assumptions, rather than doing any kind of research. And that is helping no one. |
Atma X
Posts: 708/801 |
Originally posted by Parasyte
Now that you have the tools and means to verify that SNES runs code directly from ROM, do so.
Um dude, nothing runs directly from ROM.
The Information is copied from ROM to RAM, and then run from RAM (It makes an EXACT COPY of the program/game to RAM, so it can be run from RAM, because it cannot be run from ROM at all, for any reason) Easy concept to understand? I hope so, because it is.
I think you need to get your head out of the clouds.
Btw, how do you program anything correctly when you don't even know that the Information needs to be copied from ROM to RAM in order to be run? |
HyperLamer
Posts: 3082/8210 |
You guys just seem to be getting confused by storage mediums. First off, SRAM and RAM are identical. If you cut the power, their contents are lost. The difference is that SRAM is generally connected to a battery, so when you cut the power to the cartridge, the chip is still powered. For all intents and purposes, SRAM = RAM with a battery.
Now, as far as the whole hard drive/ROM issue goes... Technically a hard drive is not ROM (because it's rewriteable) or RAM (because it works differently). But, when you run the game, the ROM file and SRAM file get copied into the computer's memory. In a way, you could say that it's all RAM, because that's what it's stored in, but you still wouldn't be entirely correct.
The easiest way to understand this is exactly what each one of them is in an emulator. Part of the memory is set aside for the game's RAM. When you close the emulator (equivilant to turning the power off), this memory gets cleared, so it can be considered RAM. Another part of memory is reserved for the game's program code (the parts that are stored on a ROM chip in a real cartridge). Technically this is RAM, but with one major exception: The emulator will not let the game modify it. As far as the game is concerned this memory area is read-only - thus, ROM. And finally, some memory is reserved for SRAM. It's the same as RAM, but its contents aren't lost when the program is closed.
Simple enough? The part called ROM is read-only, and the part called SRAM starts with the same values it had last time, just like real ROM and SRAM chips, even though it's all being stored in a RAM chip. |
Parasyte
Posts: 249/514 |
*sigh* Let's try this again.
Say you're playing good ol' Super Mario World on your SNES. Now hit your SNES with a nice, big hammer, or cut it open with some really nice laser or something. Now borrow a powerful microscope, and a logic analyzer. Now that you have the tools and means to verify that SNES runs code directly from ROM, do so.
You have your head in the clouds thinking that an emulator is in it's own little world, seperated from the real world, where SNES hardware once existed (and still does, to this day). The rules of SNES hacking are quite literally governed by the SNES hardware. That being the case, I'd appreciate it if you would stop confusing matters by looking at an emulator as anything but a virtual hardware system.
No, an emulator is not really running code from "ROM" but as far as the emulator and game are concerned, it is ROM. |
Atma X
Posts: 707/801 |
Exactly, FuSoYa knows what I'm talking about with the diff between SRAM and Save Files.
DahrkDaiz: Thanks for the explination with the Consoles Battery and SRAM.
(but I was still referring to the way SRAM works with Games run on Emulators)
Quoting FuSoYa,..... and myself
"Save files that get produced are ROM (AKA a File stored into your Hard Drive)"
Opps, I did screw up on that.
---so what's the name for Readable and Writable Memeory (R/W Mem that is not RAM),... like a Hard Drive for instance.
(Ok everyone, I confused ROM with the kind of Mem a Hard Drive etc. is).
Quoting Kyouji
I was gonna yell at him for saying firmware is another name for hardware, but he edited it out =/
Yea, I was writing too fast, and took another look at it to see that I had made a mistake.
Quoting Parasyte
Further, I never said that 'running' is an improper term. I said that 'perform' is an improper term. I also said that 'interpret' and 'handle' are improper terms. The correct terms are execute, run, etc.
Execute, Run, and Perform all mean the same thing (because one of the definitions of Execute is Perform, and if Run means Execute as you say, then all 3 are alike).
Quoting Parasyte
Almost all instructions are executed from ROM.
Um, that's partially wrong, because the Game isn't ROM, and so ROM isn't the main thing that Instructions are executed from (at least not in most cases).
*Good to see that all cleared up.*
Alastor the Stylish
Posts: 4842/7620 |
I was gonna yell at him for saying firmware is another name for hardware, but he edited it out =/ |
FuSoYa
Posts: 142/255 |
Originally posted by DahrkDaiz
SRAM isn't a special file that's written.
Except when you're dealing with an emulator, where the SRAM (or rather, the regular RAM your emulator temporarily set aside to serve for what would be battery-backed SRAM on the SNES) data is copied to a file on your hard drive so you'll still have it when you shut the emulator down. And just as a ROM image on you hard drive is not literally ROM, an SRAM file on your hard drive is not literally SRAM. But we call them that anyway, because people are lazy and it's generally understood what those files are for.
Just thought I'd cover all the bases. 
I hope you don't feel picked on Atma... but when you say something like "Save files that get produced are ROM (AKA a File stored into your Hard Drive)", it's kind of hard to ignore. 
|
DahrkDaiz
Posts: 486/885 |
I must back up Parasyte on this. RAM is memory that's powered by electricity and when the the electricity is cut off, the contents of the RAM will go away. SRAM isn't a special file that's written.
SRAM is the normal ole RAM that's placed onto the cart, it's written and read into as normal, except there's a battery that has a charge to supply electricity to the RAM so when the console is turned, off, the battery will still flow electricity into it and the RAM doesn't die, effectively saving it.
This is why when you lose a save on a game cart, it's usually said that the "battery died". Which means the battery no longer holds a charge to power the RAM on the cart. So you can still save a game and the game will remain as long as the system isn't cut off, because electricity is being supplied to it constantly. Once you turn the console off or pull the cart out, the RAM inside the cart loses it's contents and you lose your saves. Thus, once the battey on a cart that keeps SRAM alive dies, that SRAM because normal ole RAM. |
jman2050
Posts: 59/123 |
there is absolutely nothing about the behavior of SRAM that would differentiate it from any other sort of RAM. It can be read from and written to non-sequentially. It relies on an electrical chare to maintain the states of its bits. The ONLY difference between the two is that SRAM receives it's power source from the battery. The battery is not RAM, it is a power source, no different from the power the console/PC gets from the outlet on the wall. Thinking otherwise means you misunderstand the very concept of the terms.
|
Parasyte
Posts: 247/514 |
What are you talking about? SRAM is RAM. It is RAM because you have direct write access to it. If it were flash ROM, then it would technically be ROM, but with the ability to erase and rewrite sectors. Same goes for EPROM and EEPROM - technically ROM but with the ability to erase and rewrite sectors.
Flash and (E)EPROM require special registers to be accessed before sectors can be erased or written. With SRAM you simply write to it in order to make any changes to any byte. That is how RAM works. The fact that it is never refreshed (until it loses power, of course) has nothing to do with it being RAM or not.
In order to prove this point, here is an excerpt from the quote you posted:
The feature that sets RAM apart from ROM is its changeability: the fact that you can alter the contents of RAM at will.
It is definitely RAM! Do not confuse the issue.
Further, I never said that 'running' is an improper term. I said that 'perform' is an improper term. I also said that 'interpret' and 'handle' are improper terms. The correct terms are execute, run, etc.
Originally posted by Atma X
Now, I don't know how the Game itself got the Term ROM, but that is an incorrect term for even that, since it is permanent Memory (if ROM were a correct term for the Game, I wouldn't be able to edit the Game in a Hex Editor now would I)
No, what you have is a copy of the data present on a physical ROM chip. It is not a ROM in and of itself; it is a ROM image (or ROM dump; similar to a CD image). If you only had the actual chip from which the game was copied, you would not be able to change it, now would you? That is ROM.
Originally posted by Atma X
Maybe the person who came up with that, was refering to the actuall Game Cart, and forgot to distinguish a difference between the two (the Game on a Hard Drive, and the Game on the Cart,... the Game Cart can only be written to once, right?,... that's what I remember seeing somewhere)
As I said, the difference is that one is a copy. The common misconception is that everyone just calls ROM images, 'ROMs'. I can see how that would confuse you. |
FuSoYa
Posts: 141/255 |
Yea, it's not ROM, and is definately not RAM.
Well, of course it isn't.  Topics such as virtual RAM and flash ROM drives aside, a hard drive is traditionally not considered memory, just disk storage.
Mabey the person who came up with that, was refering to the actuall Game Cart, and forgot to distinguish a difference between the two (the Game on a Hard Drive, and the Game on the Cart,... the Game Cart can only be written to once, right?,... that's what I remember seeing somewhere)
He didn't forget anything. They're more accurately referred to as SNES ROM image files because it's an exact image of what was on the original ROM cart. But it's easier to just shorten the name to ROMs. Just as it's easier to refer to SRAM files by name, as that's what they're used for in an emulator.
No one is under the impression that you're literally making parts of your hard drive unwritable, or throwing memory chips in it. ^^ Just as when you take a picture with your camera and put it on your hard drive, you still call it a picture because of what the data represents or is used for.
Yea, I worded that wrong. I was meaning to say that Data and Instructions is loaded from ROM, and is Processed in RAM.
Technically, it's still wrong. Data and instructions are processed in the CPU. That's why it's called the Central Processing Unit, after all. RAM and ROM don't do processing of any sort. They only hold data.
RAM is where EVERYTHING is Run
The address that your CPU is grabbing the next instruction from is considered to be where you are "running" or executing at. The SNES CPU's PC register can be set to a RAM or ROM address, meaning you can run/execute instructions directly from RAM or ROM. Depending on the instruction, the CPU may modify or store something in RAM. Or the instruction could be for modifying an internal CPU register, in which case the SNES RAM isn't touched.
While technically the SNES emulator on your PC is running and accessing everything in RAM, for the purposes of emulation it must not allow operations that wouldn't be permitted on a real SNES system. Thus, as far as your SNES game is concerned, the ROM is still ROM and the RAM is still RAM.
And as Parasyte said, the SNES doesn't usually run anything from RAM.
And about running being an improper term, look how it's used below (in the Smaller, Green Text): (they use the word up as the word meaning to load something
Hardly. They're using "up and running" to mean getting something started. |
Atma X
Posts: 705/801 |
Yea, Kyouji's right. Yea, it's not ROM, and is definately not RAM. Yes, the memory is in RAM while playing the game, but as soon as you turn it off, RAM is erased (so if the save data never got copied to a different file, then,... bye bye save data, you're at the begining of the game again).
Well ok, now that Kyouji pointed that out, I'm not sure which term is correct for save data, but it is definately not RAM.
And about running being an improper term, look how it's used below (in the Smaller, Green Text):
(they use the word up as the word meaning to load something, and running as the word for the tasks being in session.
Webstie this info came from: http://www.systemsmedic.com/HardwareEdu3.htm
Only a small part of the operating system is stored in ROM. Just enough to get the hardware up and running and to tell the CPU how to locate and load the rest of the operating system from disk.
And also, for more info on RAM and ROM, read this (from the same webpage) :
With the development of random access memory, the CPU can go directly to whichever mailbox it is interested in. The difference between random access memory and this older type of sequential access memory is like comparing CDs to cassette tapes. If you want to listen to the fifth song on a cassette tape (sequential access), you have to start at the beginning of the tape and move past the first four songs, even if you fast-forward the tape. With a CD (random access), you can go directly to song five.
Disks are random access devices, too. Rather than starting from the outside of the disk and reading inward, or from the inside and reading outward, the read/write head can jump directly to the spot where the desired data is stored. There is actually a second type of memory used in personal computers, in addition to RAM. This second type of memory is named read-only memory, or ROM. Unlike RAM chips, ROM chips have software permanently etched into their circuitry. For this reason, ROM is often referred to as firmware-because it's kind of halfway between hardware and software.
Both RAM and ROM allow random access. To distinguish RAM from ROM, RAM is called read/write memory, meaning that you can both retrieve (read) information from RAM, and record (write) information to it. Read-only memory (ROM), instructions are frozen into the circuitry. The feature that sets RAM apart from ROM is its changeability: the fact that you can alter the contents of RAM at will. The other difference between RAM and ROM is how long their memories last. RAM is short-term memory; it forgets everything it knows as soon as you turn off your computer. ROM is long-term memory; it remembers everything it has ever known as long as it lives.
In personal computers, ROM is generally used to store some part of the operating system. Only a small part of the operating system is stored in ROM. Just enough to get the hardware up and running and to tell the CPU how to locate and load the rest of the operating system from disk.
Now, I don't know how the Game itself got the Term ROM, but that is an incorrect term for even that, since it is permanent Memory (if ROM were a correct term for the Game, I wouldn't be able to edit the Game in a Hex Editor now would I)
Maybe the person who came up with that, was refering to the actuall Game Cart, and forgot to distinguish a difference between the two (the Game on a Hard Drive, and the Game on the Cart,... the Game Cart can only be written to once, right?,... that's what I remember seeing somewhere)
Alastor the Stylish
Posts: 4823/7620 |
Eh. I wouldn't really call saves RAM, as RAM is erased when there's no power to it, which is obviously not true of battery saves. He's still wrong about it being ROM though, because ROM can't be rewritten, that being why it's called read only memory. |
Parasyte
Posts: 245/514 |
"Perform" is not a very fitting term. Neither are "handle" or "interpret", but if that gets the idea across...
And NO! Save files are not ROM at all. They should not be considered ROM in any way or form. It is RAM, and that is all there is to it. |
Atma X
Posts: 703/801 |
I know that saves are not ROM, but the Save files that get produced is a seperate file,... (AKA a File stored into your Hard Drive).
The Data inside of SRAM is recorded to a seperate file, so it can be accessed at a later time (so you don't lose your place in the game when you turn the Power Off, etc.)
That's what I was talking about by that.
About the statement "RAM is where EVERYTHING is Run (Manipulated etc., you get the idea)."
Yea, I worded that wrong. I was meaning to say that Data and Instructions is loaded from ROM, and is Processed in RAM.
And Btw, doesn't Execute mean to Perform (to Perform the Instructions loaded from ROM). Maybe one of us has some terms wrong (I don't know,... if I'm wrong, then I'm just using the wrong word to describe what I'm thinking).
So, I don't see how an instruction can be Performed from ROM (Executed from ROM as you stated). The way I see it is that Instructions can be Loaded from ROM into RAM, and then Performed in RAM (the task of the Instruction is carried out within RAM) |
Parasyte
Posts: 244/514 |
To be technical, "script" is not the proper term for assembly. It is, in fact, "assembly". The assembled instructions are called "machine code" because they are just numbers. So machine code = numbers that a CPU uses as instructions. Assembly = the human-readable form of that machine code.
There are a few non-minor errors that I noticed in your explanation:
" ... you cannot Alter, Process, or Manipulate data in ROM (as far as Writing/Overwriting Data goes, there is an exception; for example, your save files can be created while the Game is being run)."
Saves are NOT ROM. It is SRAM (Save RAM). It is definitely RAM in that you are able to read or write to it at will. The difference from SNES main system RAM is that it actually saves (it is backed up by a battery - the battery keeps the data in RAM without resetting).
"RAM is where EVERYTHING is Run (Manipulated etc., you get the idea)."
This statement is confusing. I'm not certain if you meant to say that RAM is where instructions are executed (run), but that is how it seems. And in that case, it is incorrect. Almost all instructions are executed from ROM. To get any instructions executed from RAM, the program must first copy those instructions to RAM (either a simple data transfer, or decrypt/decompress code, but that is beyond the scope of this explanation). Once the instructions are all in RAM, the program may then branch or jump into that routine. This method of running code is very rare on SNES. |
Atma X
Posts: 702/801 |
And if you want to write a Routine (later on) that requires you to work with Data formats, just be aware that a lot of the Formats that the Snes uses can be mind boggling at times (I find the Genesis' Data Formats to be much eaiser to work with). You could also write your own Data Formats, but I wouldn't try that for a while (you can think up some Formats in your head, but you won't be able to program it yet).
Note: A Routine is just a bunch of Instructions used to perform a Task.
Programming just requires that you understand a concept, and think about the operations that you want the game/computer to perform in a logical manner.
For example, well partially: You can't just make a Sprite walk left or right with simply one Instruction. In other words, there is no move left or right Instruction, you instead have to use a few or several Instructions to increase or decrease the value on the Bytes(s) that holds the Sprites X location (few Instructions in this case). Thinking Logically about writing your Instructions just means that your thinking about a logical way (a way that that you are 99% sure that makes sense) that you can accomplish your task; some of which requires that you know some things about how the Instructions shoud be used, and also other things, for example: What is an Instruction; think about that stuff like that as well, it'll help you to understand more things along the way (what does an Instruction really mean; Answer: Steps to perform a Task. Use of Instructions: To inform someone/something of the steps required to perform a task,... AKA, to use Instructions to describe how something is to be done).
There's something else you should understand as well, which is the difference between RAM, and ROM.
ROM (Read Only Memory)---Read only, as in you can only Read memory, not Process, Alter, Manipulate the memory/data/information.
RAM (Random Access Memory) It can Randomly/Freely access, process, alter Memory/Data/Information with the proper Instructions (with an Instruction that would Instruct it do something like that; Processing certain data etc.)
While a program is being run (the game in this case) you can only Read memory from ROM (The ROM file itself, same story with computer's Hard Drive, AKA, a place where Data can be permanently stored), you cannot Alter, Process, or Manipulate data in ROM (as far as Writing/Overwriting Data goes, there is an exception; for example, your save files can be created while the Game is being run). Processing, Altering, and Manipulating can only be done in RAM (your RAM chip(s) in your computer is where this is done,... and the Snes Console itself has it's own RAM chip,... but think of it as RAM Addresses when loading Istructions or Data into to RAM).
Here's an Example that may help as well:
As far as Processing, Manipulating, Altering Data/Information and Reading Data goes, It's like a Book and your Mind: A Book stores information, (or information in the form of instructions AKA, a Cook Book gives you instructions on how to make a certain type of food,... though those instructions would be too breif for a computer, but that's beside the point), and that info gets loaded into your Mind when you read the Book, and then from there, you can use your Mind to Alter, Manipulate, or Process that information, and then you can Write something back to the pages of the Book to keep a Record of what you just read (maybe with some ateration(s), if you desire), or anything that you thought of at that time,... but the Book itself cannot Manipulate, Alter, or Process the information contained in itself, because it is just a Record of Data/Information, not a Processor and Manipulator of Data/Information like your Mind.
Final notes:
RAM is temporary memory (it gets reset everytime you reboot your computer, or for the Snes Consol,... everytime you turn the Systen Off, and back On).
Also, to understand programming (any language), you just need to understand "Programming Logic", and then learn the different Instructions for each language (included Instruciotns in a language generally are they same types, just some minor differences, and with some more Instructions added to some languages compared to another,... and also the Hex/compiled or Script/uncompiled representations of the Instructions)
Well, hope this helps you in your journey to become a Programmer. 
(If I made a mistake anywhere, someone please correct me,... mistakes can happen,... I also read over this, but not enough times for all of the sections, because I'm pretty tired now)
Edit: Btw, Tracers, Assemlers, Disassemblers, Compilers, etc. are just tools to use while Programming, they do not help you write a program (Hex Editor, or Notepad etc. let you write the Program). Compilers, Disassemblers etc. only convert the Script representations of an Instruction to and from their Hex Values (not a Tracer though, don't confuse that one with the others).
Here's an Example below:
2 Notes before reading the Example:
1. JMP means: (An Instrusction to Jump to the Address you specify in the 4 Bytes after the JMP Instruction is writen,... AKA, JMP is used to continue reading code from the specified Address),... (writen by you of course,... so that means it's done in ROM).
2. Example refers to the Genesis' Hex representation of the JMP Instruction, not the Snes' Hex representation of the JMP Instruction.
Ok, here's the Example: In a Script, the Jump instruction is JMP (it consume 3 Characters/Bytes in Script form), in Hex, Jump is 4EF9 (2 Characters/Bytes).
All a Compiler does is convert JMP, to 4EF9.
The only things I use are Tracers (to find Routines of Code/Instructions), and Hex Editors (that's all you need). |
HabsoluteFate
Posts: 96/179 |
Originally posted by BrooklynMario
So, out of this page at zophars http://www.zophar.net/tech/transdocs.html
what files should i look at? I know one of them being 65816 Primer. What else?
I would read the primer and try and find examples or tutorials somewhere on the net....looking at decompiled blocks (From the Block Tool) is also helpfull especially because the code for each block isnt that long and should be more easily understood....perhaps even creating your own block with it's own properties would be a good way to at least get something that works... |
BrooklynMario
Posts: 53/110 |
So, out of this page at zophars http://www.zophar.net/tech/transdocs.html
what files should i look at? I know one of them being 65816 Primer. What else? |
| This is a long thread. Click here to view it. | | |
|
labmaster
