Hi-speed loadings for zx81

[decicoder]

Hi

I'm new here and maybe you can help me. I've developed the Otla tool that makes hi-loadings for MSX , Amstrad and and ZX Spectrum sistems.
Now i`m adapting it for zx81.
But i have a problem. I don`t have any real zx81 for doing the final tests

Here: http://personal.auna.com/casariche/zx81/test_z81.zip
some samples of hi-loads that works on EightyOne emulator (great emulator , without it i couldn't do anything ). Will them work on a real zx81?

And here: http://personal.auna.com/casariche/zx81/adjust_81.zip
a program (in wav format) to adjust the volumen level for loading. First LOAD"" and play adjust_81.wav. Then RUN it. You will see for a second six numbers and then screen will go black waiting for a signal audio. Then PLAY signal_11.wav or signal_12.wav.
If signal is detected you will see again 6 number.
Pay special atention to 2nd number in first file. Adjust audio volume until this number is close to zero.
Then note rest of numbers. If they are close to the ones seen on emulator , I think hi-speed loads for zx81 will work.

For details on the loading routine visit this page: http://code.google.com/p/otla/wiki/AdaptacionZx81

[yerzmyey]

Yo, man.
Welcome here, at first.
Well, many thanx for supporting ZX-81.
I will test Your prog soon and let You know.
Greetingzzzz!!

[yerzmyey]

So - the ManicMiner works perfectly, on my standard settings.

Now I'm waiting for some PC convertor (like this one for Spectrum http://personal.auna.com/casariche/k7zx4/k7zx4.htm ) adding also required loader,
to let people convert progs themselves.

[decicoder]

Excellent!
Then the PC tool for converting zx81 files will be released soon. It will convert .z81 and .p files to .wav.
.z81 conversion is already developed. For .p almost. There's a little problem to solve.
May be you can help me here. I'll explain it.
This is the program for the hi-spped loadings:

Code: Select all

1 REM ----------------
2 SAVE "00"
3 RAND USR 16514

One part of the machine code is located in REM line. Another parte at printer buffers 16444
For loading .P files the hi.speed loading routine loads bytes form 16291 adress (PPC varable system). So PPC will result 0 and then bytes of .P file will fill memory.
After last byte is loaded routine jumps to $0206 (ending of de ROM load routine).
But a error message is displyed: c/0 (if loading of bytes starts at 16293 and PPC is not modified, message erro is c/3).
At this point you can type RUN an then hi.loaded program wil work correctly (As far as i test on emulator)

This is a minor bug. Is there a any solution for that?

[XavSnap]

Hi,

Yerz is right.
You had to give a BOOTSTRAP ASM program to load your sample !
Or give us the name of your "wav compiler".
On the ZX81 ROM, there's no Hi-load routine, but on the TK85, the rom is patched with a loader and a saver.

1 REM ----------------

Don't work !


Have Fun !

[yerzmyey]

I'm afraid I am not a good coder but surely XavSnap or SirMorris (or other guys) can help.
Anyway, once again - great stuff, man.

[siggi]

Another parte at printer buffers 16444
For loading .P files the hi.speed loading routine loads bytes form 16291 adress (PPC varable system). So PPC will result 0 and then bytes of .P file will fill memory.
After last byte is loaded routine jumps to $0206 (ending of de ROM load routine).

Other programs load/save ZX81 programs starting with address 16393 (VERSN). You should do the same.
One problem could be, that your program part in the printer buffer at 16444 is overwritten by the loaded program.
One other problem could be, that the jump to the end of the ROM routine would execute code, that does not fit to the new loaded system variable state. So other save/load programs return to BASIC by calling the error routine at address 08 and return error 0 (vlaue $FF results in error 0):

RST 08H
DEFB $FF

That error routine cleans up the stack contents and returns to command mode.

HTH Siggi

[decicoder]

RST 08H
DEFB $FF

That is the solution!!! Thanks.

One problem could be, that your program part in the printer buffer at 16444 is overwritten by the loaded program.

That is solved this way. Before converting the original bytes in .p file 27 bytes at address 16444 are modified with bytes of the loading routine. Bytes will be indeed overwritten but they wil be with the same value. Finally the .p file loaded in memory is not extacly the same that original one: part of Printer buffer is corrupted. This should not be a very big problem .

Finally the loading routine for .p files wil be located at printer buffer + calculator memory area. There's no need for REM line. It is this:

Code: Select all

          org  16444          

full    ld   (hl),b
        inc  hl
        ld   b, c;     
more    
cicle
pi_LOW  in    f,(c)
        jp    po, 16447 ;  pi_LOW

        ld    a,c

pi_HIGH dec   a
        in    f,(c)
        jp    pe, 16453  ; pi_HIGH       

        cp    d
        rl    b
xret   defb  0xc9   ,   0xec      ;   ret   / jr  nC, full     ;dir$404e                 
                  
        out  ($ff),a               
        cp  e       
        jr  nc, more   ;                                 
                                  
        rst $08;                  ;$4055
        defb $ff

start_laoding
	out  ($fd),a              ;$4057= 16471                              
                                      
        ld    bc, $00fe 
        ld    de, $f6e9    
        ld    hl, $4009 -2 

pii     inc   b
        call  16447 ; cicle        
        djnz  pii

        ld    a,$30
        ld    (xret),a ;
        jp    16446  

[yerzmyey]

So - we're waiting for the convertor then.

[XavSnap]

Hi !
You can also use the "self mode" exit...
Jump to the $005B address in the rom.

It able clear the stacks, reset errors and to return to the basic routine at Nxt_Line address.

In case of a " If a=usr 16514 then PRINT"Hello" ",
The "JP $005B" will discared the Print "Hello"

In a Let Line, the variable will stay with old value.

If you call an ASM using a Print
PRINT chr$(usr 16514);"ERRORS."
A RET, will display a space and "ERRORS".
A JP $005B display anything and jump to the next basic line.