When reading BDDs PoC description I got a question, what happens when stack is remapped in bank 0 and not on page 1, and the program accesses the stack in the old 6502 fashion.

For example there is quite some 6502 software that does



Or similar. Will that code work or will it break?
I assume it will break but who knows?

(Sorry if stupid but it's late and no 65816 manual at hand)

_________________
Author of the GeckOS multitasking operating system, the usb65 stack, designer of the Micro-PET and many more 6502 content: http://6502.org/users/andre/

the code would break because the actual stack is located somewhere else in Memory
for example (assuming index registers set to 8-bit) if the stack is sitting at $C478, then that LDA $0101,X Instruction would access $0101 + $78 = $0179, which is nowhere near where the Stack is.
So when you run any 65C02 software that accesses the stack like that, you have to make sure it's staying in Page 1.

but for any newly written 65816 Software, they will likely use the Stack Indexed Addressing mode like LDA 1,S

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

I think this is a reminder that the '816, once it has been switched into native mode, is a very different machine, and in particular the two mode selection bits affect the action of almost every instruction - one cannot simply write or run ordinary 6502 code, without some discipline as to how the machine is presently set up.

(The '816 does boot into so-called emulation mode, which might perhaps better be called compatibility mode, in which it does behave very like a 'C02, with some additional facilities. It's a software design choice as to whether the system should remain in emulation mode or switch into native mode and stay there.)

I would change the emphasis, Ed. Don't you think it's better to say, "The '816, once it has been switched into Native Mode and one has begun altering the two mode selection bits, is a very different machine"?

What I'd hope to make clear is that the '816 in Native Mode is really not a very different machine unless one deliberately and actively chooses to go that route. This is important from the POV of 6502 folk, some of whom feel intimidated by the '816, and needlessly shy away from it.

Wisely, the '816 designers arranged that, when the user moves from Emulation Mode to Native Mode, what greets him/her is a rather 6502-like machine. By default, m and x select the familiar 8-bit modes for A and for X and Y unless the user actively chooses otherwise. Likewise, S defaults to its familiar location in page 1. As Garth says in his 65816 myths article, "It's not a package deal. Instead, there's a lot of freedom to order "à la carte" or treat it like a buffet table. Choose what you do want, and leave the rest alone."

It's true that certain Native Mode changes are not optional, but a great deal of ordinary 6502 code will run just fine in Native Mode. Even...
... will be alright unless the user has failed to initialize the Stack Pointer to $FF. In the lead post Andre mentioned remapping S so it no longer points within page 1... and that constitutes a step into new territory. But it would be an active choice, not something forced upon the user.

-- Jeff

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

mmm, I see what you're saying, but once in native mode, even 8 bit native mode, you do have a 16 bit stack pointer and a moveable direct page. (I think so - haven't checked!)

I agree that the 816 can be useful and interesting, and isn't too hard to program if you already know 6502, but I do think you need to be aware of the differences.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

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

One reason I was asking was to explore the possibility of a 65816 operating system that maps the stack elsewhere on different places for different processes that (each or at least some) run 6502 code. The advantage would be that each process has a full page of stack - but as you explained that would break some kinds of typical 6502 coding patterns.

_________________
Author of the GeckOS multitasking operating system, the usb65 stack, designer of the Micro-PET and many more 6502 content: http://6502.org/users/andre/

Just brainstorming...

If you allocate a page of stack per process, and reserve the traditional $0100-$01FF stack page for use when needed, you could block copy the per-process stack page to/from the traditional location on context switch. That's 1785 clock cycles using MVP/MVN, less with a real DMA solution. If you know which processes use those "typical 6502 coding patterns*" and which don't, the stack page copy could be avoided in many cases.

* I'm guessing you mean indexed addressing with $0100 as the base address, in order to access items from the stack.

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

The point seems to be that in native mode the 816 just really isn't a 6502 anymore - so only bares some resemblance to the 6502 but not more. That makes it difficult to reuse some of the code base, which was/is my goal still.

Anyway, my Micro-PET and Ultra-PET boards can re-map the lowest 32k to any 32k block in 512k RAM, so I'm good with this hardware.

_________________
Author of the GeckOS multitasking operating system, the usb65 stack, designer of the Micro-PET and many more 6502 content: http://6502.org/users/andre/

It's not necessarily from lack of trying, but I've concluded that native mode's personality quirks clash with my own personality quirks, and that's all I have to say about that.

_________________
Got a kilobyte lying fallow in your 65xx's memory map? Sprinkle some VTL02C on it and see how it grows on you!

Mike B. (about me) (learning how to github)

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

barrym95838: I'm not keen about 65816 either. 65816 and 74HC157 is a quick method to get a larger address-space and hyper-visor but I intend to write all user software with NMOS compatibility and deprecate 65816 at the earliest opportunity. I advocate an 8 bit compatible operating system interface and, at most, test NMOS/CMOS/65816 within specific, intensive subroutines. 65816 only solutions are often proposed and this precludes use of Commodore operating systems, Acorn operating systems and more innovative use of the instruction stream. While 65816 is conveniently available in DIP and surface mount options, second source options and test suites are weak. This is particularly notable around open source FPGA.

The 65816's multiple, zero overhead, opt-in extensions are well intentioned. However, this flexible philosophy is similar to C++ or Perl - and avoided by many for similar reasons. When you have N orthogonal binary design choices, there are 2^N design outcomes. This isn't a problem when working in isolation but it is terrible when merging projects - or working with legacy systems. In the most trivial case, setting 65816 native mode with CLC // XCE will reduce INX and DEX to single cycle operations and this is particularly helpful for data stacks. However, extended addresses and extended registers adversely affect interrupt response time. With native mode and native vectors, longer addresses are pushed to stack and this reduces the maximum interrupt response rate. Here, we only choose the most basic optional functionality - native mode - but now we're operating in different parameters: faster stacks, slower interrupts. Advocates portray 65816 as all upside but it isn't. If you are very committed to multiple extended features then additional throughput exceeds additional transistors. It is otherwise meh.

_________________
Modules | Processors | Boards | Boxes | Beep, Beep! I'm a sheep!