The Kowalski assembler doesn't precisely adhere to the official MOS Technology assembly language syntax, which is definitive for the 6502 family. In the Kowalski simulator's assembler, radices are as follows:

Code:

@   binary
$   hexadecimal

If no radix is present the number is assumed to be decimal. The instruction at line 18, which is lda #%00011110, is using a binary operand whose format is not understood by the assembler. In order fix this error you would write the same instruction as lda #@00011110.

One other note: the Kowalski simulator understands the 6502 and Rockwell 65C02 instruction sets, but not the entire instruction set of the Western Design Center 65C02, the latter which is the prototype for the 65C02. In practice, this isn't likely to cause you any problems, but you should be aware of it. So as to make it clear to the simulator which processor you are using, place the following statement at the very beginning of your source code:

Code:

   .opt proc65c02,caseinsensitive

The above tells the simulator you are using a 65C02, and also that labels, symbols, operands and mnemonics are case-insensitive. If you are simulating the NMOS 6502 change the above statement accordingly. The simulator will then consider 65C02-specific instructions, such as BRA and TSB, as undefined.

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

I see, replacing all the binary values with their hex equivalent worked, and the code assembled succesfully.
Next question though, what is the function of a monitor program ? And does this program also need one ?
From looking at a few monitor programs i get the impression they tell the cpu the adress of the connected devices. They seem to do a lot more though, but this is still beyond my comprehension.

A monitor is a minimal program which allows you to interact with the machine - so it has to provide some minimum of I/O. It might let you modify memory and set the PC to run code, it might allow you to inspect memory, fill memory, disassemble or even upload programs over the link.

As a side-effect, the monitor's routines for input and output could be used by programs which then don't need to deal with the machine's hardware, they need only to call the monitor's routines.

But if a program does its own I/O, it won't need the monitor.

(It's also possible to equip a machine with an OS which does provide useful routines for I/O but which does not provide any form of interaction.)

Ok, so i think I got the example you gave me to run succesfully aswell.
I could'nt really find where the acia was outputting to though, but I know data was written to it by checking the memory adresses assigned to it.
Is there an easier way to check this ?

Also something else, when I run the program, the emulator seems to freeze for a second, so I cant see the actual flow of data. I can only see the values the program ends in.

Being able to specify operands in binary format is useful when dealing with hardware registers, since control often involves setting and clearing individual bits. In such cases, writing %10100101 (@10100101 in the Kowalski simulator) instead of $A5 often does a better job of conveying what is supposed to be happening.


Ed's answer pretty much covers it. A machine language monitor can be indispensable when debugging a program, since the monitor lets you "see" into the machine. Here's a screen shot of a machine language monitor displaying code disassembly, microprocessor registers and a small memory dump.

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

Ahem, so, it seems Kowalski's emulator has some notion of I/O, but it probably isn't an ACIA. So, you've written to a memory location. Perhaps it's time to get back to your own system? If you write some code which just writes over and over to the ACIA, you should be able to either see the data coming out, or to debug what's happening.

What kind of tools do you have: logic probe, multimeter, 'scope, logic analyser? You can make do with LEDs if necessary.

BTW, about your LEDs: Jeff noticed that you don't seem to have any current-limiting resistors. It's a good idea to put a resistor in line with each LED to protect it. 330 Ohms is one choice, you can probably get away with various values.

Yes, that seems like a good idea, ill give writing such a program a try.
Would it be a good strategy to try and port the example to run on my system ?

As far as tools go, I have a very basic multimiter, the led's, and and aruino for things like generating a slower clock.
And yeah, some current-limiting resistors might be a really good idea

If your multimeter has a frequency-counting mode, that could help.

Otherwise, you might consider rigging up some kind of single-stepping circuit. I'm sure there are examples around.

If, for example, nothing comes out of your UART, you'll want to know if the CS is static or is going low on each access. A logic probe or frequency-counting multimeter could help with that. But single-stepping is much more powerful.

This is all good fun!

The Kowalski simulator includes a primitive I/O console, which is memory-mapped at a location declared with the IO_AREA pseudo-op. For example, IO_AREA=$D000 will map the console in at $D000.

The console has several "registers" that are used for basic I/O and display control:

• IO_AREA+$00 - A write on this location will clear the console "screen."
  
  
• IO_AREA+$01 - Canonical output: a write on this location will display the byte written, interpreting the ASCII control characters $08 (destructive backspace), $0A (linefeed) and $0D (carriage return) as expected.
  
  
• IO_AREA+$02 - Raw output: a write on this location will display the byte written without interpretation. Writing control characters may have undefined effects.
  
  
• IO_AREA+$03 - Debug output: a write on this location will display the hexadecimal value of the byte written, rather than the corresponding ASCII character.
  
  
• IO_AREA+$04 - Raw input: a read on this location will return the ASCII value of a typed character. A null ($00) is returned if there is no input waiting in the keyboard buffer.
  
  
• IO_AREA+$05 - A write on this location will set the cursor's X coordinate.
  
  
• IO_AREA+$06 - A write on this location will set the cursor's Y coordinate.

The console I/O function does not simulate a UART in any way.

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

Getting a "blink the LED" (that a human can actually see, that is) that was built with the assembler is probably the best first step to take. That way you've got your toolchain sorta figured out, and you're seeing results on your hardware. Writing the code yourself will familiarize you with the 6502 instruction set, the syntax of your assembler, how to compile it, how to get it in to a format for your eprom burner, etc. Lots and lots of steps to get an LED to blink.

Then getting the "Hello World" to spit out of a serial port would be the next step. That solve setting up the ACIA, hooking up the terminal, writing to the ACIA, waiting for statuses to change to send the next byte, etc. More really good baby steps.

Once that's working, getting a "echo" program that simply echoes what you type it is the next hurdle. This should be straight forward once you get the output working. Now you can read and write from a terminal.

Then, go for getting any of the monitors running. Now you start typing little bits of code straight in to your machine. You can also consider seeing if you can transfer files from your terminal program, acting simply as if you're typing a bunch of hex codes in to your monitor.

After all of that, then I'd look in to getting something like EHBasic running.

Forgive the pedantry, but one does not "compile" assembly language source code. The young fellow has entered an unfamiliar world where there are new things to be learned. Using the correct terminology will help avoid confusing him.

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

It's a nice idea that we shouldn't confuse each other, BDD, but this is merely a case of different people speaking different dialects. It's not within your power to solve this "problem"!

Dialects? It isn't a matter of dialect, but one of using the correct word or words. Computer terms are subject to dialect-influenced vagaries no more than are medical terms.

I don't see a "problem," just incorrect terminology, and will continue to be pedantic about it as long as anyone continues to use "compile" when the proper term is "assemble" (or vice versa). Is there something wrong with using the proper terminology, or have we devolved to being cavalier about whether anyone who is new to the world of assembly language programming is learning the right stuff?

Assembly language programs are "assembled" by an "assembler." They are not compiled. Assembly is a different process than compiling. Any computer science professor worth his or her salt would correct you if you said in class that you couldn't compile your assembly language source code.

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

Hey,

I think I might have found a monitor made for the design im using, also included with this is a port of ehBASIC.
It is made to be assembled using ca65, however I was trying to assemble it in the kowalski simulator. This gives me an error though:

ERROR E037: Unrecognized instruction/directive/macro name. ROW 8

ROW 8: .feature labels_without_colons

I understand that I get this error because the simulator im using is'nt familiar with this command. Is there an equivalent for this command to use in the kowalski simulator ?

Also, how can I verify if these monitor and port of ehBASIC are actually written for the same machine as i'm using ?

Last thing, I have built a single-stepping curcuit.

You might try just commenting out that directive. (It looks like it might be a ca65 directive.)