fuck me these are nibble addresses

I entered "87", which is hex 0x57, and it's in sector E07
E is the 5th letter of the alphabet. so it's sector E07.

okay so the 6-byte format is:
byte 0: icon
byte 1: what it is
byte 2: what sector it is in

bytes 3-5 are for intra-sector positioning (presumably). now to try and figure that shit out

okay this is weird. Byte 3 is the x-position within the sector, and it can have (valid) positions between -19 and +19.

If you go above or below that range, it'll get placed into neighboring sectors, which fucks up the game's item detection. It only looks in the current sector for items, but it won't see an item that's one sector over but positioned at -50

byte 4 is Y-position using the same rules (origin is at bottom left)

No idea what byte 5 means. it's set to 18, but changing it to 0 or FF or anything in between seems to change nothing

okay I can figure out where all the items are now

C:\DOSBox-X\drive_c\Echelon\py>python decode.py ..\Az.ARE az.out
header=(0, 144),n_items=5
icon=0,itemid=2,sector=D04,x=6528,y=4992,c6=31
icon=96,itemid=128,sector=D11,x=7552,y=7040,c6=3
icon=108,itemid=152,sector=D11,x=3712,y=4992,c6=33
icon=20,itemid=41,sector=E06,x=5760,y=6784,c6=18
icon=18,itemid=38,sector=L11,x=3456,y=7296,c6=1

but it can only have on area loaded.
So when you're at A01, you should have parts of three other areas visible... it solves this in a silly but simple fashion:

There's nothing at the borders.

when a sector isn't loaded it's rendered like it's there anyway, but empty.

So when you're at A05 and looking west, you should be seeing what's in B14. And you are... because B14 is empty. The stuff doesn't start to B13, which you can only see by traveling into B14 and loading that area instead

went and found to other copies from other places, they both crash in the same way. weird.

Here's the link if anyone wants to take a crack at running it:
http://cd.textfiles.com/smmodem/ARCHIVE/SBUST24R.ZIP

correction: the memory gets repeatedly overwritten before it ends up in the endless invalid-instruction loop.

I think it's trying to do some kind of unpackery nonsense but it breaks for god only knows what reason and it ends up uncompressing over itself

no, unless they're getting tricksy with it.

Like, timebombed software sometimes doesn't just check the date: it checks if you're cheating at the date.

One easy way to do this is to look at what files you have on your drive. if there's a bunch from 2010, you are probably lying about it being 1994

dude! I was just reading the Echelon manual and you can send off to Access software, for 5$ (plus 0.50$ shipping and handling) they'll send you a COMPLETE patrol zone map, with all areas filled in!

It's only been 37 years or whatever, you think that offer is still good?

Access Software hasn't existed since 1999. Microsoft bought them. Maybe Microsoft has that somewhere in their archives...

HEY MICROSOFT, OPEN SOURCE ECHELON!

that rarely works. but it's worth trying.

ANYWAY I looked through all the echelon copies on eBay, none have the filled-out map (or if they do, the owner doesn't know, because they're still sealed)

huh. in this code, it uses the pre-assigned AX register when MS-DOS calls the entry point.

I... don't know what's in AX at the start of a DOS program? I'm sure that's documented somewhere, but I'm not sure where

I tried using UNP again: it throw a memory error from AXE.

and I was able to confirm (since I have AXE2.2, the packer used) creates a file that breaks in the same way in UNP.

so it turns out there is a filled out map! It's just not for the PC version. I forgot to check ports. This is thanks to @growf who alerted me to it:

https://worldofspectrum.org/pub/sinclair/games-maps/e/Echelon.png

@foone This shows that the starting map for the C=64 version looks identical to the corresponding sections of the ZX Spectrum version you linked.
https://c64sets.com/echelon/patrol_zone_map_top.jpg

So, yeah, probably the same. Raises the obvious question: Which is the best version to play? ;)