Mapping hardware to Page 0 ...

[drogon]

So... I've not been a fan of sticking hardware IO registers in page 0 and I've been a bit critical of the W65C134 recently which (ab)uses a quarter of the ZP space for IO. ($00-$3F)

A few reasons - Page 0 has more uses than just general purpose RAM. You can save a byte of code and a cycle of clock by storing data there and you can use it as 16-bit pointers.

Similar arguments can be put forward for hardware - Your code uses a byte and a cycle less to access it.

But I've always coveted my precious page zero RAM and tried to stuff as much in there as possible.

But this morning I faced a little conundrum... I'm building up a new project that's quite minimal and as I have 25 bytes spare in page 0 I can use that to map in the VIA (only 16 bytes, so I still have 9 bytes free for subsequent data and I know I'll need at least 4 for some serial code I've yet to write)

The system has 4K of RAM and I can map the VIA anywhere in the first 4KB of address space on a 16-byte boundary. My initial thought was up at the top ($0FFx) or even at $010x (as I have plenty of space left in page 1 too) - I lose 16 bytes of RAM no matter where I map it to, it's just a question of where...

(And for other reasons I can't/don't want to map it anywhere other than in the first 4K of address space)

If I mapped it at $00Fx then my code would save a byte and a cycle accessing it - that may be a good thing as ROM space is limited too.

So what would you do?

-Gordon

[gfoot]

I have no problem with mapping hardware into page zero, if it makes sense ether for code size or speed reasons. I'd also add address decoding ease as a possible reason, but generally I find decoding zero page more awkward than other address regions. I'm actually about to map my video hardware into page zero, though not necessarily permanently.

I also think leaving large regions of unassigned addresses is very valuable in a flexible general purpose system, and so for just a few bytes I'd be hesitant to give up other bytes higher in the address space.

I'd also argue that it's fine for software to start out using page zero as much as possible but however much there is, when it runs out you need to decide which things really belong there and which don't. At that point you need some higher address space to store this sort of data in anyway. And you can weigh up hardware address space allocation just like software addresses in this regard and place them wherever makes sense.

Regarding the stack, maybe the top makes more sense than the bottom? Then you'd initialise the stack pointer to $1EF, and if any software wants to use $100 as scratch space it still can.

[barnacle]

I don't have a philosophical objection to it, but I've never designed IO into page zero or page one. My latest has a single VIA mapped at 0xff00-fx0f, with I/O space from 0xffff-0xff7f.

The older I get, the more I start to appreciate the 8080 and descendants' separate I/O space, if only because it makes the hardware decoding simpler.

Neil

[plasmo]

I'm working on bootstrap code in 22V10 which has limited logic fabric, so I do find myself using zero page, but only temporarily to get the overall concept to work. Once it is working, there is always room for optimization. Zero page is an useful crutch to lean on to get past certain obstacle; usually there are better solutions later on.
Bill

[drogon]

gfoot wrote:

I also think leaving large regions of unassigned addresses is very valuable in a flexible general purpose system, and so for just a few bytes I'd be hesitant to give up other bytes higher in the address space.

I sort of feel that if it's unused then it ought to be filled with RAM - as RAM is cheap these days - so my Ruby boards have RAM from $0000 to $DFFF, then 256 bytes of IO then RAM in the top 256 bytes for vectors, etc.

In this instance, I'm deliberately trying to be minimal - 4K RAM and 4K ROM and I have no wiggle room...

Quote:

I'd also argue that it's fine for software to start out using page zero as much as possible but however much there is, when it runs out you need to decide which things really belong there and which don't. At that point you need some higher address space to store this sort of data in anyway. And you can weigh up hardware address space allocation just like software addresses in this regard and place them wherever makes sense.

Here (In my TinyBasic) I have found that using the linker config file in the cc65 quite to be a boon. I can use it to move data to/from ZP without altering a byte of code - as long as I keep the "core" variables and pointers in ZP where they must be, I can shuffle other data chunks (The 27 program ariables @-Z, stacks for DO/UNTIL, FOR/NEXT, GOSUB/RETURN and the arithmetic evaluation stack) into or out of ZP as needed. I put this in for the port to the 134-SXB board which uses $40 bytes of ZP for hardware and back-ported it to the port for my Ruby board which dedicates $90 through $FF for the operating system (somewhat greedily but it's sort of for compatibility with the Acorn MOS)

In this new system, it's "bare metal" as such, so no monitor or OS other than serial handling so I have all ZP to use and I can put every byte of data my TinyBasic needs into ZP leaving 25 bytes spare...

Quote:

Regarding the stack, maybe the top makes more sense than the bottom? Then you'd initialise the stack pointer to $1EF, and if any software wants to use $100 as scratch space it still can.

Indeed. Currently I use $0100 as the keyboard input buffer (max. 126 bytes) however I can work out exactly how much stack it uses and I was thinking of bringing the stack pointer down to (say) $90 and starting (basic) program storage at $0190 but maybe I'm just grasping a little too tightly here...

The decoding is flexible as I have A[4:12] going into a GAL so changing it is fairly trivial but now I've had an afternoon to think about it I suspect it's going to go at $00Fx.

Thanks for the feedback.

-Gordon

[BigDumbDinosaur]

My main beef with mapping I/O into page zero is it really does very little for performance.  If one studies typical device drivers, it becomes apparent that the bulk of the expended processing time is in the code surrounding the device access, not the device access itself.  Furthermore, if your system runs fast enough to require I/O wait-states, then the theoretical performance gain to be had with I/O in page zero is negated by the wait-stating, during which the microprocessor will be doing absolutely nothing.  Please explain to me how mapping I/O into page zero helps with that.

Page zero is much too valuable to be populated with I/O registers.  When you also consider the decoding headaches, you can’t convince me making I/O show up in page zero is a good idea.

[drogon]

BigDumbDinosaur wrote:

My main beef with mapping I/O into page zero is it really does very little for performance.  If one studies typical device drivers, it becomes apparent that the bulk of the expended processing time is in the code surrounding the device access, not the device access itself.  Furthermore, if your system runs fast enough to require I/O wait-states, then the theoretical performance gain to be had with I/O in page zero is negated by the wait-stating, during which the microprocessor will be doing absolutely nothing.  Please explain to me how mapping I/O into page zero helps with that.

Page zero is much too valuable to be populated with I/O registers.  When you also consider the decoding headaches, you can’t convince me making I/O show up in page zero is a good idea.

Generally agree with you there and in this case I'd not bother being clever if I wasn't deliberately setting myself a task of minimalism. My current ROM based TinyBasic in the '134-SXB is 4009 bytes with an additional *mumble* 200 or so byes at $Fxxx to handle a 100Hz timer and interrupt driven serial IO. (The '134-SXB has plenty of EEPROM)

In my retro inspired minimal platform, I have a 4K ROM + 4K RAM and a VIA. No wait states.

(Actually, I have a 32K EEPROM which I can bank-switch in 4K chunks so I can save BASIC programs into in much the same way I save them on the '134-SXB - and I could use a couple of 8-bit latches rather than a VIA but I also need 1 or 2 bits of input for serial and a button - and the VIA is more, well, versatile, and I might want to hook up an LCD one day)

The ROM is minus 4 (bytes for the top 2 vectors - no interrupts so I can use the 2 byes of NMI vector is desperate - and why was reset not at the very top? Hm) so 83 bytes free. What I don't have is serial IO routines - and with no serial hardware I'll have to bit-bang 2 bits on the VIA. Can I do that in 83 bytes? I hope so and if I can I want to add in LCD code too (which I already have), but I can lose a function or 2 in TinyBasic if I need to. Decoding any 16-byte boundary over the entire 8K range is trivial as I have A[4:12] going into a GAL.

I've quite enjoyed the "code golf" challenge of squeezing as much functionality into a small TinyBasic (ok, approaching 4K and not the 2K of the 8080 versions of yesteryear) so this will be the result of that.

Cheers,

-Gordon

https://en.wikipedia.org/wiki/Code_golf

[Paganini]

Good previous discussion on this topic: viewtopic.php?f=4&t=2862

Both Peanutbutter-1 and Blue August have 128-byte I/O windows that can be configured to appear in different pages in the address space, including zero page. Address decoding speed is a little bit limited, because of using a comparator IC to generate the I/O signal. It could be faster if I didn't care about being able to move the I/O window around.

[Dr Jefyll]

Thanks for linking to that, Paganini.

BDD, we all agree that zero-page is valuable. But -- perhaps accidentally -- your post reads as though you've closed the door on I/O in Z-pg , and -- oddly -- as though you want us to close the door, too! But a black-or-white, yes-or-no answer doesn't serve anyone well. Rather than flattening the question, it's to our advantage to explore it and look for opportunities... which do indisputably exist.

In a minority of cases? Sure -- and that'll depend on circumstances. For example, my own SBC's have oodles of z-pg just sitting there unused (partly because there's no elephant of a BIOS to crowd things). In those circumstances, the cost/benefit becomes an easy decision (address decoding issues notwithstanding). And this isn't the only scenario in which it's sensible to say "yes" to a modest (though potentially crucial) improvement in code space and I/O speed. Keep an open mind, I say. Never say never!

drogon wrote:

I have 25 bytes spare in page 0 I can use that to map in the VIA (only 16 bytes, so I still have 9 bytes free for subsequent data and I know I'll need at least 4 for some serial code I've yet to write)

Yikes, that does sound uncomfortably close to the limit.

Still in the spirit of keeping an open mind to all options on the table, perhaps you should consider having half of the VIA registers in z-pg and the other half not! Unless I'm missing something, the hardware changes would be minimal. And, importantly, you'd have more headroom -- an "oh no!" cushion -- for the code that's yet to be written.

-- Jeff

[drogon]

Dr Jefyll wrote:

Thanks for linking to that, Paganini.

That's the trouble with forums that have been running so-long - so much there if you know the right search runes...

Dr Jefyll wrote:

drogon wrote:

I have 25 bytes spare in page 0 I can use that to map in the VIA (only 16 bytes, so I still have 9 bytes free for subsequent data and I know I'll need at least 4 for some serial code I've yet to write)

Yikes, that does sound uncomfortably close to the limit.

Still in the spirit of keeping an open mind to all options on the table, perhaps you should consider having half of the VIA registers in z-pg and the other half not! Unless I'm missing something, the hardware changes would be minimal. And, importantly, you'd have more headroom -- an "oh no!" cushion -- for the code that's yet to be written.

-- Jeff

Things are changing fast and I've almost sorted it out...

So moving data in/out of ZP - that's actually easy for this application (Squeezing my TinyBasic into a minimal system) as I'm fully embracing the facilities of the linker in ca65 and editing the data files lets me move data trivially - obviously the more I can store in ZP the faster TinyBasic will run and the more program code for Basic programs is left available but another little thorn lurks there and that's serial IO. I'm going to have to bit-bang serial out of the VIA so having that in ZP may be to my advantage.

Splitting the registers over the boundary - I could do that if I ran another address line into the decode GAL to give me 8-byte resolution - right now it has A[4:12] giving me 16-byte boundaries.

The 2nd thorn concerns a 3-bit register I need for the EEPROM banks - it's a 32KB device in a 4KB address space, so being able to control the top 3 address bits would give me 8 banks so I need a latch somewhere - and that was going to be the VIA, but if I can use the GAL for this too then I need a 2nd block to use as the address for the bank select register..

I could use the GAL as a polled 1-bit input register and latched 1-bit output register for serial but then the EEPROM bank would have to be in the VIA.

Or I do away with the VIA and put in a simple latch - 3 bits for the EEPROM and 5 bits spare...

Or do that AND have a VIA.

Almost too many choices now..

At least that's the theory, anyway. I'm still bouncing ideas round my head but what I have decided is to NOT map hardware at $00 but at $F0 instead - I feel there's less chance of a hardware crash then if some random program writes to 0 by accident. (Which is ORB/IRB in a VIA)

I also promised myself I'd not start this until the solstice.. but I already have the PCB half laid out... Oh well.

Making the VIA optional might be nice too... Oh well... Going to start breadboarding it next week...

Cheers,

-Gordon