> >Bears a strong kinship IIRC, to the Beehive Super Bee.
> >
> >--Chuck
>
> I cant find a full spec for that terminal, just termcap entries, and a
> field service manual for a "mini bee" that I think is related, but
> neither seem to fit beyond potential use of "unit seperator (0x1F) as
> a "new line" marker (although even that seems a bit iffy, since the
> 1F is followed by 0D 0A, i.e. CR/LF)
>
> I realised I didn't post any actual 'escape' sequences, just uses of
> control codes I haven't seen much use of before (US,GS, DC2, DC4).
The "device control" codes appear to have their familiar uses:
DC1 = ctrl-Q = reader on
DC2 = ctrl-R = punch on
DC3 = ctrl-S = reader off
DC4 = ctrl-T = punch off
However, it isn't yet clear whether the device being used is truly a
reader/punch, or that these codes are used for some analogous purpose
to turn on/off read/write of another device.
> The escape sequences I see are:
> HEX ASCII
> 1) 1F 26 24 <x y z> : ESC & $ <xyz>
> 2) 1F 26 27 <x y z> : ESC & ' <xyz>
> 3) 1F 26 21 <x y z> : ESC & ! <xyz>
>
> where 1,2,3 are all output at different times, with <x y z> being
> values I haven't yet determined (they are register values i.e. set at
> runtime, whereas the first 3 bytes are hardcoded)
The first value is hex 1B, of course (not 1F).
The x,y,z values apparently represent a record number (128-byte records).
x is an ASCII digit (30 - 39 hex)
y is an ASCII digit (30 - 39 hex)
z has the range 40 - 5F hex (at sign through underscore)
James Markevitch
FYI
10 SEPT 2010: MARYLAND INSTITUTE FOR TECHNOLOGY IN THE HUMANITIES
(MITH) LAUNCHES VINTAGE COMPUTING SITE:
MITH is very pleased to announce a new Web site
<http://mith.umd.edu/vintage-computers/> devoted to its sizable (and
growing) collection of vintage computers, retro software, and other
artifacts from the early era of personal computing. The centerpiece
of the site is a a considered metadata and modeling approach to
computing hardware, whereby individual components of the vintage
machines are documented, contextualized within their relation to the
system as a whole, and expressed using Dublin Core. The site gathers
links to other recent MITH projects in born-digital cultural
heritage, and serves as a clearing house for our expanding portfolio
in this area. It also includes newly written non-specialist's
documentation for the FC5025 Floppy Disk Controller, a device used to
retrieve data off of obsolescent media formats.
The site is presented using the content management tool Omeka. It was
researched and designed by Walker Sampson, who recently completed an
MLS from the School of Information at the University of Texas;
Sampson was in residence at MITH this past summer under the auspices
of the IMLS-sponsored Digital Humanities Model Internship Program.
MITH's Associate Director Matthew Kirschenbaum comments, "This site
demonstrates the role that vintage computing can have in the
environment of an active digital humanities center; as born-digital
cultural heritage becomes ever more important, centers such as MITH
will play a part alongside of libraries and archives in addressing
its long-term presentation and curation."
SOURCE:http://mith.umd.edu/mith-launches-vintage-computing-site/
As all of us who do hardware repairs know, a multimeter is an essential
piece of test equipment.
Until a couple of days ago, I used a Fluke 85 (original series). It did
what I wanted, there were 2 parts of the design I didn't like, but apart
>from that it was great
The 2 thing I didn't like were
1) You have ot dispmantle the meter to change the battery, and it's
assembeled with self-tapping screws going into the plastic case. I don't
know how many insertions they will stand.
2) The most switch used resistive traces on the PCB with a wiping contact
to connect them to an analogue input on the main chip. If that wiper
didn't make contact properly, it sometimes got into the wrong mode. It
owuld even sometimes power itself up (and flatten the battery) when in
the off poosition.
Anyway, I was using this iustrument on Saturday (actualy for testing the
PSU, etc, in an HP2623 graphics terminal) with no problems. I put it away
in my tool drawer. On Sunday I got it out for some other tests and
discovered the display had failed. It's totally black for half the
height, I asusem the liquid crystal material has leaked out (although the
glass is not obviously cracked or broken). AFAIK nothing fell on it in
the tool drawer (there are no really heavy tools in there anyway), it
wasn't dropped, etc. Just one of those things.
Alas Fluke say they can no longer supply the display for this insturment
as a spare part.
Given that I need the standard functions only (including a good
continuity tester!), don't need excessive accuracy, and would like to be
able to fix it if anything goes wrong, does anyone have any
recomendatins? I am not conviced I should buy another Fluke, BTW.
Long shot : Does anyone have a defective original-series Fluke 80 with a
good display (maybe the ASIC has died or something). I would be
interested in buying it.
-tony
>Bears a strong kinship IIRC, to the Beehive Super Bee.
>
>--Chuck
I cant find a full spec for that terminal, just termcap entries, and a
field service manual for a "mini bee" that I think is related, but
neither seem to fit beyond potential use of "unit seperator (0x1F) as
a "new line" marker (although even that seems a bit iffy, since the
1F is followed by 0D 0A, i.e. CR/LF)
I realised I didn't post any actual 'escape' sequences, just uses of
control codes I haven't seen much use of before (US,GS, DC2, DC4).
The escape sequences I see are:
HEX ASCII
1) 1F 26 24 <x y z> : ESC & $ <xyz>
2) 1F 26 27 <x y z> : ESC & ' <xyz>
3) 1F 26 21 <x y z> : ESC & ! <xyz>
where 1,2,3 are all output at different times, with <x y z> being
values I haven't yet determined (they are register values i.e. set at
runtime, whereas the first 3 bytes are hardcoded)
A curator at the Computer History Museum needs to borrow (or obtain) a
first-gen I-mode cell phone. This is for a long-term exhibit on the
history of portable computing. I'm involved in the project, so I
offered to ask around, including here on cctalk. However they need is *
quickly *. If anybody has one they're willing to part with, please
email me off-list ASAP.
I am trying to disassemble some ROM dumps from the SacState 8008
machine (per http://www.classiccmp.org/pipermail/cctalk/2010-September/291012.html
)
I can see a lot of escape codes being sent, but they don't make sense
(to me at least) as Tektronix 4023 escape codes, which is the terminal
type reported as being used with that machine.
For example, the first thing output after a restart is:
HEX ASCII
1F Unit Separator
0D CR
0A LF
3F ?
pressing the keys "!\h" would generate this sequence:
1D Group Separator
37 7
7F DEL
20 SPACE
40 @
1F Unit Separator
12 DC2
1D Group Separator
37 7
7F DEL
20 SPACE
40 @
1F Unit Separator
14 DC4
Does anything there look familiar to anyone at all? this would be some
kind of terminal from early to mid 70s.
Cheers
Jonno
Continuing to clear the bookshelves :)
I have a set of original Apple IIe manuals for sale.
Apple IIe Owner's Manual, IIe Reference Manual, 80-Column Text
Card, Reference Manual Addendum (Monitor Listings), Extended
80-Column Text Card Supplement, DOS Programmer's Manual, ProDOS
User's Manual, ProDOS Supplement to the IIe Owner's Manual,
AppleWriter II, & Super Serial Card User's Manual.
http://s1181.photobucket.com/albums/x426/DrCharlesMorris/?action=view&curre…
$20.00 plus 8 lb (Media Mail) postage from zip 65775.
Also an original Apple II Reference Manual:
http://s1181.photobucket.com/albums/x426/DrCharlesMorris/?action=view&curre…
$5.00 plus 1 lb postage.
please contact me off-list if interested.
I've got the //e also with Duo-Disk floppy drive, but it won't be
worth the postage!
thanks
Charles
Thanks, yes a schematic would be great. Can I post it to the web please?
I'm sure Tony knows the following, included as background.
Here's the adapter I used to read the 2564 in a 2764 programmer:
2564 pins?????? 2764 pins
20 (A11)??????? 23 (A11)
23 (A12)??????? 2 (A12)
2+27(CS1+CS2)?? 22 (OE)
1 (Vpp)???????? 28 (Vcc)
22 (PD/PGM)???? 20 (CE)
(NC)??????????? 27 (PGM)
All other pins connected straight through. The above can't be always used in the
reverse direction (eg using a 2764 in a 2564 socket), as CS1 and CS2 may or may not
be tied together depending on the circuit.
Also programming a 2564 uses a different algorithm to programming a 2764. For example,
on a 2764 Vpp can be left at programming voltage of 21V during a verify cycle, whilst on the 2564 Vpp is at 25V for programming and 5V for verifying / reading (I assume the 25C64 is similar but with a lower Vpp).
Regards,
John
==============================================================
Tony Duell
ard at p850ug1.demon.co.uk
Mon Oct 11 15:29:35 CDT 2010
> I've finally made an adapter to read the 2564 on my programmer (which can o=
> nly read the 2764). There were about 5 pins to rewire=2C I'll write some no=
> tes later on the differences.
>
> I've upload the ROM image to:
>
> http://www.vintagecomputers.btinternet.co.uk/mw4/mw4.zip
THanks. I've downloaded it, it unpacks OK. I wondered why the file was
larger than ecxpected, but then saw you'd included both hex and binary
images.
I will probably burn it into a 27C64 (those I have, and my programmer can
easily handle them) and make an adapter to use it in the MW4. Then we can
see if that gets mine working.
I won't be doing this just yet (I've gor various other things to do), but
I will let you know how I get on when I do do it.
If you are going to disassemble the ROM, do you need schematics of the
MW4 hardware?
-tony
On 10/01/10 00:22, "Michael B. Brutman" <mbbrutman-cctalk at brutman.com>
wrote:
> Sean Conner wrote:
>> > While I'm familiar wih IP, I haven't tried implementing it, but, what if
>> > you were to set an MTU size of around 50 bytes? The IP header (sans
>> > options) is 20 bytes, and the TCP header is another 20. I would think
>> > setting the MTU to just above 40 might cause some fragmentation (I thought
>> > of suggesting an MTU of just above 20, but then you're testing for IP
>> > fragmentation, and not TCP fragmentation.
>> >
>> > I tend to do stupid stuff like that, but then again, I*was* hired to
>> > write testing code at my current job ...
>> >
>> > -spc (In thoery, IP should work with an MTU of 30 bytes, right?)
> The IP header is 20 bytes without any IP header options, and the TCP
> header is another 20 bytes without any TCP header options.
The minimum allowed MTU is actually 68. (I wrote 65 erronously in a
previous mail.) See RFC 791, page 24.
In addition to the 68 bytes for a single fragment, an IP stack must be
able to handle 576 byte packets, but there is no requirement that this
isn't sent in fragments. The receiver must, however, always be able to
handle atleast 576 byte packets.
> My implementation has room for 10 fragments per packet (configurable
> with a #define), which is great for a 'normal' MTU size. If I tested
> with a ridiculously small MTU it would wind up throwing a lot of things
> away, but many implementations do the same thing.
You should allocate that stuff dynamically.
> My fragment problem is mostly on the source side - the source machines
> are too clever about trying to probe and eliminate fragments.
>
> Linux has also been 'interesting' as a gateway. Some kernel versions
> allow TCP fragments through even though they have bad checksums. I
> throw away any packet with a bad checksum. Mixing NAT (Network Address
> Translation) and fragments was problematic in my setup too - I think
> that Linux was completely screwing up the payload checksums for TCP.
What are you talking about? IP fragments for TCP don't have checksums of
the TCP payload. There is only a checksum for the IP header.
Only the final destination reassembles the packet, and can do a checksum
of the TCP packet.
Johnny
