Kowalski Simulator Updates

[BigDumbDinosaur]

8BIT wrote:

I have found the reason the registry settings were not being read and have now corrected it. I did not encounter the editor issue reported, and cannot duplicated it, so will need more details if there is in fact an editor problem.

The updated Kowalski Simulator, version 1.2.15 - is attached here.

Thank you all for your feedback.

Daryl

I tried it out and everything appears to be okay, including the editor.

[8BIT]

I'm glad it is working better now. For those interested, here are the latest source code files that produce v1.2.15.

Daryl

[BigEd]

Thanks for picking up this project and continuing to maintain it!

[8BIT]

I'm happy to help out where ever I can. I hope everyone finds it useful.

Daryl

[8BIT]

For those interested, I have also placed the latest source on github, here: https://github.com/DRictor/6502/tree/DR ... 02-v1.2.15

Daryl

[8BIT]

OK, so I thought I'd throw this tickler out.

Yes, I have added support for assembling 65816 code. Right now, it can properly assemble all of the 65816 opcodes and addressing modes, except WDM. The way the code is written, it used one value as a marker for an invalid opcode. For the 6501 and 65C02, there were plenty. The 65816 does not have any invalid opcodes. However, since WDM is reserved for future use, I chose to use it as the marker. You can still have a WDM opcode by using the .DB $42 directive.

As of now, it only operates on the first 64k of memory but I plan to expand that to the full 16MB (24 bit) address space.

Also, the Simulator and disassembler are currently disabled for 65816 mode. That will take a lot more time to complete, if ever.

I am still testing to syntax checker and am working on the memory extension. I will release a copy when I think its ready.

Is anyone interested in this new feature?

Daryl

[BigDumbDinosaur]

8BIT wrote:

OK, so I thought I'd through this tickler out...Is anyone interested in this new feature?

Well, I think you know of at least one dinosaur that would give it a spin.

BTW, you likely already know that internally all values are stored as 32-bit integers. So I'd think it wouldn't be too much of a leap to get 24-bit addressing to work.

One thing I'd really like to see is % used for the binary radix instead of @. You can't imagine how many times I've been tripped up by that over the years.

[BigEd]

Sounds like a great idea!

[8BIT]

BigDumbDinosaur wrote:

BTW, you likely already know that internally all values are stored as 32-bit integers. So I'd think it wouldn't be too much of a leap to get 24-bit addressing to work.

Well, the code uses UINT16 and UINT8 all over the place so right now any address over $FFFF gives errors or gets truncated. I know I can do it, its just going to take a lot of time to go line by line in the code to update address references to UINT32.

Quote:

One thing I'd really like to see is % used for the binary radix instead of @. You can't imagine how many times I've been tripped up by that over the years.

Unfortunately, % is used now for the Modulo function for expressions. I could change it, but then others might have issues with having to change their sources. Had % been available, I could have added it so that either could be used for binary radix and everyone would be satisfied.

Thanks for the feedback!

Daryl

[Chromatix]

One reasonable standard prefix for binary constants is 0b, similarly to 0x for hxadecimal.

[GARTHWILSON]

or putting a B after the 0's and 1's, as in ORA #00011100B, as a couple of assemblers I've used do. 0b and 0x are C language and its derivatives. It is apparently common for assemblers to accept multiple methods of specifying base.

[cjs]

GARTHWILSON wrote:

or putting a B after the 0's and 1's, as in ORA #00011100B, as a couple of assemblers I've used do. 0b and 0x are C language and its derivatives. It is apparently common for assemblers to accept multiple methods of specifying base.

Indeed. I ran into this recently when discussing base specification and symbol names with some MSX folks, as I was wanting to use the Motorola convention ($nn) for hex numbers rather than the Intel (0nnh).*

I was informed that many (most?) MSX assemblers do accept both, that it's not uncommon for MSX programmers to use the Motorola convention, and that there aren't really any technical issues with this. It's even safe to accept tokens matching [A-F][0-9A-F]*h; you just try looking them up in the symbol table first and, if they're not there, you interpret them as a constant. Apparently experience has shown the theoretical conflicts in this scheme cause no serious problems in practice.

___________________
* I had technical reasons for this: I wanted to be able easily to use the same data files included in both 6502/6800 and 8080/Z80 assembly source files. That of course does not change the incontrovertable fact that the Intel convention is morally wrong, a Sin Against God, people who prefer it are evil, it will bring about the collapse of civilisation, etc. etc.

[John West]

% the numeric literal prefix and % the binary operator appear in different contexts, with no overlap. It's always possible to distinguish them, although an existing parser might not be structured in a way that makes it easy. It's similar to * being used for both "current assembly address" and multiplication, or - being used for negative numeric literals and subtraction.

I think I've mentioned it here before somewhere, but my favourite notation is [[radix]$]<number>. A number on its own is in decimal. With a $ before it, it's hex. If there's a number before the $, that specifies the radix. So 10 = $a = 16$a = 2$1010 = 8$12 = 6$14. Base 23 doesn't come up all that often, but if you ever need it, it's there. My assembler accepts % for binary as well, because it's a common convention.

[8BIT]

The parser was not written to allow for the context of % to be distinguished. I do not plan to rewrite the parsing code, but have come up with a workaround for those who want % for a binary radix.

I have created a new option flag "SwapBin" which swaps the symbols % and @ functions. When added to the source, % will be the binary radix and @ will be the Modulo operator.

Code: Select all

     .opt SwapBin

     LDA #%10100101 - returns LDA #$A5
     LDX #13@5  - returns LDX #$03

I hope everyone will find that acceptable.

Daryl

[BigDumbDinosaur]

8BIT wrote:

The parser was not written to allow for the context of % to be distinguished. I do not plan to rewrite the parsing code, but have come up with a workaround for those who want % for a binary radix.

I have created a new option flag "SwapBin" which swaps the symbols % and @ functions. When added to the source, % will be the binary radix and @ will be the Modulo operator.

Code: Select all

     .opt SwapBin

     LDA #%10100101 - returns LDA #$A5
     LDX #13@5  - returns LDX #$03

I hope everyone will find that acceptable.

Daryl

Looks like a good compromise to me. I use binary values much more often than I use the modulo function.