Kowalski Simulator Updates

[8BIT]

I'm almost done with the 16MB expansion.

I have the save code options all done except for the Intel-hex version. I'm not sure how to proceed with this format.

Looking here -> https://en.wikipedia.org/wiki/Intel_HEX

I see I could use the record type 2 to define the bank address. That way most records are still type 0 and the bank address defaults to zero. When encountering a record type 2, the program can adjust the bank accordingly. Does anyone have an alternative ideas?

For the Motorola S record, I used record type S2 which allows 24 bit addresses. I also use record S8 if the start address is > $FFFF.

The load code options will support the formats and types in the save code functions.

Any alternative thoughts for Intel Hex support?

thanks!

Daryl

[GARTHWILSON]

http://srecord.sourceforge.net/ provides a way to convert hex file types.

[rwiker]

Maybe use a type 4 record instead of type 2? Record type 2 seems to be limited to 1MB in total, while type 4 gives you up to 4GB in "pages" of 64k.

[cjs]

rwiker wrote:

Maybe use a type 4 record instead of type 2? Record type 2 seems to be limited to 1MB in total, while type 4 gives you up to 4GB in "pages" of 64k.

This would be my instinct as well; not only is type 2 too narrow (20 bits) for the full 65816 address space (24 bits), but it also has many address aliases (e.g., FFF0:0020 == FFF1:0010 == FFF0:0020) which seems like just a bit of extra complexity that does nobody (except 8086 programmers) any good.

The only issue with that might be in working with tools that support type 2 but not type 4, but that seems unlikely to be something you'd encounter in the world of 65816 programming.

[BigDumbDinosaur]

RichCini wrote:

* CPU mode 8/16 management. I guess this could be handled by macros, but I liked the WDC LONGA/LONGI thing, EXCEPT that you also had to put the REP/SEP instructions too. If there was a way to use a single obvious directive for this, that would be great.

Darryl added the ! operator to immediate mode operands to force the assembler to generate a 16-bit operand, e.g., LDA !#DATA. The ! isn't necessary if DATA is already 16 bits. That works fine.

I have no use for the LONGA/LONGI assembler directives and in fact, they can become a land mine in some cases. For example, if the mainline code has the accumulator set to 16 bits and then calls a subroutine, you'd have to make sure that subroutine's code starts with a LONGA and ends with a SHORTA. Otherwise, things could quickly go sideways.

I use macros to avoid having to type REP and SEP to change register widths. That's about as much "automation" I want.

As for editor line numbers, no thanks! All they do is use up valuable screen real estate. The Kowalski editor has a good search and search-and-replace function, should I need to track down something in the source code. I do find line numbers useful in the listing file.

[RichCini]

BigDumbDinosaur wrote:

RichCini wrote:

* CPU mode 8/16 management. I guess this could be handled by macros, but I liked the WDC LONGA/LONGI thing, EXCEPT that you also had to put the REP/SEP instructions too. If there was a way to use a single obvious directive for this, that would be great.

Darryl added the ! operator to immediate mode operands to force the assembler to generate a 16-bit operand, e.g., LDA !#DATA. The ! isn't necessary if DATA is already 16 bits. That works fine.

I have no use for the LONGA/LONGI assembler directives and in fact, they can become a land mine in some cases. For example, if the mainline code has the accumulator set to 16 bits and then calls a subroutine, you'd have to make sure that subroutine's code starts with a LONGA and ends with a SHORTA. Otherwise, things could quickly go sideways.

I use macros to avoid having to type REP and SEP to change register widths. That's about as much "automation" I want.

As for editor line numbers, no thanks! All they do is use up valuable screen real estate. The Kowalski editor has a good search and search-and-replace function, should I need to track down something in the source code. I do find line numbers useful in the listing file.

Thanks for letting me know about the size operator, that will be helpful. Does the 816 have to be in native mode for that to work? For "new" software I guess it makes sense to switch to native mode and then if you're working with an 8-bit peripheral register just sending the LSB or MSB as needed.

On the editor, I was thinking in context of my own workflow when using other, non-real-time tools. After a compilation run, I put the source and listing files side-by-side (assuming the LST embeds the errors) and run through all the errors at once before recompiling; it just helps me locate things. I've also captured the output from a command prompt into a text file and worked from that.

[8BIT]

cjs wrote:

rwiker wrote:

Maybe use a type 4 record instead of type 2? Record type 2 seems to be limited to 1MB in total, while type 4 gives you up to 4GB in "pages" of 64k.

This would be my instinct as well; not only is type 2 too narrow (20 bits) for the full 65816 address space (24 bits), but it also has many address aliases (e.g., FFF0:0020 == FFF1:0010 == FFF0:0020) which seems like just a bit of extra complexity that does nobody (except 8086 programmers) any good.

OK, I will change type 2 to type 4, using the least significant byte for the bank register and erroring if the most significant byte is not zero. I am using type 3 to indicate the starting address, as the Simulator supports including the start address as a separate parameter.

Quote:

The only issue with that might be in working with tools that support type 2 but not type 4, but that seems unlikely to be something you'd encounter in the world of 65816 programming.

it appears that type 0 - type 3 are considered 16-bit Intel-Hex while type 1, 2, 4 & 5 are considered 32-bit Intel-Hex. I'll change type 3 to type 5 for reporting the start address, that way it is at least using a known stardard.

Almost there, I need to ensure the load feature is working with these new formats and then add the 'file changed' flag that Rich suggested.

Daryl

[BigDumbDinosaur]

RichCini wrote:

Thanks for letting me know about the size operator, that will be helpful. Does the 816 have to be in native mode for that to work? For "new" software I guess it makes sense to switch to native mode and then if you're working with an 8-bit peripheral register just sending the LSB or MSB as needed.

Let's clarify things a bit.

The 65C816 has two modes: emulation and native. In emulation mode, the MPU mostly looks like a 65C02 to software. The hardware vectors are those of the 65C02, plus there are vectors for the ABORT hardware interrupt and the COP software interrupt. Register sizes are locked at eight bits and the stack pointer's MSB is locked to $01. Differentiating between an IRQ and a BRK instruction with a stack sniff is necessary. When an interrupt is acknowledged, the program bank will not be pushed to the stack with the program counter before jumping through the relevant vector..

In native mode, the hardware vectors are different; IRQ and BRK have separate vectors. Register sizes can be set to eight or 16 bits by manipulating bits 4 and 5 in the status register, and the stack pointer is 16 bits. When an interrupt is acknowledged, the 816 will push the program bank along with the program counter before jumping through the relevant vector.

In both modes, the 65C816 looks like an NMOS 6502 to hardware if the VDA and VPA address-qualifying signals are ignored.

A common fallacy regarding the 816 is it has a "16-bit mode." It does not. It has an emulation mode or a native mode. In native mode, the registers can be set to 16 bits or eight bits, allowing one to process data a word or byte at a time, respectively. The Kowalski assembler knows nothing about 65C816 modes or register sizes. You tell it to treat 816-unique instructions, e.g., TCD, and addressing modes, e.g., LDA ($05,S),Y, as valid with the pseudo-op .OPT PROC65816 in the first line of your source file. In my source files, I use .OPT PROC65816,CASEINSENSITIVE,SWAPBIN to allow 816 code, remove case-sensitivity for non-quoted strings, and to swap the function of the % and @ operators.

[8BIT]

BigDumbDinosaur wrote:

The Kowalski assembler knows nothing about 65C816 modes or register sizes. You tell it to treat 816-unique instructions, e.g., TCD, and addressing modes, e.g., LDA ($05,S),Y, as valid with the pseudo-op .OPT PROC65816 in the first line of your source file. In my source files, I use .OPT PROC65816,CASEINSENSITIVE,SWAPBIN to allow 816 code, remove case-sensitivity for non-quoted strings, and to swap the function of the % and @ operators.

Here is a little more insight into how the program runs.
The Simulator->Options->General tab has 3 choices for Processor. Selecting this sets the default Processor for both the Assembler and the Debugger. If you set this to 65816, the assembler will assemble 65816 opcodes and modes correctly with or without the .OPT PROC65816. However, regardless of what is set in the Simulator->Options->General tab, using a .OPT PROC65xxx directive will override that setting for the Assembler only. It does not affect the Debugger functions. The Debugger will always use the setting from Simulator->Options->General tab.

An easy way to test this is to add this code to a new source document.

Code: Select all

     .OPT   proc65c02
     *=  $1000
     LDA #$00
     NOP
     BRA $1000
     BRK

Set the Simulator->Options->General tab processor to 6502.
Assemble the file and it will without error, because the proc65c02 overrode the 6502 setting in Simulator->Options->General tab.
Now start the debugger and use step into (F11) to step down to the BRA. You will notice in the 6502 uP Registers & Status window that the Stat message at the bottom says in encountered an illegal byte code. That is because the debugger is running in 6502 mode.

You can switch the Simulator->Options->General tab option to 65C02 and comment out the .OPT line in the source and see that it also assembles without error and that the debugger now accepts the BRA opcode.

That being said, it is a good practice to place the .OPT proc65xxx directive at the top of your source code. This ensures the assembler will process it as intended regardless of the debugger setting.

Be well all!

Daryl

[BigDumbDinosaur]

8BIT wrote:

The Simulator->Options->General tab has 3 choices for Processor. Selecting this sets the default Processor for both the Assembler and the Debugger.

I didn't know you added that feature. I hardly ever look at the options.

[8BIT]

I'm almost done with the updates and bug fixes. I finally had to dig into the binary file formats to ensure all load and save options had 16MB address space capabilities. This lead to testing with the Binary Program format (.65p). It was asked previously, what is the difference between the Binary Image format (.65b) and Binary program format? For saving, there is no difference. The exact same code is used for both. On loading, its very different. The Binary Image just takes 1 big chuck from start to finish and loads it. The Binary program was designed to take multiple chunks that are not sequential. Similar to how the Intel Hex and Motorola can have multiple chucks. The exact format for the file is:

Code: Select all

Block    Start     End 
Marker  Address   Address  Data to fill that block
0xFFFF  0x8000    0x80FF  [0xA9 .... 256 bytes of code ... 0xEA]

The subsequent blocks can optionally have the 0xFFFF marker or just start with the Starting address. The file has to be sized exactly to hold the data set(s) with no extra bytes.

I looked back to the earliest source code that I have (1.2.6) and it has not been changed. It looks like Michal never implemented the save code to output a file in the .65p format. I do not plan to do so either as I have no specification to pull from, and the existing load code will not support 24-bit address ranges. At least now I have a better understanding of the format.

I will hopefully be able to release the V1.3.3 and its source code in the next 2 days. This will handle 16MB address space for 65816 assembly and object output and still be fully functional for 6502 and 65C02 processors. I don not plan another release (unless to fix reported bugs) until I have the 65816 debugger ready. I expect that will take quite some time as my time after the first of the year will be much more limited.

thanks all!

Daryl

[BigDumbDinosaur]

8BIT wrote:

...This lead to testing with the Binary Program format (.65p). It was asked previously, what is the difference between the Binary Image format (.65b) and Binary program format? For saving, there is no difference...It looks like Michal never implemented the save code to output a file in the .65p format. I do not plan to do so either as I have no specification to pull from...

I believe his original plan was to have a 16-bit load address in bytes 0 and 1 of the .65P file structure, which would conform to the way eight bit Commodore computers save programs. These days, that likely isn't a big deal for most 6502 addicts—in my case, it's been nearly 10 years since I last fired up my C-128D.

Quote:

I will hopefully be able to release the V1.3.3 and its source code in the next 2 days. This will handle 16MB address space for 65816 assembly and object output and still be fully functional for 6502 and 65C02 processors.

Sounds good!

Once again, thanks for stepping up to the plate on this. At one time I had ideas of tinkering with Mike Kowalski's creation. However, I don't particularly like C and like C++ less...and like Microsoft's version of C++ even less. So my hat's off to you for diving in and extending the software.

[8BIT]

I have finished the testing on v1.3.3

This version adds 16MB address space for assembly of 65816 code. It also allows 16MB binary, intel-Hex, and Motorola S record file output.
I also added the * to the file title bar to indicate the contents have changed.

Attached are the executable and source files.

Please let me know if you have any issues with either.

Daryl

[8BIT]

BigDumbDinosaur wrote:

Once again, thanks for stepping up to the plate on this. At one time I had ideas of tinkering with Mike Kowalski's creation. However, I don't particularly like C and like C++ less...and like Microsoft's version of C++ even less. So my hat's off to you for diving in and extending the software.

You are very welcome. It gave me a chance to expand my skill set and provide something back to our community. I too have benefited and appreciate the advice and encouragement everyone has given me along the way.

I hope many will find it useful.

Wishing everyone the best in this year of years!!

Daryl

[jdimeglio]

Bug found

Sorry guys i know Daryl been the man on this but i believe ive found a bug.
See attached example. Basically if i use (using 65C02)

jsr $1000
.ASCIS ESC,"[s"

I should be getting the following bytes $20,$00,$10,$27,$5b,$f3 but instead I get $20,$00,$5b,$f3
So $10,$27 goes walk about. However using .ASCII works fine.

Thanks in advance..