Look at the listing file. a: forces 16 bit addresses, even for locations that could otherwise be direct page. f: forces 24 bit addresses, even for locations that could otherwise be 16 or 8 bit. They're emitted by the disassembler because the code it's disassembling has operands of those sizes, and (I assume) it's a way to ensure that when you assemble the disassembled code, you get exactly the same binary.

For example, lenhi = 4. If you assemble "sta lenhi" with direct page set to $0000, most assemblers will give you the direct page STA opcode $85. But the binary contains $8D. Saying "sta f:lenhi" forces it to emit the right opcode.

Why does the binary use $8D? My guess is that this code was built in a system that does assembly first, then linking. The addresses of things are only known at link time, so the assembler has to make safe assumptions if the source code doesn't say otherwise. It just knows that lenhi is somewhere in memory, not necessarily in direct page, and must use a 16 bit address for it. (To be truly safe it would have to assume a 24 bit address, but that's a reasonable assumption to make: the few things that end up outside bank 0 can be tagged by the programmer).

That doesn't explain why the same symbol is sometimes tagged with f: and sometimes not. I have no idea on that one.

Thanks John West, that clears things up. I don't really need all that as I only want to target the 6502 CPU.
I will start simple and try to setup the connection via usb first. I will study the schematic and datasheets and the source code parts involved in making the connection and send and receive data.