The D-25 PTR / PTP parallel interfaces are TTL, the ones I have had on the
bench at any rate, typically using 74 series for interfacing and 5V rails.
Generally, the data lines are on pins 1 to 8 after that it gets a bit YMMV and
at the top end you get ground and exported voltage. Hence my
On 5/16/24 15:15, Martin Bishop via cctalk wrote:
Micha
That the board is TTL and 2 layer by the look of it makes reverse engineering
rather more tractable : good luck.
The 25p D pin outs for readers/punches seem substantially standardised,
I believe the standard is RS-323 (all search
Micha
That the board is TTL and 2 layer by the look of it makes reverse engineering
rather more tractable : good luck.
The 25p D pin outs for readers/punches seem substantially standardised, I think
you will find that the Dostek 440 manual (which is a solid state substitute
for PTP / PTR)
It would have been quite a bit of good luck, but I thought maybe
b
On Thu, May 16, 2024 at 2:53 PM Michael Fritsch via cctalk <
cctalk@classiccmp.org> wrote:
> Thank you Bill, but the board in the link is completely different.
> The board in my reader is almost identical to the one in this
Thank you Bill, but the board in the link is completely different.
The board in my reader is almost identical to the one in this auction (version
D vs. A):
https://www.ebay.co.uk/itm/333131813919
Only TTL-Logic, no processor, no UART, paralleöl data output.
Micha
Bill Degnan via cctalk wrote:
> On May 16, 2024, at 1:50 PM, Kevin Jordan wrote:
>
> Regarding NOS/VE and the notion that its command language was horribly
> awkward ... the command language was strongly influenced by Multics and some
> thinking in the Computer Science world about user-friendliness in command
>
Regarding NOS/VE and the notion that its command language was horribly
awkward ... the command language was strongly influenced by Multics and
some thinking in the Computer Science world about user-friendliness in
command languages being linked to predictability. Commands in NOS/VE's SCL
(System
> On May 16, 2024, at 11:22 AM, Martin Bishop via cctalk
> wrote:
>
> It looks as though Decitek remain in business
> http://www.decitek.com/index.html
>
> Scan of a series 700 reader manual on bitsavers
> http://www.bitsavers.org/pdf/decitek/
>
> On an optical reader, I would not recon
I have something close-ish
http://www.memex.ca/wp-content/uploads/old/M110545-Dostek-440A-BTR-User-Guide.pdf
Bill
On Thu, May 16, 2024, 10:33 AM Michael Fritsch via cctalk <
cctalk@classiccmp.org> wrote:
> I have a Decitek 442A9 papertape reader which needs repair.
>
> I have already replaced
I know the document on bitsavers, but the series 700 is a complete different
one.
In this reader there is no clamp or breake or similar things, but a stepper motor which drives two
sprocket wheels. Between the wheels is the optical sensor.
In the moment I'm about to reverse engineer the
It looks as though Decitek remain in business http://www.decitek.com/index.html
Scan of a series 700 reader manual on bitsavers
http://www.bitsavers.org/pdf/decitek/
On an optical reader, I would not recon the capstan running at power on as
unusual - a pinch roller which engages for drive and
Decitek is still in business, so try decitek.com
> On May 16, 2024, at 10:13 AM, Michael Fritsch via cctalk
> wrote:
>
> I have a Decitek 442A9 papertape reader which needs repair.
>
> I have already replaced the belt, but that is not enough. The reader behaves
> very strangely. It starts
> On May 16, 2024, at 11:08 AM, Gary Grebus via cctalk
> wrote:
>
> We were a beta test site for NOS/VE and the hardware (Cyber 180?). CDC sent
> the machine and a software support engineer to help us do something with it.
> My one recollection was that the command language was horribly
We were a beta test site for NOS/VE and the hardware (Cyber 180?). CDC
sent the machine and a software support engineer to help us do something
with it. My one recollection was that the command language was horribly
awkward, but I didn't spend much time on the system.
I know there are some
I have a Decitek 442A9 papertape reader which needs repair.
I have already replaced the belt, but that is not enough. The reader behaves very strangely. It
starts running as soon as I apply power. And there is another problem: when I load a tape, it
rattles irregular during reading. This is
It was a loop hole in the strong typing of Pascal, not the operating system
itself. You could set up a record structure that mirrored the communications
area and then map this to location zero. This was important for Pascal since
it had no library mechanism, it was essentially a compile and
I assume you refer to the "case ... of" construct in PASCAL record types
which allowed you to arbitrarily "cast" - to use a C term - variables to
any type you wanted and could be (ab)used to assign integers to pointers.
The ability to call PP programs via RA+1 calls was not a loop hole, but a
I worked on the run time support for the early versions of Pascal on the CDC
6000 series. Depending upon the character set determining the end of line was
a major pain. There was a loop hole in the Pascal type system that allowed you
to call any PPU program directly from Pascal. It was not
18 matches
Mail list logo
