He told me there's no Linux support. I should try Keirf's utils or access the hardware with a serial connection.
May be I could try the Supercard in a VM.
-------- Messaggio originale --------
Da: supervinx <supervinx at libero.it>
Data:13/08/2015 08:25 (GMT+01:00)
A: "General Discussion: On-Topic and Off-Topic Posts" <cctalk at classiccmp.org>
Oggetto: R: Re: Writing 8" floppies with SuperCard Pro
Hi!
A bit OT.
I tried the fdadap card successfully reading and writing SD and DD disks, together with a standard ISA controller.
Had to try a bit, since not every disk controller manages SD writes.?
So the FDADAP should be ok, and the problems lie on the Supercard side.
I contacted the Supercard guy, in order to know if there's a Linux support. I've no windows machines, only some specialized DOS one.
-------- Messaggio originale --------
Da: John Foust <jfoust at threedee.com>
Data:13/08/2015? 04:46? (GMT+01:00)
A: cctalk at classiccmp.org
Oggetto: Re: Writing 8" floppies with SuperCard Pro
At 07:27 PM 8/11/2015, Josh Dersch wrote:
>Thus far I've been successful in creating images of floppies, but less successful in writing them back out.? Thus far I've tried a pair of Shugart 851s and a Qume QumeTrack 842.? I'm using a DBit FDADAP (http://www.dbit.com/fdadap.html) to deal with cabling and the TG43 signals.
I'd tried the SuperCard Pro / FDADAP combo last March with no success.
I hope to return to the task.? Maybe it was a problem with my drive(s).
- John
Hi!
A bit OT.
I tried the fdadap card successfully reading and writing SD and DD disks, together with a standard ISA controller.
Had to try a bit, since not every disk controller manages SD writes.?
So the FDADAP should be ok, and the problems lie on the Supercard side.
I contacted the Supercard guy, in order to know if there's a Linux support. I've no windows machines, only some specialized DOS one.
-------- Messaggio originale --------
Da: John Foust <jfoust at threedee.com>
Data:13/08/2015 04:46 (GMT+01:00)
A: cctalk at classiccmp.org
Oggetto: Re: Writing 8" floppies with SuperCard Pro
At 07:27 PM 8/11/2015, Josh Dersch wrote:
>Thus far I've been successful in creating images of floppies, but less successful in writing them back out.? Thus far I've tried a pair of Shugart 851s and a Qume QumeTrack 842.? I'm using a DBit FDADAP (http://www.dbit.com/fdadap.html) to deal with cabling and the TG43 signals.
I'd tried the SuperCard Pro / FDADAP combo last March with no success.
I hope to return to the task.? Maybe it was a problem with my drive(s).
- John
I forgot to mention one item. Since I had VERY few Double Sided
media with the index hole offset that extra 1/2" from the Single Sided
index hole - and I have many RX02 compatible floppy media which
are Single Sided with the index hole in the wrong place for being a
Double Sided media - I added a DPDT switch to the sense circuit
of the DSD 880/30 drive. In the normal position, the Single Sided
floppy media are detected as Single Sided floppy media. In the
opposite position, a Single Sided floppy media is detected as Double
Sided and the DSD 880/30 is then able to read / write both sides
of the floppy media. Since the DSD 880/30 is also able to perform
a LLF (Low Level Format), I am able to use all of the RX02 media
as Double Sided WITHOUT the inconvenience of having to punch
the extra index hole.
>Jerome H. Fine wrote:
> >Josh Dersch wrote:
>
>> Here at the museum I'm evaluating the use of a SuperCard Pro
>> (http://www.cbmstuff.com/proddetail.php?prod=SCP) to archive and
>> duplicate 8" floppies from various machines. It's not technically
>> supported (the manual states that it *should* work but has not been
>> tested, etc.) The disks I'm reading are nothing exotic (They're
>> standard double-density, double-sided disks with an IBM format -- I
>> could use a PC and ImageDisk to do the job, but the SuperCard is very
>> convenient, in theory...)
>>
>> Thus far I've been successful in creating images of floppies, but
>> less successful in writing them back out. Thus far I've tried a pair
>> of Shugart 851s and a Qume QumeTrack 842. I'm using a DBit FDADAP
>> (http://www.dbit.com/fdadap.html) to deal with cabling and the TG43
>> signals. (And the 851s are jumpered properly for the TG43 signal, as
>> far as I can tell). I've also tried a variety of media (Verbatim,
>> Maxell) with the same results (though the position of the bad data
>> varies from attempt to attempt).
>>
>> The issue is that upon reading back a disk that has been written via
>> the SuperCard, data is fine up until about cylinder 60, at which
>> point bad sectors start appearing more and more frequently (though
>> most of the data is still OK). I tried disabling TG43 just to see if
>> it made a difference, and it does - with TG43 disabled sectors
>> written past cylinder 43 read back as garbage.
>>
>> I'm running short of ideas. Anyone else have any experience with
>> this combo? Any suggestions on troubleshooting tips?
>
> I doubt that this suggestion will help, but it might be
> useful for what are called RX03 compatible media.
>
> The RX02 drive from DEC was emulated in hardware
> by DSD (Data Systems Design). DSD Produced a
> drive which was named the DSD 880/30 which consisted
> of 3 * RL02 internal drives and a single floppy drive which
> could read IBM Single Density and DEC Double Density
> floppy media. The DEC names for those two floppy media
> were RX01 and RX02. The actual DEC RX02 drive was
> able to read in both Single Density and Double density modes.
> In the case of the DEC RX01 and DEC RX02 drives, they
> were both Single Sided. Further DEC did at one point intend
> to support a Double Sided drive which I understand was to
> be called the DEC RX03, but it was never released that I
> ever heard about. The software support was specifically
> included in V04.00 of RT-11 in the file DY.MAC, but was
> probably never tested since the code was incorrect. By
> V05.00 of RT-11, DY.MAC no longer contained the extra
> code to support Double Sided media.
>
> DSD extended the support and the DSD 880/30 contained
> an RX03 compatible drive which could read Double Density
> Double Sided media. What I don't know is IF the physical
> characteristics of the Double Density media which DEC and
> DSD supported are identical to the Double Density physical
> characteristics of the floppy media to which you refer as having
> "an IBM format" since I have never encountered any floppy
> media from IBM other than Single Sided / Single Density.
>
> To make matters simple IF the floppy media which you have
> are compatible with DEC RX02 Double Density format, then
> with the DSD RX03 floppy drive, I extended the DY.MAC
> file for RT-11 and it now supports reading a Double Sided /
> Double Density floppy mounted in a DSD RX03 drive. If
> you can manage to locate a DSD 880/30 and controller to
> run on a DEC PDP-11/73 with RT-11, then I can make the
> DYX.SYS device driver available. To first make sure that
> everything will work with the DSD 880/30, you can test your
> floppy to see if a DEC RX02 can at least read the first side of
> your floppy.
>
> Please let me know if you know the answer to if your Double
> Sided / Double Density floppy media are DEC RX02 compatible
> on at least the first side. If that is true, then the DSD 880/30
> drive will probably be able to read both sides very easily.
>
> If you have any questions, please ask.
>
> Jerome Fine
At 07:27 PM 8/11/2015, Josh Dersch wrote:
>Thus far I've been successful in creating images of floppies, but less successful in writing them back out. Thus far I've tried a pair of Shugart 851s and a Qume QumeTrack 842. I'm using a DBit FDADAP (http://www.dbit.com/fdadap.html) to deal with cabling and the TG43 signals.
I'd tried the SuperCard Pro / FDADAP combo last March with no success.
I hope to return to the task. Maybe it was a problem with my drive(s).
- John
Here at the museum I'm evaluating the use of a SuperCard Pro (http://www.cbmstuff.com/proddetail.php?prod=SCP) to archive and duplicate 8" floppies from various machines. It's not technically supported (the manual states that it *should* work but has not been tested, etc.) The disks I'm reading are nothing exotic (They're standard double-density, double-sided disks with an IBM format -- I could use a PC and ImageDisk to do the job, but the SuperCard is very convenient, in theory...)
Thus far I've been successful in creating images of floppies, but less successful in writing them back out. Thus far I've tried a pair of Shugart 851s and a Qume QumeTrack 842. I'm using a DBit FDADAP (http://www.dbit.com/fdadap.html) to deal with cabling and the TG43 signals. (And the 851s are jumpered properly for the TG43 signal, as far as I can tell). I've also tried a variety of media (Verbatim, Maxell) with the same results (though the position of the bad data varies from attempt to attempt).
The issue is that upon reading back a disk that has been written via the SuperCard, data is fine up until about cylinder 60, at which point bad sectors start appearing more and more frequently (though most of the data is still OK). I tried disabling TG43 just to see if it made a difference, and it does - with TG43 disabled sectors written past cylinder 43 read back as garbage.
I'm running short of ideas. Anyone else have any experience with this combo? Any suggestions on troubleshooting tips?
Thanks,
Josh
Sr. Vintage Software Engineer
Living Computer Museum
www.livingcomputermuseum.org<http://www.livingcomputermuseum.org>
I forgot to mention one item. Since I had VERY few Double Sided
media with the index hole offset that extra 1/2" from the Single Sided
index hole - and I have many RX02 compatible floppy media which
are Single Sided with the index hole in the wrong place for being a
Double Sided media - I added a DPDT switch to the sense circuit
of the DSD 880/30 drive. In the normal position, the Single Sided
floppy media are detected as Single Sided floppy media. In the
opposite position, a Single Sided floppy media is detected as Double
Sided and the DSD 880/30 is then able to read / write both sides
of the floppy media. Since the DSD 880/30 is also able to perform
a LLF (Low Level Format), I am able to use all of the RX02 media
as Double Sided WITHOUT the inconvenience of having to punch
the extra index hole.
>Jerome H. Fine wrote:
> >Josh Dersch wrote:
>
>> Here at the museum I'm evaluating the use of a SuperCard Pro
>> (http://www.cbmstuff.com/proddetail.php?prod=SCP) to archive and
>> duplicate 8" floppies from various machines. It's not technically
>> supported (the manual states that it *should* work but has not been
>> tested, etc.) The disks I'm reading are nothing exotic (They're
>> standard double-density, double-sided disks with an IBM format -- I
>> could use a PC and ImageDisk to do the job, but the SuperCard is very
>> convenient, in theory...)
>>
>> Thus far I've been successful in creating images of floppies, but
>> less successful in writing them back out. Thus far I've tried a pair
>> of Shugart 851s and a Qume QumeTrack 842. I'm using a DBit FDADAP
>> (http://www.dbit.com/fdadap.html) to deal with cabling and the TG43
>> signals. (And the 851s are jumpered properly for the TG43 signal, as
>> far as I can tell). I've also tried a variety of media (Verbatim,
>> Maxell) with the same results (though the position of the bad data
>> varies from attempt to attempt).
>>
>> The issue is that upon reading back a disk that has been written via
>> the SuperCard, data is fine up until about cylinder 60, at which
>> point bad sectors start appearing more and more frequently (though
>> most of the data is still OK). I tried disabling TG43 just to see if
>> it made a difference, and it does - with TG43 disabled sectors
>> written past cylinder 43 read back as garbage.
>>
>> I'm running short of ideas. Anyone else have any experience with
>> this combo? Any suggestions on troubleshooting tips?
>
> I doubt that this suggestion will help, but it might be
> useful for what are called RX03 compatible media.
>
> The RX02 drive from DEC was emulated in hardware
> by DSD (Data Systems Design). DSD Produced a
> drive which was named the DSD 880/30 which consisted
> of 3 * RL02 internal drives and a single floppy drive which
> could read IBM Single Density and DEC Double Density
> floppy media. The DEC names for those two floppy media
> were RX01 and RX02. The actual DEC RX02 drive was
> able to read in both Single Density and Double density modes.
> In the case of the DEC RX01 and DEC RX02 drives, they
> were both Single Sided. Further DEC did at one point intend
> to support a Double Sided drive which I understand was to
> be called the DEC RX03, but it was never released that I
> ever heard about. The software support was specifically
> included in V04.00 of RT-11 in the file DY.MAC, but was
> probably never tested since the code was incorrect. By
> V05.00 of RT-11, DY.MAC no longer contained the extra
> code to support Double Sided media.
>
> DSD extended the support and the DSD 880/30 contained
> an RX03 compatible drive which could read Double Density
> Double Sided media. What I don't know is IF the physical
> characteristics of the Double Density media which DEC and
> DSD supported are identical to the Double Density physical
> characteristics of the floppy media to which you refer as having
> "an IBM format" since I have never encountered any floppy
> media from IBM other than Single Sided / Single Density.
>
> To make matters simple IF the floppy media which you have
> are compatible with DEC RX02 Double Density format, then
> with the DSD RX03 floppy drive, I extended the DY.MAC
> file for RT-11 and it now supports reading a Double Sided /
> Double Density floppy mounted in a DSD RX03 drive. If
> you can manage to locate a DSD 880/30 and controller to
> run on a DEC PDP-11/73 with RT-11, then I can make the
> DYX.SYS device driver available. To first make sure that
> everything will work with the DSD 880/30, you can test your
> floppy to see if a DEC RX02 can at least read the first side of
> your floppy.
>
> Please let me know if you know the answer to if your Double
> Sided / Double Density floppy media are DEC RX02 compatible
> on at least the first side. If that is true, then the DSD 880/30
> drive will probably be able to read both sides very easily.
>
> If you have any questions, please ask.
>
> Jerome Fine
I'm trying to find docs for monolithic systems 8009 board.
multibus I, z80, RAM ROM 2 serial, FDC.
I see references to the board online but no actual docs.
I'm looking for information (schematic) for the on board interrupt logic
and bus interface.
I've figured out enough to get CP/M 2.2 running on it but things like
interrupts,bus time out and arbitration are implemented in PALs and defy
my attempts at reverse engineering.
Even docs from another model (800X) may prove useful since similar
logic may be used.
thanks
joe lang
On Mon, Aug 10, 2015 at 1:00 PM, <cctech-request at classiccmp.org> wrote:
> From: Brent Hilpert <hilpert at cs.ubc.ca>
>
> There was also AlgolW, supported on MTS.
>
> As MTS was being mentioned earlier I was going to ask if anyone knew
> whether the AlgolW compiler was included in the available distribution.
>
?The sources are available - they were googlable - send me a note off list
and I can put together a tar image of what I have. FYI: It was written
PL/360. I did some hacking on it under TSS years ago.? IIRC Wirth did
AlgolW on the 360 at Stanford which was running one of the OS/360 flavors.
CMU ported to TSS and Michigan to MTS.
also check out:
The Programming Languages Genealogy Project
http://everything2.com/title/the+Programming+Languages+Genealogy+Project
?Clem?
> From: Paul Koning
> Every machine needs a fast memory system. CISC machines just as much,
> after all the number of memory references per operation of a given kind
> doesn't depend on the sort of CPU architecture you use.
You're forgetting the memory bandwidth for the instruction fetching. RISC
machines execute a stream of simple, low-level instructions, whereas CISC
machines tend to do fewer, (semantically) higher-level operations - and in
the process, use less memory bandwidth for instructions.
To be tedious (sorry), for example, instead of of the RISC instruction
sequence 'move register Ra to Rt1; add constant X to Rt1; move mem loc (Rt1)
to Rt2; add Rn to Rt2; move Rt2 to mem loc (Rt1)', a CISC would just do 'add
Rn to mem loc X[Ra]'. Same number of _data_ reads/writes, but a very different
count of instruction fetches.
The CISC tradeoff (fewer, slower, instructions) made sense 'back in the day',
and not just for memory bandwidth - it made for more compact code, back when
memory was in very short supply (by today's standards).
Now, of course, a number of technological changes - primarily multi-level
caches - have changed the 'sweet spot' for optimal instruction complexity,
while keeping the memory bandwidth needed for instruction fetches down.
Noel
