Megalextoria
Retro computing and gaming, sci-fi books, tv and movies and other geeky stuff.

Home » Digital Archaeology » Computer Arcana » Apple » Apple II » 6502bench SourceGen disassembler updated
Show: Today's Messages :: Show Polls :: Message Navigator
E-mail to friend 
Switch to threaded view of this topic Create a new topic Submit Reply
6502bench SourceGen disassembler updated [message #385700] Sun, 04 August 2019 18:15 Go to next message
Anonymous
Karma:
Originally posted by: fadden

6502bench SourceGen (https://6502bench.com/) v1.2.0 has been released. This is just like v1.1, but implemented on a different UI library.

SourceGen v1.3.0-dev2 is now available. Key features:

- Partial support for ACME cross-assembler. I say "partial" because ACME's internal program counter is apparently only 16 bits, so 65816 code targeted outside bank zero is problematic.

- Apple /// SOS MLI calls, which are like ProDOS MLI calls but with BRK instead of JSR, are now handled. This change also breaks all existing SourceGen plugins, but I'm guessing there aren't a lot of those. (See https://github.com/fadden/6502bench/issues/44 for notes on updating existing projects..)

- Changed handling of BRK. I was treating it 65816-style, as a two-byte instruction, but hardly anything else does that, and things were getting awkward.

- Updated cc65 support for cc65 v2.18, although nothing much is different from v2.17 as far as SourceGen is concerned.

- Minor fixes to the new UI.


Source code and pre-built Windows binaries are available from https://github.com/fadden/6502bench/releases
6502bench SourceGen disassembler updated [message #385710 is a reply to message #385700] Mon, 05 August 2019 02:46 Go to previous messageGo to next message
Antoine Vignau is currently offline  Antoine Vignau
Messages: 1671
Registered: October 2012
Karma: 0
Senior Member
Congrats!
av
Re: 6502bench SourceGen disassembler updated [message #385713 is a reply to message #385700] Mon, 05 August 2019 10:40 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: Frank M.

nice. thanks for adding acme. look forward to checking it out.
f
Re: 6502bench SourceGen disassembler updated [message #385719 is a reply to message #385713] Mon, 05 August 2019 16:31 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: fadden

On Monday, August 5, 2019 at 7:40:54 AM UTC-7, Frank M. wrote:
> nice. thanks for adding acme. look forward to checking it out.

ACME works great unless you're disassembling 65816 code. I've pinged the author to see if there's a way around the problem. (As noted in the docs, the internal PC is only 16 bits, so it has trouble with code outside bank zero.)

There's some potential room for improvement, e.g. using !xor to generate high-ASCII text strings.

Speaking of 65816 code, nobody can agree on what MVN/MVP args should look like: https://github.com/cc65/cc65/issues/925 . Merlin 32 is winning that one. :-)
Re: 6502bench SourceGen disassembler updated [message #385725 is a reply to message #385719] Mon, 05 August 2019 17:45 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: Frank M.

On Monday, August 5, 2019 at 1:31:47 PM UTC-7, fadden wrote:
> There's some potential room for improvement, e.g. using !xor to generate high-ASCII text strings.


I was wondering how to do that. My first big project with acme targeted the ][+ where I didn't need to worry about figuring it out.

f
Re: 6502bench SourceGen disassembler updated [message #385763 is a reply to message #385700] Wed, 07 August 2019 05:38 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: Brian Patrie

On 04/08/2019 17.15, fadden wrote:
> - Changed handling of BRK. I was treating it 65816-style, as a two-byte instruction, but hardly anything else does that, and things were getting awkward.

AFAIK, The 6502 also treats BRK as a two byte instruction; but the weird
precedent of treating it as a single was set (perhaps by the Apple II
disassembler), and it stuck.
Re: 6502bench SourceGen disassembler updated [message #385772 is a reply to message #385763] Wed, 07 August 2019 10:50 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: fadden

On Wednesday, August 7, 2019 at 2:38:03 AM UTC-7, Brian Patrie wrote:
> On 04/08/2019 17.15, fadden wrote:
>> - Changed handling of BRK. I was treating it 65816-style, as a two-byte instruction, but hardly anything else does that, and things were getting awkward.
>
> AFAIK, The 6502 also treats BRK as a two byte instruction; but the weird
> precedent of treating it as a single was set (perhaps by the Apple II
> disassembler), and it stuck.

It *behaves* like a two-byte instruction, but the data sheet for the 6502 says it's a 1-byte instruction. (See e.g. the table on page 8 of http://archive.6502.org/datasheets/synertek_sy6500_microproc essors_apr_1979.pdf )

The 65CE02 sheet correctly lists it as two bytes.
Re: 6502bench SourceGen disassembler updated [message #385824 is a reply to message #385700] Wed, 07 August 2019 20:55 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: James Davis

According to Rodnay Zaks, in "Programming the 6502" (page 126), BRK is a single byte instruction, with a value of zero ($00).

ftp://public.asimov.net/pub/apple_II/documentation/programmi ng/6502assembly/Programming the 6502_OCR.pdf
Re: 6502bench SourceGen disassembler updated [message #385825 is a reply to message #385700] Wed, 07 August 2019 20:57 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: James Davis

According to Rodnay Zaks, in "Programming the 6502" (page 126), BRK is a single byte instruction, with a value of zero ($00).

ftp://public.asimov.net/pub/apple_II/documentation/programmi ng/6502assembly/Programming%20the%206502_OCR.pdf
Re: 6502bench SourceGen disassembler updated [message #386827 is a reply to message #385700] Mon, 09 September 2019 14:25 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: fadden

6502bench SourceGen v1.3.0-dev5 is now available. There are three new features.

The first is local variable tables. When disassembling some code I ran into a part that did something like:

LDA ($00),Y
INC $02

And then later on used the same zero-page locations in a different way:

INC $00
LDA ($01),Y

This made assigning a global name useless. To make this better, you can now define tables at different points in the file, and create variable definitions. The same labels can be re-used, so one bit of code can refer to $00 as PTR and $02 as COUNT, while another bit can call $00 COUNT and $01 PTR.

This also works for the 8-bit operand to 65816 stack-relative instructions (LDA $00,S or LDA $(00,S),Y). So if you have compiled code that uses stack-relative operands to access arguments, you can put a table at the start of each function and give the arguments names. Local variables have an explicit width, so you can identify 2-byte and 3-byte pointers.

Appropriate code is generated for all four cross-assemblers. 64tass, cc65, and Merlin 32 use .var, .set, and ']', respectively. ACME uses !zone to constrain local variable scope.

The second feature is a rewrite of the way SourceGen handles strings. This allows the disassembler to tag strings as ASCII, C64 PETSCII, or C64 screen codes. Apple II code won't benefit from that directly, but because PETSCII strings sometimes have embedded control characters to do things like change the text color, I updated the string recognizers to accept some non-printable characters.

In practical terms, it means that what used to be shown like this:

.STR 'HELLO, WORLD!'
.DD1 $0D

is now the slightly nicer:

.STR 'HELLO, WORLD!',$0D

I included $07, $0A, and $0D in the set for ASCII.

Having strings in various encodings is only helpful if you can tell them apart when reading the code, so string delimiters are now fully configurable. You can have Merlin-style single-vs-double quote for low vs. high ASCII, or define various prefix/suffix combinations. (I'm actually implementing support for high-ASCII immediate operands in non-Merlin assemblers by setting the suffix to "| $80".)

The third feature is a rewrite of the Edit Instruction Operand dialog, which had some mildly baffling "shortcuts" at the bottom. These have been replaced with buttons that let you edit labels, project symbols, and local variables associated with the operand.

Source code and pre-built Windows binaries are available from https://github.com/fadden/6502bench/releases
Re: 6502bench SourceGen disassembler updated [message #387249 is a reply to message #386827] Sat, 21 September 2019 19:30 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: fadden

6502bench SourceGen v1.3.0-alpha1 is now available. There is one new feature, and lots of little improvements.

SourceGen can now "export" the project listing to text, CSV, or HTML. This behaves similarly to the text-copy option that has been around for a while, in that it exports the text as it appears on the screen, rather than formatted for some specific assembler. This gives you full control over text delimiters, pseudo-opcodes, expression syntax, cycle counts, and so on.

As an exercise, I converted Bob Sander-Cederlof's disassembly of Applesoft to SourceGen format, and exported it to HTML. The project file and HTML output can be found here: https://bigflake.com/disasm/applesoft/

I'm not quite sold on the HTML style. All of the symbols are output as links, and the blue underlined text feels kind of distracting. I may tweak the formatting in the CSS file. Maybe even just make it look like plain text that happens to be clickable?

Source code and pre-built Windows executables for SourceGen are available from https://github.com/fadden/6502bench/releases
Re: 6502bench SourceGen disassembler updated [message #387262 is a reply to message #387249] Sun, 22 September 2019 05:34 Go to previous messageGo to next message
Antoine Vignau is currently offline  Antoine Vignau
Messages: 1671
Registered: October 2012
Karma: 0
Senior Member
Nice work, Andy!

av
Re: 6502bench SourceGen disassembler updated [message #387277 is a reply to message #387249] Sun, 22 September 2019 22:02 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: fadden

On Saturday, September 21, 2019 at 4:30:58 PM UTC-7, fadden wrote:
> As an exercise, I converted Bob Sander-Cederlof's disassembly of Applesoft to SourceGen format, and exported it to HTML. The project file and HTML output can be found here: https://bigflake.com/disasm/applesoft/

I felt like getting more exercise.

Autostart ROM, direct from the Apple II Reference Manual:
https://bigflake.com/disasm/apple2-rom/F8ROM.html
Re: 6502bench SourceGen disassembler updated [message #387355 is a reply to message #387277] Wed, 25 September 2019 16:51 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: James Davis

On Sunday, September 22, 2019 at 7:02:22 PM UTC-7, fadden wrote:
> On Saturday, September 21, 2019 at 4:30:58 PM UTC-7, fadden wrote:
>> As an exercise, I converted Bob Sander-Cederlof's disassembly of Applesoft to SourceGen format, and exported it to HTML. The project file and HTML output can be found here: https://bigflake.com/disasm/applesoft/
>
> I felt like getting more exercise.
>
> Autostart ROM, direct from the Apple II Reference Manual:
> https://bigflake.com/disasm/apple2-rom/F8ROM.html

Strange, this last link is not working directly from Google Groups with MSIE-11 (error message: this page cannot be displayed), but the address works if I copy it to the IE address bar and go to it from there.
Re: 6502bench SourceGen disassembler updated [message #387410 is a reply to message #387355] Fri, 27 September 2019 17:54 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: fadden

6502bench SourceGen (https://6502bench.com/) v1.3.0 has been released. Key changes since v1.2:

- Added local variable tables. These are redefinable symbols that can be used for zero-page and stack-relative operands.
- Added support for the ACME cross-assembler (65816 support is limited).
- Added support for multiple character encodings. C64 PETSCII and screen code strings can be detected automatically, and the encodings may now be manually specified for characters and strings. Some non-printable characters, such as CR/LF, are now allowed in strings.
- Added ability to "export" the code listing to text, CSV, or HTML.
- Character and string delimiters are configurable.
- Rewrote the Edit Instruction Operand dialog to make the "shortcuts" less obscure.
- Made various improvements to source code generation for 64tass, cc65 (now v2.18), and Merlin 32.
- Changed handling of BRK to treat it as a single-byte instruction with no operand.
- Added support for Apple /// SOS MLI calls, which use BRK instructions with inline data.
- Various bug fixes and miscellaneous improvements.

Source code and pre-built Windows binaries are available from https://github.com/fadden/6502bench/releases
Re: 6502bench SourceGen disassembler updated [message #387411 is a reply to message #387277] Fri, 27 September 2019 18:04 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: fadden

On Sunday, September 22, 2019 at 7:02:22 PM UTC-7, fadden wrote:
> I felt like getting more exercise.

Added another one. This is the one that inspired me to add local variable tables: Bill Budge's 3-D Graphics System and Game Tool. I disassembled a "module" generated by the tool to see how he handled math and line drawing.

https://bigflake.com/disasm/apple2-budge3d/

(if you're not familiar with this program, I've got a bunch of links on the page, including a video of the demo that comes with it)
Re: 6502bench SourceGen disassembler updated [message #387488 is a reply to message #387410] Wed, 02 October 2019 03:41 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: James Davis

On Friday, September 27, 2019 at 2:54:50 PM UTC-7, fadden wrote:
> 6502bench SourceGen (https://6502bench.com/) v1.3.0 has been released. Key changes since v1.2:
>
> - Added local variable tables. These are redefinable symbols that can be used for zero-page and stack-relative operands.
> - Added support for the ACME cross-assembler (65816 support is limited).
> - Added support for multiple character encodings. C64 PETSCII and screen code strings can be detected automatically, and the encodings may now be manually specified for characters and strings. Some non-printable characters, such as CR/LF, are now allowed in strings.
> - Added ability to "export" the code listing to text, CSV, or HTML.
> - Character and string delimiters are configurable.
> - Rewrote the Edit Instruction Operand dialog to make the "shortcuts" less obscure.
> - Made various improvements to source code generation for 64tass, cc65 (now v2.18), and Merlin 32.
> - Changed handling of BRK to treat it as a single-byte instruction with no operand.
> - Added support for Apple /// SOS MLI calls, which use BRK instructions with inline data.
> - Various bug fixes and miscellaneous improvements.
>
> Source code and pre-built Windows binaries are available from https://github.com/fadden/6502bench/releases

For those of us who like to double-click a project file and have it run the SourceGen program with the file loaded, here is a sameple RegEdit file to adapt and merge [for *.dis65 & *.sym65 files (on W7U64DTC)]:

Windows Registry Editor Version 5.00

;=========================================================== ===
; SourceGen Files (SourceGen.reg)
;=========================================================== ===


;=========================================================== ===
; Notes:
;=========================================================== ===
;
; Unzipped "6502bench130.zip" to "C:\Program Files\6502bench"
; (on a Windows 7 Ultimate (64-bit) Lenovo desktop computer).
;
;----------------------------------------------------------- ---
;
; On first OpenWith, named:
;
; "*.dis65" files, "SourceGen Project File"
; (Open with: "SourceGen.exe"); and,
;
; "*.sym65" files, "SourceGen Platform Symbol File"
; (Open with: "NotePad.exe").
;
;----------------------------------------------------------- ---
;
; Renamed *_auto_files from "*65_auto_file" to "*65file".
;
;=========================================================== ===


;=========================================================== ===

[HKEY_CURRENT_USER\Software\Classes\.dis65]
@="dis65file"

;----------------------------------------------------------- ---

[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion \Explorer\FileExts\.dis65]
[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion \Explorer\FileExts\.dis65\OpenWithList]
"a"="SourceGen.exe"
"MRUList"="a"

[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion \Explorer\FileExts\.dis65\OpenWithProgids]
"dis65file"=hex(0):

;----------------------------------------------------------- ---

[-HKEY_CURRENT_USER\Software\Classes\dis65_auto_file]

[HKEY_CURRENT_USER\Software\Classes\dis65file]
@="SourceGen Project File"

[HKEY_CURRENT_USER\Software\Classes\dis65file\shell]
[HKEY_CURRENT_USER\Software\Classes\dis65file\shell\open]
[HKEY_CURRENT_USER\Software\Classes\dis65file\shell\open\com mand]
@="\"C:\\Program Files\\6502bench\\SourceGen.exe\" \"%1\""

;=========================================================== ===

[HKEY_CURRENT_USER\Software\Classes\.sym65]
@="sym65file"

;----------------------------------------------------------- ---

[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion \Explorer\FileExts\.sym65]
[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion \Explorer\FileExts\.sym65\OpenWithList]
"a"="NOTEPAD.EXE"
"MRUList"="a"

[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion \Explorer\FileExts\.sym65\OpenWithProgids]
"sym65file"=hex(0):

;----------------------------------------------------------- ---

[-HKEY_CURRENT_USER\Software\Classes\sym65_auto_file]

[HKEY_CURRENT_USER\Software\Classes\sym65file]
;@="SourceGen Platform Symbol File"
@="SourceGen Symbol File"; (short name)

[HKEY_CURRENT_USER\Software\Classes\sym65file\shell]
[HKEY_CURRENT_USER\Software\Classes\sym65file\shell\edit]
[HKEY_CURRENT_USER\Software\Classes\sym65file\shell\edit\com mand]
;@="%SystemRoot%\\system32\\NOTEPAD.EXE %1"
@=hex(2):25,00,53,00,79,00,73,00,74,00,65,00,6d,00,52,00,6f, 00,6f,00,74,00,25,\
00,5c,00,73,00,79,00,73,00,74,00,65,00,6d,00,33,00,32,00,5c, 00,4e,00,4f,00,\
54,00,45,00,50,00,41,00,44,00,2e,00,45,00,58,00,45,00,20,00, 25,00,31,00,00,\
00

[HKEY_CURRENT_USER\Software\Classes\sym65file\shell\open]
[HKEY_CURRENT_USER\Software\Classes\sym65file\shell\open\com mand]
;@="%SystemRoot%\\system32\\NOTEPAD.EXE %1"
@=hex(2):25,00,53,00,79,00,73,00,74,00,65,00,6d,00,52,00,6f, 00,6f,00,74,00,25,\
00,5c,00,73,00,79,00,73,00,74,00,65,00,6d,00,33,00,32,00,5c, 00,4e,00,4f,00,\
54,00,45,00,50,00,41,00,44,00,2e,00,45,00,58,00,45,00,20,00, 25,00,31,00,00,\
00

;=========================================================== ===

[HKEY_CURRENT_USER\Software\Classes\Applications\SourceGen.e xe]
[HKEY_CURRENT_USER\Software\Classes\Applications\SourceGen.e xe\shell]
[HKEY_CURRENT_USER\Software\Classes\Applications\SourceGen.e xe\shell\open]
[HKEY_CURRENT_USER\Software\Classes\Applications\SourceGen.e xe\shell\open\command]
@="\"C:\\Program Files\\6502bench\\SourceGen.exe\" \"%1\""

;=========================================================== ===

[HKEY_CURRENT_USER\Software\Classes\Local Settings\Software\Microsoft\Windows\Shell\MuiCache]
"C:\\Program Files\\6502bench\\SourceGen.exe"="SourceGen"

;=========================================================== ===
Re: 6502bench SourceGen disassembler updated [message #387489 is a reply to message #387488] Wed, 02 October 2019 10:58 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: fadden

On Wednesday, October 2, 2019 at 12:41:44 AM UTC-7, James Davis wrote:
> For those of us who like to double-click a project file and have it run the SourceGen program with the file loaded, here is a sameple RegEdit file to adapt and merge [for *.dis65 & *.sym65 files (on W7U64DTC)]:

Nice!


In related news, I found a crashing bug, so v1.3.1 has been released. (Open a project, and immediately click on the "Actions" menu... boom. Whoops. Edge case where no lines are selected.)

In related news, I can recommend the "OneFlow" methodology for managing hotfixes in a simple git repository.

FWIW, v1.3 added a crash trap that writes a "CrashLog.txt" into the installation directory when a fatal exception is encountered. So if the program crashes, look there for details.
Re: 6502bench SourceGen disassembler updated [message #387503 is a reply to message #387489] Thu, 03 October 2019 02:13 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: James Davis

On Wednesday, October 2, 2019 at 7:58:08 AM UTC-7, fadden wrote:
> On Wednesday, October 2, 2019 at 12:41:44 AM UTC-7, James Davis wrote:
>> For those of us who like to double-click a project file and have it run the SourceGen program with the file loaded, here is a sameple RegEdit file to adapt and merge [for *.dis65 & *.sym65 files (on W7U64DTC)]:
>
> Nice!
>
>
> In related news, I found a crashing bug, so v1.3.1 has been released. (Open a project, and immediately click on the "Actions" menu... boom. Whoops. Edge case where no lines are selected.)
>
> In related news, I can recommend the "OneFlow" methodology for managing hotfixes in a simple git repository.
>
> FWIW, v1.3 added a crash trap that writes a "CrashLog.txt" into the installation directory when a fatal exception is encountered. So if the program crashes, look there for details.

Andy:

That happened to me, too. Do you want me to email the crash report to you?

James Davis
Re: 6502bench SourceGen disassembler updated [message #387512 is a reply to message #387503] Thu, 03 October 2019 10:37 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: fadden

On Wednesday, October 2, 2019 at 11:13:52 PM UTC-7, James Davis wrote:
> That happened to me, too. Do you want me to email the crash report to you?

If the crash looks like the one in https://github.com/fadden/6502bench/issues/48 (look for "CanCreateLocalVariableTable()" a few lines from the top), then it's already fixed in v1.3.1.
Re: 6502bench SourceGen disassembler updated [message #387554 is a reply to message #387512] Sat, 05 October 2019 04:20 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: James Davis

On Thursday, October 3, 2019 at 7:37:27 AM UTC-7, fadden wrote:
> On Wednesday, October 2, 2019 at 11:13:52 PM UTC-7, James Davis wrote:
>> That happened to me, too. Do you want me to email the crash report to you?
>
> If the crash looks like the one in https://github.com/fadden/6502bench/issues/48 (look for "CanCreateLocalVariableTable()" a few lines from the top), then it's already fixed in v1.3.1.

I have found two crashlog.txt files (that I renamed):

6502bench SourceGen Disassembler CrashLog [2019-10-01].txt (13KB) [Contains "CanCreateLocalVariableTable()"]

6502bench SourceGen Disassembler CrashLog [2019-10-03].txt (5KB) [Does not contain "CanCreateLocalVariableTable()"]

They do not say internally which version of 6502bench SourceGen crashed. They are Greek to me. If you want to look at them, I will send them to you. If you do not, I will delete them.
Re: 6502bench SourceGen disassembler updated [message #387555 is a reply to message #385700] Sat, 05 October 2019 04:40 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: James Davis

Andy,

I have gone through the Tutorials and have found a few quirks, but it is getting too late (1:35 AM), so I will write about it the next time I am online here.

Good night,

James Davis
Re: 6502bench SourceGen disassembler updated [message #387571 is a reply to message #387554] Sat, 05 October 2019 14:23 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: fadden

On Saturday, October 5, 2019 at 1:20:24 AM UTC-7, James Davis wrote:
> I have found two crashlog.txt files (that I renamed):
>
> 6502bench SourceGen Disassembler CrashLog [2019-10-01].txt (13KB) [Contains "CanCreateLocalVariableTable()"]
>
> 6502bench SourceGen Disassembler CrashLog [2019-10-03].txt (5KB) [Does not contain "CanCreateLocalVariableTable()"]

The second one sounds interesting. Please do forward that to my e-mail if you get a chance. (Alternatively, create a new issue at https://github.com/fadden/6502bench/issues and attach the file.)

> They do not say internally which version of 6502bench SourceGen crashed.

They do now. :-) When you asked about the logs a few days back, it occurred to me that the crash logs should do a better job of identifying themselves, so now the app version and OS version are printed before each crash. (This'll start showing up in the first 1.4 dev release.)

Note that crashes are appended to CrashLog.txt if it already exists. Search for "***" to find the start of each. Your files are small enough that they probably only have one crash in them (WPF generates some deep stack traces).
Re: 6502bench SourceGen disassembler updated [message #387598 is a reply to message #387555] Sun, 06 October 2019 04:01 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: James Davis

On Saturday, October 5, 2019 at 1:40:17 AM UTC-7, James Davis wrote:
> Andy,
>
> I have gone through the Tutorials and have found a few quirks, but it is getting too late (1:35 AM), so I will write about it the next time I am online here.
>
> Good night,
>
> James Davis

Here are some of the quirks I have noticed ...

============================================================ ====
6502bench SourceGen Quirks:
============================================================ ====

In the disassembly window, at the bottom, when the slider bar is
not all the way to the left, and/or any amount or all the way to
the right, double-clicking on a column (e.g., the label-column*)
brings up the action-window for the column just to the right of
the column double-clicked (e.g., the attribute-column*,
respectively); unless the cursor is an equal offset to the right
(within the column-field selected) as the distance (lighter-
area) to the right of the slider-bar. [In other words, (it's
"Weird!" that) you have to offset your mouse-click, too!]

------------------------------------------------------------ ----

In the disassembly window, I keep expecting the (long or short)
comments and notes to work like in a word-processor (e.g.,
NotePad, MetaPad or {my preferred} WordPad), by clicking in the
column or field once, then trying to place the cursor within the
field by clicking it again somewhere else within the field;
instead of quickly double-clicking it in the first place.

It would be nice if comments and notes also worked like in a
word-processor or worked to bring up the edit-window with a
second single-click (on new short-comments, if possible, and
existing comments {both, within the comment-column}, and on
long-comments and notes).

A quick double-click should not be necessary for editing
existing (long or short) comments and notes; two single-clicks
should also work within the same field {of lines--for "multi-
line" comments and notes} (no matter where the mouse/cursor has
been between single-clicks). [Some kind of "field-single-
clicked-twice (with no-clicks-outside-the-field-between-
clicks)" flag might do the trick.]

------------------------------------------------------------ ----

There needs to be a way [using Windows' standard (large) Color
selector dialog] to set some or all the colors used in the
application to user preferred colors (e.g., all the different
highlighting colors, window background color, etc.) vs. the
Users' windows-theme or Windows' standard colors; one or the
other of which should be selectable as a base to start with (or
to build upon).

[See attached picture.]

[For example, I would prefer all the 'SELECTED' field-
highlighting to be the same (e.g., dark background with light
lettering {e.g., blue/white}), not the (light background and
dark lettering) colors you have enabled for long-comments and
notes.--{No offense meant!}]

------------------------------------------------------------ ----

Allow fonts (for individual words and characters) to be normal,
bold, italic, underlined, struck-through, and subscripted or
superscripted; like in a word-processor (e.g., WordPad {RTF});
especially in comments and notes. [Maybe there is an RTF.DLL
for textual fields you could incorporate.]

------------------------------------------------------------ ----

In the disassembly window, at the top, the column headers should
also be re-adjustable using the standard Windows ctrl-+, shift-
+, and non-standard ctrl-shift-+ key-combinations; to set them
to (ctrl-+) the maximum column widths used (below them), and
(shift-+) to the same but with the column header-name widths as
a minimum (so the names are not truncated), and (ctrl-shift-+)
to reset them to their application defaults; respectively.

------------------------------------------------------------ ----

It would be nice to be able to insert extra blank-lines, long-
comments and notes, above and/or below other lines and at the
very end, in the disassemblies.

And/or, it would be nice to be able to drag-&-drop blank-lines,
long-comments and notes, up or down in the disassemblies.

A line space is achievable as a single space in a long-comment
or note, but they have inline artifacts!

To put anything below the last line, one would have to pad the
original binary/hexadecimal machine code with an extra zero
byte, and remove it after editing the disassembly. Would the
edit remain or disappear? I will have to test this.

------------------------------------------------------------ ----

It would be nice to be able to load an ASCII text of another
disassembly created by other means and have SourceGen be able to
use it (detecting which assembler format to use, too), with or
without a binary/hexadecimal machine code file to go with it.

------------------------------------------------------------ ----

The settings keep resetting/reverting to 64tass on the last
three tabs. They do not stay set to Merlin from session to
session. Do you think this is because of the windows
permissions for the path I am using, "C:\Program Files\6502bench
\"? Or, could it be a bug in SourceGen?

============================================================ ====
Re: 6502bench SourceGen disassembler updated [message #387609 is a reply to message #387598] Sun, 06 October 2019 17:12 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: fadden

On Sunday, October 6, 2019 at 1:01:38 AM UTC-7, James Davis wrote:
> In the disassembly window, at the bottom, when the slider bar is
> not all the way to the left, and/or any amount or all the way to
> the right, double-clicking on a column (e.g., the label-column*)
> brings up the action-window for the column just to the right of
> the column double-clicked (e.g., the attribute-column*,
> respectively);

That's a bug. WPF (Windows Presentation Foundation) is based on the philosophy that hard things should be possible, and easy things should be really hard. One manifestation of this is the absence of "what row and column was clicked on" methods in ListView and DataGrid. My implementation failed to take the horizontal scroll position into account.

Fixed.

> In the disassembly window, I keep expecting the (long or short)
> comments and notes to work like in a word-processor (e.g.,
> NotePad, MetaPad or {my preferred} WordPad)

I have a "to do" list item for in-place editing of labels and comments. There might be a way to convince WPF to do it for me, but it'll likely require using a fully custom control.

The main disassembly window is a WPF ListView control with some style changes, mostly to have text that extends across multiple columns. This was sufficiently difficult that I created a separate github project just to play with it (https://github.com/fadden/DisasmUiTest). I'm not yet experienced with WPF to know how hard in-place editing would be.

> A quick double-click should not be necessary for editing
> existing (long or short) comments and notes; two single-clicks
> should also work within the same field {of lines--for "multi-
> line" comments and notes} (no matter where the mouse/cursor has
> been between single-clicks).

I think that would make sense for in-place editing. I'm picturing the way Windows lets you rename a file by selecting it, and then doing a second single click. I don't think it feels right when the action is to open an editor window though.

> There needs to be a way [using Windows' standard (large) Color
> selector dialog] to set some or all the colors used in the
> application to user preferred colors (e.g., all the different
> highlighting colors, window background color, etc.) vs. the
> Users' windows-theme or Windows' standard colors; one or the
> other of which should be selectable as a base to start with (or
> to build upon).

I have a long-standing request for a "dark" theme. Seems like it should be straightforward in WPF, but I haven't figured it out yet.

> [For example, I would prefer all the 'SELECTED' field-
> highlighting to be the same (e.g., dark background with light
> lettering {e.g., blue/white}), not the (light background and
> dark lettering) colors you have enabled for long-comments and
> notes.--{No offense meant!}]

That's another bug. The custom style that allows me to have long comments extend across multiple columns also requires me to define how highlighting works. In Win10, the system-wide theme has essentially no effect on the app, so my selected colors look the same as everything else in the list. I tried it just now on Win7, and the "high contrast" system theme significantly altered all of the colors in SourceGen, except for the ones in the replacement style. Ugh.

So I need to figure out how to get the appropriate color out of the system style. There's some chance that the Win7 Aero stuff behaves in a totally different way from what Win10 uses, which would make this even more fun.

> Allow fonts (for individual words and characters) to be normal,
> bold, italic, underlined, struck-through, and subscripted or
> superscripted; like in a word-processor (e.g., WordPad {RTF});
> especially in comments and notes.

This is doable, but I'm a little hesitant because one of the primary goals of SourceGen is to generate plain text source code, which means either stripping the formatting (which could lose information, e.g. the fact that text was struck out) or generating comments with RTF format strings (which is not especially easy for humans to read). It's useful for HTML output, but I'd rather have people express themselves within the confines of a fixed-width Unicode font so that things look the same everywhere.

> In the disassembly window, at the top, the column headers should
> also be re-adjustable using the standard Windows ctrl-+, shift-
> +, and non-standard ctrl-shift-+ key-combinations

I'm unclear as to how standard those are in terms of column widths. For example, in Chrome, those change the page "zoom" level.

> It would be nice to be able to insert extra blank-lines, long-
> comments and notes, above and/or below other lines and at the
> very end, in the disassemblies.
>
> And/or, it would be nice to be able to drag-&-drop blank-lines,
> long-comments and notes, up or down in the disassemblies.

This is doable. The reason it's not done now is that everything is associated with a file offset, and you only get one of each thing. So if you add a long comment, that comment is associated with a specific byte in the file, and is always displayed above that byte.

The mechanism could be made more general, e.g. multiple comments per offset, which can be placed above or below. Blank lines can be fiddled with. I think drag & drop or some other affordance would be necessary, since tweaking with the cosmetic aspects is awkward if you have to do it through a dialog window.

> A line space is achievable as a single space in a long-comment
> or note, but they have inline artifacts!

It would be easy to treat an empty single-line long comment as an explicit blank line. There's a potential issue in that it's hard to tell it apart from the automatically generated blank lines. (I could have a "don't put leading semicolons on blank lines" checkbox.)

> To put anything below the last line, one would have to pad the
> original binary/hexadecimal machine code with an extra zero
> byte, and remove it after editing the disassembly. Would the
> edit remain or disappear? I will have to test this.

The .dis65 file includes the file length and CRC, so you'd have to update those values before SourceGen would accept the altered file. It would then notice that you have something with an invalid offset, and ignore it. So.... don't do this.

> It would be nice to be able to load an ASCII text of another
> disassembly created by other means and have SourceGen be able to
> use it (detecting which assembler format to use, too), with or
> without a binary/hexadecimal machine code file to go with it.

This would be best done with a tool that generated a .dis65 file. The goal of such a thing would be to facilitate conversion of source code from one assembler to another by using SourceGen as a least-common-denominator format. The trouble is that SourceGen is far less expressive than a typical assembler, and you'd lose a lot. But if you can keep most of the labels and comments, that'd be an easier place to start from.

> The settings keep resetting/reverting to 64tass on the last
> three tabs. They do not stay set to Merlin from session to
> session.

This isn't a bug so much as it's just bad UI design. It annoys me too.

If you launch SourceGen v1.0, the "Quick Set" box has three buttons, "Default", "cc65", and "Merlin 32". You click the button, and the various fields get reconfigured. Simple.

In SourceGen v1.1, I added support for 64tass, and realized that my previous scheme didn't scale well, and made it difficult to add new assemblers. So instead of a pair of buttons, you have a pop-up menu, with a "Set" button to actually apply the values.

The problem, as you have noted, is that it looks like something is configured for 64tass, even though in practice nothing happens when you select a different assembler from the pop-up menu.

So the question is how to change the UI to make sense. One possibility is to get rid of "Set" and just make the combo box live: selecting a different assembler immediately updates all values. A new entry, "Custom", would hold the state of any recent edits. The pop-up would either show the name of the assembler (if all fields match) or "custom" (if any don't). So as soon as you make a change to any field, it switches to "custom" and obliterates any previously established custom setting... but I don't see a way around doing so that doesn't require wrapping a heavyweight customization UI around something that should be simple.
Re: 6502bench SourceGen disassembler updated [message #387618 is a reply to message #387609] Sun, 06 October 2019 21:38 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: fadden

SourceGen v1.3.2 has been released, to fix an "export HTML" crash that is likely responsible for the [2019-10-03] CrashLog.txt. I also threw in the fix for selecting the wrong column when the disassembly window is scrolled horizontally.
Re: 6502bench SourceGen disassembler updated [message #387652 is a reply to message #387609] Mon, 07 October 2019 20:36 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: James Davis

Two more quirks (but they are probably related to each other):

1. *.dis65 files do not work (reload into SourceGen) after being renamed (e.g.,
"Apple2.ROM.dis65" to "Apple2Plus.ROM.dis65" {SourceGen says it does not
exist!}).

2. *.dis65 files do not work (reload into SourceGen) within a folder named
"Apple II+"; but they will work after renaming the folder to "Apple II Plus"
(e.g., "Apple2.ROM.dis65" does not work from within the "Apple II+" folder,
but works in the "Apple II Plus" folder (renamed); but "Apple2Plus.ROM.dis65"
still does not work {SourceGen says it does not exist!}).
Re: 6502bench SourceGen disassembler updated [message #387656 is a reply to message #387652] Mon, 07 October 2019 20:53 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: fadden

On Monday, October 7, 2019 at 5:36:13 PM UTC-7, James Davis wrote:
> 1. *.dis65 files do not work (reload into SourceGen) after being renamed (e.g.,
> "Apple2.ROM.dis65" to "Apple2Plus.ROM.dis65" {SourceGen says it does not
> exist!}).
>
> 2. *.dis65 files do not work (reload into SourceGen) within a folder named
> "Apple II+"; but they will work after renaming the folder to "Apple II Plus"
[...]


I tried this a few different ways and didn't have any problems, so we're apparently doing different things. I will point out that the "Recent Projects" menu item, and the two recent project buttons on the initial screen, do not update when files move around in the filesystem. So if you rename or relocate a project, you will need to File > Open it rather than using the quick-load button.

This can be a little confusing because the buttons on the main screen only show the filename, so if you've opened something in two different places it's not immediately obvious which one is which. The Recent Projects menu does show full paths, so check and see if that matches up.

(It now occurs to me that the existing UI is dumb, because it's showing you a quick-load button for a project that isn't there. I'll fix that.)

The only requirement on filenames should be that the .dis65 file and the data file live in the same directory, and have the same name (just without ".dis65" for the data file). If that's not the case you'll get the opportunity to locate the file manually. Otherwise you should be able to call it anything Windows will tolerate.
Re: 6502bench SourceGen disassembler updated [message #387657 is a reply to message #387609] Mon, 07 October 2019 20:58 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: James Davis

I am not using Aero effects. I am using Windows 7 Ultimate 64-bit made to look like Classic Windows 95~98se with a Classic Start Menu. [I am a square!-box/ASCII-text kind of guy (;-D). But I do like WordPad and RTF, too.]

My preferred Apple II disassembler was the Mini-Assembler/Disassembler. And, my preferred Apple II assembler was EDASM. So, I suppose you should just stick to ASCII text for comments and notes. I prefer the Merlin format in SourceGen because it is closest to EDASM. Can you add an EDASM format? It is very similar to the original Apple II Mini-Assembler/Disassembler format.
Re: 6502bench SourceGen disassembler updated [message #387658 is a reply to message #387609] Mon, 07 October 2019 20:58 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: James Davis

On Sunday, October 6, 2019 at 2:12:12 PM UTC-7, fadden wrote:
> On Sunday, October 6, 2019 at 1:01:38 AM UTC-7, James Davis wrote:
>> In the disassembly window, at the bottom, when the slider bar is
>> not all the way to the left, and/or any amount or all the way to
>> the right, double-clicking on a column (e.g., the label-column*)
>> brings up the action-window for the column just to the right of
>> the column double-clicked (e.g., the attribute-column*,
>> respectively);
>
> That's a bug. WPF (Windows Presentation Foundation) is based on the philosophy that hard things should be possible, and easy things should be really hard. One manifestation of this is the absence of "what row and column was clicked on" methods in ListView and DataGrid. My implementation failed to take the horizontal scroll position into account.
>
> Fixed.
>
>> In the disassembly window, I keep expecting the (long or short)
>> comments and notes to work like in a word-processor (e.g.,
>> NotePad, MetaPad or {my preferred} WordPad)
>
> I have a "to do" list item for in-place editing of labels and comments. There might be a way to convince WPF to do it for me, but it'll likely require using a fully custom control.
>
> The main disassembly window is a WPF ListView control with some style changes, mostly to have text that extends across multiple columns. This was sufficiently difficult that I created a separate github project just to play with it (https://github.com/fadden/DisasmUiTest). I'm not yet experienced with WPF to know how hard in-place editing would be.
>
>> A quick double-click should not be necessary for editing
>> existing (long or short) comments and notes; two single-clicks
>> should also work within the same field {of lines--for "multi-
>> line" comments and notes} (no matter where the mouse/cursor has
>> been between single-clicks).
>
> I think that would make sense for in-place editing. I'm picturing the way Windows lets you rename a file by selecting it, and then doing a second single click. I don't think it feels right when the action is to open an editor window though.
>
>> There needs to be a way [using Windows' standard (large) Color
>> selector dialog] to set some or all the colors used in the
>> application to user preferred colors (e.g., all the different
>> highlighting colors, window background color, etc.) vs. the
>> Users' windows-theme or Windows' standard colors; one or the
>> other of which should be selectable as a base to start with (or
>> to build upon).
>
> I have a long-standing request for a "dark" theme. Seems like it should be straightforward in WPF, but I haven't figured it out yet.
>
>> [For example, I would prefer all the 'SELECTED' field-
>> highlighting to be the same (e.g., dark background with light
>> lettering {e.g., blue/white}), not the (light background and
>> dark lettering) colors you have enabled for long-comments and
>> notes.--{No offense meant!}]
>
> That's another bug. The custom style that allows me to have long comments extend across multiple columns also requires me to define how highlighting works. In Win10, the system-wide theme has essentially no effect on the app, so my selected colors look the same as everything else in the list. I tried it just now on Win7, and the "high contrast" system theme significantly altered all of the colors in SourceGen, except for the ones in the replacement style. Ugh.
>
> So I need to figure out how to get the appropriate color out of the system style. There's some chance that the Win7 Aero stuff behaves in a totally different way from what Win10 uses, which would make this even more fun.
>
>> Allow fonts (for individual words and characters) to be normal,
>> bold, italic, underlined, struck-through, and subscripted or
>> superscripted; like in a word-processor (e.g., WordPad {RTF});
>> especially in comments and notes.
>
> This is doable, but I'm a little hesitant because one of the primary goals of SourceGen is to generate plain text source code, which means either stripping the formatting (which could lose information, e.g. the fact that text was struck out) or generating comments with RTF format strings (which is not especially easy for humans to read). It's useful for HTML output, but I'd rather have people express themselves within the confines of a fixed-width Unicode font so that things look the same everywhere.
>
>> In the disassembly window, at the top, the column headers should
>> also be re-adjustable using the standard Windows ctrl-+, shift-
>> +, and non-standard ctrl-shift-+ key-combinations
>
> I'm unclear as to how standard those are in terms of column widths. For example, in Chrome, those change the page "zoom" level.
>
>> It would be nice to be able to insert extra blank-lines, long-
>> comments and notes, above and/or below other lines and at the
>> very end, in the disassemblies.
>>
>> And/or, it would be nice to be able to drag-&-drop blank-lines,
>> long-comments and notes, up or down in the disassemblies.
>
> This is doable. The reason it's not done now is that everything is associated with a file offset, and you only get one of each thing. So if you add a long comment, that comment is associated with a specific byte in the file, and is always displayed above that byte.
>
> The mechanism could be made more general, e.g. multiple comments per offset, which can be placed above or below. Blank lines can be fiddled with. I think drag & drop or some other affordance would be necessary, since tweaking with the cosmetic aspects is awkward if you have to do it through a dialog window.
>
>> A line space is achievable as a single space in a long-comment
>> or note, but they have inline artifacts!
>
> It would be easy to treat an empty single-line long comment as an explicit blank line. There's a potential issue in that it's hard to tell it apart from the automatically generated blank lines. (I could have a "don't put leading semicolons on blank lines" checkbox.)
>
>> To put anything below the last line, one would have to pad the
>> original binary/hexadecimal machine code with an extra zero
>> byte, and remove it after editing the disassembly. Would the
>> edit remain or disappear? I will have to test this.
>
> The .dis65 file includes the file length and CRC, so you'd have to update those values before SourceGen would accept the altered file. It would then notice that you have something with an invalid offset, and ignore it. So.... don't do this.
>
>> It would be nice to be able to load an ASCII text of another
>> disassembly created by other means and have SourceGen be able to
>> use it (detecting which assembler format to use, too), with or
>> without a binary/hexadecimal machine code file to go with it.
>
> This would be best done with a tool that generated a .dis65 file. The goal of such a thing would be to facilitate conversion of source code from one assembler to another by using SourceGen as a least-common-denominator format. The trouble is that SourceGen is far less expressive than a typical assembler, and you'd lose a lot. But if you can keep most of the labels and comments, that'd be an easier place to start from.
>
>> The settings keep resetting/reverting to 64tass on the last
>> three tabs. They do not stay set to Merlin from session to
>> session.
>
> This isn't a bug so much as it's just bad UI design. It annoys me too.
>
> If you launch SourceGen v1.0, the "Quick Set" box has three buttons, "Default", "cc65", and "Merlin 32". You click the button, and the various fields get reconfigured. Simple.
>
> In SourceGen v1.1, I added support for 64tass, and realized that my previous scheme didn't scale well, and made it difficult to add new assemblers. So instead of a pair of buttons, you have a pop-up menu, with a "Set" button to actually apply the values.
>
> The problem, as you have noted, is that it looks like something is configured for 64tass, even though in practice nothing happens when you select a different assembler from the pop-up menu.
>
> So the question is how to change the UI to make sense. One possibility is to get rid of "Set" and just make the combo box live: selecting a different assembler immediately updates all values. A new entry, "Custom", would hold the state of any recent edits. The pop-up would either show the name of the assembler (if all fields match) or "custom" (if any don't). So as soon as you make a change to any field, it switches to "custom" and obliterates any previously established custom setting... but I don't see a way around doing so that doesn't require wrapping a heavyweight customization UI around something that should be simple.
Re: 6502bench SourceGen disassembler updated [message #387659 is a reply to message #387656] Mon, 07 October 2019 21:14 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: James Davis

On Monday, October 7, 2019 at 5:53:46 PM UTC-7, fadden wrote:
> On Monday, October 7, 2019 at 5:36:13 PM UTC-7, James Davis wrote:
>> 1. *.dis65 files do not work (reload into SourceGen) after being renamed (e.g.,
>> "Apple2.ROM.dis65" to "Apple2Plus.ROM.dis65" {SourceGen says it does not
>> exist!}).
>>
>> 2. *.dis65 files do not work (reload into SourceGen) within a folder named
>> "Apple II+"; but they will work after renaming the folder to "Apple II Plus"
> [...]
>
>
> I tried this a few different ways and didn't have any problems, so we're apparently doing different things. I will point out that the "Recent Projects" menu item, and the two recent project buttons on the initial screen, do not update when files move around in the filesystem. So if you rename or relocate a project, you will need to File > Open it rather than using the quick-load button.
>
> This can be a little confusing because the buttons on the main screen only show the filename, so if you've opened something in two different places it's not immediately obvious which one is which. The Recent Projects menu does show full paths, so check and see if that matches up.
>
> (It now occurs to me that the existing UI is dumb, because it's showing you a quick-load button for a project that isn't there. I'll fix that.)
>
> The only requirement on filenames should be that the .dis65 file and the data file live in the same directory, and have the same name (just without ".dis65" for the data file). If that's not the case you'll get the opportunity to locate the file manually. Otherwise you should be able to call it anything Windows will tolerate.

No, that's not it. I am talking about double-clicking the *.dis65 files to start a fresh instance of SourceGen (e.g., with my reg-edits {submitted above}) [with no other instances of SourceGen running]. It must have something to do with the "+" in the folder name, the double-dots in the filenames, long filenames, or long pathnames (my path/filename is pretty long). It is probably MicroSoft-Windows' fault!
Re: 6502bench SourceGen disassembler updated [message #387660 is a reply to message #387659] Mon, 07 October 2019 21:19 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: James Davis

On Monday, October 7, 2019 at 6:14:37 PM UTC-7, James Davis wrote:
> On Monday, October 7, 2019 at 5:53:46 PM UTC-7, fadden wrote:
>> On Monday, October 7, 2019 at 5:36:13 PM UTC-7, James Davis wrote:
>>> 1. *.dis65 files do not work (reload into SourceGen) after being renamed (e.g.,
>>> "Apple2.ROM.dis65" to "Apple2Plus.ROM.dis65" {SourceGen says it does not
>>> exist!}).
>>>
>>> 2. *.dis65 files do not work (reload into SourceGen) within a folder named
>>> "Apple II+"; but they will work after renaming the folder to "Apple II Plus"
>> [...]
>>
>>
>> I tried this a few different ways and didn't have any problems, so we're apparently doing different things. I will point out that the "Recent Projects" menu item, and the two recent project buttons on the initial screen, do not update when files move around in the filesystem. So if you rename or relocate a project, you will need to File > Open it rather than using the quick-load button.
>>
>> This can be a little confusing because the buttons on the main screen only show the filename, so if you've opened something in two different places it's not immediately obvious which one is which. The Recent Projects menu does show full paths, so check and see if that matches up.
>>
>> (It now occurs to me that the existing UI is dumb, because it's showing you a quick-load button for a project that isn't there. I'll fix that.)
>>
>> The only requirement on filenames should be that the .dis65 file and the data file live in the same directory, and have the same name (just without ".dis65" for the data file). If that's not the case you'll get the opportunity to locate the file manually. Otherwise you should be able to call it anything Windows will tolerate.
>
> No, that's not it. I am talking about double-clicking the *.dis65 files to start a fresh instance of SourceGen (e.g., with my reg-edits {submitted above}) [with no other instances of SourceGen running]. It must have something to do with the "+" in the folder name, the double-dots in the filenames, long filenames, or long pathnames (my path/filename is pretty long). It is probably MicroSoft-Windows' fault!

Don't worry about it. Replacing the "+" with " plus" in the folder name has fixed the problem. ...And, matching the source and disassembly filenames..
Re: 6502bench SourceGen disassembler updated [message #387701 is a reply to message #385700] Tue, 08 October 2019 16:28 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: James Davis

6502bench SourceGen Quirks & Replies [Edited]:

> On Sunday, October 6, 2019, Andy McFadden wrote:
>> On Sunday, October 6, 2019, James Davis wrote:

------------------------------------------------------------ ----------

>> In the disassembly window, at the bottom, when the slider bar is
>> not all the way to the left, and/or any amount or all the way to
>> the right, double-clicking on a column (e.g., the label-column*)
>> brings up the action-window for the column just to the right of
>> the column double-clicked (e.g., the attribute-column*,
>> respectively);

> That's a bug. WPF (Windows Presentation Foundation) is based on
> the philosophy that hard things should be possible, and easy things
> should be really hard. One manifestation of this is the absence of
> "what row and column was clicked on" methods in ListView and
> DataGrid. My implementation failed to take the horizontal scroll
> position into account.

> Fixed.

Thanks.

------------------------------------------------------------ ----------

>> In the disassembly window, I keep expecting the (long or short)
>> comments and notes to work like in a word-processor (e.g.,
>> NotePad, MetaPad or {my preferred} WordPad)

> I have a "to do" list item for in-place editing of labels and
> comments. There might be a way to convince WPF to do it for me, but
> it'll likely require using a fully custom control.

> The main disassembly window is a WPF ListView control with some
> style changes, mostly to have text that extends across multiple
> columns. This was sufficiently difficult that I created a separate
> github project just to play with it
> (https://github.com/fadden/DisasmUiTest). I'm not yet experienced
> with WPF to know how hard in-place editing would be.

>> A quick double-click should not be necessary for editing
>> existing (long or short) comments and notes; two single-clicks
>> should also work within the same field {of lines--for "multi-
>> line" comments and notes} (no matter where the mouse/cursor has
>> been between single-clicks).

> I think that would make sense for in-place editing. I'm picturing
> the way Windows lets you rename a file by selecting it, and then
> doing a second single click. I don't think it feels right when the
> action is to open an editor window though.

I think it would feel better than not having anything happen at all!
Something is better than nothing. Opening an editor window is better
than being surprised when nothing at all happens; especially when one
is mentally elsewhere, ahead of the action, waiting for it to happen,
so ready to start editing the line(s) that one "can't hardly wait!"
[:-)] And, it should be easier to implement than in-place editing.

------------------------------------------------------------ ----------

>> There needs to be a way [using Windows' standard (large) Color
>> selector dialog] to set some or all the colors used in the
>> application to user preferred colors (e.g., all the different
>> highlighting colors, window background color, etc.) vs. the
>> Users' windows-theme or Windows' standard colors; one or the
>> other of which should be selectable as a base to start with (or
>> to build upon).

> I have a long-standing request for a "dark" theme. Seems like it
> should be straightforward in WPF, but I haven't figured it out yet.

>> [For example, I would prefer all the 'SELECTED' field-
>> highlighting to be the same (e.g., dark background with light
>> lettering {e.g., blue/white}), not the (light background and
>> dark lettering) colors you have enabled for long-comments and
>> notes.--{No offense meant!}]

> That's another bug. The custom style that allows me to have long
> comments extend across multiple columns also requires me to define
> how highlighting works. In Win10, the system-wide theme has
> essentially no effect on the app, so my selected colors look the
> same as everything else in the list. I tried it just now on Win7,
> and the "high contrast" system theme significantly altered all of
> the colors in SourceGen, except for the ones in the replacement
> style. Ugh.

> So I need to figure out how to get the appropriate color out of
> the system style. There's some chance that the Win7 Aero stuff
> behaves in a totally different way from what Win10 uses, which
> would make this even more fun.

Win7 themes are kept in the "%UserProfile%\AppData\Local\Microsoft
\Windows\Themes\" folder (e.g., "Custom.theme" and others). Which
theme is currently in force is in the Windows Registry at key/value:
" HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\ Themes "/
"CurrentTheme" and the data is a drive:\path\filename. You probably
need to use the "[VisualStyles]" data section of the current theme
file.

------------------------------------------------------------ ----------

>> Allow fonts (for individual words and characters) to be normal,
>> bold, italic, underlined, struck-through, and subscripted or
>> superscripted; like in a word-processor (e.g., WordPad {RTF});
>> especially in comments and notes.

> This is doable, but I'm a little hesitant because one of the
> primary goals of SourceGen is to generate plain text source code,
> which means either stripping the formatting (which could lose
> information, e.g., the fact that text was struck out) or generating
> comments with RTF format strings (which is not especially easy for
> humans to read). It's useful for HTML output, but I'd rather have
> people express themselves within the confines of a fixed-width
> Unicode font so that things look the same everywhere.

Forget it. It is a bad idea.

------------------------------------------------------------ ----------

>> In the disassembly window, at the top, the column headers should
>> also be re-adjustable using the standard Windows ctrl-+, shift-
>> +, and non-standard ctrl-shift-+ key-combinations

> I'm unclear as to how standard those are in terms of column
> widths. For example, in Chrome, those change the page "zoom" level.

I got used to this in Windows Explorer and in most of the NirSoft
Utilities that show detailed listings of data. The non-standard ctrl-
shift-+ key-combination is my idea exclusively for SourceGen to reset
column widths to the basic standard it starts with or what is set in
the SourceGen settings. [I do not use any Chromium based products.
I like Microsoft's Internet Explorer and Windows Live Mail.]

------------------------------------------------------------ ----------

>> It would be nice to be able to insert extra blank-lines, long-
>> comments and notes, above and/or below other lines and at the
>> very end, in the disassemblies.
>>
>> And/or, it would be nice to be able to drag-&-drop blank-lines,
>> long-comments and notes, up or down in the disassemblies.

> This is doable. The reason it's not done now is that everything is
> associated with a file offset, and you only get one of each thing.
> So if you add a long comment, that comment is associated with a
> specific byte in the file, and is always displayed above that byte.

> The mechanism could be made more general, e.g., multiple comments
> per offset, which can be placed above or below. Blank lines can be
> fiddled with. I think drag & drop or some other affordance would be
> necessary, since tweaking with the cosmetic aspects is awkward if
> you have to do it through a dialog window.

>> A line space is achievable as a single space in a long-comment
>> or note, but they have inline artifacts!

> It would be easy to treat an empty single-line long comment as an
> explicit blank line. There's a potential issue in that it's hard to
> tell it apart from the automatically generated blank lines. (I
could
> have a "don't put leading semicolons on blank lines" checkbox.)

>> To put anything below the last line, one would have to pad the
>> original binary/hexadecimal machine code with an extra zero
>> byte, and remove it after editing the disassembly. Would the
>> edit remain or disappear? I will have to test this.

> The .dis65 file includes the file length and CRC, so you'd have to
> update those values before SourceGen would accept the altered file.
> It would then notice that you have something with an invalid offset,
> and ignore it. So... don't do this.

Why don't you add (a choice to have) an extra line at the end of the
disassembly listing that has the mnemonic "END" and all the rest of
the editable fields that code lines have. Then one could edit its
short-comment or put a long-comment or a note above it, if so
desired. It would not need an address, nor some other things, so you
could leave those fields blank or filed with stars. For example:

**************************** END *****************************

------------------------------------------------------------ ----------

>> It would be nice to be able to load an ASCII text of another
>> disassembly created by other means and have SourceGen be able to
>> use it (detecting which assembler format to use, too), with or
>> without a binary/hexadecimal machine code file to go with it.

> This would be best done with a tool that generated a .dis65 file.
> The goal of such a thing would be to facilitate conversion of source
> code from one assembler to another by using SourceGen as a least-
> common-denominator format. The trouble is that SourceGen is far
less
> expressive than a typical assembler, and you'd lose a lot. But if
> you can keep most of the labels and comments, that'd be an easier
> place to start from.

Okay, that should be your second 6502bench tool: a translator that
takes a pre-existing ASCII/ANSI text file, a disassembly listing
(with or without the address, code bytes, line numbers, and other
data that preceedes the label field), and creates a .dis65 file from
it. (It should also work with SourceGen's text-file exports.) [But,
can it be done without a binary-source file? The tool might also have
to generate one for SorceGen to work with; which means the tool would
also be an assembler (e.g., "The Fadden Assembler").]

Your third 6502bench tool should do something similar for .sym65;
translating from pre-existing ASCII/ANSI text file, symbol tables
(e.g., AppleWin {1.11.2.1}'s Apple2e.sym) and/or disassembly
listings (e.g., their "Equate Tables"). [Should be a part of "The
Fadden Assembler"!]

[Call the whole thing "The Fadden Editor/Assembler/Disassembler
(FEDASM65)"; or keep it as "6502bench" if you like.]

[Then I could re-create all my "Apple II Memory Equates for Assembly
Programmers" text-edits in SourceGen. I have added quite a lot to
some of the published Apple II disassembly listing I have. I have
been re-analyzing them off and on for the last couple of years. They
are verbosely commented; especially the 'Equates' documents; with
quite a few new (undocumented) entry points (for m/l programming
{tricks}) I have discovered. They are all works in progress.]

------------------------------------------------------------ ----------

>> The settings keep resetting/reverting to 64tass on the last
>> three tabs. They do not stay set to Merlin from session to
>> session.

> This isn't a bug so much as it's just bad UI design. It annoys me
> too.

> If you launch SourceGen v1.0, the "Quick Set" box has three
> buttons, "Default", "cc65", and "Merlin 32". You click the button,
> and the various fields get reconfigured. Simple.

> In SourceGen v1.1, I added support for 64tass, and realized that
> my previous scheme didn't scale well, and made it difficult to add
> new assemblers. So instead of a pair of buttons, you have a pop-up
> menu, with a "Set" button to actually apply the values.

> The problem, as you have noted, is that it looks like something is
> configured for 64tass, even though in practice nothing happens when
> you select a different assembler from the pop-up menu.

> So the question is how to change the UI to make sense. One
> possibility is to get rid of "Set" and just make the combo box live:
> selecting a different assembler immediately updates all values. A
> new entry, "Custom", would hold the state of any recent edits. The
> pop-up would either show the name of the assembler (if all fields
> match) or "custom" (if any don't). So as soon as you make a change
> to any field, it switches to "custom" and obliterates any previously
> established custom setting... but I don't see a way around doing so
> that doesn't require wrapping a heavyweight customization UI around
> something that should be simple.

I see in my "C:\Program Files\6502bench\SourceGen-settings" (no
extension) file, that it only has Merlin listed:

"fmt-expression-mode":"Merlin",
"asm-config-Merlin32":"{\"ExecutablePath\":\"\",\"ColumnWidths\ ":
[11,4,15,50]}",
"srcgen-default-asm":"Merlin32",

And, all my disassemblies are in Merlin format, so "64tass" is just
an annoyance.

------------------------------------------------------------ ----------
Re: 6502bench SourceGen disassembler updated [message #387702 is a reply to message #387701] Tue, 08 October 2019 17:01 Go to previous message
Anonymous
Karma:
Originally posted by: fadden

6502bench SourceGen v1.4-dev1 is now available. Key features:

- Platform and project symbols now have explicit widths.
- Extension script formatting capabilities have been expanded.
- ProDOS 8 symbol file and script have been enhanced.

Platform and project symbols are used to define labels for addresses outside the project file, like zero-page locations, jump vectors, and ROM entry points. Being able to identify pointers, vectors, and multi-byte tables makes the auto-disassembly more accurate when something references PTR+1 or BUFFER+23.

After adding widths to the symbol definitions, I was able to remove the formatting from about 110 locations in the Applesoft disassembly, mostly for access to floating-point storage locations like FAC (6 bytes). This also allowed me to fully describe the ProDOS 8 MLI globals page, so those definitions have been added to the symbol file that ships with SourceGen.

This may require updates to existing projects with project symbols, as the external symbols were effectively being treated as 3 bytes wide in v1.3. So some things that used to pick up "PTR+1" won't anymore until you define PTR as 2 bytes.


The set of inline data format options available to extension scripts has been expanded to include strings. Also, scripts can now get at project and user symbols (i.e. labels on things inside the file), and can query the data structure that defines the mapping of offsets to addresses. The benefits of these changes can be demonstrated with an example.

Consider Glen Bredon's "Cat Doctor" utility. Given this P8 Open call:

2154: 20 00 bf jsr P8_MLI
2157: c8 .dd1 P8_OPEN
2158: bf 21 .dd2 L21BF

You could double-click on the .dd2 to jump to the data area, which looks like this:

21bf: 03 L21BF .dd1 $03
21c0: cf .dd1 $cf
21c1: 21 .dd1 $21
21c2: 00 .dd1 $00
21c3: b0 .dd1 $b0
21c4: 00 L21C4 .dd1 $00

The updated ProDOS 8 script converts $21bf to a file offset, and formats the data at that location automatically. It now looks like this:

21bf: 03 L21BF .dd1 3
21c0: cf 21 .dd2 L21CF
21c2: 00 b0 .dd2 $b000
21c4: 00 L21C4 .dd1 0

Of particular note is the second line, which is now correctly recognized as a pointer to a pathname buffer, and has a label generated automatically.

This is handy, but the real trick when poking around in Cat Doctor is the inline string function. Calls to a certain address are followed by string data, using the same sort of mechanism the ProDOS MLI does to skip past the function code and param block pointer.

With the new formatting capabilities, if you see a JSR to the string-print code, you can format the block of data that follows the JSR as an inline null-terminated string, and the disassembler will step over it. Hard-coding locations into the extension script is annoying, so we use the label lookup feature to avoid doing so.

Given this:

0872: 20 8c 22 jsr $228c
0875: 21 c3 and ($c3,x)
0877: c1 d4 cmp ($d4,x)
0879: a0 c4 ldy #$c4
087b: cf c3 d4 cf+ .str “OCTOR 6.8”,$8d
0885: 19 .dd1 $19
0886: c3 ef f0 f9+ .str “Copyright 1990 by Glen Bredon”,$8d,$8d
08a6: 00 .dd1 $00
08a7: 84 .dd1 $84
08a8: da .dd1 $da

If you add an appropriate script (such as SourceGen/Examples/Scripts/InlineNullTerm.cs), and set the label at $228c to "PrintInlineZString", SourceGen will disassemble this to:

0872: 20 8c 22 jsr PrintInlineZString
0875: 21 c3 c1 d4+ .zstr $21,“CAT DOCTOR 6.8”,$8d,$19,“Copyright 1990 by Glen Bredon”
+ $8d,$8d
08a7: 84 da sty $da

(You may have to hit F5 to refresh after editing the label. This is due to SourceGen trying to be efficient and only do a partial re-analysis after a label change. I'm still trying to figure out a good way to handle this.)
  Switch to threaded view of this topic Create a new topic Submit Reply
Previous Topic: Mountain Computer Music System fix
Next Topic: ProDOS port announce
Goto Forum:
  

-=] Back to Top [=-
[ Syndicate this forum (XML) ] [ RSS ] [ PDF ]

Current Time: Thu Oct 17 01:19:54 EDT 2019

Total time taken to generate the page: 0.01008 seconds