Out of curiousity what are people on the lists experiences in dealing with
4mm and 8mm tapes? The 4mm tapes are about 12-13 years old and the 8mm 8-13
years old.
I've managed to keep a good selection of tape drives around, so we should
hopefully have drives (though cleaning tapes are a different matter). We
don't know what model DDS drive the 4mm tapes were written in, however, we do
have DDS3 and maybe DDS4 drives from RS/6k's, and are hoping they'll be able
to handle any funky formating issues. Interesting, someone here just came
up with the name "AP Unix" as a possible maker of the 4mm drives used back
then.
Zane
>
>Subject: Re: Floppy controller questions
> From: "Dwight K. Elvey" <dwight.elvey at amd.com>
> Date: Wed, 24 Aug 2005 14:11:36 -0700 (PDT)
> To: cctalk at classiccmp.org
>
>>From: "Allison" <ajp166 at bellatlantic.net>
>---snip---
>>
>>ugly 8080 flavor for transfers up to 1KB:
>>
>> ; HL is memory pointer
>> ; A is temp
>> ; B is transfer length *4
>> ; Zero flag affected by DCR B
>> DMAIO: IN DMAport ; wait if DMA is not asserted
>> mov M,A
>> INX H ; HL<-HL+1
>> IN DMAport ; wait if DMA is not asserted
>> mov M,A
>> INX H ; HL<-HL+1
>> IN DMAport ; wait if DMA is not asserted
>> mov M,A
>> INX H ; HL<-HL+1
>> IN DMAport ; wait if DMA is not asserted
>> mov M,A
>> INX H ; HL<-HL+1
>> DCR B ; B is dmatransfer down counter
>> JNZ DMAIO ; loop if not Zero, more to go.
>> ...
>>
>
>Hi
> As I recall, you could move the DCR B before the last
>IN DMAport. As I recall, INX H didn't effect the zero
>flag ( or was that the carry flag ? ). In any case,
>This kept the last time shorter.
>Dwight
>
Makes no difference in action. From the last IN DMAport
you have average 16uS to do whatever and get to the next
IN DMAport. Delay too long and you have a data overrun.
The INX H does not affect the flags the flags on 8080/8085/z80.
The DCR B does affect the zero flag.
It takes 10cycles to do the jump, 7 to not jump.
Z80 DJNZ is faster by 6 cycles as it would eliminate the
DCR B and also does the jump in 8 cycles. The only difference
is C would be your data counter.
None of this really helps of the CPU is 8088 or 6502.
Allison
aka: nostalgia right under our noses
This is one of those admissions like enjoying listening to Barry
Manilow or something...
So I'm making a computer for my car (freeBSD on a mini-ITX box)
and I'm hacking a "terminal" in an old AM radio chassis (a PIC,
two rotary encoders (VOLUME and TUNE), two momentary switches on
the shafts and a 4x20 LCD) to run a Perl script that drives
mpg321.
I need to borrow a simple (trivial!) cursor control scheme for the
LCD, so I decide to peruse /etc/termcap.
The comments in termcap are hilarious. There's a lot of obsolete
knowledge and funny comments in there, from when the unix world
was a lot smaller.
I assume the same ancient crud is lodged in linux also.
Check out the 'homemade' entries! You can know your bones are
foundation of the earth when your homemade terminal is documented
in distribution termcap!
# ^S is an arrow key! Boy is this guy in for a surprise on v7!
sol:\
...
# dmchat is like DM2500, but DOES need "all that padding" (jcm 1/31/82)
# also, has a meta-key (MT)
# from goldberger at su-csli.arpa
dmchat|dmchat version of datamedia 2500:\
...
# The Visual 200 beeps when you type a character in insert mode.
# This is a horribly obnoxious misfeature, and some of the entries
# below try to get around the problem by ignoring the feature or
# turning it off when inputting a character. They are said not to
# work well at 300 baud. (You could always cut the wire to the bell!)
# From mike at brl-vgr Mon Nov 14 08:34:29 1983
vi200|vis200|visual 200 with function keys:\
...
# From cbosg!teklabs!davem Wed Sep 16 21:11:41 1981
# Here's the command file that I use to get rogue to work on the 4025.
# It should work with any program using the old curses (e.g. it better
# not try to scroll, or cursor addressing won't work. Also, you can't
# see the cursor.)
# (This "learns" the arrow keys for rogue. I have adapted it for termcap - mrh)
4025-cr|tek 4025 for curses and rogue:\
...
# i: INFOTON (GENERAL TERMINAL)
#
# Infoton is now called General Terminal Corp. or some such thing.
# gt100 sounds like something DEC would come out with. Lets hope they don't.
i100|gt100|gt100a|General Terminal 100A (formerly Infoton 100):\
...
# l: LEAR SIEGLER (ADM)
#
# If the adm31 gives you trouble with standout mode, check the DIP switch
# in position 6, bank @c11, 25% from back end of pc. Should be OFF.
# If there is no such switch, you have an old adm31 and must use oadm31
adm2|lsi adm2:\
...
# q: HOME MADE TERMINALS
#
bill croft homebrew:\
:do=^J:am:le=^H:bs:cm=\E=%+ %+ :cl=^Z:co#96:ho=^^:li#72:\
:nd=^L:up=^K:vb=:
...
# This came from the comp ctr who got it from some user. Smart indeed!
sexidy|exidy smart:\
...
# Special "terminals". These are used to label tty lines when you don't
# know what kind of terminal is on it. The characteristics of an unknown
# terminal are the lowest common denominator - they look about like a ti 700.
# The last one, "other", is like unknown but it allows an escape from software
# that insists that a "real" unknown terminal is merely so far unspecified.
...
arpanet:\
:tc=unknown:
...
plugboard|patch|patchboard:\
:tc=unknown:
...
# "Teleray Arpa Special", officially designated as
# "Teleray Arpa network model 10" with "Special feature 720".
# This is the new (1981) fast microcode updating the older "arpa" proms
# (which gave meta-key and pgmmable-fxn keys). 720 is much much faster,
# converts the keypad to programmable function keys, and has other goodies.
# Standout mode is still broken (magic cookie, etc) so is suppressed as no
# programs handle such lossage properly.
# Note: this is NOT the old termcap's "t1061f with fast proms."
# From Univ of Utah, J.Lepreau Tue Feb 1 06:39:37 1983
# lepreau at utah-cs, harpo!utah-cs!lepreau
...
# New version from ee178aci%sdcc7 at SDCSVAX.ARPA Fri Oct 11 21:27:00 1985
apple-80|apple II with smarterm 80 col:\
:am:bs:bt=^R:bw:cd=10*^K:ce=10^]:cl=10*^L:cm=^^%r%+ %+ :\
:co#80:cr=10*^M:do=^J:ho=^Y:le=^H:li#24:nd=^\\:up=^_:
lisa|apple lisa console display, black on white:\
...
>From: "Allison" <ajp166 at bellatlantic.net>
---snip---
>
>ugly 8080 flavor for transfers up to 1KB:
>
> ; HL is memory pointer
> ; A is temp
> ; B is transfer length *4
> ; Zero flag affected by DCR B
> DMAIO: IN DMAport ; wait if DMA is not asserted
> mov M,A
> INX H ; HL<-HL+1
> IN DMAport ; wait if DMA is not asserted
> mov M,A
> INX H ; HL<-HL+1
> IN DMAport ; wait if DMA is not asserted
> mov M,A
> INX H ; HL<-HL+1
> IN DMAport ; wait if DMA is not asserted
> mov M,A
> INX H ; HL<-HL+1
> DCR B ; B is dmatransfer down counter
> JNZ DMAIO ; loop if not Zero, more to go.
> ...
>
Hi
As I recall, you could move the DCR B before the last
IN DMAport. As I recall, INX H didn't effect the zero
flag ( or was that the carry flag ? ). In any case,
This kept the last time shorter.
Dwight
>It's 35 cycles in z80 for the slowest part of the loop
>and 34 for 8080. Z80 IN port is 11cy!
>
>Why four bytes pwer transfer? one it makes doing 512 or
>1024 bytes per sector with a 8bit counter (lower overhead)
>and doing a 765 format only requires 4 bytes per sector
>(C, H, R and N)!
>
>A 2mhz 8080 will actually run this for 8" DD (13us case)
>successfuly even though the last leg of the loop is
>17.5us as you have 16us +13us worst case before an
>overrun occurs and the next step in the loop is not
>as slow. Note waits for refresh will blow the works
>and Z80s systems that use processor refresh are not
>likely to behave well if the FDC hangs (no disk or
>blank inserted) too long.
>
>A 6502 can easily do it.
>
>>From a system perspective I prefer DMA. I like to free
>up CPU cycles to do "stuff" and make hardware do repeatitive
>stuff like basic transfers. However the DMA does not have \
>to be complex or even a LSI (8257 or 8237). A simple gating
>logic plus an upcounter of sufficient length is enough and
>it can even be to a fixed address (host buffer in the case
>of CP/M deblocking). Things like background tasks are then
>easier to implement to utilize otherwise wasted IO loops
>(wait for keyboard!). The most obvious interrupt driven
>background tasks to implement are printer output buffering
>or modem input buffering.
>
>
>Allison
>
>
>
>
Oops!
Change all of the 20us to 16us. That is what I really
meant but had some brain rot.
Dwight
>From: "Dwight K. Elvey" <dwight.elvey at amd.com>
>
>>From: "Philip Pemberton" <philpem at dsl.pipex.com>
>>
>>In message <0ILP004N8EKHJER2 at vms040.mailsrvcs.net>
>> Allison <ajp166 at bellatlantic.net> wrote:
>>
>>> Unless you use a drive that spins faster then the 500khz rate is fine.
>>
>>If it doesn't, I'll speedhack it to run at 300.
>>The only drive I've got that runs at 360 is a Y-E Data YD-380B. It completely
>>ignores the speed select pin, even though it's wired to "something" on the
>>PCB...
>>There are no visible jumpers anywhere, besides DS0 and DS1.
>>
>>> Yep, remember the worst case for "fast is 13us! I'd plan for that.
>>> Also the slow rates will give you nominal 32us (27us worst case).
>>
>>Eek! Interrupt-mode it is then.
>
>---snip---
>
>Hi
> You might check the interrupt overhead. If you can't handle it
>in polled mode, it is unlikekly that interrupt mode will keep
>up. Although, the time between seeing the data available bit
>and transfering the data is 13us, at 500Khz the bytes will
>arrive at 20us rate. It changes what you need to do in which
^^^^
16us
>order. Also, like I said in another post, if you know how
>fast your processor is running, you may not need to check
>the data available status every byte. Remember, they are
>comming at 20 us each. You need to know the uncertainty of
^^^^
16us
>the first status( how long it takes to loop on the status).
> You also don't need to worry too much about the first data
>available. Remember, the controller has to read across the
>header and gaps before it needs to transfer any data.
>Dwight
>
>
>
>
>From: "Philip Pemberton" <philpem at dsl.pipex.com>
>
>In message <0ILP004N8EKHJER2 at vms040.mailsrvcs.net>
> Allison <ajp166 at bellatlantic.net> wrote:
>
>> Unless you use a drive that spins faster then the 500khz rate is fine.
>
>If it doesn't, I'll speedhack it to run at 300.
>The only drive I've got that runs at 360 is a Y-E Data YD-380B. It completely
>ignores the speed select pin, even though it's wired to "something" on the
>PCB...
>There are no visible jumpers anywhere, besides DS0 and DS1.
>
>> Yep, remember the worst case for "fast is 13us! I'd plan for that.
>> Also the slow rates will give you nominal 32us (27us worst case).
>
>Eek! Interrupt-mode it is then.
---snip---
Hi
You might check the interrupt overhead. If you can't handle it
in polled mode, it is unlikekly that interrupt mode will keep
up. Although, the time between seeing the data available bit
and transfering the data is 13us, at 500Khz the bytes will
arrive at 20us rate. It changes what you need to do in which
order. Also, like I said in another post, if you know how
fast your processor is running, you may not need to check
the data available status every byte. Remember, they are
comming at 20 us each. You need to know the uncertainty of
the first status( how long it takes to loop on the status).
You also don't need to worry too much about the first data
available. Remember, the controller has to read across the
header and gaps before it needs to transfer any data.
Dwight
There was a long discussion about creating an archive of 'em, but
it doesn't appear that anything ever happened. Jay offered to create
www.classiccmp.org/M9312, but that doesn't appear to exist. Pete
Turnbull has a list of part numbers, but no images.
--- On Wed 08/24, Ethan Dicks < ethan.dicks at gmail.com > wrote:
From: Ethan Dicks [mailto: ethan.dicks at gmail.com]
To: cctalk at classiccmp.org
Date: Wed, 24 Aug 2005 13:30:33 -0500
Subject: Re: pdp8 virtual memory disk system -pick up free, or will be junked!
On 8/24/05, vrs <vrs at msn.com> wrote:<br>> Cool! Unfortunately, I am nowhere near Dallas :-(.<br><br>Neither am I. :-(<br><br>-ethan<br><br>
Nor am I. My brother lives in Houston, but that's still a drive.
_______________________________________________
Join Excite! - http://www.excite.com
The most personalized portal on the Web!
I got a LSI-11 (11/03) the other day that is pretty much intact, but
will need some work.
Included with the chassis, backplane and power-supply, were the
following cards:
Top
LSI-11 CPU M7264 <----------><Quad>
M7940 <dual> | DSD 1140-AA floppy ctl <dual>
M7940 (aux1) | M7940 <dual> (aux 2)
M7941 <dual> | M7944 <dual> (5)
M7944 <dual> (1) | M7944 <dual> (2)
M7944 <dual> (3) | M7944 <dual> (4)
EMPTY | M7944 <dual> (bank)
<------------------<Quad> Mystery/Terminator??---->
Bottom
I do believe the mystery card at the bottom is in fact a
terminator/bootstrap?? (TEV11/REV11)
But there are no numbers on the handles or on the board.
The plastic handles are grey and are DEC branded. The board has a 40 pin
connector.
Having never seen a TEV11 or aa REV11 and finding little by googling,
I'm wonder if anybody out there
can enlighten me!!
I took a picture and excuse me for the size, but I wanted to include as
much detail as possible!
http://personal.riverusers.com/~dponsford/qbus.html
I also believe the DSD board is a floppy controller.However what looks
like the model # on the side of the board:
A/1140-6A a small ehite label on the 28 pin eeprom N82S 100I 7851. The
controller has a fifty pin connector.
Does this look familiar to anybody
Thanks in advance for any help!!
Tom
>
>Subject: Re: Floppy controller questions
> From: "Dwight K. Elvey" <dwight.elvey at amd.com>
> Date: Wed, 24 Aug 2005 09:36:49 -0700 (PDT)
> To: cctalk at classiccmp.org
>
>>Yep, remember the worst case for "fast is 13us! I'd plan for that.
>>Also the slow rates will give you nominal 32us (27us worst case).
>>
>>>Isn't learning fun?
>---snip---
>
>Hi
> One thing to consider is that you can unroll the loop and just
>fetch or write data and increment the pointer. Even on an
>8080, this is reasonably fast. If you know the speed of the
>processor and the speed of the controller, you don't have to
>check the data ready bit every time. You just need to do it
>often enough to resync things. Another trick, if you are
>using a loop, is that you can make the loop partially unrolled.
>You only modify the counter once every few data read or writes.
>You do, say, 4 bytes at a time. Any odd amounts needed can
>be unrolled.
> Using any one of these tricks will get you in the range.
>On a PC, the main issue is that you need to shut down all
>interrupts and be aware of refresh if it uses memory cycles.
> On a processor that I was playing with, I found that the
>processor was too fast for the FDC chip. It was only
>running a 4 MHz instruction speed.
>Dwight
You can do that with care.
One oddity is the 765 will assert DRQ (dma request) before the
data is in the buffer and a .5uS delay is needed on DRQ for ultra
fast DMA systems. I found this out with 4mhz z80 using processor
stall: read the DMA input port, IF DRQ not TRUE then assert CPU WAIT/
until true. Thsi is fast enough as it's waiting on an IN A,DMAport
and will grab the buffer as soon as DRQ is true. If you can have
the CPU wait on DRQ the loop is very tight. For Z80/8080:
ugly 8080 flavor for transfers up to 1KB:
; HL is memory pointer
; A is temp
; B is transfer length *4
; Zero flag affected by DCR B
DMAIO: IN DMAport ; wait if DMA is not asserted
mov M,A
INX H ; HL<-HL+1
IN DMAport ; wait if DMA is not asserted
mov M,A
INX H ; HL<-HL+1
IN DMAport ; wait if DMA is not asserted
mov M,A
INX H ; HL<-HL+1
IN DMAport ; wait if DMA is not asserted
mov M,A
INX H ; HL<-HL+1
DCR B ; B is dmatransfer down counter
JNZ DMAIO ; loop if not Zero, more to go.
...
It's 35 cycles in z80 for the slowest part of the loop
and 34 for 8080. Z80 IN port is 11cy!
Why four bytes pwer transfer? one it makes doing 512 or
1024 bytes per sector with a 8bit counter (lower overhead)
and doing a 765 format only requires 4 bytes per sector
(C, H, R and N)!
A 2mhz 8080 will actually run this for 8" DD (13us case)
successfuly even though the last leg of the loop is
17.5us as you have 16us +13us worst case before an
overrun occurs and the next step in the loop is not
as slow. Note waits for refresh will blow the works
and Z80s systems that use processor refresh are not
likely to behave well if the FDC hangs (no disk or
blank inserted) too long.
A 6502 can easily do it.
>From a system perspective I prefer DMA. I like to free
up CPU cycles to do "stuff" and make hardware do repeatitive
stuff like basic transfers. However the DMA does not have \
to be complex or even a LSI (8257 or 8237). A simple gating
logic plus an upcounter of sufficient length is enough and
it can even be to a fixed address (host buffer in the case
of CP/M deblocking). Things like background tasks are then
easier to implement to utilize otherwise wasted IO loops
(wait for keyboard!). The most obvious interrupt driven
background tasks to implement are printer output buffering
or modem input buffering.
Allison
