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
Re: 6502bench SourceGen disassembler updated [message #392585 is a reply to message #391937] Mon, 30 March 2020 20:28 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: fadden

I added two new projects to the 6502 disassembly site:

Elite: https://6502disassembly.com/a2-elite/
Stellar 7: https://6502disassembly.com/a2-stellar7/

Elite is enormous and very similar to well-documented versions on other platforms, so large sections of code are uncommented. I focused on Apple II-specific stuff and figuring out how to render the shapes. It turns out some of the shape data is wrong and causes visible glitches when you render at higher resolutions, but I was able to work around it in the visualizer.

Stellar 7 is complete (unless I overlooked something). The line drawing code ( https://6502disassembly.com/a2-stellar7/ROCK1.html#SymDrawLi ne) is remarkable -- run-slice algorithm with 3 different functions for horizontal lines to take advantage of updating multiple pixels per loop. I suspect the calculation of the slope wrecks performance for short lines though.
Re: 6502bench SourceGen disassembler updated [message #392598 is a reply to message #392585] Tue, 31 March 2020 07:20 Go to previous messageGo to next message
Antoine Vignau is currently offline  Antoine Vignau
Messages: 1860
Registered: October 2012
Karma: 0
Senior Member
That is cool, Andy!
Re: 6502bench SourceGen disassembler updated [message #394581 is a reply to message #392584] Fri, 15 May 2020 16:15 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: fadden

6502bench SourceGen v1.7-dev1 is now available. Key changes since v1.6:

- Added visualization generator for Atari AVG.
- Added visualization generator for NES pattern tables.

Most of you are probably familiar with the NES (Nintendo Entertainment System), at least in passing. As an exercise, I ported a disassembly of Super Mario Bros.

https://6502disassembly.com/nes-smb/

I suspect relatively few of you are familiar with Atari's AVG (Analog Vector Graphics). It was used in a bunch of Atari video arcade games back in the early 1980s. The one that caught my eye ~40 years ago was called Battlezone. When I learned a few years back that it was written for the 6502, I decided to disassemble it.

https://6502disassembly.com/va-battlezone/


Neither of these is Apple II-related (apologies!). I'm somewhat tempted to pry open the Atarisoft version of Battlezone to see if they shared any code.


The project web site is https://6502bench.com/. Source code and pre-built Windows binaries are available from https://github.com/fadden/6502bench/releases
Re: 6502bench SourceGen disassembler updated [message #396623 is a reply to message #394581] Sat, 11 July 2020 20:21 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: fadden

6502bench SourceGen v1.7-dev2 is now available. Key changes since v1.7-dev1:

* NOTE: changes to handling of 65816 code may impact projects that span multiple banks.
* NOTE: changes to Disk ][ symbols may require a minor project update.
* Improved 65816 support.
* Added ability to set the value of the Data Bank Register ('B').
* Added "smart PLB" feature that handles common code patterns.
* Fixed bugs in analyzer and source code generation.
* Improved Apple IIgs support.
* Added OMF viewer and converter.
* Added option to retain and use OMF relocation data when mapping operand to symbols. (Experimental)
* Improved GS/OS call recognition and formatting.
* Separated Apple Disk ][ I/O addresses into new .sym65.
* Added "export" button to visualization editor.
* Various minor fixes and UI improvements.
* Reworked regression tests to split 6502 and 65816 code. Allows better test coverage for assemblers with partial or no 65816 support (e.g. ACME).

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

-----

Some of these items merit a longer explanation.

Code that accesses the Disk ][ drive usually does so with an instruction like "LDA $C08n,X". Unfortunately some of the $C08n values already have a meaning: they control access to the Language Card. We could do a trick where direct accesses mean one thing and indexed accesses mean another, but you might encounter some other peripheral device that uses the same code pattern. So I created an overlapping set of definitions for $C08n and pulled them into a separate file. The default Cxxx-IO.sym65 has the direct LC definitions, and a new C08x-DiskII.sym65 has the Disk ][ definitions. If you want the Disk ][ defs, include the additional file. It's included by default in new projects, but will need to be added to older projects that use the symbols (which were previously included as constants).

The 65816 CPU has been mostly supported since v1.0, but without knowing the value of the Data Bank Register you can't reliably convert something like "LDA absolute" to a 24-bit address. Without the full address you can't map the operand to a symbol, which makes the disassembly less useful.

SourceGen now provides a way to specify the value of the DBR. It can generate some of these values automatically based on static analysis of the code.. For example, if it sees a PHK/PLB sequence, or LDA #imm8/PHA/PLB, the appropriate directive is inserted.

The incomplete nature of SourceGen's 65816 implementation meant it wasn't exercised much, so there were some bugs in the source code generators that have now been fixed.

The primary systems for the 65816 are the Apple IIgs and the SNES. SNES ROMs tend to be enormous, and SourceGen is not designed for multi-megabyte binaries, so I haven't paid much attention to those. (Having the entire code listing in a single scrollable window is fine for 64KB, but gets awkward to use above that. The analysis routines are not designed to work incrementally when things change, so things get slow when programs get big.)

The Apple IIgs has some reasonably-sized executables of interest, but they're stored in OMF format, which has relocatable code and data segments. So the file on disk might have "JSL $000000" in one place, and the target segment/offset in another, and the System Loader is responsible for filling in the actual address when the segment is loaded into memory.

Instead of trying to disassemble these in place, SourceGen provides an OMF viewer and conversion tool. The converter works like the GS/OS loader does, placing segments in memory and applying the relocation dictionaries. Segments that have to be loaded at a specific address are loaded first, and the others are filled in after. A SourceGen .dis65 project file is created at the same time, with .ORG directives for each segment, and some comments with the segment name and attributes.

The resulting file can be disassembled fully. However, SourceGen doesn't currently generate a Merlin32 link file, so you can't re-create the original OMF without some manual editing. Also, the currently-supported cross-assemblers other than Merlin32 will fail on any file larger than 64KB. (Merlin is good out to a few hundred KB, after which it silently implodes.)

-----

I had initially planned to stop there, but then I started to wonder if there was value in retaining the relocation dictionary. So I tried a quick experiment to see if it would help. While the implementation is incomplete, and occasionally yields odd behavior (e.g. cross-references sometimes look weird), it's sufficiently useful to be included and enabled by default.

Some examples. Consider this code snippet:

pea rsrcmsg2|-16
pea rsrcmsg2
_WriteCString
lda #buffer
sta pArcRead+$04
lda #buffer|-16
sta pArcRead+$06

In both cases we're referencing a 24-bit address as two 16-bit values. Without context, the disassembler will treat the PEA instruction as two independent 16-bit addresses, and the immediate values as constants:

.dbank $02
02/317c: f4 02 00 L2317C pea L20002 & $ffff
02/317f: f4 54 32 pea L23254 & $ffff
02/3182: a2 0c 20 ldx #WriteCString
02/3185: 22 00 00 e1 jsl Toolbox
02/3189: a9 00 00 L23189 lda #$0000
02/318c: 8d 78 3f sta L23F78 & $ffff
02/318f: a9 03 00 lda #$0003
02/3192: 8d 7a 3f sta L23F78 & $ffff +2

Worse yet, those STA instruction operands would have been shown as hex values or incorrect labels if the DBR had been set incorrectly. However, if we have the relocation data, we know the full address from which the addresses were formed, and we can tell when immediate values are addresses rather than constants. And we can do this even without setting the DBR.

02/317c: f4 02 00 L2317C pea L23254 >> 16
02/317f: f4 54 32 pea L23254 & $ffff
02/3182: a2 0c 20 ldx #WriteCString
02/3185: 22 00 00 e1 jsl Toolbox
02/3189: a9 00 00 L23189 lda #L30000 & $ffff
02/318c: 8d 78 3f sta L23F78 & $ffff
02/318f: a9 03 00 lda #L30000 >> 16
02/3192: 8d 7a 3f sta L23F78 & $ffff +2

The absence of relocation data can be a useful signal as well. For example, when pushing arguments for a toolbox call, the disassembler can tell the difference between addresses and constants without needing emulation or pattern-matching, because only the addresses get relocated. Consider this bit of source code:

lda <total_records
pha
pea linebuf|-16
pea linebuf+65
pea $0005
pea $0000
_Int2Dec

Without relocation data, it becomes:

02/0aa8: a5 42 lda $42
02/0aaa: 48 pha
02/0aab: f4 02 00 pea L20002 & $ffff
02/0aae: f4 03 31 pea L23103 & $ffff
02/0ab1: f4 05 00 pea L20005 & $ffff
02/0ab4: f4 00 00 pea L20000 & $ffff
02/0ab7: a2 0b 26 ldx #Int2Dec
02/0aba: 22 00 00 e1 jsl Toolbox

If we treat the non-relocated operands as constants:

02/0aa8: a5 42 lda $42
02/0aaa: 48 pha
02/0aab: f4 02 00 pea L230C2 >> 16
02/0aae: f4 03 31 pea L23103 & $ffff
02/0ab1: f4 05 00 pea $0005
02/0ab4: f4 00 00 pea $0000
02/0ab7: a2 0b 26 ldx #Int2Dec
02/0aba: 22 00 00 e1 jsl Toolbox

Instructions with 16-bit address operands are not matched to symbols if they don't have a relocation entry.

If the results are undesirable, or you just want to see how it would look without this behavior, the feature can be disabled with a setting in the project properties. (Project property changes are undoable, so you can un-check the property and hit undo/redo to flip back and forth.)

In the above listings, the original source code is Orca/M format. The disassembly is cc65 format. (Merlin is more succinct but less obvious.)
Re: 6502bench SourceGen disassembler updated [message #396624 is a reply to message #396623] Sat, 11 July 2020 20:48 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: fadden

In the "nothing is ever easy" department, I found this sequence in ProSel-16:

<set short registers>
<calculation>
BEQ label1
<set long registers>
<calculation>
label1:
BEQ label2
<calculation with long registers>
label2:
<set short registers>

So execution can legitimately arrive at label1 with long or short registers.. It just happens that the 'Z' flag will be set whenever they're short, so you can't actually get to the following line with short regs.

SourceGen's flag model doesn't include inter-flag dependencies, so it just sees a blended-flag situation and punts to the default.

It's certainly possible to teach SourceGen about this particular situation (e.g. conditional branch points maintain two sets of flags, and the appropriate sets are used for branch/no-branch), but that seems like a lot of complexity for little payoff. I figure this is why manual overrides exist.
Re: 6502bench SourceGen disassembler updated [message #396667 is a reply to message #396623] Mon, 13 July 2020 08:07 Go to previous messageGo to next message
TomCh is currently offline  TomCh
Messages: 242
Registered: November 2012
Karma: 0
Senior Member
On Sunday, 12 July 2020 01:21:33 UTC+1, fadden wrote:
> 6502bench SourceGen v1.7-dev2 is now available. Key changes since v1.7-dev1:
>
> ...
> * NOTE: changes to Disk ][ symbols may require a minor project update.
> ...
>
> The project web site is https://6502bench.com/. Source code and pre-built Windows binaries are available from https://github.com/fadden/6502bench/releases
>
> -----
>
> Some of these items merit a longer explanation.
>
> Code that accesses the Disk ][ drive usually does so with an instruction like "LDA $C08n,X". Unfortunately some of the $C08n values already have a meaning: they control access to the Language Card. We could do a trick where direct accesses mean one thing and indexed accesses mean another, but you might encounter some other peripheral device that uses the same code pattern. So I created an overlapping set of definitions for $C08n and pulled them into a separate file. The default Cxxx-IO.sym65 has the direct LC definitions, and a new C08x-DiskII.sym65 has the Disk ][ definitions. If you want the Disk ][ defs, include the additional file. It's included by default in new projects, but will need to be added to older projects that use the symbols (which were previously included as constants).
>
> ...

Great idea - I will have a think about how I can incorporate something similar into AppleWin's disassembler.

Thanks.
Re: 6502bench SourceGen disassembler updated [message #396911 is a reply to message #396623] Wed, 22 July 2020 14:19 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: fadden

6502bench SourceGen v1.7.0-alpha1 is now available. Key changes since v1.7..0-dev2:

- OMF converter will optionally start segments at xx/0100.
- Added option to configure wrap length of strings and bulk data.
- Added File > Reload External Files to reload .sym65 and plugins easily.
- Fixed a crash associated with computer suspending while project is open.

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 added the "start at $0100" option because I found it confusing when code accessed an early address with something like "LDA $0056". It's not accessing the direct page (unless B=0 and D=0), but my brain reads it that way. Some assemblers also consider it ambiguous, so SourceGen has to generate operand width disambiguators to avoid confusion.

If you start the code at $0100, it becomes "LDA $0156", which resolves the problem. We can't do this if ALIGN > $100 or the segment is > (65536-256) bytes long (with a nonzero BANKSIZE), but those are rare.
Re: 6502bench SourceGen disassembler updated [message #396916 is a reply to message #396911] Wed, 22 July 2020 15:07 Go to previous messageGo to next message
Antoine Vignau is currently offline  Antoine Vignau
Messages: 1860
Registered: October 2012
Karma: 0
Senior Member
Hi Andy,
I thought LDA |$0056 was the convention?!?
av
Re: 6502bench SourceGen disassembler updated [message #396920 is a reply to message #396916] Wed, 22 July 2020 20:33 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: fadden

On Wednesday, July 22, 2020 at 12:07:34 PM UTC-7, Antoine Vignau wrote:
> I thought LDA |$0056 was the convention?!?

Orca/M, which went by the WDC recommendations, uses that.

64tass: LDA @w$0056
Merlin: LDA: $0056
ACME: LDA+2 $0056
cc65: LDA a:$0056

Most things should end up referenced by label, so the assembler knows what you're trying to do, but even that falls through sometimes (ACME and cc65 have issues with forward references).

Some people might prefer to have their segments start at xx/0000, so I made it an option.

Mostly I just wanted to avoid seeing things like:

LDA $56
STA $0056

because my 6502-based brain thinks those are the same thing. The nice thing about relocatable code is that you can put it wherever you feel like. :-)
Re: 6502bench SourceGen disassembler updated [message #396928 is a reply to message #396920] Thu, 23 July 2020 03:01 Go to previous messageGo to next message
Antoine Vignau is currently offline  Antoine Vignau
Messages: 1860
Registered: October 2012
Karma: 0
Senior Member
Thanks Andy, I really thought pipe was the std. With Merlin, I have always used the pipe symbol without knowing other options were possible,
av
Re: 6502bench SourceGen disassembler updated [message #396944 is a reply to message #396928] Thu, 23 July 2020 10:57 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: fadden

On Thursday, July 23, 2020 at 12:01:30 AM UTC-7, Antoine Vignau wrote:
> Thanks Andy, I really thought pipe was the std. With Merlin, I have always used the pipe symbol without knowing other options were possible,

FWIW, I didn't realize Merlin 32 accepted '|' on the operand. The only approach mentioned in the documentation is to add a character other than 'L' to the opcode mnemonic.
Re: 6502bench SourceGen disassembler updated [message #397279 is a reply to message #396911] Fri, 31 July 2020 00:07 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: fadden

6502bench SourceGen v1.7.0 is now available.

My earlier v1.7.0-* posts listed the new features, so I won't regurgitate them here. It's the Apple IIgs release, essentially.

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

-----

To exercise the code, I disassembled the DOS 3.3 FST from GS/OS System 6.0.1. You can find the project here: https://6502disassembly.com/a2-gsos/

Mostly this convinced me that I need a better way to organize equates at the top of the file. :-)
Re: 6502bench SourceGen disassembler updated [message #397283 is a reply to message #397279] Fri, 31 July 2020 02:54 Go to previous messageGo to next message
Antoine Vignau is currently offline  Antoine Vignau
Messages: 1860
Registered: October 2012
Karma: 0
Senior Member
Nice work on the DOS 3.3 FST, Andy.

That reminds me of my 2008 work to understand how FST were built. That has led to the rDOS FST and a couple of others, either released or still on my HDD.

Antoine
Re: 6502bench SourceGen disassembler updated [message #397833 is a reply to message #397279] Thu, 13 August 2020 14:16 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: fadden

In my documentation for https://github.com/fadden/fdraw, I explained what got me interested in drawing hi-res lines, but I didn't discuss my motivation for drawing hi-res circles. That goes back to a game called ABM, written by Silas Warner in 1980.

The game is clearly inspired by Missile Command, and features circular explosions. These expand outward to form a full white circle, then expand outward with black until the original is cleared. I do a similar effect in the fdraw demo, by drawing filled circles with increasing radii, but I always wondered how ABM did it.

It turns out that what ABM does is closer to a spiral, drawing an expanding circle pixel-by-pixel incrementally. The approach isn't an especially fast way to draw a completed circle, but it provides a flexible and visually appealing way to draw an expanding circle across several game frames.

The code for the game is interesting in another respect: almost all math is done with Applesoft's floating-point routines. Much of the hi-res rendering makes use of Applesoft routines as well. It's not the fastest approach, but it let the game be tiny. The game also makes heavy use of inline data following JSRs, as a convenient way to pass arguments to math and text output routines.

The full disassembly, with a visualization of the circle data, can be found at https://6502disassembly.com/a2-abm/

I ended up adding a bunch of Applesoft entry points to the SourceGen symbol file, and added a new visualization type to the Applesoft shape table renderer (ABM uses shape table shapes, but doesn't put them in an actual shape table). Since these changes are generally useful I packaged them up in a minor release of SourceGen (v1.7.1).
Re: 6502bench SourceGen disassembler updated [message #397840 is a reply to message #397833] Thu, 13 August 2020 16:28 Go to previous messageGo to next message
Antoine Vignau is currently offline  Antoine Vignau
Messages: 1860
Registered: October 2012
Karma: 0
Senior Member
That is very interesting once again, Andy.

What is .zstr? A C string? I really do not like the syntax of the assembler you are using. .bulk? That is so weird. Just a question of time I presume!

Antoine
Re: 6502bench SourceGen disassembler updated [message #397859 is a reply to message #397840] Thu, 13 August 2020 20:29 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: fadden

On Thursday, August 13, 2020 at 1:28:31 PM UTC-7, Antoine Vignau wrote:
> What is .zstr? A C string? I really do not like the syntax of the assembler you are using. .bulk? That is so weird. Just a question of time I presume!

It's a generic pseudo-op. You can change them to whatever you want; there are "quick set" buttons to change them to Merlin directives, cc65, etc. When you open the project you'll see your definitions rather than mine. Same for upper/lower case on mnemonics and hex, string delimiters, etc. One of my goals was that everyone should be able to look at a project in the way that they're most comfortable with.

I generate the HTML files with Merlin-style expressions and label modifiers (because they're concise and they're what I'm used to), but use the generic pseudo-ops because Merlin doesn't define everything that SourceGen does. ".zstr" is a zero-terminated string, for which Merlin has no documented equivalent.

If you want it to be exactly Merlin, you could generate an assembly source file instead. But then you lose the visualizations and other HTML goodies. The ".zstr" directive turns into what you'd expect:

jsr InS_PrintString ;print high score notice
asc "HIGH SCORE IS ",00

".bulk" becomes a HEX directive in Merlin, and a series of comma-separated hex values in most other assemblers. The point is to have the directive describe the purpose (big blob of data), and have the source generator output whatever is most appropriate for the target assembler.
Re: 6502bench SourceGen disassembler updated [message #398146 is a reply to message #397859] Tue, 18 August 2020 11:47 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: fadden

One of the games that went around Back In The Day was this really simple one where you would drop a bomb on a tank. When the bomb hit, the tank would burst into a shower of pixels. More of a graphics demo than a game, really.

The game is Bomber, written by Bob Bishop, distributed by Softape on cassette. Two versions circulated, one of which added additional features, like keeping score. The newer version only works on computers with the original (non-Autostart) ROM.

I always wondered how the graphics were done. You can find a disassembly here: https://6502disassembly.com/a2-bomber/
Re: 6502bench SourceGen disassembler updated [message #398161 is a reply to message #398146] Tue, 18 August 2020 17:03 Go to previous messageGo to next message
David Schmidt is currently offline  David Schmidt
Messages: 993
Registered: October 2012
Karma: 0
Senior Member
On 8/18/20 11:47 AM, fadden wrote:
> One of the games that went around Back In The Day was this really simple one where you would drop a bomb on a tank. When the bomb hit, the tank would burst into a shower of pixels. More of a graphics demo than a game, really.
>
> The game is Bomber, written by Bob Bishop, distributed by Softape on cassette. Two versions circulated, one of which added additional features, like keeping score. The newer version only works on computers with the original (non-Autostart) ROM.
>
> I always wondered how the graphics were done. You can find a disassembly here: https://6502disassembly.com/a2-bomber/

Thanks for the writeup - always interesting to read. It's very much
like Bob was simulating a (simple) physical system. He tracked each
element as the tank exploded, disintegrated, and got acted on by gravity
in 2D.
Re: 6502bench SourceGen disassembler updated [message #398324 is a reply to message #398146] Sun, 23 August 2020 14:25 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: fadden

One of the most eye-catching games for the Apple II is Nasir Gebelli's Phantoms Five. The full-screen scrolling terrain and big, colorful graphics were pretty amazing back in 1980.

It's also pretty tough to control with a joystick, especially during the dogfight phase, but nothing's perfect. :-)

Disassembly and analysis here: https://6502disassembly.com/a2-phantoms-five/
Re: 6502bench SourceGen disassembler updated [message #400505 is a reply to message #397279] Thu, 24 September 2020 16:13 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: fadden

6502bench SourceGen v1.7.2 is now available.

Changes since last major release:
* Added Apple II screen memory chart tool, for text and hi-res graphics.
* Updated Apple II symbol files and visualizers.
* Updated Apple /// symbol files and extension scripts.
* Improved analyzer's handling of BRKs.
* Fixed and improved cross-reference listing.
* Added toolbar button to toggle cycle counts. Made on-screen and asm configurable independently.

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 screen memory chart is for those times when you see code writing to $22d8 and wonder, "what line is that on?". It also identifies the screen holes. Text and hi-res, pages 1 and 2.

The Apple /// SOS script now formats SOS call parameter blocks, similar to the way the ProDOS 8 formatter does it. The list of I/O addresses has some new stuff from robjustice.
Re: 6502bench SourceGen disassembler updated [message #408809 is a reply to message #400505] Tue, 08 June 2021 17:28 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: fadden

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.
Re: 6502bench SourceGen disassembler updated [message #408818 is a reply to message #408809] Wed, 09 June 2021 03:39 Go to previous messageGo to next message
erolfi is currently offline  erolfi
Messages: 55
Registered: December 2012
Karma: 0
Member
Great news, Andy!

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

Thanks
Re: 6502bench SourceGen disassembler updated [message #408824 is a reply to message #408818] Wed, 09 June 2021 10:48 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: fadden

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/d3e00b23429e65baa 7ead7519ed044037adf10a2
Re: 6502bench SourceGen disassembler updated [message #408847 is a reply to message #408824] Thu, 10 June 2021 18:29 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: fadden

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.
Re: 6502bench SourceGen disassembler updated [message #409089 is a reply to message #408847] Fri, 18 June 2021 14:00 Go to previous messageGo to next message
erolfi is currently offline  erolfi
Messages: 55
Registered: December 2012
Karma: 0
Member
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.
Re: 6502bench SourceGen disassembler updated [message #409117 is a reply to message #409089] Sat, 19 June 2021 10:50 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: fadden

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
Re: 6502bench SourceGen disassembler updated [message #409298 is a reply to message #409117] Fri, 25 June 2021 02:33 Go to previous messageGo to next message
erolfi is currently offline  erolfi
Messages: 55
Registered: December 2012
Karma: 0
Member
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
Re: 6502bench SourceGen disassembler updated [message #409299 is a reply to message #409117] Fri, 25 June 2021 02:34 Go to previous messageGo to next message
erolfi is currently offline  erolfi
Messages: 55
Registered: December 2012
Karma: 0
Member
.....and I'm running the prebuilt version, of course.
Re: 6502bench SourceGen disassembler updated [message #409307 is a reply to message #409298] Fri, 25 June 2021 10:54 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: fadden

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?
Re: 6502bench SourceGen disassembler updated [message #410520 is a reply to message #408809] Mon, 16 August 2021 16:12 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: fadden

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.
Re: 6502bench SourceGen disassembler updated [message #412321 is a reply to message #410520] Sun, 14 November 2021 12:49 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: fadden

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.
Re: 6502bench SourceGen disassembler updated [message #412322 is a reply to message #410520] Sun, 14 November 2021 13:02 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: fadden

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/
Re: 6502bench SourceGen disassembler updated [message #412327 is a reply to message #412322] Sun, 14 November 2021 17:21 Go to previous messageGo to next message
Steven Hirsch is currently offline  Steven Hirsch
Messages: 798
Registered: October 2012
Karma: 0
Senior Member
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?
Re: 6502bench SourceGen disassembler updated [message #412331 is a reply to message #412327] Sun, 14 November 2021 18:52 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: fadden

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_do cumentation.zip on asimov, but it all seems to be ProSel-16.
Re: 6502bench SourceGen disassembler updated [message #412334 is a reply to message #412327] Sun, 14 November 2021 23:52 Go to previous messageGo to next message
D Finnigan is currently offline  D Finnigan
Messages: 1154
Registered: October 2012
Karma: 0
Senior Member
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
Re: 6502bench SourceGen disassembler updated [message #412335 is a reply to message #412334] Sun, 14 November 2021 23:55 Go to previous messageGo to next message
D Finnigan is currently offline  D Finnigan
Messages: 1154
Registered: October 2012
Karma: 0
Senior Member
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.
Re: 6502bench SourceGen disassembler updated [message #412339 is a reply to message #412335] Mon, 15 November 2021 08:16 Go to previous messageGo to next message
erolfi is currently offline  erolfi
Messages: 55
Registered: December 2012
Karma: 0
Member
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)
Re: 6502bench SourceGen disassembler updated [message #412341 is a reply to message #412339] Mon, 15 November 2021 11:32 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: fadden

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.)
Re: 6502bench SourceGen disassembler updated [message #412342 is a reply to message #412341] Mon, 15 November 2021 11:48 Go to previous message
erolfi is currently offline  erolfi
Messages: 55
Registered: December 2012
Karma: 0
Member
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.
Pages (3): [ «    1  2  3]  Switch to threaded view of this topic Create a new topic Submit Reply
Previous Topic: Asimov FTP anonymous login
Next Topic: new apple2 demos/game
Goto Forum:
  

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

Current Time: Thu Mar 28 14:17:00 EDT 2024

Total time taken to generate the page: 0.15113 seconds