don't click here

68000 Highlighter for ConTEXT

Discussion in 'Engineering & Reverse Engineering' started by Ambil, Sep 9, 2005.

Thread Status:
Not open for further replies.
  1. Ambil

    Ambil

    I want that heinous hedgehog hammered! Member
    893
    0
    0
    Spain
    Last evening I was looking the technical stuff at SMS Power, and found a beginners Z80 programminmg tutorial. In the recommended downloads, I grabbed a good text editor called ConTEXT (freeware), with some very nice features for programming -- much better than MS Notepad of course!

    Maxim, one of the main developers in SMS power (visit his website) had programmed a highlighter to visually make easier the programming in Z80 assembly. So this game me an idea, why not make one for our Motorola 68000? This morning I finished my work. Grab the file and place it in the "Highlighters" folder at the ConTEXT program files directory.

    MOTOROLA 68000 ASSEMBLY HIGHLIGHTER FOR CONTEXT (8 KB) -- Right click, Save as --

    Open a split disassembly in ConTEXT and see how the program finds the keywords and gives them a format. If there were any documentation along with the Snasm68k assembler, I would nicely merge its instructions into the highlighter.

    Credit goes to Maxim, for giving me the idea.
     
  2. Quickman

    Quickman

    be attitude for gains Tech Member
    5,596
    18
    18
    :x
    omg porjcet
  3. Aurochs

    Aurochs

    Единый, могучий Советский Союз! Tech Member
    2,343
    0
    0
    Whatever catches my fancy
    Yeah, about that... I'm not updating it anymore. I'm moving on to AS, and I encourage everybody else to do the same. For one thing, it comes with very good documentation.

    And at any rate, it doesn't have anything about assembler directives - just the command line.
     
  4. Quickman

    Quickman

    be attitude for gains Tech Member
    5,596
    18
    18
    :x
    omg porjcet
    Why are you moving onto AS when it's not even the AS which IDA Pro wants you to use? SNASM68K is still better in that respect since it doesn't need you to screw around with the disassembly as much as your AS. (You yourself said certain forms are not accepted by AS which are accepted by SNASM68K.)
     
  5. Aurochs

    Aurochs

    Единый, могучий Советский Союз! Tech Member
    2,343
    0
    0
    Whatever catches my fancy
    1. Better documentation.
    2. It can handle LFNs in included files.
    3. The listing format is far more readable, and it actually puts a symbol table at the end.
    4. It's faster than SNASM68K.
    5. You can assemble Z80 code with it.
    6. Those unacceptable code formats are in bad form, anyway, and the "too many arguments" errors are caused by COMBINE.EXE.
    EDIT: By the way, I use gvim. It already had syntax hilighting for 68000 ASM. So =P
     
  6. LocalH

    LocalH

    roxoring your soxors Tech Member
    3,303
    26
    28
    wouldn't you like to know
    Guitar Hero II Deluxe
    I wouldn't imagine it would be too hard to write a program that would crawl through the file and automate 'fixes' that are required for using AS instead of SNASM.

    I'll probably be sticking with SNASM for now, for my future democoding projects. Although there is a small project I found called "68000 Editor, Assembler, and Simulator" that I'm playing around with (obviously, the simulator is useless, but the assembler might be good).
     
  7. Aurochs

    Aurochs

    Единый, могучий Советский Союз! Tech Member
    2,343
    0
    0
    Whatever catches my fancy
    Or, the next version of the S2 disassembly will have all the "fixes" applied already. It should be released rather soon.

    I'll probably have to use a macro to simulate CNOP though. Is it really necessary to have all that filler space?
     
  8. LocalH

    LocalH

    roxoring your soxors Tech Member
    3,303
    26
    28
    wouldn't you like to know
    Guitar Hero II Deluxe
    Well, I'm talking in general, with all existing SNASM sources.
     
  9. Quickman

    Quickman

    be attitude for gains Tech Member
    5,596
    18
    18
    :x
    omg porjcet
    In the case of the sound driver, emphatically yes. The banks need to be aligned correctly for the pointers to work. If you feel like wrestling with your precious assembler to decompress and split up the music so you can put it where you like then be my guest.
     
  10. LocalH

    LocalH

    roxoring your soxors Tech Member
    3,303
    26
    28
    wouldn't you like to know
    Guitar Hero II Deluxe
    Any Z80 music driver that uses ROM will require it to be aligned on 32KB boundaries, since that's the size of the Z80's ROM window. Code and data that is injected into Z80 RAM by the 68K does not have this limitation. You can move blocks of data around inside each 32KB as you wish, but if a particular combination of data doesn't fit then you'll have to shift things around so that each Z80 ROM bank contains only full blocks of data, and that none overflow into the next 32KB.

    Or, if the code only uses one 32KB bank, then you can place it anywhere as long as it's aligned on a 32KB boundary, and you can do whatever you want inside that bank as long as it stays 32KB or less.
     
  11. Aurochs

    Aurochs

    Единый, могучий Советский Союз! Tech Member
    2,343
    0
    0
    Whatever catches my fancy
    Right after the sound drive, we find <tt>cnop -$2F00,$8000</tt>. Similary, before the Sega PCM, we find <tt>cnop -$6174,$8000</tt>. I don't see how $5100 or $1E8C line up to multiples of $32000. So what's up with that?
     
  12. LocalH

    LocalH

    roxoring your soxors Tech Member
    3,303
    26
    28
    wouldn't you like to know
    Guitar Hero II Deluxe
    First of all, 32KB is $8000. Second of all, that's probably just the amount of filler necessary to get to a 32K boundary. If there are $5100 bytes of room left to get to a boundary, then that's all you'd pad it by.
     
  13. Aurochs

    Aurochs

    Единый, могучий Советский Союз! Tech Member
    2,343
    0
    0
    Whatever catches my fancy
    Oops. Heh heh. That's embarassing.

    CNOP <offset>,<boundry> sets the assembler's program counter to <offset> after the next multiple of <boundry>. All you'd really need to do what you're talking about is CNOP 0,$8000.
     
  14. Aurochs

    Aurochs

    Единый, могучий Советский Союз! Tech Member
    2,343
    0
    0
    Whatever catches my fancy
    NOW I get it. The SEGA PCM is exactly $6174 long. The END of the sound should line up with the next $8000 boundry. The same is true of DAC samples, which have a total size of $2F00.

    So, my problem is really how to get the end of data to line up on a boundry.

    EDIT: This is a rather short-sighted method of doing this. What if somebody wants to edit the DAC samples? And is it really necessary to line up this data to the end of a $8000 boundry?
     
  15. Quickman

    Quickman

    be attitude for gains Tech Member
    5,596
    18
    18
    :x
    omg porjcet
    At the time the disassemblies were made the sound driver was not as extensively examined.
     
  16. Aurochs

    Aurochs

    Единый, могучий Советский Союз! Tech Member
    2,343
    0
    0
    Whatever catches my fancy
    Well, I'm going to use org to emulate cnop. It doesn't work unless the DACs/PCM are/is in precicely the same spot that they were in the original ROM, anyway. If I find a disassembly of the sound driver, I'll figure out a way to integrate it into the game's disassembly somehow so that this isn't really a problem.
     
Thread Status:
Not open for further replies.