Kowalski Simulator Updates

[8BIT]

I discovered that wanting to code a absolute long address mode with a variable that was word-sized resulted in the instruction getting coded as absolute. it seems that the backslash is the only special character not used, so I tried it as an experiment.

Code: Select all

long = $123456
word = $007890

BF 56 34 12     LDA long, X  ;   good
AD 90 78        LDA word     ;   wanting long addressing mode
BF 90 78 00     LDA \word, X ;  got long mode

Its not really elegant but its functional. It works with BYTE sizes values as well and even works when numbers are used in the operands. I get a "value exceeds 16 bits" error once in while but its pointing to the *= line. Pressing Assemble again and the error goes away. I need to trace the source of that issue down. Still more work before its ready for release.

Daryl

[8BIT]

8BIT wrote:

I discovered that wanting to code a absolute long address mode with a variable that was word-sized resulted in the instruction getting coded as absolute. it seems that the backslash is the only special character not used, so I tried it as an experiment.

I have updated this a little to increase flexibility. I've added a numeric after the \ to indicate the number of bytes to use. This allows for specific modes when needed, such as forcing Absolute long in bank zero, or using absolute vs. direct page addressing for addresses < 256.

The format looks like this:
\1 byte sized - takes least significant byte of the operand
\2 word sized - takes least significant 2 bytes of the operand
\3 long sized - takes full 24 bit value of the operand

Code: Select all

long = $123456
word = $007890
byte = $89

BF 56 34 12     LDA long, X  ;   good
BF 90 78 00     LDA \3word, X ;  force long mode
BF 89 00 00     LDA \3byte, X ;  force long mode
BD 89 00        LDA \2byte, X ; force absolute mode vs direct.
BF FF FF 00     LDA \3$FFFF, X ; can be used with numeric constants also.

My next task is to expand the memory coverage to the full 16MB space, and address any issue that get found along the way.

Daryl

[BigDumbDinosaur]

8BIT wrote:

I have updated this a little to increase flexibility. I've added a numeric after the \ to indicate the number of bytes to use...

Cool! Do you have code you can upload so it can be exercised?

[8BIT]

BigDumbDinosaur wrote:

Cool! Do you have code you can upload so it can be exercised?

As soon as I get done testing it, I'll post it.

Daryl

[8BIT]

*** EDIT *** I have updated the zip file with the corrected program. The Missing ORG error is fixed.

Here is the latest version - 1.3.2

It includes the \x overrides I mentioned previously, a few fixes, some added features, and updated help.

Features added:

Code: Select all

     .XWORD  $123456     ; 24 bit constant declaration
     .DX     $123456

     .DWORD  $12345678   ; 32 bit constant declaration
     .DDW    $12345678

     .DATE               ;  inserts ASCII date in the format YYYY-MM-DD into the output file.  It is not null-terminated.

     .TIME               ; inserts ASCII time in the format (24 hour time)  HH:MM:SS.  It is not null-terminated.

     COP       #$00      ; you can insert an immediate value after COP   -  $02 $00
     COP                 ; or you can have just the opcode - $02

I also added all of the 65816 opcodes to the help file along with the new 65816 mode chart. There is a new page on overriding the operand sizes as well, which covers immediate '!#' and '\1', '\2', and '\3'.

The assembler makes an assumption that any undeclared variable will be 16 bits by default. If it later is found to fix in 8 bits or 24 bits, it will adjust the output accordingly. However, if an address label value changes between the first and second pass, a "Phase Error" will be generated. This is not new, but may be encountered more often with the increased possibility of operand size changes. This can be hard to troubleshoot as the error will tell you where the label is, but not where the variable size change happened. It would require a major rewrite to allow better error reporting. I am investigating other options.

Please give this a try - try to use the new features, and let me know if you find any issues.

thanks!

Daryl

[BigDumbDinosaur]

8BIT wrote:

Here is the latest version - 1.3.2...

Downloaded. I will see if I can test-assemble POC V1.2 firmware (~13,000 lines of code) with some gratuitous 24- and 32- values sometime later in the day.

Quote:

It includes the \x overrides I mentioned previously, a few fixes, some added features, and updated help.

Features added:

Code: Select all

...
     COP       #$00      ; you can insert an immediate value after COP   -  $02 $00
     COP                 ; or you can have just the opcode - $02

Pedantically, a signature byte should be required with COP to comply with the WDC standard. This is unlike BRK, in which the signature has historically been optional.

Quote:

The assembler makes an assumption that any undeclared variable will be 16 bits by default. If it later is found to fix in 8 bits or 24 bits, it will adjust the output accordingly. However, if an address label value changes between the first and second pass, a "Phase Error" will be generated...

The means to avoid this sort of problem is simple: declare values that are not 16 bits before you use them. This is no different than what happens in many assemblers when a zero page address is referenced before it is declared.

[jdimeglio]

Let me start by saying its awesome to see the Michal Kowalski Simulator continue to be developed.
In fact i personally found it pretty hard to a *latest copy, that i created a latest github repository just to store a copy of it.

I "wrote" a monitor with code borrowed/inspired from San Bergmans (with permission) two pass assembler, KRUSADER (MOS) disassembler, code tracer, and usual commands (is for a 65c02 only that i built in 1992 - this CONVID-19 stuff hashed out some old projects and wanted it to be "polished" as i can afford the extra space in the ROM. I've also added LCD 16x2 code..

Anyway when i run it on version 1.3.2 i get "ERROR E032: Missing .ORG directive-..." yet when i run it in 1.2.15 i have no issues. Full source is here:

https://github.com/jdimeglio/6502-Monitor

[8BIT]

jdimeglio wrote:

...Anyway when i run it on version 1.3.2 i get "ERROR E032: Missing .ORG directive-..." yet when i run it in 1.2.15 i have no issues.

Hello and thank you for posting. I created a bug while trying to expand the memory beyond 64k. The last line of your code is causing the error because after the .WORD directive writes the Interrupt vector, it advances the internal program counter to $10000. I am working to reverse the bug I created.

If you comment out that last statement, it will assemble without error.

I'll post the revised v1.3.2 sometime today.

thanks!

Daryl

[BigDumbDinosaur]

jdimeglio wrote:

Anyway when i run it on version 1.3.2 i get "ERROR E032: Missing .ORG directive-..." yet when i run it in 1.2.15 i have no issues. Full source is here:

https://github.com/jdimeglio/6502-Monitor

In the future, it will be more convenient for other forum members if you attach files to your post instead of requiring that they go off-site to examine them. For some of us, github is a nuisance—I generally do not look at stuff stored there.

In any case, I see Darryl addressed the E022 error. This problem can be provoked with either .BYTE followed by two bytes, or .WORD.

For future reference, the first line in your main source file should be an .OPT directive to set the target MPU (65C02, 65C816, etc.), as well as whether case matters in non-quoted strings and optionally, if % should represent a binary value, e.g., %01011010, instead of @01011010. At the least, it's best to be specific about which MPU is the target; the assembler may otherwise make faulty assumptions.

As just about all of my work in Kowalski is targeted to the 65C816, the first line in my main source files is:

• .opt proc65816,caseinsensitive,swapbin

which tells the assembler that 65C816-specific mnemonics and addressing modes are to be recognized, non-quoted text is not case-sensitive, and % is the radix for binary values—@ becomes the symbol used in macros to represent positional parameters.

The other MPU types recognized are proc6501, proc6502 and proc65c02. Note that when the 65C02 is set as the target MPU what is being simulated is the Rockwell part, not the WDC (current production) part. The WDC part has two instructions, STP and WAI, which are not recognized as valid by the assembler (however, they are recognized if the target MPU is the 65C816). Furthermore, if the target MPU is a 65C02, DEA and INA are the valid mnemonics that decrement and increment the accumulator. On the other hand, if the target is the 65C816, DEC and INC without operands are the valid mnemonics that decrement and increment the accumulator.

As I said, the .OPT directive should be the first line seen by the assembler during assembly. It will not appear in the listing file.

[BigEd]

(we all have preferences... I like to see projects hosted somewhere convenient, and I find github convenient. Let's not suppose any one person's preferences are ideal. That said, I think there is consensus on images: best to attach them to a post. Too many times externally hosted images have vanished.)

[cjs]

BigDumbDinosaur wrote:

In the future, it will be more convenient for other forum members if you attach files to your post instead of requiring that they go off-site to examine them. For some of us, github is a nuisance—I generally do not look at stuff stored there.

Well, emphasis on some other forum members. While I feel an equal amount of annoyance to BDD in this case, it's aimed in the opposite direction: I find GitHub a lot more convenient than downloading a file and viewing it, and especially more convenient than dowloading multiple files or dealing with unarchivers. Clicking a link or two and having the code pop up immediately in that same web browser window is (for me, anyway) invariably much faster. When I do want a set of files locally, a simple `git pull` is much faster and easier for me than dealing with manual downloads and unarchivers and the like.

Probably the best solution (and the one I use) is to give a link to the repo, but also attach here any specific files that are particularly relevant, even if they don't include the build and test system that some of us would consider de rigueur for any close examination of code.

This has been discussed (or "discussed" :-)) before; I wonder if it's worth spending the effort to build a little document describing the opinions and options so that one could just link to it.

[GARTHWILSON]

I definitely shy away from github myself.  It has several characteristics I heavily dislike, and I can never find what I want.  I don't know if the latter part is just the way github works, or if it's because users don't organize and name their folders appropriately; but I wander around their folders and pages, and finally give up and move on.  So now when someone posts a github link, I usually just skip over it now.

When I post sample code of my own, I just give a link to my website, for example http://wilsonminesco.com/6502primer/GENRLI2C.ASM or http://wilsonminesco.com/6502primer/SPI.ASM, where a single click will bring up the page or index to a group of pages.  I recognize that not everyone can easily set up their own website; in fact, it was our web-savvy son who set up mine for me.  Posting something is as easy as copying it to another hard disc on my computer, as the website just shows up as another drive in my file browser.  I do wish he would write up the simple steps to starting one's own website and registering your domain name with DNS (which is easy and nearly free).

[8BIT]

In case anyone misses my edited post above, here is the fixed version 1.3.2.

Daryl

[jdimeglio]

Sorry still got bugs.

So when i run up my polished monitor it assembles (f7), it debugs (f6) and Run is highlighted (f5). Hitting Run does nothing other then grey out all the options.
I've tried to step in rather than run, even place a breakpoint on RESET.

Is this worth fixing? Are there any more 65C02 die-hards out there? or am i just better off using an older version..

PS:@BigDumbDinosaur i added .OPT proc65C02,swapbin (and removed it and all the @<->% in troubleshooting this issue)

[BigDumbDinosaur]

8BIT wrote:

In case anyone misses my edited post above, here is the fixed version 1.3.2.

Everything appears to be copacetic with it. It successfully assembled the POC V1.2 firmware.

Good job!

poc_listing.txt

POC Firmware Listing

(586.06 KiB) Downloaded 142 times