z88dk forums

1 - Ok, I've just enabled the '-zorg' parameter in the zx81mode too, but the resulting packaged program will not work when different location is specified.   You'll need to manage the intermediate 'a.bin' file.

That would be ok for me. I currently don't use the -create-app option and use directly the .bin file (I wrote about "raw binary data" above).

2 - Z80ASM *IS* able to generate relocatable code (it will be slightly bigger).  It can be done, and I did it for the Spectrum (see the bin2bas-rem tool in the "support" folder), but it is not an easy task.  If you show it is really useful I can provide a similar tool.

Is there really another tool necessary, when using the only .bin file? I also have MEFISDOS and can load binary data from MMC into ZX81 memory without any loader.

3 - I'm not aware of an easy way to know at which location the program begins/ends, I agree the absolute ending position after the linkage could be very useful, but this is the price we pay for that powerful incremental linker, I'm afraid.   You can obviously compile the program a first time, look at its lenght, compute the first free byte position and update a local program constant by hand.
Honestly I think the ZX81 is the machine getting the higher benefits from hand optimizations: isn't the higher memory half available for data only ?

Only the highest 16K (from 48 to 64K) cannot be used for M/C, but for data. 32K-48K can be used for M/C, if you have a "M1-NOT" modification done in the ZX81 (most of us have that done).

My thoughts are:
I wrote a new user interface (UFM: USB File Manager) for the USB driver, used in the German ZX-Team:
http://forum.tlienhard.com/phpBB3/viewt … 4101#p4098

With the driver a BASIC program  or data (also binary code) can be loaded from USB stick to any region of the ZX81 memory. So depending on the destination of the loaded data, the driver/UFM must not run at the same location, where the loaded data are written to.

So I compiled UFM for adresses:
11182 (regionb 8K-16K)
35678 (region 32-40K)
and a version for region 40-48K is also requested.
So my first idea was, to have a relocatable UFM. That would make life easier

My next idea was, that the UFM could itself load the USB driver (must also be relocatable) to a free memory location behind or before the UFM. Therefor UFM must know its beginning and end.

But having a relocatable UFM only would be fine ...

Siggi



------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure
contains a definitive record of customers, application performance,
security threats, fraudulent activity, and more. Splunk takes this
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d

It works

Thanks!!!

One additional question:
when the program has been started, relocatged and finished:
if I save that relocated program and load that changed program back to another location: will it there run again?

I want to hold setup-values in the program, which should be available at the next start anywhere (see old thread of SUPERSTATIC variables).

Siggi



------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure
contains a definitive record of customers, application performance,
security threats, fraudulent activity, and more. Splunk takes this
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d

I played a little bit with a relocated program and saved and reloaded it to another location, but it did not run there.
It seems that the relocator patches its own entry, so that the program is relocated only one times ....

Siggi



------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure
contains a definitive record of customers, application performance,
security threats, fraudulent activity, and more. Splunk takes this
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d

The 'second' push is the key one.  The trick is to set IY with the current location, so:

push bc
push hl
pop iy

..should work;  btw since we are not passing parameters on those registers I think it is not that horrible thing to alter BC or HL on entry, choose your favourite way.


>And a question to zx81_ctr0.asm:
>is a call to "l_dcal" allowed?
>I want to do a "call (hl)" by loading HL and calling "l_dcal". But why are there 2 "jp (hl)" >at "l_dcal"? Is this location patched sometimes?

I don't remember of tricks on it, probably it is just an error 



------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure
contains a definitive record of customers, application performance,
security threats, fraudulent activity, and more. Splunk takes this
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d

Hi Stefano

something is a little bit strange, when a relocated ZX81 program is runnig the first time (and relocation is processed): the C program (after RAND USR xxx) then comes back to BASIC with error 4/0 (out of memory).
If it is started again (so no more relocation is done), it returns without error: 0/0

Siggi



------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure
contains a definitive record of customers, application performance,
security threats, fraudulent activity, and more. Splunk takes this
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d