Visual Sega Genesis Assembler/Disassembler

[walker7]

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.

[MintyTheCat]

Hi Walker,

what you are describing can be achieved using:

GDB / DDD
VIM

Including Symbols in ( -g ) built C programs using GCC or the equivalent in Assembly (use the Listing) can get you that type of functionality.

However, you can patch the Work RAM directly say using UMDK but not the CRAM, VRAM or VSRAM.

However, I have a Command-Monitor that allows me to dump and set CRAM, VRAM, VSRAM and WRAM that operates over RS232. It allows a Developer to try things out, enter commands, see the changes, etc.

DDD is visual but there is no way to add in code to manipulate the CRAM directly from a debug-session but it is possible already to accomplish this.

Me and Prophet36 ( UMDK Inventor) had discussed having some kind of visual VDP Debugger added onto UMDK that would help Developers debug the VDP but can anyone program GUI Applications? Having a Socket hooked up between the debug session, UMDK and the VDP Debugger would be possible.

[sega16]

I can program GUI applications that are cross platform you can see an example of my work here viewtopic.php?t=1392
I do not think programming a GUI application is any more challenging that any other type of programming. I use fltk which is very easy to use. If you can program, you could make a GUI application.

[walker7]

Wanna see what section banners would look like?

Here's a banner using a normal text font:

This banner uses Arial font, and 24-bit RGB color #FF0000.

And here's what a section using a custom font might look like:

This banner uses the Sonic 2 title card font. In this banner, I made the "#", "1", and ":" characters myself. It uses Sega Genesis color format, with the color $000E. Also, this banner is a little thinner than the first one. You could control how thin or thick, in pixels, you want the banners to be.

The names of sections, font, colors, and thickness could be edited at any time if you want.

[MintyTheCat]

I can program GUI applications that are cross platform you can see an example of my work here viewtopic.php?t=1392
I do not think programming a GUI application is any more challenging that any other type of programming. I use fltk which is very easy to use. If you can program, you could make a GUI application.

Hehehe. This might sound a bit odd to you but I simply find GUI programming to be all a bit too fiddly. I tend to find that one has to conform a lot more when partaking in that type of programming. I shall have to stick to Embedded I'm afraid. I can program Command-Line Programs too but that is strictly as high as I ever personally want to go.

If you fancy doing some GUI work for us we need a Level-Editor for our MD Game project if you fancy it.

How does FLTK compare to QT and wxWidgets?

Cheers.

[sega16]

Well FLTK is more lightweight and I think easier to use. I have not bothered with wxWidgets or QT as FLTK has been good enough for me. I am not saying that I am incapable of using them I just have not had a use for them yet. The only disadvantage to FLKT is that it does it's own drawing instead of using the systems native GUI drawing functions so it may look a bit different than what you would find on the system. I was going to add level editing anyways to Retro Graphics Toolkit at some point in time. I though you were trying to make a VDP debugger as you mentioned earlier. I also enjoy embedded programming and have wrote command line tools myself but I am not sure what you mean by "conform". As for GUI programming being too "fiddly" I avoid that by mathematically calculating where I want to put buttons and such. It usually turns out good enough for me.

[MintyTheCat]

Well FLTK is more lightweight and I think easier to use. I have not bothered with wxWidgets or QT as FLTK has been good enough for me. I am not saying that I am incapable of using them I just have not had a use for them yet. The only disadvantage to FLKT is that it does it's own drawing instead of using the systems native GUI drawing functions so it may look a bit different than what you would find on the system. I was going to add level editing anyways to Retro Graphics Toolkit at some point in time. I though you were trying to make a VDP debugger as you mentioned earlier. I also enjoy embedded programming and have wrote command line tools myself but I am not sure what you mean by "conform". As for GUI programming being too "fiddly" I avoid that by mathematically calculating where I want to put buttons and such. It usually turns out good enough for me.

Ok, from what I understand QT and wxWidgets tends to use the system look and QT is fairly portable at the application level but that's not really a big issue for us.

I find that Level-Editors are at the very least genre specific such as platform, RPG , etc due to the way that a level is structured and the type of data that a level requires.

Yes, me and Prophet36 had discussed this VDP Debugger; the Level-Editor is a completely seperate topic.

Good to hear.

Yes, fiddly in the sense that one has to learn the way that each GUI framework functions and then apply the method - I find it to be too fiddly and if I am honest I find no joy what so ever in messing around with forms, buttons and such; it simply bores me to tears. I'd never get my 'math kick' by calculating button placement locations

I think as high as I like to go would be SDL.

I suppose Software-Engineering takes all sorts of backgrounds and interests and perhaps one day I will change my ideas about GUI development but for now it repels me

[neologix]

I've had some success using the phoenix GUI toolkit wrapper by byuu, the author of bsnes/higan. It uses one API and essentially ifdefs to the native GUI toolkit of the current OS (supports Win32, OS X Cocoa, GTK, Qt). byuu himself runs FreeBSD 10 and expands from there, so you know that it'll work on essentially every *nix without special dependencies.

I'm unfortunately not experienced at all in emulation-related programming, so I can't help here :/

[MintyTheCat]

I've had some success using the phoenix GUI toolkit wrapper by byuu, the author of bsnes/higan. It uses one API and essentially ifdefs to the native GUI toolkit of the current OS (supports Win32, OS X Cocoa, GTK, Qt). byuu himself runs FreeBSD 10 and expands from there, so you know that it'll work on essentially every *nix without special dependencies.

I'm unfortunately not experienced at all in emulation-related programming, so I can't help here :/

Hi,

well, actually it is a simple queue of VDP actions that can be picked up from a UMDK Trace-Log to reconstruct what occurred or could feed into the queue of the VDP Debugger as action that involves the VDP occurs. You could get away with it as a Command-Line program but it would be fairly simple to put together a front-end GUI for it to make it easier to use on the Desktop.

I haven't actually delved any deeper in to this as yet but it is on the cards so to speak if you fancy lends your GUI skills to UMDK.

Cheers.