6502.org Forum  Projects  Code  Documents  Tools  Forum
It is currently Mon Nov 11, 2024 10:58 pm

All times are UTC




Post new topic Reply to topic  [ 15 posts ] 
Author Message
PostPosted: Sat Aug 27, 2022 8:36 pm 
Offline

Joined: Tue Jul 05, 2005 7:08 pm
Posts: 1042
Location: near Heidelberg, Germany
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

Code:
TSX
LDA $0101,X


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/


Top
 Profile  
Reply with quote  
PostPosted: Sat Aug 27, 2022 8:45 pm 
Offline
User avatar

Joined: Fri Aug 03, 2018 8:52 am
Posts: 746
Location: Germany
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


Top
 Profile  
Reply with quote  
PostPosted: Sat Aug 27, 2022 9:19 pm 
Offline
User avatar

Joined: Fri Aug 30, 2002 1:09 am
Posts: 8539
Location: Southern California
Quote:
accesses the stack in the old 6502 fashion

In 6502 fashion but not running in '02-emulation mode? And index registers set to 16-bit width? I'd say it could work if you're mindful of the fact that TSX will transfer the entire 16-bit stack pointer and you either:

  • do 1,X (rather that 101,X, since the high byte comes with the TSX), and change the stack pointer for different tasks if necessary, or
  • leave the stack pointer alone and do 1,X for one task, $21,X to reach for another task's last-on byte or cell, $41,X for another's, etc.

(and add to the '1' for other depths to reach into the stack, for example 6,X). But like Proxy said, using the '816, you might as well take advantage of the stack-relative addressing modes.

These are just some initial thoughts, so maybe someone else will think of creative ways to do this kind of thing to accomplish efficient tricks we haven't thought of.

_________________
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?


Top
 Profile  
Reply with quote  
PostPosted: Sun Aug 28, 2022 6:00 am 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10977
Location: England
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.)


Top
 Profile  
Reply with quote  
PostPosted: Sun Aug 28, 2022 1:32 pm 
Offline
User avatar

Joined: Fri Dec 11, 2009 3:50 pm
Posts: 3367
Location: Ontario, Canada
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...
Code:
TSX
LDA $0101,X
... 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


Top
 Profile  
Reply with quote  
PostPosted: Sun Aug 28, 2022 5:06 pm 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10977
Location: England
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.


Top
 Profile  
Reply with quote  
PostPosted: Sun Aug 28, 2022 7:01 pm 
Offline
User avatar

Joined: Fri Aug 30, 2002 1:09 am
Posts: 8539
Location: Southern California
BigEd wrote:
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!)

Right. I'd say it's all native mode, and that 8- and 16-bit accumulator and index registers are not modes, just sizes in native mode, where SP and DP are always 16-bit. The only mode bits are d (like the '02 has) and e ('02-emulation versus native).

_________________
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?


Top
 Profile  
Reply with quote  
PostPosted: Sun Aug 28, 2022 7:58 pm 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8482
Location: Midwestern USA
BigEd wrote:
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.

We need to be careful with terminology. The 816 has two modes: native and emulation. In native mode, the user registers’ sizes may be set to eight or 16 bits. There is no “eight-bit mode” or “16-bit mode,” as the 816 has a 16-bit ALU regardless of whether operating in emulation or native mode.

In native mode, the stack pointer (SP) is always seen as a 16-bit register, with bank $00 implied, and the direct page pointer (DP) is likewise always seen as a 16-bit register, also bank $00 implied. Instructions that copy DP and SP to or from the accumulator always copy 16 bits, even when the accumulator is set to eight bits—this effect is present in both operating modes.

TSX and TXS likewise copy 16 bits to/from .X, but with the most significant byte set to $00 if the x bit in SP is set to 1.

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

“Can be useful?” That sounds a bit like damning with faint praise. :o From my perspective, once you go with the 816 running in native mode and are comfortable with its personality, you will wonder why you didn't adopt it sooner.

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


Top
 Profile  
Reply with quote  
PostPosted: Sun Aug 28, 2022 8:06 pm 
Offline

Joined: Tue Jul 05, 2005 7:08 pm
Posts: 1042
Location: near Heidelberg, Germany
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/


Top
 Profile  
Reply with quote  
PostPosted: Sun Aug 28, 2022 11:01 pm 
Offline

Joined: Mon Feb 15, 2021 2:11 am
Posts: 100
fachat wrote:
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.


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.


Top
 Profile  
Reply with quote  
PostPosted: Mon Aug 29, 2022 12:00 am 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8482
Location: Midwestern USA
fachat wrote:
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.

The 6502 method of stack access is by its nature non-portable. That is the raison d'être for the 816's stack addressing modes, as well as the very useful ability to temporarily map direct page onto the stack. The latter permits the use of direct page addressing modes to access and otherwise use stack elements. The kernel in my POC units’ firmware makes extensive use of this capability.

In native mode, the 816 is in a world of its own compared to the rest of the 6502 family. Although basic 6502-like algorithms can be employed, the much more expansive capabilities of the 816 can only be fully exploited by treating it as a different beast. This is especially the case if you are planning to write an operating system. Aside from stack capabilities and the movable direct page, there is indirect long addressing, which is the key to “bank-agnostic” access to the full 16 MB address space.

Another behavior that is specific to the 816 is the “non-rollover” nature of its indexing during data fetches and stores. This even applies to direct page accesses. For example:

Code:
         rep #%00010000        ;16-bit index
         ldx !#$FFFF           ;!# means 16-bit immediate
         lda $FF,x             ;loads from $0100FE

Here, I'm fetching from direct page, or so it would seem, yet end up fetching from the next bank.

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

That’s like a lot of hoop-jumping just to accommodate a programming technique that really has no purpose in 816 software. Any software that would be developed to run with the services of a native-mode 816 operating system would, by necessity, have to be written to a certain standard. That would include methods to access and manipulate per process stacks. This should be done using methods that don't need to know the current value of the stack pointer. Mass-copying a stack just to accommodate stone-axe coding seems to me to be counterproductive.

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


Top
 Profile  
Reply with quote  
PostPosted: Mon Aug 29, 2022 9:42 am 
Offline

Joined: Tue Jul 05, 2005 7:08 pm
Posts: 1042
Location: near Heidelberg, Germany
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/


Top
 Profile  
Reply with quote  
PostPosted: Mon Aug 29, 2022 2:41 pm 
Offline
User avatar

Joined: Sun Jun 30, 2013 10:26 pm
Posts: 1949
Location: Sacramento, CA, USA
BigDumbDinosaur wrote:
“Can be useful?” That sounds a bit like damning with faint praise. :o From my perspective, once you go with the 816 running in native mode and are comfortable with its personality, you will wonder why you didn't adopt it sooner.

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)


Top
 Profile  
Reply with quote  
PostPosted: Mon Aug 29, 2022 9:06 pm 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8482
Location: Midwestern USA
fachat wrote:
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.

It will depend on what that code base is. As long as it doesn’t depend on undefined opcodes or idiosyncratic hardware behavior, most 6502 code will run as is. Even after switching from emulation mode (the power-on default) to native mode, the 65C816’s outward appearance is that of a 65C02, minus the Rockwell instructions. The gotchas are predictable and easily accommodated.

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


Top
 Profile  
Reply with quote  
PostPosted: Mon Nov 21, 2022 11:48 am 
Offline
User avatar

Joined: Tue Aug 11, 2020 3:45 am
Posts: 311
Location: A magnetic field
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!


Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 15 posts ] 

All times are UTC


Who is online

Users browsing this forum: No registered users and 5 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron