LD80 - help with error message

[nockieboy]

Hi everyone,

I'm trying to use LD80 (apparently) to assemble the BBC BASIC source files along with a custom patch.z80 file for my DIY computer. I've finally managed to get the project to build - almost - but the assembly (using ZMAC) is failing with this error:

ld80: Unimplemented extension type 0x80

Does anyone have any idea what the issue could be, or point me in the right direction to find out? I seem to be drawing blanks with my Google-fu.

 

[daver2]

I can see the point at which the linker is generating the error [section.c within function add_item()]. It comes across a 'type' which is T_RELOCATABLE and T_SPECIAL. It then identifies it as a C_EXTENSION. However, the next test fails. It is looking for a character 'A', 'B' or 'C' - but finds the value 0x80 and dies a horrible death as a result.

This (in my experience) is an incompatibility between the assembler and linker somewhere - or you are using a 'feature' of the assembler within your source code that is not supported by the linker.

Did you get ZMAC and LD80 as a 'matched pair', or have you downloaded them separately and are trying to get them to work together?

I had a similar problem with a PDP-11 cross-assembler. The assembler and linker were incompatible. With a bit of 'hunting around' (and a post or two) I had a different solution that worked.

Another issue I had was finding a 'branch' of the code that was stagnant. Locating another site (where someone else had taken up the support) cured the latent bugs in the product.

Dave

 

[durgadas311]

That message is talking about MicroSoft's extension to REL file format, that DRI did not implement/support. These extensions have to do with performing arithmetic operations of relocatable objects (values). This is the reason that I can't mix ZMAC REL files with DRI LINK commands (unfortunately).

There is a description of the REL file format in MicroSoft's L80 manual, page 1-7. It takes a minute to get oriented, as the format is a *bit* stream and so simple hex dumps don't do any good. The most complete description of REL that I've found is in View attachment Microsoft-macro-80-l80.txt, but that still does not define the extensions generated by ZMAC.

That being said, the extension byte that ld80 is complaining about is supposed to be an ASCII character, so "0x80" might suggest that the file is corrupted or isn't actually REL format.

 

[nockieboy]

Hi daver2! Thanks for your quick reply.

To be honest, I've had this BBC BASIC source sitting in a folder within my main project since the start of last year. I might even have posted here way back then (my memory fails me) as I managed to get it to build at some point, as I have a working version of BBC BASIC on my DIY computer, so I must have assembled a working version with the correct IO port settings etc. at some point.

Problem is, can't remember how I did it. I've since come back to add in some graphics routines as my FPGA GPU is coming along nicely and it would be nice to be able to test some of the accelerated routines in a BASIC program. I've got a BBC BASIC project, can't remember it's origin, and it has a 'build' file and what appears to be a Linux version of ZMAC. I'm a Windows user through and through, unfortunately. I have, however, worked out how to get the project to build using a bash terminal and that's where I'm getting this error. ZMAC and LD80 are supplied in their own folders, in a 'tools' folder, within the BBC BASIC main folder, so I can only assume that they were supplied together and should work together.

One thing I have done is copy-paste a patch.z80's source from a github repo (https://github.com/breakintoprogram/next-bbc-basic/blob/main/patch.z80) and past bits of it into the existing patch.z80 in my project. It references a non-existent (even in the original github project it's from!) function called EXPR_P2, which I've replaced with calls to EXPR instead, but I'm wondering if there isn't some other glitch in the system as a result.

I've attached my BBC BASIC project folder, but have had to remove the .lst files and (I think) source files for ZMAC and LD80, in case it's any help.

 

[nockieboy]

That message is talking about MicroSoft's extension to REL file format, that DRI did not implement/support. These extensions have to do with performing arithmetic operations of relocatable objects (values). This is the reason that I can't mix ZMAC REL files with DRI LINK commands (unfortunately).

There is a description of the REL file format in MicroSoft's L80 manual, page 1-7. It takes a minute to get oriented, as the format is a *bit* stream and so simple hex dumps don't do any good. The most complete description of REL that I've found is in , but that still does not define the extensions generated by ZMAC.

That being said, the extension byte that ld80 is complaining about is supposed to be an ASCII character, so "0x80" might suggest that the file is corrupted or isn't actually REL format.

Thanks Doug, that throws some light on the issue - the REL files should be created by ZMAC, so perhaps they're not compatible with LD80 as Daver2 has suggested, but that's confusing - as far as I'm aware, both ZMAC and LD80 came with the project.

 

[durgadas311]

Thanks Doug, that throws some light on the issue - the REL files should be created by ZMAC, so perhaps they're not compatible with LD80 as Daver2 has suggested, but that's confusing - as far as I'm aware, both ZMAC and LD80 came with the project.

Correct, although they are of different pedigrees. I've not found ZMAC and LD80 to be incompatible, but I most-often use RMAC/LINK since I need to generate SPR/RSX/PRL files and no other linker seems to do that.

I'd still look at the "extension type 0x80", which is from a "switch" statement in ld80 where it is looking for 'A', 'B', or 'C'. So, 0x80 is a *VERY* illegal value. I would make sure that my "REL" files are really REL files.

 

[durgadas311]

I did a little experimenting with your code bundle. The offending REL object is related to the "external chain" for the second "CALL EXPRI" in 'PLOTPX' of patch.z80. As I look at it, I am wondering why you (they) are using ASEG here. That really does not go well with the rest of files being default (CSEG). I would suggest ditching ASEG and eliminate/replace the ORGs. The "ORG 0100H" should not be necessary since the linker will do that, and the other ORGs (and any associated IF) should be replaced by REPT or other methods of filling the space to pad out to the desired *relative* address.

UPDATE: there may be a bug in zmac, but I'd focus in why "ASEG" is being used in this project.

 

[daver2]

I have just checked my ZMAC.

I 'blew up' ZMAC dated 5jan2019 and had to download ZMAC dated 4apr2021. This fixed a bug in ZMAC itself.

I see that the website itself that I got ZMAC from 'recommended' ld80 if you are using .REL files to separately link. However, up until now, I have not been using ZMAC to generate (and therefore link together) separate .REL files.

Here is where I got mine from http://48k.ca/zmac.html. I do note that they have a 'modified' ld80 though...

Dave

 

[shirsch]

I have just checked my ZMAC.

I 'blew up' ZMAC dated 5jan2019 and had to download ZMAC dated 4apr2021. This fixed a bug in ZMAC itself.

I see that the website itself that I got ZMAC from 'recommended' ld80 if you are using .REL files to separately link. However, up until now, I have not been using ZMAC to generate (and therefore link together) separate .REL files.

Here is where I got mine from http://48k.ca/zmac.html. I do note that they have a 'modified' ld80 though...

Dave

Ah, George and Peter Phillips. Both gentlemen are regulars on the Tandy Troubleshooting Discord and would be able to fill in the blanks.

 

[durgadas311]

I'm digging into the code a bit and trying to understand what is needed. So, it looks like this is a CP/M BASIC program then? It seems you should be able to use CSEG/DSEG as they are intended and then let the linker "do the right thing" and creating the COM file. Here's a git patch of what I did (think is correct) to build the program. I'm not sure what hardware dependencies the program has, but it sort of ran in my CP/M emulator. Not sure how to use this version of BASIC... View attachment 0001-Get-build-working.patch.txt

 

[nockieboy]

Thanks Doug, you're a star - the project builds without any errors now. I just have to sort out my 'download.,com' program that receives the data stream from the serial console - it's not as stable as I need it to be to download such a large file, strangely. One problem replaced by another, it seems.

 

[durgadas311]

You could also choose the output type "hex" on the ld80 command, a HEX file might download better?

 

[nockieboy]

Yeah, I've always been able to transfer any size file without issue over the serial port, it just seems to have become far less stable since my work on the GPU driver for CP/M. There's obviously an issue there I'll need to dig away at.