Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Apple II language card switch references being used with slot IO index addressing #80

Closed
gbody opened this issue Mar 22, 2020 · 3 comments
Labels
enhancement New feature or request

Comments

@gbody
Copy link

gbody commented Mar 22, 2020

Apple II language card switch references being used with slot IO index addressing, this makes the code harder to understand due to the incorrect reference.
The following four were used incorrectly
ROMIN .eq $c081 ;RWx2 read ROM, write RAM bank 2
ROMIN_RO .eq $c082 ;RW read ROM, no write
LCBANK2 .eq $c083 ;RWx2 read/write RAM bank 2
LCBANK1 .eq $c08b ;RWx2 read/write RAM bank 1

Maybe checking addressing modes before making some substitutions.

Example for slot based accesses
L2A7D ldx $4391
lda #$00
sta $c084,x
sta $c085,x
lda #$a0
sta $c086,x
lda #$01
sta LCBANK2,x - should be $c083,x
sta ROMIN_RO,x - should be $c082,x
rts

@fadden
Copy link
Owner

fadden commented Mar 22, 2020

Yeah, this is a problem. I've seen many occasions were "LDA some_addr" and "LDA some_addr,x" both mean some_addr, but Apple II I/O is often different.

In 1.6 I've added the Disk ][ I/O locations (this change), but because they overlap with the LC locations I added them as slot 6 $C0En values. So they don't get resolved automatically, but the symbols are present, which allows you to manually edit operands to get the (kind of ugly):

         lda     IWM_MOTOR_ON-96,x ;start the disk spinning
         lda     IWM_DRIVE_1-96,x  ;select drive 1

(I'm debating changing them from addresses with $C0En values to constants with $C08n values. They're not getting matched automatically anyway.)

The trouble is that access to $C08n,x could be referring to any slot, including slot 0 (though that's unlikely), so it can't get matched to the "right thing" automatically.

The simple way around it is to add explicit definitions for the relevant $C08n to the project symbol list or to a project-specific symbol file. These can define the symbol of your choice, or (in a symbol file) use the magic value "erase" to cause SourceGen to forget an earlier definition. The former is useful if you're working on something specific, the latter if you're working on code that e.g. accesses multiple I/O devices. For example, you can erase all of the F8ROM zero-page definitions with this.

Another way is to copy the Cxxx-IO.sym65 file into your project, edit it, and include that instead of the platform definition. You can rename or delete the $C08n defs.

All of these measures feel like hacks, and I'm not happy that they're necessary for a situation this common on the Apple II. I can come up with something that helps code that touches the LC and one set of slot I/O, but assigning symbols for a single piece of code that accesses I/O locations in more than one slot gets complicated quickly.

One simple change would be to make all $C08n values constants, so none of them are matched automatically, but that's annoying for code that uses the LC.

The approach you suggested -- use LC symbols for $C08n, but leave $C08n,x/y unmatched -- may be the right way to go. I'd need to define some sort of "exact address only" flag in symbol files.

@fadden fadden added the enhancement New feature or request label Apr 4, 2020
@fadden
Copy link
Owner

fadden commented Jul 12, 2020

I decided to just add a separate "C08x-DiskII.sym65" that you can include to overwrite the LC definitions with Disk ][ definitions. I'm hesitant to add a direct-vs-indexed instruction feature since it adds complexity for a very specific situation. I'm also concerned that it doesn't fully solve even this problem, e.g. if another peripheral device accessed registers through $C08n,x then you still have ambiguity in the code.

So I took the easy way out for now.

@fadden
Copy link
Owner

fadden commented Aug 1, 2020

Migrating feature requests to wiki.

@fadden fadden closed this as completed Aug 1, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants