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