Yeah, I submitted before thinking it through. I "fixed" it while you were viewing the original.

Mike B.

I ran the following code on POC to see what effect an attempt to relocate direct page on the 65C816 in emulation mode would have:

Code:

        sei                   ;ignore IRQs
        sec                   ;switch to...
        xce                   ;emulation mode
        lda #$90              ;MSB of relocated direct page
        xba                   ;move to .B
        lda #$00              ;LSB of relocated direct page
        tcd                   ;relocate direct page to $9000
        xba                   ;clear .B
        tdc                   ;copy what we think is direct page pointer
        sta $a000             ;store LSB somewhere for later examination
        xba                   ;get MSB &...
        sta $a001             ;store as well
        lda #$a5              ;write test pattern to...
        sta $80               ;direct page
        lda #$5a
        sta $81
        clc                   ;return to...
        xce                   ;native mode
        rep #%00100000        ;16 bit accumulator
        lda #$0000            ;16 bit load
        tcd                   ;restore direct page to default location
        lda #$cdff
        tcs                   ;restore stack pointer to default
        cli                   ;process interrupts &...
        brk                   ;stop

Upon running the above code and examining location $00A000 I found the pattern 00 90, the regurgitated direct page pointer value picked up by the TDC instruction. At location $009080 I found the pattern A5 5A, which was written by the STA $80 and STA $81 instructions. This test conclusively proves that it is possible to relocate direct page while the 65C816 is in emulation mode.

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

Awesome! This sort of effort yields far better info than inferences from the doc -- which is vague in this case; at least the references to doc in this thread are vague.

I liked your approach too, Mike. Thank you, both.

-- Jeff

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

This topic gave me a bit of a scare as the FT816 ignores the DPR on a mode switch, and otherwise always uses it when generating direct page addresses in either mode.
On reset DPR is set to zero. When switching to emulation mode then I guess the DPR should manually be set to zero or other desired value.



Address generation in FT816.


I think it should be possible to switch the dpr to point to I/O registers in bank 0 for higher-speed I/O.

_________________
http://www.finitron.ca

Yes, you could point DP at the I/O block to slightly boost performance (however, the boost isn't as much as you might think), but then you would also create a potentially intractable problem. Any indices associated with I/O that are stored in the physical page zero, e.g., buffer pointers, will be inaccessible while DP points to the I/O hardware, unless you use absolute addressing to access them. So you'd gain slightly by accessing chip registers via direct page addressing, but lose by having to access page zero addresses using slower absolute addressing.

You'd also have to consider the expectations of interrupt service handlers, which may need to have DP pointing at the real page zero—failure to account for this would probably trigger a crash when DP is modified and an IRQ hits.

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

Awesome, thank you! Will include link to this test in the emulator.

New questions that came up, this time while coding first versions of PHP and PLP:

In emulated mode, can PLP (and REP and SEP) change the b-flag and the "unused flag" (bit 5) ? The handbook seems to say "yes" for PLP (p. 385) and "no" for REP and SEP. Note however that for PLP, we have a dash in the schematic, but an "all flags are replaced" in the text. That's not good, especially if we switch to native mode right after these instructions for some reason.

Then, if the b-flag is clear in emulation mode and we push P to the stack, and then switch into native mode and then pull P again, will this set X and Y to 16 bits (since both use bit 4 of P)? I'm guessing it should, which would make it another source of ugly errors, so I wanted to make sure.

Finally, if we set the m-flag in native mode, and then go emulated, will the "unused flag" (bit 5) be set afterward? The same question occurs with the x- and b-flags. The manual on page 61 simply says: Ignoring the typo for the moment ( m turns to unused, x turns to b), we have no word on if they keep their values or are set to zero.

I realize these pretty much all deserve a "dude, who cares" as an answer, because sane people will avoid these situations. Would be grateful for any suggestions (again), because the emulator still has to deal with them.

(Also, I'm getting somewhat fed up with emulation mode, which seems to cause most of the problems. If there is one thing I'm taking away from all of this, it is to get to native mode ASAP and to stay there.)

Yes, staying in emulation mode, or leaving quickly and then staying in native mode, both tactics make for a much simpler machine model. Indeed, even within native mode, picking one of the four sub-modes and sticking to it is a good idea too: any given subroutine pretty much has to make assumptions about the m and x mode bits, and if they are changed then it's best to change them back as soon as the need passes. Even then, how you leave or modify the high bytes of A, X and Y could possibly cause side-effects - entirely deterministically, but again you need a more sophisticated model in your head in order not to mess things up. I would expect 16/16 is the most popular choice, with 8/8 as the second most popular. Possibly mixed-width would be handy for string operations on large strings.

Garth likes to use 16-bit accumulator/memory and 8-bit index registers in his 65c802 ITC Forth most of the time. I find global mode-switching (and prefix bytes [off-topic]) to be generally annoying concepts, and avoid them as much as possible, but I understand their need to exist, and use them when necessary, albeit with a bit of eye-rolling.

Mike B.

That's an interesting choice... you don't have much reach with an 8 bit index.

In my '816 DTC Forth I went for 16-bits everywhere and switch A/M to 8-bit when needed.

_________________
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

The break flag is just a flip-flop which is set during the execution of break instruction. The 6502 does not pull it from the stack. I'm inclined to think that the 816 also does not pull it from the stack since it's 100% 6502 compatible in emulation mode (it's the way I coded the FT816). The x and m bits are independent FF's.


I think not since the break flag and m flag are independent FFs. The break flag would retain the value of it's last setting in emulated mode.

_________________
http://www.finitron.ca

This is a slippery subject. On 6502/c02 the break flag is not a flip-flop -- in fact the break flag is more or less an illusion. Break status is recorded in the image of P pushed to stack during the interrupt, and nowhere else. IOW memory records break status but the CPU doesn't -- bit4 of P isn't implemented. There's probably a forum thread or a wiki topic dealing with this, although at the moment I don't have that handy.

The '816 (like the FT816) is a whole different question, however -- as for how they decided to emulate 6502 behavior, I mean. I suspect another actual hardware test is in order. I haven't reviewed the doc but I'd be very surprised if the authors expended the considerable effort necessary to clearly explain some subtle and confusing behavior that hardly anyone cares about. Heck, it's hard enough to write doc that answers most of the questions for most of the people!

I expect most of Garth's indexing is into the Forth data stack, and 8 bits is plenty. 16-bit index mode has the downside of adding a byte and a cycle to instructions such as LDY or CPX with an immediate operand.

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

Which is perfectly understandable, especially in a situation where it costs money to have something like that written.

I'll collect these kinds of "esoteric" secondary questions here and in the TODO file, and for now just code a "best guess" variant in the first version of the emulator. Once that is working Well Enough (TM), I should probably, you know, actually build a computer with the 65816, even if it is only a breadboard testing setup. I'm sure this is not the last "weird stuff" to turn up.

Indeed it is a slippery subject. The above is probably the best way to think of it.

The BRK status could be recorded by directly muxing the IRQ line onto the databus in the break flag position (perhaps the '02 does this). But the problem with that is what if the IRQ line goes inactive before storing the status to memory takes place ? It's safer to use a FF. If no FF is used it would be possible that some IRQ's would get interpreted as BRK's if the IRQ line isn't held low long enough. I guess this typically wouldn't be a problem as the IRQ line should remain active until the IRQ processing routine resets it.
Hmmm, I wonder now if it would be possible to use the IRQ line to flag as a BRK instruction on purpose by pulsing the IRQ line inactive at just the right point ? This would give two hardware interrupt lines on the '02.

Anyways ,when coding the FT816 core I used a flag FF to indicate where the interrupt came from. (A hardware IRQ or the BRK instruction). Then used the same hardware to process both IRQ's and BRKS's. I believe this is same way that the original '02 does it. Because it's typically a couple of clock cycles between an IRQ event and when the status register needs to be saved on the stack. So this is state that has to be saved (in a FF) for a clock or two, before it gets written to memory. The long term state of the break flag still really exists only on the stack and not in the processor.
Doing things this way allows the FT816 core to accept a short pulse as n IRQ in addition to level sensitivity.


Since it should be accessed from the stack in order to be tested, it retains it's state in native mode provided the stack doesn't get overwritten.

The way I currently have the core coded is to have an actual break flag (bf) which can be pulled from the stack by a PLP or RTI (This isn't 6502 identical) but hasn't broken any programs. Unless the break status is modified on stack before a PLP / RTI the execution result will be identical to the '02.

_________________
http://www.finitron.ca