Not one capture here. Every picture is drawn from the bytes of the tape, by running in Python the same upload routines the Z80 runs. The listings and the numbers are reproducible with make, and reassembling gives back the whole tape byte for byte.
The CARGA file runs from 0xC000 to 0xD3DF, but its execution address is 0xD302, not 0xD300. The reason is in those two bytes: they hold 69 D3, the word 0xD369, which is the loop that reads a tape block.
The first half of the game ends with ld hl,(0xD300) / push hl / ret at 0x5CC2, and that is how it returns to the loader to ask for the second half without carrying the address in its own code. The loader survives both programs, because no tape block reaches past 0xD2FF.
The tape holds four files: one line of BASIC, the CARGA binary, and two headerless blocks of 30,472 and 30,467 bytes. The BIOS never reads those two: the loop at 0xD369 reads them by hand with TAPION and TAPIN, byte by byte, and splits them into three sync bytes, 0x2400 bytes at 0x4000 and 0x5300 bytes at 0x8000.
So both halves of the game occupy exactly the same addresses at different times. That is why this project is five listings and not one: carga, p1bajo, p1alto, p2bajo and p2alto.
There are no screens here: there is a longitudinal cutaway of the ship, 128 x 52 tiles -1024 x 416 pixels- with the deck, three masts with their sails and rigging ladders, and three runs of cabins and hold below.
The 0x1A00 bytes run from 0x9000 to 0xA9FF, and what says the width is 128 is the 0x80 step between rows in the loop at 0x4285. The game cuts a 32x24 window out of that plan and scrolls it both ways.
The five commodities -water, wine, food, timber and cloth- are bought at the quayside warehouse, each costing one of the sixteen units of MONEY. But the number does not stay in a counter: the routine at 0x4F60 in the second half stows the cargo in the hold, one pile per commodity and as many pieces as units remain.
Drawn out, the tiles of each pile are staved barrels (0xBF-0xC4), tied sacks (0xB9-0xBE), stacked planks (0xC6-0xC8) and rolls of cloth (0xC5, 0xC9 and 0xCA).
The tape records fixed-size blocks -0x2400 and 0x5300 bytes- no matter what, but the first half's program ends at 0x5F9F and the second's at 0x5C3F. Whatever was in memory got recorded behind them. That is 7,564 bytes out of 66,016 (11.5%) that are identified and accounted for, but that no instruction ever touches; 4,534 of them are block tail.
One of those leftovers can be read: from 0xCC56 to 0xD2FF the first half carries 1,706 bytes identical to the CARGA file but for a single byte. It is the loading screen, still sat in memory when the block was recorded.
Decoding the name table at 0xD000, down the right margin of the loading screen you read "OMIKRON Softwarwe", with two w's. The typo is on the tape, not in this disassembly, and a test pins it.
The letters are not ASCII: they are tile indices, and they use two different alphabets inside the same table (0x00-0x19 and 0x20-0x39, two sets for the same twenty-six letters), plus six tiles (0x3A-0x3F) for the tall two-tile capitals that start "El", "Descubrimiento" and "America".
Under each picture is where it comes from and what is on it.
CARGA file. It is the only piece on the tape that names the publisher, and it does so with a typo: OMIKRON Softwarwe, running down the right margin