How can this be relocated?

[alank2]

I've got a program that is a demo for the NEC PC-6001A. It is called substrike and has two components. The first is written in BASIC and it has a loader to load the second part. The first part is fine and easily dealt with, but the second part is the problem. It loads on a Z80 compatible CPU between 0xC400 and 0xDFFF. The problem is that I want to make it work from a floppy disk instead of loading from cassette. The computer has more memory and a floppy interface which double the memory to 32K, but unfortunately the way they designed it, the floppy uses the memory area 0xDA00-0xDFFF. With the RAM expansion I have 0x8400 through 0xD9FF available, but yet the program wants to load 0xC400-0xDFFF. To make it easy, I would just think of moving it from starting at 0xC400 to 0xB400. Could I just find all the CALL/JMP opcodes and change it possibly? I'm attaching it.

 

[alank2]

Maybe it doesn't need to be relocated. I wonder if I could load it into memory and then copy it into place and then execute it. I don't think that memory area would be used maybe.

 

[krebizfan]

Would changing the address in the BLOAD command in the BASIC program work? The BASIC quick reference shows that the load address can be appended to the command.
BLOAD PROG 1, &H100 is the example given though the scan shows the value as IOO which I think is mistake.

 

[alank2]

My current plan is to BLOAD it in at 0xA400 and then write a small assembly stub at 0xA300 that copies 0xA400 directly to 0xC400 for 7168 bytes and then executes it. Hopefully the extended basic won't touch that memory if it never gets control returned to it.

 

[alank2]

Here is my loading code - I"m sure you guys can improve it! It has an Z80 compatible, but I'm only familiar with 8080

A300                          .ORG   $a300   
A300   21 00 A4               LXI   h,$a400   
A303                LOOP:     
A303   46                     MOV   b,m   
A304   3E 20                  MVI   a,$20   
A306   84                     ADD   h   
A307   67                     MOV   h,a   
A308   70                     MOV   m,b   
A309   3E E0                  MVI   a,$e0   
A30B   84                     ADD   h   
A30C   67                     MOV   h,a   
A30D   23                     INX   h   
A30E   3E C0                  MVI   a,$c0   
A310   BC                     CMP   h   
A311   C2 03 A3               JNZ   loop   
A314   C3 00 C4               JMP   $c400

 

[alank2]

Oddly, it is working if I enter 0 files at startup up, but if I specify 2 files, then one of the boats you are trying to hit is corrupted in its graphics. My loader copies the full 7168 bytes in and directly executes it. I wouldn't think the extended basic would ever have control again at that point, so I find this odd. It may be possible for the game to call areas in the non-extended basic rom, but again, that wouldn't use the area in the upper 0xDxxx range.

Could there be an interrupt/vector taking control? This thing has ROM at 0x0000-0x3fff.

 

[CP/M User]

If it's a Z80 Compatable system, I'm just wondering if it's got something like LDIR or LDDR?

That's what I'd do on my system, so you can load the file somewhere else from Disk and use something like this:

LD HL,&<address of the code>
LD DE,&<where it needs to go>
LD BC,&<the length of it>
LDIR
RET

 

[alank2]

That is quite a bit easier than what I came up with!

Here it is, probably very few people in the world will be interested in it, but the cassette demo for the NEC PC-6001 modified for disk use on a system with 32K and extended BASIC. (Mode 4, Files 0, Pages 2). Files must be set to 0 for sub strike to work for some reason - I can only guess that some of the functions that the game uses still interact with that upper area of memory where the number of files you specify at reset matter.

 

[alank2]

I made a tool that can import/export files into a disk image now, so I've done some more testing on this. CP/M user your optimized Z80 memory copier works fine with the LDIR instruction.

I am still finding a mystery with the game though. On this system when it boots with the extended basic cartridge, it asks how many files you want. When I select 0, the game boots and runs fine. When I pick 2, some of the ships you are shooting at are corrupted. I believe this is because of the memory area shared by extended basic for floppy file access and the game. The game does not need or have knowledge of the extended basic cartridge which loads between 0x4000-0x7fff. Regular basic is at 0x0000-0x3fff. Normally basic uses another area of ram 0xfa00-0xffff, and I suspected that the number of files selected is stored here somewhere. I then attempted to load the 16K version of this fa00-ffff range using the same copy method I was using for the game. My thinking was that if the game calls out to the 0x0000-0x3fff rom basic for anything, it will see the fa00-ffff range as normal data for it and be content. This also did not work and I still have corrupt ships if I specify 2 for the number of files. What is baffling is that practically all of the memory that would be in the machine if it were 16K is essentially being copied to what a 16K machine would be. 0xc000-0xc3ff is text screen. 0xc400-0xdfff is the game copied in. 0xe000-0xf5ff is the extended graphics screen. 0xfa00-0xffff is the basic area also being copied in. Could there be another way it knows the number of files? I'd love to find out how to make the game work when one selects 2 for the number of files by overriding it somehow, but I am out of ideas.

 

[CP/M User]

Sorry I'm a bit confused because I'm not familiar with the OS the NEC uses.

Earlier when you said that you have 0x8400 to 0xD9FF available, I thought if it were possible to load the second file somewhere in that area, the LDIR could be used to MOVE it to 0xC400-0xDFFF area, though if other files need to be loaded, this could be a problem if the file occupies the area the OS resides. Though it sounds to me the OS has to know what files needs loading, it sounds similiar to a MSX, though MSXs have additional file handling commands. The routine I supplied is only 11 bytes in size, it should be ample space if it's possible to load the 2nd file to that free space area before moving it to 0xC400, the routine also needs to be executed, so whatever command BASIC has to execute Machine Code routine, once RET (&C9) is found, it returns back to where BASIC executed the command from.

The alternative would be a painstacking process of moving the location of that M/C, though depending on what tools are available a really good disassembler can generate dummy labels and then reassembled to the new locality (0x8400 ?).