> It just occurred to me that it should be possible to write OCR software
> to read punchcards on your scanner. Not that I have any punchcards
> mind you, more of an intellectual exercise, but has anyone written
> such a thing?
Planning on it, as I think I know where there are some binary decks
containing bootstraps for some old RJE stations formerly used at
IU, and I'd like to preserve that software. I planned on scanning
the decks and then eventually writing such a utility or findind
someone who already had.
> Also, if you're desperate for a punchcard reader I suspect you could
> make an acceptable one with Lego Mindstorms. You'd have to use
> one of the popular input multiplexing schemes, and probably program it
> in nqc or legos, but it should be possible. Using the RCX's motor
> controllers and a couple motors and tires you should even be able to make it
> automatic feed. In fact, come to think of it, you SHOULD be able to
> build the thing with... lessee. two motors, a couple tires, and the
> light sensor. 'course your software on the RCX would have to translate
> awhat amounts to the scan of a card into data, but if the sensor is
> precise enough to tell holes from chads, I can think of a couple ways to
> do this.
Dr. Anthony Schaeffer built one that appeared in either BYTE or Interface
Age back in the 70s using a block of wood and what looked like hairpins.
You pulled the cards through manually, one at a time.
-dq
Hello,
I have the following problem. I want to open lif-files (created by my hp 3360 analysator) on my pc operating with Linux and WinNT, but this is impossible, it doesen?t work.I have no idea how to handle it.I?m looking for any information, documentations and codes/programmes refering to this problem which may help me.
Is it possible to solve my problem with RMB?
Please, would you be so kind (only if possible) and give me some advice, where I can get these information/how to handle ist?
Please send any information to my E-Mail Address: FlyingMadman(a)web.de
Thank you very much!
Robert
______________________________________________________________________________
Sie surfen im Internet statt im Meer? Selbst schuld!
Auf zum Strand: http://lastminute.de/?PP=1-0-100-105-1
I second the motion.
There have been examples recently where major libraries have microfilmed old
newspapers, then gotten rid of the originals. Researchers subsequently found
that much information had been lost due to such factors as the copies being
in B/W while the originals had color, the copies were of poor quality, and
the copies were only of the last edition of the day, where news/quotes that
had appeared in earlier editions was no longer included (presumably due to
pressure from the news subject).
For just two examples, see:
http://www.guardian.co.uk/uk_news/story/0,3604,402222,00.htmlhttp://reveille
.stumedia.lsu.edu/archives/november-2000/11-7-00/viewpoints/Richard.html
-----Original Message-----
From: Sellam Ismail [mailto:foo@siconic.com]
Sent: Friday, June 22, 2001 9:48 AM
To: classiccmp(a)classiccmp.org
Subject: Re: preserving / ressurecting old docs?
<snip>
I completely recommend AGAINST destroying the original. Not only is it in
some cases a historical artifact on its own, if the digital copy were ever
to be lost then you're SOL.
Sellam Ismail Vintage Computer
Festival
----------------------------------------------------------------------------
--
International Man of Intrigue and Danger
http://www.vintage.org
> Does anyone know where to find a punched card reader
> these days? I'm looking for a small desktop unit that
> I could interface to a PC.
I would be thinking that a sh*tload of them will be
available in Florida soon, as they have clearly
outlived their political acceptableness.
If any Floridian listers get a line on these (mostly
Documation readers, possibly various models) when
they become available, I'd like to try to get one,
particularly if Pr1me-color-schemed units are among
them.
-dq
> Does anyone know where to find a punched card reader
> these days? I'm looking for a small desktop unit that
> I could interface to a PC.
In the 1976-1978 timeframe my high school leased a desktop reader made
by H-P which would read either mark-sense or punched cards, and output
serial data. It was hooked up in tandem with an ASR33 Teletype for
access to a TOPS-10 timesharing system (BOCES NCODE on Long Island).
It made a goose like "honk" each time it read a card.
I've got some 8" disks that are apparently double density (the
manufacturer label says so). I thought they were Intel ISIS formatted
disks (which Eric Smith said would make them M2FM and uncompatible with
anything other than an Intel MDS development machine) but I'm not so sure,
since I can't seem to access any on the two Intel MDS systems I have set
up.
Both machines have Shugart 801 drives in them, and after doing some web
research, I've come to find out they are single-density only. This would
probably explain why I am not able to access these disks on these
machines.
The disks I am trying to access are supposedly CP/M, but the labelling
indicates they were perhaps used on an Intel development system (they have
filenames on the label with ".HEX" file types; this may not mean
anything). If this is the case, and they were formatted on an Intel MDS
(and therefore M2FM), and since they are double-density, then I may not be
able to read them with the machines I have.
However, I want to check their format on some CP/M machine and see if
perhaps I can read them. If so, then they are probably more standard DD
formatted diskettes, maybe even CP/M since that is what I was told they
are.
If they are in a standard DD format, and I have a computer that can boot a
DD CP/M system master, could I then pop these disks in the drive and do a
DIR to see if I get a directory?
For those who've used these before: when I put any of the disks in
question in the drive, the drive seems to seek for a few seconds, then
goes off for a split second, back on again for half a second, then off
(and the system crashes). The normal boot sequence for a (single density)
system disk is, upon reboot the disk seeks for a few seconds, then stops
for a split second, then starts seeking/reading for a few more seconds and
the ISIS prompt comes up.
It seems the system is trying to read the double density disks and just
not seeing anything intelligible and crashes. With single density
non-system diskettes, the machines will come up with something like "NOT A
SYSTEM DISK".
Suggestions appreciated.
Sellam Ismail Vintage Computer Festival
------------------------------------------------------------------------------
International Man of Intrigue and Danger http://www.vintage.org
Edwin:
Well, Win104 did not have DLLs, but it did have *.DRV drivers. The
balance of Windows was implemented as an overlay file (win100.bin) which has
a standard NE-style format. So, conventional Windows spleunking tools work.
Rich
==========================
Richard A. Cini, Jr.
Congress Financial Corporation
1133 Avenue of the Americas
30th Floor
New York, NY 10036
(212) 545-4402
(212) 840-6259 (facsimile)
-----Original Message-----
From: Edwin P. Groot [mailto:epgroot@ucdavis.edu]
Sent: Thursday, June 21, 2001 9:00 PM
To: classiccmp(a)classiccmp.org
Subject: Re: SDK for Windows 1.04??
George,
I don't think Windows 1.04 had DLLs! It ran in real mode and used
simple .EXE files as programs and nothing else.
Edwin
At 03:26 PM 6/21/2001 -0500, you wrote:
>Two different concepts. The DOS tech refs are refering to the values to
place in ah (I think, or was it al?) before making a DOS or BIOS int call.
This is all pre-DLL days. Richard is referring to
>the ordinal number within a DLL to reference a specific function located
in the DLL. Not all functions in a dll have their names exported and
sometimes the only way to get to them is by ordinal
>number. This is one way that M$ creates 'value added' to their software
by utilizing these undocumented calls.
>
>George
>
>On Thu, 21 Jun 2001 13:42:53 -0400, John Allain wrote:
>
>>From: Cini, Richard <RCini(a)congressfinancial.com>
>>
>>> most of the functions in the DOS Shell code (MSDOS.exe
>>> and MSDOSD.exe) are referenced by ordinal number
>>
>>Early (most?) DOS techinical reference
>>manuals listed function calls by numbers,
>>E.G. 10H = Close file. 01H = Keyboard input, etc.
>>Could this be it?
>>
>>John A.
Fred:
I've used sourcer for many years in other spleunking projects. Below
is some heavily snipped output from Windows Sourcer (this is the code
reached from the NE header of MSDOS.EXE):
;??????????????????????????????????????????????????????????????????????????
; MSDOS_10
;??????????????????????????????????????????????????????????????????????????
; Note: Subroutine does not return to instruction after call
1.0000 MSDOS_10 proc far
1.0000 mov si,364h
1.0003 loc_0003:: ; xref
1.0021
1.0003 ? xor ax,ax ; Zero
register
1.0005 push ds
1.0006 push si
1.0007 push ax
1.0008 push ax
1.0009 push ax
1.000A call far ptr GetMessage
1.000F or ax,ax ; Zero ?
1.0011 jz short loc_0004 ; Jump if
zero
1.0013 push ds
1.0014 push si
1.0015 call far ptr TranslateMessage
1.001A push ds
1.001B push si
1.001C call far ptr DispatchMessage
1.0021 jmp short loc_0003 ; (0003)
1.0023 loc_0004:: ; xref
1.0011
1.0023 mov ah,4Ch
1.0025 int 21h ; DOS
Services ah=function 4Ch
; terminate
with al=return code
MSDOS_10 endp
;??????????????????????????????????????????????????????????????????????????
; SESSIONWNDPROC
;??????????????????????????????????????????????????????????????????????????
1.0027 SESSIONWNDPROC proc far
PARAMETER_1 = 6 ; bp+6
PARAMETER_2 = 8 ; bp+8
PARAMETER_3 = 0Ah ; bp+0Ah
PARAMETER_4 = 0Ch ; bp+0Ch
PARAMETER_5 = 0Eh ; bp+0Eh
LOCAL_2 = -4 ; bp+0FFFCh
LOCAL_1 = -2 ; bp+0FFFEh
{snippage}
You can see that the first two routines contained in MSDOS are
exported differently. The first one is MSDOS_10, the second is
SESSIONWNDPROC. If you look at the NE header, MSDOS.EXE only exports window
procedures by name. Everything else is by ordinal. MSDOS_10 above is clearly
the WinMain (the main message loop--notice the calls to GetMessage,
TranslateMessage and DispatchMessage). SESSIONWINDPROC is the main windows
procedure.
The MSDOSD.EXE file really only includes the equivalent code for
FORMAT and SYS.
I just thought that the Win104 SDK would have some helpful
information in it that may aid in renaming these MSDOS_XX calls.
Rich
==========================
Richard A. Cini, Jr.
Congress Financial Corporation
1133 Avenue of the Americas
30th Floor
New York, NY 10036
(212) 545-4402
(212) 840-6259 (facsimile)
-----Original Message-----
From: Fred Cisin (XenoSoft) [mailto:cisin@xenosoft.com]
Sent: Thursday, June 21, 2001 9:38 PM
To: 'ClassCompList'
Subject: Re: SDK for Windows 1.04??
On Wed, 20 Jun 2001, Cini, Richard wrote:
> Hello, all:
> I was paging through some Sourcer listings that I have of the
> Windows 1.04 code and noticed that most of the functions in the DOS Shell
> code (MSDOS.exe and MSDOSD.exe) are referenced by ordinal number and not
> function name ("MSDOS_23" versus "DoSomeThing"). So, I was wondering if
> anyone had a copy or knows the existence of SDK documentation for Windows
1.
"Sourcer listings" are disassemblies.
You don't want, or need Win SDK for THIS (plenty of use for it for other
stuff!)
What you need is a copy of the DOS Technical Reference, or ANY of the
after-market programmer's references, that will provide you a list of the
MS-DOS (aka INT 21h) functions, so that you can substitute
"DoSomething" in lieu of function "23".
Note: the DOS Technical Reference consists of what used to be the
appendices of the DOS manual in version 2.00 and below. In version 2.10,
they did an appendectomy.
BTW, Norton refers to the functions by DECIMAL numbers, whereas the entire
civilized world always refers to them in hexadecimal. For example,
function 30h of INT 21h reports DOS version, (as opposed to function 48 of
int 33 in Norton-speak)
--
Grumpy Ol' Fred cisin(a)xenosoft.com
Fred:
I'm using the Windows Sourcer program from V Communications. WinSrc
has the ability to generate an import library from any Windows program by
scanning the "exported functions" portion of the file header. So, running
this on kernel.dll would produce a listing of the exported function names.
Some functions are not exported by name, but by ordinal number only. These
are referenced in module.ordinal format (such as "kernel.34"). So,
subroutines disassembled by Sourcer are labeled with their real name
("GlobalLock") or if the name is not available, the ordinal ("KERNEL_34").
This utility works on any Windows program using the NE, P3, LE, or
PE type headers.
My whole point was that the 1.04 SDK would probably give me some
clues as to what the MSDOS_XX functions are since very few are exported by
name. Windows programs were not supposed to call down into MSDOS.EXE or
MSDOSD.EXE (the rough equivalent to win386.exe or vmm.vxd in current
versions), Microsoft exported most functions by ordinal.
Rich
==========================
Richard A. Cini, Jr.
Congress Financial Corporation
1133 Avenue of the Americas
30th Floor
New York, NY 10036
(212) 545-4402
(212) 840-6259 (facsimile)
-----Original Message-----
From: Fred Cisin (XenoSoft) [mailto:cisin@xenosoft.com]
Sent: Thursday, June 21, 2001 11:06 PM
To: classiccmp(a)classiccmp.org
Subject: Re: SDK for Windows 1.04??
On Thu, 21 Jun 2001, George Currie wrote:
> Two different concepts. The DOS tech refs are refering to the values
> to place in ah (I think, or was it al?) before making a DOS or BIOS
> int call. This is all pre-DLL days. Richard is referring to the
> ordinal number within a DLL to reference a specific function located
> in the DLL.
He is referring to the number reported by his disassembler that is
disassembling the Windoze program (into DOS compatible assembly language).
The value placed in AH IS for the purpose of referencing a specific
dunction located in the MS-DOS DOS function handler (INT 21h).
> Not all functions in a dll have their names exported and
> sometimes the only way to get to them is by ordinal number. This is
> one way that M$ creates 'value added' to their software by utilizing
> these undocumented calls.
And there were/are a few undocumented functions in MS-DOS, such as #34h,
and INT 28. And don't forget the "network redirector" (since 3.10) that
is needed even to use MS's CDROM drivers.
--
Fred Cisin cisin(a)xenosoft.com
XenoSoft http://www.xenosoft.com
PO Box 1236 (510) 558-9366
Berkeley, CA 94701-1236
