Hi everyone,
I'm looking for the images of ROMs installed on the IOC (I/O controller)
board of Intel MDS-2 development systems. In particular I'm looking for
the content of the character generator ROM (A19-2708) and of firmware
ROMs (A50 to A53-4x2716). So far I had no success in googling them.
My goal would be to contribute a good emulation of MDS systems to MESS,
especially for what regards the look of the video terminal. Well, this
is the plan, when "real-life" is not inteferring too much...
Thanks a lot.
-- F.Ulivi
Hi all,
I?ve been struggling getting a 64k Dynamic RAM card back up and working in my IMSAI 8080. In fact I?m giving up on the DRAM card in this system and have decided to start looking for a SRAM card that can get the IMSAI up to 56k.
In terms if SRAM cards, I presently have:
2 x Problem solver RAM16 cards - both seem to be working.
2 x 8K RAM cards - both seem to be working.
Less cards generating heat, and putting stress on the old power supply is obviously best, so I?d be looking for either:
- 1 x 16k SRAM card (for a total of 4 RAM cards (3 x 16k + 1 x 8k) in my system). A PSS RAM16 would be preferred for sake of consistency, but obviously not crucial.
- 1 x 32k SRAM card (for a total of 3 RAM cards (1 x 32k, 1 x 16k + 1 x 8k) in my system)
- 1 x 64k SRAM card that can have the last 8k bank turned off
I would love to hear from anyone with one of the above cards who would be willing to pass it on.
Much thanks for your time.
Best regards
Philip
----- Original Message -----
> Date: Sun, 22 May 2011 22:56:32 -0500
> From: Daniel Seagraves <dseagrav at lunar-tokyo.net>
> Subject: Re: Scraping DEC Equipment
> To: "General Discussion: On-Topic and Off-Topic Posts"
> <cctalk at classiccmp.org>
> Message-ID: <C7A98127-DFF4-41B1-A6AF-5DFCA234D286 at lunar-tokyo.net>
> Content-Type: text/plain; charset=us-ascii
>
> I need a tractor feed assembly for a LA100, are the ones on the 120
> compatible?
----- Reply:
Apparently not, but I might have one for an LA100.
mike
I would like to get a Tek 4404 computer going but lack any service
manuals. The system turns on but has no curser on the screen. Has
good power from the Power supply and heater is on in the CRT.
Has a row of LEDs on the mother board. Does anyone know how
to read these.
- Thanks, Jerry
On 7 May 2010, at 08:25, cctalk-request at classiccmp.org wrote:
>
> Message: 2
> Date: Thu, 06 May 2010 16:06:37 -0700
> From: Al Kossow <aek at bitsavers.org>
> Subject: Re: Servant .953
> To: cctalk at classiccmp.org
> Message-ID: <4BE34B7D.6060902 at bitsavers.org>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> On 5/6/10 2:23 PM, Fred Cisin wrote:
>>> Al Kossow wrote:
>>>> I am interviewing Andy Hertzfeld tomorrow, and had hoped to talk about
>>>> Servant, but I can't find a copy of it around anywhere tonight.
>
> A huge thank you to Nigel Williams who forwarded a working copy of .951 five
> minutes before Bill and Andy arrived. We spent an hour talking about MacPaint
> and Quickdraw (Apple has finally given CHM approval to make the sources available)
> then another hour on Alice, Dali Clock, Servant, Hypercard, and Magic Cap.
Could you please clarify, the QuickDraw source is available for what purpose? Could developers modify it any include it in heir commercial 64 bit Intel applications for instance?
Is the source Pascal, Assembler, C or something else?
Roger Holmes,
Director of Microspot who has a Carbon application which compiles with over 10,000 warnings about deprecated QuickDraw calls.
The revival process of the 11/750 continues. The power supplies is working
good and then I started testing the actual machine. But that was not a very
smooth journey to success. I have in total at least three complete CPU
board sets and just after quite a lot of board swapping it got running (I
think).
I had error like:
* Bright red error light
* No response at all on the console
* %C microverify error
* %O microverify error
* An hexdump prompt which non like above bot still not correct.
* etc
Finally I had the
%% which meant that it passed microverify.
Then I used the (second) RDM module (the first one had RAM error) to run
the DPM and MIC test which passed.
The I ran the "Hardcore VAX instruction test" / TU58#7 which also passed
fine.
BUT the Cache / TB diag, TU58#5, give me this:
%%
00000000 16
>>>B
%%
@?ECKAL -- VAX 11/750 Cache/TB Diagnostic
00003488 06
>>>
I am running a BE-S198Q-DE tape image.
Anyone has a listing or description for the ECKAL diagnostic? Is there any
know incompatibilities with certain revisions of boards? Or known bugs?
The machine manage to boot the console tape so I get the BOOT58> prompt.
But I am not sure if that indicate that it is indeed working or not.
So, some help with the Cache/TB diagnostic would be very much appreciated.
/Mattis
When Multics was officially released as free software a couple of
years ago, there was a flurry of activity aimed at getting some sort
of emulator up and running to run it. Did anything ever come of that
or did folks just lose interest (or find out that the needed
GE/Honeywell hardware was too poorly-documented to write an emulator
of)
Mike
> From: Jacob Ritorto
> Would you happen to have notes or references about how to do it?
It's not too hard; basically, one has to wire pins BC1, BD1, BE1 and BF1
(BDAL 18-BDAL21, respectively) on all _QBUS_ slots together into a bus. So
wire BC1 on slot 1 to BC1 on slot 2, slot 3, etc, etc.
A couple of notes: First, I said '_QBUS_' because if you have a Q/CD
backplane, clearly one doesn't run the extra BDAL lines to the CD slots, only
the QBUS slots (which run down the left-hand side, when facing the backplane).
Second, for optimal analog behaviour, the 'out' slot on the backplane should
be the last slot you wire to, so that there are no branches in the
transmission line for BDAL18-BDAL21 (which can produce reflections - aka
noise - on the transmission lines). How to do this efficiently (in terms of
the wiring) can be a bit tricky, depending on the backplane configuration.
E.g. if one has the standard 'serpentine' backplane, i.e. one with the slots
in the following kind of order (facing the backplane from the board side):
1-2
4-3
5-6
8-7
9-10
etc., one might naively think one has to run the extra bus lines back and
forth to match. However, only the _grant_ lines have to follow this pattern
(and they are already there); the added lines don't have to follow the same
pattern, as long as there are no branches.
So, for the example 5-slot backplane above, one could/would wire:
1-4-5-8-9--2-3-6-7-10
i.e. a single vertical run on the left hand side, a single diagonal from 9
back to 2 (shown with "--"), and then another vertical run on the right hand
side. Much simpler than wiring back and forth in slot order; there are no
branches; and the last slot is the 'out' slot.
For backplane with an _even_ number of layers, e.g.:
1-2
4-3
5-6
8-7
it's a little more complicated: a single vertical run on each side
cannot be connected in such a way as to have the 'out' slot (8) be the
last slot. One has to do something a little more complex:
1-4-5--2-3-6-7--8
with a vertical run on the left side, stopping short of the last slot; then
a vertical run on the right side, then a lateral back across on the last
layer.
Obviously one _could_ run the wires back and forth, in slot order, but that
will take a lot more wire, which at the very least is more work (especially
on backplanes which don't have full wire-wrap pins, just the little stubby
pins that have to have the wires soldered to); whether it also increases the
delay down those transmission lines enough to be noticeable is something I
don't know the answer to.
All the obvious caveats apply: make sure not to get confused by the mirror
pin and slot numbers on the front and back sides (you'll be wiring on the
back, whereas the diagrams above are on the front), etc.
Noel
Exciting stuff for a Friday night, right? Here's a visual aid in case
you're needing further inspiration:
https://www.instagram.com/p/_K-zHhHvLn78Qu5ijWqMf-HBem1LKMLaEdI1c0/ The
M2333K is the smaller one on the left with the green and yellow lights on.
I'm booting from rl0, which contains the tuhs 2.9.1 rl02 image I wrote with
vtserver earlier.
I want to use my nice, roomy smd disk so I can pull in all the sources and
recompile stuff and I've managed to get this *so* close to working but I'm
getting
xp0a: hard error bn xxxx cs2=1100 <MXF, IR> er1=0
on every single block when I try to mkfs /dev/xp0a 4800
This disk was working fine years ago via MSCP attached to the 11/73 (before
I lost the Micro/11 power supply).
Anyway, I referred to
http://bitsavers.trailing-edge.com/pdf/emulex/SC2151001-CC_SC21tech_Jan87.p…
to set the emulation on the Emulex card for two rm03s and they're showing
up in xxdp's zrmlb1 formatter, though they won't format there, screensful
of errors.
I think I set the m2333k to 32 sectors, per this manual:
http://manx.classiccmp.org/collections/antonio/chrisq/B03P-4760-0101A_-_M23…
Because XXDP is reputed to be really strict, I figured that was normal and
then tried the Emulex on-board formatting procedure against both xp0 and
xp4 and they formatted perfectly without error. Guess the Emulex on-board
stuff doesn't bother verifying much?
So I think that maybe I've misunderstood the hard sectoring / sector sizing
thing. Does anyone remember the gist of it and would you be able to
describe? Do you see any other mistakes?
thx
jake
