>But if you want an IDE interface for the S100 bus that will work with
>just about any IDE drive that you throw at it, then you should only
>depend on whatever features are required for the drive to work in a
>normal PC. Because you can bet that some drive (or most drives!) won't
>implement anything else.
I'd agree from my experience. I'd add the 2.5" drive are less likely too.
>> willing to believe that the interface will not assert IOCS16- if the
drive's
>> interface is programmed to operate in 8-bit mode. I would expect that if
I
>
>The term 'interface' is ambiguous here. IOCS16/ is asserted by the drive,
>not by the bus adapter card.
True! I built the interface on the assumption it would be asserted to
save logic.
>The bus adapter simply buffers the signal (most of the time) and sends it
>to the ISA slot. In particular, note that the address decoder logic on
>the bus adapter is not what asserts IOCS16/
Correct, those assert CS lines.
>AFAIK, a standard IDE drive only asserts IOCS16/ for accesses to the data
>register. Not for accesses to any of the control/status registers. Which
>means all of those are seen as 8-bit registers.
Yep. That mas a 8<>16 adaptor simpler as it's only reads and writes to one
address that need folding.
>> MSI-implemented IDE channels don't have the means to operate in that
mode.
>
>See above. The bus adapter should do the right thing provided the drive
>asserts IOCS16/ at the right time. The TTL bus adapter cards are just a
>couple of buffers and an address decoder (normally a PAL, but it doesn't
>have to be).
Actually this is only important to obscure hardware as the software knows
a data register read/write is 16bit (word) and that all other registers are
byte.
I think the idea was that IOCS16 was to notify byte oriented logic to handle
the 16bit transfer (ISA-8).
Allison
>
>-tony
>
> > I can't help with your question, but you may want to post it on
> >comp.sys.ibm.ps2.hardware....
>
>Yes, that was going to be my next move....as you say they're VERY helpful
>over there!!
Heres a PS2/50z question.
Mine only has 1meg, looks like 72pin simm but none I have seem work.
All of them happen to be 8x32 (16chip).
There is only one SIMM socket. What is the limit for ram (max)?
Where can I get something bigger than 1mb?
As my internal network progresses this box has value as I have a SMC 10bt
NIC for it. I figure OS/2 warp V3 or Win3.1 would be a good os for it.
Being 286 there are few unix based OSs with a networking that run well on
it.
That and its just too silly not to.
Allison
[For those that don't read acquisition reports, there's a parts search
request at the bottom!]
Whee, what a pleasant week or so it's been. :-) Found a local guy
selling a mono NeXT slab about a week ago -- I've been meaning to pick
up one of these for *years* but never really got around to it. So I
pick it up, and it's got an N4000A monitor. Now, for those that don't
know NeXT, the phosphor in the 4000s and 4000As is relatively
low-life. Like any Unix machine, NeXTs tended to be left turned on,
and there was no way to turn the display off when the machine was on
(power being supplied through the monitor cable). So, the displays by
now tend to be quite dim. So, the seller pulls it out of the closet
and it's under about half an inch of dust. He apologizes for the
condition, and explains that a local university bought it but only
used it three months before putting it in storage, and he bought it
>from the university for a ridiculously low price but never used it
himself. So, with the dust out of the way, I find myself with what is
basically a brand-new NeXTstation! Were that not enough, it was a
*steal*, and then as I was leaving, the seller goes "Oh, I should give
you the documentation" and comes out with a NEXTSTEP Academic Bundle
(with Developer and Mathematica) and a documentation library.
So then today, a week later, I stop by my old faculty to pick up a Sun
386i that they were about to throw out ("Hey, better I decide to get
rid of it than you", I say). I'm carting the machine out the door
(alas, stripped of disks) and one of the technicians goes "You know, I
think we have some documentation for that". There was too much for me
to take; by the time we finished going through the storage room I'd
found the original 19" mono display, a full documentation set, the
system's purchase orders and maintenance history ($3500 for a 300mb
disk, anyone?), an expansion cabinet, and two boxes of looseleaf Sun
documentation about a foot square each, labeled "Owner's Supplement"
(but containing all sorts of hardware docs for sun-3, -4, and 386i)
and "Toolkit Documentation Set" (which appeared to be the equivalent
for software and drivers) and two bags of disks and tapes. All free!
So I still need to pick up a keyboard, which should be easy; but I'm
having a hard time tracking down the Y-cable for the 386i that goes
between the framebuffer card and the monitor and keyboard. It's a
501-1244 mono hi-res framebuffer and a 540-1062 monitor; anyone know
of a source for these cables?
-Rich
--
------------------------------ Rich Lafferty ---------------------------
Sysadmin/Programmer, Instructional and Information Technology Services
Concordia University, Montreal, QC (514) 848-7625
------------------------- rich(a)alcor.concordia.ca ----------------------
>I wonder why we never had access to this stuff at work, I'm sure it
would've
>been of some help.
only if you could find what you sought. ;-P
>Yes, I'd be using NT4 myself except that I cannot run DVE (Vectrex
emulator)
>under it. I haven't tried it under Win2K Professional yet, but I'm none too
>hopeful.
I'm running NT4ws and things I was told would not run seems to work fine!
Even Gcadd6.1 (a PITA even under dos) runs smoothly. Then again I'm not
running AGP video (using a PCI 2mb S3 board).
>One thing I will say about Win2K is that it seems to be far more stable
than
>any other M$ OS on my hardware thus far. NT4 was giving me memory faults
>when running OE5, Win95 is flaky at best and Win98 wouldn't run for more
>than 4 or 5 minutes without "freezing" up completely. Sigh.
Well, there is a message there.
Memory faults??? doesn't this sugggest something to you? I'd start with the
hardware setup. You may have bad ram, some device that is abusing the
bus. or just maybe something is misconfigured. FYI there is a patch for W95
if your using a AMDk6-2/300 or faster (timing race condition in w95 breaks).
That was after I fofund the board didn't want to run PC100 but did run PC66
as stable.
That is an example of what subtle things can screw a system up. While I
don't love w95 I have 40 clients running it and for the most part one burp a
week among them all is the common thing and often reboot solves that. I've
found office97 to be more troublesome. Then again, we don't run games and we
dont run IE5.0 for obvious reasons. I'd look at that system for problems
that make it unstable. Video drivers are commonly a problem, and some sound
drivers are painful. the worst problem we have are things like ODBC drivers
that leak, solution is a once perday stop/restart of Coldfusion on the NT
server. Over the last year I've spent a lot of time debunking the
rebilability myth and NT3.51 can be stable and so can W95. The work was
finding all those gremlin apps, drivers and some hardware that didn't work.
Then installing W95 correctly in some cases. MS code is not as robust as
I'd like but if it falls over too often then you have a different problem.
W95 is at least three versions with OSR2.1 (aka 95c) being the latest W95
and win 98 is really 95 with bug fixes and enhancements and currently OSR2
is the latest. W98 is more stable than 95 and has some debugging functions
to help. Upgrades are available, W98 OSR2 is free for download if you have
W98! NT4 is really improved 3.51, same deal, more stable ONLY if SP4
or later is installed. However bad apps and bad hardware will get you even
with Linux, faster as it uses hardware harder! Start with good hardware.
I'm not a MS lover, though it makes me a living now. I have foudn one thing
that was true when I was hacking PDP-8s and later 8080s.
Don't blame the cow for soggy cereal.
Allison
> > There is only one SIMM socket. What is the limit for ram (max)?
> >Where can I get something bigger than 1mb?
>
>Interesting, my Model 50 has a pair of SIMM sockets on the planar. They
look
>more like 30-pin SIMMs than 72-pin ones, but I haven't taken them out to
>check yet. Also, I've never seen SIMMs like these before - the PCB is a
>brown/beige colour, and the RAM chips are in small silver "cans" rather
than
>the usual black epoxy.
Ok, there are two merged messages there to start with.
Also there are two versions of the PS/2M50 one is like yours and uses two
simms. the other is like mine a 50Z that uses one. the 50z is also 286
powered but was designed for no memory wait states. It's a tiny bit faster.
At onepoint I had working examples of both, I kept the 50Z and geve the
other away.
>Anyway, I suspect you'll find that the limit for RAM (on the
>motherboard/planar/whateveryouwanttocallit) will be 2Mb. IBM used to make
>these wierd, double sided, 2Mb 72-pin SIMMs specifically for some models in
>the PS/2 family.
Thats what some one else already said.
>I remember these SIMMs distinctly since around 10 years ago they used to
>sell for practically nothing on FidoNet as they were of no use whatsoever
in
>anything but a PS/2.
Figures.
Allison
>Any idea where I can find one of these IBM ESDI drives, the one from my
>Model 50 is missing and I want to restore the machine to it's original
>configuration?
If its mod 50 then not EDSI but RLL or MFM. I have one of the MFM ones
with a few bad blocks.
Allison
>The coding, unfortunately, is not similar enough to the 1003-wah to make
the
>code directly portable, but there are simply more registers in the IDE.
The only additional register is the FDC control hence the second CS.
I used the 1003spec as I had that for writing code as it was more complete.
>from what I could see for drives that were smaller than 500mb the two are
identical. for larger dirves that could be different (things like LBA and
all).
Allison
On Apr 17, 18:06, Nick Oliviero wrote:
> Jeffrey l Kaneko wrote:
>
> > BTW-- Are RL02's a maintainance nightmare? Do the advantages
> > of these drives outweigh the problems (not to mention their *size*,
> > or are they simply not worth it?
>
> I'll second Tony's comments re:maintenance&alignment. We've had two
> RL01's running on a 11/23 since 1980 and one RL02 on a 11/45 since
> 1991 and I can recall just one head crash in all that time. I'm no longer
> on the maintenance side, but I don't believe anyones changed the filters
> in the last 5 years. (I am not recommending this aproach)
Same sort of story with my pair of RL02s; they're not really in continuous
use, though they were for about 4-5 years, haven't had a filter change in
ten years, and they live in the garage. The only real incident was when a
spider decided that nice warm drive was a good place to live, made its home
amongst the heads, and came to a sticky end when the drive was spun up.
--
Pete Peter Turnbull
Dept. of Computer Science
University of York
On Apr 17, 22:09, Peter Pachla wrote:
> >> It's a nice machine, but of little use with nothing but the OS
> >>installed. :-(
>
> > True :-) I've possibly got things that you might have a use for. It
> >depends on what you're interested, obviously. What would you like to
do?
>
> Initially, the main things I'm interested in are learning about the
system
> architecture and getting an assembler for it so I can try out ARM
assembly
> language.
Ah, well I might have an assembler somewhere -- there were two flavours:
one produced executable object code directly (I think) and the other
produced object modules which could be linked with modules produced by
high-level languages such as C, Fortran, and Pascal. I'm sure some of the
remaining Acorn web and/or FTP sites, like Stuttgart or HENSA, still have
instruction set lists.
But you don't even need that to get going -- BBC BASIC V contains a
reasonable 2-pass ARM assembler. It works just like the 6502 assembler in
BBC BASIC II (et al). Here's a sample so you seen what I mean (don't ask
me exactly how it works, it's intimatley bound up with the interactions
between the desktop palette, the OS palette, and the hardware palette, and
anyway I wrote this 12 years ago :-)):
REM part of palette control program for RISC OS 2.0
DIM code% 408
PROCassemble
REM main program loop here
REM followed by several other procedures/functions
DEF PROCsupremacy
CALL getpal : REM read actual colour mapping
D%=colour% : REM R3=colour%
H%=windowhandle% : REM R7=windowhandle%
CALL do_sup
ENDPROC
DEF PROCassemble
LOCAL cnt,sup,bm,sptr,vptr,val,ptr,ccol,sp,link,pass%
ptr=1 : ccol=3 : cnt=6 : sp=13 : link=14 : REM windowhandle passed in
R7
sup=10 : bm=4 : sptr=5 : vptr=8 : val=9 : REM arbitrary register
choice
log=0 : phys=1 : bpp=4 : wptr=5 : tmp=9
FOR pass%=0 TO 2 STEP 2
P%=code%
[ OPT pass%
.do_sup STMFD (sp)!, {link}
ADR sptr, supremacy% ; set up pointers
ADR vptr, vpalette%
LDR sup, [sptr] ; get supremacy word
MOV bm, #&80 ; supremacy bit mask
MOV R0, #12 ; for OSWORD 12
; In case of moving from 16-colour mode to 256-colour mode,
; we need all the clrs separate from all the sets - because
; several colours may share one physical palette register
ADD ptr, vptr, #95 ; ptr to last vpalette entry
MOV cnt, #19 ; counter
.clr TST sup, bm, LSL cnt ; s-bit for this palette entry
LDRB val, [ptr, #1]
AND val, val, #&7F
STRB val, [ptr, #1]
SWI "OS_Word"
SUB ptr, ptr, #5
SUBS cnt, cnt, #1
BPL clr
; Do sets after clrs to ensure that if any colour in a group
; is set, all will be. If we did set/clr together, might
; finish a group with a clear.
ADD ptr, vptr, #95 ; ptr to last vpalette entry
MOV cnt, #19 ; counter
.set TST bm, sup, LSR cnt ; s-bit for this palette entry
LDRNEB val, [ptr, #1]
ORRNE val, val, #&80
STRNEB val, [ptr, #1]
SWINE "OS_Word"
.next SUB ptr, ptr, #5
SUBS cnt, cnt, #1
BPL set
; If there is a current colour, and it should be clear, then
; we need to clear it explicitly in case it's been set as part
; of a group which is set
TST ccol, ccol ; see if there IS a current colour
BMI newsup
ADD ptr, ccol, ccol, ASL#2 ; if so, point to vpalette%+ccol*5
ADD ptr, ptr, vptr
LDRB val, [ptr, #1] ; get logical colour
ORR val, val, #&80
TST sup, bm, LSL ccol ; should it be set ?
ANDEQ val, val, #&7F ; clear supremacy if not
STRB val, [ptr, #1]
SWI "OS_Word"
; now we re-get supremacy in case of interactions above
.newsup ADD vptr, vptr, #95 ; ptr to final vpalette entry
MOV cnt, #19 ; counter
MOV val, #0
.nsloop LDRB R0, [vptr] ; logical colour
LDRB R1, [vptr, #1] ; supremacy+programming info
AND R1, R1, #&7F ; just programming info
SWI "OS_ReadPalette"
AND R2, R2, #&80 ; return just supremacy
ADD val, R2, val, LSL#1 ; shift into new supremacy word
AND R0, bm, sup, LSR cnt ; corresponding bit in old word
TEQ R0, R2 ; see if same
BLNE toggle
SUB vptr, vptr, #5
SUBS cnt, cnt, #1
BPL nsloop
STR val, [sptr]
LDMFD (sp)!, {PC} ; pop PC to return
.toggle ADR R1, wimp%+1024
SUB R1, R1, #1024
STR R7, [R1] ; wimp%!0=windowhandle%
STR cnt, [R1, #4] ; wimp%!4=icon% or cnt (ie R6)
CMP cnt, #16
MOVLT R11, #&00000005 ; depending on which icon,
MOVGE R11, #&77000000 ; change different things
STR R11, [R1, #8] ; wimp%!8=icon flags EOR word
MOV R11, #0
STR R11, [R1, #12] ; wimp%!12=icon flags clear word
SWI "Wimp_SetIconState"
MOVS pc, link
.getpal MVN R0, #0 ; get bits-per-pixel for mode#-1
MOV R1, #9
SWI "OS_ReadModeVariable"
MOV bpp, R2 ; save Log2BPP
ADR wptr, wpalette%
MOV R1, wptr
SWI "Wimp_ReadPalette" ; get wimp palette mappings
ADR vptr, vpalette%
ADD vptr, vptr, #95
MOV cnt, #19
.pal CMP cnt, #16
LDRMIB log, [wptr, cnt, LSL#2] ; get colour programming info
ANDPL log, cnt, #7 ; for 16-19, log=cnt MOD 16
MOVMI phys, #16
MOVEQ phys, #24
MOVHI phys, #25
BPL lc_ok
CMP bpp, #3 ; if 256 colours, GCOL => LogColNo
ANDEQ tmp, log, #&40
ANDEQ log, log, #7
ADDEQ log, log, tmp, LSR#3
.lc_ok STRB log, [vptr]
SWI "OS_ReadPalette"
BIC R2, R2, #&1F ; correct physical colour
ADD R2, R2, phys
MOV tmp, #3
.byte STRB R2, [vptr, #1]! ; save RGB, prog info, supremacy
MOV R2, R2, LSR#8
SUBS tmp, tmp, #1
BPL byte
SUB vptr, vptr, #9
SUBS cnt, cnt, #1
BPL pal
MOV pc, link
; claims upcall to permit OS_ChangeDynamicArea
; as it does no checking, it must only be enabled immediately prior
; to calling OS_ChangeDynamicArea, and disabled immediately
thereafter
.upcall MOV R0, #0
LDMFD R13!, {PC}
]
NEXT pass%
ENDPROC
--
Pete Peter Turnbull
Dept. of Computer Science
University of York
On Mon, 17 Apr 2000 12:35:56 -0400 (EDT) allisonp(a)world.std.com writes:
> > Has anybody ever ripped the Low Level formatter
> > from the XXDP+ diskpack and put the needed components
> > onto a floppy (of some sort)?
> >
> > I'm contemplating attempting to do this myself,
> > but in case it's been done already, I'd just as
> > soon as not re-invent the wheel.
>
> It's doable. You need to create a bootable XXDP disk and copy the
> required formatter to it. not much more than that required.
I figured as much; I was just probing to see if anyone had already
done it.
BTW-- Are RL02's a maintainance nightmare? Do the advantages
of these drives outweigh the problems (not to mention their *size*,
or are they simply not worth it?
Jeff
________________________________________________________________
YOU'RE PAYING TOO MUCH FOR THE INTERNET!
Juno now offers FREE Internet Access!
Try it today - there's no risk! For your FREE software, visit:
http://dl.www.juno.com/get/tagj.
