Page 1 of 1

uart on 265 vx 134

Posted: Fri Nov 08, 2019 4:37 pm
by Collen
Hello,

i was trying to get text down the uart3 line, and tried this viewtopic.php?f=4&t=3545#p42268

thing is, you need to "JSL put_str" the thing...

2 questions:

how can you do this in 6502 emulation mode ?
and how does this work, when you have a 134sxb (8bit) ?

in my understanding, there is no "JSL" in 8 bit.
does "JSR" do the trick, and do i leave the 00 from $00:e04e (put_str) ?
or am i way off here... :)

Thx... C.

Re: uart on 265 vx 134

Posted: Fri Nov 08, 2019 6:14 pm
by BigDumbDinosaur
Collen wrote:
thing is, you need to "JSL put_str" the thing...how can you do this in 6502 emulation mode
The short answer is you don't. Just as you use RTS to return from a subroutine called with JSR, you use RTL to return from a subroutine called with JSL.

The fundamental difference is JSL pushes the current program bank (the contents of PB) along with the return address (minus one), after which PB is loaded with bits 16-23 of the subroutine's address. RTL pulls the return address and the bank byte that was pushed by JSL. put_str has RTL as the return instruction, which means your subroutine call must use JSL to match the RTL. If you attempt to call put_str with JSR the RTL return instruction will fail because it will pull a garbage byte instead of a real bank byte. The result will be a bogus address, sending the MPU off to uncharted waters. Also, the stack will become unbalanced and if the bogus address pulled by the MPU doesn't crash the machine, the jacked-up stack will.

Succinctly stated, JSR/RTS pushes/pulls two bytes to/from the stack. JSL/RTL pushes/pulls three bytes.

Of course, all this begs the question of why you would be running in emulation mode. There's a good chance the BIOS primitives were written with the expectation of the MPU running in native mode. I can foresee all sorts of bad things happening in emulation mode.

Re: uart on 265 vx 134

Posted: Fri Nov 08, 2019 6:21 pm
by BigEd
Is it especially tricky to push the right three bytes so the RTL will work as expected? I imagine it can be done - although it does seem unusual. (Edit: indeed as Jeff notes, it seems here to be inapplicable.)

Re: uart on 265 vx 134

Posted: Fri Nov 08, 2019 7:00 pm
by Dr Jefyll
BigDumbDinosaur wrote:
The short answer is you don't.
Correct. Collen, the code example you linked to is from a thread concerning the W65C265SXB board, whose processor uses the 65816 instruction set. But the processor in your 134sxb board uses the 65C02 instruction set.

It's reasonable to suppose the bios's for the two boards will be different. Although both probably support calls to a function called put_str, the location of put_str may be different -- and certainly the usage will be different. For example, you can't JSL if you have a 134sxb.

Usage for put_str and other calls will be explained if you can find documentation for the bios on your 134sxb. ( Does anyone have a link handy? Thanks! WDC documentation is sometimes hard to find. )

-- Jeff

Re: uart on 265 vx 134

Posted: Fri Nov 08, 2019 8:17 pm
by handyandy
Hi Jeff,

Documentation on the '134 can be found here: http://www.westerndesigncenter.com/wdc/ ... tation.cfm

See 134romlist and 134monrom files.

Cheers,
Andy

Re: uart on 265 vx 134

Posted: Sat Nov 09, 2019 12:38 am
by Dr Jefyll
Collen wrote:
in my understanding, there is no "JSL" in 8 bit.
does "JSR" do the trick, and do i leave the 00 from $00:e04e (put_str) ?
JSR does indeed do the trick! But although the W65C265 Monitor ROM Reference Manual does mention put_str, the W65C134 Monitor ROM Reference Manual does not. However there is a routine called PRTSTR, and the function (as with put_str ) is to output a string to the serial port.

If you search the manual for PRTSTR you'll find several references, including usage on page 60 and a "hello world" example on page 35 (copied below). PRTSTR itself is located at $F01E. Hope that helps! ps- Thx, Andy :)

-- Jeff

Code: Select all

        CHIP 6502
        LONGA OFF
        LONGI OFF
        SPACES ON
;
; This program sends the phrase 'Hello, world!' to the serial port.
;
        INCLUDE FIRMWARE.H     ;Firmware equates
        .ORG $0800             ;A good test location
                               ; to start.
        JSR CRLF               ;Get to the next line
                               ; (send CR/LF characters)
        LDA #>HSTRING          ;High order address
                               ;to accumulator.
        LDX #<HSTRING          ;Low order address to X
        LDY #ESTRING-HSTRING   ;Number of characters.
        JSR PRTSTR             ;Print it.
        BRK                    ;Return to monitor.
        HSTRING .BYTE 'Hello, world!' ;Define the text.
        .BYTE $0D                     ;A 'return' character.
        ESTRING EQU *                 ;Define the end of text.

Re: uart on 265 vx 134

Posted: Sat Nov 09, 2019 2:29 am
by BigDumbDinosaur
Dr Jefyll wrote:
But although the W65C265 Monitor ROM Reference Manual does mention put_str, the W65C134 Monitor ROM Reference Manual does not. However there is a routine called PRTSTR, and the function (as with put_str ) is to output a string to the serial port.
I neglected to mention in my earlier response that the put_str sub requires a 16-bit pointer to the string in .X. Furthermore, a bank byte must be in .A. The result, of course, is a 24-bit string address will be passed.

Re: uart on 265 vx 134

Posted: Sun Nov 10, 2019 1:59 pm
by Collen
Dr Jefyll wrote:
Collen wrote:
in my understanding, there is no "JSL" in 8 bit.
does "JSR" do the trick, and do i leave the 00 from $00:e04e (put_str) ?
JSR does indeed do the trick! But although the W65C265 Monitor ROM Reference Manual does mention put_str, the W65C134 Monitor ROM Reference Manual does not. However there is a routine called PRTSTR, and the function (as with put_str ) is to output a string to the serial port.

If you search the manual for PRTSTR you'll find several references, including usage on page 60 and a "hello world" example on page 35 (copied below). PRTSTR itself is located at $F01E. Hope that helps! ps- Thx, Andy :)

-- Jeff
Thx you all (Dr Jefyll & handyandy), that was indeed the hassle i experienced.
also thx for the Monitor Rom refs. those come in handy..

basically the 6502 emulation on the 265sxb is very poor on these maters.

again, thanx for clearing matters up for me. Cheers. :D