Hi guys

Here's a basic video showing off my new 6502 assembler which I've given the original title of "6502 Code Assembler" to.
For those who view it, I'd suggest in 720 or 1080p to see the text clearly. I apologise in advance for the mouse pointer seeming to disappear at times when hovering over the assembler: This is a quirk of the FRAPS video recording and does not happen outside of FRAPS.

One thing I forgot to demonstrate is the simple math it can handle such as x = 100 + 300 or x = y + 10. it can do a single +, -, /, *, DIV, MOD per variable assignment.

http://www.youtube.com/watch?v=-hOXCVdJOm0

I see some very handy features there!

This much more than an assembler, it is also a simulator!
I really like that.
Keep us posted of your progress!

Thanks for making that demo video. If I've understood, the debug/stepping mode is purely for debugging the assembler, not the project code: nothing wrong with that, but presumably useful mainly to you or co-developers, not to end-users?
Cheers
Ed

Unfortunately, it's not a simulator. For that it'd have to actually run the assembled code which it doesn't, I'm afraid.
I *could* write a simulator if there was a demand, but I'm not sure that there would be a need for most folks.




The debug mode is more useful for debugging changes in variable (i.e. symbolic links as someone on the forum has advised) values more than anything else and what the program counter is doing.
For most projects the debug modes wouldn't be needed for the most parts - I just got carried away when trying to think of features .


I've still got some work to do on the project: namely implement the "alternate program counter" O% (there's probably another term for this somewhere), ability to change the colour scheme, save options, etc..

Do you guys have any suggestions for useful features that you normally look for in an assembler? I want this to be useful to others as well as myself.

forum topics:
desirable assembler features
assembler macros!
Using assembly macros to raise the level of the language

For ideas of what others have done, you could take a look at the links in the programming section of my links page, at http://wilsonminesco.com/links.html#soft . One of the links also goes to a web page with lots more links to 6502/c02/816 assemblers.

_________________
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?

It might be worth considering writing a simulator - what you have is perhaps only a simulator short of Kowalski's program, and that seems quite widely used. You'd have the advantage of documentation in English, too. I think there's plenty of scope for helping debug by adding the right features to a simulator - breakpoints, watchpoints, counted triggers, stepping over subroutine calls.
Cheers
Ed

A feature of Kowalski's simulator that I've often used is its ability to count clock cycles as it runs. Although the simulator can't run 65C816 code, it can run Rockwell-style 65C02 code. From that, I've been able to work out areas in POC's firmware that could stand to run faster.

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

Hmmm ok. I've never written a simulator/emulator before, but it can't be too hard

Proposed features list:

Run 6502 code(!)
Run 65C12 code (optional)
Run 6502 illegal opcodes code (optional)
keep track of program counter, flag (CZIDBVN) changes, register (AXY) changes
Keep track of CPU cycle count
Support for the h/w vectors entry points (&FF
Support for the hard coded stack at address &100 (256)

I could try and throw in support for 6522, but I'd have to learn how they properly work first lol

How important is real-time accuracy on how fast the code runs? I ask this as I can give this a go, but it might prove a challenge. Would it be acceptable to have the emulator calculate the speed from the CPU cycles and report it at the end?

Anything vital that I've missed?

[edit] BTW many thanks for the assembler links. I've looked through a few and most seem to be talking about creating an assembler which is in effect a high level assembler which uses local variables, code blocks etc.. I'd have to go through and change quite a bit to do that and would be a large project all by itself.

I'd put no emphasis at all on trying to make the simulator realtime - it's tricky, and unless its 100% accurate it's not terribly valuable. Reporting clock counts is very worthwhile though.

On my (only) Windows box, the Kowalski simulator appears to run at 10 MHz when in 65C02. As you say though, actual cycle counts are what really matter if trying to optimize code.

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

Way back when (fifteen years ago or so) I had written a simulator that would run a nearly-two-MHz CPU plus video hardware plus audio synthesis at pretty close to realtime speed on a 133MHz pentium. It was, however, finely tuned for the specific hardware it was simulating and the CPU simulator itself was written in assembly language.

I was later horrified at the documentation for a (slow!) commercial Z8 CPU simulator which claimed that it took hundreds of host CPU cycles to simulate a single Z8 instruction. Now, fifteen or so years later, I'm still horrified as I think about it. A ratio that high is unconscionable unless you're getting good value from the additional code.

On the whole, however, the interesting case for the former was being able to run close enough to realtime to be able to play games on it, and the latter was basically a toy that we ignored in favor of using an in-circuit emulator to verify that our code was functioning correctly (combined with a spectrum analyzer, plus some kind of power line conditioner to keep the 60Hz line noise plus whatever else was on the local circuit out of the system, plus massive ferrite "beads" between our desktop machines and the ICEs and the ICE and the actual circuit)...

Anyway, with modern computers it's easy enough to simulate a CPU (and possibly other hardware) faster than "realtime" if "realtime" involves a clock speed of 5 MHz or less (and possibly more), even to a decent degree of fidelity. Once you're at that point, keeping things slowed down to realtime is a separate problem.

I'm using the New Advanced User Guide for the BBC Micro to look up the main assembly instructions. I've noticed that some of them suffer from an additional cycle when crossing a page boundary. Is something that afflicts all versions of the 6502? An example: AND with "Absolute,X", "Absolute,Y" and "(Indirect),Y" addressing modes.
From what I can tell it seems to be so, but just thought I'd check with you guys.

They all do it. It's not a bug though. If the indexing resulted in the low byte carrying, then an extra cycle is taken to increment the high byte. WDC's data sheets give the info on every single bus cycle.

_________________
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?

Relative branches that are taken across a page boundary have the same behavior, for the same reason. I believe that zp,x zp,y (zp,x) don't follow this pattern, because they 'wrap' :

Methods to prevent the assembler from 'optimizing' the third instruction to zp,x exist, but differ from assembler to assembler.

Mike