Home Page Forums MAME MAME NLQ401 printer

I remembered that the Tandy Pocket Computer PC2 had a mini plotter and was able to actually find an emulator (with 3d no less) that supported it.

http://www.forever1500.fr/


I found a manual with schematics for the PC-2 (which I assume is the same as the sharp PC-1500 and the CE-150) so I'm going to take a swing at it.

edit: Added the rom and the io chip into the memory map and it seems to be moving the x and y steppers but it won't settle down. More investigation needed.


also noticed that the lh5801 disassembler gives odd numbers for the relative branches,

case RelP:
temp=opcodes.r8(pos++);
util::stream_format(stream, "%s %04x", entry->ins_name(),pc+pos+temp);break;
case RelM:
temp=opcodes.r8(pos++);
util::stream_format(stream, "%s %04x", entry->ins_name(),pc+pos-temp);break;


changing that to just pos+temp and pos-temp instead of pc+pos+temp and pc+pos-temp makes it more sane.

The NLQ401 is fairly similar to the MPS-803 but it has some significant differences. I was able to get it to do the self test.

There's a sample in the manual and it looks pretty close:

Ok, got the VIC-1515 doing the self test. This printer uses a motor shaft rotation detection disc like the other seikosha unihammers, however, it has a different structure.

So I looked at my kludgey code to generate the detection disc and wanted something more elegant.

After spinning on it for awhile, why not use cpp macros.

Instead of a bunch of complicated code, this is much easier to modify for a different wheel pattern.






The VIC 1515 also uses a different paper feed mechanism. There's a solenoid that moves a sawtooth along. It fires 3 discrete times for a text line, 2 times for a graphic line.

Got the VIC1515 self test looking right.

I was having problems with stray dots everywhere, finally tracked it to using > instead of >= when checking against the size of array for the rotation detector.





Better "meediately" notify your dealer.

Been really struggling with the MPS-802/1526, finally got it doing something!

Was so close to getting it working for a couple of days but it just wouldn't go.

Then I finally realized that I copied and pasted some code and was referencing the pf stepper instead of the cr stepper in checking for horizontal motion.






and with a little fixing, setting the horizontal dpi to 80 and getting right side up:

The 8023P printer (aka MPP-1361) is similar to the MPS-802, but I can't quite get it working and doing the self test. It has a cylindrical cam with a detector that signals "ready to print".

There's videos on youtube that show the spiral cylinder and the detector (like a semi circular piece).

There is original source code to the printer's rom (for version 1), which is makes it a little easier to figure out.

It also has the same test for the 6522 and 6532 timers as the MPS-802.

tmtest ;test timers
inc f ;advance error count
lda #$ec
sta crclk
lda #$ee
sta pfclk
lda #0
sta crclk+1
sta pfclk+1
lda #$f5
sta ndclkd+8
lda #$fb
sta dmclkd+8
tt10
lda crclk
bne tt10
tt20




(shows off the cylinder and detector at 7:24 mark)


One odd thing is that the printer has 2 x 2114 memory chips which should provide 1K of ram. However, as far as I can tell, it only seems to use the lower 512 bytes of the ram, 3000 up to 31ff.

The source actually has the test for the upper 512 bytes, but it's commented out. I guess they could use ram chips that had a bad upper 512 bytes.

More likely 512b RAMs were difficult to source so they just used what they had in stock. The MPP-1361 manual has a date of 1983 which fits with the time C64's were in production. 2114 is used in C64 as the color RAM. Likely they just grounded the highest address pin A9 to halve the capacity.
I just discovered Seibu did the same thing on the SPI boards with the 32kx8-bit SRAMs connected to the RISE11 chip. The upper 4 address lines are tied high or low making these RAMs effectively 2kB and with 2 chips connected it means the RISE11 has 4kB connected to it, not 64kB.

One of the reasons I've been having so much trouble with the 8023P is that the schematic is wrong.

The HP home position and the RTP (ready to print) timing pulse are swapped. It's also backwards on the MPP-1361 schematic.





;****************************************
;
; 6532-2 printer control
;
*=$280
;
contrl *=*+1 ;printer control
hlevel =$80 ;in: home signal level 1=home
tlevel =$40 ;in: timing pulse level


Now at least, the carriage does its normal initialization sweep from left to right and back to left.

Still can't figure out why it won't get into the self test, but getting closer.

So according to the schematic, there's a hall effect sensor ULN3006-T which will shut off printing if it's activated.

The only thing I could find out about it is this from a sprague databook:

"Intended for use in position sensing and contactless switching applications, the UGN-3201K switch utilizes the Hall Effect for detecting a magnetic field.
It is supplied in a four-pin single in-line plastic package. The switch was originally introduced as ULN-3006."



The MPP-1361 schematic doesn't have this sensor at all.





So now it'll go into the self test and start printing.




But sometimes after the second line the carriage just keeps going to the left.

You can see how I've reset it a few times.



edit:

I think it has something to do with the bidirectional printing moving left and hitting the home sensor while it's still printing a character.

If you look at the printouts that fail, it clips the leftmost dots on the return sweep.

The print head must slip a little while it's changing direction, which we don't model.

After adding a fudge factor on the home sensor when we're moving leftward, it seems to work consistently every time (so far).

(the red line is the RTP sensor, and the blue line is the home sensor)

Interesting to compare the self test of the 8023 in the manual:





Looking at the schematic for the 4022 ieee printer, it looks much like the MPS-802 iec printer.

Just plugging in the rom into the MPS-802 driver it will do the self test: