Hi All,

Has anyone worked with the 6502 Macroassembler & Simulator?

http://members.nbci.com/mkowalski.1/6502.html

It is an integrated development environment for the 6502 that runs on Windows and includes an editor, assembler, and simulator. There are some bugs, the most crippling of which is one that incorrectly assembles JSR return addresses. I have recently been talking to the author, Michal Kowalski, about fixing bugs in the program and adding some features. He is working now and hopes to have a new release out in a week or so.

I think the program has the potential to be a great tool like Microchip's MPLAB or Atmel's AVR Studio. I would appreciate if anyone cross-assembling on the PC would check it out and send (or post) comments and suggestions regarding the program.

_________________
- Mike Naberezny (mike@naberezny.com) http://6502.org

Hi All,

Immediately after posting this the author released an update which fixes the most serious problems. Let's all check out the program and put it through its paces.

Best Regards,
Mike

_________________
- Mike Naberezny (mike@naberezny.com) http://6502.org

I haven't fiddled with it (yet) but I agree a good macroassembler is a good thing to have around.

I'm curious whether anybody has looked at the task of emulating a 6502 in a UBICOM (formerly SCENIX) SX48 at 100 MHz. It's a task I've considered from time to time, but one that I haven't gotten into yet. It seems to me that one should be able to write an emulation that would, on the average, outperform the fastest avaiable 6502's of today, and, since it's reprogrammable and cheap, and small enough to fit on a 6502 footprint, might be of practical use.

A fast CPU would surely contribute to extending the life of this old architecture.

Uli

Hi,

Michal's "6502 Macroassembler and Simulator" includes a good macroassembler but there are already many excellent ones available. What makes this package so nice is that the program includes an integrated editor and most importantly, a simulator. The simulator lets code be run or "animated" while you watch memory and register windows. You can set breakpoints and single-step. There are a few bugs left in it (the simulator portion) but they are quickly being ironed out. Lee Davison has successfully run his monitor program in the simulator and is now working with the author to nail down the few remaining problems which will let his BASIC interpreter run.

The author is actively developing and improving the program. I'd strongly suggest that anyone check it out and send him feedback about it.

Regards,
Mike

_________________
- Mike Naberezny (mike@naberezny.com) http://6502.org

That sounds like a nice feature set. I've got some reservations about integrated editors, since I've had countless disappointing experience, but it's a popular solution. I am curious which model the simulator follows. Is it the MOS Technology version, the Synertek model, or the Rockwell CMOS version?

Uli

Actually I've been putting my head together with a friend of mine to do just that. We've done some tests, and a 50 or even 100Mhz 65xx would be more than possible. The only real issue is marketability, who would want such a chip?

The market for such a CPU, particularly at high clock rates >100 MHz, but principally as an IP-core for use in CPLD/FPGA applications. The 6502 core should be really useful for moving data around. Consider, for example, its potential for use in a TCP/IP implementation in hardware.

Uli

Hi,

If you don't like the editor you can develop your code in another program and just load it in. There are benefits to using the built-in editor such as syntax checking as you type.

The assembler has two modes of operation, one for the original NMOS 6502 opcodes (MOS) and the other for the extended CMOS set (WDC).

Regards,
Mike

_________________
- Mike Naberezny (mike@naberezny.com) http://6502.org

Yes, I know is't often an option to use an external editor with arrangements such as you describe. As I said before, I've had mixed results with packages written around an Editor-Assembler-Simulator model, and my experience has made me wary, as the problems, so far, have always come from the editor, mostly in that the editors (two that I can think of right away) have attempted to follow the "WordStar" model, which is what the various "Turbo" tools have used, but, in each case, the author has been unwilling to make his/her editor comply with the model strictly enough that the editor didn't get in the way. This became most obvious to me at a time when I was trying to use two such arrangements at the same time, constantly tripping over various inconsistencies with the WordStar model (with which I'm VERY familiar).

Now, that's just an example. I'm not suggesting that that's a problem with THIS package, but it's the sort of seemingly minor problem that comes up with firmly integrated development packages, but which can seriously impede one's progress. It's really not very difficult to write a program that seamlessly attaches an external editor, thereby getting around the need to learn the quirks and foibles of a tool that really shouldn't be allowed to interfere with progress.

Too many of these thingies are vestiges of school projects, wherein someone writes a full-screen editor in their freshman Pascal or 'C' class and thinks it needs to be given a life of its own. Thousands of these are written every week, all purportedly following the "Turbo-Editor" model, yet all different. Some of them are even pretty good, yet still don't really hold themselves to the spec.

When you're writing code for a project on a fixed schedule, the last thing you need is to learn a new editor.

The reason I feel so strongly about this is that I've been SO disappointed by the various editor problems I've seen, that have made using the assembler/simulator such a PAIN that it's been unpleasant, when it didn't need to be.

Uli

How do you do I/O in the simulator? The author's web page shows an I/O window, but the download includes no sample source code or instructions for the simulator.

Paul R. Santa-Maria
Monroe, Michigan USA

Also, how do you get an assembly listing?

Paul

>How do you do I/O in the simulator? The author's web page shows
>an I/O window, but the download includes no sample source code
>or instructions for the simulator.

From the Simulator menu select Options (or press CTRL-E). Select the Simulator tab on the options requester and set the I/O window size, start address and make sure the active box is checked.

Then with io-area = the start address you can access the following..

io_cls = io_area + 0 - writing to this clears the output window
io_putc = io_area + 1 - a "glass teletype" output window. Backspace,
CR and LF are actioned
io_putr = io_area + 2 - raw output, bytes are output as their
characters and not actioned.
io_puth = io_area + 3 - hex output, bytes are output as their hex code
io_getc = io_area + 4 - halting character get, will wait for input
io_posx = io_area + 5 - set cursor x position by writing here
io_posy = io_area + 6 - set cursor y position by writing here

It's not a comprehensive I/O function but it does allow monitor code and even high level languages to be run.

Cheers,
Lee.

I've used the july/01 version, I think it's the latest. The lack of docs hindered me in two ways, first I wanted to know how to use the I/O (already answered here), also I don't know how to single step; and when I run animate it moves too quickly.
I tried using this lately for serious development but I keep getting errors with my labels; it will say phase matching error, the label changed between passes. To me, the label looked correct. So I resorted to hand coding absolute addresses but got tired of that workaround pretty quickly
Note: I tried entering code by pasting. I noticed that instructions would change to uppercase if I press enter in the real editor, so I pressed enter on all my lines in case that was "needed" for the program to process my lines.
Another bug, it seems I have to close the variables window between assembling, as the listing in that window won't change during an assemble, and somehow what's in the window is the correct version... in other words if you change a label, you must close the window and reassemble and open the window again.
But, otherwise it's a cool concept and the best I've seen of it's kind.
Since then I resorted to one of the many dos assemblers but that's a real pain - I write in notepad, save (yes to overwrite), type the assemble command in a dos window, copy and paste the object file in two other windows, load the program in my emulator, then run and debug it there - it would sure help to do it all in one environment, at least for the pure 6502 stuff, and the built in I/O is great cause I would spend the extra time writing some i/o routines into my code just to help with the testing.

http://members.nbci.com/mkowalski.1/6502.html is now a dead page.

Paul R. Santa-Maria
Monroe, Michigan USA

> http://members.nbci.com/mkowalski.1/6502.html is now a dead page.

It's moved to http://home.pacbell.net/michal_k/6502.html

The latest version is 1.1.9.19 and is easily the best version yet.

Lee.