please help :) Z180 - more then 64K - assembler ...

[Tom Tom]

Hi guys, I am an old fasioned 8 bit guy. 

A Z80 has 8 bit and the capability to address 16 Bit = 64K memory. I use zasm and get hex output, hex-upload to SC-108, start with g8000 (or thanks to stephen for his RAM@0000 code) and everything works fine.

I love this simplicity :)

And then broke Stephens SC-126 into my life! 

I thought -  ok, first 512k are rom,  then ram. so i told zasm .org 80000 and SP 90000 - to be honest, i really was sceptical how the assembler will squeeze a 20 bit into a 16 bit HL register...but i thought - ok, the .z180 directive will tell the assembler to do magic...

But - zasm is only able to address up to 512K....

Now my question _ PLS HELP :) ... i have no idea how to assemble code with this Z180, hexupload (not cpm!) and start with g80000 :) :)

SCM also can handle (in my current world) 64K - maybe any banking - and then hexupload in MY SPACE 80000? :) - i have no clue...

I think, more then 64K in a 8 bit system is magic - voodoo - devil stuff :)

I already started a massive google - but i did not find any step by step example. i only was able to get to know that the z180 will use 3 registers(?) to handle this banking.

But - when i want to start code at .org 80000 - how can i tell zasm this and how do i hex-upload this?

thx guys :)

[Tom Storey]

The Z180 has an MMU, so very likely you will have to configure some internal registers to map a slice of the 64K address space over a slice of the (larger) physical address space, and move it around as required to access different parts of it.

The program counter is only 16 bits, so you will have to compile some of your code to live within a certain piece of the 64K address space, and if you need to execute multiple pieces of code, you re-map the MMU over the chunk that you need to execute at that moment in time. Its a bit of a juggling act, but probably intended to be managed by some kind of OS, with the window being moved around to map in code and data for different tasks/applications etc.

If you want a larger linear address space that doesnt require any kind of juggling, you'll need a different CPU.

--
You received this message because you are subscribed to the Google Groups "RC2014-Z80" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rc2014-z80+...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/rc2014-z80/58d860a4-bfdc-4835-9f36-c58eeab1c8can%40googlegroups.com.

[Tom Tom]

thx - no, i dont want/need another (bigger) cpu - i just want to understand how the z180 handles the memory and how i can tell zasm that my code should be in sc-126 above the 512k of rom. further, how can i hex upload the hex to sc-126 in SCM and tell scm that my code is in ram space above 64K ?

Or do I have a thinking error somewhere? 

so, the zasm also just "see" 64K of address space - korrekt? but how do i tell him, that the code should be in the physically space of 90000 ??

[Douglas Miller]

Looking at things from the perspective of the program/instructions, the instructions don't know about more than 64K - all references are within a 16-bit address space. The assembler never needs to know about what physical address the program will be loaded into, only the *logical* address (i.e. the address that will be in the (16-bit) PC register to start the program). If SCM allows you to specify the physical address, then you can do that when loading. Otherwise, I suspect SCM has a default/hard-coded physical address for the "user area" and that is where your program will be loaded. In that case, you will have to write a "bootstrap loader" that retrieves the various chunks of your program code and places them in the assigned (by you) physical addresses.

[Tom Storey]

The Z180 CPU can only logically work with 64K at any one point in time. To access "more" than 64K, you have to "replace" part of the 64K. By doing this you *effectively* get access to more ROM/RAM than the CPU can logically address.

The important bit to remember is that you are still logically constrained to 16 bit addresses, hence 0x80000 is not a valid address because it is outside of 64K.

To execute some code from 0x80000 what you instead have to do is tell the MMU to open a window over 0x80000 and map it into the 64K that the CPU can work with, lets say at 0xA000. Your code thus needs to be written and compiled as if it exists logically at 0xA000, but physically you can place it anywhere within the physical address space. You then configure the MMU to map logical 0xA000 to the physical address where it is located.

I hope that makes some more sense.

Perhaps think of it like a torch illuminating a small part of a big wall. You can only ever see a small portion of the wall based on where the torch is pointing, but never the full wall.

I am not familiar with SCM, so someone else will need to step in to help there. :-)

To view this discussion on the web, visit https://groups.google.com/d/msgid/rc2014-z80/c7e60916-ff2a-416e-ac2b-81a921a71856n%40googlegroups.com.

[Tom Tom]

Ok, thanks guys. Yes, I know that the CPU only can address 16 bits logical. I also understood, that the cpu maps physical address ranges into logical 64K address range. But I still did not understand how i deal with this mapping in SCM ...where do i know, which physical space is currently mapped in which logically in address space in scm? maybe i have still some thinking errors - as i said before - i was familar with 64k logically is 64K physically - mapping was never any topic in my projects before.

[Alan Cox]

I am not familiar with SCM, so someone else will need to step in to help there. :-)

Akin to RC2014 the BP80 boards like the SC126/130/etc use ROMWBW and a flat 512K/512K memory card so the basic setup you have is

Low 512K ROM

High 512K RAM

At start up the CPU memory all maps to the bottom of the ROM and the ROM code at 0 sets up the memory to map in some RAM. By the time you are in CP/M it's all being managed for you and if you play with the MMU registers it will break. In fact even CP/M is oblivious to what is going on below it 8)

The actual model is fairly simple - part of the register configuration lets you split the memory into chunks, the other one essentially gives you a large number to add to the address the CPU provided. So when you LD A,(08000h) the CPU decides which range it is in and then adds the offset set for that range to give a much bigger address so your LD in fact ends up fetching 0x88000h or similar. It's not part of the instruction set - it's an I/O device between you and the memory - even though it's on chip.

If you are taking over at the hardware level then you can  just use the memory management registers in the Z180. If you are wanting to use ROMWBW you'll need to use the ROMWBW services to allocate and switch other banks of memory and playing with the hardware yourself will create a nasty mess fast.

See: https://raw.githubusercontent.com/wwarthen/RomWBW/master/Doc/RomWBW%20Architecture.pdf

Some of the Fx functions. As you apparently can't give banks back at this point you'll have to reboot after using those functions. You'll also have to be very careful what you call and how you call it under CP/M if banking stuff.

There are a few ways of making use of the banking you'll find used

1. Banks are just used as a glorified ram disk and you copy data to/from it keeping the normal banking

2. Code is carefully carved into chunks akin to CP/M overlays and banking is managed by hand

3. Similar to #2 but the toolchain does some of the work switching banks on function calls as needed. I have SDCC patches to do this

4. Some memory is allocated for the data, and common code (support routines etc). Everything else is arranged by the tool chain and you program as if you had lots of code memory whilst behind the scenes function calls in your high level language bank switch back and forth. AFAIK only the old Zilog development kit ever supported this model. It's also the model used in the very similar Rabbit processors and tool chain.

If you are running under ROMWBW then CP/M will give you a big ramdisc of the remaining memory and the best thing to do in most cases is probably to totally ignore the CPU banking feature and just use the ram disc to manage data. If you are not using CP/M then you can in theory use the HBIOS functions.

Alan

[Douglas Miller]

SCM is not RomWBW, so it is a different scheme. I'm pretty sure that SCM has good documentation, or at least Steve Cousins is good at answering questions.

[Alan Cox]

On Mon, 5 Jul 2021 at 18:02, Douglas Miller <durga...@gmail.com> wrote:

SCM is not RomWBW, so it is a different scheme. I'm pretty sure that SCM has good documentation, or at least Steve Cousins is good at answering questions.

I missed the SCM reference. SCM simply maps the low 32K to bottom of flash and the top 32K to the top of RAM. Having had a quick look at the SCM 1.2 code that seems to still be all it ever does with Z180 memory management.

Alan

[Tom Tom]

thanks guys - very helpful!! when I play with RomWBW or cpm I don't care about where the OS map things to - I have enough ram for my program beginning from $0000 or $0100 :)

but the splitting into two 32k spaces in SCM was the decisive note! I wrote quick counter code for the sc-129 (par I/O) with .org 8000, hex uploaded and it worked. 

BUT I still did not understand this mapping at all - not yet...but I think slowly light comes in....thx guys!

[Steve Cousins]

I think others have explained it pretty well, but here's my take from the SCM point of view.

As Alan says, SCM simply configures the 64k (16-bit) memory map to include 32k ROM and 32k RAM. After that SCM knows nothing of the rest of the memory. SCM simply operates within that 64k of memory. All addressing within SCM is 16-bit so you can not make reference to the rest of the memory using SCM commands or APIs. If you want to access other parts of the memory you need to directly access the Z180's MMU registers. It takes a bit of study to work these out but ultimately it is quite manageable.

Steve