Old school Eprom & Prom programmer.

[Muttley Black]

Here is the part that talk about that:

------------------------------------------------------------------------------------------------------------

8.2 COMMUNICATION FORMAT

The developer uses two formats. The "memory dump" described below and the intel hex. To change the format, after pressing the <S-IN> or <S-OUT> key, press the <P> key. This causes a '1' to flash on or off on the display. When '1' is on the format is intel hex.

The layout of the "memory dump" format information is:

ADDR: DD DD DD DD DD DD DD DD DD DD DD DD DD DD DD DDCRLF
ADDR: DD DD DD DD DD DD DD DD DD DD DD DD DD DD DD DDCRLF

The transfer end is given with the characters "=CS", or with the EOF character.

Where ADDR is 4 ASCII characters, representing an address.
DD is two characters that represent information.
CR is the CARRIAGE RETURN character.
LP is the LINE PEED character.
CS is the sum of all hexadecimal characters and EOF is a CNTL/2 character.

This device is compatible with the CP/M operating system.

----------------------------------------------------------------------------------------------------------------

 

[SiriusHardware]

The 'Hex Dump' variant is the one provided for humans to read as it presents the code as a nice table with the line start addresses at the start of each line, and also shows the checksum of the whole file at the bottom of the listing.

Intel Hex format, although it is also text, is a bit harder for humans to read because it contains extra extra items of information per line, namely the record type, the number of data bytes in the line and a checksum byte. This is the format which the programmer itself will 'prefer' for file uploads and downloads.

 

[Bruce Tomlin]

I did wonder whether the data lines have been scrambled

More probably the address lines were scrambled. So many 4th bytes being FF just seems really suspicious. It might be just a simple scrambling where the address lines are connected to the "wrong" pins that could be beeped out with a DVM.

 

[SiriusHardware]

I think both are scrambled. If only the address lines were scrambled the code area would still contain values frequently found in Z80 code such as 3E (load A with immediate value) and C3 (Jump nnnn) and CD (Call nnnn) and C9 (Return) but there is a suspicious absence of these values.

As has been said, not hard to verify, just have to meter out the address and data lines between the Eprom and CPU to see what is connected to what.

However all this may be academic now as the main reason for needing to read the code was to work out the serial command set if any. Since Muttley has now kindly been given a manual, this is no longer worth pursuing except for the sake of curiosity, perhaps.

 

[Muttley Black]

Hello all!

Here is what we need to connect eprom programmer with PC. As i told you earlier, i am waiting the parts to come!

I upload it as pdf because is easiest to keep the text format.

 

[SiriusHardware]

That's interesting - the cable itself will be simple enough to make but notice that the pins on 5-pin DIN plugs are strangely numbered, 1-4-2-5-3 running clockwise.

The other thing made clear by that document is that the programmer expects the host to use 'Hardware handshaking' when communicating with it, so in Teraterm, as well as setting the correct baud rate, number of bits, number of stop bits and parity (none) you will also need to set the handshaking type to 'Hardware' and if there is a further choice beyond that, choose 'RTS/CTS' handshaking.

Also the pins numbers for the RS232 connection at the host end are for a 25-way COM port connector whereas USB to Serial COM port cables tend to have a 9-way connection so you will need to translate the pin numbers for a 25-way RS232 plug to the corresponding ones for a 9-way RS232 plug.