WC65C265SXB Monitor ROM problems

[randrews]

That was you? I've been relying heavily on that guide, I was going to submit a PR to it detailing, basically, how to make printf() work. Only I kept not being able to make it work.

I haven't used the 816 at all (or anything 6502 but this in fact, I've messed with Z80s and AVR microcontrollers but that's it), why's it harder to work with? I know about the high address pins being multiplexed with the data bus.

[BitWise]

If you are working in C then the underlying processor is largely irrelevant except when you need to interact with the hardware.

Once you have a small number of routines that abstract the hardware the rest of the code should be straight forward.

[randrews]

That's really what I was hoping, but I couldn't find any examples of anyone having written those routines for the 265, or figure it out myself.

[whartung]

BitWise wrote:

Why not implement your own polled output routine for now and replace with something cleverer later?

So the first question is why did you feel the need to create your own routine in the first place.

Second, if the monitor works, which uses the same routine, why shouldn't the experiments that he's been trying?

[randrews]

whartung: been asking myself that for days....

All I can figure is that it's related to IRQHandler. That's the symbol, along with main(), that c0.obj (WDC's init code) references that I have to supply. I'd love to have the sample C project that WDC claims comes with their tools...

[BitWise]

whartung wrote:

BitWise wrote:

Why not implement your own polled output routine for now and replace with something cleverer later?

So the first question is why did you feel the need to create your own routine in the first place.

Second, if the monitor works, which uses the same routine, why shouldn't the experiments that he's been trying?

WDC's C compilers generate code for an arbitrary 65xx machine. They do not have any special support for the SXB boards or the 134/265 micro-controllers. It has no knowledge of the WDC monitor.

Dumping the C0C.obj module (wdcobj -R c0c.obj) shows

Code: Select all

  20    0 : section : #5 : startup
  22 7D00 : org : 7D00
  27 7D00 : 5 data bytes:
              78 18 FB C2 38
  2D 7D05 : 2 debug bytes
  32 7D05 : 6 data bytes:
              A9 FF 01 1B E2 20

.. that it executes SEI/CLC/XCE/REP #$38/LDA #$1FF/TCS/REP #$20 on startup so the interrupts are disabled and the WDC monitor will not function correctly.

[whartung]

BitWise wrote:

.. that it executes SEI/CLC/XCE/REP #$38/LDA #$1FF/TCS/REP #$20 on startup so the interrupts are disabled and the WDC monitor will not function correctly.

Aha! Winner, winner, chicken dinner.

My confusion was randrews said that he tried some of the assembly bits and that it was still not working.

But if he tried it via the assembler WITHIN the C compiler, then you'd get the same result.

So it might be as simple as CLI to get the interrupts running again.

Though it's curious that he was able to get anything at all -- seems to me that the routine just fills a queue, and lets the interrupt drain it. In contrast to your routine which drives it directly.

[randrews]

It disables interrupts? That's stupid.

Okay, honestly, a non-interrupt-based version is better for me anyway because I'm going to be writing something that will run without the monitor (and its interrupt handler).

[BitWise]

randrews wrote:

It disables interrupts? That's stupid.

Most if the WDC's real users are building products with bespoke hardware (e.g. washing machines, toys, pace makers, etc.). You would not want the firmware to start processing interrupts until the hardware and software is fully initialised.

[BitWise]

To use interrupts on the 265 I think you would need to build a Flash ROM image for the $8000-$ffff region and disable the built in monitor ROM -- Thats what I do in my assembly projects.

The 816SXB has redirects interrupts through a 'shadow vector' area in RAM. I suspect the C startup up modules included with the free compiler has been configured for the 816SXB by default.

[randrews]

So I'm not super clear on how 65816 / 65265 interrupts work... The monitor itself must use them, right? So if I want to call its functions like put_chr or whatever, all I should have to do is cli in my main() before I do anything, and then it'll use the monitor's handler.

And in fact that seems to work perfectly.

The cost of this is that probably I can't use my OWN interrupt handler... Without disabling the ROM and providing my own, of course. But maybe that's what the IRQHandler symbol is for, maybe the monitor ROM jsl's to that symbol as well on interrupts, if it's an interrupt type (or however 6502 interrupts work, I only speak Z80) that it doesn't know how to handle.

And I just tried, and if I cli in main... put_chr DOES work! Exactly as it should. Here's my final working hello world:

Code: Select all

void monitor_putchar(char ch);

void main() {
	const char *str = "\nHello there\n";
	int n;

	asm cli;
	
	for(n = 0; n < 13; n++) {
		monitor_putchar(str[n]);
	}
}

void monitor_putchar(char ch) {
	asm {
		lda %%ch
		jsl $00:e04b
	}
}

void IRQHandler() { }

So now we know two ways of doing it, one with a polling loop that doesn't require the monitor, one using the monitor's routine and interrupt handler.

Later today or tomorrow I'm going to write all this crap up and submit a PR to that guide on github. I'm certain I'm not the last person who's going to want to know how to do this.

[whartung]

randrews wrote:

So I'm not super clear on how 65816 / 65265 interrupts work... The monitor itself must use them, right? So if I want to call its functions like put_chr or whatever, all I should have to do is cli in my main() before I do anything, and then it'll use the monitor's handler.

Yea, if you want to use the monitors routines, you need to leverage the monitors interrupt handlers.

Quote:

The cost of this is that probably I can't use my OWN interrupt handler... Without disabling the ROM and providing my own, of course. But maybe that's what the IRQHandler symbol is for, maybe the monitor ROM jsl's to that symbol as well on interrupts, if it's an interrupt type (or however 6502 interrupts work, I only speak Z80) that it doesn't know how to handle.

All of the monitors interrupts are vectored through RAM, which is another aspect of the monitor.

You can tap in those vectors, pointing them at your code, and then calling the monitors routines, so you don't necessarily have to replace them completely.

That said, it is just a monitor, set up to make working with the board reasonably easy to start with. But it's not a BIOS. Whatever is there is there to support the monitor, not the chip per se.

You could certainly lift stuff out of it in to a BIOS of your own.

Also, the fact that the default C runtime disables interrupts is just that -- a default. You should be able to provide your own.

Historically, there's always been crt0 routine that is actually the bootstrap of the program. The binary starts with crt0, and crt0 works its magic and then calls 'main'.

Admittedly, it would have been very nice for WDC to provide a working toolchain to produce C code that works with the boards and the monitor. Example programs showing those little ins and outs.