Visual Sega Genesis Assembler/Disassembler
Posted: Sat Aug 23, 2014 7:55 pm
Wouldn't it be interesting if there was a visual Sega Genesis assembler? Of course, it would support all Motorola 68000 opcodes and directives. Macros can also be used.
What would make it better are many things:
The code can be split up into sections. Sections use code-folding. You can fold an entire section at once, or all sections at once. Sometimes, focusing on only one section of code is a good idea when programming.
Subroutines and other data sets can also be folded.
Each section would have a banner, describing that section's main purpose (example: "Section #1: VBlank Routines"). You would choose the font and color for the banner. Although the font would remain the same for each section's banner, you can choose different a color (using the Sega Genesis' $0BGR, or 24-bit RGB) for each section's banner. For fonts, you could use a font from your computer, or make your own font using 8*8 tiles or bigger (example: Sonic 2's title card font, which is called Roco).
Colors can be entered in the normal 0BGR format. But, they can also be entered using a grid. Full 64-color palettes wold use a 16*4 grid, with columns labeled $0-$F and rows labeled $0-$3. Each cell displays the appropriate color chosen. Sometimes, you want to store less than 64 colors. These colors will appear as squares in a grid (you choose the dimensions). You could have the colors displayed using the grid, or a set of dc.w directives.
Graphics can also be entered visually. Graphics could appear as a panel with grid, a 16-color palette above it, and any compression options. It gets better: You can also compress graphics using a simple command. Also, you can rearrange and change colors in the palette. Graphics can be displayed as the actual tiles or the corresponding bytes. You could also make your own compression/decompression libraries.
Graphics can also be imported from your computer (.bmp, .gif,. png, etc.), or Paint Shop Pro.
Plane mappings are also listed in a grid. You could copy or mirror parts of the grid if you want. Plane mappings can be displayed as a grid with the actual tiles, or dc.w directives.
Commenting could be easy. Any time you press ";", it will automatically tab over to the right to create a comment section.
For local labels, they would be defined as a period with the local label name after it. You could choose to rearrange local labels in alphabetical order, or numerical order if you want.
There's also register rearranging. For any piece of code, you could choose how to rearrange the registers, so that different registers perform the same function. MOVEM opcodes will have their registers changed accordingly.
Functions and other subroutines could have a description box after the label. It tells what the subroutine does, as well as input and output registers.
There's also "coding as you go." You enter code, but also see the results of that code in registers and memory as you enter. This makes it easy to spot mistakes. This entering mode can be toggled on and off.
The $200-byte header can be entered into a panel using text boxes, check-boxes, and radio buttons.
For each file, you could make the background color anything you want. You can use different colors. Also, images can be used.
The text font could be fixed-width, like Courier New or Fixedsys. You could even come up with your own font if you want.
You could also use graphics to represent data. For example, in music data, you could have a graphic reading "C" to represent the byte value that corresponds to the note C. How about a quarter note symbol to represent a byte that stands for a quarter note? Graphics can be overlaid on top of one another or combined in some way to create more possibilities. You could assign values to images in order (starting at a certain value), or define a C++-style expression that tells what image corresponds to what value.
Plus, you could get the size, in bytes, of any section, subroutine, data group, etc. of the ROM.
There are many other possibilities for a visual Sega Genesis disassembler.
What would make it better are many things:
The code can be split up into sections. Sections use code-folding. You can fold an entire section at once, or all sections at once. Sometimes, focusing on only one section of code is a good idea when programming.
Subroutines and other data sets can also be folded.
Each section would have a banner, describing that section's main purpose (example: "Section #1: VBlank Routines"). You would choose the font and color for the banner. Although the font would remain the same for each section's banner, you can choose different a color (using the Sega Genesis' $0BGR, or 24-bit RGB) for each section's banner. For fonts, you could use a font from your computer, or make your own font using 8*8 tiles or bigger (example: Sonic 2's title card font, which is called Roco).
Colors can be entered in the normal 0BGR format. But, they can also be entered using a grid. Full 64-color palettes wold use a 16*4 grid, with columns labeled $0-$F and rows labeled $0-$3. Each cell displays the appropriate color chosen. Sometimes, you want to store less than 64 colors. These colors will appear as squares in a grid (you choose the dimensions). You could have the colors displayed using the grid, or a set of dc.w directives.
Graphics can also be entered visually. Graphics could appear as a panel with grid, a 16-color palette above it, and any compression options. It gets better: You can also compress graphics using a simple command. Also, you can rearrange and change colors in the palette. Graphics can be displayed as the actual tiles or the corresponding bytes. You could also make your own compression/decompression libraries.
Graphics can also be imported from your computer (.bmp, .gif,. png, etc.), or Paint Shop Pro.
Plane mappings are also listed in a grid. You could copy or mirror parts of the grid if you want. Plane mappings can be displayed as a grid with the actual tiles, or dc.w directives.
Commenting could be easy. Any time you press ";", it will automatically tab over to the right to create a comment section.
For local labels, they would be defined as a period with the local label name after it. You could choose to rearrange local labels in alphabetical order, or numerical order if you want.
There's also register rearranging. For any piece of code, you could choose how to rearrange the registers, so that different registers perform the same function. MOVEM opcodes will have their registers changed accordingly.
Functions and other subroutines could have a description box after the label. It tells what the subroutine does, as well as input and output registers.
There's also "coding as you go." You enter code, but also see the results of that code in registers and memory as you enter. This makes it easy to spot mistakes. This entering mode can be toggled on and off.
The $200-byte header can be entered into a panel using text boxes, check-boxes, and radio buttons.
For each file, you could make the background color anything you want. You can use different colors. Also, images can be used.
The text font could be fixed-width, like Courier New or Fixedsys. You could even come up with your own font if you want.
You could also use graphics to represent data. For example, in music data, you could have a graphic reading "C" to represent the byte value that corresponds to the note C. How about a quarter note symbol to represent a byte that stands for a quarter note? Graphics can be overlaid on top of one another or combined in some way to create more possibilities. You could assign values to images in order (starting at a certain value), or define a C++-style expression that tells what image corresponds to what value.
Plus, you could get the size, in bytes, of any section, subroutine, data group, etc. of the ROM.
There are many other possibilities for a visual Sega Genesis disassembler.