test-drb August 2004

test-drb@ccmp.vtda.org

283 participants
661 discussions

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

19 years, 10 months

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

19 years, 10 months

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.

19 years, 10 months

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 ]

19 years, 10 months

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 ]

19 years, 10 months

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 >

19 years, 10 months

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

19 years, 10 months

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

19 years, 10 months

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.

19 years, 10 months

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

19 years, 10 months

← Newer
1
...
32
33
34
35
36
37
38
...
67
Older →

Jump to page:

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