Banked RAM, ok... And why not banking Page 0 and 1 ;) ?

kktos · Post by **kktos** » Tue Jan 12, 2021 10:44 am

Yeah, yeah, I know, one of this stupid idea.

Nevertheless, there's something to it which is appealing.... like having a local ZP and Stack.....

Having a 65C02 which can behave kinda like its big brother, the 65816....

Just a thought....

?

Lorin Millsap · Post by **Lorin Millsap** » Tue Jan 12, 2021 12:53 pm

Because how many variables do you need? It adds complexity and it’s not as useful as you think. Also the banking is stored in zero page so that wouldn’t work. Sent from my iPhone using Tapatalk

kktos · Post by **kktos** » Tue Jan 12, 2021 1:28 pm

Lorin, it's not a matter of var quantity rather than context.

Did you play with a 65816, 6809 or 68K ?

From a dev POV, it's pretty nice.

Not to mention it may, if one wish, allow to do multi tasking.

And as for the ZP $00 and $01 used for banked mem, those 2 addresses could shadowed.

Anyway, I said it first. Just a possibly stupid idea.

Let's call it Food for thoughts ?

Lorin Millsap · Post by **Lorin Millsap** » Tue Jan 12, 2021 1:36 pm

Lorin, it's not a matter of var quantity rather than context.
Did you play with a 65816, 6809 or 68K ?
From a dev POV, it's pretty nice.
Not to mention it may, if one wish, allow to do multi tasking.
And as for the ZP $00 and $01 used for banked mem, those 2 addresses could shadowed.
Anyway, I said it first. Just a possibly stupid idea.
Let's call it Food for thoughts [emoji6]

The system is not intended to multitask. It is a direct to hardware system and while you could do simple multitasking, it’s not our design goal. They are used as quick access stash points for code, most programs will only use maybe a couple dozen tops. If you aren’t using BASIC you can repurpose all the ones reserved for BASIC and the same goes for KERNAL ones.

So from a dev standpoint it’s not needed furthermore your dev tools would have to keep track of which ZP you are accessing.

The ZP banking is already shadowed.

What you are asking is not a simple change. This lands firmly in the category of the hardware is set and this isn’t going to happen. In fact most future changes are bug fixes.

Sent from my iPhone using Tapatalk

kktos · Post by **kktos** » Tue Jan 12, 2021 1:40 pm

?

I'm not asking for anything, Lorin. Merely sharing thoughts, ideas, here.

And to be honest, I think it's a tad late to consider such a change for the X16.

kktos · Post by **kktos** » Tue Jan 12, 2021 1:47 pm

5 minutes ago, Lorin Millsap said:

The ZP banking is already shadowed.

Interesting.

I suppose you meant that the Bank register is affecting the whole address range $0000 - $FFFF so address $0000 is therefore shadowed.

ok, I wasn't seeing things like that rather than having the BR (RAM/ROM) affecting only addresses from $A000 - $FFFF.

So I guess from your answer, physically, really, the whole RAM is banked with some "windows" shadowed.

Am I understanding correctly ?

Lorin Millsap · Post by **Lorin Millsap** » Tue Jan 12, 2021 1:54 pm

Interesting. I suppose you meant that the Bank register is affecting the whole address range $0000 - $FFFF so address $0000 is therefore shadowed. ok, I wasn't seeing things like that rather than having the BR (RAM/ROM) affecting only addresses from $A000 - $FFFF. So I guess from your answer, physically, really, the whole RAM is banked with some "windows" shadowed. Am I understanding correctly ?

No. You are not understanding that at all. The bank registers are mapped are located in memory locations $00 and $01. They are latches that capture writes to those locations. As long a the memory model doesn’t change then you can read those locations too and the value they contain is always the same as what is written. But if you make that area of memory swappable suddenly the value stored in those locations will not match what is stored in the latches. There is no practical or simple way to do it. Our goal is a simple memory model. As I’ve stated before the use case is not really that useful. A relocatable ZP makes more sense and that requires a different CPU. Once you start remapping too much you are moving away from banking and starting to look more like a full MMU. Sent from my iPhone using Tapatalk

kktos · Post by **kktos** » Tue Jan 12, 2021 2:19 pm

I knew there was a misunderstanding and I wasn't sure where.

It's on the word shadowed.

Let's me explain what I meant:

I'm coming from the Apple ][ world. And my last one was a IIgs.

The RAM used for HIRES is located at $2000 and $4000. There are 2 pages.

On the IIgs, running a 65816, we have 24bits address bus. And in the bank $E0 and $E1, the addresses $2000-$5FFF from bank $00 and $01 are shadowed.

Shadowed means even you're accessing 2 different addresses, $00/2000 and $E0/2000, you're physically writing at the same location.

StephenHorn · Post by **StephenHorn** » Tue Jan 12, 2021 7:28 pm

I just feel that the 65C02 is a distinctly poor choice for a multitasking system. But I'm not expecting to write multitasking code. I think it's amply clever just to put certain tasks like file I/O on the non-interrupt code path, while my interrupt code handles other normal frame-by-frame program execution.

Stefan · Post by **Stefan** » Tue Jan 12, 2021 8:40 pm

After programming a while for the emulator I'm generally very pleased with how things are working.

There are a lot of free ZP addresses, at least when you program in assembly. Typically even a large program really requires only a few ZP words, mostly for indirect addressing.

The bank switching works well as is, and it will work even better when moved to ZP. But I have the advantage of not having done bank switching 6502 programs before, so I have no fixed view on how this could or should work.

The interface to VERA is logical and easy to work with. I'm especially fond of the auto increment/decrement feature, making it possible to do really fast writes to the memory in VERA.

And there's a lot of RAM and ROM, making it possible to do things never imagined on 8 bit computers.

I think it really is a dream to program. ?