6502bench SourceGen v1.7.4 is now available.

Changes since the previous minor release:
* Fixed "last offset" calculations in Apple II hi-res visualizer (issue #94).
* Reworked Apple IIgs $Cxxx I/O location constants. Fixed 24-bit MULTI_MASK.
* Changed HTML exporter to generate HTML 5 (was outputting XHTML).
* Minor UI bug fixes.
* Moved tutorials to web site. Expanded text and added many screen shots.

The project web site is https://6502bench.com/. Source code and pre-built Windows binaries are available from https://github.com/fadden/6502bench/releases

-----

I finally got around to re-working the tutorials to be a mix of text and screen shots. (Michael's post recommending this was written back in February.... of 2020.) Previously, you really had to be following along in the program for anything to make sense. Hopefully now it's something you can just read.

I used this as an opportunity to play with "responsive web design", so it should be readable on mobile devices or really skinny monitors if that's your thing.

Great news, Andy!

What has changed for Apple IIgs $Cxxx I/O location constants?

Thanks

On Wednesday, June 9, 2021 at 12:39:28 AM UTC-7, Enrico wrote:
> What has changed for Apple IIgs $Cxxx I/O location constants?

One .sym65 file has constants for the $Cxxx locations for all Apple II systems. I had created another for the $E0/Cxxx constants, with names like "KBDSTRB_GS". Apparently I forgot that the I/O locations are mapped into banks $E0 *and* $E1. The update creates mappings for both banks, with names like KBDSTRB_E0 and KBDSTRB_E1.

It's possible to have a single file with a MULTI_MASK statement (which is used to define I/O locations that are mirrored across multiple addresses), but I thought the output looked better with explicit "_E0"/"_E1". SourceGen still lacks a mapping for $01/Cxxx, but I haven't seen anything reference those in 16-bit code.

Relevant change:
https://github.com/fadden/6502bench/commit/d3e00b23429e65baa7ead7519ed044037adf10a2

New on the web site: I "ported" the listings from _Reference Manual Addendum: Monitor ROM Listings, For //e Only_. These are the monitor and 80-column firmware from the *unenhanced* Apple //e.

https://6502disassembly.com/a2-rom/Unenh_IIe_F8ROM.html
https://6502disassembly.com/a2-rom/Unenh_IIe_80col.html

TIL that ESC-R was a thing, and that the 80-column firmware would copy the F8 ROM into the language card if it couldn't find the monitor.

Andy,
I just wanted to inform you that I had to install Windows 8.1 SDK and .NET Framework 4.7.2 in order to be able to run 6502bench on Windows 7.
Perhaps you might want to point that out in the docs.

On Friday, June 18, 2021 at 11:00:07 AM UTC-7, Enrico wrote:
> I just wanted to inform you that I had to install Windows 8.1 SDK and .NET Framework 4.7.2 in order to be able to run 6502bench on Windows 7.
> Perhaps you might want to point that out in the docs.

..NET framework is a known thing. I'm still not sure how Win7 manages to show up without it, but clearly it can.

With regard to the SDK, are you building SourceGen with Visual Studio or just running the pre-built version? i.e. is it this situation:
https://stackoverflow.com/questions/43704734/how-to-fix-the-error-windows-sdk-version-8-1-was-not-found

I'm late on replying because I did a few tests first.

I have two Windows 7 machines.
- The first one with Visual Studio and all its SDK installed just needed .NET Framework 4.7.2 in order to be able to run 6502bench
- The other machine had no Visual Studio and I had to install both Windows 8.1 SDK and .NET Framework 4.7.2 for 6502bench to work

On Windows 10 I was able to run 6502bench with only .Net 4.6.2 installed and nothing else, even though I had to update Windows 10 to its latest version. (on the earlier Windows 10 release 1510 that I had, 6502bench wouldn't work).

Thank you

.....and I'm running the prebuilt version, of course.

On Thursday, June 24, 2021 at 11:33:58 PM UTC-7, Enrico wrote:
> I have two Windows 7 machines.
> - The first one with Visual Studio and all its SDK installed just needed ..NET Framework 4.7.2 in order to be able to run 6502bench
> - The other machine had no Visual Studio and I had to install both Windows 8.1 SDK and .NET Framework 4.7.2 for 6502bench to work

I do my testing on a Win7 Professional virtual machine, with a system that has basically nothing but Chrome and CiderPress installed, and I didn't have to explicitly install either .NET Framework or an SDK. I'm not even sure how one installs the Windows 8.1 SDK without Visual Studio. (The program list in Settings shows CiderPress, Chrome, Microsoft .NET Framework 4.8, Edge, and the Oracle VM Guest Additions. I believe Edge was delivered by auto-update, and probably .NET Framework as well, since I don't remember explicitly downloading v4.8.)

> On Windows 10 I was able to run 6502bench with only .Net 4.6.2 installed and nothing else, even though I had to update Windows 10 to its latest version. (on the earlier Windows 10 release 1510 that I had, 6502bench wouldn't work).

My primary system is Win10, with the latest updates. There's nothing in the 6502bench code that depends on a specific version of Windows, so my guess would be something in .NET Framework was mismatched.

I take it you have the automatic Windows updates disabled on your systems?

6502bench SourceGen v1.7.5 is now available.

Changes since the previous minor release:
* Added symbols for Super Nintendo Entertainment System (SNES) [@absindx].
* Added symbols for Oric Atmos [@dma-coco].
* Updated ACME code generation for assembler v0.97.
* Loosened restrictions on string formatting (issue #100). Allow single-character DCI strings (issue #102).
* Fixed odd keyboard behavior in code list (issue #105).
* Fixed local variable width limitation (issue #96).
* Fixed table formatting problem (issue #103).
* Fixed 64tass source generation for non-loadable files (issue #98) and a 65816 corner case (issue #104).
* Fixed "goto address" behavior in overlapping segments.
* Fixed minor issue in .sym65 parser.

The project web site is https://6502bench.com/. Source code and pre-built Windows binaries are available from https://github.com/fadden/6502bench/releases

-----

The update to ACME source generation is significant because v0.97 is incompatible with all existing ACME source files that have a backslash ('\') in a string literal. The assembler now recognizes character escapes like "\n" by default. (The previous behavior can be restored with a command-line flag.) SourceGen will generate correct sources for whichever version you have installed, defaulting to v0.97 if ACME is not present.

6502bench SourceGen v1.8.0 is now available.

Changes since the previous release:
* Reworked the way addresses are handled (issue #107):
* Replaced linear list of start points with a hierarchy of nested address regions.
* Added non-addressable areas.
* Added region pre-labels (issue #109).
* Added relative addressing.
* Added "uninitialized data" pseudo-op.
* Added quick-set button to string/char delimiter configuration tab in app settings.
* Added "daily tips" to start screen.
* Added "remove formatting" action.
* Added "StdInline" extension script, for common inline data formats.
* Added Atari DVG visualizer (Lunar Lander, Asteroids).
* Updated reference manual formatting.
* Fixed resize crash (issue #108).
* Fixed editing of high-ASCII L1 strings (issue #110).

The project web site is https://6502bench.com/. Source code and pre-built Windows binaries are available from https://github.com/fadden/6502bench/releases

-----

The big change is to the way address regions are handled. Somebody showed me a situation with multiple overlapping segments that SourceGen couldn't handle, because the mapping of absolute address to file offset was ambiguous.. The ambiguity can be managed by forming address regions into hierarchical form.

Some assemblers (64tass and ACME) have explicit support for this. For assemblers that don't, like Merlin 32, the hierarchy is "flattened" when generating the source code.

Merlin-style behavior, where ORG starts a region that continues until you hit the next ORG, is still available: when defining a region you can pick whether the end point is "fixed" or "floating". The UI got a little more complicated, but I think it works.

I also fixed the thing where you can't put a label on both the "before" and "after" addresses of relocated code.

I also added "non-addressable" regions. This is useful for file headers that are examined by the system loader and then discarded.

There are a few new things at the 6502disassembly.com site...

A while back somebody was poking at the ProSel-8 CAT.DOCTOR utility and asked me to peek at it. I remembered it having a somewhat twisty initialization, relocating bits and pieces of itself, and used inline data for ProDOS/SmartPort calls and strings. The code is actually split into two files, CAT..DOCTOR and CD.EXT, which call into each other; the latter is only loaded on 128KB systems, and is stored in auxmem.

This seemed like a good exercise for the new address region code, so I concatenated the two files and unwound the relocations and inline data. I didn't do much of anything beyond that -- 99.9% of the project is uncommented. Because there's not much to see, it's not linked from the main page, but you can find it here: https://6502disassembly.com/a2-prosel8/

In a similar vein, I found a pretty full disassembly of Metroid for the NES, which is a 128KB cartridge with multiple overlapping segments. Again, didn't do much with it: https://6502disassembly.com/nes-metroid/

I also "ported" a disassembly of the coin-op Asteroids game, which uses the new DVG visualizer. This one does appear on the main page: https://6502disassembly.com/va-asteroids/

On 11/14/21 1:02 PM, fadden wrote:
> There are a few new things at the 6502disassembly.com site...
>
> A while back somebody was poking at the ProSel-8 CAT.DOCTOR utility and
> asked me to peek at it. I remembered it having a somewhat twisty
> initialization, relocating bits and pieces of itself, and used inline data
> for ProDOS/SmartPort calls and strings. The code is actually split into
> two files, CAT.DOCTOR and CD.EXT, which call into each other; the latter is
> only loaded on 128KB systems, and is stored in auxmem.
>
> This seemed like a good exercise for the new address region code, so I
> concatenated the two files and unwound the relocations and inline data. I
> didn't do much of anything beyond that -- 99.9% of the project is
> uncommented. Because there's not much to see, it's not linked from the
> main page, but you can find it here:
> https://6502disassembly.com/a2-prosel8/

Weren't the sources for Glen's programs released after his death?

On Sunday, November 14, 2021 at 2:21:12 PM UTC-8, Steven Hirsch wrote:
> Weren't the sources for Glen's programs released after his death?

Sort of?

https://groups.google.com/g/comp.sys.apple2/c/btUHqGNLuvc

"All the 8-bit stuff is MIA. There have been a number of things I would've liked to have fixed over the years, but I think it's all gone for good."

You can find a PROSEL.BXY in various locations, e.g. pub/apple_II/images/gs/utils/glenbredon_prosel_sourcecode_documentation.zip on asimov, but it all seems to be ProSel-16.

Steven Hirsch wrote:
>
> Weren't the sources for Glen's programs released after his death?
>

Here are the news articles from 2000:

ANN. All of Glen Bredon's Apple software, src. codes and photo CD's - now PD
https://macgui.com/usenet/?group=1&id=178597
https://macgui.com/usenet/?group=1&id=178599#msg

Note that it's our illustrious Mr. Turley again. :-p

Confusion ensues over status of Merlin software
https://macgui.com/usenet/?group=1&id=178911

D Finnigan wrote:
>
>
> Note that it's our illustrious Mr. Turley again. :-p

Wow, just think: all those people running around flaming Dr. Tom in the
mid-to-late 90s and 2000s are now 20 to 25 years older.... :-/

If you were a 25-year-old flaming Turley in 1996 for his sector-editing
shenanigans, you're now about 50. :-0

And Turley wasn't a spring chicken at the time, either, from the impression
I've gotten.

When generating a SourceGen project using the OMF File Viewer there's an option to "Offset segment start by $0100". I thought that it was a good idea at first, but in the end I decided that I wanted to revert back to a zero offset situation, because I was going crazy while comparing SourceGen code with GsBug listings. Unfortunately this isn't possible in SourceGen, therefore I figured out a way to convert the project to a zero offset situation. Manually.
I hope that the procedure is correct. Everything seems to be working fine, so far. So I decided to post it here in case anyone needs it or wants to point out any error in my procedure.

Conversion from $0100 relocated disassembly to $000 offset:

- Open the OMF File Viewer again and generate another project from the same program, but without the relocation offset option checked. Then, replace the .ld file from the original project with the .ld file from the new project
- Manually change the .dis65 file from the original project:

1. Replace the "FileDataCrc32" from the original .dis65 file with the Crc from the new .dis65 file

2. Replace the whole "AddressMap" section from the original .dis65 file with the same section taken from the new project

3. In the "UserLabels" section of the original project, change all of the "Value:" tags by subtracting 256 to their original value
(I created an Excel sheet just for doing that!)

4. Replace the whole "RelocList" section from the original file with the same section taken from the new .dis65 file

5. Modify any relevant Text description at the beginning of code blocks (Well, actually this can be done in the SourceGen app, too)

On Monday, November 15, 2021 at 5:16:26 AM UTC-8, ero...@gmail.com wrote:
> When generating a SourceGen project using the OMF File Viewer there's an option to "Offset segment start by $0100". I thought that it was a good idea at first, but in the end I decided that I wanted to revert back to a zero offset situation, because I was going crazy while comparing SourceGen code with GsBug listings. Unfortunately this isn't possible in SourceGen, therefore I figured out a way to convert the project to a zero offset situation. Manually.

SourceGen is generating a binary as if the IIgs were loading it into memory, rewriting operands and stripping OMF headers. You can't reliably re-do it without working from the original.
> I hope that the procedure is correct. Everything seems to be working fine, so far. So I decided to post it here in case anyone needs it or wants to point out any error in my procedure.

Seems reasonable. Most of what SourceGen does is anchored by file offset, not address, so things should work out so long as everything ends up in the same place in the file. One note:

> 3. In the "UserLabels" section of the original project, change all of the "Value:" tags by subtracting 256 to their original value
> (I created an Excel sheet just for doing that!)

The Value field is redundant for UserLabels. Simple demonstration: go into a data file, trash a few Value fields, and then edit the project. You'll find that the Values get reset when the file is saved. The labels are associated with a file offset, not an address.

("Value" is stored in the project file because the serialization code uses the same function for everything that uses a Symbol. For project symbols, which have addresses and constants, the Value field is relevant.)

Il giorno lunedì 15 novembre 2021 alle 17:32:56 UTC+1 fadden ha scritto:
> The Value field is redundant for UserLabels. Simple demonstration: go into a data file, trash a few Value fields, and then edit the project. > You'll find that the Values get reset when the file is saved. The labels are associated with a file offset, not an address.

Oh well... I should have checked first. I could have saved a couple of hours writing a conversion sheet, in the fear of losing thousands of hard-worked labels.

Thank you for your clarification. That will make any future conversion attempt - either by me or anyone else - a lot easier.