Kowalski Simulator Updates

[8BIT]

OK, I must have uploaded the wrong zip file previously.

Here is the latest file v1.3.3.2 with all the ASCIS fixes.

Sorry for the extra trouble.

Help - About should show v1.3.3.2

thanks!

Daryl

[jdimeglio]

Looking great, and once again very appreciative - and if you ever head down here, look me up., I'll shout you a beer.

[8BIT]

Hi all,

I found a bug in the disassembly window. I have the address extended to 24 bits and if you scroll down past $FFFF (6502 or 65C02 modes), it will wrap to $000000 and keep going. The problem is if you try to scroll back up, it locks up the program and its stops responding. So until I fix it, be aware and do not scroll past $FFFF.

Wishing everyone a happy new year!

Daryl

[8BIT]

8BIT wrote:

Hi all,

I found a bug in the disassembly window. I have the address extended to 24 bits and if you scroll down past $FFFF (6502 or 65C02 modes), it will wrap to $000000 and keep going. The problem is if you try to scroll back up, it locks up the program and its stops responding. So until I fix it, be aware and do not scroll past $FFFF.

Wishing everyone a happy new year!

Daryl

Here is the updated code to fix this bug. The version is now 1.3.3.3

Daryl

[8BIT]

For those having trouble finding the latest update in all of these pages, I will always post the latest updates to my Simulator page on my website as well as this forum.

Here's a link -> https://sbc.rictor.org/kowalski.html

Daryl

[8BIT]

I found another bug yesterday. In 65816 assembly, labels above $FFFF cause a missing ORG error. I believe it is not assigning/handling 24-bit addresses for labels properly. I am working on the fix, should be ready in a few days.

Daryl

[8BIT]

After fixing the label issue, I realized I had a few other oversights as well. Branches, jumps, and JSR's also had issues outside of bank 0. I have fixed those also and I am finishing up testing of operations that attempt to cross bank boundaries. I added a new error message for invalid bank crossings.

I am also adding a popup warning when code is assembled across a bank boundary. The one issue is no line # can be provided. The programmer will have to look at the assembly listing to find the location in the source to ensure branches, jumps, and JSR's are respecting the bank limits. I will try to flag an error if an operation splits the boundary, and the warning if does not.

I hope to get the update out this weekend.

Thanks!

Daryl

[BigDumbDinosaur]

8BIT wrote:

After fixing the label issue, I realized I had a few other oversights as well. Branches, jumps, and JSR's also had issues outside of bank 0. I have fixed those also and I am finishing up testing of operations that attempt to cross bank boundaries. I added a new error message for invalid bank crossings.

I am also adding a popup warning when code is assembled across a bank boundary. The one issue is no line # can be provided. The programmer will have to look at the assembly listing to find the location in the source to ensure branches, jumps, and JSR's are respecting the bank limits. I will try to flag an error if an operation splits the boundary, and the warning if does not.

I'm not sure I'm understanding...wouldn't the program bank byte be static once established? If I say * = $A18000 I would have fixed the execution bank and should the program counter wrap the bank would remain $A1, thus following the behavior of the hardware. If so, it would seem a branch, subroutine call or jump (excepting JML and JSL) would never cross banks because the bank byte would not be changed.

[8BIT]

Here are some code examples that I was testing with. Assuming a programmer was assembling a huge program and did not realize he ran over a bank boundary. I get the fact that a good programmer would know where he is and not need these errors and warnings, I'm writing the assembler to assume nothing.

This code will cause an error due to the BEQ crossing a bank.

Code: Select all

        *= $FFFA ; just to place us close to the end
        LDA $00
        BEQ NEXT
        LDA $03
        STA $01
NEXT    STA $02

This code would cause a warning pop-up only as STA $01 fits inside the first bank and STA $02 fits inside the next bank. Assembly is correct but execution will not flow as this is written.

Code: Select all

        *= $FFFA ; just to place us close to the end
NEXT    LDA $00
        BEQ NEXT
        STA $01
        STA $02

This code would cause an error as STA $01 splits the bank - STA opcode is on first bank and $01 is in the next bank.

Code: Select all

        *= $FFFB ; just to place us close to the end
NEXT    LDA $00
        BEQ NEXT
        STA $01
        STA $02

Hope that helps!

Daryl

[8BIT]

After re-reading your question, I think I understand your statement better. You want the assembler to wrap the PC back to $0000 of the present bank. In the current format, that would cause a PC wrapped error, just like the 65C02 code does. If the consensus is to wrap the PC vs. advancing to the next bank, then I'd leave the error as is and let the assembly stop.

By default, the assembler just increments the PC after each instruction and I was letting it pass into the next bank. As long as I have the errors and warnings that I have added, this too is a viable option. The coder just needs to ensure he is adjusting the PBR for code on either side of the bank boundary. The warning reminds him of that need.

What does everyone prefer?

Daryl

[BigDumbDinosaur]

8BIT wrote:

After re-reading your question, I think I understand your statement better. You want the assembler to wrap the PC back to $0000 of the present bank. In the current format, that would cause a PC wrapped error, just like the 65C02 code does. If the consensus is to wrap the PC vs. advancing to the next bank, then I'd leave the error as is and let the assembly stop.

By default, the assembler just increments the PC after each instruction and I was letting it pass into the next bank. As long as I have the errors and warnings that I have added, this too is a viable option. The coder just needs to ensure he is adjusting the PBR for code on either side of the bank boundary. The warning reminds him of that need.

What does everyone prefer?

My opinion is the assembler should halt with an error if PC wraps. The 65C816 will not increment PB when PC wraps, so it makes sense to me that the assembler should behave in the same fashion.

I should note there is no programmatic means by which PB can be directly changed in the 816. Following that pattern, the only way the assembler's analog of PB should be changeable is by explicitly setting an assembly address as a 24-bit value.

[cjs]

8BIT wrote:

Assuming a programmer was assembling a huge program and did not realize he ran over a bank boundary. I get the fact that a good programmer would know where he is and not need these errors and warnings....

Actually, I disagree: I feel that a good programmer would understand that this is a likely source of human error and use tools that catch it at reasonable cost, building them if necessary. (I've recently been doing this with macros that catch these sort of "overflowed the area to which I wanted to limit my code" issues.)

BDD's suggestion sounds like the right one to me. Wrapping code execution around to the beginning of the bank sounds like a bit of a trick that you'd want documented in your code, and it seems to me that his approach would make such documentation easy. Of course, this would best be tested with an example of where it would be reasonable to do this and then looking at exactly how much extra work the programmer has to go to in order to make this happen.

[dclxvi]

8BIT wrote:

What does everyone prefer?

I don't use the Kowalski simulator, so I have no opinion on which way to go, but I will suggest that it might be worth allowing the user to select which behavior it uses. Code wraps at a bank boundary, but data does not. When X is nonzero or the m flag is 0, LDA $12FFFF,X accesses bank $13 not bank $12; furthermore, the cycle count of LDA long,X does not depend on whether or not a bank (or page) boundary was crossed, so unlike the 6502 and 65C02, there isn't much incentive to align things like tables or buffers to a page or bank boundary. (If you're counting them as data, then the direct page and stack are exceptions, as both do wrap at the bank 0 boundary.)

When assembling code it makes sense to catch bank boundary crossings, and when assembling data it makes sense to ignore bank boundary crossings (after all, <64k of code with >64k of data isn't a crazy scenario). However, it's not so easy for the assembler to figure out which is being assembled.

Code: Select all

ENABLE
   SEP #$40
   .byte $50 ; BVC, skip CLV
DISABLE
   CLV

In the above example .byte $50 is code, not data, but how would the assembler figure out that it should be detecting a bank boundary crossing?

There are also routines like PRIMM that use inline data.

Code: Select all

   .org $12FFF8
   JSL PRIMM
   .string "nvmxdizc e"
   .byte 0

There is a further complication that, even if the assembler is somehow able to figure out that .string is inline data, how would the assembler know whether PRIMM returns to bank $12 or to bank $13? And should it even be making such an assumption?

It'll likely be a lot simpler to pick a reasonable default behavior and let the user tell you if and when to use a different behavior, perhaps even via an assembler directive. I can imagine use cases where the desired behavior is:

1. If bank boundary crossing occurs, wrap, issue error and halt immediately
2. If bank boundary crossing occurs, wrap, issue warning and continue
3. If bank boundary crossing occurs, wrap, continue without issuing a warning or error
4. If bank boundary crossing occurs, increment bank, continue without issuing a warning or error
5. If bank boundary crossing occurs, increment bank, issue warning

There may be additional cases that haven't occurred to me. Furthermore, it might be helpful to have an independent setting that switches between cases 1 and 2. Example, user A publishes source code and prefers behavior 1. User B would prefer behavior 2 while adapting, extending, or otherwise updating the source. It might be nice if User B only had to make a change in one place to switch between those behaviors.

Again, be careful about placing too much weight on the thoughts of someone who isn't (and in the foreseeable future isn't likely to be) using the simulator, but be aware there are subtle ways in which the 65C816 is more complicated than the 6502 and 65C02.

Good luck.

[cjs]

dclxvi wrote:

Code wraps at a bank boundary, but data does not.... When assembling code it makes sense to catch bank boundary crossings, and when assembling data it makes sense to ignore bank boundary crossings....

This is quite a good point.

Perhaps the assembler could always simply move foward into the next bank when the assembly address counter passes over a bank boundary, but generate an error on any attempt to assemble an instruction mnemonic (or anything that contains one, such as a macro) when the current bank is not the same bank as the last explicitly set assembly address. Then large amounts of data will assemble just fine, but code, even after a large amount of data, will generate an appropriate error. I'm not sure if it would be useful to have a way of generating an error on data overflowing a bank.

Quote:

...issue warning and continue...

IMHO, warnings are about the worst way to handle any potential problem. They are easy to miss and generate the kind of noise in build output that makes things easy to miss. (And yes, I'm the sort of person who always turns on -Werror for his own code.) If the problem is common enough that the assembler, rather than the developer, should be catching it, the assembler should emit an error and ensure no output is produced, and provide an easy way to indicate at that point in the code that there isn't a problem there if the developer might reasonably want to do whatever triggered the error.

[8BIT]

Thank you all for your input. This is what I have chosen to do:

If program code goes past the end of a bank, it will stop and error on the instruction where the cross happens.
Program code can go all the way to $FFFF of the current bank without warnings or errors.
Data can freely cross a page boundary.
To move from one bank to another for program code, use a .ORG or *= directive to set the new starting address for that bank.
If a branch, jump, or JSR tries to move to a label in a different bank, an error will be generated. JSL and JML will cross banks as designed.
There are no pop-up warnings. Errors will have to be resolved.

I have not done any testing with macros, but expect they will error when they should.

So for now, here is version 1.3.3.4 - correcting the bank boundary issues. Please let me know if you find anything out of sorts.

Source code is on my website.

Thanks!

Daryl