Brass 3.0.0.0 Beta 13

One suite to code them all. An complete IDE and assembler for all your z80 projects!

Moderators: benryves, kv83

Post Reply
User avatar
benryves
Maxcoderz Staff
Posts: 3087
Joined: Thu 16 Dec, 2004 10:06 pm
Location: Croydon, England
Contact:

Post by benryves »

Brass 3.0.0.0 Beta 12 wrote: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
MCF Legend
Posts: 1601
Joined: Mon 20 Dec, 2004 8:45 am
Location: Budapest, Absurdistan
Contact:

Post by CoBB »

benryves wrote: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... :roll:
User avatar
benryves
Maxcoderz Staff
Posts: 3087
Joined: Thu 16 Dec, 2004 10:06 pm
Location: Croydon, England
Contact:

Post by 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
MCF Legend
Posts: 1601
Joined: Mon 20 Dec, 2004 8:45 am
Location: Budapest, Absurdistan
Contact:

Post by CoBB »

benryves wrote: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. ;)
benryves wrote: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. :)
User avatar
benryves
Maxcoderz Staff
Posts: 3087
Joined: Thu 16 Dec, 2004 10:06 pm
Location: Croydon, England
Contact:

Post by 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
Extreme Poster
Posts: 346
Joined: Mon 17 Jan, 2005 8:56 am
Location: Indiana

Post by 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
MCF Legend
Posts: 1601
Joined: Mon 20 Dec, 2004 8:45 am
Location: Budapest, Absurdistan
Contact:

Post by CoBB »

Spencer wrote: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.
Spencer wrote: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
Extreme Poster
Posts: 346
Joined: Mon 17 Jan, 2005 8:56 am
Location: Indiana

Post by Spencer »

Cobb wrote: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.
Cobb wrote: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).
User avatar
benryves
Maxcoderz Staff
Posts: 3087
Joined: Thu 16 Dec, 2004 10:06 pm
Location: Croydon, England
Contact:

Post by 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
Calc King
Posts: 1513
Joined: Sat 05 Aug, 2006 7:22 am

Post by King Harold »

User avatar
driesguldolf
Extreme Poster
Posts: 395
Joined: Thu 17 May, 2007 4:49 pm
Location: $4080
Contact:

Post by driesguldolf »

benryves wrote:
driesguldolf wrote: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
Extreme Poster
Posts: 346
Joined: Mon 17 Jan, 2005 8:56 am
Location: Indiana

Post by 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
Brass 3 wrote:************** 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.
User avatar
benryves
Maxcoderz Staff
Posts: 3087
Joined: Thu 16 Dec, 2004 10:06 pm
Location: Croydon, England
Contact:

Post by benryves »

King Harold wrote:This works for me.. http://www.revsoft.org/wabbitemu.zip
Thanks! :)
driesguldolf wrote:
benryves wrote:
driesguldolf wrote: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).
Spencer wrote: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
Brass 3 wrote:************** 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
Extreme Poster
Posts: 346
Joined: Mon 17 Jan, 2005 8:56 am
Location: Indiana

Post by 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.
User avatar
benryves
Maxcoderz Staff
Posts: 3087
Joined: Thu 16 Dec, 2004 10:06 pm
Location: Croydon, England
Contact:

Post by 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";
Post Reply