• Please review our updated Terms and Rules here

Lanier Model 103 "No Problem" word processor

Had a rainy-afternoon minute so adjusted the screen on the AES to be central and about the correct width (as per burn-in on the screen!).
moved a couple of the 8216 chips from ram to bus sides and switched on. Got a constant tone which is good. Stuffed a disc in the drive and it brought on the UPPER DRIVE light, the beep stopped and it filled the screen with a repeating pattern of .5.5.5.5.5.5.5.
So yes, from what I can see, starting point again here is the buffer chips. I need to put a switch in to make the screen blanking line bypass and normal, too.

Phil
 
Last edited:
New buffers just arrived in the mail, from GlitchWorks ( glitch ).
Thank you. Just about to put them in and see what (if any) difference I get!

Phil
 
Completely different behavior now.

Now I get a screen of ;I;I;I with the occasional 9 popping in and being cleared.

No beep

Novel...
 
I changed the video ram (300ns 4116 series) and though the uninitialized junk on the screen is different, once it wakes up the same i;i;i;i; pattern appears.
Haven't had the "matrix 9's" again as in that video though.

I also appear to have broken the chip that controls drive enable on the top controller. The light is constantly on.

I'm staying to think quite a lot of the chips on the board might have taken a dislike to the way the power supply failed... The +5 may well have spiked to as much as+27 before the crowbar dumped the current and popped the fuse.
 
The other thing that comes to mind, looking at how random the behavior is- is this machine suffered a lightning strike and was shelved as a result.
 
Well, fun times ahead, I think.

I had a little time today so I removed a few chips from the board.

DM81LS95N - tristate octal buffer.
Truth table should be:
Enable1. Enable2. Input. Output.
H. X. X. Hi-Z
X. H. X. Hi-Z
L. L. H. H
L. L. L. L

​​​​​​Tested, the table is:
H. X. X. H
X. H. X. H
L. L. H. L
L. L. L. L

so that's no good, everything through it will be zeroes.

The others are D-type flip flops, which should have Q match D on a rising Clock edge.
​​​​​​With clock high, Q is !D. Clock low, Q drops. Rising clock edge does not trigger Q to follow D.

One of the chips had blown out underneath so I think this board saw a significant voltage surge.

I'm going to pull the logic off, and socket everything after testing it.

​​​​
​​​​Phil
 
Aha.
Clock speed was too low while testing. I hooked up to my Arduino and wrote a quick sketch to roll through the truth table. Watched the output on my analyzer.
This way appears to be the way forward in terms of making sure the logic individually is good; it also settles my disdain for older computers with soldered IC's. I'll deal with contacts if it means I can easily pull a chip.

Gonna order up a bunch of DIP sockets and go from there.

On a good note, someone very helpfully dumped the contents of their boot PROM and dropped it into Z80 assembler decoder, whereby it returned some fairly sane looking commands, so I have no idea what I did originally.

There's a possibility the floppy drive maps to &8000

Interesting restart.

Phil
 
Last edited:
I now have means to duplicate the discs for this machine.
A hole punch has been fabricated to create hard sector discs from single-hole soft-sector floppies.

Means that I can write a few "burner" discs that if the machine hiccups and writes trash to the disc, all that I have is not lost.

Chip sockets should be here today, I am going ro start working on socketing all the logic. (Makes remedial work easier).

Phil
 
The other 8216 chips I ordered July 9th arrived today ...

​​​​​ Express mail! (From Indiana)
 
Last edited:
Click image for larger version Name: 20210727_212104.jpg Views: 0 Size: 97.8 KB ID: 1218534
Working on checking the logic chips individually. Slow work, but pulling them off, testing them then soldering a socket back on is quite therapeutic.

it also does mean I can get a photo of the traces that run under the chips and build that up so I can more easily create a schematic of the board...

Phil
 
Last edited:
View attachment BOOT DISC ASSEMBLER MNEMONICS.txt

Started on annotating the boot prom code, trying to figure out what it's doing.

I can only make educated guesses right now on what device address is what, but I'm pretty sure 05 is the floppy drive data read-in.
The cards lack a full drive controller, with only a UART to interface with, so it appears that the cpu is directly controlling the floppy drive and all peripheral parts.

I have seen that a bcd chip on the io board is physically cracked- that leads to the UART so that may be causing the random data events.

I'll pull it and test.

Phil
 
Using a USART chip for an early FDC would not be uncommon. I'll have to go back to my notes on an early 8" AES disk to look at the encoding, but I do recall that the bitstream was USART order, not traditional FDC order. Using asynch I/O would seem to be a horrible waste of resources, however.
 
Chuck(G) said:
Using a USART chip for an early FDC would not be uncommon. I'll have to go back to my notes on an early 8" AES disk to look at the encoding, but I do recall that the bitstream was USART order, not traditional FDC order. Using asynch I/O would seem to be a horrible waste of resources, however.
Click to expand...

Per the guy who worked out the format:

"AES 5.25" diskettes are hard sectored, FM coded and have a data length of 151 bytes per sector. There is only an 8 bit checksum per sector, not a CRC. The databits in a byte are stored in reverse order on the disk."
 
The 8" disks were hard-sectored and MMFM encoded. Here's a sector sample from one showing the preamble:

Code: 
0000e050  00 00 00 00 00 00 40 55  55 55 55 55 03 19 1c fc  |......@UUUUU....|
0000e060  61 20 66 69 78 65 64 20  70 65 72 63 65 6e 74 61  |a fixed percenta|
0000e070  67 65 20 6f 66 20 61 20  e1 fe 00 fd 00 ed 09 e9  |ge of a ........|
0000e080  67 69 76 65 6e 20 73 65  72 69 65 73 20 6f 66 20  |given series of |
0000e090  63 6f 6e 74 72 61 63 74  73 2c 20 73 75 63 68 20  |contracts, such |
0000e0a0  61 73 20 31 30 25 20 6f  6e 20 63 75 6c 76 65 72  |as 10% on culver|
0000e0b0  74 20 70 69 70 65 2c 20  31 32 25 20 6f 6e 20 e1  |t pipe, 12% on .|
0000e0c0  fe 00 fd 00 ed 09 e9 67  72 61 76 65 6c 20 6f 72  |.......gravel or|
0000e0d0  20 31 35 25 20 6f 6e 20  65 71 75 69 70 6d 65 6e  | 15% on equipmen|
0000e0e0  74 20 72 65 70 61 69 72  73 2e 20 20 49 6e 20 6f  |t repairs.  In o|
0000e0f0  74 68 65 72 20 63 61 73  65 73 20 74 68 65 20 22  |ther cases the "|
0000e100  74 68 69 6e 67 20 6f 66  20 e1 fe 00 fd 00 ed 09  |thing of .......|
0000e110  e9 76 61 6c 75 65 22 20  67 69 76 65 6e 20 65 61  |.value" given ea|
0000e120  63 68 20 77 65 65 6b 20  6f 72 20 6d 6f 6e 74 68  |ch week or month|
0000e130  20 69 73 20 6e 6f 74 20  63 61 73 68 20 62 75 74  | is not cash but|
0000e140  20 70 72 6f 70 65 72 74  79 2c 20 73 75 63 68 20  | property, such |
0000e150  61 73 20 e1 fe 00 fd 00  ed 09 e9 74 92 71 aa aa  |as ........t.q..|

So not like that 5.25" version.
 
Well, thinking back to what you said- about having the cpu directly control the floppy being a large waste of resources.
Looking at the intended use of this machine I would say no. It did not need to be optimized for anything other than snappy keyboard-to-screen response. Drive access could halt the entire machine of necessary without causing the user any distress.
It just had to be able to type to screen, send to disk, send to printer and send to modem (where fitted) as independent operations. Nothing else needed to be particularly streamlined.

Phil
 
Last edited:
PhilipA said:
Well, thinking back to what you said- about having the cpu directly control the floppy being a large waste of resources.
Looking at the intended use of this machine I would say no. It did not need to be optimized for anything other than snappy keyboard-to-screen response. Drive access could halt the entire machine of necessary without causing the user any distress.
It just had to be able to type to screen, send to disk, send to printer and send to modem (where fitted) as independent operations. Nothing else needed to be particularly streamlined.
Click to expand...

Keyboard-to-screen can place demands on the CPU during entry, particularly during on-screen formatting. Word wrap, justification and hyphenation isn't a trivial task on a whole page of text.

I suppose that's no different from the early CPT wapros--basically shoot a page of text to an editing terminal and then wait for it to be shot back. Documents were indexed by pages.
 
Chuck(G) said:
Keyboard-to-screen can place demands on the CPU during entry, particularly during on-screen formatting. Word wrap, justification and hyphenation isn't a trivial task on a whole page of text.

I suppose that's no different from the early CPT wapros--basically shoot a page of text to an editing terminal and then wait for it to be shot back. Documents were indexed by pages.
Click to expand...

True, but if that's all is doing at the time- you can afford to have sub-optimal drive access. There's no screen handling required other than prompts at that time, which are minimal in terms of cycles consumed.

Phrases such as "good enough for purpose" come to mind.

As a general purpose computer I would agree, there are better ways of doing it. But, it was designed with one task in mind- word processing (and later, spreadsheets, database work).

Phil
 
Last edited:
You must log in or register to reply here.
Back
Top