I want to bould my own PDP11 some day but in an other way as other people
here :-)
I want to build an Bit Slice CPU out of AM2901 Chips to emulate the
PDP11 CPU. As a prt of the design I'LL need some very fast Proms for the
microcode and I've found the AM27C291,TMS27C291 and CY7C291 Chips, they are
fast and big enough (2Kx8 and 25-35ns).
I'mm looking now for a data sheet from the CY7C291 that describes the
programming algorithm, getting a datasheet is easy on
http://www.datasheetarchive.com/ but there is this sentence in the text:
"Programming Information
Programming Support is available from Cypress as well as from a number of
third party software vendors. For detailed programming information,
including a listing of software packages, please see the PROM Programming
Information located at the end of this section. Programming algorithms can
be obtained from any Cypress repesentative."
Ok, so far so good.
I don't know of what end of which section I schould look for the
programming information, since I don't know from where the datasheet was
scanned from. I've contacted Cypress itself some time before..to make it
short: they failed.
The sold the entire Eprom bussines years agao (forgot to which company)
but wheter cypress nor the new company has the required information or want
to share them.
So please: Maybe someone has this old databook from cypress and could look
"at the end of this section"?
I got the algorithm for the TMS in a datasheet, but according the german
company "Conitec" that makes programmers (have a GALEP-III from them) that
seems to be not the same on the CY7C291. The guy there couldn't program my
samples I've sent to him.
Any help?
Regards,
Holm
--
Technik Service u. Handel Tiffe, www.tsht.de, Holm Tiffe,
Freiberger Stra?e 42, 09600 Obersch?na, USt-Id: DE253710583
www.tsht.de, info at tsht.de, Fax +49 3731 74200, Mobil: 0172 8790 741
I'm divesting myself of most of my q-bus stuff, starting with the
uVax board sets.
M7169 - 4-plane video controller module
M7168 - 4-plane color bitmap module (x2)
M7622 - 16-Mbyte RAM for KA650 (MicroVAX III) (x2)
M7625 - MicroVAX III CPU (workstation license), 60nS
M7606-EF Microvax II CPU
M7609 - 8-Mbyte parity 36-bit RAM for KA630 (MicroVAX II) (x2)
I also have the cable for the video card, and a couple of those
switch panels for the CPU's
I just need to unload this, make me an offer; would prefer to
sell the lot. I could also be bribed to ship this internationally;
make me a good offer, and maybe we can cut a deal.
Shipping will be from STockton, CA 95212 (USA)
____________________________________________________________
Publish your photos in seconds for FREE
TRY IM TOOLPACK at http://www.imtoolpack.com/default.aspx?rc=if4
So, my UK101 sold for a healthy ?224, which I am very happy about indeed.
However, it's to a buyer in the USA and he wants me to split the
bundle and send just the computer - he does not want the monitor.
He claims that although the computer will run on a 240-to-120V
transformer, the monitor will not, as US DC is 60Hz and European is
50Hz.
Is this correct? It's news to me.
I don't really want to split the package up, TBH - I am not sure that
the monitor is worth much on its own.
--
Liam Proven ? Profile: http://lproven.livejournal.com/profile
Email: lproven at cix.co.uk ? GMail/G+/Twitter/Flickr/Facebook: lproven
MSN: lproven at hotmail.com ? Skype/AIM/Yahoo/LinkedIn: liamproven
Tel: +44 20-8685-0498 ? Cell: +44 7939-087884
Looking for early TRSDOS disks (pre-2.0) for the TRS-80 Model II.
This would be on 8-inch disks. This is NOT the same as any TRSDOS for
the Model I or Model III.
Thanks!
Eric
Hi Dave,
answers below. I must admit I was not expecting this in a thread with
this title, but I spotted it because I had replied the other day. I hope
I can address all your questions.
Best,
Chris
Am 29.02.2012 15:00, schrieb cctalk-request at classiccmp.org:
>
> I do have a Kryoflux board too ? I got it mainly for testing purposes.
> The Kryoflux team does not seem interested in working together with
> interested people at the same level as Phil ?
Are we? In fact many people working on KryoFlux are contributors.
Several people work with the source, and we recently even visited a KEEP
(http://www.keep-project.eu/ezpub2/index.php) workshop to discuss and
exchange with others, to name just one occasion. I never got a request
or proposal from you, but if you have ideas or comments, or whatever to
share... please let us know!
If you want to browse our website... there is a ton of information we
shared (and still do) over the last decade.
> their actually-useful
> analysis software is very expensive and even dongle protected,
> according to the FAQ at
> http://forum.kryoflux.com/viewtopic.php?f=3&t=3#p1241 .
Yes it is, so are many products. It must admit I don't get how this is
related to KryoFlux, or us being interested?
I have several products from the same company, some are cheap, others
are more expensive. Some come with a dongle, others activate only
(yikes!). People that want it can contact us. Some did/do. And some use
the software as part of a special arrangement. I really don't see why
this is wrong.
> The basic DTC
> software is closed-source and can be rather temperamental, as is the
> firmware.
Is it? I'd be happy to hear about quirks. I in fact have many posts and
mails that report the opposite. People are in fact happy it works so
well. If anything is broken, please send in a bug report. I haven't seen
one and I really wonder about the firmware. How would one notice that
it's currently "temperamental"?
I wonder what this has to do with the status of the source. I'd say it
does say nothing about quality. I in fact know many quality products
that are not open but I think they are very well executed. Does that
mean being open but flawed would be more desireable?
> Though Christian says the Kryoflux "never had such a
> problem," I have never seen an independent analysis or source code or
> anything confirming that.
We don't have anything to hide. We do have eleven years of field
experience in regard to preservation. The problem outlined by Johannes
was a design fault, it's not a glitch. You must not have ambiguity in
encoding. Apparently it was fixed lately, a year after release.
> I may end up doing this myself. Without
> source it's definitely more work to verify it.
Let me know how we can help you.
It feels a bit odd to read the above when in fact you never asked for
anything of the above. How should we know you would want to audit it?
> An overview of the engineering of the Kryoflux board indicates it was
> designed mainly with low cost in mind. The level buffers on it are
> very ESD-sensitive and are not designed for cables (so a long floppy
> cable may cause issues), and there's lack of protection overall,
> especially in the power supply.
I think this is very easy to explain... it was made to be as cheap as
possible without sacrificing ingestion quality. We like to make it
affordable, and we'd even make it cheaper if we could. We don't want it
to be more expensive. The buffers work very well, and we haven't had a
single dead one in more than 600 units sold. In regard to protection:
One dead board in 600 units supplied, the PSU was broken and just fried
the board. We exchanged it. Should I have made all 600 more expensive to
cover that one case? That's 599 vs 1. And again: We don't have to hide
anything - so I am telling you here in public.
> There's no way the current Kryoflux design ever will be able
> to image high-RPM media.
That's correct. The software could, but the hardware defnitely can't. We
never targeted harddrives. We focussed on one specific field of use. And
it's working very well. If we'd want to do harddrives or other high-RPM
media, we would do another model or product.
If these things were cars... we wanted to make something that drives,
not something that floats or flies. Just one thing... but very well
executed.
> As for Linux support: I've seen several complaints lately on the
> Kryoflux forums about libusb and glibc issues.
Right, you did not want to mention that this is more or less a
"theoretical problem"? We offer 32bit and 64bit builds. The 32bit worked
for all users (as far as I know, and also on 64bit systems), the 64bit
version needed to be refined to make it work on as many distributions as
possible. That's just the way it is with binaries on Linux. I am not
really happy with that.
But on the other hand it satisfies many customers. Just install the
software, attach the board - have fun. Buying a bread instead of always
baking your own isn't that bad.
I wonder how many users will be able to compile a source on Windows or
Mac, just to shed some light on the other side of the coin. It's not all
black and white.
> Take a look:
> http://forum.kryoflux.com/viewforum.php?f=3 . Even though they're
> somewhat responsive, it's still relying on them for support.
I don't get the meaning of this but... if you mean we need a bug report
to remove a bug... yes, we do. The wording "somewhat responsive" makes
me wonder... people usually get replies the next working day, and even
fixes come along pretty quickly. What is wrong with that? To make it
better, we have to listen. We do.
> There's also the issue of the Kryoflux software lagging behind.
> Currently the Mac version (which is what I use) is a few months old,
> and lacks many of the features I would like.
That is true, you would have to use Windows or Linux. Today.
> When I asked about this,
> I got brushed away, saying that the person who usually builds that
> version is busy.
Excuse me, would you mind publishing the answer I gave you as well? I
wonder where I did brush you away. I think I was very polite and
explained that the Mac port was being worked on. And yes, it's true, our
Mac devs are very busy, which is why the team was expanded and a new
release is near completion.
We welcome everyone that needs an earlier port to step forward and help.
Sometimes it's just diffing some files and applying a few platform
specific changes. Still, it needs to be done with care and by someone
who knows what he's doing. We take quality very serious.
Does anyone have a Operator's Field Reference Guide (or any other
manual) for an Atlantic Research Interview Comstate 1?
--
Pete Peter Turnbull
Network Manager
University of York
> From:?ard at p850ug1.demon.co.uk (Tony Duell)
> Subject:?Re: UK versus US monitor question
>> > > It used to be the case that TVs synced to the mains
>> > frequency but I don't
>> >
>> > Was it?
>>
>> A long time ago...
>
> OK, I am sceptical. ?What do you mean by a 'long time ago'?
>
> Unti lthe coming of the National Grid, different areas would be supplied
> with mains at slightly differnet frequencies (even assuming it was
> supposed to be nominally 50Hz), and therre would eb no phase relationship
> at all. So usign that for any form of TV synchronisation is a non-starter.
>
> So that really limits us to post-WW2 TVs. The oldest book of schematics I
> have is dated 1953, but it contains models going back to 1948. Not one
> attempts to derrive the vertical sync signal from the mains as far as I
> can see.
>
> But I am a scientist... So while I have not found such a TV, I ?an't say
> they don't exist. So I would ask you to state the make and model of one
> or more TVs that derrived the vertcal sync signal from the mains, so that
> I can track down the scheamtics and see what they did.
>
> -tony
There is a schematic from 1930 on this WWW page from our local museum.
http://www.newsm.org/Wireless/TV/mechanical_TV.html
Click on the link for the booklet "The Romance and Reality of Television".
--
Michael Thompson
Original Message:
Date: Sat, 25 Feb 2012 19:15:37 +0000 (GMT)
From: ard at p850ug1.demon.co.uk (Tony Duell)
> > IIRC tjhat switchbox contains what we (in the UK) call a 'Balun'. I am
> > not sure if that term has crossed the Pond, it's an abreviation of
> > 'Balanced <-> Unbalanced'.
>
> In the US, the term "balun" is not used by the general public. It's used
Ove here, the 'genral public' wouldnt' know what a matching transformer
was used for :-)
-----
Not just the general public; when one of my tenants had cable TV installed
recently the installer told her that she'd have to buy a new second TV
because her perfectly good 300-Ohm-only TV was not compatible with the coax
>from the converter box...
