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

by rcini＠optonline.net

Hello, all: I wanted to drop everyone a note to let you know that the latest version of the Altair32 Emulator was released this evening. It has been more than a year since the last update and a lot of work has gone into bug hunting and enhancing operational performance. Scott made the timeslicer multi-threaded, so now the Altair32 can achieve prototypical performance with a machine as slow as a Pentium-III/500MHz (the slowest machine available for testing) at a greatly reduced host system load (10-20%). There are a few things on the drawing board for the next version. First, we will be adding support for a to-be-named color graphics board. Second, hopefully, we will be adding support for an operational Altair (or IMSAI) front panel with a machined metal dress panel in the case of the Altair, or a screenprinted plexiglass one for the IMSAI. Thanks again for all of your support with this project, and enjoy. As always, if anyone finds any bugs or anomalies in the code, please let me know. Rich Rich Cini Collector of classic computers Build Master for the Altair32 Emulation Project Web site: http://highgate.comm.sfu.ca/~rcini/classiccmp/ Altair32 Page: http://highgate.comm.sfu.ca/~rcini/classiccmp/Altair32.htm /************************************************************/

22 years

1
0
0 0

DECMate II

by Innfogra＠aol.com

> Decmate Software, copyright 1985, DM/WPS utility > diskette 2.0 and DM/WPS system diskette v2.0. Don't know which version of > decmate they are for, but they are 5.25 inch, not 8 inch. These are the basic wordprocessing which is called WPS and should work on the Decmate II and III. Since the RX50s held 400K on each floppy they were fine for wordprocessing and two RX50s was a common configuration. You could keep DM/WPS in drive A, the Utility disk or another in Drive B and Data disks in C and D. CPM was an option with a piggyback processing card as was a hard drive. Neither are commonly found in Decmate IIs Paxton Astoria, OR

22 years

1
0
0 0

archive file format exmaple

by melamy＠earthlink.net

I agree in all what Hans had to say except for how data would be stored. This is supposed to be an archive format which would in my view preclude getting data from the outside world. My only other concern as I have stated before was that data should not be an integral part of the media. If a device happens to be a tape drive, the data on the tape still separates into "file" type data and overhead data required for the tape physical format. Enbedding the "file" tyupe data inside of the physical format makes the data inaccessible without special knowledge. best regards, Steve Thatcher -----Original Message----- From: Hans Franke <Hans.Franke(a)siemens.com> Sent: Aug 12, 2004 9:30 AM To: "General Discussion: On-Topic and Off-Topic Posts" <cctalk(a)classiccmp.org> Subject: Re: archive file format exmaple > I'm not so sure about having the actual data within the archive element; > I'd rather have it afterwards. I would prefer an aproach where both ways are possible, includeing a third wich allows to put the data even into another file. In the CCDD definition almost every element (except META) may be empty and have a HREF attribute pointing to it's content: A take header record could have it's data included: <DATA SIZE="80" ENCODING="CHAR" FILLER=" ">HDR2U020480204841 00</DATA> or just point to the data <DATA HREF="#DB1"/> <DATA SIZE="80" ENCODING="CHAR" FILLER=" " ID="DB1">HDR2U020480204841 00</DATA> which of course may even be in another file: <DATA HREF="http://cc-archive.org/~hans/mytapes/T43782.xml#DB1"/>

22 years

4
3
0 0

DECMate II

by trash3＠splab.cas.neu.edu

I looked through my floppy library and came across three floppies that might help. They are labelled Decmate Software, copyright 1985, DM/WPS utility diskette 2.0 and DM/WPS system diskette v2.0. Don't know which version of decmate they are for, but they are 5.25 inch, not 8 inch. I don't think I'll ever need them, but maybe somebody can put them out on the web? Also, I haven't tried to read them, they may be bad, but I don't know. Joe Heck

22 years

2
1
0 0

MTI MLV11M Controller Diagnostics/Formatter wanted.

by dj.taylor＠starpower.net

I have a MicroTechnology MLV11M, which connects to a MFM ST412 type of disk and emulates a DEC RL02. I used to have the manual and formatting software for this but they got lost.... It's a long story. What I am looking for is a utility called RL02DG.SAV which runs under RT11 and allows you to format a disk connected to the controller. Anyone have this very old software? Circa 1985 perhaps. Doug

22 years

1
0
0 0

PICT files

by technobug＠comcast.net

On Aug 12, 2004, at 3:34 PM, cctalk-request(a)classiccmp.org wrote: [...rip...] > There were tools that could handle PICTs, but they puked on > the payload portion of the file. They _knew_ there was a chunk there, > but > didn't know what to do with it. > > Do you happen to know of any way to digest these files except with the > right > libraries loaded on a real Mac? > > -ethan [...too cold to even consider...] For the Mac environment get ye a copy of *Graphic Converter* <http://www.lemkesoft.de/en/graphcon.htm> shareware. Takes in about anything format-wise and will put out anything else. CRC

22 years

2
1
0 0

Motorola In Circuit Emulator and similar stuff available

by jwest＠classiccmp.org

I saw this stuff at the surplus dealer today. I don't know anything about this, but it sounded/looked list stuff some here may be interested in. 1) Motorola EVB/EVM/EVS Software disk with an M68HC05EVM board 2) P&E Microsystems ICS05JPW In Circuit Simulator for Windows diskette, plus M68ICS05JP board 3) MMDS08 or MMD508 software and lots of manuals, plus M68EM08 board 4) M68EVB912B32 circuit board They had a price tag of $25 on each of the 4 items above. Each one seemed pretty complete, with lots of papers, diskettes, PLCC adapter with ribbon cable, power supplies, serial cable to hook up to host PC, etc. Anyways, thought folks might have interest. Jay

22 years

2
1
0 0

Lost Vector Computers to Another Start up

by jrkeys＠concentric.net

A guy contacted me back on the 10th offering me a complete line of Vector Graphic Computers. Hardware, manuals (tech & user), and sales literature for all of it, free for pickup. Asked him the same day when and were could I pick it all up and today I get my answer back saying it's all gone to a startup computer museum at the UT-Arlington campus. Talk about bad luck and everyone here in Texas wanting to start a computer museum.

22 years

2
2
0 0

archive file format exmaple

by melamy＠earthlink.net

that is real simple. You have a physical section that says it is a sequential block of data. You point to the data block that has a length. End of image file in the case. If you know nothing about the format, all you can do is save a sequential data block. I would still separate the two out for strictly consistency sake, so you can get the data easiliy to analyze. Once anlyzed, the a new image file could be generated with more info. best regards, Steve Thatcher -----Original Message----- From: Vintage Computer Festival <vcf(a)siconic.com> Sent: Aug 12, 2004 5:59 PM To: Steve Thatcher <melamy(a)earthlink.net>, "General Discussion: On-Topic and Off-Topic Posts" <cctalk(a)classiccmp.org> Subject: Re: archive file format exmaple On Thu, 12 Aug 2004, Steve Thatcher wrote: > I agree in all what Hans had to say except for how data would be stored. > This is supposed to be an archive format which would in my view preclude > getting data from the outside world. My only other concern as I have > stated before was that data should not be an integral part of the media. > If a device happens to be a tape drive, the data on the tape still > separates into "file" type data and overhead data required for the tape > physical format. Enbedding the "file" tyupe data inside of the physical > format makes the data inaccessible without special knowledge. Steve, What if you don't know what a tape you are archiving contains in the first place? What if you just want to preserve it in case someone else in the future can figure it out? -- 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 ]

22 years

1
0
0 0

Let's develop an open-source media archive standard

by melamy＠earthlink.net

comments below... best regards, Steve Thatcher -----Original Message----- From: Vintage Computer Festival <vcf(a)siconic.com> Sent: Aug 12, 2004 3:44 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, Steve Thatcher wrote: > I did not say it was the primary purpose. The data blocks work hand in > hand with the formatting information. It is fine to make a standard > extensible, but what good does it do if the (I hate the use the word) > file can't be gotten without jumping through major hoops because how the > data was stored in the image file wasn't extended out to make blocks. If > you have to iterate through formatting information to get data then you > have to be intimately familiar with the disk format in use. It means any > GENERAL utility to read an image file for data access will have to KNOW > about all machione supported rather than just getting some type of data > identifier and reading the data out. > > I think part of the problem here is that the word file is being taken > literally to mean filename, size, data, etc. I am using in the context > of a block of data. It has NOTHING to do with how the data is on the > disk, where it is stored, the recording format, etc. It is just a piece > of data... One way to resolve this is to put comments in the image file pointing out where a block of data ("file") starts and how long it is. This can also be built into the spec as a tag, rather than relying on human readable comments to effect this. *** I agree comments could help explain how to get info out of the image file, but if you don't create data blocks in a fashion that implies knowledge of the file system, then you can not just simply point at the data block and say how long it is. If you are talking about my propsed concept then you can just point at a data block and go get it. > I am talking about two separate sections inside the same image file. One > of the sections contains data blocks. The other has specific formatting > information and POINTS to the data in the data blocks. A utility program > could then SIMPLY get any type of data out of the image file without the > utility being out of date as soon as someone added a new physical > format. The spec COULD be made to allow for this, and I don't see a reason why not. It's just an organizational attribute. I'll add it to the notes. *** great, I would hope that people who are archiving disks will use the data blocks rather than embedding the data in the physical format. It just makes life easier for everyone. -- 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 ]

22 years

3
3
0 0

Let's develop an open-source media archive standard

by melamy＠earthlink.net

comments below... best regards, Steve Thatcher -----Original Message----- From: "Dwight K. Elvey" <dwight.elvey(a)amd.com> Sent: Aug 12, 2004 3:09 PM To: cctalk(a)classiccmp.org Subject: RE: Let's develop an open-source media archive standard >From: "melamy(a)earthlink.net" <melamy(a)earthlink.net> > ---snip--- > >The image file that you are discussing is only good as a "how to" to write >arbitrary data to arbitrary media. It is only good for creating a final >media image because the format being contemplated (mixing data into the >physical spec) will preclude the file from standing on its own. No, that is not true. The description of the physical data in the archive should be sufficient to recover the system side data. I can state this because the system side data is just a subset of the physical data. *** if all you are describing is tracks, sectors and heads then you have not included ANY information as to how to get at a specific piece of data in the image file. You can certainly get a sector piece but you will have no clue how to connect individual pieces together to make a block of data. Only platform specific information will get you to that point and that means text has to be included to tell someone how to write software that accesses a particular file structure on a particular OS. If you have that file information when the image file is created, it would be easy to save the info and then be able to get at any file inside of the image file without ANY knowledge of the physical file structure or OS. I recommend that the archive should include enough information to translate from the physical to the system but for archiving purposes, that is not absolutely necessary. *** this information is not trivial, but if we make the data separate then it is if we save the file information too. It is not that hard to describe as part of the header what FM looks like. Still, if we restrict all archived information to include this, some unknown formats may not be archived because the person with the data doesn't know that format. It is better to capture the data first. It may also be that the only way that person has to capture the data is the output of a controller chip. The archiving should allow this as well ( more in the format the Steve would like it all to be in ). *** not sure why this relates to the format I was proposing. What I was desdcribing was a way to do both low level bytes as well as blocks of data This file could later be combined with the more physical information when that was available, just as a archive file that originally had only physical information could be appended with the data as seen by the system. What this means is that some of the archived files may not be directly useable by Steve and his tools without some more in depth knowledge about the encoding use. It doesn't make it impossible to use, just difficult. *** is is not a encoding issue with regards to the hardware level. There are three standards just for 8" disks - FM, MFM, and M2M. ISIS DD uses M2M and I for one want to be able to use my ISIS software independent of the media it is on. I also don't want to have to write a major utility (in other words a small OS) just to read the image file. Dwight >I was >proposing identifying data blocks as files if that is what they were. The >data blocks would have been sequential and trivial to retrieve. That is >hardly what I would call defining a file system as part of the image file. > >best regards, Steve Thatcher >

22 years

2
1
0 0

Let's develop an open-source media archive standard

by melamy＠earthlink.net

no mention of age and unfortunately I am old enough to have worked on and designed predicatbale systems... -----Original Message----- From: "Dwight K. Elvey" <dwight.elvey(a)amd.com> Sent: Aug 12, 2004 6:41 PM To: cctalk(a)classiccmp.org Subject: Re: Let's develop an open-source media archive standard Hi I was more referring to a modern PC than specific older hardware. The issue with doing direct I/O is the it needs to be predictable and on time. Most modern machines can no longer to that reliably without using DMA. They have too may other things that they are expected to do simultaneously. Also because of multiple levels of caching, real-time predictability is not practical. In the N*, they dedicate a predictable processor to do just the disk I/O and nothing else. Dwight >From: "Steve Thatcher" <melamy(a)earthlink.net> > >I seem to recall that my slow old N* Horizon was doing dd at 4mhz with no dma - in fact it was polled I/O because their wait for I/O available kept locking up so I modified it. > >best regards, Steve Thatcher > >-----Original Message----- >From: Fred Cisin <cisin(a)xenosoft.com> >Sent: Aug 12, 2004 5:12 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 Thu, 12 Aug 2004, Dwight K. Elvey wrote: >> Hi Jules >> Here is what I've found. It is a disk drive emulator. >> Unless a PC is DMA driven, bit banging a floppy is not practical. > >Disk I/O without DMA is not practical. But it IS possible. >Consider the PCJr and Tandy 1000, both of which do disk I/O >without DMA on 4.77MHz? machines. > > >

22 years

1
0
0 0

Let's develop an open-source media archive standard

by dwight.elvey＠amd.com

Hi I was more referring to a modern PC than specific older hardware. The issue with doing direct I/O is the it needs to be predictable and on time. Most modern machines can no longer to that reliably without using DMA. They have too may other things that they are expected to do simultaneously. Also because of multiple levels of caching, real-time predictability is not practical. In the N*, they dedicate a predictable processor to do just the disk I/O and nothing else. Dwight >From: "Steve Thatcher" <melamy(a)earthlink.net> > >I seem to recall that my slow old N* Horizon was doing dd at 4mhz with no dma - in fact it was polled I/O because their wait for I/O available kept locking up so I modified it. > >best regards, Steve Thatcher > >-----Original Message----- >From: Fred Cisin <cisin(a)xenosoft.com> >Sent: Aug 12, 2004 5:12 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 Thu, 12 Aug 2004, Dwight K. Elvey wrote: >> Hi Jules >> Here is what I've found. It is a disk drive emulator. >> Unless a PC is DMA driven, bit banging a floppy is not practical. > >Disk I/O without DMA is not practical. But it IS possible. >Consider the PCJr and Tandy 1000, both of which do disk I/O >without DMA on 4.77MHz? machines. > > >

22 years

1
0
0 0

DOS looking like a mainframe project

by ron.hudson＠sbcglobal.net

Ok, Here's another pet project of mine.. I Have a simple DOS6.22 installed in one of my laptops, and I want to make it look like as much like an IBM (it's an IBM laptop too btw) mainframe as possible. I am working on a vauge memory from a job over 10 years ago when I had an account on the R&D little mainframe. I think the machine was an early AS400, It filled 3 Equipment Racks. This was about the time of the Loma-Preata Earthquake (for non california readers, I forget the year but both San Francisco and Oakland, and San Jose were all effected by it, and that was the one where the freeway collapsed and many of the buildings in SF's Marina District suffered from liquifacation) I think it ran somthing like VM/OS, anyway it had Xedit for a system editor and I have "the heisling editor" which is very much like xedit. Can any one capture screens from a Mainframe like this? I'd love to see them.. Esp. the login screen, A directory/datset screen (where in you put an X near a file and hit enter to edit the file.) and any other sorts of menu screens. Thanks.

22 years

3
4
0 0

Let's develop an open-source media archive standard

by dwight.elvey＠amd.com

>From: "Fred Cisin" <cisin(a)xenosoft.com> > >On Thu, 12 Aug 2004, Dwight K. Elvey wrote: >> Hi Jules >> Here is what I've found. It is a disk drive emulator. >> Unless a PC is DMA driven, bit banging a floppy is not practical. > >Disk I/O without DMA is not practical. But it IS possible. >Consider the PCJr and Tandy 1000, both of which do disk I/O >without DMA on 4.77MHz? machines. > > True, but it does require the hardware to be setup for it. I have a Forth processor ( NC4000 ) that I talk directly to the controller chip without DMA. Newer processors are faster but may have latency issues. Using a dedicated uP or some FPLA is the right way to handle it. Of course the problem is multiplies when you have no controller chip and you are talking about raw bit streamed data. It was mentioned earlier that for logging bit stream data, the gaps my have trash in them that causes loss of sync. This should also be handled in the specification. Dwight

22 years

1
0
0 0

Let's develop an open-source media archive standard

by RCini＠congressfinancial.com

How would one actually go about re-generating an original media from the metafile? Do we contemplate connecting some future computer's I/O port to a 34-pin ribbon cable connected to a 1980's vintage floppy drive? At some point in this process we're going to have to make some detailed assumptions on how the metadata will be used 50 or 100 years from now. Also, the metafile not only has to include information about the "user" data areas of the disk but also the system areas (the stuff written to the media by the controller -- address marks, gaps, sync bits, etc.). This would require us to not only compile the general media format data but also data on the controller used to generate the media (chip specs, data gleaned from examining the "format" programs used, etc.). The reason why I ask is that somehow we're going to have to test the archival/restoration process to see that it works. It's like making tape backups but never testing them with a restore. This might be obvious, but I've been accused of stating that before :-) Rich -----Original Message----- From: cctalk-bounces(a)classiccmp.org [mailto:cctalk-bounces@classiccmp.org]On Behalf Of Steve Thatcher Sent: Thursday, August 12, 2004 10:17 AM To: General Discussion: On-Topic and Off-Topic Posts Subject: RE: Let's develop an open-source media archive standard comments embedded below... best regards, Steve Thatcher -----Original Message----- From: Hans Franke <Hans.Franke(a)siemens.com> Sent: Aug 12, 2004 10:06 AM 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 Am 11 Aug 2004 14:47 meinte Steve Thatcher: > 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. Well, physical format and data is not always seperable. In some circumstances the physical format is part of the onformation an application needs, and differs form media to media (e.g. copy protection schemes) *** the separated data that I am talking about is what would be accessed through normal OS channels. Copy protection schemes, special destroyed sectors, etc are not accessible through the OS. > 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. But what if the emulator needs the physical format information? *** I have not proposed that the physical format information be excluded... > 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. At least within a CP/M system it usualy doesn't matter at all how the files are stored on a disk. Except for some odd apps who tried to implement system specific copy protection schemes, all and every CP/M app accesses files just via BDOS which already hides the real disk strukture. *** talk to other people here and one of their arguements for keeping things all together was being able to access track and sector directly. As for BDOS, that is fine, but keep in mind that BDOS was customized for nearly every cp/m platform

22 years

3
2
0 0

Let's develop an open-source media archive standard

by dwight.elvey＠amd.com

>From: "Fred Cisin" <cisin(a)xenosoft.com> > >I think that capability of including comments is essential! > >For example: > ><COMMENT>CRC error on disk. Not yet determined whether it is >a read error, or a deliberate component of copy protection ></COMMENT> > >or ><COMMENT>Note that HEAD NUMBER field in sector header is wrong. >Machine uses WD controller, and doesn't care about that field, >therefore, the incorrect value does not need to be replicated >for normal use. </COMMENT> > > Hi A must. Dwight

22 years

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> From: "Dwight K. Elvey" <dwight.elvey(a)amd.com> ---snip--- > It may also be that the only way that person has to capture the >data is the output of a controller chip. The archiving should allow >this as well ( more in the format the Steve would like it all to >be in ). > >*** not sure why this relates to the format I was proposing. What I was desdcribing was a way to do both low level bytes as well as blocks of data > Hi Steve Again, you've missed the point here. The information may not have anything other than the bit stream and the track. The person extracting the data may have no knowledge of the format ( FM, MFM, M2FM, RLL or whatever ). They are just archiving the data of the disk. I agree that if there is sufficient information available to include such things as sector boundaries, that should be encoded in some method. This may not be in the actual data but as part of the format description ( requires some work to extract from the data ). At the lowest level, the archive may only contain a bit stream that correlates to the signal coming from the drive. Without information as to the encoding method, this may be useless to you. As Sellam has stated, your application is secondary to actually capturing a reproduceable medium. Obviously, most people will not be able to create such information ( I believe I will ). Most will be creating such things as the output data from some standard disk reading chip. These will surely have some form of partioning, either in the header or embedded in the data. This could still be a valid archive input for standard formats. Note the word 'could' and not must. Dwight

22 years

1
0
0 0

archive file format exmaple

by melamy＠earthlink.net

here is a "crude" example of what I was talking about. try: <archive image file version="1.0"> <definitions> a place to put whatever relevant information is needed about the format or achive or your favorite poem or joke </defintions> <target system>Tandy Model 100</target system> <author>Ian Blindly</author> <media> <format>5.25" floppy</format> <default-sector-data value="$AA"/> <encoding>MFM? RLL? something ... </encoding> <tracks>35</tracks> <heads>1</heads> <sectors size="256">18</sectors> <wordsize>8</wordsize> </media> <datamap> <head physical="0"> <track physical="0"> <sector logical="1" physical="4" datablock="DB1" dataitemid="SB1" /> <sector logical="2" physical="8" datablock="DB2" dataitemid="SB1"/> <sector logical="3" physical="12" fill="$00" /> <sector logical="4" physical="16" fill="$00" /> ... </track> <track physical="1"> <sector logical="1" physical="4" fill="$FF" /> <sector logical="9" physical="12" datablock="DB3" dataitemid="SB1"/> </track> <track physical="22" datablock="DB3" dataitemid="SB2" /> </head> </datamap> <datablock id="DB1" type="boot"> <dataitem id="SB1" encoding="HEX" crc="1234">456789ABCDEF...</dataitem> <dataitem id="SB2" encoding="HEX" crc="2341">1234567890A...</dataitem> <dataitem id="SB3" encoding="HEX" crc="3412">890ABCDEF01245...</dataitem> <dataitem id="SB4" encoding="HEX" crc="4123">456789ABCDEF...</dataitem> </datablock> <datablock id="DB2" type="OS"> <dataitem id="SB1" encoding="HEX" crc="1234">456789ABCDEF...</dataitem> <dataitem id="SB2" encoding="HEX" crc="2341">1234567890A...</dataitem> <dataitem id="SB3" encoding="HEX" crc="3412">890ABCDEF01245...</dataitem> <dataitem id="SB4" encoding="HEX" crc="4123">456789ABCDEF...</dataitem> </datablock> <datablock id="DB3" type="file" name="DUMP.ASM"> <dataitem id="SB1" encoding="HEX" crc="1234">456789ABCDEF...</dataitem> <dataitem id="SB2" encoding="HEX" crc="2341">1234567890A...</dataitem> <dataitem id="SB3" encoding="HEX" crc="3412">890ABCDEF01245...</dataitem> <dataitem id="SB4" encoding="HEX" crc="4123">456789ABCDEF...</dataitem> </datablock> </archive image file> please don't get hung up on names, etc, The basic structure is what I have been talking about. A utility can go into the archive file, find a <datablock>, know what it is and extract it without having to know anything about the OS. Another utility can read the media, datamap, and datablocks to re-create tracks in memory to then write out to disk. There was earlier talk about years from now being able to still re-create disks. I think that is a fine ambition, but that still requires all the hardware and intimate OS knowledge to still be around. My idea was to at least be able to extract the data without having to have ANY knowledge of the OS. best regards, Steve Thatcher

22 years

5
6
0 0

Let's develop an open-source media archive standard

by melamy＠earthlink.net

I seem to recall that my slow old N* Horizon was doing dd at 4mhz with no dma - in fact it was polled I/O because their wait for I/O available kept locking up so I modified it. best regards, Steve Thatcher -----Original Message----- From: Fred Cisin <cisin(a)xenosoft.com> Sent: Aug 12, 2004 5:12 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 Thu, 12 Aug 2004, Dwight K. Elvey wrote: > Hi Jules > Here is what I've found. It is a disk drive emulator. > Unless a PC is DMA driven, bit banging a floppy is not practical. Disk I/O without DMA is not practical. But it IS possible. Consider the PCJr and Tandy 1000, both of which do disk I/O without DMA on 4.77MHz? machines.

22 years

1
0
0 0

archive file format exmaple

by melamy＠earthlink.net

my crude example was a form of picture because words just didn't seem to be conveying what I had in mind... :) -----Original Message----- From: Vintage Computer Festival <vcf(a)siconic.com> Sent: Aug 12, 2004 5:33 PM To: "General Discussion: On-Topic and Off-Topic Posts" <cctalk(a)classiccmp.org> Subject: Re: archive file format exmaple On Thu, 12 Aug 2004, Jules Richardson wrote: > On Thu, 2004-08-12 at 11:11, Steve Thatcher wrote: > > here is a "crude" example of what I was talking about. > > [snip] > > That looks good. How's about moving things like author into the > definitions section? I'm not sure that it belongs at the top level, but > more in the section containing archive info (description, creation date > etc.) I think it's rather premature to be discussing implementation :( -- 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 ]

22 years

1
0
0 0

Let's develop an open-source media archive standard

by dwight.elvey＠amd.com

Hi Jules Here is what I've found. It is a disk drive emulator. Unless a PC is DMA driven, bit banging a floppy is not practical. There are just too many other things that the PC is doing on the side. Having a separate dedicated uP is the best way. That device can then either communicate with the host through serial or parallel. Dwight Web pointer: http://www.rothfus.com/SVD/ >From: "Jules Richardson" <julesrichardsonuk(a)yahoo.co.uk> > >On Thu, 2004-08-12 at 00:13, Dwight K. Elvey wrote: >> >From: "Fred Cisin" <cisin(a)xenosoft.com> >> > >> >truly demented idea: >> >build a hardware device that can read the image file, connects >> >via 34 or 50 pin cable to an FDC, and that produces pulses >> >that look like disk data to the FDC. >> > >> Hi >> It has already been done. I can look up the web page if you like. >> Dwight > >yes, please :-) > >I remember asking about this a while back, specifically wondering if a >PC parallel port was fast enough to drive it (not without buffering at >some sort of level, it seemed) > >I wouldn't mind seeing what someone else has come up with. > >cheers > >Jules > >

22 years

2
1
0 0

URL for UT Museum

by jrkeys＠concentric.net

You can check out their museum at http://www.cse.uta.edu/TheMuseum@CSE/

22 years

1
0
0 0

Let's develop an open-source media archive standard

by melamy＠earthlink.net

I did not say it was the primary purpose. The data blocks work hand in hand with the formatting information. It is fine to make a standard extensible, but what good does it do if the (I hate the use the word) file can't be gotten without jumping through major hoops because how the data was stored in the image file wasn't extended out to make blocks. If you have to iterate through formatting information to get data then you have to be intimately familiar with the disk format in use. It means any GENERAL utility to read an image file for data access will have to KNOW about all machione supported rather than just getting some type of data identifier and reading the data out. I think part of the problem here is that the word file is being taken literally to mean filename, size, data, etc. I am using in the context of a block of data. It has NOTHING to do with how the data is on the disk, where it is stored, the recording format, etc. It is just a piece of data... Sellam in a later email thought that I was proposing that the data be duplicated twice - one for file access and one for format data - NO, that is not what I was talking about. The formatting information contains no data other that what may be necessary for things outside of what is considered a sector on a drive such as address mark, etc(note: this does not preclude sequential data - I am only using this as a specific example in this email). I am talking about two separate sections inside the same image file. One of the sections contains data blocks. The other has specific formatting information and POINTS to the data in the data blocks. A utility program could then SIMPLY get any type of data out of the image file without the utility being out of date as soon as someone added a new physical format. I have tried to make this email as clear as possible, so there is no misunderstanding of what I have proposed. best regards, Steve Thatcher -----Original Message----- From: "Dwight K. Elvey" <dwight.elvey(a)amd.com> Sent: Aug 11, 2004 8:11 PM To: cctalk(a)classiccmp.org Subject: RE: Let's develop an open-source media archive standard >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

22 years

2
1
0 0

Let's develop an open-source media archive standard

by RCini＠congressfinancial.com

>>XML is platform neutral because it's basically ASCII, right? Yes, true, but I think of XML more as a Web technology requiring a complex parsing engine. I'm not a Web programmer so my thoughts on XML are probably somewhat broken. Another comment was made about the difference between what's actually on the media versus what the CPU actually sees. We would thus need to capture the raw data stream from the "heads" side of the controller in order to regenerate a usable original media from the metafile. For emulator use, we can grind this metafile through a translation program to get the bytestream. OR, the metafile could contain both types of data (using the container file and metadirectory idea from earlier). What we really need is PDF for magnetic media :-) -----Original Message----- From: cctalk-bounces(a)classiccmp.org [mailto:cctalk-bounces@classiccmp.org]On Behalf Of Vintage Computer Festival Sent: Wednesday, August 11, 2004 3:23 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: > 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 ]

22 years

5
5
0 0

Let's develop an open-source media archive standard

by melamy＠earthlink.net

as Sellam had suggested, the data size we represent the information in is not that important. 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. XML has become a storage format choice for a lot of different commercial packages. My knowledge is more based on the windows world, but I would doubt that other computer software houses are avoiding XML. Sun/Java certainly embraces it. I don't quite understand why representing binary as hex would affect the ability to have command line utilitities. Certainly more cpu cycles are needed for conversion and image file size is larger, but we need a readable format and I would think that cpu cycles is not as much of a concern or file size. A utility to create a disk would only have to run through the conversion once to buffer a representation of the floppy disk (unless we are talking about a hard drive image of course). The file size to re-create a floppy disk is only going to be 2 to 3meg at the most (if thinking about a 1.2meg floppy with fortmatting info). The only difference I see in the sections that were described is that the first one encompasses the format info and the data. My description had the first one as being a big block that contained the two other sections as well as length and CRC info to verify data consistency. Adding author, etc to the big block would make perfect sense. As for GCR, that would have been covered under etc... I am not familiar with GCR, but I would guess that it has to deal at least with physical tracks and heads. In this case, a track would consist of whatever the format needed plus the data blocks required for the track. best regards, Steve Thatcher -----Original Message----- From: Jules Richardson <julesrichardsonuk(a)yahoo.co.uk> Sent: Aug 11, 2004 8:08 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, 2004-08-11 at 10:50, Steve Thatcher wrote: > 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. I haven't done any serious playing with XML in the last couple of years, but back when I did, my experience was that XML is not a good format for mixing human-readable and binary data within the XML structure itself. To make matters worse, the XML spec (at least at the time) did not define whether it was possible to pass several XML documents down the same data stream (or, as we'd likely need for this, XML documents mixed with raw binary). Typically, parsers of the day expected to take control of the data stream and expected it to contain one XML document only - often closing the stream themselves afterwards. I did end up writing my own parser in a couple of KB of code which was a little more flexible in data stream handling (so XML's certainly not a heavyweight format, and could likely be handled on pretty much any machine), but it would be nice to make use of off-the-shelf parsers for platforms that have them where possible. As you've also said, my initial thought for a data format was to keep human-readable config seperate from binary data. The human-readable config would contain a table of lengths/offsets for the binary data giving the actual definition. This does have the advantage that if the binary data happens to be a linear sequence of blocks (sectors in the case of a disk image) then the raw image can easily be extracted if needs be (say, to allow conversion to a different format) Personally, I'm not a fan of mixing binary data in with the human-readable parts because then there are issues of character escaping as well as the structure detracting from the readability. And if encoded binary data is used instead (say, hexadecimal representation) then there's still an issue of readability, plus the archive ends up bloated and extra CPU cycles are needed to decode data. Neither of those two approaches lend themselves to simply being able to use common command-line utilities to extract the data, either. I'm prefectly willing to be convinced, though :) > 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. So, first section is all the 'fuzzy' data (author, date, version info, description etc.), second section describes the layout of the binary data (offsets, surfaces, etc.), and the third section is the raw binary data itself? If so, I'm certainly happy with that :-) One aside - what's the natural way of defining data on a GCR floppy? Do heads/sectors/tracks still make sense as an addressing mode, but it's just that the number of sectors per track varies according to the track number? Or isn't it that simple? cheers Jules

22 years

13
33
0 0

TKQ50 proms

by pete＠dunnington.u-net.com

I'm looking for ROMs (or ROM images would be better) for a TQK50 controller. The ROMs I want are 23-330E5 and 23-331E5. Can anyone help? -- Pete Peter Turnbull Network Manager University of York

22 years

3
2
0 0

Let's develop an open-source media archive standard

by melamy＠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 ... ) > > > >

22 years

3
4
0 0

rarest computers. was: RE: Xerox Alto Restoration + Emulation

by Adrian＠beovax.co.uk

> -----Original Message----- > From: cctalk-bounces(a)classiccmp.org > [mailto:cctalk-bounces@classiccmp.org] On Behalf Of Jules Richardson > Sent: 02 August 2004 23:10 > To: General Discussion: On-Topic and Off-Topic Posts > Subject: Re: rarest computers. was: RE: Xerox Alto > Restoration + Emulation > > > On Mon, 2004-08-02 at 19:56, Vintage Computer Festival wrote: > > On Mon, 2 Aug 2004, Jules Richardson wrote: > > > Apple /// (possibly lots worldwide; there don't seem to be many > > > people this side of the pond who have seen one though) > > > > Very common. > > I figured they might be - just not in this part of the world, it seems > :-) Wonder how many were actually sold in the UK... At least 3 - you've got 1, I've got 2 and I bet Tony's got one somewhere... What might be uncommon these days is a *working* /// :) Cheers w

22 years

3
2
0 0

Metal Case Northstar Horizon

by dwight.elvey＠amd.com

Hi I suspect that most metal cased N*'s were destined to be used in rack mount applications. Dwight >From: "Marvin Johnston" <marvin(a)rain.org> > >Actually, it would be nice to have pictures of all three Northstar >chassis styles. Right now, mine are all buried and I won't get a chance >to get near them for another month or so. But I'll keep my eyes open for >one of the beige ones now :). > >Adrian Graham wrote: >> >> > On Wed, 4 Aug 2004, Marvin Johnston wrote: >> > >> > > Someone mentioned some time ago a metal case instead of the >> > standard >> > > case for the Northstar Horizon. Can anyone confirm if they >> > did put out >> > > a computer in a metal case, and if so, (wishful thinking) how many >> > > they might have produced? I have one here in a powder blue >> > metal case >> >> There's at least one of the metal cased ones in 'storage' at Bletchley >> Park - IMSAI blue with an (I assume) aluminium front, 2 vertical floppy >> drives etc. Got a pic somewhere if anyone's interested, I can't attach >> it to this mail 'cos the list software will bin it. >

22 years

3
2
0 0

Let's develop an open-source media archive standard

by dwight.elvey＠amd.com

>From: "melamy(a)earthlink.net" <melamy(a)earthlink.net> > ---snip--- > >The image file that you are discussing is only good as a "how to" to write >arbitrary data to arbitrary media. It is only good for creating a final >media image because the format being contemplated (mixing data into the >physical spec) will preclude the file from standing on its own. No, that is not true. The description of the physical data in the archive should be sufficient to recover the system side data. I can state this because the system side data is just a subset of the physical data. I recommend that the archive should include enough information to translate from the physical to the system but for archiving purposes, that is not absolutely necessary. It is not that hard to describe as part of the header what FM looks like. Still, if we restrict all archived information to include this, some unknown formats may not be archived because the person with the data doesn't know that format. It is better to capture the data first. It may also be that the only way that person has to capture the data is the output of a controller chip. The archiving should allow this as well ( more in the format the Steve would like it all to be in ). This file could later be combined with the more physical information when that was available, just as a archive file that originally had only physical information could be appended with the data as seen by the system. What this means is that some of the archived files may not be directly useable by Steve and his tools without some more in depth knowledge about the encoding use. It doesn't make it impossible to use, just difficult. Dwight >I was >proposing identifying data blocks as files if that is what they were. The >data blocks would have been sequential and trivial to retrieve. That is >hardly what I would call defining a file system as part of the image file. > >best regards, Steve Thatcher >

22 years

1
0
0 0

Let's develop an open-source media archive standard

by dwight.elvey＠amd.com

>From: "Roger Merchberger" <zmerch(a)30below.com> > >Rumor has it that Vintage Computer Festival may have mentioned these words: >>On Wed, 11 Aug 2004, Steve Thatcher wrote: >> >> > 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. > >I don't wanna sound like a doofus, but: > >So? > >> 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. >> >>You're describing an imagefile that contains a filesystem image, rather >>than, say, a disk image. This can be accomodated in the spec, but it's a >>different type of image than what we've been discussing. > >It could be accommodated, but why should it when it would be easier for >someone to build a converter into an emulator image file? > >This spec (as far as I understand it) is going to be read-only anyway - >this is for archiving after all. What happens when the emulator tries to >rewrite the disk image (say, from saving a modified file)? What will happen >to the original archive? Hi I don't see this as being an issue. Once one knew how to decode the information for such applications that wanted to extract the data, one could import information into the image. It would of course require some knowledge of the data structures used by that system. It would have to know how to resolve things like logical interleaving and allocating space by the allocation methods. > >>It's up to emulator writers to read the spec and adapt to it. > >Bam. That hit the thumbnail right on the head. ;-) > >> We'll make >>the spec as flexible as possible, but first and foremost, the spec is >>intended to archive images of data media, and not to serve as a universal >>emulator image format (though it should be able to be used as such). > >I'd like to add that IMHO it should be "read-only" so the emulator doesn't >destroy the archive when it rewrites certain sectors and/or files. I don't see this as an issue. Once one has the archive file in hand, using it as a method to import external data is surely a valid application. The concept of read-only is just an OS flag that can be overwritten. Surely, someone doing this would rename the file or otherwise indicate that it has change. There is nothing anyone can do to restrict such actions. Why specify something that can not be enforced? We can recommend action. We can recommend that there be a field that indicated any change in the data of an archive and if that change is an overwrite of data or an enhancement of the data. Dwight > >At least that's my take on the deal... >Laterz, >Roger "Merch" Merchberger > >-- >Roger "Merch" Merchberger --- sysadmin, Iceberg Computers >Recycling is good, right??? Randomization is better!!! > >If at first you don't succeed, nuclear warhead >disarmament should *not* be your first career choice. > >

22 years

1
0
0 0

Let's develop an open-source media archive standard

by melamy＠earthlink.net

the emails I received seem to be out of order... I believe what you are saying does satisfy the requirement that I have been proposing. There are different levels of physical to data mapping. I can see target platform code running that creates an image file and might actually send the XML directly out a serial port in zmodem for example. It could send it out as files or strictly embedded data. My point has been to make the file blocks available if the target has them just so the data can be extracted easily. best regards, Steve Original Message: ----------------- From: Vintage Computer Festival vcf(a)siconic.com Date: Thu, 12 Aug 2004 09:39:18 -0700 (PDT) To: cctalk(a)classiccmp.org Subject: RE: Let's develop an open-source media archive standard On Wed, 11 Aug 2004, Steve Thatcher wrote: > I am not assuming anything about the data. The usual use is to have > files... in the case of a paper tape emulator system used for CNC, the > disk structure may not resemble a normal file structure. It still > contains one or more blocks of data. you can apply whatever name to that > you want to. The boot sector on a cp/m 8" disk doesn't have a name, but > it is a block of data that is separate from everything else. Personally, > I would want to be able to "read" the boot sector and potentially even > write it back to an image file. It really doesn't make a difference > whether you access track 0 and sector 1 or a data block inside the image > file that contains the boot code. I see what you're saying now. I suppose another potential format that can be incorporated into the spec is a file-based format, where blocks or "files" are represented inside the archive. I can see this being useful for two purposes: 1) Imaging the filesystem from a medium (as opposed to the medium itself) 2) Incorporating code along the lines of what Dwight has been suggesting that knows how to do special processing of the image it is contained in. The code can be extracted and poked into memory using a very simple algorithm that possibly can be described in comments in the image file. I did suggest that the spec be able to image filesystems in a previous message. I think this comes close enough to what you are describing. It can be modified to also be able to indicate "blocks of data". These blocks could be given an identifier--a name, number, whatever; it doesn't matter, as long as it's an ASCII-representable string--and then extracted >from the image file as needed. Does this satisfy you, Steve? :) -- 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 ] -------------------------------------------------------------------- mail2web - Check your email from the web at http://mail2web.com/ .

22 years

1
0
0 0

RESCUED: pristine systems (DEC)

by waltje＠pdp11.nl

All, Just to let you know I followed up to Lyle's message, and went to see those guys (with Lyle) to see what is there. I am going in there tomorrow morning, and will save the systems from the oven. Basically, we have: - MicroVAX 3600 with RA82 (my new baby ;-) - extra rack filled with 6 pcs RA92 - Cipher magtape unit, frontloader (not in rack) - two VAX 4000(-500A) systems - a stack of BA42 storage expanders with various drives - a stack of MicroVAX 3100 -M38 and -M76 systems - two what seem to be DECsystem 5500 systems - one more VAX 3600 .. and some little things. If you have an interest in any of this (cept the 3600- tis mine!) please contact me off-list so we can work something out. Warning: RA92 dont ship well. This means that it will probably be pickup only, sorry. --f

22 years

4
3
0 0

He shoots... he scores!

by jwest＠classiccmp.org

Just obtained an M4 Data tape drive, model 9914 (800/1600/3200/6250)... just pulled from working service...desktop enclosure... $50 bucks :) I believe it's Differential, not single ended. I haven't kept up with PC technology (hooking this to a PC). Is this older Differential the same as LVD? I believe it had a centronics 50 pin connector labeled "differential". I'm wondering what SCSI card I can use with this... Adaptec 2940? Jay

22 years

2
1
0 0

Let's develop an open-source media archive standard

by melamy＠earthlink.net

I am not assuming anything about the data. The usual use is to have files... in the case of a paper tape emulator system used for CNC, the disk structure may not resemble a normal file structure. It still contains one or more blocks of data. you can apply whatever name to that you want to. The boot sector on a cp/m 8" disk doesn't have a name, but it is a block of data that is separate from everything else. Personally, I would want to be able to "read" the boot sector and potentially even write it back to an image file. It really doesn't make a difference whether you access track 0 and sector 1 or a data block inside the image file that contains the boot code. best regards, Steve Thatcher -----Original Message----- From: "Dwight K. Elvey" <dwight.elvey(a)amd.com> Sent: Aug 11, 2004 1:39 PM To: melamy(a)earthlink.net, cctalk(a)classiccmp.org Subject: RE: Let's develop an open-source media archive standard >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

22 years

2
1
0 0

Welcome back Hans F!

by jpl15＠panix.com

Good to see you back on the List - from your cyber-exile.. Cheers John

22 years

4
4
0 0

Let's develop an open-source media archive standard

by melamy＠earthlink.net

comments embedded below... best regards, Steve Thatcher -----Original Message----- From: Hans Franke <Hans.Franke(a)siemens.com> Sent: Aug 12, 2004 10:06 AM 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 Am 11 Aug 2004 14:47 meinte Steve Thatcher: > 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. Well, physical format and data is not always seperable. In some circumstances the physical format is part of the onformation an application needs, and differs form media to media (e.g. copy protection schemes) *** the separated data that I am talking about is what would be accessed through normal OS channels. Copy protection schemes, special destroyed sectors, etc are not accessible through the OS. > 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. But what if the emulator needs the physical format information? *** I have not proposed that the physical format information be excluded... > 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. At least within a CP/M system it usualy doesn't matter at all how the files are stored on a disk. Except for some odd apps who tried to implement system specific copy protection schemes, all and every CP/M app accesses files just via BDOS which already hides the real disk strukture. *** talk to other people here and one of their arguements for keeping things all together was being able to access track and sector directly. As for BDOS, that is fine, but keep in mind that BDOS was customized for nearly every cp/m platform

22 years

1
0
0 0

archive file format exmaple

by melamy＠earthlink.net

that would be fine. Your <archivetype> is what <media> was all about though i.e. rom definition etc. The archive really doesn't have a type, it does however contain media information and then the data to be accessed or put onto the defined media. best regards, Steve Thatcher -----Original Message----- From: Jason McBrien <jbmcb(a)hotmail.com> Sent: Aug 12, 2004 10:04 AM To: Steve Thatcher <melamy(a)earthlink.net>, "General Discussion: On-Topic and Off-Topic Posts" <cctalk(a)classiccmp.org> Subject: Re: archive file format exmaple How about breaking up the sections a bit, like HTML <head><body> sections? Putting card-catalog information up top in it's own section would speed indexing and searches. Like this: <archive image file version="1.0"> <catalog> <definitions> a place to put whatever relevant information is needed about the format or achive or your favorite poem or joke </defintions> <archiver>Pete Smith</archiver> <method>ROM Dumper V4.12</method> <recdate>02004-02-02</recdate> <title>Omega Race</title> <author>Midway</author> <platform> <mfg>Commodore</mfg> <system>VIC-20</system> </platform> <archivetype> <fmtcategory>ROM</fmtcategory> <fmttype>Game Cartridge</fmttype> </archivetype> </catalog> <format> <default-sector-data value="$AA"/> .... </format> <data> ....etc

22 years

1
0
0 0

Let's develop an open-source media archive standard

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

22 years

4
3
0 0

CCDD Definition

by Hans.Franke＠siemens.com

The following is a XML definition I did some 3+ years ago during a discusion, here on classiccomp (back when there was one list *G*), as an example what a XML storage good for everything from punch card to CD could be. This example shows two CCDD structures, one showing an IBMish tape, the other a disk for a popular 8 Bit micro. (Back then nobody came up with the systems name :). Someone asked recently how to handle multiple XML within one file ... well, that's exactly the way it works :) Gruss H. CCDD stands for Classic Computer Device Data ------------------------- <?xml version="1.0" standalone='yes' ?> <!DOCTYPE CCDD [ <!ELEMENT CCDD (VORSPANN?, META?, (CHANNEL* | DEVICE* | MEDIA))> <!ELEMENT VORSPANN (#PCDATA)> <!ELEMENT META (#PCDATA | SYSTEM | OS)*> <!ELEMENT SYSTEM (#PCDATA)> <!ELEMENT OS (#PCDATA)> <!ELEMENT CHANNEL (META?, DEVICE*)> <!ELEMENT DEVICE (META?, MEDIA*)> <!ELEMENT MEDIA (META?, (RAW | HEAD*) )> <!ELEMENT HEAD (RAW | TRACK*)> <!ELEMENT TRACK (RAW | BLOCK*)> <!ELEMENT BLOCK (RAW | DATA*)> <!ELEMENT DATA (#PCDATA)> <!ELEMENT RAW (#PCDATA)> <!ATTLIST CHANNEL ID ID #IMPLIED> <!ATTLIST DEVICE ID ID #IMPLIED> <!ATTLIST MEDIA ID ID #IMPLIED LFD CDATA #IMPLIED SIZE CDATA #IMPLIED FILLER CDATA #IMPLIED FORMAT CDATA #IMPLIED> <!ATTLIST HEAD LFD CDATA #IMPLIED SIZE CDATA #IMPLIED FILLER CDATA #IMPLIED FORMAT CDATA #IMPLIED> <!ATTLIST TRACK LFD CDATA #IMPLIED SIZE CDATA #IMPLIED FILLER CDATA #IMPLIED FORMAT CDATA #IMPLIED> <!ATTLIST BLOCK LFD CDATA #IMPLIED SIZE CDATA #IMPLIED FILLER CDATA #IMPLIED TYPE (DATA|HEADER|UNDEF) "DATA"> <!ATTLIST DATA SIZE CDATA #IMPLIED FILLER CDATA #IMPLIED ENCODING (CHAR|BIN|SED|INTEL|MOT) "SED"> <!ATTLIST RAW SIZE CDATA #IMPLIED FILLER CDATA #IMPLIED CONTENT (DATA|PYSICAL) "DATA" ENCODING (CHAR|BIN|SED|INTEL|MOT) "SED"> ]> <CCDD> <META> Example for a tape mounted on Drive D0 on Channel 1. </META> <CHANNEL ID="C_1"> <META> Standard type 1 channel </META> <DEVICE ID="D_D0"> <META> T9G (6250bpi) </META> <MEDIA LFD="0" FORMAT="T6250"> <META> First Tape in Device </META> <HEAD LFD="0" SIZE="36" FILLER="00"> <TRACK LFD="16" SIZE="16" FILLER="00"> <BLOCK TYPE="HEADER"> <DATA SIZE="80" ENCODING="CHAR" FILLER=" ">VOL1TAPE001 BS2000 TSOS 4</DATA> </BLOCK> <BLOCK TYPE="HEADER"> <DATA SIZE="80" ENCODING="CHAR" FILLER=" ">UVL1PRIVATE LABEL</DATA> </BLOCK> <BLOCK TYPE="HEADER"> <DATA SIZE="80" ENCODING="CHAR" FILLER=" ">HDR1FILE1 00010001000100000102000102 000000BS2000</DATA> </BLOCK> <BLOCK TYPE="HEADER"> <DATA SIZE="80" ENCODING="CHAR" FILLER=" ">HDR2U020480204841 00</DATA> </BLOCK> <BLOCK TYPE="HEADER"> <DATA SIZE="80" ENCODING="CHAR" FILLER=" ">HDR3TSOS COMPLETE.FILE.NAME.OF.FILE1 0</DATA> </BLOCK> <BLOCK TYPE="DATA"> <DATA SIZE="2048" ENCODING="CHAR" FILLER="">NO REAL DATA INSIDE THIS BLOCK</DATA> </BLOCK> <BLOCK TYPE="HEADER"> <DATA SIZE="80" ENCODING="CHAR" FILLER=" ">EOF1FILE1 00010001000100000102000102 000001BS2000</DATA> </BLOCK> <BLOCK TYPE="HEADER"> <DATA SIZE="80" ENCODING="CHAR" FILLER=" ">EOF2U020480204841 00</DATA> </BLOCK> <BLOCK TYPE="HEADER"> <DATA SIZE="80" ENCODING="CHAR" FILLER=" ">EOF33TSOS COMPLETE.FILE.NAME.OF.FILE1 0</DATA> </BLOCK> </TRACK> </HEAD> </MEDIA> </DEVICE> </CHANNEL> </CCDD> <CCDD> <META> This is another CCDD File for a FD of <SYSTEM>XXXXX</SYSTEM> running under <OS>yyyy</OS>. </META> <MEDIA LFD="0" SIZE="2" FORMAT="GCR"> <META> Floppy disk for xxxxxx </META> <HEAD LFD="0" SIZE="36" FILLER="00"> <TRACK LFD="16" SIZE="16" FILLER="00"> <BLOCK LFD="14"> <DATA SIZE="256" ENCODING="SED" FILLER="00"> </DATA> </BLOCK> <BLOCK LFD="15"> <DATA SIZE="256" ENCODING="SED" FILLER="00"> 000000000000000000000000100E </DATA> </BLOCK> </TRACK> <TRACK LFD="17" SIZE="16" FILLER="00"> <BLOCK LFD="0"> <DATA SIZE="256" ENCODING="SED" FILLER="00"> 04110F030000FE000000000000000000 00000000000000000000000000000000 000000000000007A0000000000000000 23010000231001000000000000000000 00000000000000000000000000000000 00000000000000000000000000000000 00000000000000000000000000000000 000000000000000380010000 </DATA> </BLOCK> <BLOCK LFD="15"> <DATA SIZE="256" ENCODING="SED" FILLER="00"> 0000000000000000000000100F02C8C5 CCCCCFA0A0A0A0A0A0A0A0A0A0A0A0A0 A0A0A0A0A0A0A0A0A0A0A00001 </DATA> </BLOCK> </TRACK> </HEAD> </MEDIA> </CCDD> -- VCF Europa 6.0 am 30.April und 01.Mai 2005 in Muenchen http://www.vcfe.org/

22 years

2
1
0 0

archive file format exmaple

by melamy＠earthlink.net

the keyword arrangement was just a waking thought this morning and is not cast in codecrete. Required fields is definitely a good thing as long as the info is really necessary. The only data that was in the media section was data that was specific to to media such as fill bytes, address marks, etc. Also, I kept a sub block arrangement because a single datablock was supposed to represent a complete data entity such as a file, boot routine, OS itself for example. In order to retrieve any block of data, one only had to find a "datablock" and then concatanate the dataitems. best regards, Steve Thatcher -----Original Message----- From: Jules Richardson <julesrichardsonuk(a)yahoo.co.uk> Sent: Aug 12, 2004 7:50 AM To: cctalk(a)classiccmp.org Subject: Re: archive file format exmaple On Thu, 2004-08-12 at 11:11, Steve Thatcher wrote: > here is a "crude" example of what I was talking about. > [snip] That looks good. How's about moving things like author into the definitions section? I'm not sure that it belongs at the top level, but more in the section containing archive info (description, creation date etc.) I'd suggest making certain fields mandatory in what you've called the definitions section. People tend to be lazy, which means the temptation is there to create an archive and not bother to include much of the information, thinking that they'll know what it is a few years down the line. We've all be caught out by that one! (author, date, description are good candidates for mandatory fields; there'll be others too) I'm not so sure about having the actual data within the archive element; I'd rather have it afterwards. Data in your datamap section still points to chunks of data, using whatever scheme is understood by the storage/compression system used by the archive. But then the possibility is there for using an encoding method that doesn't mix with XML data if needs be. It also makes it easy to scan the archive section by eye as it's not mixed up with huge chunks of encoded media data. Actually, you could probably build collections of media archives (say for some common platform) all within the same file that way, without breaking the format - the data in the datamap section of the first archive section just points to other archives within the same file. That's kinda neat. eg. (simplifying a little for example purposes): <archive image file version="1.0"> <definitions> ... as before ... </defintions> <media> ... as before ... </media> <datamap> <head physical="0"> <track physical="0"> <sector logical="1" physical="4" id="DB1" /> <sector logical="2" physical="8" id="DB2" /> ... </track> </head> </datamap> </archive> <datablock id="DB1" type="boot"> .... </datablock> <datablock id="DB2" type="boot"> .... </datablock> .. that way anything following the archive section doesn't have to be XML data even, providing the definition within the datamap section for the encoding/compression scheme used by the archive can reach it. It might be zipped data, other archive definitions, whatever. cheers, Jules

22 years

1
0
0 0

Let's develop an open-source media archive standard

by RCini＠congressfinancial.com

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

22 years

6
7
0 0

(Fwd) Re: Let's develop an open-source media archive standard

by Hans.Franke＠siemens.com

Second try ------- Weitergeleitete Nachricht / Forwarded message ------- Von: Hans Franke <Hans.Franke(a)mch20.sbs.de> An: "General Discussion: On-Topic and Off-Topic Posts" <cctalk(a)classiccmp.org> Betreff: Re: Let's develop an open-source media archive standard Datum: Wed, 11 Aug 2004 15:16:36 +0200 Am 11 Aug 2004 12:08 meinte Jules Richardson: > On Wed, 2004-08-11 at 10:50, Steve Thatcher wrote: > > 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. > I haven't done any serious playing with XML in the last couple of years, > but back when I did, my experience was that XML is not a good format for > mixing human-readable and binary data within the XML structure itself. Only if you intend to keep it 100% human readable. > To make matters worse, the XML spec (at least at the time) did not > define whether it was possible to pass several XML documents down the > same data stream (or, as we'd likely need for this, XML documents mixed > with raw binary). Typically, parsers of the day expected to take control > of the data stream and expected it to contain one XML document only - > often closing the stream themselves afterwards. Now, that's a feature of the reading application. XML does not stat what happens next since this is outside the scope. It is perfectly op to look for the next Document, or the next start tag of the same document type, or for whatever. > I did end up writing my own parser in a couple of KB of code which was a > little more flexible in data stream handling (so XML's certainly not a > heavyweight format, and could likely be handled on pretty much any > machine), but it would be nice to make use of off-the-shelf parsers for > platforms that have them where possible. Right, but especialy when we're coming down to classic platforms, such building blocks are not always usable, and in general way oversized. On a 48k Apple (or a 64 K 4 MHz CP/M machine) we don't have the space to just port a C-app that has 'only' 100k of code size. So reader/writer applications for the original environment have to be small and special to type. > As you've also said, my initial thought for a data format was to keep > human-readable config seperate from binary data. The human-readable > config would contain a table of lengths/offsets for the binary data > giving the actual definition. This does have the advantage that if the > binary data happens to be a linear sequence of blocks (sectors in the > case of a disk image) then the raw image can easily be extracted if > needs be (say, to allow conversion to a different format) Well, that is only true if you define binary data as 8 Bit and all means of transport as 100% transparent. Just, this hasn't worked that way in the past, and I doubt that we will be safe >from changes in the future. As for the character size: we had in the past everything from 6 to 12 Bit (ok, I can't remember 11 Bit characters/words) as 'binary' characters. Of course 6,7 and 8 Bit Bytes can be easy stored in a 8 Bit Byte, but what about 9 Bit (Bull) or 12 (DEC)? At that point you already have to incooperate speciual trans- formation rules which are not necersary transparent. Also for the requirement of a transparent transport: When transfering files between different architectures we usualy have code or even format conversions. Most notable code conversion would be, for example, ISO 8859-1 <-> EBCDIC which totally destroys the 'binary' part. Or take format conversions as done on the way between Unix style files and (Win-)DOS, LF vs CR/LF. Whenever you leave the A-Z and 0-9 range we are likely to encounter such problems. Shure, one could code an app capable to read ASCII/Binary on a EBCDIC Machine and vice versa, but to my experience (doing programming since 25 years in mixed environments) it's not only a boring job, but also one of the most sensitive to errors. Any kind of standard format must be true machine independent. Thus (at least when using the recommended representation) be able to be transferred across all platforms thinkable of. > > 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. > So, first section is all the 'fuzzy' data (author, date, version info, > description etc.), second section describes the layout of the binary > data (offsets, surfaces, etc.), and the third section is the raw binary > data itself? If so, I'm certainly happy with that :-) I would rather go for an anoted format, where more detailed information can be added at any point, and not necersary in certain sections. Especialy since the 'fuzzy' data is usualy not needed for the job itself. > One aside - what's the natural way of defining data on a GCR floppy? Do > heads/sectors/tracks still make sense as an addressing mode, but it's > just that the number of sectors per track varies according to the track > number? Or isn't it that simple? Well, that's already outside of what a standard definition can define without doubt. To my understanding interpretation of Data is always part of a real application. As soon as it touches machine or format specific implementation details a standard may only give guidelines how to store them properly, but not how to interprete. That's part of an actual reader implementation. And each rader will of course only understand parts he's made for - e.g. a Apple DOS 3.3 reader will have no idea what a tape label for a IBM tape is not to mention be able to differentiate between the various header types. Reader/Writer apps will always be as specific as they are right now, when handling a proprietary format. The big advantage is that intermediate tools, like archiving, indexing, etc.pp can be shared. Well, in fact it's the only advantage, except the fact that one doesn't have to figure out a new format each time, and the simple format does allow the ad hoc inclusion of new machines/systems. Gruss H. --- Ende der weitergeleiteten Nachricht / End of forwarded message --- -- VCF Europa 6.0 am 30.April und 01.Mai 2005 in Muenchen http://www.vcfe.org/

22 years

1
0
0 0

Let's develop an open-source media archive standard

by dwight.elvey＠amd.com

>From: "Fred Cisin" <cisin(a)xenosoft.com> > >truly demented idea: >build a hardware device that can read the image file, connects >via 34 or 50 pin cable to an FDC, and that produces pulses >that look like disk data to the FDC. > > > Hi It has already been done. I can look up the web page if you like. Dwight

22 years

2
1
0 0

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

by dave04a＠dunfield.com

Thanks for the very useful information! >If you want the keyboard to work, you'll need to set up one of the 6520s. If >you just want to see stuff on the screen, there's a table in the ROMs that is >loaded into the 6545 CTRC. There are two sets of values, one for 4032 and one >for 8032 (different ROMs). The other chips are used for IEEE-488, cassette >control, and the user port. No initialization for your purposes required AFAIK. I checked the funet archive and found some details, however the PET "IO" document describes only the 6520's and 6522 - there is no mention of the video controller. The only other references I found to I/O addresses were obviously a disassembley, with such meaningful labels as: AE810 DS 1 AE811 DS 1 AE812 DS 1 Can you tell me where (address) the 6545 is located? I'm going to begin disassembling the Kernel ROM and see if I can figure out enough to turn on the screen - don't need keyboard (yet) - just want to be able to display some info. >Once you extract the table and load the 6545, you should be able to sling >bytes at the screen starting at $8000. Remember that "POKE codes" are not >ASCII nor PETSCII, they are character codes from the chargen ROM (not >accessible to 6502 memory space). There should be some docs on this on funet. >As an example, though, while you might "PRINT CHR$(65)" to get an 'A' on the >screen, you'd "POKE 32768,1" to get that 'A' to appear in the upper left >corner of the screen. I didn't see an obvious reference - can you give me a pointer - all I really need right now is 0-9,A-F and SPACE - I can determine these by fooling with the working machine if I have to. Btw, do anyone have (or know of) a working stand-alone monitor program which can be stuffed into the Kernel ROM position? 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

22 years

2
1
0 0

Let's develop an open-source media archive standard

by vcf＠siconic.com

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 ]

22 years

12
31
0 0

Drive format spreadsheet questions

by zmerch＠30below.com

http://www.30below.com/~zmerch/classics/driveformats.html It's new, it's rough, it's mainly to figure out what kinds of data we need here -- right now, I can see that we need 2 spreadsheets; one for physical drive formats, and one for OS layouts. (and yes, it's evil HTML -> StarOffice 6.0 "saved as .html". I ain't goin' fer pretty yet... ;-) ) Believe me, I realize that it's not anywhere perfect... so I'm asking for more input for whatever (many things) I've forgotten to include. If you have info for different disk formats, please feel free to include them, but please be aware that they may not be integrated until the format is more solid. Jay, I dunno if the addresses are munged in the archives... so I'm going to err on the side of caution here. I have 1 mailing address that as yet gets no spam (so has no spam-filter), and its: {my Ham radio callsign} @30below.com. (If you wanna go the hard way to find it, go here: http://wireless2.fcc.gov/UlsApp/UlsSearch/searchLicense.jsp and search for "Merchberger" and look for my active one.) If not, I'll use the phonetic alphabet, hopefully spammers haven't figured that one out yet for the spiders: Alpha Bravo Ait Kilo Kilo That address gets very little email (unlike my main address which gets around 500 emails/day) so I'll see things quickly there... and also, the main email is personal/work/mailer-daemon/root/catchall/whatever and also has a spamfilter, so I might miss one email there. Rare, but it can (and unforch, does) happen. This way, guaranteed not to be missed in any way. ;-) Thanks, Roger "Merch" Merchberger -- Roger "Merch" Merchberger | A new truth in advertising slogan sysadmin, Iceberg Computers | for MicroSoft: "We're not the oxy... zmerch(a)30below.com | ...in oxymoron!"

22 years

1
0
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.

22 years

1
0
0 0

Let's develop an open-source media archive standard

by melamy＠earthlink.net

Hi Sellam, I sent off another email with a comment with regards to what I was proposing. There is a misunderstanding with regards to what I was proposing. I was not looking at having two copies of the data. Only one is required and that is what the formatting information references when it needs sector data. I think it would be better at this point for us all to try and understand all the facits of what is being done. My proposal for the data blocks are not a file specification per se. I would gather that a data block would consist of a descriptor that would indicate how many blocks comprise the data, a data type such as "file", internal data (boot sector), block ID for use with the formatting info. The formatting info would tell whether it is sequential, track/sector oriented, etc. There is no need to create a bunch of different types. Even your description created two distinct formats for data. I was being more generic in that a engineering design for a image file could be created that was not difficult and could satisfy both EASY emulator access for non-physical media access and image file description for another tool to actually create the media required. best regards, Steve Thatcher -----Original Message----- From: Vintage Computer Festival <vcf(a)siconic.com> Sent: Aug 11, 2004 9:07 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, Steve Thatcher wrote: > 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. This can be done anyway. Parsing the tags should not be too difficult. And unless someone can come up with an elegant way of doing it, what you're proposing will require two sets of data in the imagefile: one in the structured format and one in an unstructured format. I suppose tags could be added to specify this is the case so that "lazy" programs don't have to go through all the trouble of parsing the structured data. > 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. You're describing an imagefile that contains a filesystem image, rather than, say, a disk image. This can be accomodated in the spec, but it's a different type of image than what we've been discussing. Remember, I envision the spec being able to handle: 1) A filesystem image (as you describe) 2) An image in "logical" format (i.e. blocks structured in tracks and sectors for a floppy, or cards for a punch card deck) 3) An image in "raw" format (a bit stream, or the actual punched holes >from a punch card deck) And there's actually a: 2.5) Magnetic media at a level below the "logical" format (decoded tracks and sectors) but above a bit-stream, which would be the raw sectors on a disk or tape including address headers, data headers, prologue/epilogue bytes, sync bytes, etc. > 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 Right. If you choose to store an image in the raw disk format. > 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. It's up to emulator writers to read the spec and adapt to it. We'll make the spec as flexible as possible, but first and foremost, the spec is intended to archive images of data media, and not to serve as a universal emulator image format (though it should be able to be used as such). > Sellam, let me know if you would like to discuss this via telephone so I > can convery the idea that I am proposing. I think I understand what you're saying. Let me know if I still don't get it. -- 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 ]

22 years

1
0
0 0

HP diag library on disc

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]

22 years

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.

22 years

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

22 years

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

22 years

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

22 years

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

22 years

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

22 years

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

22 years

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!

22 years

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

22 years

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

22 years

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

22 years

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

22 years

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

22 years

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

22 years

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

22 years

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

22 years

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 ]

22 years

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 ]

22 years

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

22 years

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

22 years

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

22 years

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

22 years

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 ]

22 years

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 ]

22 years

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

22 years

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.

22 years

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 ]

22 years

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

22 years

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

22 years

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

22 years

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 ]

22 years

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

22 years

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

22 years

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

22 years

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 ]

22 years

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

22 years

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

22 years

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

22 years

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

22 years

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"

22 years

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

22 years

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

22 years

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

22 years

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

22 years

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 >

22 years

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"

22 years

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

22 years

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

22 years

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 ]

22 years

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