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.

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.

_________________
Andrew Jacobs
6502 & PIC Stuff - http://www.obelisk.me.uk/
Cross-Platform 6502/65C02/65816 Macro Assembler - http://www.obelisk.me.uk/dev65/
Open Source Projects - https://github.com/andrew-jacobs

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.

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?

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...

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

.. 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.

_________________
Andrew Jacobs
6502 & PIC Stuff - http://www.obelisk.me.uk/
Cross-Platform 6502/65C02/65816 Macro Assembler - http://www.obelisk.me.uk/dev65/
Open Source Projects - https://github.com/andrew-jacobs

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.

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).

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.

_________________
Andrew Jacobs
6502 & PIC Stuff - http://www.obelisk.me.uk/
Cross-Platform 6502/65C02/65816 Macro Assembler - http://www.obelisk.me.uk/dev65/
Open Source Projects - https://github.com/andrew-jacobs

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.

_________________
Andrew Jacobs
6502 & PIC Stuff - http://www.obelisk.me.uk/
Cross-Platform 6502/65C02/65816 Macro Assembler - http://www.obelisk.me.uk/dev65/
Open Source Projects - https://github.com/andrew-jacobs

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: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.

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

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.