- test-drb@ccmp.vtda.org - classiccmp.org

by jwest＠classiccmp.org

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]

21 years, 7 months

4
8
0 0

RT-11 / PDP-11 Software Users

by jhfinexgs2＠compsys.to

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.

21 years, 7 months

3
3
0 0

Let's develop an open-source media archive standard

by dwight.elvey＠amd.com

>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

21 years, 7 months

1
0
0 0

Let's develop an open-source media archive standard

by dwight.elvey＠amd.com

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 >>>> > >

21 years, 7 months

4
3
0 0

Tandy 10 Business Computer System

by tyger69＠chartermi.net

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

21 years, 7 months

5
5
0 0

Let's develop an open-source media archive standard

by RCini＠congressfinancial.com

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 >>>

21 years, 7 months

7
11
0 0

8" floppy project

by dwight.elvey＠amd.com

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! > > >

21 years, 7 months

1
0
0 0

Let's develop an open-source media archive standard

by dwight.elvey＠amd.com

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 ... ) >> >> >> >> > > > >

21 years, 7 months

1
0
0 0

Anyone need greenbar paper?

by zmerch＠30below.com

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!

21 years, 7 months

6
6
0 0

Let's develop an open-source media archive standard

by dwight.elvey＠amd.com

>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 ] > > >

21 years, 7 months

1
0
0 0

Let's develop an open-source media archive standard

by dwight.elvey＠amd.com

>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

21 years, 7 months

1
0
0 0

Let's develop an open-source media archive standard

by dwight.elvey＠amd.com

>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 ... ) > > > >

21 years, 7 months

1
0
0 0

Let's develop an open-source media archive standard

by dwight.elvey＠amd.com

>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 ] > >

21 years, 7 months

1
0
0 0

Let's develop an open-source media archive standard

by dwight.elvey＠amd.com

>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

21 years, 7 months

2
1
0 0

What is it? Prometheus Versacard

by rigdonj＠cfl.rr.com

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

21 years, 7 months

4
3
0 0

Let's develop an open-source media archive standard

by dwight.elvey＠amd.com

>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

21 years, 7 months

1
0
0 0

Let's develop an open-source media archive standard

by dwight.elvey＠amd.com

>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

21 years, 7 months

1
0
0 0

Let's develop an open-source media archive standard

by melamy＠earthlink.net

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 ]

21 years, 7 months

1
0
0 0

Let's develop an open-source media archive standard

by melamy＠earthlink.net

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 ]

21 years, 7 months

1
0
0 0

Let's develop an open-source media archive standard

by dwight.elvey＠amd.com

>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

21 years, 7 months

2
1
0 0

List problems?

by healyzh＠aracnet.com

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

21 years, 7 months

1
0
0 0

Let's develop an open-source media archive standard

by dwight.elvey＠amd.com

>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

21 years, 7 months

2
1
0 0

Osborne / TRS-80 III wanted for British TV show- can you help?

by tosteve＠yahoo.com

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

21 years, 7 months

3
2
0 0

Let's develop an open-source media archive standard

by RCini＠congressfinancial.com

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 ]

21 years, 7 months

2
1
0 0

Let's develop an open-source media archive standard

by melamy＠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 -----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 ]

21 years, 7 months

2
1
0 0

Let's develop an open-source media archive standard

by melamy＠earthlink.net

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 >>>

21 years, 7 months

2
1
0 0

Let's develop an open-source media archive standard

by melamy＠earthlink.net

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.

21 years, 7 months

2
1
0 0

Let's develop an open-source media archive standard

by RCini＠congressfinancial.com

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 ]

21 years, 7 months

1
0
0 0

Let's develop an open-source media archive standard

by melamy＠earthlink.net

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 >>> >>> >>>

21 years, 7 months

1
0
0 0

DEC/PDP-11 ROMs -- was Re: TKQ50 proms

by pete＠dunnington.u-net.com

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

21 years, 7 months

1
0
0 0

5362 SSP Diskettes

by rfama＠deltacomputergroup.com

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

21 years, 7 months

1
0
0 0

Let's develop an open-source media archive standard

by melamy＠earthlink.net

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 ]

21 years, 7 months

6
5
0 0

Matrox graphic card

by Trevor.Wright＠metronetbcv.com

********************************************************************************* 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 **********************************************************************************

21 years, 7 months

1
0
0 0

Beg, Borrow, or Steal OpenVMS media.

by eric＠redrouteone.net

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

21 years, 7 months

1
0
0 0

Let's develop an open-source media archive standard

by dwight.elvey＠amd.com

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 > >

21 years, 7 months

3
2
0 0

RDI BriteLite IPX portable

by vcf＠siconic.com

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 ]

21 years, 7 months

1
0
0 0

Let's develop an open-source media archive standard

by dwight.elvey＠amd.com

>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

21 years, 7 months

1
0
0 0

PET startup sequence?? (was LF: Commodore PET schematics, troubleshooting info)

by dave04a＠dunfield.com

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

21 years, 7 months

2
1
0 0

monitor program

by tyger69＠chartermi.net

"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

21 years, 7 months

2
1
0 0

PET startup sequence?? (was LF: Commodore PET schematics, troubleshooting info)

by dwight.elvey＠amd.com

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 > > >

21 years, 7 months

1
0
0 0

Pristine systems at scrappers...

by lbickley＠bickleywest.com

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"

21 years, 7 months

1
0
0 0

PET startup sequence?? (was LF: Commodore PET schematics, troubleshooting info)

by dave04a＠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

21 years, 7 months

1
0
0 0

NExt Station for sale

by soheilasoheil＠yahoo.com

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

21 years, 7 months

1
0
0 0

TIL306...any leads

by trash3＠splab.cas.neu.edu

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

21 years, 7 months

2
1
0 0

TIL306...any leads

by ofthe_girl＠hotmail.com

I am looking for TIL306 circuits do you have any leads as to where i can get some?? best regards -Cassandra Munro

21 years, 7 months

2
2
0 0

8" floppy project

by rigdonj＠cfl.rr.com

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 >

21 years, 7 months

1
0
0 0

Newbie enquiries (MONECS/DEAMON)

by unibus＠gmail.com

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"

21 years, 7 months

1
0
0 0

TKQ50 proms

by pete＠dunnington.u-net.com

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

21 years, 7 months

1
0
0 0

TKQ50 proms

by pete＠dunnington.u-net.com

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

21 years, 7 months

1
0
0 0

First computer with real-time clock?

by vcf＠siconic.com

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 ]

21 years, 7 months

20
72
0 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

test-drb