Kowalski Simulator Updates

[Yuri]

8BIT wrote:

.START was included to allow for code to be compiled with data tables being placed before the code. .START would point the simulator to the desired start code. You do the same thing without it by adjusting the PC before running the sim.

Not sure I see how that is any different than assigning the startup value to FFFC/FFFD which you'd need to do on an actual 6502/65816. Which is easy enough to do with a label in a .WORD directive. This is more inline with how other assemblers work, which AFAIK don't have a .START directive.

Quote:

With the 65816, setting .START above bank 0 will start the code running, but the E bit is still set and many operands will be addressed in bank 0 vs the start bank. Clearing the E bit allows the code to run but I encountered some strange effects when invoking NMI and IRQ. Before I make the changes, I want to dig deeper and ensure I don't break other things too. The work around is to place some small startup code on bank 0 that gets the CPU into native mode and jumps to the desired START address above bank 0.

At the end of the day it sounds like you're twisting your brain trying to figure out how to support something that you can't do on actual hardware. I'm not sure I understand the value of doing that if the goal is to try and provide an environment to debug code for that hardware.

If you want to keep the .START directive, I would think it would be simple enough to have the assembler flag an error if it is set to anything above the max 64KB space.

(Though I still think it makes more sense to just get rid of it entirely.)

[8BIT]

Hi Yuri,

I understand your thinking, and mostly agree. This program is not just an assembler however. It's more of an IDE that includes assembler and simulator. Michael Kowalski put the .START there so I don't really want to remove it. It's a bridge to allow custom jumping from assembler to simulator. Its possible the program would not start at the beginning (lowest) address of the source. That is the only function of .START.

I can see its benefit for software development on an application level, where the author is working on an application but does not have the underlying operating system. The program starts without regard for how the system was booted, so using the reset or interrupt vectors would not work.

In that regard, it might also be practical to allow it to work above bank 0 as well. I just want to be sure the simulator will function reliably, so will not expand it until I have confidence it will function without fault.

I think of a system where video memory might be in the lower address space and the program would load above that. The author might want to place a splash screen image at the beginning of the source with the program start afterward. Using .START would allow the assembler to build the data table first followed by the code. Jumping from assembler to the Simulator would start the execution at the code vs. the data table. This is just one example.

As with any feature, the user has the choice to use it or not. Here's a personal example: I do not like using the case insensitive directives or the processor directives in my code. I prefer to set those on the Options tab of the program. Others do like them and that is why Michael included them. I'm trying to keep with his philosophies.

Have a great rest of your day!

Daryl

[BigEd]

(For what it's worth, I'd support the simple solution of START being restricted to Bank 0.)

[8BIT]

Thanks Ed. It will remain restricted to Bank 0. Someday, maybe, I'll get around to a further study of expanding it.

I have re-uploaded the source and executable files to my website, removing the diagnostic code from the IOWindow that Yuri found several posts back. No rev change.

Thanks!
Daryl

[BigDumbDinosaur]

The .START directive not only affects the execution address used by the simulator code, it also influences the address field of an S8 or S9 record when S-record is selected as the object output.  In an S-record loader that is “properly designed,” the starting execution address of the loaded program will be established by decoding the address field of the S8 or S9 record that terminated the load.  Hence limiting .START to work only with bank $00 would cripple functionality that Mike Kowalski built into the package.

The way in which I discovered that .START wouldn’t work with a 24-bit address was in assembling my master boot record (MBR) generator to run in bank $01, which is where I intended to run the generator.  The MBR code itself is loaded at $000100 during boot time, but for convenience, the MBR code’s source is INCLUDEd in the generator source code—the generator itself assembles at $0800 and is bank-agnostic.  Hence a statement in the main source file sets .START to the starting execution address of generator at $xx0800, not that of the MBR code, which would be at $xx0100.

8BIT wrote:

With the 65816, setting .START above bank 0 will start the code running, but the E bit is still set and many operands will be addressed in bank 0 vs the start bank.

...which makes perfect sense, because with actual hardware, that would be the default behavior if the 816 is in emulation mode.  It’s incumbent on the programmer to select native mode if his/her code is written to run that way.

[8BIT]

BigDumbDinosaur wrote:

In an S-record loader that is “properly designed,” the starting execution address of the loaded program will be established by decoding the address field of the S8 or S9 record that terminated the load.  Hence limiting .START to work only with bank $00 would cripple functionality that Mike Kowalski built into the package.

I forgot I added the S8 support on the Motorola S Record code for program start above bank 0. The work around for now will have to be manually replacing the S9 record with an hand-generated S8 record.

Thanks for pointing that out. When/if I get more time, I'll dig a little deeper into the Simulator code.

Daryl

[Yuri]

BigDumbDinosaur wrote:

The .START directive not only affects the execution address used by the simulator code, it also influences the address field of an S8 or S9 record when S-record is selected as the object output. In an S-record loader that is “properly designed,” the starting execution address of the loaded program will be established by decoding the address field of the S8 or S9 record that terminated the load. Hence limiting .START to work only with bank $00 would cripple functionality that Mike Kowalski built into the package.

In an S-record loader that is “properly designed,” the starting execution address of the loaded program will be established by decoding the address field of the S8 or S9 record that terminated the load.  Hence limiting .START to work only with bank $00 would cripple functionality that Mike Kowalski built into the package.

If we're talking about writing out to a file that tries to impart some additional meaning to the values than a flat binary dump, then .START directive makes perfect sense. E.g. S-Record, or maybe an ELF or other format that might want to provide an OS info on where a program's start function actually is. (Thank you for clearing that up for me BDD)

This point is somewhat muddied inside the code as the assembler doesn't really directly output any of these files. It just writes directly into the simulator memory, and bits of info get lost amongst the sea of things that happens between the assembler completing and (maybe) the user selecting the option to save the code.

Also had it in my head for some reason that the start address was settable directly from the UI. Seems that's only the case from the load code options. (Of which I have not fully finished those or worked out all the details of their needs in the port.)

8BIT wrote:

This program is not just an assembler however. It's more of an IDE that includes assembler and simulator.

Actually kind of my point really. As the program is all of these things, it makes it all the more important that the assembler (and other parts) maintain as little access to each other as reasonably possible.

The assembler really should be agnostic to the idea that it's making stuff for the simulator. As such, it's output would be more likely to work on actual hardware, not just in the confines of the simulator.

One of my goals is to move the assembler portion into it's own standalone command line interface, with the intention of being able to use it inside of a build script, or as I believe BDD noted, could be run from any editor the user so chooses. If the .START just updated the UI's idea of the start address; then that kind of defeats the point of it continuing to be there. However, I see now how that can be handy for the reasons that BBD just pointed out.

The simulator really shouldn't be making any assumptions that the code was generated by it's own assembler. If you load up a raw binary generated by the CA65, WLA-DX, or whatever else, it should work (obviously baring the lack of other support hardware those binaries might be looking for e.g. a 6522).

Additionally (and the simulator portion is REALLY bad about this, as this is the #1 thing that is giving me heart burn with the port), the simulator shouldn't be making direct access to the UI. (The MFC version loves sending raw Win32 messages itself, and has hard references directly to the UI classes).

As for the .START in of itself, it does look like the assembler does not just reach into the UI and adjust it's idea of what that value should be. (Yeay!) It is the UI that asks for the assembler for the result of that, and doing what it needs to with it. (This is good, and as I would expect it to be.)

THAT being all said and done. If you still want to be able to support .START from any location in memory; I think you're looking at possibly more than just trying to work out what the E flag is doing. Code in that area is almost certainly going to be expecting various other things to be initialized. (E.g. the stack pointer, the various bank registers, etc.)

[ OKAY, rambled on long enough... time for me to sleep..... x_x ]

[8BIT]

I have come up with a solution for the .START issue above Bank 0.

The assembler now accepts the higher address and will save the Motorola code with the S8 record.

When starting the Simulator, this warning will pop up whenever the start address is above Bank 0.

Note, this will also happen without the .START directive if the source .ORG is above Bank 0. (this was a previously unreported bug. Simulator would start at the right 16-bit address but in Bank 0.)

My goal is the allow the assembler to produce usable code for export to real hardware while also allowing simulation to be as seamless as possible. I hope this satisfies both.

Update 1.4.0.8 is on my website --> https://sbc.rictor.org/kowalski.html

EDIT: As a side note, .END had the ability to accept a parameter that didn't really make sense to me. The parameter was also not in the help. I removed that feature so now .END is as the documentation reads.

thanks!
Daryl

[BigDumbDinosaur]

8BIT wrote:

I have come up with a solution for the .START issue above Bank 0...

Sounds like a good solution.

I have only used the simulator once in 816 native mode, and in that use, I had front-end code in the program to put the 816 into native mode, configure DP and SP, etc..  That usage normally wouldn’t reflect a real-world application, but, of course, was necessary to make sure simulation was correct.  Things I have coming up software-wise will have algorithms that will be easier to test and debug in simulation instead of in hardware.  So I expect that with Daryl’s many improvements to the simulator, I will be giving it much more “exercise” than in the past.

In particular, code that dynamically uses the stack (easy to do with the 816) has always been somewhat challenging to debug on live hardware—an unbalanced stack upon a function’s exit frequently causes a crash and a forced reset.  When that happens, the test conditions are destroyed and debugging becomes a trial of inference, rather than an exercise in analyzing machine state.  I had more than my fill of the inference debugging approach when I was writing the firmware primitives for my POC units, especially the SCSI driver.    Any opportunity to avoid that is always welcome.

Quote:

My goal is the allow the assembler to produce usable code for export to real hardware while also allowing simulation to be as seamless as possible. I hope this satisfies both.

It sounds as though you have achieved this goal.  I will give it a spin and report back.

Quote:

EDIT: As a side note, .END had the ability to accept a parameter that didn't really make sense to me. The parameter was also not in the help. I removed that feature so now .END is as the documentation reads.

Hmm...I wonder what that was all about?  Try as I might, I can’t envision anything that .END would do other than mark the end of a source file.

[BigDumbDinosaur]

After loading simulator version 1.4.0.8 on my elderly Windows XP box, I test-assembled my new-and-improved™ S-record loader, starting at address $010200, followed by loading and running it on the POC hardware.  Everything seemed to be okay.  Source code and assembly listing are attached.

loader.asm

65C816 S-Record Loader Source Code

(62.9 KiB) Downloaded 209 times

srecord_loader.txt

65C816 S-Record Loader Assembly Listing

(84.51 KiB) Downloaded 202 times

[8BIT]

While testing some 16 bit BCD math, I found a small bug in the register windows of the simulator. 16 bit results were only updating as 8 bit in the Acc register. The actual Acc contents were correct.

I tested 512 samples each for BCD ADC and BCD SBC. Results matched the 65816.
Test values were 0000,1111,2222 - EEEE, FFFF for Acc and operand with and without carry.

I have fixed that bug and version 1.4.0.9 is on my website --> https://sbc.rictor.org/kowalski.html

Daryl

[BigDumbDinosaur]

I have encountered what may be a pair of bugs during 65C816 native-mode simulation.

If the stack window ([Alt-4]) is opened during simulation, it will only display one page of memory.  As the native-mode stack pointer (SP) is 16-bits wide, the stack window should not be limited in this way.

The other bug occurs if SP is set to something other than $01xx.  The following code, if run with the stack window open, will illustrate the problem:

Code: Select all

init     clc
         xce
         rep #%00100000
         lda !#$b8ff
         tcs
         brk

After the above is run, the stack window will shift range, but it will be displaying the $B9xx page, not $B8xx.

[8BIT]

I will work on these 2 items as time permits.

Thanks for pointing them out.

Daryl

[BigDumbDinosaur]

8BIT wrote:

I will work on these 2 items as time permits.

Thanks for pointing them out.

You’re welcome.

There may be another issue involving DP (direct page pointer) when it is set to something other than the default $0000, but I haven’t yet determined if it is a bug in my code or a bug in the simulator’s code.  It has to do with temporarily pointing DP to SP+1 in functions (subroutines).

[Yuri]

8BIT wrote:

While testing some 16 bit BCD math, I found a small bug in the register windows of the simulator. 16 bit results were only updating as 8 bit in the Acc register. The actual Acc contents were correct.

I tested 512 samples each for BCD ADC and BCD SBC. Results matched the 65816.
Test values were 0000,1111,2222 - EEEE, FFFF for Acc and operand with and without carry.

I have fixed that bug and version 1.4.0.9 is on my website --> https://sbc.rictor.org/kowalski.html

Daryl

Fell a bit behind on updating the Github for this, but this has been done now.