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

_________________
Please visit my website -> https://sbc.rictor.org/

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

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.

_________________
Curt J. Sampson - github.com/0cjs

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

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.

_________________
Rich Cini
Build Master and maintainer of the Altair32 Emulation project
http://cini.classiccmp.org
http://altair32.classiccmp.org

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.


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

_________________
Please visit my website -> https://sbc.rictor.org/

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

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.


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

_________________
Please visit my website -> https://sbc.rictor.org/

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

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

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:


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

_________________
Please visit my website -> https://sbc.rictor.org/

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

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

_________________
Please visit my website -> https://sbc.rictor.org/

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

_________________
Please visit my website -> https://sbc.rictor.org/

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..

_________________
_________________________________________________________________________
Checkout my 2pass assembler/monitor https://github.com/jdimeglio/6502-Monitor