In the next week, I should be cutting a few bootable HP diagnostic library
discs for both 7900 and 7905/6 media.
If someone is in dire need to replace their properly licensed diagnostic set
& media, contact me off-list.
Jay
---
[This E-mail scanned for viruses by Declude Virus]
The reason the subject is for "Software Users" is that ""Hardware Users"
will probably want to use ONLY standard DEC distributions of RT-11
which sufficiently exercise the real PDP-11 hardware. The goal of this
post is to reach and elicit comments from all of those hobby RT-11
Users who want the bugs fixed and / or want some enhancements.
I suppose that it might even be possible that there are some commercial
RT-11 users who might be interested, but at this point I am not aware
of any and doubt very much that any commercial RT-11 users would be
sufficiently interested. BUT, if you are still there, it might still be possible
to accommodate the commercial side.
The ISO file for a CD with 13 RT-11 distributions is available for download at:
http://www.classiccmp.org/PDP-11/RT-11/dists/
The file is: RT11DV10.ISO.zip
The CD contains 13 RT-11 distributions from V01-15 up to V05.03 under
both the ISO9660 file structure along with 4 RT-11 directories for the
4 RT-11 partitions on the CD. A rather unique aspect of the CD is that
none of the files in the ISO9660 file structure are duplicated. The RT-11
directory entries point to the same location on the CD for the same
file in each case. In addition, if SIMH is able to ATTACH the CD as
as single file, then it will be possible to actually BOOT the CD under
RT-11. Otherwise, just BOOT the container file RT11DV10.ISO, after
it is copied to the hard drive (UnZipped actually), under RT-11 as in:
ATTACH RQ0: RT11DV10.ISO
SET RQ0: LOCK
BOOT RQ0:
It is STRONGLY recommended that NO changes of any kind be
made to the ISO file under RT-11, even by experienced RT-11 users.
The reasons are explained in the 2 README files.
NOTE that all of the images for the RK05 and RL02 media have been
truncated - all of the contiguous blocks with zeros at the end of the
file image have been removed. The primary reason was so that more
of these file images would fit on each RT-11 partition. Specifically,
since all RL02 file images are 20,450 blocks, ONLY 3 would fit on
each RT-11 partition. In addition, even if the full image of 20,450
blocks were present, it would still not be possible to use each file as
a correct file image in all situations under SIMH since the system
area needed for the INITIALIZE command under RT-11 would
NOT be present. IF the RT-11 user wishes to copy the truncated
file image to a "fully functional" RL02 container file to be used under
SIMH, then copy the file ZEROSDL.DSK at the end of the CD as in:
C:\>COPY D:ZEROSDL.DSK C:RT11V5.03
C:\>PDP11
simh>ATTACH RL0: D:RTV5RL.03
simh>SET RL0: LOCK
simh>ATTACH RL1: C:RT11V5.03
simh>BOOT RL0:
COPY/DEVICE DL0: DL1:
NOTE that the file ZEROSDL.DSK was created by using PUTR to:
(C:\)>FORMAT ZEROSDL.DSK/RL02
A big thank you to John Wilson at: http://ww.dbit.com/pub/putr/
For those RT-11 users who have a legal license to run RT-11 under
E11, there are two alternatives. If the user has a DVD drive or CDROM
drive which allows the first 64 blocks (16 CD sectors) to be read under
E11, the it is possible to MOUNT the complete CD as an image as in:
E11>MOUNT DU0: CDROMD:/RONLY
Of course, it is also possible use the actual ISO image file of the CD as in:
E11>MOUNT DU0: C:RT11DV10.ISO/RONLY
OR, if the files are on a CD and the user prefers:
E11>MOUNT DL0: D:RTV5RL.03/RONLY
Depending on the option that the user prefers, the complete text would be:
C:\>COPY D:ZEROSDL.DSK C:RT11V5.03
C:\>E11
E11>MOUNT DU0: CDROMD:/RONLY
E11>MOUNT DL1: C:RT11V5.03
E11>BOOT DU0:
COPY/DEVICE/FILES DU0:RTV5RL.03 DL1:
If anyone requires any help in using V1-0 of the CD, please ask!!!!!!!!
MY BACKGROUND
--------------
I am an RT-11 software addict. I don't know why, but maybe a partial
answer is because I have OCB (Obsessive Compulsive Behaviour). In
any case, I have used RT-11 off and on for almost 30 years (mostly ON)
since I started with V02 of RT-11. I can't remember a single year, since,
when I did not use RT-11 some of the time and some years I probably
spent more than 4000 hours designing, writing and debugging RT-11
software. I am presently in the midst of fixing bugs and making some
of the enhancements mentioned below.
PURPOSE OF THIS POST
-----------------------
This point is to ask if there are any RT-11 users, either active or inactive,
who want to see any of the RT-11 bugs fixed along with enhancements
added. While I believe that these news groups are the best means of
making contact, perhaps others exist as well. PLEASE mention any
other method of contacting RT-11 users. INDEED, PLEASE forward
this message to them if you know of any other RT-11 users who may
still be interested.
LIST OF ITEMS TO BE CONSIDERED
-----------------------------------
(a) Bugs! There are a (large??) number of bugs, some of which are
able to crash RT-11. Identifying them (probably the biggest part of the
problem) as well as fixing them will be a large part of the effort.
(b) Enhancements are also very important. Just a few are:
- A Path Handler
- Enhancements to the MSCP device driver
- Enhancements to the SL: (Single Line Editor)
- Y2K for older versions followed by Y9K
- Enhancements to the BINCOM program
- Enhancements to the VBGEXE program
- Allow use of SET commands with ANY file
- Increase the precision of the TIME command to 1 tick followed by 1 msec
- Being able to BOOT an LD: file
While I am aware of a VERY small number of RT-11 users, the
more that are still interested, the more ideas that can be generated.
Please reply, either by private e-mail (first fix my munged e-mail
address since the original e-mail address is no longer active) or
else send a post and I will reply privately if so requested.
I am also sending this post to classiccmp.org, so if you are a member
of that list, you can reply either to that list or directly to me in a private
manner if you so choose.
Sincerely yours,
Jerome Fine
--
If you attempted to send a reply and the original e-mail
address has been discontinued due a high volume of junk
e-mail, then the semi-permanent e-mail address can be
obtained by replacing the four characters preceding the
'at' with the four digits of the current year.
>From: "Steve Thatcher" <melamy(a)earthlink.net>
>
>what is wrong with making things easier?
---snip---
Hi
I'm not saying to make it impossible to do, just that it shouldn't
be considered as a primary purpose. Using an extendable language
like I've suggested, one can add such features. Part of the problem
is that when someone creates the archive, they may not even know
the file structure of the disk. I would expect the specification
to be broad enough to allow such. Still, the primary thing is
to be able to recreate the original material.
To me this means that any input to some emulator may mean that
it requires some post processing. How would one know what some
some format a particular emulator wanted? How would a person always
know how to read the directory structure and be able to extract
files? If one wanted to work in all cases, I'd expect that the
person writing the emulator would provide the needed post processing
to extract such information. Otherwise, they'd only be able to
read archives of disk that were specifically created for their
system. Those archives that the person didn't know the file
structure would be useless unless.
Such things are secondary functions. They shouldn't be restricted
>from being used, it is just that the primary function should
be to capture the entire information in as close to the original
format as possible. Creating post processors could easily be
done as a separate outside function for special purposes.
Dwight
Hi
Nether of these formats is totally a match for what we need.
These are all just data image formats for bits. None of these
describe the format of the bits. We can use the parts of these
specifications we like but what ever we use will still be
embedded as part of a larger file format. As Sellam says, that
format needs to be extendable to handle anything that comes
along. Both Intel HEX and Motorola S formats are such a small
part of the picture.
One thing that could be done but I'm sure many will think
I'm crazy. If the files contained OpenBoot source code to describe
the data, one can then create almost anything one wants.
This would be something like how postscript files are done now.
These file would have code that would transform the data into
whatever format the user needed. One could extract the bit
stream to feed as raw information to a drive or simply extract
the sector data. Using something like OpenBoot code has the
advantage that the source is human readable, just as postscript
is human readable ( although tedious ).
There could be some guide lines on standard ways to describe
common formats. These would also help other describe more
obscure formats.
We need to remember that what normally comes out of a floppy
controller chip is not the actual data on the disk. The information
on the disk is a more complex. It contains things like special
marks for indexing, headers and even errors. These need to
be represented as well. We need to be looking at capturing the
raw data from the disk. And at methods of post processing this
to a form similar to what comes from the floppy controller.
Dwight
>From: "David V. Corbin" <dvcorbin(a)optonline.net>
>
>You might want to consider Motorola rather than Intel.
>The only reason I suggest this is the motorola format alread has a (semi)
>extensible record type description [the second char of each line].
>
>S2 and S3 are already defined for 16MB and 4GB memory spaces...
>
>A (non-standard) record type "could" be used for media format, etc...
>
>Just my 16.3875 milli-EUR comment...
>
>>>> -----Original Message-----
>>>> From: cctalk-bounces(a)classiccmp.org
>>>> [mailto:cctalk-bounces@classiccmp.org] On Behalf Of Cini, Richard
>>>> Sent: Wednesday, August 11, 2004 10:02 AM
>>>> To: 'General Discussion: On-Topic and Off-Topic Posts'
>>>> Subject: RE: Let's develop an open-source media archive standard
>>>>
>>>> I haven't read the entire thread on this but I did read
>>>> Steve Thatcher's idea and it describes about where I was
>>>> coming out on this myself.
>>>>
>>>> I might have missed what the ultimate use of this archive
>>>> would be. Will the archive be used to (1) re-generate
>>>> original media; (2) operate with emualtors; (3) both?
>>>>
>>>> To ensure integrity of the data I would propose recording
>>>> the data in the Intel Hex format -- it's text-based and has
>>>> built-in CRC. Now, we'd have to modify the standard format
>>>> a bit to accommodate a larger address space and to add some
>>>> sort of standardized header (a "Hardware Descriptor"). This
>>>> data would be used by the de-archiver to interpret the
>>>> stream of data read from the data area (the "Hex Block").
>>>>
>>>> I agree that a multi-layer approach offers the best
>>>> combination of platform neutrality and portability. I don't
>>>> really know if we need two or three layers as Steve
>>>> described to describe the file in a standard fashion. Using
>>>> an Intel Hex-like format would increase the "de-archiving"
>>>> time, but in my view it's a fair trade-off. De-archiving
>>>> software could translate the platform-neutral file into
>>>> another format better suited for use in emulators.
>>>>
>>>> I think that we should start compiling a list of the
>>>> various media we want represented and how that media is
>>>> organized natively. I don't mean "well, it has blocks and
>>>> sectors" either. We should examine the exact format down to
>>>> the actual numbers (i.e., "2048 blocks of 256-bytes
>>>> recorded twice"). Seeing how the various data stores are
>>>> organized should bring some clarity to how we should represent it.
>>>>
>>>> Just my $0.02.
>>>>
>>>> Rich
>>>>
>
>
While reading through an old (1979) book, I came across a reference to a Tandy 10 system (complete with picture), as an example of "turnkey systems". Judging from the date of publication, I presume this is some precursor to the TRS-80, but I have not been able to dig up any more info on it. Has anyone else ever heard of such a computer before, and could you share your info, please?
--T
Jam the computer...trash every lethal machine in the land! -- Timothy Leary
Dave:
I tend to forget about the Motorola format (call me an Intel snob).
The 16mb would be enough for many systems, and I would hope that 4gb would
be enough, at least for now, to represent the largest of the media types we
want to represent.
Rich
-----Original Message-----
From: cctalk-bounces(a)classiccmp.org
[mailto:cctalk-bounces@classiccmp.org]On Behalf Of David V. Corbin
Sent: Wednesday, August 11, 2004 10:34 AM
To: 'General Discussion: On-Topic and Off-Topic Posts'
Subject: RE: Let's develop an open-source media archive standard
You might want to consider Motorola rather than Intel.
The only reason I suggest this is the motorola format alread has a (semi)
extensible record type description [the second char of each line].
S2 and S3 are already defined for 16MB and 4GB memory spaces...
A (non-standard) record type "could" be used for media format, etc...
Just my 16.3875 milli-EUR comment...
>>> -----Original Message-----
>>> From: cctalk-bounces(a)classiccmp.org
>>> [mailto:cctalk-bounces@classiccmp.org] On Behalf Of Cini, Richard
>>> Sent: Wednesday, August 11, 2004 10:02 AM
>>> To: 'General Discussion: On-Topic and Off-Topic Posts'
>>> Subject: RE: Let's develop an open-source media archive standard
>>>
>>> I haven't read the entire thread on this but I did read
>>> Steve Thatcher's idea and it describes about where I was
>>> coming out on this myself.
>>>
>>> I might have missed what the ultimate use of this archive
>>> would be. Will the archive be used to (1) re-generate
>>> original media; (2) operate with emualtors; (3) both?
>>>
>>> To ensure integrity of the data I would propose recording
>>> the data in the Intel Hex format -- it's text-based and has
>>> built-in CRC. Now, we'd have to modify the standard format
>>> a bit to accommodate a larger address space and to add some
>>> sort of standardized header (a "Hardware Descriptor"). This
>>> data would be used by the de-archiver to interpret the
>>> stream of data read from the data area (the "Hex Block").
>>>
>>> I agree that a multi-layer approach offers the best
>>> combination of platform neutrality and portability. I don't
>>> really know if we need two or three layers as Steve
>>> described to describe the file in a standard fashion. Using
>>> an Intel Hex-like format would increase the "de-archiving"
>>> time, but in my view it's a fair trade-off. De-archiving
>>> software could translate the platform-neutral file into
>>> another format better suited for use in emulators.
>>>
>>> I think that we should start compiling a list of the
>>> various media we want represented and how that media is
>>> organized natively. I don't mean "well, it has blocks and
>>> sectors" either. We should examine the exact format down to
>>> the actual numbers (i.e., "2048 blocks of 256-bytes
>>> recorded twice"). Seeing how the various data stores are
>>> organized should bring some clarity to how we should represent it.
>>>
>>> Just my $0.02.
>>>
>>> Rich
>>>
Hi
I sure that there was a FIG-86 listing done( would run
on a 8088 ). There is also a large Forth that runs under
DOS called FPC that is available over the net. For those
that want to create there own smaller '86 Forth, there
is a tool called TCOM ( by the same author ) that creates
COM files. Since these are just code, they can be made
to work on any '86 compatible platform. With minor changes,
any target processor can be used( I've used it to create
8051 and Z80 code ). As I recall, the release comes with
a number of examples of targeting for other machines.
It was mentioned that a Forth could be as small as 32K.
I've done quite a few that run in less that 8K of space
( 6K ROM and 2K RAM ). If one doesn't need the interpreter
and compiler, 2K systems are quite practical for many
applications. These are often done as tethered systems
where something like a PC has the compiler and interpreter.
The application machine only needs a way to read/write
memory, execute and break execution.
Dwight
>From: "Stan Barr" <stanb(a)dial.pipex.com>
>
>Hi,
>
>ben franchuk <bfranchuk(a)jetnet.ab.ca> said:
>> Tony Duell wrote:
>>
>> > Cheating a bit, but how about FIGforth? I believe it is truely public
>> > domain, and as it runs on the bare metal, it could be claimed to include
>> > the OS. I assume there was/is a version of the 8088.
>>
>> Yes, but try and find it today. Fig forth is for the 8080 and 6502 with I/O
>> supplied by the user and ASM source. While I suspect you can get a
>> version for the 8088 I don't expect you can get the source for it.
>> Read keyboard, test keyboard ready, print to screen, read disk block,
>> write disk block I think is all that is needed.
>> Ben.
>
>Versions of FIGForth were available for quite a few processors.
>I've got it running on simh emulating a PDP-11 and I'll copy it
>to my Micro 11/73 as soon as I can persuade it to read floppys
>written by putr. I'm running it under RT-11 but it can be compiled
>to run stand-alone.
>
>It's quite possible that FigUK may have a FIG listing in their library
>and I've possibly got a TRS-80 version somewhere.
>--
>Cheers,
>Stan Barr stanb(a)dial.pipex.com
>
>The future was never like this!
>
>
>
Hi
Again, these are archive files. First preserve the media information.
If ones wants, one can add other features. Emulators that don't
provide some level of I/O interface at a low level usually don't
work well for all programs. Emulators should as a minimum, provide
a BIOS level interface ( if such exist ). Even this may not
be low level enough. If someone writes an emulator that sees things
at such a high level as simply files, it will most likely be
useless for anything but the simplest programs that could have
run on almost any platform.
None of the emulators that I've used so far have been at such a
high level of I/O. They have all understood drive, track and sector.
If you wish to create such an emulator, you can alway post process
the archive data ( once ) into whatever format is convenient. There
is no particular reason to make archive files emulator friendly.
As I've proposed, adding built in language definitions, one could
add special purpose functions to do things like extract files
based on directory entries. Even if not directly used, existing
as source in the archive could provide the emulator writer the
methods needed to do such them selves.
I'm not saying that we should specifically restrict such from
being in the archive file, just that I still don't see why
a proper emulator would require such.
IMHO
Dwight
>From: "Steve Thatcher" <melamy(a)earthlink.net>
>
>would you rather have one format that allows for easy data access and
re-creation of media or only be able to re-create media and have a difficult
interface in EVERY emulator that needs to access the data? From a usage
standpoint, I think putting the burden on the emulators is not a reasonable
approach. There are a variety of emulators available do not have to deal with
track sector access of information. One uses an import command to bring ms-dos
files in for example. To have to write an outside utility that has to know what
the image file type is, know the physical layout of the disk, know how the OS
accesses files on the disk just to retrieve file data is not a good idea. leave
the OS access to the real platform or emulators that want to deal with actual
tracks and sectors.
>
>best regards, Steve Thatcher
>
>-----Original Message-----
>From: "Dwight K. Elvey" <dwight.elvey(a)amd.com>
>Sent: Aug 11, 2004 3:05 PM
>To: cctalk(a)classiccmp.org
>Subject: Re: Let's develop an open-source media archive standard
>
>
>>From: spc(a)conman.org
>>
>>It was thus said that the Great Vintage Computer Festival once stated:
>>>
>>> HOWEVER, this makes it very difficult to use the imagefile on an emulator.
>>> To use the floppy disk example again, if the emulator wants Track 14
>>> Sector 8 (or Block 417) but it has not been explicitly laid out in the
>>> imagefile because it was originally zeroes, then the emulator, if poorly
>>> designed, may crap out.
>>
>> Are you trying to create an archive format, or a format that is to be used
>>by emulators? I say skip the emulators and concentrate on archival
>>purposes. An emulator can then use the archive format to create a disk
>>image in whatever internal format it requires.
>>
>> Don't complicate the problem.
>
> I agree. We only need to provide a format that could be converted
>for a specific emulator, not necessarily one that can be conveniently
>read by an emulator.
>Dwight
>
>>
>> -spc (And don't try to become everything for everybody ... )
>>
>>
>>
>>
>
>
>
>
Just for grins, I went to google & typed in "greenbar paper" - and the 3rd
or 4th link was this:
http://www.business-supply.com/dept/2005280/sparco-1-2-green-bar-computer-p…
They have 18 & 20 lb. greenbar paper, 8.5" and 11" deep, narrow &
widecarriage (in each) and they even carry carbonless 2-part! Prices range
>from $33/carton to $90/carton.
Dunno if the prices are any good or not, but I did notice their "over $25
order gets free shipping" banner prominently displayed - I'm sure shipping
this schtuff ain't cheap, so it might be a decent deal...
Me? Don't need it... even all my dot-matrix printers had cut-sheet feeders
on 'em... ;-)
=-=-=-=-=
That said, what I *have* been looking for (and google turned up nothing the
last 3 times I checked) is a set of:
Greenbar Bedsheets.
I'd doubt they're still made, and it seems they weren't that popular when
they were, as they certainly didn't make a big mark on google or history,
it seems.
Ah well... one can dream, right?
Laterz,
Roger "Merch" Merchberger
--
Roger "Merch" Merchberger --- sysadmin, Iceberg Computers
zmerch(a)30below.com
Hi! I am a .signature virus. Copy me into your .signature to join in!
>From: "Steve Thatcher" <melamy(a)earthlink.net>
>
>
>I realize that the idea is to create a format to make re-creation
>of media possible for a variety of platforms. We can certainly do
>that and have its only function be to maintain a physical data format.
>My added idea is that the data and the formatting be separated so
>that a simple utility on a non-target platform could extract data
>from the image file.
>
>If we create a physical description only and do not abstract the data
>then any emulator must understand the OS file structure in order to
>retrieve any internal file representation. My idea would make the
>file re-creation simple in that the xml image file would be parsed
>for the actual file data that an emulator would need. This makes
>the emulator easier.
No, this is to archive the disk, not to make life easy for emulators.
Again, you assume that the data is files. Also, anyone making such an
emulator will surely know how to find files ( if they exist ) in an
image of the disk. Most emulators include the BIOS and such. The
emulator that we have in the H8 group simply uses the BIOS code
and the boot code from the disk to find file ( as it should ). It
just needs raw data. The emulator I/O is just tracks and sectors,
not files.
>To retrieve a file from the physical layout that it at the end of this
>message, >the emulator must know the actual disk format that is used on
>the target system (the one the image file was made for). I have seen
>cp/m systems where the actual physical sectors were sequential on disk
>and the OS file sector was actually virtual to increase speed. Not my
>idea of the way to do it. It is much easier to make the physical
>sectors slewed so that a physical sector is a file sector. These
>are the types of issues you will have to overcome if an emulator
>must totally understand each and every file system for a cp/m
>version for example.
Like I said, the archive file can include sufficient information to extract
the data in any form that you'd like but it must as a minimum be able to
recreate the physical disk. It may take some human to actually make the
physical media generator but the data in the file should be sufficient
to do that. This is not an easy task and goes beyond simply finding files
in the raw data.
Dwight
>
>Sellam, let me know if you would like to discuss this via telephone >
so I can convery the idea that I am proposing.
>
>best regards, Steve Thatcher
>
>-----Original Message-----
>From: Vintage Computer Festival <vcf(a)siconic.com>
>Sent: Aug 11, 2004 3:00 PM
>To: Steve Thatcher <melamy(a)earthlink.net>,
> "General Discussion: On-Topic and Off-Topic Posts"
<cctalk(a)classiccmp.org>
>Subject: RE: Let's develop an open-source media archive standard
>
>On Wed, 11 Aug 2004, Steve Thatcher wrote:
>
>> I agree with Sellam on the point about using it both for media
>> re-creation and emulation. The trouble with the approach below of just
>> using raw data on a track sector basis is that now you have created a
>> file that can only be used with an emulator that understands the
>> physical format and OS access for the computer system you are emulating.
>
>That is the point, really. What we are attempting to do is describe as
>faithfully as possible a physical media with logical data in a purely
>logical form. The goal would be that the physical media could be
>re-created from the imagefile if need be. The parameters of the physcial
>media are specified so that this can be possible.
>
>> My earlier point of separating the data and the format information
>> allows a single file (that would not be much bigger that the one
>> described below) to contain multiple platform specific files that can be
>> "read" by a simple utility that does not require any knowledge of the OS
>> or the platform.
>
>I'm not quite understanding you here. Or maybe I am. An image in the
>format shown below could be read by any emulator. Making sense of the
>data with respect to that emulator is a different issue altogether, but it
>does make it possible for, say, a Northstar Horizon emulator to load up an
>Apple ][ disk image and then try to access it.
>
>Anyway, I don't think I am quite getting the point you are trying to make.
>
>
>> <MEDIA TYPE=FLOPPY SIZE=5.25 SIDES=1 DENSITY=SINGLE FORMAT=GCR TRACKS=35
>> SECTORS=16 SECTORSIZE=256>
>>
>> <VOLUME>Apple ][ System Disk</VOLUME>
>>
>> </MEDIA>
>>
>>
>> <DATA>
>> <TRACK 0><SECTOR 0>
>>
>> HERE WOULD BE THE ASCII HEX DATA FOR TRACK 0, SECTOR 0
>>
>> </SECTOR></TRACK>
>>
>> ...
>>
>> <TRACK 34><SECTOR 15>
>>
>> HERE WOULD BE THE ASCII HEX DATA FOR TRACK 34, SECTOR 15
>>
>> </SECTOR></TRACK>
>> </DATA>
>
>--
>
>Sellam Ismail Vintage Computer Festival
>------------------------------------------------------------------------------
>International Man of Intrigue and Danger http://www.vintage.org
>
>[ Old computing resources for business || Buy/Sell/Trade Vintage Computers ]
>[ and academia at www.VintageTech.com || at http://marketplace.vintage.org ]
>
>
>
>From: "Vintage Computer Festival" <vcf(a)siconic.com>
---snip---
>>
>> or E5h? (fill byte for "no data" on CP/M formatting)
>> or F6h?
>> rather than "leave out" any sections that are just zeroes,
>> put in a tag that says "x 00's", "x E5's", etc.
>
>Well, sure. But then I went on to imply that this method has problems
>(one of which you just pointed out).
>
>Still, it bears consideration.
>
Hi
Using the Postscript like concept, one would have a compactor
word defined earlier in the file such that simple syntax like:
EXPAND 512 E5 would be able to create a block of 512 E5's
Of course one might want to keep a consistant radix like:
EXPAND 200 E5
But that is not neccessary if the word EXPAND was first defined
as such.
Also such things as copy protection where a sector size has
been changed on a track might be encoded as:
SECTOR_SIZE 512 SECTOR_DATA 0 xxx..xxx SECTOR_SIZE 256
SECTOR_DATA 1 xx....xxx etc.
The Archive file could include a simple glossary of the externally
defined words that are in common use while still being internally
extended to cover special cases.
Dwight
>From: spc(a)conman.org
>
>It was thus said that the Great Vintage Computer Festival once stated:
>>
>> HOWEVER, this makes it very difficult to use the imagefile on an emulator.
>> To use the floppy disk example again, if the emulator wants Track 14
>> Sector 8 (or Block 417) but it has not been explicitly laid out in the
>> imagefile because it was originally zeroes, then the emulator, if poorly
>> designed, may crap out.
>
> Are you trying to create an archive format, or a format that is to be used
>by emulators? I say skip the emulators and concentrate on archival
>purposes. An emulator can then use the archive format to create a disk
>image in whatever internal format it requires.
>
> Don't complicate the problem.
I agree. We only need to provide a format that could be converted
for a specific emulator, not necessarily one that can be conveniently
read by an emulator.
Dwight
>
> -spc (And don't try to become everything for everybody ... )
>
>
>
>
>From: "Vintage Computer Festival" <vcf(a)siconic.com>
>
>On Wed, 11 Aug 2004, Dwight K. Elvey wrote:
>
>> One thing that could be done but I'm sure many will think
>> I'm crazy. If the files contained OpenBoot source code to describe
>> the data, one can then create almost anything one wants.
>
>I'm not familiar with OpenBoot. Can you explain this a bit more?
Hi
OpenBoot is the coding method used to bring up Sun workstations.
It is normally used to interpret byte codes stored in the ROMs
of various boards that plug into a SUN box. The idea is that
the board configures itself by executing a non-platform dependent
code. The platform supplies the information, such as where the
next avaialble address space is and the board then allocates what
it needs.
One doesn't need to encode as byte code because there is also
and interpreter. This is the part I think is most valuable.
Unlike XML, Forth like languages are truly extendable to a
greater degree. The richness of the primitives is what counts here.
There is also the fact that even a mediocre programmer can
implement a Forth like interpreter where as something like
XML is easier to read but because it contains higher level
syntactical rules needs a more complicated interpreter.
The problem is that in the future, one needs to provide the
simplest method of describing that can be implemented the
easiest. Forth like interpreters follow simple rules:
1. Every thing that is separated with white space is a word.
2. As one comes across a word, left to right, one executes it.
Forth adds one more step that I don't necessarily recommend.
If it comes to a word that it doesn't understand, it tries to
read it as a number. I believe that this is not necessary.
The advantages are such that most any form of encoded data
( in ASCII ) can follow. The file itself can then convert to
other formats. Things like simple compaction can even be added.
>
>> We need to remember that what normally comes out of a floppy
>> controller chip is not the actual data on the disk. The information
>> on the disk is a more complex. It contains things like special
>> marks for indexing, headers and even errors. These need to
>> be represented as well. We need to be looking at capturing the
>> raw data from the disk. And at methods of post processing this
>> to a form similar to what comes from the floppy controller.
>
>There are multiple levels at which someone may want to archive a medium.
>There's the physical level, as you describe above. Then there's the level
>in between physical and logical, which is, to use the example of floppy
>disks again, tracks and sectors. And then there's the logical level which
>is an actual filesystem with a directory and filenames, etc.
>
>This spec should be designed to be able to handle all three types
>simultaneously within the same image file.
Agreed.
>
>What I mean is that it might be useful to have (to use a floppy disk as an
>example again) most of the disk encoded in a track/sector representation,
>but then have one particular track encoded at a bit level, because perhaps
>it contains special signatures that are part of a copy protection scheme.
>If the image is ever used to re-create the original physical disk, the
>binary data will be essential if the disk is going to actually be expected
>to work (unless the copy protection scheme is removed at that point).
Yep
Dwight
>
>--
>
>Sellam Ismail Vintage Computer Festival
>------------------------------------------------------------------------------
>International Man of Intrigue and Danger http://www.vintage.org
>
>[ Old computing resources for business || Buy/Sell/Trade Vintage Computers ]
>[ and academia at www.VintageTech.com || at http://marketplace.vintage.org ]
>
>
>From: "Vintage Computer Festival" <vcf(a)siconic.com>
>
>On Wed, 11 Aug 2004, Dwight K. Elvey wrote:
>
>> I can understand the need for both raw bit stream and extracted
>> data. I propose that it should always include both types of information.
>> The raw bits are needed to actually rebuild a particular format
>> but often the information in the data is all that one needs to extract.
>> In the case of the H8/89, we have working machines to read and write
>> the format. We just need the data that fills the sectors. In the case
>
>Sure. You can always take the imagefile and process it into a binary file
>that you then upload to the machine.
>
>I am not liking the concept of mixing ASCII and binary.
I'm not proposing the have raw binary. I agree that it all should
be in ASCII. What I'm talking about here is just the data as
compared with all of the actual information related to the
format of the transitions on the disk surface. The archive needs
both or an easy way to separate them.
Emulators only need the data where as recreating a disk needs
much more information.
Dwight
---snip---
>Sellam Ismail Vintage Computer Festival
Anybody know what this card is? It appears to be for an Apple II and
has two N-cell battery holders on it and a 20 pin and a 26 IDC header along
the top edge.
Joe
>From: "Cini, Richard" <RCini(a)congressfinancial.com>
>
>This example represents the block data using metatags...I guess along the
>"XML" part of the thread.
>
>I was thinking similarly to you but not using XML metadata:
>
>;Hardware descriptor
>MFGR
>MACHINE
>SUBTYPE
>DRIVETYPE (this of course defines what follows)
>;for floppy
>DRIVESIZE
>ENCODING
>TRACKS
>SECTORS
>SECTSIZE
>;HexData
>; Each record or group of records contains the related media data. The
>address record would be used for encoding the metadata
>00TTSSHH: (00-track-sector-head)
>
>I looked to Intel Hex (or Motorola) because it had built-in CRC facilities
>and it was human-readable ASCII. The drive and machine description could be
>encoded in special MOT records probably.
>
>XML is more a more "current" technology but I was trying to keep with the
>platform neutrality by sticking to text-only and not assuming the use of any
>other technology like XML.
>
>Rich
>
Hi
I like the use of OpenBoot like languages better than more natural
languages like XML or such. My primary reason is that the Forth
like languages are one of the few languages that syntax rules are
simple enough that anyone ( with some programming skills ) can
implement an interpreter. Also, the language is rich enough
that one can even include various converters and even things like
directory printout and file extractors inside the archive file it
self ( with minimal overhead ). This is the concept of a postscript
file. The file it self defines how to be printed with only a
few initial primitives that directly correspond to printing.
Without too much to go on, one could take the actual printout
of a postscript file and the file itself and be able to determine
the general rules for how do decode any postscript file. Kind
of like the rosetta stone concept.
We are talking about the maximum information in the smallest human
readable form.
Dwight
>From: "Steve Thatcher" <melamy(a)earthlink.net>
>
>I agree with Sellam on the point about using it both for media re-creation and
emulation. The trouble with the approach below of just using raw data on a
track sector basis is that now you have created a file that can only be used
with an emulator that understands the physical format and OS access for the
computer system you are emulating. My earlier point of separating the data and
the format information allows a single file (that would not be much bigger that
the one described below) to contain multiple platform specific files that can be
"read" by a simple utility that does not require any knowledge of the OS or the
platform.
>
>best regards, Steve Thatcher
Hi Steve
You seem to be assuming that the particular disk you are
archiving has a file structure. This is not always the case.
Dwight
no, I have only talked about data represented in xml ascii, that has three distinct sections. A overall structure that contains author, and other info. A data section that contains multiple data blocks with subsections that are identified as files, and finally, a third which describes the physical arrangement of the data blocks on some type of media.
best regards, Steve Thatcher
-----Original Message-----
From: Vintage Computer Festival <vcf(a)siconic.com>
Sent: Aug 11, 2004 2:53 PM
To: Steve Thatcher <melamy(a)earthlink.net>,
"General Discussion: On-Topic and Off-Topic Posts" <cctalk(a)classiccmp.org>
Subject: RE: Let's develop an open-source media archive standard
On Wed, 11 Aug 2004, Steve Thatcher wrote:
> I know a three section approach that I was proposing is more
> complicated, but from a code standpoint allows total freedom of data
> access without having to create a target media let alone have the
> computer system to then read the media just to get at the data that was
> on a floppy disk. The beauty is that if you need to create a Northstar
> system diskette then you can, but if all you need is a copy of the
> dump.asm program then you can get that also without having to go any
> further than the file you started with.
What you're discussing here are binary images.
--
Sellam Ismail Vintage Computer Festival
------------------------------------------------------------------------------
International Man of Intrigue and Danger http://www.vintage.org
[ Old computing resources for business || Buy/Sell/Trade Vintage Computers ]
[ and academia at www.VintageTech.com || at http://marketplace.vintage.org ]
XML is platform neutral, ascii and provides a structure to information rather than just an INI file type of dump - the start and end keywords let you define as many sub structures as you need.
best regards, Steve Thatcher
-----Original Message-----
From: Vintage Computer Festival <vcf(a)siconic.com>
Sent: Aug 11, 2004 3:23 PM
To: "General Discussion: On-Topic and Off-Topic Posts" <cctalk(a)classiccmp.org>
Subject: RE: Let's develop an open-source media archive standard
On Wed, 11 Aug 2004, Cini, Richard wrote:
> This example represents the block data using metatags...I guess along the
> "XML" part of the thread.
>
> I was thinking similarly to you but not using XML metadata:
>
> ;Hardware descriptor
> MFGR
> MACHINE
> SUBTYPE
> DRIVETYPE (this of course defines what follows)
> ;for floppy
> DRIVESIZE
> ENCODING
> TRACKS
> SECTORS
> SECTSIZE
> ;HexData
> ; Each record or group of records contains the related media data. The
> address record would be used for encoding the metadata
> 00TTSSHH: (00-track-sector-head)
>
> I looked to Intel Hex (or Motorola) because it had built-in CRC facilities
> and it was human-readable ASCII. The drive and machine description could be
> encoded in special MOT records probably.
I like the XML style because it's more explicit; more human-readable.
> XML is more a more "current" technology but I was trying to keep with the
> platform neutrality by sticking to text-only and not assuming the use of any
> other technology like XML.
XML is platform neutral because it's basically ASCII, right?
--
Sellam Ismail Vintage Computer Festival
------------------------------------------------------------------------------
International Man of Intrigue and Danger http://www.vintage.org
[ Old computing resources for business || Buy/Sell/Trade Vintage Computers ]
[ and academia at www.VintageTech.com || at http://marketplace.vintage.org ]
>From: "Jules Richardson" <julesrichardsonuk(a)yahoo.co.uk>
---snip---
>
>As for file size, if encoding as hex that at least doubles the size of
>your archive file compared to the original media (whatever it may be).
>That's assuming no padding between hex characters. Seems like a big
>waste to me :-(
>
---snip---
>Jules
>
>
Hi
It mightseem a waste but i would expect to see a proper archive
file to be 200% to 500% larger than the original data. Having the
data in something that can be printed directly on paper is a
must. This means something like HEX values or binary or whatever.
Still, anything as non-printable bits is useless.
JMHO
Dwight
Have there been any sort of list problems? I noticed a couple days ago that
I'd not gotten any messages since Saturday, but hadn't had time to do
anything about it. Well, about 370 so far just showed up.
Zane
>From: "Vintage Computer Festival" <vcf(a)siconic.com>
>
>On Tue, 10 Aug 2004, John Foust wrote:
>
>> Astounding! Will that computer never die? And I say that
>> as someone who Believed, '85-92.
>
>The Amiga is still going strong in some circles. More power to them.
>
>> I'm tempted to say that we should leave copy protection
>> hacks out of the spec for now, but if it was extensible,
>> that would be great.
>
>Yes, copy protection will defintely be able to be described naturally in
>the specification I have in mind. The spec should be able to define
>several layers of bit storage: logical (files, directories, etc.), byte
>(e.g. tracks, sectors), and raw (bit streams). In this way, copy
>protection schemes can be preserved by storing the image in the raw
>format.
>
>This will of course have to be thought out, and it may not even be
>included in the first revision of the spec, but as I declared originally,
>the spec will be extensible.
>
>--
>
>Sellam Ismail Vintage Computer Festival
Hi Sellam
I can understand the need for both raw bit stream and extracted
data. I propose that it should always include both types of information.
The raw bits are needed to actually rebuild a particular format
but often the information in the data is all that one needs to extract.
In the case of the H8/89, we have working machines to read and write
the format. We just need the data that fills the sectors. In the case
of the H8/89, I've written a bootstrap that can be entered through
the monitor commands. In some cases, the machine has no monitor or
bootstrapping method. In these cases, it would be necessary to create
the disk on another machine. Having the raw bits of clock and data
would then be valuable.
I'm currently looking at using a DSP chip to extract raw data from
disk. The biggest problem so far is that one needs to do one of two
things. One either needs to extract clocking operations with something
like a PLL or simply oversample the bit stream from the drive.
To do the PLL method, one needs to understand the disk format used
and have hardware to handle that particular format. The oversampling
has the advantage that one can capture all that is needed and post
process it to normalize the data. The disadvantage here is that it
takes a lot of data space. The DSP chip I'm looking at doesn't have
enough RAM space to capture an entire track. Capturing track fragments
has the issue that one needs realign things later. Knowing when
the two fragments are properly connected is not easy. It looks like
the newer DSP chips do have enough speed to capture raw data with
little or no external hardware. This means that one can get one
of the manufacture's development boards ( usually in the $50-$150
range ) and wire it up to the disk drive by connector.
The disadvantage here is that as newer chips come out, the older
development boards are obsoleted. Still, having the raw data means
that one can recreate the disk in the future, with some effort.
Dwight
This was posted on oldcomputers.net comments page, can
anyone help?
Please email rosy thomas directly:
rosy.thomas(a)talkbackthames.tv
hello,
we are working on a comedy series over here at
talkback - basically a pastiche of the old British
technology programme "Tomorrow's World" specifically
circa 1980. A script is currently being written which
includes a fictitious military super computer -
interest has been expressed in the stylistic beauty of
the Osbourne 1 and also the TRS-80 model III... I
expect you would not be interested in hiring your
computers to our production but I wonder if you could
advise me of any easy way to get hold of such rare
computers for our temporary purposes. We do have full
insurance public liability and otherwise. We start
filming on the 13th September for 6 weeks. I will
attempt e-bay and also explore all your links but if
you could advise me in any way I would be very
grateful. If you are interested there is information
about our first series on the www.bbc.co.uk. This was
a slightly different format in that it was a pastiche
on the open university programmes of the late
seventies. Thanking you in anticipation for any help
you can give me.
__________________________________
Do you Yahoo!?
Read only the mail you want - Yahoo! Mail SpamGuard.
http://promotions.yahoo.com/new_mail
I don't mean "machine address" but rather some sort of block address on the
media. I was thinking more on the lines of how data sectors on a hard drive
are numbered...not CHS numbering but "absolute sector" numbering from 0 to
something.
-----Original Message-----
From: cctalk-bounces(a)classiccmp.org
[mailto:cctalk-bounces@classiccmp.org]On Behalf Of Vintage Computer
Festival
Sent: Wednesday, August 11, 2004 2:00 PM
To: General Discussion: On-Topic and Off-Topic Posts
Subject: RE: Let's develop an open-source media archive standard
On Wed, 11 Aug 2004, Cini, Richard wrote:
> I tend to forget about the Motorola format (call me an Intel snob).
> The 16mb would be enough for many systems, and I would hope that 4gb would
> be enough, at least for now, to represent the largest of the media types
we
> want to represent.
The data should be structured in a way where address size does not even
come into consideration. Why would we encode platform specific
information into a media archive?
--
Sellam Ismail Vintage Computer
Festival
----------------------------------------------------------------------------
--
International Man of Intrigue and Danger
http://www.vintage.org
[ Old computing resources for business || Buy/Sell/Trade Vintage Computers
]
[ and academia at www.VintageTech.com || at http://marketplace.vintage.org
]
I agree with Sellam on the point about using it both for media re-creation and emulation. The trouble with the approach below of just using raw data on a track sector basis is that now you have created a file that can only be used with an emulator that understands the physical format and OS access for the computer system you are emulating. My earlier point of separating the data and the format information allows a single file (that would not be much bigger that the one described below) to contain multiple platform specific files that can be "read" by a simple utility that does not require any knowledge of the OS or the platform.
best regards, Steve Thatcher
-----Original Message-----
From: Vintage Computer Festival <vcf(a)siconic.com>
Sent: Aug 11, 2004 10:56 AM
To: "General Discussion: On-Topic and Off-Topic Posts" <cctalk(a)classiccmp.org>
Subject: RE: Let's develop an open-source media archive standard
On Wed, 11 Aug 2004, Cini, Richard wrote:
> I might have missed what the ultimate use of this archive would be. Will the
> archive be used to (1) re-generate original media; (2) operate with
> emualtors; (3) both?
Both. Emulators will certainly be able to make use of the archive by
having parsers built-in that can translate the archive data into
something the emulator can use. So instead of point the emulator to a
binary disk image, you would point it to an archive file and it would
translate the file back into tracks/sectors, or punch cards, or whatever.
> To ensure integrity of the data I would propose recording the data in the
> Intel Hex format -- it's text-based and has built-in CRC. Now, we'd have to
> modify the standard format a bit to accommodate a larger address space and
> to add some sort of standardized header (a "Hardware Descriptor"). This data
> would be used by the de-archiver to interpret the stream of data read from
> the data area (the "Hex Block").
I think you're thinking of this in terms of a large binary file encoded as
ASCII hex. If so, this is not what's being proposed. What is being
discussed is a format which actually describes the physical medium. For
example, on floppy:
<MEDIA TYPE=FLOPPY SIZE=5.25 SIDES=1 DENSITY=SINGLE FORMAT=GCR TRACKS=35
SECTORS=16 SECTORSIZE=256>
<VOLUME>Apple ][ System Disk</VOLUME>
</MEDIA>
<DATA>
<TRACK 0><SECTOR 0>
HERE WOULD BE THE ASCII HEX DATA FOR TRACK 0, SECTOR 0
</SECTOR></TRACK>
...
<TRACK 34><SECTOR 15>
HERE WOULD BE THE ASCII HEX DATA FOR TRACK 34, SECTOR 15
</SECTOR></TRACK>
</DATA>
> I think that we should start compiling a list of the various media we want
> represented and how that media is organized natively. I don't mean "well, it
> has blocks and sectors" either. We should examine the exact format down to
> the actual numbers (i.e., "2048 blocks of 256-bytes recorded twice"). Seeing
> how the various data stores are organized should bring some clarity to how
> we should represent it.
I agree. This would be useful. Does someone want to volunteer to do
this?
--
Sellam Ismail Vintage Computer Festival
------------------------------------------------------------------------------
International Man of Intrigue and Danger http://www.vintage.org
[ Old computing resources for business || Buy/Sell/Trade Vintage Computers ]
[ and academia at www.VintageTech.com || at http://marketplace.vintage.org ]
actually both Intel and Motorola use a checksum which is just the negative value of the summation of all bytes. A CRC check actually was used in zmodem for example and it is a mathematical value derived from a polynomial function (do a search for CRC onm the web). There are CRC code snippets for creation of this type of data.
I know a three section approach that I was proposing is more complicated, but from a code standpoint allows total freedom of data access without having to create a target media let alone have the computer system to then read the media just to get at the data that was on a floppy disk. The beauty is that if you need to create a Northstar system diskette then you can, but if all you need is a copy of the dump.asm program then you can get that also without having to go any further than the file you started with.
best regards, Steve Thatcher
-----Original Message-----
From: "Cini, Richard" <RCini(a)congressfinancial.com>
Sent: Aug 11, 2004 7:37 AM
To: "'General Discussion: On-Topic and Off-Topic Posts'" <cctalk(a)classiccmp.org>
Subject: RE: Let's develop an open-source media archive standard
Dave:
I tend to forget about the Motorola format (call me an Intel snob).
The 16mb would be enough for many systems, and I would hope that 4gb would
be enough, at least for now, to represent the largest of the media types we
want to represent.
Rich
-----Original Message-----
From: cctalk-bounces(a)classiccmp.org
[mailto:cctalk-bounces@classiccmp.org]On Behalf Of David V. Corbin
Sent: Wednesday, August 11, 2004 10:34 AM
To: 'General Discussion: On-Topic and Off-Topic Posts'
Subject: RE: Let's develop an open-source media archive standard
You might want to consider Motorola rather than Intel.
The only reason I suggest this is the motorola format alread has a (semi)
extensible record type description [the second char of each line].
S2 and S3 are already defined for 16MB and 4GB memory spaces...
A (non-standard) record type "could" be used for media format, etc...
Just my 16.3875 milli-EUR comment...
>>> -----Original Message-----
>>> From: cctalk-bounces(a)classiccmp.org
>>> [mailto:cctalk-bounces@classiccmp.org] On Behalf Of Cini, Richard
>>> Sent: Wednesday, August 11, 2004 10:02 AM
>>> To: 'General Discussion: On-Topic and Off-Topic Posts'
>>> Subject: RE: Let's develop an open-source media archive standard
>>>
>>> I haven't read the entire thread on this but I did read
>>> Steve Thatcher's idea and it describes about where I was
>>> coming out on this myself.
>>>
>>> I might have missed what the ultimate use of this archive
>>> would be. Will the archive be used to (1) re-generate
>>> original media; (2) operate with emualtors; (3) both?
>>>
>>> To ensure integrity of the data I would propose recording
>>> the data in the Intel Hex format -- it's text-based and has
>>> built-in CRC. Now, we'd have to modify the standard format
>>> a bit to accommodate a larger address space and to add some
>>> sort of standardized header (a "Hardware Descriptor"). This
>>> data would be used by the de-archiver to interpret the
>>> stream of data read from the data area (the "Hex Block").
>>>
>>> I agree that a multi-layer approach offers the best
>>> combination of platform neutrality and portability. I don't
>>> really know if we need two or three layers as Steve
>>> described to describe the file in a standard fashion. Using
>>> an Intel Hex-like format would increase the "de-archiving"
>>> time, but in my view it's a fair trade-off. De-archiving
>>> software could translate the platform-neutral file into
>>> another format better suited for use in emulators.
>>>
>>> I think that we should start compiling a list of the
>>> various media we want represented and how that media is
>>> organized natively. I don't mean "well, it has blocks and
>>> sectors" either. We should examine the exact format down to
>>> the actual numbers (i.e., "2048 blocks of 256-bytes
>>> recorded twice"). Seeing how the various data stores are
>>> organized should bring some clarity to how we should represent it.
>>>
>>> Just my $0.02.
>>>
>>> Rich
>>>
to clarify my comment about using zip, this was suggested as a way for a person to reduce the size of their archive for their own purposes. I was not proposing that data be compressed with zip for the actual archive file.
The only assumption I made for data continuity was that the data needed to be ascii and to have some error detection ability to let the person accessing the data have an idea of validity.
Keeping an image file in an error checked ascii file in a purely sequential form seems to me to not rely on any technology or special information other than accessing a pure data file from some type of computer system. As someone else suggested, ascii text could even be contained in archive files to explain how to get teh data back. My thought of having the data accessible as well as the formatting information would allow a single transmission of a group of files to be sent with information contained within to either get just the data or be able to actually create media copies.
best regards, Steve Thatcher
-----Original Message-----
From: Doc Shipley <doc(a)mdrconsult.com>
Sent: Aug 11, 2004 10:20 AM
To: General(a)mdrconsult.com, Discussion@mdrconsult.com@null,
On-Topic and Off-Topic Posts <cctalk(a)classiccmp.org>, null@null
Subject: Re: Let's develop an open-source media archive standard
Jules Richardson wrote:
> On Wed, 2004-08-11 at 13:13, Steve Thatcher wrote:
>
>
>> I would encode binary data as hex to keep everything ascii. Data size would expand,
>>but the data would also be compressable so things could be kept in ZIP files of
>>whatever choice a person would want to for their archiving purposes.
>
>
> "could be kept" in zip files, yes - but then that's no use in 50 years
> time if someone stumbles across a compressed file and has no idea how to
> decompress it in order to read it and see what it is :-)
There's going to have to be _some_ assumption of continuity or this
project is hopeless. It's my opinion that short-term or long-term,
anyone who wants or needs access to the data** will have some historical
understanding of the computing environment contemporary to that data.
Provisions for changing technology and loss of continuity are good,
but we still need to draw the line at some point, especially concerning
"external" archival of the archived data, i.e. zipped arcives and
storage media. To go to an extreme example, even printed ASCII on paper
or mylar isn't reliable. Paper may be just as archaic as hieroglyphics
when the data is wanted.
We have to depend on ongoing maintenance of these archives. If they
are not periodically migrated to current media, and if the
attached/imbedded documentation is not augmented to account for social
and technical "loss of memory", future retrieval will be difficult, if
not impossible, no matter what we do now.
Doc
** Technically speaking. We can't provide for, say a non-technical
attorney who wants recorded files as evidence. That example will end up
in the hands of someone like us.
I forgot to answer one part of the original post. If you need someone to act
as the consolidator of the media data, I can do that.
-----Original Message-----
From: cctalk-bounces(a)classiccmp.org
[mailto:cctalk-bounces@classiccmp.org]On Behalf Of Vintage Computer
Festival
Sent: Wednesday, August 11, 2004 1:56 PM
To: General Discussion: On-Topic and Off-Topic Posts
Subject: RE: Let's develop an open-source media archive standard
On Wed, 11 Aug 2004, Cini, Richard wrote:
> I might have missed what the ultimate use of this archive would be. Will
the
> archive be used to (1) re-generate original media; (2) operate with
> emualtors; (3) both?
Both. Emulators will certainly be able to make use of the archive by
having parsers built-in that can translate the archive data into
something the emulator can use. So instead of point the emulator to a
binary disk image, you would point it to an archive file and it would
translate the file back into tracks/sectors, or punch cards, or whatever.
> To ensure integrity of the data I would propose recording the data in the
> Intel Hex format -- it's text-based and has built-in CRC. Now, we'd have
to
> modify the standard format a bit to accommodate a larger address space and
> to add some sort of standardized header (a "Hardware Descriptor"). This
data
> would be used by the de-archiver to interpret the stream of data read from
> the data area (the "Hex Block").
I think you're thinking of this in terms of a large binary file encoded as
ASCII hex. If so, this is not what's being proposed. What is being
discussed is a format which actually describes the physical medium. For
example, on floppy:
<MEDIA TYPE=FLOPPY SIZE=5.25 SIDES=1 DENSITY=SINGLE FORMAT=GCR TRACKS=35
SECTORS=16 SECTORSIZE=256>
<VOLUME>Apple ][ System Disk</VOLUME>
</MEDIA>
<DATA>
<TRACK 0><SECTOR 0>
HERE WOULD BE THE ASCII HEX DATA FOR TRACK 0, SECTOR 0
</SECTOR></TRACK>
...
<TRACK 34><SECTOR 15>
HERE WOULD BE THE ASCII HEX DATA FOR TRACK 34, SECTOR 15
</SECTOR></TRACK>
</DATA>
> I think that we should start compiling a list of the various media we want
> represented and how that media is organized natively. I don't mean "well,
it
> has blocks and sectors" either. We should examine the exact format down to
> the actual numbers (i.e., "2048 blocks of 256-bytes recorded twice").
Seeing
> how the various data stores are organized should bring some clarity to how
> we should represent it.
I agree. This would be useful. Does someone want to volunteer to do
this?
--
Sellam Ismail Vintage Computer
Festival
----------------------------------------------------------------------------
--
International Man of Intrigue and Danger
http://www.vintage.org
[ Old computing resources for business || Buy/Sell/Trade Vintage Computers
]
[ and academia at www.VintageTech.com || at http://marketplace.vintage.org
]
my concept of splitting the data and the formatting information relies on the data blocks being the correct size for whatever media you are creating. In other words, you could see 128, 256, 512, and 1024 "sectors" for floppies. Each data block is assigned a number (virtual or real) that is then used to put the data in the correct physical location on whatever media it was supposed to be put in. The addressing of the hex formats in less important that the ability to have a block size of the required length. A paper tape data block would be whatever arbitrary length the tape was a be sequential. Same goes for a cassette tapel recording that might have been converted to mp3 for storage.
best regards, Steve Thatcher
-----Original Message-----
From: "David V. Corbin" <dvcorbin(a)optonline.net>
Sent: Aug 11, 2004 8:46 AM
To: "'General Discussion: On-Topic and Off-Topic Posts'" <cctalk(a)classiccmp.org>
Subject: RE: Let's develop an open-source media archive standard
S1 = 16 bit address in each record..
S2 = 24 bit address in each record..
S3 = 32 bit address in each record..
Hence the maximum sizes.....
>>> -----Original Message-----
>>> From: cctalk-bounces(a)classiccmp.org
>>> [mailto:cctalk-bounces@classiccmp.org] On Behalf Of Jules Richardson
>>> Sent: Wednesday, August 11, 2004 10:52 AM
>>> To: 'General Discussion: On-Topic and Off-Topic Posts'
>>> Subject: RE: Let's develop an open-source media archive standard
>>>
>>> On Wed, 2004-08-11 at 14:37, Cini, Richard wrote:
>>> > Dave:
>>> >
>>> > I tend to forget about the Motorola format (call me an
>>> Intel snob).
>>> > The 16mb would be enough for many systems, and I would
>>> hope that 4gb
>>> > would be enough, at least for now, to represent the
>>> largest of the
>>> > media types we want to represent.
>>>
>>> I don't know about 4GB, but I'd really like to archive hard
>>> disk images in the 20-30MB range using the same format if
>>> possible...
>>>
>>> cheers
>>>
>>> Jules
>>>
>>>
>>>
On Aug 9 2004, 21:58, trash3(a)splab.cas.neu.edu wrote:
> I have three boards. Two of them are Rev. K3. One of the boards has
PROMS
> on it, and no readable version, but the second has the 330-E5 and the
> 331-E5.
Thanks, Joe. I've got images now.
For those who may be interested, I've added a few more images to my DEC
ROM collection, including those. In an effort to make it slightly more
user-friendly, I've also added a 00ReadMe file and one called
"ROMlist", which lists ROM numbers I know, with the modules they belong
to, and some (occasionally cryptic) notes.
The whole lot is at http://www.dunnington.u-net.com/public/DECROMs/
Further contributions welcome :-)
Did anyone sort out a repository for the small PROMs used in Unibus
bootstraps and the like? I know Henk has a nice (if you don't mind
Javascript) list of the common ones, but I don't know if dumps are
around anywhere.
--
Pete Peter Turnbull
Network Manager
University of York
Hello,
My name is Rick Fama from Delta Computer Group. We are in need of the SSP diskettes for a IBM 5362.
Any idea of where I can obtain these?
Thanks
Hi all, after reading all this morning's posts, I thought I would throw out some thoughts.
XML as a readable format is a great idea. There is plenty of software available on most platforms to deal with this format.
I looked at the CAPS format and in part that would be okay. I would like to throw in an idea of whatever we create as a standard actually have three sections to it.
The first would be a data description and subsequent data (i.e. Data Container contains Data Items). Block size, number of blocks, and block data...
The second would be a physical format description that would tell how the data description data is actually stored on whatever media is being targeted (Format Container contains Format Items). Device type (sequential, random), track, sector, virtual sector, head, bad sectors, etc would be needed and then a mapping from each Data Item to each Format Item.
The third would simply be a "image file" that would simply be a sequential block of data with length and CRC that contained the Data Container and Format Container.
This type of arrangement would give us a single file to send around that not only allowed for the recreation of the physical format, but also allowed for direct file access (read only of course). I suppose one could think of it as a smart library file that not only contained one or more files, but also gave physical re-creation information.
best regards, Steve Thatcher
-----Original Message-----
From: Vintage Computer Festival <vcf(a)siconic.com>
Sent: Aug 10, 2004 7:04 PM
To: Classic Computers Mailing List <cctalk(a)classiccmp.org>
Subject: Let's develop an open-source media archive standard
Ok, instead of all the unproductive bickering over semantics (most of
which is illogical...come on, admit it) I'd rather we actually discuss
developing further an open-source, public domain, free (in every sense of
the word) standard for archiving data media of all types (magentic, paper,
or otherwise).
This is basically going to be a continuation of what we've already
discussed on the list, and what Hans and I have discussed in private.
First, let's start with the goals.
The format should be:
1) Well Documented (with such documentation actively preserved in all four
corners of the globe and beyond)
2) Not constrained to any particular hardware
3) Be inclusive of all physical (and logical?) manner of recording media
4) Be implementable on even the simplest architectures (because the
original media source will in many cases have to be read on the hardware
it is connected to)
5) Open source, public domain, etc. (although a copyright may be held if
it makes sense to do so)
6) Adaptable, expandable, revisable (for future extensions)
7) Text-based and storable in commonly accessible character formats (i.e.
a suitable subset of Unicode, i.e. ASCII)
8) Allow for the representation of media in either logical or physical
(raw bit stream) formats
This is a good start. Someone please continue adding to the definition.
I will establish a special session at the next VCF (November 6-7) where
we can commence a committee for formalizing this standard and getting it
recognized internationally in all the various relevant groups (i.e. ANSI
or ISO/IEC).
--
Sellam Ismail Vintage Computer Festival
------------------------------------------------------------------------------
International Man of Intrigue and Danger http://www.vintage.org
[ Old computing resources for business || Buy/Sell/Trade Vintage Computers ]
[ and academia at www.VintageTech.com || at http://marketplace.vintage.org ]
*********************************************************************************
Before acting on this e-mail or opening any attachment you are advised to
read Metronet Rail BCV Limited's disclaimer at the end of this e-mail.
*********************************************************************************
Hi lee
I found this discussion thread recently and would be interested in the
Matrox Graphic cards - have you still got?
Best Regards
Trevor Wright
Recently rescued ..
HP 9000/300 - 68010 CPU, 1MB RAM + video (so it says)
HP 9153A - 2 of, floppy + HD (probably 10MB)
HP 35731A - 12" 512x400 monochrome monitor (some burn)
HP 46021A - keyboard
HP 46083A - HP-HIL rotary control
HP 46084A - HP-HIL ID module
One of the 9153A drives is alleged to contain the software
to dribe a gas chromatograph (written in PASCAL) the other
is alleged to contain the PASCAL compiller environment.
Not tested as yet. Also ..
MEM/340 - 4MB multibus II(?) memory card
And bought recently ..
Heurikon M220 - 5 of, VME, 68020/68881, 4MB DRAM, SCSI, 2 x SERIAL
Matrox MMG640 - 2 of, VME, graphics, ??
I need info for the Matrox and Heurikon boards, and possibly ROM
images, and I could use a VME backplane or two (or other VME cards
such as ethernet) so the HP stuff and the multibus card are available
for swap/sale. I can probably deliver/collect within the UK.
Cheers
Lee.
*********************************************************************************
Any opinions expressed in this e-mail are those of the individual and
not necessarily the company. This e-mail and any files transmitted with
it are confidential and solely for the use of the intended recipient.
It may contain material protected by attorney-client privilege.
If you are not the intended recipient or the person responsible for
delivering to the intended recipient, be advised that you have
received this e-mail in error and that any use is strictly prohibited.
If you have received this e-mail in error please notify the sender or
Metronet Rail BCV Limited's service desk on 0870 458 3862 and then delete
this message.
Unencrypted e-mail is intrinsically insecure and Metronet Rail BCV Limited does
not accept responsibility for any changes made to this e-mail or attachments
during its transmission. If you are unsure of the authenticity of this e-mail
then please contact the sender.
Virus Disclaimer:
Every effort has been made to ensure that this e-mail is virus free.
However Metronet Rail BCV Limited does not accept any liability in respect to
an undetected virus and recommends that the recipient(s) use an up to date
virus scanner.
Metronet Rail BCV Limited
Registered Office: Templar House, 81-87 High Holborn, London WC1V 6NU.
Company Number: 3923496
**********************************************************************************
Hello,
I recently got an Alphaserver 2000 4/200 and I want to run OpenVMS on
it. I have signed up for the Hobbyist program but I do not have the
money to purchase the media. If someone has a set that I can borrow or
get a copy of I would be very grateful.
Thanks,
Eric Moody
Hi
There is a format that has been used with the H8/89
hard sectored disk called SVD. I like it in some ways but not
in others.
Things I like:
It is in a human readable format
Sectors are separated by white space and/or comments
comments can be added
Things I don't like:
Format is octal ( I prefer hexadecimal )
Header contains various bit of information that are not decoded
in a human readable form( still encoded as octal values ).
I use a straight binary image file to transfer disk images to
my H8's and H89. Converting the SVD format to one that I can use
is trivial.
The issue of reading the actual file from an image and placing
that into a file is another issue. Each disk system uses a
different directory structure and allocation method. How this
could be simply encoded into the image files is more than I'd like to
think about unless one would just settle for a textual description
in the comment space.
As an example, the H8/89 hard sectored disk have a volume number
encoded in the header field ( that isn't part of the data ). The
directory and allocation tables are pointed to by specific locations
on track 0. They are not at specific locations.
Other issues that might be a problem are things like the actual encoding
methods used. Not all data is in nice 8 bit chunks ( my Nicolet does
20 bit chunks ). Inter leaving is usually not a great issue since
it often only effects speed but it might be important.
Dwight
>From: "Paul Koning" <pkoning(a)equallogic.com>
>
>>>>>> "Vintage" == Vintage Computer Festival <vcf(a)siconic.com> writes:
>
> Vintage> Ok, instead of all the unproductive bickering over semantics
> Vintage> (most of which is illogical...come on, admit it) I'd rather
> Vintage> we actually discuss developing further an open-source,
> Vintage> public domain, free (in every sense of the word) standard
> Vintage> for archiving data media of all types (magentic, paper, or
> Vintage> otherwise).
>
> Vintage> This is basically going to be a continuation of what we've
> Vintage> already discussed on the list, and what Hans and I have
> Vintage> discussed in private.
>
> Vintage> First, let's start with the goals.
>
>When you say "archiving" what span of time do you mean? A year? A
>decade? A century? Longer?
>
>You will get completely different answers depending on how you answer
>that question.
>
>(See also www.longnow.org)
>
> paul
>
>
I've got an RDI BriteLite IPX portable. Neat machine.
Does anyone know if this has a color or monochrome LCD display?
--
Sellam Ismail Vintage Computer Festival
------------------------------------------------------------------------------
International Man of Intrigue and Danger http://www.vintage.org
[ Old computing resources for business || Buy/Sell/Trade Vintage Computers ]
[ and academia at www.VintageTech.com || at http://marketplace.vintage.org ]
>From: "Jay West" <jwest(a)classiccmp.org>
>
>Dwight wrote...
>> Things I don't like:
>> Format is octal ( I prefer hexadecimal )
>Blasphemy!! *Grin*
>
Hi
It was my mothers fault. She would never let me play with the smart kids.
Dwight
At 17:43 10/08/2004 -0700, you wrote:
>Hi Dave
> A common failure item in these old machines is the RAM.
>Any failure of the RAM makes things like subroutines fail
>quickly.
>Dwight
Yeah - that did occur to me - hard to diagnose for certain - all the RAM's are
soldered in.
I did remove and socket the ROM's today - so with an EPROM emulator I can put
boot code in fairly easily - anyone know what the minimum I need to do to setup
the video and any other essential hardware is? Also a memory MAP would be
handy (I think I saw one in the Archive - I'll look, however if anyone knows
where the RAM limits are and where Video memory is - could save me sime time.
If I can figure out where the RAM is, and how to write to the screen, I can
boot a small RAM test in the Kernal ROM space.
Regards,
Dave
--
dave04a (at) Dave Dunfield
dunfield (dot) Firmware development services & tools: www.dunfield.com
com Vintage computing equipment collector.
http://www.parse.com/~ddunfield/museum/index.html
"Joe" wrote:
Unless you use a Zenith PC. They came with a monitor/debugger built into
ROM. Just use CNTL-ALT-INSERT to bring it up. OTOH I've had very good
results just using Debug with MS-DOS.
Joe
I've always liked the monitor in my Columbia MPC series better than
Zenith's. It allows easy access to the disks, sector-by-sector, for (R)eads
or (W)rites. The Zenith makes you jump through hoops to accomplish the same
thing.
BTW, I never got into DEBUG much, but my all-time favorite program is DDT
under CP/M.
--T
Jam the computer...trash every lethal machine in the land! -- Timothy Leary
Hi Dave
A common failure item in these old machines is the RAM.
Any failure of the RAM makes things like subroutines fail
quickly.
Dwight
>From: "Dave Dunfield" <dave04a(a)dunfield.com>
>
>>> Deos ftp://ftp.funet.fi/ still exist? That used to be a good place for
>>> Commodore schematics and technical info,
>>
>>Yup, FUNET's still alive. <ftp://ftp.funet.fi:/pub/cbm> for the CBM stuff.
>>There's also a web-based version at <http://nic.funet.fi/pub/cbm/index.html>.
>
>Thanks guys - that helps a lot.
>
>+++
>
>Does anyone have "inside" information on exactly what the PET firmware does
when
>it starts up?
>
>I am still working on the same pair of SuperPET 9000's (one works, one does
not).
>Both machines have been stripped to just the base 6502 board.
>
>The "bad" machine plays it's tune and clears the screen - then appears to hang.
>(If you reset it with the monitor warmed up, you can see the screen fill with
>"garbage" and then clear - just like the working one).
>
>Code appears to be running:
>
> - If I remove the KERNAL rom, the startup beep does not occur, and the screen
> never initializes, so it looks like this ROM is executing.
>
> - After it appears to "hang", the code still seems to be running. Looking at
> the 74LS154 decoder which shows accesses within 4k boundaries, I see lots of
> accesses to 0xxx (probably page0 RAM), no accesses to intervening locations
> and lots of access to the ROM's, which follow a clearly identifiable
pattern.
> Removing any ROM prevents this from happening, with the machine just
"flailing"
> until it gets a HLT - so it looks like it may actually be running ROM code.
>
> - I can see accesses to the keyboard scanner.
>
>On the working machine, after accessing all ROM's as BASIC starts (and prints
it
>welcome message), it settles into a keyboard scan which appears to exist within
>the KERNAL and EDIT rom's - the BASIC ROM's are not accessed unless some
function
>is activated.
>
>The non-working machine appears to hang during the phase where it is accessing
all
>ROM's - it continues to do this indefinately.
>
>It looks like the system is hanging during the initialization of BASIC - it
never
>prints the welcome message (hangs with blank screen).
>
>So far I have been unable to determine what it is doing exactly - any info on
the
>startup sequence would be MOST appreciated!
>
>I have verified that the ROM's contain exactly the same code as the other
machine
>(I've seen several PET's fail with bad ROM's, however this does not appear to
be
>the case here).
>
>Regards,
>Dave
>--
>dave04a (at) Dave Dunfield
>dunfield (dot) Firmware development services & tools: www.dunfield.com
>com Vintage computing equipment collector.
> http://www.parse.com/~ddunfield/museum/index.html
>
>
>
One of our local scrappers called me up today about some systems they pulled
>from a working site. I went and looked at them and they must have been in a
controlled environment - they are all in excellent to pristine condition.
They will be scrapped shortly - in fact, by the time I got there (two hours
after the call) - one big Teradyne was already stripped :-(
If you are interested in any of these, let me know immediately and what price
you'd like to offer for the equipment. The equipment is in the San Francisco
Bay Area - shipping on some of this stuff would be costly (RA82/VAX,
Sequents, Teradyne, IBM 3720)....
Several VAX 3100 (M76 and M38)
Several Digital BA42s with RZ55, RZ56 and RZ57
Digital RA82/VAX 3600
Sequent (1) S2000/500 and (1) S2000/200
Teradyne S16 (?)
IBM Power 530
IBM 3720
Lyle
--
Lyle Bickley
Bickley Consulting West Inc.
http://bickleywest.com
"Black holes are where God is dividing by zero"
>> Deos ftp://ftp.funet.fi/ still exist? That used to be a good place for
>> Commodore schematics and technical info,
>
>Yup, FUNET's still alive. <ftp://ftp.funet.fi:/pub/cbm> for the CBM stuff.
>There's also a web-based version at <http://nic.funet.fi/pub/cbm/index.html>.
Thanks guys - that helps a lot.
+++
Does anyone have "inside" information on exactly what the PET firmware does when
it starts up?
I am still working on the same pair of SuperPET 9000's (one works, one does not).
Both machines have been stripped to just the base 6502 board.
The "bad" machine plays it's tune and clears the screen - then appears to hang.
(If you reset it with the monitor warmed up, you can see the screen fill with
"garbage" and then clear - just like the working one).
Code appears to be running:
- If I remove the KERNAL rom, the startup beep does not occur, and the screen
never initializes, so it looks like this ROM is executing.
- After it appears to "hang", the code still seems to be running. Looking at
the 74LS154 decoder which shows accesses within 4k boundaries, I see lots of
accesses to 0xxx (probably page0 RAM), no accesses to intervening locations
and lots of access to the ROM's, which follow a clearly identifiable pattern.
Removing any ROM prevents this from happening, with the machine just "flailing"
until it gets a HLT - so it looks like it may actually be running ROM code.
- I can see accesses to the keyboard scanner.
On the working machine, after accessing all ROM's as BASIC starts (and prints it
welcome message), it settles into a keyboard scan which appears to exist within
the KERNAL and EDIT rom's - the BASIC ROM's are not accessed unless some function
is activated.
The non-working machine appears to hang during the phase where it is accessing all
ROM's - it continues to do this indefinately.
It looks like the system is hanging during the initialization of BASIC - it never
prints the welcome message (hangs with blank screen).
So far I have been unable to determine what it is doing exactly - any info on the
startup sequence would be MOST appreciated!
I have verified that the ROM's contain exactly the same code as the other machine
(I've seen several PET's fail with bad ROM's, however this does not appear to be
the case here).
Regards,
Dave
--
dave04a (at) Dave Dunfield
dunfield (dot) Firmware development services & tools: www.dunfield.com
com Vintage computing equipment collector.
http://www.parse.com/~ddunfield/museum/index.html
Excellent condition. Looks new. If interested, please
send email to foadamoon(a)yahoo.com.
Price $475.
we can email you pictures:
NeXTstation Color
32MB Memory
406 MB Hard Disk Drive and Floppy disk drive
Keyboard + Mouse + Sound Box + CD ROM
NeXTstation (MegaPixel) 21-inch Color Monitor
SCSI port
A and B serial ports
DSP port
Display port
Printer port
Twisted-pair and thin-wire Ethernet port
Miniphone jack for headphones
Left and right line-out jacks
NeXT Mach 3.3 (Processor 68040)
All original Software CDs
Network and System Administration Manual
User’s Reference Manual
NEXTSTEP User’s Guide
NEXTSTEP Object-Oriented Programming and The Objective
C Language
Setup and Tutorials Manual
Applications Manual
Service Guide
NeXSTEP Programming (Simson L. Garfinkel, Michael K.
Mahoney)
__________________________________
Do you Yahoo!?
Yahoo! Mail - 50x more storage than other providers!
http://promotions.yahoo.com/new_mail
The first edition of the Optoelectronics Data Book for Design Engineers
by Texas Instrument, date unknown, probably early 70's lists this device
along with a test circuit. The six pages have specs and a small application
circuit for cascading the displays. No other circuits are in my library
as far as I can tell.
Joe Heck
BTW someone was collecting a list of operating systems and the machines
that they ran on. Does anyone know if and where it's posted?
Joe
What about FreeDOS? Or they just call it that for kicks? There's also
Minux and Linux which may not technically public domain but they're
certainly free. I'm not sure about the older versions of DR-DOS but but I
seem to recall that they're in the public domain now too and I believe CPM
also is. Anybody know the status of CPM-86? The last that I heard MPM was
still being sold commercially but I expect that it may end up in the public
domain before long.
Joe
At 10:53 AM 8/10/04 -0400, you wrote:
>> Name another computer with as many choices of OS and as many
>> versions, including third party and public domain OSs.
>
>Public domain? While admittedly I haven't specifically looked, I don't
>think I've ever seen a public domain OS for anything, even for values
>of "OS" as marginal as MS-DOS. (Not to detract from your basic point,
>which I agree with - if there are public domain OSes out there, I would
>expect most of them to be for peecees....)
>
>/~\ The ASCII der Mouse
>\ / Ribbon Campaign
> X Against HTML mouse(a)rodents.montreal.qc.ca
>/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
>
At 01:10 PM 22/11/2002 +1100, Kane, David (DPRS) wrote:
>>The system comprised a CPU and dual 8" floppy in a half height rack, on
>>top of which sat a marked sense card reader, and in the corner was a DEC
>>line printer. My memory of the CPU front panel is that it looks somewhat
>>like an 11/34 picture I found in the user manual PDF with the programmers
>>console. But I definitely remember it as an "slash zero" something model,
>>so I believe that it was an 04. However the only picture of an 04 I have
>>found to date has a rather basic looking programmers panel, by basic I
>>mean as it is simple white text on black panel and buttons. I seem to
>>remember the octal keypad had a border drawn on the pane and was a little
>>bit smarter looking, maybe there were updated cosmetic version of the
>>panel. The system booted straight to a local derivative of FORTRAN (MONECS
>>FORTRAN), so we were insulated from the hardware and I therefore have no
>>memory or interface card details.
>
>The MONECS system we had at La Trobe for many years was an 11/23 (maybe >an
>11/23+) although this was the prepackaged version from Digital known as the
>DEAMON. For those of you outside of Australia:
>
>MONECS - MONash (University) Educational Computing System
PDP-11/05 (or PDP11/10), core memory, Documation or HP brand mark
sense card readers, Memorex 751 floppy disk drives (these preceeded 8
inch floppys that most people would recognise) and a line printer.
System packaging varied greatly with the processor and drives racked
into desks or wheeled cabinets. They were in various Secondary schools
in Victoria, Monash University (for first year students before they
graduated to terminals) and some may have been used at Melbourne
University. Suggest C. Ching would have the best knowledge of these
systems.
>DEAMON - Digital Equipment Australia / MONash
>From memory the versions I maintained were PDP11/04 based, RX01, etc.
The 11/03, 11/23 would have been later machines.
http://www.csse.monash.edu.au/museum/
>
>Monash University developed a card based system where the user wrote code
>(in FORTRAN, COBOL and ISTR a pseudo-assembler) and used pre-punched or
>mark sense cards. You queued up to use the card reader, loaded your own job
>and collected output almost immediately. I used the main frame based
>(probably Burroughs) predecessor to lean to program FORTRAN in either 1969
>or 1970. We used to send our cards by post to Monash and if we were lucky
>would get one run a week....
Probably Fortran on the Burroughs B5500, maybe too early for the
B6700, this is before my time. Think both of these machines were
ex-Victorian Government Gas and Fuel Corporation mainframes and were
donated to Monash Uni by Burroughs for a token amount.
>
>Huw Davies | e-mail: Huw.Davies(a)kerberos.davies.net.au
> | "If God had wanted soccer played in the
> | air, the sky would be painted green"
On Aug 9 2004, 21:58, trash3(a)splab.cas.neu.edu wrote:
> I have three boards. Two of them are Rev. K3. One of the boards has
PROMS
> on it, and no readable version, but the second has the 330-E5 and the
> 331-E5. What is your timeframe? I have to power up the right PC
with
> the eprom burner on it to read them, but that could be done within a
> fortnight or less.
Thanks very much to to all who responded, both on- and off-list. I've
now got images, and I'll put them in the usual place in case anyone
else needs them :-)
--
Pete Peter Turnbull
Network Manager
University of York
On Aug 9 2004, 22:28, quapla(a)xs4all.nl wrote:
>
> You should have told me earlier. I have a controller here which has
> those 2 roms on them. Mind you, the other 3 I have all have 23-248 &
> 23-249 on them.
Hmm. Turns out I don't have 248/249 either (unless you mean 208/209?).
Have you got any way to dump those for me as well? Just to add to the
collection.
--
Pete Peter Turnbull
Network Manager
University of York
Does anyone know what was the first computer to have a built-in real-time
clock?
--
Sellam Ismail Vintage Computer Festival
------------------------------------------------------------------------------
International Man of Intrigue and Danger http://www.vintage.org
[ Old computing resources for business || Buy/Sell/Trade Vintage Computers ]
[ and academia at www.VintageTech.com || at http://marketplace.vintage.org ]