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

If you set up a 3-byte pointer in Direct Page you can use "Direct Indirect Long" address mode to reach the entire 16 MB address range. In fact there are four modes that can reach all 16 MB (without relying on DBR):

- Direct Indirect Long
- Direct Indirect Long indexed with Y
- Absolute Long
- Absolute Long indexed with X

-- Jeff

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

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

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

Thanks. Direct Indirect Long is what I needed.

My ISR takes a byte from either the ACIA or PS/2 keyboard controller and places them in a circular buffer similar to the one you recommend in your primer. My ISR is about 47 bytes long.


My ISR uses 16-bit absolute addressing. My data bank register is set to bank 2 at start up. That's where my I/O and RW data reside.

There's more than one way to do that. For example, my ROM and I/O are contiguous from $FF00-$200FF. My extended RAM is also contiguous from $20100-$7FFFF.

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

Some interesting design choices here. I like the idea of keeping the hardware simple - and an effect of that is that the memory map might not be so simple, because optimising two things at once doesn't always work out. ​

I'd like to see this play out with I/O in bank 2 - it's not what we normally see, and it might have some interesting tradeoffs. But, I'm not sure of the advantage of having the I/O share with RAM in this bank - I see that it means DBR can point to both, but it also means that you now have another special area of RAM: bank 0 is always special, now bank 2 is special, and the rest of your RAM is all one piece. If you sketch out what you I/O routines will look like, and how you might load a block of data from an I/O device into working RAM, what consequences do you see?

It does feel to me that worrying about extra single-cycle costs is potentially a mistake, especially at higher clock speeds. The overall latency, and overall elapsed time, of the ISR, is what matters, and it's not usually quite so critical. One might be worrying about a tenth of a microsecond.

I have 256 bytes of I/O from $20000-$200FF and about 64k of ROM from $FF00-$1FFFF. I don't need that much ROM, but like you mentioned, this keeps RAM in one contiguous range from $20100-$7FFFF. I/O is in bank 2 vs bank 1 because that's where my RW data is and this allows I/O access with 16-bit absolute addressing.


Direct page, return stack and Forth data stack, likely multiple instances of each. At this point in my design it doesn't seem reasonable to waste bank 0 features on things that can be accommodated elsewhere. Of course I'm just starting out, so I'm not locked into anything yet.

Most I/O routines are done. ACIA and PS/2 keyboard controller ISRs in bank 0 save to circular buffers in bank 2. Input routines (getc and get_blk for example) accesses these for input. Block data is saved from the serial buffer to a block buffer in bank 2. Output (putc) writes directly to serial which is connected to a smart display that also provides SD card access. I haven't made put_blk yet. I need an editor first.


I suppose this refers to other comments as counting clock cycles isn't one of my concerns. I started my Forth system as token threaded so speed was never one of my goals. I'm now doing direct threaded but I'm still not worried about speed.

and

I will be interested to see your token threading. I can envision a token-threaded Forth, but haven't ever seen one. Even with ITC or DTC however, Forth program memory usage is so efficient that if you're working by yourself, I'm sure you'll never come close to filling a bank, even with stacks and I/O in the same bank. If you do token-threading, it'll be all the more compact. My '02 ITC Forth is rather full-featured, unlike fig. It takes something like 24KB of ROM, and then I have 16KB of RAM for compiling applications on the fly, and I've never needed anywhere near that much except for when I wanted large data arrays, and I would want many megabytes for some of those. In my '816 Forth, non-bank-0 RAM is only for these large data arrays, not program memory.

_________________
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 started developing with TTC to save memory on a 6502 system that only had 32k RAM and 16k ROM. I gave it up after seeing that expanding the number of tokens past my initial quantity of 256 required more memory than I was saving with the TTC construct.


I agree. With the memory I gained with my PLD address decoder I can fit everything in 64k. So bank 0 would be fine for it with a 65816, but where's the fun in that. With the 65816, I'm basically treating bank 0 as the zero page on the 6502 and using the next two banks for the ROM and RAM that filled the rest of the 6502's 64k address space. I'm just tripling the size of it all. I then have another 320k extended RAM on top of that. What more could I ask for?

I really liked TTC and might have stuck with it if I'd had the nearly inexhaustible memory available with the 65816. Right now I'm more interested in the experience than in saving a byte or a cycle. If I try to optimize I'll never get anything done and I already have too much of a tendency to get side tracked.

I've tried some of the refinements that have been suggested without success:




My new code:

RAM_CS needs 70 pterms, I have 16 on that pin. Essentially the same as my original problem and why I used overlapping ranges.

With the PLD I'm using I can't use logic directly mapping the single page of ROM and IO that I want. My solution has the downside of selecting RAM when writing to ROM, but it works for my system. In fact it may be the only way to achieve my goal with this PLD. Anyone up for the challenge to prove otherwise?

As an aside, I don't think these refinements did much (or anything?) to help WINCUPL use fewer terms. Perhaps it's smart enough to get over my bad coding.

Also, note that my IRQ logic is surely off but I didn't bothering with it as these refinements didn't help solve the original problem. Perhaps it shows, negations play tricks with my brain. I'm still looking askew at the negated pins and corresponding logic and scratching my head. It's just not clearer for me what's going to come out of the pin. Including the negation in the logic seems clearer. For example

clearly states that CLKB is the inverted clock. In the refined code above I have but it's active negative from the pin setting I'm all for it if it helps it fit in the PLD, but if not, I'll go for what fits in my brain.

Just for reference in my challenge above, the following code also fails but only needs 18 product terms for RAM_CS, versus 70 in the code with non-overlapping address regions. 16 is the max on a pin for the ATF22V10C.