Hello everyone. I'm excited to be here! Happy this place exists!

Primary goal is just to mess around and have fun with this stuff. I'm reversing a Star Micronics NX-1020 printer with some hopes to extract fonts directly from the ROMs. The printer uses a MELPS 740 M50734SP-10. As you probably know, the 740 series is a superset of NMOS 6502. I've got a lot of things going for me. There are schematics for the printer, and I've got a couple working printers that I can probe. I've got equipment -- scopes and logic analyzers.

This system has AM27C256 (32K ROM) attached and mapped to 0x8000. It also has a 128K 27C1001 ROM. I've got them dumped. An intriguing fact is that the 32K ROM is ALSO contained entirely within the 128K ROM. File offsets from 0x8000-0xFFFF contain version 3.0, the AM27C contains version 3.2. 3.2 is running on the printer. I've tried booting without the 128K ROM, and it does not boot.

Addresses A0-A14 on the AM27C256 tone out to the same pins on the 27C1001.
Logic would say that the larger ROM contains the fonts, and the smaller one the code. But as a start, I really like the small (relatively) confined search space of the 32K.

I've downloaded Mike's m740dasm (which doesn't have direct support for this CPU), and using the 7450 CPU setting (just trying random choices, but most of them produce the same output) disassembled the AM27C256, I'm getting what I think are spectacular results.. but it would helpful if someone looked to say, "yeah, looks encouraging" or not. I have just enough experience with assembly, multiple processors, architecture, to have a clue. I don't think I've ever seen this many intact complete code blocks. Not just random "unknown" bytes in the middle of routines... RESET vector at the end of the file is 0x8130, and I see this at that location, which appears to be a bunch of clears, encouraging indeed.

I've got schematics, 740 processor manual, ROM images, and the disassembly here. No account required.

https://www.dropbox.com/scl/fo/ewsr8sqf92sfe5k34chv8/h?rlkey=lbz1jindm3qb1n0sx37wseliz&dl=0

I've got a logic analyzer hooked up to the address bus and data bus, including the chip selects/output enable pins for the ROMs. Printer takes 1450ms from on-switch to stopping of initial carriage movement. I should be able to capture that entire sequence. I've got the data loading into python with pandas, so I can analyze it, process it, etc. It would be nice if I could identify repeated code blocks to help abstract the thousands of lines of assembly. Due to physical space restrictions, I can't probe the CPU.

My plan so far has been to understand the boot up sequence to wrap my head around how all this functions. Then I'll capture a test print which by necessity needs to access the font information to drive the print head. By monitoring the ROM accesses, I should be able to identify specific non-code sections of the ROM, which should allow me to focus reverse engineering efforts to that particular section.

This dual ROM thing is complicating things.

I'm still absorbing information, searching the forum (found the gentleman from 8 months ago posting investigating a very similar printer!), and so on. Sponge mode.

Any suggestions, general advice, observations about my specific files would be appreciated!

Welcome! That does indeed look exactly like a reset initialisation sequence, so you're on the right track.

Can't quite think what the dual ROM idea is. In some sense the small ROM is a field upgrade, perhaps.

Photos of the board and looking at any jumpers or test points might be interesting.

Thanks, see the attached PCB photo.

The schematics and silkscreen for the board is visible starting around page 90 on the PDF, which is attached and linked in Dropbox.

Theory of operation for the whole unit is included that attached PDF, but I haven't torn it apart yet. The print head is driven off of writes to the databus, looking at address bits A0 and A1, the WR signal. And Port P0/bit-4 HDEN signal, which I'm not sure I can probe yet. PDF Page 20 shows the print head circuit.

If I can see what code drives that port, I could then look to see where that data came from.

EDIT: And, page 102 describes the function of two slides switches. These are set to 256 and EP.

Which...... if I'm not mistaken..... the "Special Function Register" from the datasheet for this particular CPU, Port P0 uses uses three single byte registers to control the port.

The register mapping seems to change based on the exact CPU. For the 7450 decoding I chose, here's the mapping for F5, F6, F7:


which then tells me that if I find CLB instructions for clearing, and SEB instructions for setting that manipulate that specific bit on the port, I should be in business.

From the 32K disassembly, I see

From the print driving image, looks like the pulse is a low going pulse. So Port P0, bit 4, has to go low for 327us-387us. It gets inverted before going into the timer.

hrmmmm.

Ah yes, thanks for all those docs. I see now that the EP/MASK switch controls whether the smaller EPROM overlays the large mask ROM, or is disabled. So with that switch you should see that you can run either 3.0 or 3.2 of the firmware.

I see also there's a printing sequence which can print a hex dump of the small settings EEPROM - might be worthwhile to do that, if you haven't already. Although if the printer is broken you can't! But that EEPROM contains per-printer fine alignment so ideally you would have a dump. Interestingly it also contains a small area of patch code - or something, decribed as two times 28 bytes of autostart code.