• Please review our updated Terms and Rules here

Lanier Model 103 "No Problem" word processor

I've taken a new photo and sent it for evaluation.

I also had a thought this morning. I've never powered this thing up with the printer attached. I wonder if there's a possibility it hangs if it doesn't get a response from the thing? I'll have to bring my Variac in and power it up gently, it's never been powered up in the time I've had it, just sat on the side awaiting later attentions.

A thought on gathering data off the bus- I'll have to come up with something that requires data to be brought off the Arduino onto something else- it has a bottleneck of 115200 baud max on the UART and basically no onboard memory. It can be used to push data "away" from the PC rapidly, as code can be loaded onto it and executed. A different method to extract ~1Mhz signaling from the CPU will be required.

Also, looking at it, the 50-ish ns timing requirements for DRAM is a bit outside the system capability of the Arduino, the most granular it can time to is 1ms, and that can be a bit unreliable whilst the rest of the code is going on.

The direction forward might just be writing code for the thing to boot from and run its own testing.

Found a supply of 20-pin turned-pin DIL sockets which are excellent to make pseudo-chips from. It's tempting to fit the PROM location with a ZIF socket. There's enough space on the board.


--Phil
 
Last edited:
A thought on gathering data off the bus- I'll have to come up with something that requires data to be brought off the Arduino onto something else- it has a bottleneck of 115200 baud max on the UART and basically no onboard memory. It can be used to push data "away" from the PC rapidly, as code can be loaded onto it and executed. A different method to extract ~1Mhz signaling from the CPU will be required.

Also, looking at it, the 50-ish ns timing requirements for DRAM is a bit outside the system capability of the Arduino, the most granular it can time to is 1ms, and that can be a bit unreliable whilst the rest of the code is going on.

I have pushed the Arduino to a baud rate of 2M baud without issue. That was on an Uno if I recall. Also, you can get much more accurate timing if you stray away from the built in Arduino functions and work more in native C. Also, be sure to disable interrupts if doing anything special timing wise.

Kyle
 
I thought the maximum data rate on it was 1.5Mbps if you leave the functions out of it?

I'm not very good at working with the code in that respect, I'll admit. I'm still learning the thing really (I have an Uno) and have only really been using the regular libraries.

--Phil
 
Figured what the hey

Brought the Variac in, hooked up the printer and powered it up gently

It then kindly proceeded to run away, went dead short and blew out the +5v rail on the PSU.


Now I gotta find the last remaining chopper transistor.. I think I have it somewheres.

--Phil
 
Pulled the printer to bits. Found the culprits for the smoke- a resistor (might be an inductor, not sure) and a couple caps.

20150514_102459.jpg

Printer got a clean-out and is going back together once I can figure out where the loose nut that was rattling about int he back is supposed to go.

It'll be on the "DO NOT PLUG" list for a while yet. Need to order some more chopper transistors before I can continue.

--Phil
 
Last edited:
Thankfully, I have found the last remaining chopper transistor.

I shall fit it this weekend. I have brought the thing home so I can work on it more easily.

I shall also be fitting fuses to the +5V feeds.

Phil
 
That is a good idea. I will be able to see if the boards are still working after the printer shenanigans.

The wife was nonplussed again at the introduction of another piece of, er, vintage equipment being introduced to the kitchen table...

I have a couple 20 pin dil sockets coming in the mail, the type that have the turned pins. They plug into sockets nicely.

Going to see also about getting the eeprom memory and build it up on a small board in order to create a custom boot prom.

Phil
 
I do like that a lot. Neat trick, hadn't thought that hooking it in and paging it with addresses available at pins.

Unfortunately I don't have anything "laying around", as my old bench was in the UK and very little of it made it with me to the USA. I'll have to pick up some logic, but I'm going to have to order the EEPROM so I'll get them at the same time, grab a ZIF for the board and probably the EEPROM

I had the power supply in bits again this morning. Got the 5V rail operational again.
20150516_102134.jpg

Which means, repopulated (I had to strip the chassis down in order to be able to get it light enough to carry) the thing is back to the same old tricks. Raster.. pause..beep.

20150516_103619.jpg

Buttoned it back up for now. I'll have to see about ordering the rest of the bits next week. Leave those schematics up if you don't mind and I'll set about building a rig. I think the plan you have is good. Keep the new EEPROM, most of the original boot code, paged out for greater capability

--Phil
 
Last edited:
PhilipA said:
...I do like that a lot. Neat trick, hadn't thought that hooking it in and paging it with addresses available at pins.

Unfortunately I don't have anything "laying around", as my old bench was in the UK and very little of it made it with me to the USA. I'll have to pick up some logic, but I'm going to have to order the EEPROM so I'll get them at the same time, grab a ZIF for the board and probably the EEPROM...

Give me a week to see if I can simplify it further. Is there clearance when the CPU card is inserted in its slot for a daughter card to stand atop the CPU Card prom socket?

Funny thing is that last year I was in a discussion about how CP/M should have been shadow-rom'd into a smaller address space and use exactly the idea of switching pages to put 24KBytes of CP/M 2.2 into a small 4KByte top of 64KByte memory map. This 8KByte EEprom in a 512byte Prom rang those similarities loudly. So I'll be thinking along several paths for what can be done with this system at least until someone disk-images a Lanier floppy that you can use.

Another floppy-free way to load CP/M would be to put a Shadow Static Ram in an unused location in the 8080s 64KByte address space. With RD/WR access, it could have a Nor Flash Rom in the same address space so that it could fetch CP/M into Dram memory by paging the Flash Rom and copying it into Dram. All sorts of ways to do that. The Flash Rom could even be used to store the files and programs for the system, making it less reliant upon floppies.
 
Last edited:
Thankfully yes. The cpu card is the furthest to the left,leaving component-side access of several inches deep and the full height and length of the cpu card available.

I shall hold off for now, however a ZIF socket for the boot prom is in order, regardless.

Phil
 
Shadow Rom Banking the 8KByte EEprom as a 512Byte Prom:

I've updated this message is the improved use of JP (HL) as the single byte opcode to use in the EEprom Page change block.

Below is a schematic for a small Lanier 103 CPU Card 20pin Prom socket to 8KByte EEprom plug-in. It uses a two-stage capture off the address bus to supply sixteen page addresses for the 8KB EEporm, residing in the 512B address page of the original prom. A single stage might suffice but as we don't have a schematic, this two-stage design works safely.

The concept is that the rig detects access to the highest 16 bytes of the 512byte prom address space. When A4-A8 are all high, and CS# is active low, the program counter has addressed that range of 16 bytes. The *trick* is to capture the low address lines A0-A3 (nibble) and latch them in as the page select A9-A12 on the EEprom. Thus the selection of 1 or those 16 bytes in high prom space, will set the page address to the EEprom when that cycle is over.

For example, access to address 01Fx will the the page of the EEProm to the nibble value x. Thus 01F0h selects page 0 or 15, 01FCh selects page 12 of 15, and 01FFh selects page 15 of 15. The trick is to not switch the page until that access is completed, thus when CS# and A4-A8 all being high, deasserts, that's when the EEprom page is updated. As it needs A4-A8 as they're disappearing, the two stage latch is used to temporarily hold A4-A8 anytime CS# goes active on the prom, holding it in the first stage. That value is never used unless the current access is to the high 16 bytes of the prom, which triggers a LOW signal to the second stage latch, that clocks in the address saved on the first stage latch as CS# and A4-A8 deassert at the end of the access cycle. That updates the EEProm page.

That's the hardware side.

On the firmware side the access to the 16 byte page select range, needs to have a single byte instruction that changes the program counter out of the range afterwards. Previously I discussed RST N and RET instructions and how they'd be used. As both require a dummy stack operation, I've realized that using a JP (HL) instruction is more advantageous. Its single byte, Z80 and 8080 instruction, and it allows a jump to any address in another page, as the code example below will illustrate. If the current page is loaded into a register other than HL, a call can be made to a routine in another page, and it can use the register to find its way back. I'll add a code example to illustrate that too.
Code:
;every 512byte page would have this at the top 24 bytes FROM 01E8h-01FFh:
		ORG		01E8h
		;E holds previous page as F0-FF value
01E8H	1601	PAGRET:	LD	D,01h		;high page select address 01Fxh for accessed by dummy return
01EAH	D5		PUSH	DE		;setup return address on stack prior to RET goes to PAGEx
01EBH	21EE01		LD	HL,RETURN	;routine to execute in the destination page
01EEH	C9	RETURN:	RET			;enters PAGEx via the return address on the stack
01EFh	F0	PAGE:	DB	0F0h		;address of current selected page of EEProm
01F0h	E9	PAGE00:	JP	(HL)		;select page 0 of 15 and execute code at (HL)
01F1h	E9	PAGE01:	JP	(HL)		;select page 1 of 15 and execute code at (HL)
01F2h	E9	PAGE02:	JP	(HL)		;select page 2 of 15 and execute code at (HL)
01F3h	E9	PAGE03:	JP	(HL)		;select page 3 of 15 and execute code at (HL)
01F4h	E9	PAGE04:	JP	(HL)		;select page 4 of 15 and execute code at (HL)
01F5h	E9	PAGE05:	JP	(HL)		;select page 5 of 15 and execute code at (HL)
01F6h	E9	PAGE06:	JP	(HL)		;select page 6 of 15 and execute code at (HL)
01F7h	E9	PAGE07:	JP	(HL)		;select page 7 of 15 and execute code at (HL)
01F8h	E9	PAGE08:	JP	(HL)		;select page 8 of 15 and execute code at (HL)
01F9h	E9	PAGE09:	JP	(HL)		;select page 9 of 15 and execute code at (HL)
01FAh	E9	PAGE10:	JP	(HL)		;select page 10 of 15 and execute code at (HL)
01FBh	E9	PAGE11:	JP	(HL)		;select page 11 of 15 and execute code at (HL)
01FCh	E9	PAGE12:	JP	(HL)		;select page 12 of 15 and execute code at (HL)
01FDh	E9	PAGE13:	JP	(HL)		;select page 13 of 15 and execute code at (HL)
01FEh	E9	PAGE14:	JP	(HL)		;select page 14 of 15 and execute code at (HL)
01FFh	E9	PAGE15:	JP	(HL)		;select page 15 of 15 and execute code at (HL)

Example: In EEprom page 4 it needs to jump to address 0B8h in page 12.
Code:
P04:		218000		LD	HL,GETCHR	;load the address of function on another page in HL
P04:		C3FC01		JP	PAGE12		;go to 01FCh to execute JP (HL) and switch to page 12
P04:	01FCh	E9	PAGE12:	JP	(HL)		;load the destination address into the program counter
P12:	0018h		GETCHR:				;Page 12 is loaded by hardware as the previous instruction is fetched.
						;execution continues within page 12 and the address of function GETCHR.
To do a call and return, the current page is loaded into a register for the function to utilize:
Code:
P04:		1EF4		LD	E,0F4h		;load return page number
P04:		211800		LD	HL,GETCHR	;load the address of the other page function in HL
P04:		CDFC01		CALL	PAGE12		;go to 01FCh to execute JP (HL) and switch to page 12
P04:	01FCh		PAGE12:	JP	(HL)		;load the destination address into the program counter
P12:	0018h		GETCHR:				;Page 12 is loaded by hardware as the previous instruction is fetched.
P12:	...	C3E801h		JP	PAGRET		;return to original page in E and return address on stack
P12:	01E8H	1601	PAGRET:	LD	D,01h		;high page select address 01Fxh for accessed by dummy return
P12:	01EAH	D5		PUSH	DE		;setup return address on stack prior to RET goes to PAGEx
P12:	01EBH	21EE01		LD	HL,RETURN	;routine to execute in the destination page
P12:	01EEH	C9	RETURN:	RET			;enters PAGEx via the return address on the stack
P12:	01F4h		PAGE04:	JP	(HL)		;load the destination address into the program counter
P04:	01EEH	C9	RETURN:	RET			;enters PAGEx via the return address on the stack
P04:	(original return address)

Here's the schematic updates:
(1) Lanier CPU prom adapter2.jpg
(2) Lanier Arduino EEprom Burner2.jpg
(3) Lanier Arduino Dram Tester2.jpg

(1) Shows to two-stage address latch.
(2) Shows the previous updated with I/O counts and bus lines for clarity.
(3) Shows the previous updated with I/O counts and A7 added for 64Kbit Drams too.
 

Attachments

  • Lanier CPU prom adapter2.jpg
    Lanier CPU prom adapter2.jpg
    91.1 KB · Views: 1
  • Lanier Arduino EEprom Burner2.jpg
    Lanier Arduino EEprom Burner2.jpg
    60.6 KB · Views: 1
  • Lanier Arduino Dram Tester2.jpg
    Lanier Arduino Dram Tester2.jpg
    42.3 KB · Views: 1
Last edited:
First of the new bits arrived in yesterday.

20150527_223344.jpg

Going to mount flying leads into the pin holes and use it as a plug to connect to the boot PROM socket on the CPU board, nice thin (turned) pins.

--Phil
 
Last edited:
I took a look at the two circuits, (1) The Arduino remote EEprom programmer and (2) the In-Circuit paging EEprom.

There are a few chips common to both designs suggesting that it might be worth looking at combining the two into to one board so that you can more quickly reprogram the EEprom while plugged into the Lanier CPU card.

The isolation logic might not make it worth doing, but give me the weekend to look at it and post an small schematic of the combination.

A more interesting alternate would be to have one of the EEprom resident paging-monitor commands, allow it to program itself from a TTL serial-clocked HEX file transmit. More code, less circuit. You'd program the EEprom originally in the Arduino, and when tested ok, you just send a hex file from you arduino and it uses the CPU card's 8080 to program the EEprom. The board would have to include another "trick" to create a WRITE signal for programming and be able to detect the EEprom's BUSY signal to time it right. Using a tiny cable with GND, DAT, CLK (like SPI interface) could make it a lot easy to work with (less chance and accidently yanking the EEProm rig out of the board.

My goal is to use Tricks rather than using signals that are not on the 20pin prom socket. Might be ODD.
 
Last edited:
Okay. I'm game for that, sounds like it could work well.

I was having a thought also on the Arduino and communications therein. It has 4 UARTs onboard and could be used as a base for serial i/o on and off the CPU board. There should be enough digital i/o lines to support hooking it up to the bus- programmed in C it should be fast enough to become an expansion board, useful for building a software-based prototype, at least.

--Phil
 
I started designing a circuit for your Lanier 103 CPU card's 20 pin prom socket. The given rule for this design is that it only uses the limited signals in the prom socket; no jumpers to get extra signals are allowed. Thats { A08-A00, D7-D0, CS#, VCC, GND }.

Its a more advanced version, but its still limited to the 512 byte address block of prom socket. To access additional on-board EEprom or Static Ram memory, it uses either dedicated read and dedicated write addressed registers or a mode select for its paging block of continuous 256 Bytes of static ram. It can also program the EEprom in-system using the 8080 processor running a small program loaded into its ram, while the Arduino or other remote host transfers the program in from a shift register. The 8080 on the Lanier does the shift clocking. It can also be used to transfer data from the Lanier to the Arduino-or-other-remote-host.

And because there is more control logic controlling more operations, it uses a simpler prom paging method than the previous design.
 
Last edited:
You have been having fun with this challenge, it seems.

I look forward to building and troubleshooting it.

Phil
 
Its a fun puzzle... I'd call it the digital engineer's equivalent to building a model ship inside a bottle. ;)
 
Last edited:
Back
Top