Strange behaviour of Kowalski assembler

[Dan Moos]

I spent a couple nights trying to track down some strange behavior in my fledgling monitor program. Basically, it had all the hallmarks of some sort of RAM corruption leading to inadvertent crashes.

Finally I inspected the identifier window of the simulator.

In my code, I have the following:

previou

Code: Select all

STRING_PTR:	.DS 	$02		;pointer to current output message string
STRING_INDEX: 	.DS 	$01		;index into input buffer
LINE_CNT: 	.DS	$01		;clear screen line count
CMD_INDEX:	.DS	$02		;index into command string list
SELECTED_CMD:	.DS	$02		;pointer to slected command routine

LINE_CNT, and CMD_INDEX weren't shown in the sim's identifier window. Even after re-assembling. What was weirder, SELECTED_CMD was show to be where it should have been if the two missing identifiers were ther as they should have been.

So I saved, closed, re-opened, and re-assembled. I checked the identifier window, and everything was fixed! Put the code in ROM, and all the weird crashes stopped.

Any idea what happened here? Is it a bug, or could I have done something strange? BTW, the two identifiers had been in use before the weirdness, so adding them wasn't the trigger.

[BigDumbDinosaur]

Dan Moos wrote:

I spent a couple nights trying to track down some strange behavior in my fledgling monitor program. Basically, it had all the hallmarks of some sort of RAM corruption leading to inadvertent crashes.

Finally I inspected the identifier window of the simulator.

In my code, I have the following:

previou

Code: Select all

STRING_PTR:	.DS 	$02		;pointer to current output message string
STRING_INDEX: 	.DS 	$01		;index into input buffer
LINE_CNT: 	.DS	$01		;clear screen line count
CMD_INDEX:	.DS	$02		;index into command string list
SELECTED_CMD:	.DS	$02		;pointer to slected command routine

LINE_CNT, and CMD_INDEX weren't shown in the sim's identifier window. Even after re-assembling. What was weirder, SELECTED_CMD was show to be where it should have been if the two missing identifiers were ther as they should have been.

So I saved, closed, re-opened, and re-assembled. I checked the identifier window, and everything was fixed! Put the code in ROM, and all the weird crashes stopped.

Any idea what happened here? Is it a bug, or could I have done something strange? BTW, the two identifiers had been in use before the weirdness, so adding them wasn't the trigger.

Are these supposed to be zero page locations you are defining or absolute memory?

[Dan Moos]

Zero page.

I'm no longer sure the erratic behaviour was related, as it came back. It turned out a resistor I'd put in s series with the clock to tame ringing was making poor contact, so my clock was screwy. Dealing with that caused all trouble to cease.

Still, strange that those identifiers didn't show up in the list until I restarted the editor.

[GARTHWILSON]

Dan Moos wrote:

I'm no longer sure the erratic behaviour was related, as it came back. It turned out a resistor I'd put in s series with the clock to tame ringing was making poor contact, so my clock was screwy. Dealing with that caused all trouble to cease.

I don't want to sound discouraging, but it sounds like it's on the raggedy edge of working. Putting a resistor in a clock line is very bad practice, but in this case maybe just not quite as bad as what you had before. If you're still confined to a solderless breadboard, at least make the clock connections as short and direct as possible, not big hoops. The same goes for power and ground which should have wires making short connections across boards so the return current doesn't have to go all the way out to the end of the board to get its connection to the next board over. We want you to be successful of course.

[Dan Moos]

It was a small resistor on the recommendation of another forum member.

I just have some ringing, that wasn't causing me any trouble, but bugged me on principle. The resistor cured it. I have removed the resistor altogether, and have had no issues since, with rigorous torture testing. I'm only running at 1 MHZ, and the system seems completely stable.

If I go permanent build, I'm going PCB It will either be home-brewed, or pro etched. Haven't decided. I am confident, based on past efforts, that I can do a home brewed pcb with the needed specs. I know having true dedicated power/ground planes is huge, but I feel if I can get the thing to work on a breadboard, I can get it to work on a 2 sided PCB.

Remember, this is just for fun, and "see how far I can take it" purposes, so failed attempts are all part of the game. Once I switch from the fun of building the thing, to the fun of creating software for it, I'll most certainly have a board house make me a proper pcb.

The thing seems pretty stable on my current setup though.

[BigDumbDinosaur]

Dan Moos wrote:

Zero page...Still, strange that those identifiers didn't show up in the list until I restarted the editor.

Zero page assignments are best not done with .DS (which is the equivalent of *=*+). Conventionally, zero page locations are assigned with simple equates. For example, here is how I do it in POC's firmware:

Code: Select all

;================================================================================
;
;BIOS/KERNEL DIRECT PAGE STORAGE
;
zeropage .set 0                ;physical zero page
kerneldp =zeropage             ;kernel's notion of direct page
;
;
;	DUART channel block & pointer allocation...	
;
s_nxpchp =s_ptr*n_nxpch        ;channel
s_nxpbkp =s_ptr*n_nxpblk       ;block
;
;
;	counters & timers...
;
jiffct   =kerneldp             ;jiffy counter
uptime   =jiffct+s_byte        ;uptime counter (seconds)
uxtime   =uptime+s_utcnt       ;UNIX time (seconds)
tdjiffct =uxtime+s_time_t      ;sleep jiffy counter
tdsecct  =tdjiffct+s_byte      ;sleep time (seconds)
;
;
;	TIA-232 driver workspace...
;
tiasr    =tdsecct+s_tdcnt      ;DUART channel status
tiacr    =tiasr+s_nxpchp       ;DUART channel command
tiafif   =tiacr+s_nxpchp       ;DUART channel FIFO
tiaisr   =tiafif+s_nxpchp      ;DUART block IRQ status
tiagetrx =tiaisr+s_nxpbkp      ;RxD FIFO 'get'
tiaputrx =tiagetrx+s_nxpchp    ;RxD FIFO 'put'
tiagettx =tiaputrx+s_nxpchp    ;TxD FIFO 'get'
tiaputtx =tiagettx+s_nxpchp    ;TxD FIFO 'put'
tiatxst  =tiaputtx+s_nxpchp    ;TxD status (bit field)
tiaiblk  =tiatxst+s_byte       ;block offset
tiaicoff =tiaiblk+s_byte       ;input channel offset
tiaocidx =tiaicoff+s_byte      ;output channel index
tiaocoff =tiaocidx+s_byte      ;output channel offset

Values such as S_BYTE and S_TIME_T are externally defined in a different INCLUDE file.

One of the sneaky problems with making zero page assignments as you are doing is you have to set the program counter to the start of zero page, which makes the assembler think it is starting to assemble code at zero page.

[Arlet]

BigDumbDinosaur wrote:

One of the sneaky problems with making zero page assignments as you are doing is you have to set the program counter to the start of zero page, which makes the assembler think it is starting to assemble code at zero page.

Assuming you set the address back to a code space when you're done, does that matter?

Certainly looks a lot cleaner than calculating the addresses yourself.

[Dan Moos]

I did it exactly as Arlet said. It works great. This wasn't a code problem, it was a weird sim behavior that a simple restart cured. I'm just curious if it's a known issue, or just a rare fluke.

[GARTHWILSON]

I'm not familiar with the Kowalski assembler, but I would hope it has something more elegant than

Code: Select all

<label>   =<previous_variable_name> + <previous_variable_size>

to assign variable space. What does .DS (which I assume means "Define Storage") do that's undesirable in ZP, BDD? The two 6502 commercial assemblers I've used are 2500AD and C32. 2500AD uses BLKB (assign a BLocK of so many Bytes), and C32 uses DFS (DeFine Storage), like this:

Code: Select all

.PAGE0

STRING_PTR:    BLKB  2      ; pointer to current output message string
STRING_INDEX:  BLKB  1      ; index into input buffer
LINE_CNT:      BLKB  1      ; clear screen line count
CMD_INDEX:     BLKB  2      ; index into command string list
SELECTED_CMD:  BLKB  2      ; pointer to slected command routine

and

Code: Select all

 ORG 0

STRING_PTR:    DFS   2      ; pointer to current output message string
STRING_INDEX:  DFS   1      ; index into input buffer
LINE_CNT:      DFS   1      ; clear screen line count
CMD_INDEX:     DFS   2      ; index into command string list
SELECTED_CMD:  DFS   2      ; pointer to slected command routine

It's more clear, and it doesn't require changing more than one line when you want to add, delete, or resize a variable.

[BigDumbDinosaur]

Arlet wrote:

BigDumbDinosaur wrote:

One of the sneaky problems with making zero page assignments as you are doing is you have to set the program counter to the start of zero page, which makes the assembler think it is starting to assemble code at zero page.

Assuming you set the address back to a code space when you're done, does that matter?

It may with the Kowalski assembler, since it may populate part or all of the zero page space with (presumably) nulls, which will result in a saved program being much larger than anticipated.

Quote:

Certainly looks a lot cleaner than calculating the addresses yourself.

It's no cleaner than the "orthodox" method of using simple equates, as I show in my example.

[Dan Moos]

I can definitely say the through the eyes of a newbie, .DS is way more understandable and clean.

[barrym95838]

Meh, six to one, a half dozen to another. I happen to favor the use of equates, but I don't try to push my preferences on others unless they specifically ask me.

Mike B.

[Arlet]

I like the way the ca65 assembler does it. Instead of using ORG, you just start a segment using ".zeropage", and then define the labels. When you want to assemble some code, you start an appropriate code segment. You can switch back and forth as you want, and let the linker figure out all the addresses.

Per segment, you can define whether to fill with a certain value, or use initialized data from the source, and choose an output file to store it.