|
|
ForumsSega Master System / Mark III / Game GearSG-1000 / SC-3000 / SF-7000 / OMV |
Home - Forums - Games - Scans - Maps - Cheats - Credits Music - Videos - Development - Hacks - Translations - Homebrew |
View topic - Y2Koders and Development Tools
 |
| Author | Message |
|---|---|
|
 Y2Koders and Development Tools
 Posted: Wed Feb 28, 2001 10:13 pm
|
|
O.k. all you Y2Koders out there (all three of you :-)) I'd like your expert opinions on a few things.
If you were going to do your development testing and debugging work on an emulator with built-in debug features, what kind of features would be most useful, based on your experience coding for the Y2Kode competition? Here's some examples, how useful would these have been to your work for Y2Kode: Single-stepping CPU/VDP register editing CPU/VDP memory editing CPU/VDP memory protection (for example, did you ever wish that the system could warn you that a write was attempted to ROM space?) I/O port protection Breakpoints (register read/write, memory read/write/execute, port in/out, vblank, hblank, specific scanline) Watch windows (what would you have liked to watch?) Self-interrupt generation (programmatic interrupt generation) Paging protection Performance monitoring (counting page swaps, cycle counting) Would you have used features allowing you to put "debug code" into your program that sent messages to a separate text (ascii) display window? What about to a log file? Any feedback you'd like to give me would be appreciated. Thank you. -- Eric Quinn Obviously, you have all gotten well past the point of simply displaying a tile on the screen or moving a sprite around with the joypad. |
|
  
|
|
|
Posted: Wed Feb 28, 2001 10:15 pm
|
Please disregard the above comment in the previous post (after my signature). It was from an older draft of that message. -- Eric Quinn |
|
|
|
|
|
Posted: Wed Feb 28, 2001 11:18 pm
|
|
|
|
|
|
|
Immitation is the sincerest form of flattery
Posted: Wed Feb 28, 2001 11:25 pm
|
|
But this time I'll write my own text.
I will respond to this in greater detail soon, as well as addressing SDSC. I do have some ideas to share on the matter. But, first, a short break from SMS development... |
|
|
|
|
|
PolestaR
|
Posted: Thu Mar 01, 2001 2:22 am
|
|
Not really debugging related but its still Sms development ;). I would like to see a windows based paint program which allows me to select two 16 color palettes from a 64 colors palette range and then can store the picture in 8x8 tiled bitplane format. That would be pretty handy :)
-Jason Starr- |
|
|
Posted: Thu Mar 01, 2001 4:05 pm
|
 Must have... Extremely nice, almost a must have. Can't think of a real need. Very nice. Make it so things that don't work on the actual hardware don't work on the emulator. Nice to have, not absolutely necessary. Code breakpoints are a must have. Make it so the code can be 'browsed' through, and set breakpoints similar to Visual C++ or VGBC. Nice. Specify an address, VDP register, or CPU register. Not really needed. Very nice. Oh yes! :) A log file of VDP register settings or 'violated' protections would be great. Make it easy to single-step and set breakpoints. Allow the debugger to be started prior to the rom starting. My favorite debugger is the MAME debugger. This would be a wonderful interface. |
|
|
|
|
|
Posted: Thu Mar 01, 2001 5:00 pm
|
The current plan includes an "unassembly" window that includes all of memory and can be scrolled through (forwards and backwards) at will. Furthermore, the window "remembers" the true start of instructions, so scrolling backwards is still possible while maintaining the correct instruction unassembly. Is this what you mean by "browsing" or was there more to it?
I'm afraid I'm not familiar with the MAME debugger (or MAME at all for that matter). Presently, I'm hesitant to try to download and compile MAME myself. I'm hoping you can elaborate a little on what specifically you like about it. Thanks for the feedback Charles. I believe you've given me some suggestions in the past too; I haven't forgotten them. -- Eric Quinn |
|
|
|
|
|
that reply I was promising:
Posted: Thu Mar 01, 2001 8:59 pm
|
Be warned, this one is LONG.
Absolutely necessary. Handy, not vital, but I'd use it.
Yes indeed! That would be a great way to detect pointer problems. That and maybe a few more checks, like being able to set a ram address that the stack pointer should never go past, and issuing you a warning if it does (but then, I use the stack pointer to process a list of callbacks during vblank... hehehe.) Code breakpoints is a must have, as Charles said. The others sound useful, particularly the memory watch points. Yes (More below) Hmm, sounds like KTy's sort of thing. How would that work? Useful, I'd make it a lower priority but a good idea. Useful, although I tend to use breakpoints for these kinds of things.... I guess there are some things I'd like to monitor over time that I don't necessarily want to be notified about. Okay, here's what the (More Below) refers to: Since having.. outgrown TASM I've move to the always evolving WLA-DX assembler by Ville Helin. It's relatively new, and has been designed from the ground up to be useful for coding on consoles (originally the GB but its grown to support multiple CPUs), with special attention to paging (which I haven't really tapped into yet but it's getting there). Unlike TASM, which only generates direct object code from a single input file (you have to link a bunch of files together with include to break it up into multiple files), WLA compiles to individual object files which can be linked together with the associates wlalink. You can compile libraries and link them into other projects as well, export definitions, do calculations with external symbols (which are resolved by the link)... One thing is does is generate, on request, a symbol file. The symbol file is a list of all the symbols (i.e. address labels) you've used, and their address and page number. This information is importable directly into WLA-DX author's own Gameboy emulator, and I think it would be just as handy in a SMS/GG (AGAMA as you call it) emulator/debugger. Here is an example of a WLA Symbol file. It's from my sound test program. Normally it would have a .sym extension but I renamed it to .txt so everyone's browser would know what to do with it (i hope). Note that the structure is pretty simple. Each line begins with the page/address field: nnnn:aaaa (where nnnn is page information (all zeroes in my case), and aaaa is the address (relative the to the page)) followed by the name of the label. They're listed in address order. For instance: 0000:0050 WaitVBlank 0000:0055 _Loop Names starting with _ are local labels. There can be duplication in _ labels because they're resolved according to what section they're in. We can assume _Loop to be relative to WaitVBlank. We'll ignore the local labels for now, and consider the benefit of importing labels in general. First of all, in your dissassembly, each address that gets shown can be checked against the symbol table, and if there's a match the label name can be shown in front of the actual opcodes. While debugging you can see all the address labels as if you were looking at your source code. It's much easier to keep from being disoriented. But, better yet, imagine being able to set breakpoints by browsing through a tree view of sections, labels, and local labels. Right now to set a breakpoint I have to open up the .sym file, scroll up and down the ever growing list (my Y2Kode entry has about 400 labels. I think). find it, remember it long enough to run BRSMS in debug mode and type it in. If I need to switch new breakpoints a lot I have to keep switch back and forth between brsms and the ever growing list of labels. And I can only set one breakpoint at a time. Now, the symbol file format doesn't contain quite all the features I'd like to, but the beauty about picking WLA as the assembler of choice is that Ville Helin seems quite open to feature suggestions and letting you add new features yourself, since he distributes the source code (it's not exactly 'open source' but you can download it, add a new feature, and submit it back to him and he'll probably incorporate it in the new version if your changes are clean and don't interfere with the rest of the program). This would be a good matter for the SDSC to discuss, just what information the MesaDX (or whichever emulator uses it) symbol file should have and how to format it. I think it should have the following information, in a format more or less like this one: [main label section] pppp:aaaa label section objectfile ... [variable addresses] variablename aaaa ... [breakpoints] pppp:aaaa where: pppp = paging information (bank and slot, I need to check into how this is formatted in WLA right now) aaaa = 16 bit address label = full name of label (including the _ in local labels) section = name of the section of origin (in a later post, like a 'how to use WLA' introduction for all here who are curious, I'll explain what a section is, exactly) objectfile = The object file name (or library file name) the label originates from. variablename = the name of a define used as a variable address (these would always be in the system ram anyway so I specify it as a 16-bit address). and the bit about breakpoints is a feature that doesn't exist in WLA but I'll propose it to Ville Helin and see if he doesn't mind adding it (and if it's feasible); You could tag any line in your source code with a ! at the front (or some other symbol) and its address will be placed in the breakpoint section.. a compliant emulator would have the option of autmatically setting all the address in that field as breakpoints. This mimics the behavior of many IDE's with debuggers. The variable names are usually done with .define directive, (which is much different than the .define from TASM, it's really just for numerical or string substitution. WLA has seperate MACRO support), i.e.: .define FirstVariable $c000 or done with .enum, which is an autodefiner: .enum $c000 FirstVariable DB FirstPointer DW SecondVariable DB (...) .ENDE which has the effect of assigning the value $c000 to FirstVariable, $c003 to SecondVariable, and $c001 to FirstPointer. This could be used in memory watch pointers, and to a limit extent, maybe substitution in disassembly view (should be okay for things like ld a,($c000), though it's could be ambiguous in other situations like ld hl,$c000 .. maybe I just want to load h with $c0 and l with 0, and it has nothing to do with a variable) But as it stands, the debug info in the current version of the symbol file could be of considerable use. WLA is moving towards a new release, which will greatly improve macro performance. When it's at a comfortable release spot I'll compile the z80 version for a couple platforms (pure dos and win32 probably -unix people should have no problem compiling their own) and submit them here for the tools section. Speaking of the tool section, I notice the dz80 disassembler is attributed to Nico Mak computing.. Nico Mak makes WinZip, and probably some commandline unzip utility before that, so I think someone got a little mixed up when they unzipped that file. Another thought I had about the development of MesaDX is that you might want to look into the possibility of supporting plugins (as DLL's). My first notion is that each plug in would establish and update its own window (if need be), register itself in the list of available plug ins to be switched on and off, and request to be notified on various types of events. There would be a variety of functions available to the plug in that expose all the features of the SMS and allow reading from them and modifying them (such as RAM, VRAM, rom, all VDP registers, sound registers, elapsed cycles, and more). A plugin which lets you view the contents of the tiles (like in Meka) would request to be notified when data is written the VDP so it could update its bitmap. A full single-stepping debugger plug in would probably want to be notified for every CPU instruction, and maybe a special event that the other plugs can generate to put it into single-step mode. There should probably something in place that only allows one debugger plugin loaded at a time. Then again we could just figure that anyone loading two together deserves what they get. A memory write watch window would want to be notified on memory writes. If the watch plugin were set to break when a particular location or range was written to then it need only set the call the function that generates an event to place the debugger in single step mode. Plug ins could also be used to simulate new on-cart hardware, like a countdown timer that KTy might be wiring onto a cartridge right now (or a PIC simulator, if he dares to write one). Or a weird mapper, etc. Then you could develop MesaDX a plug in friendly emulator with the debugger as a seperate DLL (or build it into the emulator if you prefer, as a default). And we can write new plug ins for features that we want and you don't have to do all the work or listen to us nit-pick about the details. Sucks for the unix users, though.
"WOW! FASTEST SHIPPER, GREAT COMMUNICATION! TOP SELLER! A+++++" |
|
|
|
|
|
Re: that reply I was promising:
Posted: Thu Mar 01, 2001 9:58 pm
|
The stack pointer range idea is good. I'll have to figure out how to incorporate that.
Preventing certain pages from being mapped (mostly range checking on values written to the PFRs).
You've got me interested. I'm going to check it out. Where can I find it? Maybe you or I (or both) could develop some documentation for WLA-DX for SDSC.
AGAMA is actually an SMS (or GG) with built-in debug features. I'll tip my hat just a little here and give you an example: With AGAMA extensions turned on in MesaDX special AGAMA code (debug code) in the program can write to AGAMA specific registers to set or remove a breakpoint, i.e., the developer has run-time control over breakpoints.
There's no such limit in MesaDX, you can have a breakpoint set for every single memory address. Using labels is a good idea. Would it be acceptable if the symbol file was simply loaded, and you could just type the symbol name in a breakpoint add window instead of selecting from a tree or list?
I agree. I'm going to (try to) familiarize myself with WLA-DX and get back to you on this.
Sounds good. I am planning on having a "project file" feature which would all developers to save and load information about the debugger configuration.
I'll look into that.
The plug-in idea is very good. The AGAMA machine emulator in MesaDX ("Kokin") already has much of the structure (programmer interface) required to report emulator status back to the debugging GUI. Let me do some research and testing on this to determine how to best support plug-ins in MesaDX.
I laughed when I read the line above. I'm flattered that I deserved 5 +'s. Thanks for all the information Heliphobe. -- Eric Quinn |
|
|
|
|
|
Re: that reply I was promising:
Posted: Fri Mar 02, 2001 1:01 am
|
Another one I thought of, which is probably tricky to implement but might be worth trying: A means of detecting when a 'ret' instruction doesn't return to the address that called it (or the address the CPU was at when the interrupt occured), as a way to check if there have been too many pop or push instructions in a function. This one zings me quite frequently. IT would be good to be able to turn that off since again I do some nasty stack tricks in places.
Ah, sensible.
http://www.hut.fi/~vhelin/wla.html And I've compiled a win32 binary of the latest beta version and put them here. Later on (tonight?) I may post a very quick example of how to use it (there are some compulsory directives you need to use to define the memory map, new concepts to learn, and one or two pitfalls for TASM users.)
That's an interesting idea, I could see that being very useful.
In that case, three cheers for MesaDX!
Sure, feel free to fire any questions at me (or Ville)
That's a good idea.
Sure thing.. the more I think about it the more I like the idea.
I think the usual custom is to use as many +'s as will fit in the 80 character limit. |
|
|
|
|
