MDS-II Model 230 at the Rhode Island Computer Museum

[Michael Thompson]

We received another donation last week, an MDS-II Model 230. It has the 8080 based IPB, an additional 32k RAM, double-density floppy, and an iSBC 310 High-Speed Mathematics Unit installed. We will have to remove the iSBC 310 to install the ICe-85 boards. It also came with a dot matrix printer that we have not documented yet. The peripheral cables got misplaced between the original owner and the museum. Hopefully we won't have to make new ones.

Details are here: https://www.ricomputermuseum.org/collections-gallery/small-systems-at-ricm/intel-mds-ii-model-230-development-system

The IOC diagnostics run OK. We get a Monitor V1.2 prompt at power up. The CRT needs some adjusting after a very long sleep. We have not powered on the diskette chassis, so that is the next project.

When powered up the interrupt 0, 1, and 2 LEDs are on. If we fiddle with the interrupt switches we can sometimes get the interrupt 7 LED to go on. What is the normal behavior for these LEDs?

It came with an ICE-85. The two ribbon cables to the controller board are connected, but the ribbon cable to the trace board is not connected. Which connector on the trace board does it connect to? Does it make a difference where the controller and trace boards are installed in the card cage?

We would like to use this system connected to an MCS-85, so that should be an adventure.

[Herb Johnson]

On 10/10/2021 3:45 PM, Michael Thompson wrote:
> We received another donation last week, an MDS-II Model 230. It has the
> 8080 based IPB, an additional 32k RAM, double-density floppy, and an
> iSBC 310 High-Speed Mathematics Unit installed. We will have to remove
> the iSBC 310 to install the ICe-85 boards.

I don't know if the microcode on the '310 board is documented, or at
least recovered as binary. Can anyone assist or inform the RICM about
reading the ROMS on it? They won't be accessible from the Multibus, they
are run entirely on the 310's 3002 processor/slices. (I can't quite make
out the ROM models and Intel part numbers. I'm not sure the iSBC 310
manual is readily available.)

Regards Herb Johnson
float-curious

--
Herbert R. Johnson, New Jersey in the USA
http://www.retrotechnology.com OR .net
preserve, recover, restore 1970's computing
email: hjohnson AT retrotechnology DOT com
or try later herbjohnson AT comcast DOT net

[Jon Hales]

There's a 4-page description of the iSBC 310 in the 1981 Intel Systems Data Catalog (pages 1-59-1-62). This states that the reference manual is 9800410A. The photo of the board is not legible to identify the type of ROMs. The iSBC 310 is also in the 1982 Data Catalog, which has a clearer photo at page 2-83.

9800410A is not one of the PDF manuals in Mark Ogden's collection. It is listed on Bill's NJ7P website, but is not a document Bill offers for download.

It's possible that businesses supporting collectors of arcade machines might extract the code. 

Best regards

Jon

--
You received this message because you are subscribed to the Google Groups "intel-devsys" group.
To unsubscribe from this group and stop receiving emails from it, send an email to intel-devsys...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/intel-devsys/f558f371-08c9-4123-d90d-9d9a31d539ec%40retrotechnology.com.

[Roger Arrick]

Very good idea to capture these ROMS.
Possibly the same type as on the Disk controller boards.
I dont remember seeing this board documented anywhere.
It was probably a low volume product.

_______________________________________________
Roger Arrick
Ro...@Arrick.com
Tyler, TX

[Herb Johnson]

Regarding the iSBC 310:

Jon, thanks for the report. I'm wasn't sure why you mentioned "arcade
collectors", until I searched further on the ROMs in question.

I'm interested in old-school floating point hardware and software. And
in Multibus, and 8080's. So I'm interested in the 310 card. Pretty
simple. Here's the bit of remote engineering I can do.

A card PWA 1001107-01A sold on eBay in 2020, had these eight Intel 3604
ROMS: 52-763 0218, 52-764 0219, 52-765 0220, 52-766 0221; 52-759 0214,
52-760 0215, 52-761 0216, 52-762 0217. Date codes on chips suggest it
was built in early 1977. These cards don't appear to be highly priced on
eBay; they've appeared a few times a year that I could spot.

The image of the board from RICM's Web page, apparently resolves at 72
DPI, a 1080 X 800 pixel image. That's not sufficient resolution to
easily read off some of the individual IC's. Pardon my judgement but
that limits the ability to reverse engineer a board of that size. Maybe
the original photo has more resolution.

In any event, my photo analysis suggests the RICM-owned board PWA
1001107-04 F GE has eight Intel D3604A ROMS, numbered 142747-001 through
142747-008. IC date codes suggest a very early 1980 construction date.
So apparently Intel provided these boards for at least three years and
four revisions.

The 3604 is an early ROM from Intel. Some Intel boards use it as an
address decoder because it's a fast mask-programmed ROM, 512 X 8. In Web
search I found the arcade references I and Jon previously mentioned.
Also this reference:

http://www.retrotechnology.com/restore/mon80_proms.html

look for "about the 3604 PROM..." I actually tried to wire up a stack of
24-pin sockets to create a cross-wired socket to look like a 2732A (a
convenient 5-volt only PROM). But I wasn't confident of the result as I
did not decode the address-logic the ROM provided. I provide notes on my
efforts.

Let's get to the bottom line, if anyone is interested in reading these
ROMs. If the RICM owners have a compatible PROM reader, (shrug) then
please dump the ROMS and report the data. It's only 4K of code.

The most plausible way to read these without such a reader would be,

1) to wire up an adapter to make it look like a reader-supported PROM,
say a 2732; possibly add pullups or pulldowns. See if resistors are used
on the 310 board.

2) reverse engineer the iSBC 310's data and address lines to confirm the
likely pin-order of address inputs and data outputs. They could be
scrambled, if not it won't take long.

3) dump a ROM

4) look at the dump versus some clue about the bit-slices to say "yeah,
that looks orderly enough". Correct the adapter or methods if necessary.

5) dump all the ROMS

If one is indifferent, just dump them any way you can.

Why bother?

There's a general history among Multibus owners, of interest in
recovering ROMs and other programmable device content, if only to
archive such information. Some Multibus owners work to reverse-engineer
further and disassemble code. And as mentioned, some supporters of
emulators work to reverse engineer *anything* on principle or on
specific interest. The MAME MESS emulator seems to grow by accretion
when someone with a particular interest chooses to add one more device
to emulation. I'm aware that Bill Beech has worked on this emulator.

Here's my tedious adventure with MAME today:

Web search for "mess mame intel multibus" seems the only way to ask the
question "does MAME support some particular Intel Multibus card?".
Tedious search finds a reference to MESSinfo 0.218 from Feb 2020 which
says among other things: "Added .... Intel i3001 MCU, Intel i3002 CPE,
Intel Multibus slot, iSBC-202 floppy controller ..." [F.Ulivi] is
mentioned for the floppy controller.

Lacking any other means to ask the simple "is this supported" question,
a download of MAME 0.236's apparent documentation was inspected. It's a
259 megabyte XML file!!! it *crashed* my Firefox browser tab!!! That's
the end of my adventure with MAME.

regards, Herb Johnson

On 10/11/2021 7:00 AM, Jon Hales wrote:
> There's a 4-page description of the iSBC 310 in the 1981 Intel Systems
> Data Catalog (pages 1-59-1-62). This states that the reference manual is
> 9800410A. The photo of the board is not legible to identify the type of
> ROMs. The iSBC 310 is also in the 1982 Data Catalog, which has a clearer
> photo at page 2-83.
>
> 9800410A is not one of the PDF manuals in Mark Ogden's collection. It is
> listed on Bill's NJ7P website, but is not a document Bill offers for
> download.
>
> It's possible that businesses supporting collectors of arcade machines
> might extract the code.
>
> Best regards
>
> Jon
>

> On Mon, 11 Oct 2021 at 02:47, Herb Johnson wrote:
>
> On 10/10/2021 3:45 PM, Michael Thompson wrote:
> > We received another donation last week, an MDS-II Model 230. It
> has the
> > 8080 based IPB, an additional 32k RAM, double-density floppy, and an
> > iSBC 310 High-Speed Mathematics Unit installed. We will have to
> remove
> > the iSBC 310 to install the ICe-85 boards.

[Michael Thompson]

I emailed Herb a 2928 x 1851 resolution image of the 310 board.

[Herb Johnson]

On 10/11/2021 2:27 PM, Michael Thompson wrote:
> I emailed Herb a 2928 x 1851 resolution image of the 310 board.

Thank you. - Herb

[Al Kossow]

> Lacking any other means to ask the simple "is this supported" question,

https://forums.bannister.org/ubbthreads.php?ubb=postlist&Board=1&page=1

[F.Ulivi]

Yes, I can confirm that iSBC202 is supported in MAME as I wrote the
low-level emulation some time ago.
By low-level emulation I mean that the various components of the
3000-series bit-slice processor are emulated and they run the actual
firmware from dumped PROMs (I think I got the images from Eric Smith).
If you somehow manage to dump PROMs on this other board and if you have
some kind of schematics, I volunteer to write the MAME emulation.
Cheers,
--F.Ulivi

[Herb Johnson]

still posting about the iSBC 310 math board.

Thanks, Al. While that is an open forum, one must be registered to post
a question. And up-front, the forum states that registrations are
manually processed and are only done every few weeks. That's longer than
I care to wait; I can find my go/nogo answer with persistent effort sooner.

A Web search of the forum, did not find much mention of Multibus. No
mention of Intel 3001 or 3002. the forum itself didn't offer me a search
feature. I can't say much more from a non-result, possibly Web search
was incomplete.

Also: there's nothing more nubie-annoying, than someone who takes no
time to look at a subject and whom posts "can someone tell me about X?".
I took a little time to look around MAME materials, but from experience
it was not enough time spent to avoid looking foolish.

And, in any event, my point amounted to "these MAME people are
interested in ROM dumps also". I'm not going to run MAME. It's simply
another reference to interest in ROMS beyond myself; and an invitation
to others in this discussion to voice their interests in the Intel math
board.

anyone else with an interest in Intel 3001 bit slices? Or Intel's
floating-point Math board iSBC 310 from 1979 forward? Or who is
operating MAME and can simply determine its support of either?

http://www.bitsavers.org/components/intel/3000/Series_3000_Reference_Manual_Feb76.pdf

The Intel double-density controller uses the 3001, but I don't recall
any of our colleages here attempting to decode its operation. But my
recall may be faulty.

Regards, Herb

[Herb Johnson]

I've changed the subject line to reflect the current discussion.

Thank you. I have no particular access to the schematics. They may or
may not be, in the Intel manual for the iSBC 310 board, identified as
the Intel reference manual 9800410A. And of course, I have no access to
the PROMs, they are held by RICM with the board of course.

It's possible on the margins, to re-engineer the board by inspection and
consideration. To a first order, it executes the 3001 code in the PROMS.
It has some kind of I/O or memory address. It may or may not have
interrupts. Someone with skills, may be able to physically examine the
board, or to attempt to operate the board, to determine those features.

Someone with deep knowledge of Intel's software products for the 8080 in
the late 1970's early 80's era, may find software support for the 310
board, and so extract that code for examination.

The 1981 Systems Data Catalog, has four pages on the iSBC 310. By
inspection: It describes memory-address byte access to the "310 working
registers". The memory address of the 16 bytes of registers, are passed
to one of the eight I/O ports of the board; only four ports are in use.

"An operation command .. by using an output instruction to pass the
appropriate opcode." Upon completion of the operation, notification is
"by an interrupt or by setting a status bit." the data is then
memory-read read. Flags available in a status byte are "busy" "complete"
"error"; "a result byte .. indicates the error conditions and the
results of a compare or test operation".

My engineering spider-sense suggests this is a basis for simulation. But
that's up to the implementer. The document suggests schematics were
distributed with the board. But they suggest the 9800410A Hardware
manual was "NOT SUPPLIED" but "may be ordered".

https://www.retrotechnology.com/z/isbc310_SDC81.pdf

Here are the pages from the Systems Data Catalog. This is a *temporary*
link to obtain the document. It will be removed in days.

Inspection of the photo of the card, shows a DIP switch. Possibly marked
S1? A DIP header of 14 pins is marked J1. These are not referenced in
the catalog pages. There's a W2 set of 8 pins which are likely an
interrupt jumper; this could likely be traced manually on the board.

"The proof of the pudding is in the eating." Some Intel code must
support the operation of this card. That code was not named in the 1981
catalog entry. Possibly the code is in a compiler. Possibly a linker. It
may be buried in a PL/M compiler library with external labels
appropriate to floating-point or fixed-point math. If so, it would
provide a roadmap for use.

Web search says, "PL/M floating point", references a iSBX 331 math
module; I presume it has Intel's single-chip very-slow floating point
device. Not our target.

InfoWorld (Intelligent Machines Journal )Feb 28 1979, page 16: "Intel's
Enhanced ANS Fortran 77 compiler" identifies "Fortran-80 can use intel's
iSBC-310 High speed Mathematics Board". *bingo*.

https://www.retrotechnology.com/z/infoworld_feb79_1.jpg
https://www.retrotechnology.com/z/infoworld_feb79_2.jpg

My wife will not give me time to OCR this document but it's brief. The
salient point is, Fortran-80 Version 2.0 under ISIS-II product MDS-301
as announced Feb 1979 supports the 310 board.

Regards, Herb

[Michael Thompson]

The 1978 ISIS-II FORTRAN-80 Compiler Operator's Manual has a chapter on using the iSBC 310 for improving the performance of floating point math. It says to set the I/O address to 98h and to disable interrupts from the 310. It says that you need to call FQ0GO in F80RUN.lib to configure the memory map of the 310. There is a caution that the 310 can't DMA to memory on 80/10, 80/20 or 80/30 CPUs. You have to link to a special hardware math library.

[Herb Johnson]

Hey, good work Michael! Chapter 5 of

http://www.bitsavers.org/pdf/intel/MDS2/9800480B_ISIS-II_FORTRAN-80_Compiler_Operators_Manual_Aug79.pdf

It says the I/O address for the board can be set "manually via switch
on the 310 board" to 98H. and to "wire wrap the unit so it initiates no
interrupt request on completion of an operation" - so the board must be
polled in software I guess. There's other notes. appendix C describes
FORTRAN's floating point formats.

Chapter 5 says, substitute FPHARD.LIB for FPSOFT.LIB, for use with
ISIS-II or stand-alone. It also says "Two additional libraries are
provided in the FORTRAN-8O RunTime Package for RMX/8O Systems (iSBC 8Ol)
to perform the same functions under RMX/8O: FPHRDX.LIB for iSBC 80/20
and 8O/30 systems, and FPHX1O.LIB for iSBC 8O/lO systems."

and while I'm sure others have these images and software:

http://www.bitsavers.org/bits/Intel/MDS/MDS_II/isis_II/image.txt

Fortran-80 Compiler & Runtime Libs V2.0 DD 9700028-02
Fortran-80 Compiler & Runtime Libs V2.2 DD 9700028-04

Fortran-80 Compiler & Runtime Libs V2.0 SD 9500028-02
Fortran-80 Runtime Library V2.0 SD 9500030-02

http://www.bitsavers.org/bits/Intel/MDS/MDS_II/isis_II/

seems to have several disk images with these reference numbers. Bill
Beech has:

http://www.nj7p.org/Computers/Intel/ISIS-II-SW/9500028_30-002_ISIS-II_V3.4_Fortran-80_Compiler_Utilities_and_Runtime_Libraries_V2.0.7z

which has disk images and extracted Fortran 2.0 files including
FPHARD.LIB. That has a bunch of FQF*** calls. The Chap. 5 document says
call FQ0GO and FQ0END in F80RUN.LIB. Indeed, those are found in text
search in the F80RUN.LIB file.

We can check against Mark Odgen's works:

https://github.com/ogdenpm/intel80tools/tree/master/itools/fort80/2.0

yeah, same file approximately as Bill Beech's. Mark has 2.1 also. Mark
has tools to process many of these Intel files. This is above my pay
grade but there's likely means to "extract" content from .LIB files.
But, the files of interest are small and a brute-force attack may
disassemble them.

Backtracking: Mark Ogden comes through again on a Web search "intel
fortran-80 V2.0 (isis, rmx/80) FPHARD.LIB" with

https://mark-ogden.uk/files/intel/publications/9800836A%20AP-47%20Using%20Fortran-80%20for%20iSBC%20Applications-Nov78.pdf

has a one-paragraph reference to the iSBC 801 for iRMX/80 but follows
with an example of both the '801 and RMX/80 for sewage treatment.
Because floating point is necessary to handle sewage, and hardware FP to
handle it with speed, one calls FPHRDX.LIB or FPHX10.LIB. Code listings
follow.

So: I can locate FPHARD.LIB and FPSOFT.LIB among the FORTRAN-80 files.
But I cannot locate the RMX-80 files described; apparently they are
unique to a distribution for the iSBC 801. The FORTRAN-80 and iSBC
document was a lucky find.

It may be enough, to compare the FPHARD and FPSOFT libraries to extract
useful floating point calling sequences to the iSBC-310 card.

I think I've stumbled through enough material, that the more experienced
can say "oh, yeah, that" and just point to the right bits of code and
the right tools to bust out what's potentially useful.

Still ...

https://mark-ogden.uk/files/intel/labels/9500017-06SD%20v1.3%20RMX_80%20Extensions%20For%20iSBC%2080_10%2C%2080_20%2C%2080_20-4%2C%20and%2080_30.jpg

Those are CPU boards called out for 310 use.

https://mark-ogden.uk/files/intel/labels/9700032-02DD%20v1.3%20RMX_80%20Real-time%20Multitasking%20Executive%20for%20iSBC%2080_30.jpg

This is the iRMX/80 disk itself.

but https://mark-ogden.uk/files/intel/Intel80/irmx/

doesn't seem to have any of the FORTRAN floating libraries in it. and
none of the "label" imaged disk physical lables, seem to reference the
iSBC 801. Again, the library code for the '801 unique to RMX/80, may
only be found on the distribution just for that board.

Regards, Herb

On 10/11/2021 7:27 PM, Michael Thompson wrote:
> The 1978 ISIS-II FORTRAN-80 Compiler Operator's Manual has a chapter on
> using the iSBC 310 for improving the performance of floating point math.
> It says to set the I/O address to 98h and to disable interrupts from the
> 310. It says that you need to call FQ0GO in F80RUN.lib to configure the
> memory map of the 310. There is a caution that the 310 can't DMA to
> memory on 80/10, 80/20 or 80/30 CPUs. You have to link to a special
> hardware math library.
>
> On Monday, October 11, 2021 at 6:00:42 PM UTC-4 hjohnson wrote:
>
> I've changed the subject line to reflect the current discussion.
>

> InfoWorld (Intelligent Machines Journal )Feb 28 1979, page 16: "Intel's

> Enhanced ANS Fortran 77 compiler" identifies "Fortran-80 [Version 2.0] can use

> intel's iSBC-310 High speed Mathematics Board". *bingo*.
>
> https://www.retrotechnology.com/z/infoworld_feb79_1.jpg
> https://www.retrotechnology.com/z/infoworld_feb79_2.jpg
>

[Michael Thompson]

I connected the diskette drive chassis from the MDS-800 to the MDS-II, powered both chassis up, installed a CP/M diskette made by Roger Arrick, in drive 0, and pressed RESET. It selected the drive, but didn't boot. I tried the ISIS V3.4 and ISIS 4.1 and had the same results. I removed the diskette from the drive and pressed RESET. The "_" character stayed on the screen and it didn't display the monitor prompt. I disconnected the floppy diskette chassis and still no monitor. I removed the 32k RAM, diskette boards, and math board, and still no monitor prompt. The IOC passes its diags.

i did notice that the RUN let is bright when the system is first turned on and dimmer after RESET is pressed.

So, is the IPB board broken now? Unfortunately we don't have an ICE-80 that we can put in the MDS-800 to debug it.

[Michael Thompson]

I reaseated all of the chips on the IPB, but it didn't help.

[Roger Arrick]

Great to see progress on and MDS!

I would suspect the drive.
Do you hear the head move?
Reach in there on the back of the drive and turn the head stepper shaft,
then reset and listen for movement.

Hate to ask this, but are you getting the diskette in correctly?

Did this diskette work in the MDS800?

Do you have the connector board on the DD controller board set that connects the boards?

Can you move this DD board set and drives to the MDS800 to reduce the unknowns?

If you suspect the drive, reach in there and move the drive select jumpers
and try the other drive. You don't have to move terminators or cables or anything.

_______________________________________________
Roger Arrick
Ro...@Arrick.com
Tyler, TX

> --
> You received this message because you are subscribed to the Google
> Groups "intel-devsys" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to intel-devsys...@googlegroups.com

> <mailto:intel-devsys...@googlegroups.com>.

> To view this discussion on the web visit

> https://groups.google.com/d/msgid/intel-devsys/45d455f3-d339-4388-9197-db199266f509n%40googlegroups.com
> <https://groups.google.com/d/msgid/intel-devsys/45d455f3-d339-4388-9197-db199266f509n%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Herb Johnson]

Roger gives good advice. I'd suggest however, don't move the boards to
the MDS-800. You have the '230 mostly working in providing video and a
prompt on screen.

But the fact that the drive light comes on, is informative. That says:
the drive has some power (at least logic power); the drive controller is
operating enough to send a drive-select to the drive (so it's not dead).
Make sure you have 24 volts for the stepper! And of course 110VAC for
the disk motor.

Of course, the drive and cabinet was pulled from the *working* MDS-800;
so the drives probably work in principle. But they may operate
differently on the DD controller versus whatver's on the MDS-800. Keep
in mind single versus double sided disks.



Oh! that's a good point. The index hole for single versus double sided,
is in a different place. If the drives are SINGLE sided, and the
diskette is DOUBLE sided - no go, you won't get an index signal, sensor
is in the wrong place. This is on purpose, so you don't f**k up disks.



Roger's diagnostic of rotating the shaft of the head screw, is a good
one. The first thing a controller will do, is seek to track 00. Rotate
the head outside of track 00 to HEAR the head being "seeked".

If the drive or drives don't have a proper "terminator", they may behave
erratically. Make sure one of the drives connected to the controller
has a resistive terminator. It's usually a DIP package. Again: if these
drives worked before, they should have good termination.

Check the fine documentation. See if you can perform a cold boot from
the prompt, with some ROM command. Ask our colleagues for simple
programs, to just command the double-density controller to do things. My
recollection is that the DD controller pair are pretty smart and don't
require much code to do basic things.

I'll bet you can use the ROM monitor to "diagnose" the DD boards. My
guess is, there's some kind of cabling problem. Make sure all cables and
board cross-connects are positioned correctly. Of course make sure the
boards are properly pushed into the Multibus backplane.

Also: put all the boards back into your MDS-II, including that math
board, in the order the system was received in. It's possible there's
some daisy-chained interrupt that got "broke" by reordering the boards.

Moral: With enough futzing around, the problem will identify itself.
Things mostly work! Use the computer, to diagnose the computer!

Regards, Herb

On 10/13/2021 4:01 PM, Roger Arrick wrote:
> Great to see progress on and MDS!
>
> I would suspect the drive.
> Do you hear the head move?
> Reach in there on the back of the drive and turn the head stepper shaft,
> then reset and listen for movement.
>
> Hate to ask this, but are you getting the diskette in correctly?
> Did this diskette work in the MDS800?
>
> Do you have the connector board on the DD controller board set that
> connects the boards?
>
> Can you move this DD board set and drives to the MDS800 to reduce the
> unknowns?
>
> If you suspect the drive, reach in there and move the drive select jumpers
> and try the other drive.  You don't have to move terminators or cables
> or anything.
>
>
> _______________________________________________
> Roger Arrick
> Ro...@Arrick.com
> Tyler, TX

[Jack Mcmullen]

Ok let's get down to basis

Get visual access to the drive. With power applied to drive cabinet and MDS, boot MDS verify drive select light, disk is rotating head is in home position. If failed power down drive cab manually move head toward disk center. Repower drive cab and reboot MDS. Verify head retracts. If above all works, it's alcohol and "Qtip" head cleaning time. If still no joy it's troubleshooting time. Try above

Sent from the all new AOL app for Android

--
You received this message because you are subscribed to the Google Groups "intel-devsys" group.

To unsubscribe from this group and stop receiving emails from it, send an email to intel-devsys+unsub...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/intel-devsys/ce5ef5e5-8dec-0b1f-0475-627daa6376f3%40retrotechnology.com.

[Michael Thompson]

I think that the problem now is that the IPB CPU board is no longer working. The voltages to the Multibus chassis are OK. I can't get the Monitor prompt on the console anymore, even with just the IPB board installed in the Multibus chassis.

[Jack Mcmullen]

If you haven't yet reseat the socketed chips on the IPB

Sent from the all new AOL app for Android

To unsubscribe from this group and stop receiving emails from it, send an email to intel-devsys...@googlegroups.com.

To view this discussion on the web visit

https://groups.google.com/d/msgid/intel-devsys/bd1371db-e108-401b-a329-4f15cd9ae87en%40googlegroups.com

.

[Michael Thompson]

I reseated all of the socketed chips but saw no change in the behavior. We just see the "_" character on the screen.

Does anyone have an IPB or IPC that they would donate to the museum?

[Jack Mcmullen]

Ok question....to boot are you using the reset and/or keyboard. Is your card cage empty with just IPB

Sent from the all new AOL app for Android

On Thu, Oct 14, 2021 at 1:47 PM, Michael Thompson

<michael.9...@gmail.com> wrote:

https://groups.google.com/d/msgid/intel-devsys/42e7e486-1658-4417-808e-c825ae4d2838n%40googlegroups.com

.

[Michael Thompson]

I read through the MDS_Troubleshooting_Manual and followed the debug procedures. The IOC tested OK. I left the keyboard connected and removed everything but the IPB. No monitor prompt. I reaseated all of the socketed chips. Still no monitor prompt. The power supply voltages are all OK.

I might connect a logic analyzer to the IOC J14 connector and see if there is any activity on the Master Data Bus to the IPB.

The RUN LED is on bright after power up, and is dimmer and flickers after a reset.

The 0, 1, and 2 interrupt lights are all on. Is this the correct behavior?

The system description is here: https://www.ricomputermuseum.org/collections-gallery/small-systems-at-ricm/intel-mds-ii-model-230-development-system

Notes on what I have done are here: https://www.ricomputermuseum.org/collections-gallery/small-systems-at-ricm/intel-mds-ii-model-230-development-system-restoration

[Herb Johnson]

Myself, I find an oscilloscope, is a useful logic-operation tool.

One can look at individual signals quickly, and determine general
operations. For instance, low addresses will change rapidly if code is
being executed. ROM and RAM chip-enables, tells you if a chip is being
addressed. Clocks tell you if logic is being clocked. Address decoders,
I/O chips, and so on.

A scope on that RUN LED and the logic that addresses it, for instance,
would be informative about the "flicker". If HALT is being evoked, that
suggests some I/O operation is occuring that halts the processor. That
is a good thing to the extent it suggests a program is operating.

Details of actual operations, of course, may be informative. and a logic
analyzer can zoom in, on actual code or hardware execution and determine
where something is "hung".

Regards, Herb

On 10/14/2021 5:32 PM, Michael Thompson wrote:
> I read through the MDS_Troubleshooting_Manual and followed the debug
> procedures. The IOC tested OK. I left the keyboard connected and removed
> everything but the IPB. No monitor prompt. I reaseated all of the
> socketed chips. Still no monitor prompt. The power supply voltages are
> all OK.
>
> I might connect a logic analyzer to the IOC J14 connector and see if
> there is any activity on the Master Data Bus to the IPB.
>
> The RUN LED is on bright after power up, and is dimmer and flickers
> after a reset.
>
> The 0, 1, and 2 interrupt lights are all on. Is this the correct behavior?

[Jack Mcmullen]

Definitely something gone south on that IPB. Before pulling out the big the big test equip and  since you don't have a spare, you could download IBP proms and verify yours or just make a set and swap out. Since you have several interrupt LED on and just the IBP in the card cage the 8259 interrupt controller has those interrupts holding and no external hardware causing possibly from the csetup code in the proms being corrupt. Appears to be running some valid code before crashing.

Sent from the all new AOL app for Android

On Thu, Oct 14, 2021 at 2:58 PM, Michael Thompson

<michael.9...@gmail.com> wrote:

https://groups.google.com/d/msgid/intel-devsys/2483fe0e-483f-47b0-8464-764c9afcbe58n%40googlegroups.com

.

[Vale, Martyn]

Hi Michael,

 

I didn’t see an answer to your final question regarding the ICE-85, I’m attaching all my gathered ICE-85 documentation for reference at the link below. The user guide will answer your cabling question.

 

https://drive.google.com/drive/folders/1Y2besjcysXDfOJSP7YHTO7mpyiH5YzmH?usp=sharing

 

With regard to your current problems with the IPB can you not try your Tauntek 8080 ICE to check the memory ?. It sounds from what I’ve read that it is running something so could be a memory problem. From my experience of this kind of working one minute and then failing sometime later is that it’s caused by open circuit outputs on one or two TTL ic’s, you can spot this fairly easily with a logic probe as the output is neither low or high just floating about. Although the IPB is doing something I would examine the Reset and Ready circuits first as these are the ones I’ve noticed are the most common failures.

 

Bye

Martyn.

--

You received this message because you are subscribed to the Google Groups "intel-devsys" group.
To unsubscribe from this group and stop receiving emails from it, send an email to intel-devsys...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/intel-devsys/9e01ea05-8ae0-4d4e-8d16-37c6e12e4f05n%40googlegroups.com.

[Michael Thompson]

Martyn,

Thanks for the manuals. The only ICE that we have are the ICE-85 and ICE-86 that go with the MDS, so we are stuck using a 'scope and logic analyzer to debug the IPB.

[Michael Thompson]

I only had a few hours on Saturday to work on the IPB in the MDS-II because we had lots of visitors. IC A27 on the IPB, an Intel 5222 DRAM Refresh Controller, has a corner broken off the upper ceramic layer. We were concerned that it might have damaged the chip and be causing DRAM problems. We looked at the signals on the chip and it looks like it is working correctly. The CYREQ signal goes active at power on, but is not active otherwise.

We looked at the signals on IC A31,  a 74ls155 decoder. We see the correct sequence of RAM address, MRDC/ and INH1/ signals just once at power up, but otherwise not. We see the RAM address being decoded and we see MRDC/ so the 8080 CPU is doing RAM reads, but we only see the INH1/ signal go inactive once at power on. We need to chase the source of the INH1/ signal and see why it is not going inactive.

This week we will connect the logic analyzer part of the 'scope to the 8080 CPU address lines to see if it is stepping through the right addresses in the Monitor ROM.

[Michael Thompson]

I spent some time with the IPB in the MDS-II today. I read the Hardware Reference Manual, especially the parts about the boot sequence. I connected the 'scope to the STARTUP/ and SEL BOOT/ signals from IC A73, and the CS signals for the boot EPROM IC A57 and the Monitor EPROM IC A48. In the Hardware Reference Manual they describe the Boot EPROM being at address 0x0000 at power on and after a reset. The first code in the Boot EPROM is a JMP to 0xE806. I expected to see the CS for the Boot EPROM go low three times for this instruction, and then see STARTUP/ go high to move the Boot EPROM from 0x0000 to 0xE800.

I actually saw the CS go low five times and then STARTUP/ went high. I guess that means that the JMP 0xE806, the DI, and the MVI without the constant were fetched while the Boot EEPROM was at address 0x0000, and then the constant 0x02 was fetched and the OUT 0xFF was executed. There are many MVI & OUT sequences to be executed to configure the devices. During this time I see the STARTUP/ signal go active a few times. When the LXH H, RTCC has partially executed the SEL BOOT/ signal goes inactive which will hide the BOOT EPROM. The CS activity to the Boot EPROM stops. After a few seconds the RUN LED goes bright and there is CS activity on the Monitor EPROM. There is no activity on the CRT other than displaying the _ character.

I started looking at the data being fetched by the 8080 with a logic analyzer, but one channel would not work. The data that I could see looked OK. I will try again on Saturday using the upper 8 bits in the logic analyzer.

So it looks like the boot description in the Hardware Reference Manual does not match the code in the BOOT EPROM and also does not match the behavior of the IPB.

[Michael Thompson]

I traced the data fetched from the Boot EPROM and the resulting data from the OUT instructions. I compared it to the V1.2 listing, and everything looks OK up to address 0xE8D2. The OUT ITCP works OK, and then the next two bytes of the following LXI instruction are fetched. At this point the MRDC/ signal goes low (active) and stays that way. At this point the RUN LED goes out.

If I zoom way out on the logic analyzer time scale I see the MRDC/ signal toggle once per ms. This activity causes the RUN LED to be on, but DIM. This happens to coincide with how the RTC was just configured by the OUT ITCP instruction. The interrupts should still be disabled at this point, and there is no activity on the RTC signal from the 8253, so I have some more digging to determine what is causing the 1 ms wake-up.

After about 5 seconds the CPU starts to run at full speed and the RUN LED is bright. I saw a loop of an OUT or IN instruction being executed, but did not have the time to determine which I/O port was being accessed. One thought is that the CPU is running at an address that is not implemented so just NOP, and eventually gets to F800 and runs the Monitor code.

Since the I/O and RAM setup was never completed by the BOOT EPROM there is nothing on the CRT screen. Maybe I should connect a terminal emulator to the serial ports so see if the monitor responds?

[Herb Johnson]

Other people on this list, know the circuits and ROM monitor code. Mabye
they can analyze the details reported. I have two general suggestions.

1)

Apparently, you don't have an in circuit CPU or ROM emulator. So a brief
general suggestion, is that you burn a new ROM with a very simplified
ROM monitor, that only sets up a serial port, for simple serial
commands to load and read memory, and maybe read/write I/O ports.

If you can get that running, then you can download any simple test
routines. Those simple routines would exercise memory or I/O repeatedly,
and you can monitor results with a simpler oscilloscope (or with your
logic analyser). And you can vary tests based on results and progress.

I do not suggest, you try to burn someone's super-duper do-all monitor.
The goal is to test, not to recreate or debug a monitor. The code you
push in will do the work, not the ROM monitor. Code snips from the V1.2
listing will be sufficient to create a simple testing monitor. Then send
in code snips to test individual things.

If you cannot get the machine to init and read a serial port and return
a serial prompt or response - that in itself is a test and you can track
down why THAT fails.

The VERY simplest code is: Loop: init the UART, send "?". wait for a
character, add say 2 to it, and send back that; end loop. (Adding 2
tells you, you haven't shorted the serial cable.) You may have to mess
with interrupts and timers and a stack also.

If you can't get a monitor running, You can still burn successive ROM
monitors to inject your testing code. For instance, a loop to init some
I/O device. Reliable looping code, provides a means to examine some
device over time. IT's easier to diagnose a repeating condition, than an
intermittent condition.

Right now, your V1.2 monitor is "stuck", apparently runs out of some
resource (stack?), and then runs wild. YOu are stuck diagnosing the
"runs wild" and can't repeatedly test the condition that fails except
with the reset button.

--------------------------
2)
...having said "pushing the reset button"; maybe you should put a clock
signal *on the reset line*, so you can keep restarting the ROM monitor
init code. See repeatedly what's going on, up to the code's point of
failure. That may allow you to use a convenient oscilloscope, to trace
hardware; instead of the less-convenient logic analyzer to look at CPU
operations and guess at how the hardware is responding.

regards, Herb Johnson

On 10/24/2021 9:33 AM, Michael Thompson wrote:
> I traced the data fetched from the Boot EPROM and the resulting data
> from the OUT instructions. I compared it to the V1.2 listing, and
> everything looks OK up to address 0xE8D2. The OUT ITCP works OK, and
> then the next two bytes of the following LXI instruction are fetched. At
> this point the MRDC/ signal goes low (active) and stays that way. At
> this point the RUN LED goes out.
>
> If I zoom way out on the logic analyzer time scale I see the MRDC/
> signal toggle once per ms. This activity causes the RUN LED to be on,
> but DIM. This happens to coincide with how the RTC was just configured
> by the OUT ITCP instruction. The interrupts should still be disabled at
> this point, and there is no activity on the RTC signal from the 8253, so
> I have some more digging to determine what is causing the 1 ms wake-up.
>
> After about 5 seconds the CPU starts to run at full speed and the RUN
> LED is bright. I saw a loop of an OUT or IN instruction being executed,
> but did not have the time to determine which I/O port was being
> accessed. One thought is that the CPU is running at an address that is
> not implemented so just NOP, and eventually gets to F800 and runs the
> Monitor code.
>
> Since the I/O and RAM setup was never completed by the BOOT EPROM there
> is nothing on the CRT screen. Maybe I should connect a terminal emulator
> to the serial ports so see if the monitor responds?
>

[Roger Arrick]

Michael,

I haven't read all of this, so pardon the comments here if not applicable:

I almost never troubleshoot hardware this way, it's just rarely needed.

90% of the time it's just corroded connections, 8% bad caps, 2% bad semiconductors.

Every socketed chip needs to be rocked.
Every nylon connector pulled/plugged 10 times.

You've put a scope all over and make sure you have ripple-free 5V everywhere?
And the other V rails?

Inspect all of the cables, double check, recheck.

Have you poked around on all the clock signals for the CPU and UARTs and stuff?

Have you tried connecting a terminal through a breakout box to the serial port?
Jumper 4-5 (CTS/RTS) that's the hardware flow control.

A lot of times on these old systems the I/O is custom configured and all that needs to be done is make that work the way they wanted.

As for chips, the ones that connect to the real world or to cables are the most vulnerable. In this era that's 1488/1489 RS232 level converters, but it can also be stuff on the FD port and elsewhere.

If I remember right, you have drive activity? Haven't read if you have stepper motor home seek. You've checked the media in another machine? Swapped drive select jumpers and used the other drive? Obvious head dirt and head load pad? Index sensor adjustment? Can you see the head actually loading? That solenoid is sometimes tempermental.

Just some ideas. The current path seems frustrating.

[Jack Mcmullen]

With no floppy drive boards installed a reset should go right to monitor. I have not read that was tried or maybe I missed it. 

Jack

Sent from the all new AOL app for Android

--

You received this message because you are subscribed to the Google Groups "intel-devsys" group.

To unsubscribe from this group and stop receiving emails from it, send an email to intel-devsys+unsub...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/intel-devsys/6175BAF6.6080706%40Arrick.com.

[Michael Thompson]

The system displayed a monitor prompt on the CRT when we first powered it up, so at the beginning everything worked OK.

The power supplies appear to work OK and there is an acceptable amount of ripple on the voltages. If there was a power supply or capacitor issue the failure would be somewhat random. In this case the startup failure mode is always the same. It always dies just when the LXH H, RTCC has partially executed.

With all of the machines at the museum I have seen LOTS of transistor and chip failures, and very few power supply failures or power caused problems. I really think that a chip on the IPB has failed. I need some more debugging time so I can understand what it should do at power up, what it is actually doing, and why it is misbehaving. I might connect the logic analyzer and 'scope to the MDS-800 to watch how it boots.

We have a working MDS-800, so I can swap any of the socketed chips between the MDS-II and the MDS-800 to see what changes the behavior. We also have two Altairs that I can use to test some of the chips.

I really appreciate the comments and suggestions. I am far from an expert with the MDS, but am willing to invest a significant amount of time to learn how they work.

[Michael Thompson]

>With no floppy drive boards installed a reset should go right to monitor. I have not read that was tried or maybe I missed it.

Yes it should, and did for the first few hours that we had it powered on.

There are lots of details about what debugging we have done, including 'scope and logic analyzer images here: https://www.ricomputermuseum.org/collections-gallery/small-systems-at-ricm/intel-mds-ii-model-230-development-system-restoration

After a RESET it is executing the code correctly in the Boot EPROM up to address E82E. From that point it fetches the first two bytes of the LXI H instruction from addresses E82F and E830 and then the the CPU hangs. The SEL BOOT/ signal goes inactive at this time. I believe that SEL BOOT/ going inactive would make the Boot EPROM disappear from the address space, so that would account for no more memory fetches.  Every 1 mS it wakes up for one memory fetch. I haven't traced what the CPU is doing for the 1 mS intervals.

Since the point where it dies is just where it is fiddling with the 8253 Interval Timer, and it is set to 1 mS, and the CPU wakes up every 1 mS, I find this most curious.

There is also a 1 mS bus timeout TO ACK/ signal that I need to look at. It is possible that SEL BOOT/ makes the Boot EPROM disappear, which makes the LOC ACK signal go inactive, so the CPU sits in a wait state until one of the other ACKs like TO ACK/ activates and lets the CPU do another cycle. I need to look at the TO ACK/ signal too to see if it is waking up the CPU every 1 mS.

I think that eventually the CPU executes very slowly until it eventually gets to address F800 and executes the Monitor EPROM. This would generate the LOC ACK and the CPU would then run at full speed. Unfortunately the CPU never executed the configuration code in the Boot EPROM after E830 so the RAM wasn't sized, the interrupt vectors were not set, the stack pointer wasn't set, the serial ports were not configured, and the Monitor banner is not printed.

[Jack Mcmullen]

If you have a prom programmer I'd down the E800 monitor prom from Bill's or Herbs site, do a compare against yours. Sure sounds like a bad prom. 

Sent from the all new AOL app for Android

--
You received this message because you are subscribed to the Google Groups "intel-devsys" group.
To unsubscribe from this group and stop receiving emails from it, send an email to intel-devsys...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/intel-devsys/c502291b-aa2c-4a65-a5b2-492c072f68e0n%40googlegroups.com.

[Michael Thompson]

>If you have a prom programmer I'd down the E800 monitor prom from Bill's or Herbs site, do a compare against yours. Sure sounds like a bad prom. 

I made new Boot and Monitor EPROMs. Swapping them for the originals did not change the behavior.

That does lead to the possibility of writing some test code to replace the original Boot EPROM.

[Jack Mcmullen]

Ok, looking at the monitor listing versus the 225 IPB schematic, using your eyes and scope see if pin 7 of the 8224 is outputting a continuous pulses from Boot thru hang. This pulse continues resetting the RUN D-flipflop allowing a dimmer intensity. If you have a spare 8228 give it a try.

If you can log the state of the 8224 pins ( less 14 & 15 crystal). Before and after hang that would help me help you.

Jack 

Sent from the all new AOL app for Android

On Sun, Oct 24, 2021 at 6:36 PM, Michael Thompson

<michael.9...@gmail.com> wrote:

https://groups.google.com/d/msgid/intel-devsys/f77c44b6-4d53-4746-a9a0-1ff2fa258c69n%40googlegroups.com

.

[Jack Mcmullen]

Also since that E82F sets up the Real Time Clock you can look at the 8253 (A49) pin 17, 13 and 10 are output clocks and 9, 15 and 18 is the system input clock. Since that E82F is setting up this chip looking AR pre hand and post hang should give you and me an idea of the reason for the hang

Jack

Sent from the all new AOL app for Android

On Sun, Oct 24, 2021 at 6:36 PM, Michael Thompson

<michael.9...@gmail.com> wrote:

https://groups.google.com/d/msgid/intel-devsys/f77c44b6-4d53-4746-a9a0-1ff2fa258c69n%40googlegroups.com

.

[Jack Mcmullen]

Chip #3 to reseat or replace, A60, the 8259, the interrupt controller. 

These 3 recommendations I sent you are all involved in the hanging after the E82F write of RTCC TIMER CHANNEL which continously resets the watchdog timer and the RUN LED.

Jack

https://groups.google.com/d/msgid/intel-devsys/f77c44b6-4d53-4746-a9a0-1ff2fa258c69n%40googlegroups.com

.

[Michael Thompson]

Thanks for all the pointers. I will look at these signals Wednesday afternoon and report back.

[Roger Arrick]

Hi MDS'ers

Don't think I've ever seen a cassette interface for multibus
https://www.ebay.com/itm/264479045568

This seller has some other interesting "boards"

[Jack Mcmullen]

Hey Roger,

Geeese a cassette data interface. Reminds me of the early Radio Shack computer days. The audio data storage device that deserved death by launching against the wall. Later the tape cartridge interface was a solid storage media. I have no knowledge of ISIS support for any tape device. How about OSIRIS, maybe this board was for one of those.

There is no processor on board I can see. The document is blocked by the card, would help to see what else it stated there. At $300 way too steep for a just for fun buy

Sent from the all new AOL app for Android

Tyler, TX

--
You received this message because you are subscribed to the Google Groups "intel-devsys" group.

To unsubscribe from this group and stop receiving emails from it, send an email to intel-devsys+unsub...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/intel-devsys/617863F9.3040501%40Arrick.com.

[Bill Beech (NJ7P)]

Interesting but way too pricey for me!  Just what I need, a Cassette Recorder on and MDS.  Gag!

Bill

To unsubscribe from this group and stop receiving emails from it, send an email to intel-devsys...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/intel-devsys/1775328419.1959688.1635281551055%40mail.yahoo.com.

[Mark Fisher]

 WSI-MDN.pdf

Hi Everyone,

While this is not a cassette drive. There were removable drives for the MDS.  See page two.  The whole thing is an interesting read really. 

Page 2 also mentions ISIS 2+ which kind of sounds like OSIRIS with the password/partitions.  The Winchester Systems product I have is a SASI interface to their box.  I would assume this removable one is probably the same.  Think the cartridges/drive was a early Syquest drive.

Regards, Mark    

To view this discussion on the web visit https://groups.google.com/d/msgid/intel-devsys/3242c588-7b74-4ce4-81cc-f7e918f59dee%40nj7p.info.

[Jack Mcmullen]

That description of ISIS 2+ sure reads of most of what OSIRIS does. That removable media cartridge I remember but not with MDS rather early PCs. 

To view this discussion on the web visit https://groups.google.com/d/msgid/intel-devsys/CAJ5BDDDqdD2L-2YOa02xO07-NAKM7kYj4jzZ1rwqOWJ%2B%3DD8msw%40mail.gmail.com.

[Herb Johnson]

On 10/26/2021 10:42 PM, Herb Johnson wrote:

> On 10/26/2021 4:52 PM, 'Jack Mcmullen' via intel-devsys wrote:
>> Hey Roger,
>> Geeese a cassette data interface. Reminds me of the early Radio Shack
>> computer days. The audio data storage device that deserved death by
>> launching against the wall. Later the tape cartridge interface was a
>> solid storage media.

>>     On Tue, Oct 26, 2021 at 1:24 PM, Roger Arrick

>>     Don't think I've ever seen a cassette interface for multibus
>>     https://www.ebay.com/itm/264479045568
>

Unclear, if this is a digital data cassette controller. That's a little
more sophisticated than an audio cassette player and two-tone audio
data. A lot of industrial controllers in the late 70's early 80's used
digital data cassettes. I cover some of that - analog Phillips
cassettes, a tiny bit of PhiDeck digital cassettes - on my web site,
somewhere. Or even older data storage stuff. That was hard work back in
the past, not that long before microprocessors.

regards, Herb

[Jack Mcmullen]

Hey Mark...Thanks...Good Read!!!

Sent from the all new AOL app for Android

To view this discussion on the web visit https://groups.google.com/d/msgid/intel-devsys/CAJ5BDDDqdD2L-2YOa02xO07-NAKM7kYj4jzZ1rwqOWJ%2B%3DD8msw%40mail.gmail.com.

[Roger Arrick]

Greetings MDS'ers:

Today's preservation haul:

The first is a data tech corp host controller
which I'm hoping can act as a backup for my OSIRIS machine.

The second is a national semi BLC-8221 or BLC-8201 (I dont know which)
which is SUPPOSE to emulate SBC 201 SD FDC on a singla board - I THINK.
But it has a missing 40-pin chip. Maybe it's a 177x.
This board has an 8080 CPU and 8228.
Does anyone have schematics for it?
The Hardware reference manual is 420305586-001

[Roger Arrick]

Read the description on this auction for a little fun:

https://www.ebay.com/itm/290958775065

[Herb Johnson]

On 10/27/2021 2:33 PM, Roger Arrick wrote:
>
> The first is a data tech corp host controller
> which I'm hoping can act as a backup for my OSIRIS machine.

I think that will prove to be a SASI controller for DTC's SASI to MFM
cards. 003-0003 rev 4B. Check bitsavers. Seems like I've had this card
myself at one time or another, maybe currently; and the DTC SCSI/MFM card.

> The second is a national semi BLC-8221 or BLC-8201 (I dont know which)

> which is SUPPOSE to emulate SBC 201 SD FDC on a single board - I THINK.

> But it has a missing 40-pin chip.  Maybe it's a 177x.
> This board has an 8080 CPU and 8228.

You've described the text on the board. A NOv 12 1079 Computerworld
article (press release) says the the BLC-8201 is a replacement for the
INtel SBC-201. It infers that the BLC-8221 is unique to National. BOth
are described as single-density floppy controllers. The National
Multibus product line is "Series/80".

It looks like, later data books from National on their series/80
systems, used the BLC-8222 which is a double-density controller card. I
could not find detailed references to the prior single-density card
except as a model number and type.

With some due diligence on the board itself, you may be able to
determine the FDC chip. look at simple signals like index hole, head
load, and so on. Trace them from the 50-pin 8-inch connector back to the
empty socket. Or: look at the board's I/O address controller circuits.
See where the I/O address enable goes to the empty socket. OR: the eight
data lines, same deal. They may be unique per floppy-controller chip.
There aren't that many single-density FDC chips from National or
otherwise in the era.

Regards, Herb

[Michael Thompson]

I looked at the signals on the 8224 chip. The STSTB signal has 50 ns pulses for 190 us, and stops when everything else stops. The SYNC signal has 400 ns pulses for 190 us, and also stops. The RESET and CLR/ signals go inactive at the beginning, and doesn't change. The RDYIN, READY, XACK/, LOC ACK all stop after 190 us. This all looked OK.

I decided to chase why the SEL BOOT/ goes inactive after 190 us. The IC A73, a 74LS259 latch, has four data inputs to select the output pin and the data to write to the pin. The CLR input signals conditions the chip at power on. The G/ signal causes the chip to use the A, B, and C inputs to select the output pin and write the data from the DATA IN input. We found that the G/ input was always active. This would cause any random data on the input pins to be latched to the output pins at any time.

We looked at pins 1, 2, and 3 of IC A54, a 74S32 that makes the Q/ signal for IC A73. Pin 1 has SEL CPU/ signal that goes low when I/O port 0xFF is selected. You can see this as the OUT CPUC instructions in the Boot EPROM. These were 2.5 us low going pulses and the timing matched the code in the Boot EPROM. Pin 2 according to the schematic has the IOWC/' signal, but was always low. We looked at IC A75, a 74LS241, that is the source of the IOWC/' signal. It looked OK and the timing matched the OUT instructions in the Boot EPROM. We looked at IC A59, the 8259, pin 2 and the signal looked like the IOWC/' signal. I guess that the schematic doesn't match the board. The signal on IC A54 pin 2 looks like the INIT/ signal. In any case when the SEL CPU/ signal is high the output on pin 3 that makes the G/ signal should also be high. Pin 3 tracked pin 2, and didn't react to pin 1. We replaced the 74S32 with a 7432 in a socket and ordered some 74S32 parts. On power up we were rewarded with the SERIES II MONITOR, V1.2 display on the CRT. It looks like it is working again, so we can try to boot ISIS and CP/M.

Thanks everyone for all of your help and guidance.

[Jack Mcmullen]

Hey!! HEY!!!

Sent from the all new AOL app for Android

On Wed, Oct 27, 2021 at 2:49 PM, Michael Thompson

<michael.9...@gmail.com> wrote:

https://groups.google.com/d/msgid/intel-devsys/639914d2-b15d-44fd-bae7-fe360e47842cn%40googlegroups.com

.

[Herb Johnson]

On 10/27/2021 4:47 PM, Roger Arrick wrote:
> Read the description on this auction for a little fun:
>
> https://www.ebay.com/itm/290958775065
>

https://www.cpu-world.com/CPUs/3002/index.html

Well, all I can say, is that the seller stumbled into the truth. The die
looks to me like this Intel 3002 bit-slice die (from Signetics but they
are probably a second-source and got Intel's die design).

I don't know why someone would pay $75 for one chip: one can often buy a
BOARD of them for that price to say twice that price. There's ebay
auctions now for 3002's at $15-$20 each from China (could be fakes).

We just discussed an Intel bit-slice floating-point board held by the
RICM. The Intel Multibus M2FM controller used them, as did various other
hard disk and early floppy disk controller boards. So it's a thing.

regards, Herb

[Jack Mcmullen]

Outside of the description. I Love the attempt to sell a chip with a broken ceramic top. 

Sent from the all new AOL app for Android

--
You received this message because you are subscribed to the Google Groups "intel-devsys" group.
To unsubscribe from this group and stop receiving emails from it, send an email to intel-devsys+unsub...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/intel-devsys/6179BAD3.5030706%40Arrick.com.

[Bill Beech (NJ7P)]

Great! Another SBC 201 or 202 bites the dust!

Bill

[Michael Thompson]

Will the MDS-II Model-230 boot from the same double-density ISIS and CP/M diskettes as the MDS-800?

[Jack Mcmullen]

Yes it should

Sent from the all new AOL app for Android

On Thu, Oct 28, 2021 at 4:57 PM, Michael Thompson

<michael.9...@gmail.com> wrote:

https://groups.google.com/d/msgid/intel-devsys/d7815ce0-575f-4d49-aae7-2b48a93cee69n%40googlegroups.com

.

[Vale, Martyn]

Roger,

If you are looking for a Single Density Controller, Patrick Wong of Northwest Tech has a few Zendex ZX-200A's. The boards are un-tested, but mine was fine and looked like new.

I'm working on re-mapping the I/O Decoder Prom and have already managed to get the board to boot single density floppies something the original Prom won't do as it just provides Double Density boot and Single Density on :F4: and :F5:. The Prom is twice the size it needs to be, so my solution will be switchable via an existing jumper on the board. I've also designed a buffered PCB to connect the ZX-200A directly to the MDS-202 port on the SA800 PCB,. I've mostly built one of the prototype PCB's, but obviously not tested it yet. The ZX-200A board uses an Octal Latch for the drive signals which has limited sink capacity, hence the need for buffering to drive an SA800 PCB with my drive select logic.

Bye
Martyn.

--
You received this message because you are subscribed to the Google Groups "intel-devsys" group.
To unsubscribe from this group and stop receiving emails from it, send an email to intel-devsys...@googlegroups.com.

To view this discussion on the web visit https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgroups.google.com%2Fd%2Fmsgid%2Fintel-devsys%2F61799B91.5010407%2540Arrick.com&amp;data=04%7C01%7Cm.vale%40ucl.ac.uk%7C7df1ef3f7507403f39f308d99978bf36%7C1faf88fea9984c5b93c9210a11d9a5c2%7C0%7C0%7C637709566623436725%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=KF6zA7u8SSEuSUUkmb6r4SOHoYl4TRZVOYeq4IX%2F%2FE0%3D&amp;reserved=0.

[Bill Beech (NJ7P)]

Martyn,

I use a ZX-200A in my MDS-225 here.  I would like to get your new ROM
image for the disk controller when you complete it.

Thanks!

Bill

[Vale, Martyn]

Hi Bill,

No problem, will release the image and PCB as soon as they are finished.

Thanks

> To view this discussion on the web visit https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgroups.google.com%2Fd%2Fmsgid%2Fintel-devsys%2F61799B91.5010407%2540Arrick.com&amp;data=04%7C01%7Cm.vale%40ucl.ac.uk%7C515b8c1237504fb2736108d99ca64965%7C1faf88fea9984c5b93c9210a11d9a5c2%7C0%7C0%7C637713061455816131%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=n7wNXR1ckRE6peOzDNlgJLIl8hsaOxqtVAREBOBrupw%3D&amp;reserved=0.

>

--
You received this message because you are subscribed to the Google Groups "intel-devsys" group.
To unsubscribe from this group and stop receiving emails from it, send an email to intel-devsys...@googlegroups.com.

To view this discussion on the web visit https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgroups.google.com%2Fd%2Fmsgid%2Fintel-devsys%2F43a556fd-b447-24ce-98b0-fb0c6a7c2b21%2540nj7p.info&amp;data=04%7C01%7Cm.vale%40ucl.ac.uk%7C515b8c1237504fb2736108d99ca64965%7C1faf88fea9984c5b93c9210a11d9a5c2%7C0%7C0%7C637713061455816131%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=Qz4KrkPQmKEKj8mGbNzqs%2BBtTekPqTx2eVf429ZRb0g%3D&amp;reserved=0.

[Herb Johnson]

Um, someone left in the subject line, a "spam" reference. Please edit
that out in any replies, it's starting to propagate. . - Herb

On 10/31/2021 6:40 PM, Vale, Martyn wrote:
[subject line had "spam" reference]

> Hi Bill,
>
> No problem, will release the image and PCB as soon as they are finished.
>
> Thanks
> Martyn.
>
> -----Original Message-----
> From: intel-...@googlegroups.com On Behalf Of Bill Beech (NJ7P)
> Sent: 31 October 2021 19:39
> Subject: {SPAM?} Re: intel-devsys Today's preservation haul: Host controller, BLC-8221 FDC
>
>
> Martyn,
>
> I use a ZX-200A in my MDS-225 here. I would like to get your new ROM
> image for the disk controller when you complete it.
>
> Thanks!
>
> Bill

[Michael Thompson]

Can we install an 8271 in the empty socket on the IOC board and add a single density diskette drive?

I didn't see any 8271s on eBay. Does anyone know of a source?

[Jack Mcmullen]

That 8271 was normally installed as was the ability for a Single Density Flop. There was a 50 pin short flat cable for that drive at the top of the IOC by that chip. The drive needs the typical power hookup. 

You can use "SearchDome.com" to set up daily Ebay searches that

 email you results daily automatically for free. Just wait till a chip pops up while you beat the bushes 

Jack

Sent from the all new AOL app for Android

On Wed, Nov 3, 2021 at 12:59 PM, Michael Thompson

<michael.9...@gmail.com> wrote:

https://groups.google.com/d/msgid/intel-devsys/911ce71f-ab5a-4d9e-b868-b61aa755bfb7n%40googlegroups.com

.

[Michael Thompson]

Thanks for the info on searchdome. I will try it.

We slowly, over the course of an hour, powered up the dual-diskette chassis that came with the MDS-II. The drive bearings are noisy, but otherwise it looks OK. We booted the MDS-800 from this dial-diskette chassis and ISIS and CP/M both booted. ISIS said that the left diskette was not ready when we tried to list the directory of a diskette. CP/M would not boot on the MDS-II using this chassis. We will swap the iSBC 202 from the MDS-800 into the MDS-II to see if that is the problem.

[Herb Johnson]

On 11/3/2021 4:30 PM, Michael Thompson wrote:
> We slowly, over the course of an hour, powered up the dual-diskette
> chassis that came with the MDS-II. The drive bearings are noisy, but
> otherwise it looks OK. We booted the MDS-800 from this dial-diskette
> chassis and ISIS and CP/M both booted. ISIS said that the left diskette
> was not ready when we tried to list the directory of a diskette. CP/M
> would not boot on the MDS-II using this chassis. We will swap the iSBC
> 202 from the MDS-800 into the MDS-II to see if that is the problem.

If the bearings are noisy, you might check the index signal for a proper
rate (360RPM = 60Hz), if the bearings are dragging. Otherwise it's
probably some difference in drive setup, or cabling. But it could be
that one controller was more tolerant than another of drive issues.

It could also be: you clogged up the heads on the drive in the course of
use - always clean the heads before further diagnosis. And always
examine your diskettes after use. That "noisy bearings" could possibly
be the sound of the read head scraping off iron oxide. Other noise
sources are the hub itself vibrating: There's many places where a
vibration can be produced. Touch lots of things and see if that changes
the sound.

regards, HErb

[Michael Thompson]

We tried the not working iSBC-202 diskette controller boards from the MDS-II in the working MDS-800. If either the Channel or the Interface board was installed in the MDS-800 it would not boot into the monitor or boot from diskette. After a lot of cleaning the gold fingers, chip sockets, and chip leads we were able to get the iSBC-202 boards working. We reinstalled the boards in the MDS-II and now it boots CP/M and ISIS from the same diskettes that Roger Arrick made for the MDS-800. It looks like CP/M is configured for two iSBC-202 diskette controllers with a total of four drives, and an internal single-density drive.

One of our volunteers likes to fix keyboards, so he really cleaned up the MDS-II keyboard. Looks much better now.

We still need to fix the left diskette drive because the controller says that it is not ready. I suspect that this is just an adjustment of the index pulse, as was the case with the MDS-800. We haven't touched the LSI dot-matrix printer that came with the system yet. it has some rust on the slide bars for the print head that needs to be cleaned up, and it needs a new ribbon. We have about 10 new ribbons for it, that hopefully are not dried out.

As always, thanks everyone for the suggestions and the help.

[Herb Johnson]

This is all good news, thanks for reporting your work in detail. Those
details in this list, and on your Web site, inform many other people
about the means and methods to restore these mid/late 1970's
microcomputers back into service. In particular restoration info on
Intel Multibus systems is somewhat sparse.

The Intel multibus floppy controller board-pairs, may need to match on
revisions, I'm not sure. Also: the ROMS and microcontrollers on them do
need to match on revisions. It's good to report programmed-device labels
in detail, so others can build a list of revision-sets per board
revisions. Same applies to Intel hard-disk controllers.

My interests include 8 inch floppy drives, others in this list are also
interested. So your reportage on the index-pulse adjustment will be of
interest; I'll otherwise check your MDS-800 notes.

On printers: I often use sewing-machine oil for sliding metal surfaces,
it's a good oil. Be careful not to overly abrade the chromed steel
slidebars in removing rust. Start with oil and some cloth scrubbing.
Then possibly some kind of very mild abrasive liquid. Almost every
printer I've ever operated, has some kind of self-test mode which is
operated by holding down some button while powering up. All of them with
carriages, do some kind of motion on power-up, which is diagnostic.

Dried up ribbons are sometimes restored by applying some kind of oil;
some Web searching may be informative. But ribbon cartridges with
internal parts often have those parts busted up from age. If the printer
uses open-reel ribbons; look for new "typewriter ribbons" that can be
rewound onto your old spools.

That's all the advice and encouragements I can come up with.

Regards, Herb Johnson

> http://www.retrotechnology.com <http://www.retrotechnology.com> OR .net

> preserve, recover, restore 1970's computing
> email: hjohnson AT retrotechnology DOT com
> or try later herbjohnson AT comcast DOT net
>

> --
> You received this message because you are subscribed to the Google
> Groups "intel-devsys" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to intel-devsys...@googlegroups.com

> <mailto:intel-devsys...@googlegroups.com>.

> To view this discussion on the web visit

> https://groups.google.com/d/msgid/intel-devsys/ff388f49-311d-4cd1-8bc1-e62197d2a28bn%40googlegroups.com
> <https://groups.google.com/d/msgid/intel-devsys/ff388f49-311d-4cd1-8bc1-e62197d2a28bn%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Bill Beech (NJ7P)]

Michael,

That is probably BIOS21I, which is configured for one SBC-202, one SBC-201, and the internal SD drive.  I have attached the source code for it.

I have source for CP/M-80 V2.2 and all the ISIS Versions on my site.

Good luck!

Bill

--

You received this message because you are subscribed to the Google Groups "intel-devsys" group.
To unsubscribe from this group and stop receiving emails from it, send an email to intel-devsys...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/intel-devsys/ff388f49-311d-4cd1-8bc1-e62197d2a28bn%40googlegroups.com.

[Michael Thompson]

Bill, you are right, that was the BIOS21I I saw on the CP/M 2.2 diskette.

If I can find an 8271 diskette controller chip I will add a single-density drive inside of the MDS-II chassis. No luck so far finding one.

[Bill Beech (NJ7P)]

Michael,

Yes, I just made a quick look on eBay.  Nothing!  Internet yielded exactly one source:

https://www.sellmyretro.com/offer/details/intel-8271-floppy-disc-controller-38630

Not sure what quality this part is or anything about the vendor.

I sure don't have any spares for them.

Bill

To view this discussion on the web visit https://groups.google.com/d/msgid/intel-devsys/a812a0f3-7304-4bb7-87e8-6f0cce229f14n%40googlegroups.com.

[Michael Thompson]

The RICM has a large collection of BBC and Acorn computers. The next time I am in the warehouse I will see if we have duplicates of any, and see if the 8271 inside is socketed.

Does anyone else have suggestions for computers that used an 8271 so that we could borrow one?

[Herb Johnson]

https://news.ycombinator.com/item?id=25115916

is slightly informative. I looked with Web search, for S-100 cards that
may have used the 8271. Nothing readily popped up. But I don't recall
any myself, and I've seen a number of S-100 cards. I'll try to remember
this particular need.

Persistent Web search finds Acorn and BBC referenced many many times;
and nobody else.

https://hackaday.com/2020/11/22/intels-forgotten-1970s-dual-core-processor/

Is a curious article.

I thought about checking IBM PC controllers. But 1) they used Western
Digital compatible controllers and 2) double density. The 8271 is single
density; a few MS-DOS semi-compatibles used the 8272 double-density chip.

So this is a tough component to find, as it was used in a narrow window
of time, and was not popular even then. S-100 would be the alternative
search strategy to Intel Multibus and BBC/Acorn searching.

actually, those BBC micros, are kinda special, to those interested.
Don't bust them up just for a chip, not that I need to say that.

Regards, Herb

On 11/12/2021 2:18 PM, Michael Thompson wrote:
> The RICM has a large collection of BBC and Acorn computers. The next
> time I am in the warehouse I will see if we have duplicates of any, and
> see if the 8271 inside is socketed.
>
> Does anyone else have suggestions for computers that used an 8271 so
> that we could borrow one?

[craig andrews]

It doesn’t look like this “sell my retro” fellow ships out of the UK.  I could use a 8271 also if anyone finds some.

It is a long shot, but did anyone check with Patrick at northwest technical in brookings Oregon?

Craig

On Nov 12, 2021, at 11:02 AM, Bill Beech (NJ7P) <nj...@nj7p.info> wrote:



To view this discussion on the web visit https://groups.google.com/d/msgid/intel-devsys/c659b430-90e7-6933-9e0b-1117866a4efb%40nj7p.info.

[Roger Arrick]

I don't have any 8271 chips that are not in working boards that I use.
There are a few 8272's on ebay in boards but I didn't look up to see the differences.

_______________________________________________
Roger Arrick
Ro...@Arrick.com
Tyler, TX

>>>> <https://groups.google.com/d/msgid/intel-devsys/ff388f49-311d-4cd1-8bc1-e62197d2a28bn%40googlegroups.com?utm_medium=email&utm_source=footer>.

>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "intel-devsys" group.
>>> To unsubscribe from this group and stop receiving emails from it,
>>> send an email to intel-devsys...@googlegroups.com.
>>> To view this discussion on the web visit

>>> https://groups.google.com/d/msgid/intel-devsys/a812a0f3-7304-4bb7-87e8-6f0cce229f14n%40googlegroups.com
>>> <https://groups.google.com/d/msgid/intel-devsys/a812a0f3-7304-4bb7-87e8-6f0cce229f14n%40googlegroups.com?utm_medium=email&utm_source=footer>.

>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "intel-devsys" group.
>> To unsubscribe from this group and stop receiving emails from it, send
>> an email to intel-devsys...@googlegroups.com

>> <mailto:intel-devsys...@googlegroups.com>.

>> To view this discussion on the web visit

>> https://groups.google.com/d/msgid/intel-devsys/c659b430-90e7-6933-9e0b-1117866a4efb%40nj7p.info
>> <https://groups.google.com/d/msgid/intel-devsys/c659b430-90e7-6933-9e0b-1117866a4efb%40nj7p.info?utm_medium=email&utm_source=footer>.

>
> --
> You received this message because you are subscribed to the Google
> Groups "intel-devsys" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to intel-devsys...@googlegroups.com

> <mailto:intel-devsys...@googlegroups.com>.

> To view this discussion on the web visit

> https://groups.google.com/d/msgid/intel-devsys/2E39AB1B-AFCE-478B-AE85-EB070922C910%40gmail.com
> <https://groups.google.com/d/msgid/intel-devsys/2E39AB1B-AFCE-478B-AE85-EB070922C910%40gmail.com?utm_medium=email&utm_source=footer>.

[Michael Thompson]

I found an 8271 in the UK. It should be on the way here next week.

[Michael Thompson]

I got both of the diskette drives that came with the MDS-II working today. The right drive just needed the index pulse length adjusted. The left drive had intermittent problems with the J2 connector that connects the devices on the drive to the controller board on the bottom of the drive. Some DeoxIT fixed it. We adjusted the index pulse length too. The stepper motor was difficult to turn, so it would not step between tracks correctly. We put just a little Teletype oil on the lead screw and slide bar and that freed it up.

We used the MDS-800 to control the diskette drives because the iSBC-202 in the MDS-II is misbehaving again. I will try DeoxIT on the socketed ICs, sockets, and gold fingers. 

[Herb Johnson]

If the index pulse is generated by a one-shot or monostable
multivibrator, it's possible that age has changed the value of the
resistor and/or capacitor. I see that occur on 1970's S-100 boards. I
suppose that trimpots change value but it might be the contact
resistance on the trimmer.

ANother thin oil that's more readily found, is sewing-machine oil. Any
well stocked hobby store and most stores that sell cloth and sewing
machines will have this. You might clean off the old oil first; it mixes
with dust and otherwise become either gummy or varnish-like.

regards Herb

On 11/13/2021 8:04 PM, Michael Thompson wrote:
> I got both of the diskette drives that came with the MDS-II working
> today. The right drive just needed the index pulse length adjusted. The
> left drive had intermittent problems with the J2 connector that connects
> the devices on the drive to the controller board on the bottom of the
> drive. Some DeoxIT fixed it. We adjusted the index pulse length too. The
> stepper motor was difficult to turn, so it would not step between tracks
> correctly. We put just a little Teletype oil on the lead screw and slide
> bar and that freed it up.
>
> We used the MDS-800 to control the diskette drives because the iSBC-202
> in the MDS-II is misbehaving again. I will try DeoxIT on the socketed
> ICs, sockets, and gold fingers.

[Vale, Martyn]

 

Just for reference please see attached manual section 3.3, which states do not lubricate drive as this will attract dust. With my ones I cleaned all the moving parts with IPA and a Toothbrush and after a good cleaning all seems to be fine. Obviously the drive could get in to a state where lubrication might be the only answer, but I would still clean off the oil after it’s run in again.

 

Martyn.

 

From: intel-...@googlegroups.com [mailto:intel-...@googlegroups.com] On Behalf Of Michael Thompson
Sent: 14 November 2021 01:05
To: intel-devsys <intel-...@googlegroups.com>
Subject: {SPAM?} Re: intel-devsys MDS-II Model 230 at the Rhode Island Computer Museum

 

 

I got both of the diskette drives that came with the MDS-II working today. The right drive just needed the index pulse length adjusted. The left drive had intermittent problems with the J2 connector that connects the devices on the drive to the controller board on the bottom of the drive. Some DeoxIT fixed it. We adjusted the index pulse length too. The stepper motor was difficult to turn, so it would not step between tracks correctly. We put just a little Teletype oil on the lead screw and slide bar and that freed it up.

We used the MDS-800 to control the diskette drives because the iSBC-202 in the MDS-II is misbehaving again. I will try DeoxIT on the socketed ICs, sockets, and gold fingers. 

On Saturday, November 13, 2021 at 1:10:25 PM UTC-5 Michael Thompson wrote:

>>>> --
>>>> Herbert R. Johnson, New Jersey in the USA
>>>> http://www.retrotechnology.com OR .net
>>>> preserve, recover, restore 1970's computing
>>>> email: hjohnson AT retrotechnology DOT com
>>>> or try later herbjohnson AT comcast DOT net
>>>>

To view this discussion on the web visit https://groups.google.com/d/msgid/intel-devsys/baf98810-f89a-46d5-bd32-68b13dea44c0n%40googlegroups.com.

[Michael Thompson]

Thanks for the manual and pointer. I only lubricated the left drive. After I run it for a while I will wipe off any remaining lubricant. If I remove the top cover of the chassis I can easily check for dust accumulation. 

[Michael Thompson]

I found a welcome letter for the MDS-II in the pile of documentation.

[Michael Thompson]

We received an Intel blue LSI 201A dot matrix printer with the MDS-II. We have the manual, and lots of NOS ribbons that are probably dried out.

Is anyone familiar with this printer and have some suggestions before try to revive it?

[Herb Johnson]

> On 11/14/2021 11:03 AM, Michael Thompson wrote:
>> I found a welcome letter for the MDS-II in the pile of documentation.
>>

Was there a second page of Intel employee contacts? The document number
is 9800569B for those keeping score.

On 11/14/2021 11:12 AM, Michael Thompson wrote:
> We received an Intel blue LSI 201A dot matrix printer with the MDS-II.
> We have the manual, and lots of NOS ribbons that are probably dried out.
>
> Is anyone familiar with this printer and have some suggestions before
> try to revive it?
>

Look up repairs of other dot-matrix printers, and use the same methods.
They are all alike, to a first order. Make sure the carriage moves
smoothly. Handle the head carefully, especially at the end where oils
and impacts may have damaged or gummed up the pins and the surrounding
head materials. Look inside at the boards for rust and other damage. See
if there's any kind of "smarts" inside to run the printer stand-alone.
Don't operate it without a ribbon and paper.

See if you can date the printer by looking at IC chip dates.

But it's likely that on power up, the head will seek to the left.
Possibly there's a self-test if you hold down a button during power up.

For more information, you may have to search electronic trade magazines
of the late 60's early 70's. As this was before or during
microprocessors popularity (abt 1975), there aren't as many online
resources of vintage magazines. This is why I said "date the printer".

Also: printers are entirely out-of-favor in the 21st century. That
doesn't help. So Michael, please "cover" the printer on your RICM Web
site. Frankly: I can't find online references to that LSI model, and
barely ANY references to ANY LSI printers. I can't immediately confirm
the model number. Possibly you'll have to look for "ballistic printers"
or "impact printers", that being LSI's designation.

Regards Herb

[Michael Thompson]

I put images of the printer on the MDS-II WWW page at: https://www.ricomputermuseum.org/collections-gallery/small-systems-at-ricm/intel-mds-ii-model-230-development-system

The label on the back of the printer says that it was made 7/24/78.

I found the trademark registration for "Ballistic" and a Datamation advertisement for the "200 Series" printers. It is mentioned in the LSi ADM-3A terminal manuals as a companion device. There are also mentions of "300 Series" printers. I am really surprised that there is so little information available on this printer.

[Herb Johnson]

On 11/14/2021 2:01 PM, Michael Thompson wrote:
> I put images of the printer on the MDS-II WWW page
> at: https://www.ricomputermuseum.org/collections-gallery/small-systems-at-ricm/intel-mds-ii-model-230-development-system
> The label on the back of the printer says that it was made 7/24/78.
>
> I found the trademark registration for "Ballistic" and a Datamation
> advertisement for the "200 Series" printers. It is mentioned in the LSi
> ADM-3A terminal manuals as a companion device. There are also mentions
> of "300 Series" printers. I am really surprised that there is so little
> information available on this printer.

I overlooked that "you have the manual" so that's a start. What the
manual says, is another matter; I'll read your scanned manual.

Thanks for the ad and photos on your site. Good quick work. Pardon my
micro-management, but please add to your page (or make a new Web page)
the title "Lear Siegler LSI 200 series Ballistic printer". That's so
Google will find your page when your next benefactor looks for that
item. That's the shortest argument I can provide. Evidence: I find ads
now on Web search of that phrase. March 13 1978 Computerworld; May 1
1978 same. Seems a late date, but I don't know. Please date and identify
the magazine on your Web page.

Regarding ribbons. Looking at the actual ribbon on the actual printer, I
think you will find it matches common 1970's manual typewriter ribbons
down to the spool and certainly the width of the ribbon. YOu can buy
those today at Staples, I believe; certainly elsewhere. At worst you
might have to respool a new ribbon. Observe how the ribbon motion
auto-reverses at the end of the ribbon, thanks to rivets in the ribbon;
that is an informed guess on my part.

Regarding "Centronics": most 21st century Web descriptions of it, insist
that somehow "The IBM PC" "standardized" its use. FALSE! Previous
personal and business computers established it as a peripheral standard;
Centronics and other printing companies established it as a printer
standard. *Then* in 1981, IBM followed suit with its new personal
computer. IBM PC's was a follower-of, not a leader-of. This IBM-centric
false narrative, is one reason why vintage computing owners are obliged
to detail their own histories.

Finally, a personal note. A few years ago, a computer club asked me to
help with a "cleanout" of a personal computing founding engineer's home,
after his passing. I recall coming across, a gigantic blue printer with
a spiral lead-screw and giant print head: now I see it again on the
RICM's Web page. I drew the attention of the leading member of that
club, to the printer now in front of us. His response? To pull out his
smart-phone and tell me "I'm searching ebay". My response was immediate;
I suggested an action anatomically impossible to perform upon a Web
based corporation. They left the printer behind.

I gotta run.

Regards, Herb

[Michael Thompson]

I used IMG2MDS to format and write the floppy image IMG2MDS.IMG on an MDS-800. Everything worked OK.

Format Complete...

Send image file now using XMODEM...

Imaging Complete

#42B0

I tried to boot the floppy image and it said:

ERROR  24 USER PC 40EB

STATUS=   8

D= 0

#320C

[Vale, Martyn]

 

This is a Double Density Drive ? as it won’t do Single Density.

 

From: intel-...@googlegroups.com [mailto:intel-...@googlegroups.com] On Behalf Of Michael Thompson
Sent: 17 November 2021 20:30
To: intel-devsys <intel-...@googlegroups.com>
Subject: {SPAM?} Re: intel-devsys MDS-II Model 230 at the Rhode Island Computer Museum

 

 

I used IMG2MDS to format and write the floppy image IMG2MDS.IMG on an MDS-800. Everything worked OK.

--

You received this message because you are subscribed to the Google Groups "intel-devsys" group.
To unsubscribe from this group and stop receiving emails from it, send an email to intel-devsys...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/intel-devsys/5bbf406c-af39-48ed-8d64-f2945461edf9n%40googlegroups.com.

[Michael Thompson]

It has the iSBC-202 Double-Density Floppy Controller installed.

[Michael Thompson]

It looks like there may be a problem with the CPU board in the MDS-800. It will not stay running after a reset.

[Vale, Martyn]

 

According to the ISIS II Manual

 

24 = DISK ERROR

 

8 = ADDRESS ERROR

 

0 = Disk Drive 0

 

Not much help I guess

 

It might be worth running the confidence tests for the MDS II. Very few of the Tests work on the MDS-800, however the Floppy Test do !

To view this discussion on the web visit https://groups.google.com/d/msgid/intel-devsys/a1a41e1f-d67b-4130-8fce-cef77799be75n%40googlegroups.com.

[Michael Thompson]

We need to fix the second serial port on the MDS-II before we can use the IMG2MDS program.

The MDS-800 is misbehaving too. The program that is came with IMG2MDS is supposed to change the baud rate from 2400 to 19200. It actually changed the baud rate to 9600. We will apply some DeoxIT to the connectors and sockets on the diskette controller to see if that helps.

[Michael Thompson]

OK, I received an email explaining why this is the correct behavior for the serial port baud rate. I have so much to learn...

[Vale, Martyn]

As I guess you’ve already discovered it’s just a division thing on the Baud Rate and mine is based at 4800, hence the difference.

 

I’d recommend soldering in some wire wrap pins in to the monitor board on the MDS-800 and this will make changing baud rate much easier and reduce the risk of damaging the PCB each time you need to alter Baud rate. Unless you have slow serial devices though I think 4800 is a good base. One thing I have discovered though is that the Credit Editor will not work correctly at 19200 Baud as the MDS can’t seem to keep up with the screen updates, so 9600 max on that one.

 

There’s a fair bit of error checking in IMG2MDS, so I’m not sure why it’s not throwing an error, it’s almost as if it’s not fully writing the data. Can either of the systems create a fresh system disk from the working ones you have ? if they can then we may need to investigate further as it would then be very odd if IMG2MDS isn’t working. You can use IDISK command if you have only one working drive.

 

Martyn.

 

From: intel-...@googlegroups.com [mailto:intel-...@googlegroups.com] On Behalf Of Michael Thompson

Sent: 18 November 2021 00:27
To: intel-devsys <intel-...@googlegroups.com>

Subject: {SPAM?} Re: Re: Re: intel-devsys MDS-II Model 230 at the Rhode Island Computer Museum

 

⚠ Caution: External sender

 

To view this discussion on the web visit https://groups.google.com/d/msgid/intel-devsys/b9cc6687-9e07-46ba-be3c-c2b9040ed4c8n%40googlegroups.com.

[Michael Thompson]

Martyn,

Instead of typing in the instructions in BOOT.PRN using the monitor, I created a file containing the monitor commands. I just set the inter-character delay to 500 ms, and sent the file to the console serial port. The G3000 command could be added to the file too. Don't forget to set the delay back to zero, or sending the HEXLOAD.BIN file and others will take forever.

S3000 21 00 20 11 A7 01 DB F7 0F 0F D2 06 30 DB F6 77 23 1B 7A 83 C2 06 30  

I made some notes from watching the video. Using a file with the instructions might be easier than watching the video. It needs to be adjusted a little because the instructions differ for the MDS-800 and the MDS-II.

Remove the keyboard cable

Connect the serial cable to the PC to the "Serial CH 2" connector

Configure the terminal emulator (Tera Term) for 2400,N,8,1

Power on the MDS, press and release the RESET switch

Hit the space bar in the terminal emulator

You should see the "SERIES II MONITOR" banner and a "." prompt

Enter the Bootloader from the BOOT.PRN listing at 0x3000 using the monitor

Enter the "G3000" command to run the Bootloader

Using the File->Send File selection in Tera Term, send the HEXLOAD.BIN file to the MDS, and make sure that binary is checked

You should see the "LOADER 1.2" banner and the "*" prompt

Enter an "H" to start a hexload

Using the File->Send File selection in Tera Term, send the RS232-2.HEX file to the MDS

You should see "1000" and "1010" print and then the "*" prompt

Enter an "H" to start a hexload

Using the File->Send File selection in Tera Term, send the IMG2MDS.HEX file to the MDS

You should see "4000" and a sting of numbers print and then the "*" prompt

Enter an "X" to exit from the hex loader

Enter "G1000" to run the RS232-2.HEX program

Change the Tera Term baud rate to for 19200,N,8,1

If you hit Return you should see a "." prompt

Enter "G4000" to run the IMG2MDS.HEX program

You should see the "IMG2MDS v1.0" banner

Enter 1 or 2 to select the right or left diskette drive

Enter a "Y" or "N" to format the floppy diskette or not

You will now see a prompt to send the image file using XMODEM

Use the Transfer->XMODEM->Send selection in Tera Term

The IMG2MDS program will now write the IMG diskette image to the diskette

[Michael Thompson]

I disconnected the MDS keyboard, then connected an RS-232 breakout box in series with a PC and serial Ch 2 on the MDS-II. I swapped pins 3 & 2 and jumpered pins 4 & 5. After a reset I hit the space bar on the PC, and the MDS monitor prompt showed up on the CRT. Entering return on the PC made no change on the MDS.

[Vale, Martyn]

 

Almost there but not quite then. The MDS is obviously able to transmit, so the jumper is working and it recognised the space bar. Have you turned off hand shaking in your terminal emulator as this could be stopping any further transmission from the PC. I’ve had a few problems with the 8251’s, however I think you have an IPB which has them soldered in so not so easy to swap.

 

Try monitoring RxRDY pin 14 on the 8251 this should pulse on each character received from the terminal, if not then the 8080 is not reading the 8251. Also check TxEMPTY pin 18 this should be high if all characters have been transmitted if not there’s something stuck in the 8251 probably due to a hand shake problem.

 

As I mentioned in the video unfortunately the serial port configuration is set by wire wrapping a set of pins in the corner of the IOC and it’s worth checking yours to make sure all is as it left Intel.

 

Bye

To view this discussion on the web visit https://groups.google.com/d/msgid/intel-devsys/c7080749-104c-45df-a9fe-abd6883c4b9fn%40googlegroups.com.

[Michael Thompson]

Martyn,

With the keyboard disconnected, the serial console works OK on port 0 (CH 1) at 2400 baud, so output 0 of the 8253 and all of the 8251 A62 are working. With the serial console connected to port 1 (CH 2) at 2400 baud, when I enter a space bar I see the monitor prompt on the built-in CRT. This means that output 1 of the 8253 is working and at least the receiver in the 8251 A74 is working. There is no response to anything typed on the serial console after the banner and prompt are displayed.

Having the monitor banner and prompt displayed on the built-in CRT when a space is sent to CH 2 to me looks like a firmware problem where it detected the space on CH 2, but displayed the banner on the CRT instead of sending it to CH 2. This system has Monitor 1.2. Should I make Monitor 1.3 EPROMs and try them?

I looked at the jumpers on the back of the IOC board. They all look like they are in the original factory positions.

[Roger Arrick]

Hi MT and other MDS'ers

These are such typical RS232 port issues. The basic design is too haphazard and has too many options and implementations. I've been working with it since '75 and worked for a communications company 77-80 where we battled RS232 all day every day. I still have one of the old blue breakout boxes of the time which cost $300!

There can be both hardware and software flow control.

The output of the 8251 has a hardware flow control pin that makes the UART busy to the software, so it's no work at all for the software but to check the busy bit like usual.

This hardware flow control on output is bypassed by jumpering 4 and 5 (CTS and RTS) on the RS232 port. Use the breakout box. And make sure you're not getting a competing signal from your terminal.

But sometimes these systems are REwired inside on the PCB right at the driver chips.

There can be software flow control programmed into the I/O handler but I don't ever remembering seeing that on MDS 1 or 2 systems.

Obviously your input works and the baud rate is right
but you don't know if your data width is right (7 or 8)
or stop bit (1 or 2)
or parity (off, even, odd)
It's possible that space bar can get through with some of those wrong.

Maybe the system is somehow configured to send output to CRT and not serial port.
Hardware and logic mapping.
I'd have to pull the books and I'm still in my PJs thinking about Sonic for lunch.

Anyway, you're making great progress and it's great to see another system come back to life.

Cheers yall.

_______________________________________________
Roger Arrick
Ro...@Arrick.com
Tyler, TX

Michael Thompson wrote:
> Martyn,
>
> With the keyboard disconnected, the serial console works OK on port 0
> (CH 1) at 2400 baud, so output 0 of the 8253 and all of the 8251 A62 are
> working. With the serial console connected to port 1 (CH 2) at 2400
> baud, when I enter a space bar I see the monitor prompt on the built-in
> CRT. This means that output 1 of the 8253 is working and at least the
> receiver in the 8251 A74 is working. There is no response to anything
> typed on the serial console after the banner and prompt are displayed.
>
> Having the monitor banner and prompt displayed on the built-in CRT when
> a space is sent to CH 2 to me looks like a firmware problem where it
> detected the space on CH 2, but displayed the banner on the CRT instead
> of sending it to CH 2. This system has Monitor 1.2. Should I make
> Monitor 1.3 EPROMs and try them?
>
> I looked at the jumpers on the back of the IOC board. They all look like
> they are in the original factory positions.

> RICM_MDS-II_IOC-Jumpers.jpg
>
> On Sunday, November 21, 2021 at 6:35:00 AM UTC-5 m.vale wrote:
>

> __ __

>
> Almost there but not quite then. The MDS is obviously able to
> transmit, so the jumper is working and it recognised the space bar.
> Have you turned off hand shaking in your terminal emulator as this
> could be stopping any further transmission from the PC. I’ve had a
> few problems with the 8251’s, however I think you have an IPB which

> has them soldered in so not so easy to swap. ____
>
> __ __

>
> Try monitoring RxRDY pin 14 on the 8251 this should pulse on each
> character received from the terminal, if not then the 8080 is not
> reading the 8251. Also check TxEMPTY pin 18 this should be high if
> all characters have been transmitted if not there’s something stuck

> in the 8251 probably due to a hand shake problem.____
>
> __ __

>
> As I mentioned in the video unfortunately the serial port
> configuration is set by wire wrapping a set of pins in the corner of
> the IOC and it’s worth checking yours to make sure all is as it left

> Intel.____
>
> __ __
>
> Bye____
>
> Martyn. ____
>
> __ __
>
> *From:* intel-...@googlegroups.com
> [mailto:intel-...@googlegroups.com] *On Behalf Of *Michael Thompson
> *Sent:* 20 November 2021 22:13
> *To:* intel-devsys <intel-...@googlegroups.com>
> *Subject:* {SPAM?} Re: intel-devsys MDS-II Model 230 at the Rhode
> Island Computer Museum____
>
> __ __

>
> I disconnected the MDS keyboard, then connected an RS-232 breakout
> box in series with a PC and serial Ch 2 on the MDS-II. I swapped
> pins 3 & 2 and jumpered pins 4 & 5. After a reset I hit the space
> bar on the PC, and the MDS monitor prompt showed up on the CRT.

> Entering return on the PC made no change on the MDS.____

>
> On Friday, November 19, 2021 at 4:22:06 PM UTC-5 Michael Thompson

> wrote:____
>
> Martyn,____
>
> __ __

>
> Instead of typing in the instructions in BOOT.PRN using the
> monitor, I created a file containing the monitor commands. I
> just set the inter-character delay to 500 ms, and sent the file
> to the console serial port. The G3000 command could be added to
> the file too. Don't forget to set the delay back to zero, or

> sending the HEXLOAD.BIN file and others will take forever.____
>
> __ __

>
> S3000 21 00 20 11 A7 01 DB F7 0F 0F D2 06 30 DB F6 77 23 1B 7A

> 83 C2 06 30 ____
>
> __ __

>
> I made some notes from watching the video. Using a file with the
> instructions might be easier than watching the video. It needs
> to be adjusted a little because the instructions differ for the

> MDS-800 and the MDS-II.____
>
> __ __
>
> Remove the keyboard cable____

>
> Connect the serial cable to the PC to the "Serial CH 2"

> connector____
>
> Configure the terminal emulator (Tera Term) for 2400,N,8,1____
>
> Power on the MDS, press and release the RESET switch____
>
> Hit the space bar in the terminal emulator____
>
> You should see the "SERIES II MONITOR" banner and a "." prompt____

>
> Enter the Bootloader from the BOOT.PRN listing at 0x3000 using

> the monitor____
>
> Enter the "G3000" command to run the Bootloader____

>
> Using the File->Send File selection in Tera Term, send the
> HEXLOAD.BIN file to the MDS, and make sure that binary is

> checked____
>
> You should see the "LOADER 1.2" banner and the "*" prompt____
>
> Enter an "H" to start a hexload____

>
> Using the File->Send File selection in Tera Term, send the

> RS232-2.HEX file to the MDS____
>
> You should see "1000" and "1010" print and then the "*" prompt____
>
> Enter an "H" to start a hexload____

>
> Using the File->Send File selection in Tera Term, send the

> IMG2MDS.HEX file to the MDS____

>
> You should see "4000" and a sting of numbers print and then the

> "*" prompt____
>
> Enter an "X" to exit from the hex loader____
>
> Enter "G1000" to run the RS232-2.HEX program____
>
> Change the Tera Term baud rate to for 19200,N,8,1____
>
> If you hit Return you should see a "." prompt____
>
> Enter "G4000" to run the IMG2MDS.HEX program____
>
> You should see the "IMG2MDS v1.0" banner____
>
> Enter 1 or 2 to select the right or left diskette drive____
>
> Enter a "Y" or "N" to format the floppy diskette or not____
>
> You will now see a prompt to send the image file using XMODEM____
>
> Use the Transfer->XMODEM->Send selection in Tera Term____

>
> The IMG2MDS program will now write the IMG diskette image to the

> diskette____
>
> __ __
>
> On Friday, November 19, 2021 at 4:59:33 AM UTC-5 m.vale wrote:____

>
> As I guess you’ve already discovered it’s just a division
> thing on the Baud Rate and mine is based at 4800, hence the

> difference.____
>
> ____

>
> I’d recommend soldering in some wire wrap pins in to the
> monitor board on the MDS-800 and this will make changing
> baud rate much easier and reduce the risk of damaging the
> PCB each time you need to alter Baud rate. Unless you have
> slow serial devices though I think 4800 is a good base. One
> thing I have discovered though is that the Credit Editor
> will not work correctly at 19200 Baud as the MDS can’t seem

> to keep up with the screen updates, so 9600 max on that one.____
>
> ____

>
> There’s a fair bit of error checking in IMG2MDS, so I’m not
> sure why it’s not throwing an error, it’s almost as if it’s
> not fully writing the data. Can either of the systems create
> a fresh system disk from the working ones you have ? if they
> can then we may need to investigate further as it would then
> be very odd if IMG2MDS isn’t working. You can use IDISK

> command if you have only one working drive.____
>
> ____
>
> Martyn.____
>
> ____
>
> *From:* intel-...@googlegroups.com
> [mailto:intel-...@googlegroups.com] *On Behalf Of *Michael
> Thompson____
>
>
> *Sent:* 18 November 2021 00:27
> *To:* intel-devsys <intel-...@googlegroups.com>____
>
> *Subject:* {SPAM?} Re: Re: Re: intel-devsys MDS-II Model 230
> at the Rhode Island Computer Museum____
>
> ____
>
> ⚠ Caution: External sender____
>
> ____

>
> We need to fix the second serial port on the MDS-II before

> we can use the IMG2MDS program. ____
>
> ____

>
> The MDS-800 is misbehaving too. The program that is came
> with IMG2MDS is supposed to change the baud rate from 2400
> to 19200. It actually changed the baud rate to 9600. We will
> apply some DeoxIT to the connectors and sockets on the

> diskette controller to see if that helps.____

>
> On Wednesday, November 17, 2021 at 4:24:27 PM UTC-5 m.vale

> wrote:____
>
> ____
>
> According to the ISIS II Manual____
>
> ____
>
> 24 = DISK ERROR____
>
> ____
>
> 8 = ADDRESS ERROR____
>
> ____
>
> 0 = Disk Drive 0____
>
> ____
>
> Not much help I guess____
>
> ____

>
> It might be worth running the confidence tests for the
> MDS II. Very few of the Tests work on the MDS-800,

> however the Floppy Test do !____
>
> ____
>
> ____
>
> *From:* intel-...@googlegroups.com
> [mailto:intel-...@googlegroups.com] *On Behalf Of
> *Michael Thompson
> *Sent:* 17 November 2021 21:11
> *To:* intel-devsys <intel-...@googlegroups.com>
> *Subject:* Re: Re: intel-devsys MDS-II Model 230 at the
> Rhode Island Computer Museum____
>
> ____
>
> ____

>
> It has the iSBC-202 Double-Density Floppy Controller

> installed.____

>
> On Wednesday, November 17, 2021 at 3:37:53 PM UTC-5

> m.vale wrote:____
>
> ____

>
> This is a Double Density Drive ? as it won’t do

> Single Density.____
>
> ____
>
> *From:* intel-...@googlegroups.com
> [mailto:intel-...@googlegroups.com] *On Behalf Of
> *Michael Thompson
> *Sent:* 17 November 2021 20:30
> *To:* intel-devsys <intel-...@googlegroups.com>
> *Subject:* {SPAM?} Re: intel-devsys MDS-II Model 230
> at the Rhode Island Computer Museum____
>
> ____
>
> ____

>
> I used IMG2MDS to format and write the floppy image

> IMG2MDS.IMG on an MDS-800. Everything worked OK. ____
>
> ____
>
> Format Complete...____
>
> Send image file now using XMODEM...____
>
> Imaging Complete____
>
> #42B0____
>
> ____
>
> I tried to boot the floppy image and it said:____
>
> ____
>
> ERROR 24 USER PC 40EB____
>
> STATUS= 8____
>
> D= 0____
>
> #320C____
>
> ____

>
> On Sunday, November 14, 2021 at 3:46:38 PM UTC-5

> hjohnson wrote:____

>
> On 11/14/2021 2:01 PM, Michael Thompson wrote:
> > I put images of the printer on the MDS-II WWW
> page
> >
> at: https://www.ricomputermuseum.org/collections-gallery/small-systems-at-ricm/intel-mds-ii-model-230-development-system

> <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ricomputermuseum.org%2Fcollections-gallery%2Fsmall-systems-at-ricm%2Fintel-mds-ii-model-230-development-system&data=04%7C01%7Cm.vale%40ucl.ac.uk%7C2b325bc14ce64967161108d9ac72f917%7C1faf88fea9984c5b93c9210a11d9a5c2%7C0%7C0%7C637730433012532990%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=a5dTVwZUtLBq0xsZ%2Bn30huvctT09%2BRhDp5ehCZs72D4%3D&reserved=0>

> <https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.retrotechnology.com%2F&data=04%7C01%7Cm.vale%40ucl.ac.uk%7C2b325bc14ce64967161108d9ac72f917%7C1faf88fea9984c5b93c9210a11d9a5c2%7C0%7C0%7C637730433012542947%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=fABcvv2qeFNfml36qsBjdi%2FepFsrsCOk1z0fhXPh7sw%3D&reserved=0>

> OR .net
> preserve, recover, restore 1970's computing
> email: hjohnson AT retrotechnology DOT com

> or try later herbjohnson AT comcast DOT net ____
>
> -- ____

>
> You received this message because you are subscribed
> to the Google Groups "intel-devsys" group.
> To unsubscribe from this group and stop receiving
> emails from it, send an email to

> intel-devsys...@googlegroups.com.____

>
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/intel-devsys/5bbf406c-af39-48ed-8d64-f2945461edf9n%40googlegroups.com

> <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgroups.google.com%2Fd%2Fmsgid%2Fintel-devsys%2F5bbf406c-af39-48ed-8d64-f2945461edf9n%2540googlegroups.com%3Futm_medium%3Demail%26utm_source%3Dfooter&data=04%7C01%7Cm.vale%40ucl.ac.uk%7C2b325bc14ce64967161108d9ac72f917%7C1faf88fea9984c5b93c9210a11d9a5c2%7C0%7C0%7C637730433012542947%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=Kgba%2BQNzQVOzNCl51g209SaWzQgIcv%2FaWw5R1mvQuUY%3D&reserved=0>.____

>
> --
> You received this message because you are subscribed to
> the Google Groups "intel-devsys" group.
> To unsubscribe from this group and stop receiving emails
> from it, send an email to

> intel-devsys...@googlegroups.com.____

>
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/intel-devsys/a1a41e1f-d67b-4130-8fce-cef77799be75n%40googlegroups.com
> <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgroups.google.com%2Fd%2Fmsgid%2Fintel-devsys%2Fa1a41e1f-d67b-4130-8fce-cef77799be75n%2540googlegroups.com%3Futm_medium%3Demail%26utm_source%3Dfooter&data=04%7C01%7Cm.vale%40ucl.ac.uk%7C2b325bc14ce64967161108d9ac72f917%7C1faf88fea9984c5b93c9210a11d9a5c2%7C0%7C0%7C637730433012552900%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=2B2%2FtZxZiaIh9bq9oFzAWxvTacK6DGZDZstlTqV4fAQ%3D&reserved=0>.____

>
> --
> You received this message because you are subscribed to the
> Google Groups "intel-devsys" group.
> To unsubscribe from this group and stop receiving emails

> from it, send an email to intel-devsys...@googlegroups.com.____

>
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/intel-devsys/b9cc6687-9e07-46ba-be3c-c2b9040ed4c8n%40googlegroups.com
> <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgroups.google.com%2Fd%2Fmsgid%2Fintel-devsys%2Fb9cc6687-9e07-46ba-be3c-c2b9040ed4c8n%2540googlegroups.com%3Futm_medium%3Demail%26utm_source%3Dfooter&data=04%7C01%7Cm.vale%40ucl.ac.uk%7C2b325bc14ce64967161108d9ac72f917%7C1faf88fea9984c5b93c9210a11d9a5c2%7C0%7C0%7C637730433012552900%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=q%2BKWKixjRO6qFHWFsiE1k93macCqZTVwAbfKBZqLo6g%3D&reserved=0>.____

>
> --
> You received this message because you are subscribed to the Google
> Groups "intel-devsys" group.
> To unsubscribe from this group and stop receiving emails from it,
> send an email to intel-devsys...@googlegroups.com.
>
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/intel-devsys/c7080749-104c-45df-a9fe-abd6883c4b9fn%40googlegroups.com
> <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgroups.google.com%2Fd%2Fmsgid%2Fintel-devsys%2Fc7080749-104c-45df-a9fe-abd6883c4b9fn%2540googlegroups.com%3Futm_medium%3Demail%26utm_source%3Dfooter&data=04%7C01%7Cm.vale%40ucl.ac.uk%7C2b325bc14ce64967161108d9ac72f917%7C1faf88fea9984c5b93c9210a11d9a5c2%7C0%7C0%7C637730433012552900%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=JLx7OwaWgRSwEs3Ickx05FLiIYhem8j%2BWz%2F2Y45ly7Q%3D&reserved=0>.____

>
> --
> You received this message because you are subscribed to the Google
> Groups "intel-devsys" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to intel-devsys...@googlegroups.com

> <mailto:intel-devsys...@googlegroups.com>.

> To view this discussion on the web visit

> https://groups.google.com/d/msgid/intel-devsys/317cb7eb-6707-4b8a-9eed-37a08a2cb346n%40googlegroups.com
> <https://groups.google.com/d/msgid/intel-devsys/317cb7eb-6707-4b8a-9eed-37a08a2cb346n%40googlegroups.com?utm_medium=email&utm_source=footer>.
>
> ------------------------------------------------------------------------
>

[Vale, Martyn]

Ah, sorry I misunderstood your original post !

 

Looking at Bill’s disassembly of V1.2 and V1.3 there is some extra code after the space bar press is determined which is then stored in a status pointer in memory, the V1.2 code seems to have this missing at a quick glance.

 

If you can produce some V1.3 Rom’s it definitely worth a try something is definitely wrong there. Might even be worth writing some simple code to write a message to serial 2 and see what comes out. I don’t think there’s any way to redirect in the monitor as you can in the MDS-800, since the inbuilt CRT and Serial 2 share the same device name it’s just a case of which is enabled at the time.

To view this discussion on the web visit https://groups.google.com/d/msgid/intel-devsys/317cb7eb-6707-4b8a-9eed-37a08a2cb346n%40googlegroups.com.

[Michael Thompson]

I have the mdsIIv13b.7z collection of 1.3 Monitor files. Should I program just the monitor EPROM monIIv13.hex or monIIv13.rom? Do I need to upgrade the Boot/Diag EPROM at the same time?