Brass 3.0.0.0 Beta 13

[benryves]

Temporary unresolved labels created when parsing expressions were not being purged if the parser threw an exception, resulting in incorrect error report information. This has been corrected.

Added a crude debugging framework that hopefully will become a lot more flexible. Currently it can be used (via a plugin in the Core package) to run an external program or a slightly updated version of the PindurTI debugger from Latenite 1.

Templates have been modified for use with the PindurTI debugger.

Tidied up the project builder a little (default build configuration, IE stealing shortcut keys).

An error is displayed when loading buggy, old or otherwise problematic plugins in the help viewer. The help viewer automatically handles all .exe files now (as well as .dlls) and supports debugger plugins.

...and .global, but I forgot to mention that in the release notes.

The "PindurTI debugger" has been mercilessly hacked out of Latenite, so the code very bad (reliance on public static members in Program, to give you a sample). CoBB is not properly credited, though, and it does use a pretty old build of PindurTI, so this'll have to be fixed.

[CoBB]

The "PindurTI debugger" has been mercilessly hacked out of Latenite, so the code very bad (reliance on public static members in Program, to give you a sample). CoBB is not properly credited, though, and it does use a pretty old build of PindurTI, so this'll have to be fixed.

The newest build is pretty old already, it was uploaded more than a year ago...

[benryves]

s/pretty/very old, then.

I'd really like to do a total rewrite of the front-end so it can interact with the assembler a bit better. And it really needs your name on it.

That said, not being able to change the state of the calculator via the non-interactive mode (edit registers and memory, for example) limits the usefulness of any debugger, so I don't know if the time would be better spent working on this.

[CoBB]

I'd really like to do a total rewrite of the front-end so it can interact with the assembler a bit better. And it really needs your name on it.

I’m not standing in your way.

That said, not being able to change the state of the calculator via the non-interactive mode (edit registers and memory, for example) limits the usefulness of any debugger, so I don't know if the time would be better spent working on this.

Hmm, I think the easiest route would be simply to take the 83+ emulation of PTI and adapt it to your code. Since I can’t seem to allocate any time for it any more, I’ll just release the source and let everyone do whatever they want with it.

[benryves]

The source would be very useful -- I'm already using adaptations of your arithmetic table generation code in the Z80 emulator bit as it is.

[Spencer]

Wabbitemu expands on a lot of PindurTI's features, it wouldn't be a bad idea to incorporate your source with it. You'd also get support for SE and 84+.

The next version has many improvements over the first beta release. Perhaps supporting a modified version of Cobb's scripting would be a good idea. Alternatively, I also have gotten very interested in COM lately with all the drag-and-drop fanciness, so I'd have no problem providing a COM debugging interface. (COM would also allow Wabbitemu code to show output instead of funneling it through stdout).

[CoBB]

Wabbitemu expands on a lot of PindurTI's features, it wouldn't be a bad idea to incorporate your source with it. You'd also get support for SE and 84+.

I don’t think the current core would be easy to use for these newer models, and I had problems adding debugging facilities too. It would require a complete, much better thought out rewrite.

Alternatively, I also have gotten very interested in COM lately with all the drag-and-drop fanciness, so I'd have no problem providing a COM debugging interface. (COM would also allow Wabbitemu code to show output instead of funneling it through stdout).

I went the stdio way because I wanted something portable that’s still flexible enough. And it’s not much of a burden even if you transmit the full calculator state several times a second, which is of course unnecessary.

[Spencer]

I went the stdio way because I wanted something portable that’s still flexible enough.

That's certainly the most portable interface. Inspired by your command-line interface, we almost went the stdout route for the Mac OS version of Wabbitemu, but with a couple of tweaks the core can neatly build side-by-side with the native Objective-C.

One of the main reasons I favor the COM approach is it would allow Ben to use our display and display configuration dialogs without requiring any duplicated effort. We put a lot of effort into the next release to allow the user the option of making any grayscale program appear with all its "theoretical" shades.

I had problems adding debugging facilities

Your debugger is still more mature than Wabbitemu's in some ways. I only added features as I needed them (so features like importing breakpoints and labels were done earlier than other essential features like ports and memory banks).

[benryves]

I have to confess, I feel an acute sense of embarrassment when it comes to WabbitEmu, as I've never been able to find a working binary - so am yet to use it.

A COM interface would indeed be ideal on the Windows platform.

[King Harold]

This works for me.. http://www.revsoft.org/wabbitemu.zip

[driesguldolf]

But still, what happened to .global and .local?

I guess I never got around to writing them. Feel free to do so yourself, that's the basic idea here!

Actually it's rather a problem of that I have no idea where to start...
If you could give me some pointers where I can learn how to do that I'd be very happy

.local isn't required (or practical) given the new entirely-modular label system. .global would be rather useful, though, I can see that.

I just mentioned it for the sake of completeness, though you're correct.
In the meanwhile I ended up making an extra file which re-equates all routines available from the libraries. Though I will probably keep using this trick because it's easier to replace/modify libraries without causing mass label not found errors.

[Spencer]

I figured I better give this a try, but I'm having a bit of trouble. In Windows Vista I see the shell extension for "Build" for the projects in Templates. When I click it, the Project Builder opens. If I hit rebuild or debug, this pops up

************** Exception Text **************
System.ArgumentNullException: Value cannot be null.
Parameter name: path2
at System.IO.Path.Combine(String path1, String path2)
etc
etc

Also I unwittingly removed Brass.exe from the folder (I was trying to create a desktop shortcut so I could see if you did a PNG icon for Vista haha), which causes any helper program to crash.

[benryves]

This works for me.. http://www.revsoft.org/wabbitemu.zip

Thanks!

But still, what happened to .global and .local?

I guess I never got around to writing them. Feel free to do so yourself, that's the basic idea here!

Actually it's rather a problem of that I have no idea where to start...
If you could give me some pointers where I can learn how to do that I'd be very happy

Aye, the plugin development could probably do with some documentation. For the record, the way I implemented .global was to save the current module then set it to "" (and then recalling the old module when it hit .endglobal).

I figured I better give this a try, but I'm having a bit of trouble. In Windows Vista I see the shell extension for "Build" for the projects in Templates. When I click it, the Project Builder opens. If I hit rebuild or debug, this pops up

************** Exception Text **************
System.ArgumentNullException: Value cannot be null.
Parameter name: path2
at System.IO.Path.Combine(String path1, String path2)
etc
etc

Ah, OK, that looks easy enough to correct. Not that building a template is going to do anything meaningful...

Also I unwittingly removed Brass.exe from the folder (I was trying to create a desktop shortcut so I could see if you did a PNG icon for Vista haha), which causes any helper program to crash.

The helper programs all reference the Brass.exe assembly directly (rather than running it as a process and using some sort of interprocess communication system) so it's going to be much the same result as removing any library file. I'm not sure if I can detect and handle such error conditions cleanly. (No 256x256 PNG icon, I'm afraid, only 48x48 XP icons).

[Spencer]

Ohh, I finally found the example projects in the documents folder. Sorry about that.

When I use the shell extension to build it just opens up the compiler UI. I have to hit rebuild for it to generate the 8xp. This is OK, but isn't the behavior I was expecting.

[benryves]

You found a bug anyway, so nothing is lost.

The "Build" menu option/verb is carried over from when it would just build the project and exit immediately (or remain open if there were any errors). Would you rather it built automatically, or would you rather I changed the context menu item to "Open"?

It's not a true shell extension, just a registry entry to register the file type.

Code: Select all

[Registry]
; Register .brassproj file type:
Root: HKCR; Subkey: ".brassproj"; ValueType: string; ValueData: "Brass.Project";
Root: HKCR; Subkey: "Brass.Project"; ValueType: string; ValueData: "Brass Project";
Root: HKCR; Subkey: "Brass.Project\shell\Build\command"; ValueType: string; ValueData: """{app}\ProjectBuilder.exe"" ""%1"""; Components: "Tools\ProjectBuilder";