16 Jun
2006
16 Jun
'06
5:27 a.m.
A while ago (late '80s, early '90s) I heard a suggestion for using copier toner as
PCB etch resist
(draw on paper, copy onto overhead transparencies, iron onto the PCB).
Now that PCB layout software is available easily, as are laser printers, has anyone here
tried
it? I'm wondering how well it would resolve for finer-pitch DIP/SIP packages, or if
the etchant would eat
through the traces.
16 Jun
16 Jun
5:58 a.m.
On 6/16/2006 at 12:27 AM Scott Quinn wrote:
A while ago (late '80s, early '90s) I heard a
suggestion for using copier
toner as PCB etch resist
(draw on paper, copy onto overhead transparencies, iron onto the PCB).
Now that PCB layout software is available easily, as are laser printers,
has anyone here tried
it? I'm wondering how well it would resolve for finer-pitch DIP/SIP
packages, or if the etchant would eat through the traces.
I tried it once; it's been a long time and the results weren't wonderful.
IIRC, it involved printing onto a transfer medium land then transferring
the toner to the PCB blank using a heat sorce like a household flatiron.
It was barely adequate for regular DIP. I used a PCB design program on an
Atari 540ST (one of the better choices for that kind of stuff in its day).
I still have the software, if anyone's interested.
Did anyone have better luck with it? Maybe it has a lot ot do with the
toner.
Cheers,
Chuck
2:48 p.m.
On Friday 16 June 2006 01:58 am, Chuck Guzis wrote:
Did anyone have better luck with it? Maybe it has a
lot ot do with the
toner.
Actually from what I read the paper is the key. And using a flatiron isn't
the best choice to heat the stuff, either...
--
Member of the toughest, meanest, deadliest, most unrelenting -- and
ablest -- form of life in this section of space, a critter that can
be killed but can't be tamed. --Robert A. Heinlein, "The Puppet Masters"
-
Information is more dangerous than cannon to a society ruled by lies. --James
M Dakin
3:41 p.m.
In message <200606161048.19926.rtellason at verizon.net>
"Roy J. Tellason" <rtellason at verizon.net> wrote:
Actually from what I read the paper is the key. And
using a flatiron isn't
the best choice to heat the stuff, either...
Apparently the best way is to steal a fuser out of a broken LJ2 or LJ3, wire
up a temperature controller and use that to melt the toner onto the copper.
I've been using Staples inkjet photo paper, but it seems they've switched
suppliers and the new stuff doesn't work for TT at all. It didn't even work
properly when I used it with the inkjet to print some photos off - the ink
just smeared straight off (even after half an hour drying in a warm room).
--
Phil. | Kitsune: Acorn RiscPC SA202 64M+6G VF+UniPod
philpem at dsl.pipex.com | Cheetah: Athlon64 3200+ A8VDeluxeV2 1G+180G
http://www.philpem.me.uk/ | Tiger: Toshiba SatPro4600 Celeron700 256M+40G
3:29 p.m.
Chuck Guzis wrote:
On 6/16/2006 at 12:27 AM Scott Quinn wrote:
I think people found it worked better to print the circuit on mylar,
then use the regular photo-resist-etch method.
A while ago (late '80s, early '90s) I
heard a suggestion for using copier
toner as PCB etch resist
(draw on paper, copy onto overhead transparencies, iron onto the PCB).
Now that PCB layout software is available easily, as are laser printers,
has anyone here tried
it? I'm wondering how well it would resolve for finer-pitch DIP/SIP
packages, or if the etchant would eat through the traces.
I tried it once; it's been a long time and the results weren't wonderful.
IIRC, it involved printing onto a transfer medium land then transferring
the toner to the PCB blank using a heat sorce like a household flatiron.
It was barely adequate for regular DIP. I used a PCB design program on an
Atari 540ST (one of the better choices for that kind of stuff in its day).
I still have the software, if anyone's interested.
Did anyone have better luck with it? Maybe it has a lot ot do with the
toner.
8:02 a.m.
Scott Quinn wrote:
A while ago (late '80s, early '90s) I heard a
suggestion for using copier toner as PCB etch resist
(draw on paper, copy onto overhead transparencies, iron onto the PCB).
Now that PCB layout software is available easily, as are laser printers, has anyone here
tried
it? I'm wondering how well it would resolve for finer-pitch DIP/SIP packages, or if
the etchant would eat
through the traces.
One of the last of the local component retailers around here sells this system:
http://www.pulsar.gs/PCB/a_Pages/1_Menu/overview.html
It *claims* to have good pitch resolution and the etchant getting through the
toner to the traces is supposed to be addressed by the application of a second
type of film which adheres to the toner.
I've been thinking about trying it, but have yet to do so. It would be worth
it if it works, but it's in the category of "ya spends y'r money and takes
y'r chances".
As a kid in the 70s I made PCBs using the photo-resist technique, but I can't
find supplies for that anymore, at least not locally (and it was a tedious process).
1:57 p.m.
Rumor has it that Brent Hilpert may have mentioned these words:
Scott Quinn wrote:
It's entirely possible - but *getting* that resolution is damn tough... see
below:
A while ago (late '80s, early '90s) I
heard a suggestion for using
copier toner as PCB etch resist
(draw on paper, copy onto overhead
transparencies, iron onto the PCB).
Now that PCB layout software is available easily, as are laser
printers, has
anyone here tried
it? I'm wondering how well it would resolve
for finer-pitch DIP/SIP
packages, or if the etchant would eat
through the traces.
One of the last of the local component retailers around here sells this
system:
http://www.pulsar.gs/PCB/a_Pages/1_Menu/overview.html
It *claims* to have good pitch resolution... I've been thinking about trying it, but have yet to
do so. It would be worth
it if it works, but it's in the category of "ya spends y'r money and takes
y'r chances".
In this case, it's "ya spends y'r money, then ya gots no more money." I
spent my money. I spent it again on a photo-resist kit. ;-)
From what I understand, you can make it work very well, with 3 things to
keep in mind:
1) the stuff was designed a *long* time ago - it does *not* work well with
newer laser printers (If it says "MicroFine Toner" beware - AFICT, this
toner needs a higher fusing temp. and the media's not able to handle that
well.) and certainly not with any color lasers that use fuser oil (read:
most of 'em). Use an old LaserJet II at 300DPI, and it should work OK..... if:
2) you keep in mind it's a one-shot-wonder. You can't print a half-page,
then save the other half-page for later - once it's been heated by the
toner, it's done for. It either gets expensive, or you have to save up your
projects for one go.
3) You can precisely control the temperature, pressure & humidity of the
heat transfer. The last time I tried it, it took four sheets of the stuff
to build a (really basic) 3x3 inch board, and I still had to touch up a few
of the traces before etching and one piece of kynar afterwards where the
paper bubbled "just a touch" in just the wrong spot due to uneven heating
(I'm guessing).
Personally, I'd point-to-point solder with fishing line before using the
stuff again...
As a kid in the 70s I made PCBs using the photo-resist
technique, but I can't
find supplies for that anymore, at least not locally (and it was a tedious
process).
This place has a kit, and a *really* good beginners book for it:
http://www.circuitspecialists.com/
[[ more specifically:
http://www.circuitspecialists.com/prod.itml/icOid/7783 (the book)
http://www.circuitspecialists.com/level.itml/icOid/7156 (the hardware)
]]
I'd suggest spending a bit more money for the better etchant tank &
aquarium heater, and the better exposure lamp.
They do sell some toner-transfer paper stuff, but even in the book they say
that the product doesn't work well... ;-)
They've got about the best prices for presensitized boards I've found, too.
[[ No affiliation except a satisfied customer... ]]
HTH,
Roger "Merch" Merchberger
--
Roger "Merch" Merchberger -- SysAdmin, Iceberg Computers
zmerch at 30below.com
What do you do when Life gives you lemons,
and you don't *like* lemonade?????????????
2:34 p.m.
New subject: Floppy stepping problem
Hi
I've been writng some code to transfer disk images to my Olivetti
M20. It uses 340K but with the first track being FM while the
rest is MFM. I've found a good controller to handle the FM but
I'm still having a stepper problems.
When I transfer, using the hard drive as the source, things work
fine. When I try to transfer from the 1.44M drive, I have to do a
lot of Recal's on the 360K drive I'm using. I use DOS to fetch the
image from the 1.44M. When I do this, the stepper on the 360k
drive can't keep up and it corrupts the position. This requires a
Recal to resort the stepper. Even a Read ID doesn't work because
it is left partially stepped.
How does DOS keep the mixed drives happy? They don't seem to
be doing a lot of Recal's when transfering files. I've tried a
number of things but I've not found any simple answer.
Dwight
4:05 p.m.
New subject: Floppy stepping problem
Dwight,
DOS (actually the BIOS) uses a table with an entry for each drive to
indicate several things like specify bytes (which sets stepping rates).
Later 5.25" drives tend to step at 6 ms per cylinder, although some older
drives (e.g. SA400) require longer than that. 3.5" drives typically can
step at 3-4 msec. per track.
It doesn't hurt a drive to step it more slowly than the manufacturer
specifies, but it does tend to increase the noise level. As a quick fix,
you may simply want to slow everything down.
What's the FDC chip in the M20?
Cheers,
Chuck
4:52 p.m.
New subject: Floppy stepping problem
Subject: Re: Floppy stepping problem
DOS (actually the BIOS) uses a table with an entry for
each drive to
indicate several things like specify bytes (which sets stepping rates).
Later 5.25" drives tend to step at 6 ms per cylinder, although some older
drives (e.g. SA400) require longer than that. 3.5" drives typically can
step at 3-4 msec. per track.
It doesn't hurt a drive to step it more slowly than the manufacturer
specifies, but it does tend to increase the noise level. As a quick fix,
you may simply want to slow everything down.
Years ago I experimented with the MicroSolutions Compaticard 4. The
documentation included some tables showing how to change the stepping rate.
This was especially important for 8" drives, as I recall.
The experiments were made a necessity, as I had to read some funny CP/M
disks, and it showed that the BIOS's embedded in newer systems (I'm now
speaking of 486/50's etc) could not read 180 KB and 160 KB disks anymore,
not to speak of 8" disks.
The compaticard solved my problems; I could even generate a bootable 8" disk
for DOS 3.20
Nico
6:05 p.m.
New subject: Floppy stepping problem
On 6/16/2006 at 6:52 PM Nico de Jong wrote:
The experiments were made a necessity, as I had to read
some funny CP/M
disks, and it showed that the BIOS's embedded in newer systems (I'm now
speaking of 486/50's etc) could not read 180 KB and 160 KB disks anymore,
not to speak of 8" disks.
I think it's more like the BIOSes can, but their CMOS setup programs don't
know the first thing about anything about older drives. I suspect that the
DPB for any drive can be modified even in a modern PC to step at any rate
the FDC is capable of. I've got some old Micropolis 100 tpi 5.25' drives
that require a full 30 msec. track-to-track.
Cheers,
Chuck
17 Jun
17 Jun
2:23 a.m.
New subject: Floppy stepping problem
From: "Chuck Guzis" <cclist at
sydex.com>
Dwight,
DOS (actually the BIOS) uses a table with an entry for each drive to
indicate several things like specify bytes (which sets stepping rates).
Later 5.25" drives tend to step at 6 ms per cylinder, although some older
drives (e.g. SA400) require longer than that. 3.5" drives typically can
step at 3-4 msec. per track.
It doesn't hurt a drive to step it more slowly than the manufacturer
specifies, but it does tend to increase the noise level. As a quick fix,
you may simply want to slow everything down.
What's the FDC chip in the M20?
Cheers,
Chuck
Hi
I've had no problems setting the step rate for the drive
by writing directly to the PC controller. The problem has been that
when I use DOS's routines to access the imgae file, it overwrites
what I put into the disk controller. This wouldn't be an issue
if it were not for the fact that both drives seem to be stepping at the same
time when doing a seek. I thought that once the motor was
turned off, the drive wouldn't step. This doesn't seem to be the case.
I did some research and found that DOS uses values stored in a table
that is pointed to by interrupt location 1E. I'll change this to run at the
slower rate. This is called the "Disk Base Table".
I'm not sure what this matters but the Olivetti M20 uses a WD1791
with a WD1691 chip. I can create M20 floppies with my PC using
the hard drive. My problem is if I use the other floppy as the source.
Some of the people that will be using my code may not have a
hard drive to run from. Many that have 360K drives are floppy based
systems.
I'll see what changing the parameters in the table does. It should
help. I'll report back with the results.
Dwight
5:27 a.m.
New subject: Floppy stepping problem
Okay, I misunderstood--I thought you were doing this with your M20.
Yes, the simplest way is to change the pointer to the DBT, rather than the
DBT contents themselves. Change the table pointer, then do a diskette
reset (AH=00) to make sure that the BIOS routines notice.
Unless you 've got your drive jumpers set wrong, though, a drive should
only step when selected (the motor state doesn't matter--most drives will
step with the motor off or on).
I'm assuming that you're running in real-mode DOS, not trying to run under
a virtualized DOS command prompt session in Windoze. Starting with W95
OSR2, Windows uses its own floppy VXD that has its own peculiarities.
Cheers,
Chuck
6:07 a.m.
New subject: QIC-80 peculiarities was Re: Floppy stepping problem
From: "Chuck Guzis" <cclist at sydex.com>
I'm assuming that you're running in real-mode
DOS, not trying to run under
a virtualized DOS command prompt session in Windoze. Starting with W95
OSR2, Windows uses its own floppy VXD that has its own peculiarities.
One of my conversion systems, http://www.farumdata.dk/uk/enserv.asp , runs
as Windows 2000 or DOS 3.something. The DOS is used only for accessing the
Irwin Rhomat drive (connected to the floppy controller as drive B), as I
cant get it to work under Windows.
Could the thing you mentioned above, be the reason for it ?
Nico
6:25 a.m.
New subject: QIC-80 peculiarities was Re: Floppy stepping problem
On 6/17/2006 at 8:07 AM Nico de Jong wrote:
One of my conversion systems,
http://www.farumdata.dk/uk/enserv.asp , runs
as Windows 2000 or DOS 3.something. The DOS is used only for accessing the
Irwin Rhomat drive (connected to the floppy controller as drive B), as I
cant get it to work under Windows.
Could the thing you mentioned above, be the reason for it ?
Almost certainly. Win2K/NT/XP has a very lame VDD to convert some simple
port accesses to diskette driver commands, but it doesn't try very hard.
When we offer our conversion software for 2K/XP, we have a special
kernel-mode device driver to handle it. This is also the reason that you
can't read a floppy under XP/2K if it doesn't have a DOS boot sector on
it--the floppy driver actually reads the boot sector to figure out how it
should set things up.
A better VDD for Windows might help 16-bit programs that attempt to
directly access the FDC, but it would do nothing for 32-bit programs.
Cheers,
Chuck
4:28 p.m.
New subject: QIC-80 peculiarities was Re: Floppy stepping problem
From: "Chuck Guzis" <cclist at
sydex.com>
---snip---
A better VDD for Windows might help 16-bit programs that attempt to
directly access the FDC, but it would do nothing for 32-bit programs.
And on to 64 bit :)
Dwight
Cheers,
Chuck
4:45 p.m.
New subject: QIC-80 peculiarities was Re: Floppy stepping problem
On 6/17/2006 at 9:28 AM dwight elvey wrote:
And on to 64 bit :)
Dwight
So, you ask, "why doesn't someone write a better VDD for XP/2000?"
Because MS has made it very clear that Vista won't support 16 bit apps.
Period. Maybe they'll relent at the last minute (they've been known to do
it), but right now, it's not even clear that if they tucked 16 bit support
back in, that Vista would support VDDs.
Cheers,
Chuck
4:25 p.m.
New subject: Floppy stepping problem
From: "Chuck Guzis" <cclist at
sydex.com>
Okay, I misunderstood--I thought you were doing this with your M20.
Yes, the simplest way is to change the pointer to the DBT, rather than the
DBT contents themselves. Change the table pointer, then do a diskette
reset (AH=00) to make sure that the BIOS routines notice.
Unless you 've got your drive jumpers set wrong, though, a drive should
only step when selected (the motor state doesn't matter--most drives will
step with the motor off or on).
Hi Chuck
The 360K floppy I have, only has the drive select jumpers. I've tried
changing the DBT and using Int 13 but it is still not working. I guess I'll
just have to live with it. It is working, it is just that when the 1.44M
goes
to another track, I have to recal the 360K drive. Noisy and takes some time
but it does work. It doesn't seem to corrupt the 1.44M when the
360K steps so I'd think that drive is ignoring the steps as it should.
The 1.44 does seem to be making the slower steps after the Int 13
so that is working correctly. Still, even the ReadID fails after the 1.44
moves several sectors. I guess one should use a less fragmented disk ;)
I'm not sure why the ReadID is not working?? If the steps are
at a compatable rate, the 360K drive should be able to get back by
just the ReadID????
I'm assuming that you're running in real-mode
DOS, not trying to run under
a virtualized DOS command prompt session in Windoze. Starting with W95
OSR2, Windows uses its own floppy VXD that has its own peculiarities.
I don't expect it would work there. Others that are doing direct floppy
access haven't had much success using the DOS window either.
Cheers,
Chuck
4:51 p.m.
New subject: Floppy stepping problem
On 6/17/2006 at 9:25 AM dwight elvey wrote:
The 360K floppy I have, only has the drive select
jumpers. I've tried
changing the DBT and using Int 13 but it is still not working. I guess
I'll
just have to live with it. It is working, it is just
that when the 1.44M
goes>to another track, I have to recal the 360K drive...
Let's see if we can solve this.
I'm going to go out on a limb here and ask you to carefully check your
cable that you're using. If you can, put another 1.44MB drive in place of
the 360K and see if it behaves similarly. If it does, check your cable; if
not, you might well have a wonky 360K drive.
What vintage PeeCee are you using? This isn't one of the more modern ones
with support for only a single drive built onto the mobo, is it?
Does your 360K drive have the terminator installed? If not, have you tried
it with the terminator? (you don't need to use the standard 150 ohm ones;
1K should be good enough).
Cheers,
Chuck
8:54 p.m.
New subject: Floppy stepping problem
>The 360K floppy I have, only has the drive select
jumpers. I've tried
>changing the DBT and using Int 13 but it is still not working. I guess
>I'll just have to live with it. It is working, it is just that when the
>1.44M goes>to another track, I have to recal the 360K drive...
On Sat, 17 Jun 2006, Chuck Guzis wrote:
Does your 360K drive have the terminator installed?
If not, have you tried
it with the terminator? (you don't need to use the standard 150 ohm ones;
1K should be good enough).
Check pin 34 of the drive. Is it using it for "Disk Change", or for
"READY"?
Use Int 1Eh to point to a new parameter table, copied from the old one.
Insert some code to check whether 1E is still pointing to your table after
a floppy access.
Insert some code to check the validity of your table after a floppy access.
Point 1E back to where it was, afterwards.
Check the behavior under DOS 2.10 (which has the absolutely slowest
default step rates (to work with the Qume 142))
What else can be narrowed down as occurring when you get the recals?
(several other kinds of floppy errors could result in a recal.)
Can you assume that everyone will have 640K?
You COULD read the image into RAM, to avoid any switching of floppies.
9:32 p.m.
New subject: Floppy stepping problem
From: Fred Cisin <cisin at xenosoft.com>
Reply-To: "General Discussion: On-Topic and Off-Topic
Posts"<cctalk at classiccmp.org>
To: "General Discussion: On-Topic and Off-Topic Posts"
<cctalk at classiccmp.org>
Subject: Re: Floppy stepping problem
Date: Sat, 17 Jun 2006 13:54:22 -0700 (PDT)
Hi Fred
I had issues getting the 1.44M to work at all with the wire from the
360K disk connected. I've removed the wire from the 360K disk. The
360K seems to work fine when staying in the DOS world. I'm able to
transfer files to and from the 1.44M to the 360K. It is only when I use
my program that it gets lost.
>The 360K floppy I have, only has the drive
select jumpers. I've tried
>changing the DBT and using Int 13 but it is still not working. I guess
>I'll just have to live with it. It is working, it is just that when the
>1.44M goes>to another track, I have to recal the 360K drive...
On Sat, 17 Jun 2006, Chuck Guzis wrote:
Does your 360K drive have the terminator
installed? If not, have you
tried
it with the terminator? (you don't need to
use the standard 150 ohm
ones;
1K should be good enough).
Check pin 34 of the drive. Is it using it for "Disk Change", or for
"READY"?
Use Int 1Eh to point to a new parameter table, copied from the old one.
Insert some code to check whether 1E is still pointing to your table after
a floppy access.
Insert some code to check the validity of your table after a floppy access.
Point 1E back to where it was, afterwards.
According to what I've seen, one also needs to do INT 13 with AH=0
to get these values transfered to the controller.
Check the behavior under DOS 2.10 (which has the absolutely slowest
default step rates (to work with the Qume 142))
What else can be narrowed down as occurring when you get the recals?
(several other kinds of floppy errors could result in a recal.)
I'd do another post with psudo code to show what I do.
Can you assume that everyone will have 640K?
You COULD read the image into RAM, to avoid any switching of floppies.
I've thought about that but the way I'm generating my program assume
to run in a 64K memory chunk. I do have a few that I know don't have a
full 640K. I'd like to stay within what I can do in a *.COM file.
I'm currently doing a full track.
Dwight
10:14 p.m.
New subject: Floppy stepping problem
Hi
Here is a typical read cycle for getting a track from the M20 disk:
FOR sector 1 to 11
setup DMA
write clock rate to 3F7h ( may be FM or MFM )
BEGIN
set drive motor timeout to nice long number for DOS so it doesn't
turn the motor off while I'm using it.
If the motor isn't already on, turn it on and add a little delay
time
to get it up to speed.
Do a SEEK to the track ( I do this every time even if I'm already on
that track )
Clear Interrupt status bit in DOS
Write all the stuff to the controller to read a sector ( including
if it is FM or MFM )
Wait until there is an interrupt 6 and then read all the returned
status
WHILE the status fails
if second try, do a READID
if third try, do a RECAL
if more tries then Error out
REPEAT
NEXT Sector
Use DOS call to write track to a file and
repeat it all for the next track.
I can break down things like SEEK, READID and RECAL if you think they are
needed. The actual code is a little messy since it has been a growing
project.
I don't seem to have any issues with the clock rate since it has problems
during the MFM time and not the FM time. If it had clock problems
I'd suspect it would show while switching between FM and MFM.
I used to reset the step rate after each DOS call but I'm using
the INT 1E and INT 13 AH=0 method and the step rates for the
360K and the 1.44M seem to be OK now. It is just that the 360K
seems to get lost after the 1.44M steps tracks. The ReadID on
the 360K doesn't seem to help.
Dwight
9:23 p.m.
New subject: Floppy stepping problem
From: "Chuck Guzis" <cclist at
sydex.com>
Reply-To: "General Discussion: On-Topic and Off-Topic
Posts"<cctalk at classiccmp.org>
To: cctalk at classiccmp.org
Subject: Re: Floppy stepping problem
Date: Sat, 17 Jun 2006 09:51:51 -0700
On 6/17/2006 at 9:25 AM dwight elvey wrote:
Hi Chuck
The machine was working fine with a 1.2M drive. It is a Dell box with
a 486SX but that controller couldn't handle FM so I'm using a combination
IDE and floppy controller that has a GoldStar chip on it. It seems that
most of the GoldStar chips handle FM OK. ( and yes, I changed the jumper
on the mother board to use the external controller ).
The 360K floppy I have, only has the drive select
jumpers. I've tried
changing the DBT and using Int 13 but it is still not working. I guess
I'll
just have to live with it. It is working, it is
just that when the 1.44M
goes>to another track, I have to recal the 360K drive...
Let's see if we can solve this.
I'm going to go out on a limb here and ask you to carefully check your
cable that you're using. If you can, put another 1.44MB drive in place of
the 360K and see if it behaves similarly. If it does, check your cable; if
not, you might well have a wonky 360K drive.
What vintage PeeCee are you using? This isn't one of the more modern ones
with support for only a single drive built onto the mobo, is it?
As I stated, it is using a combination IDE/Floppy card. The card has been
checked out to work fine with both the 1.44M and 1.2M at the same time. I
did this early on.
Does your 360K drive have the terminator installed? If not, have you tried
it with the terminator? (you don't need to use the standard 150 ohm ones;
1K should be good enough).
The 1.44M has some termination on it. I don't think the 360K needs
additional
termination. I do have a resistor pack but it makes no difference if I
install it.
Dwight
Cheers,
Chuck
16 Jun
16 Jun
10:29 p.m.
New subject: Floppy stepping problem
Hi
I've been writng some code to transfer disk images to my Olivetti
M20. It uses 340K but with the first track being FM while the
rest is MFM. I've found a good controller to handle the FM but
I'm still having a stepper problems.
When I transfer, using the hard drive as the source, things work
fine. When I try to transfer from the 1.44M drive, I have to do a
lot of Recal's on the 360K drive I'm using. I use DOS to fetch the
image from the 1.44M. When I do this, the stepper on the 360k
drive can't keep up and it corrupts the position. This requires a
A silly question. Are you telling the floppy controller chip which drive
you're using when you wrote your own code. I don't mean selecting the
drive with the I/O port that controls the drive select and the motor-on
lines, I mean when you send a command to the FDC, you also include the
drive number there.
The reason is that the FDC (should?) keep a separate track position for
each drive, and will use the approprtiate one when you issue a seek, etc.
If you're telling the FDC that your 360K drive is drive 0 when it isn't,
accesses to the 1.44M drive (the real drive 0, I assume) will change
where the controller thinks the head is on the 360K drive.
-tony
17 Jun
17 Jun
2:32 a.m.
New subject: Floppy stepping problem
From: ard at p850ug1.demon.co.uk (Tony Duell)
---snip---
A silly question. Are you telling the floppy controller chip which drive
you're using when you wrote your own code. I don't mean selecting the
drive with the I/O port that controls the drive select and the motor-on
lines, I mean when you send a command to the FDC, you also include the
drive number there.
The reason is that the FDC (should?) keep a separate track position for
each drive, and will use the approprtiate one when you issue a seek, etc.
If you're telling the FDC that your 360K drive is drive 0 when it isn't,
accesses to the 1.44M drive (the real drive 0, I assume) will change
where the controller thinks the head is on the 360K drive.
-tony
Hi Tony
Yes, I do both. I'll need to experiment some more. Like I said,
I'm doing fine as long as I only use floppy to hard drive or hard drive
to floppy. It is when I do floppy to floppy that things don't
work as expected. One other thing, other than changing
the DBT as mentioned in the other post, I don't currently
use the DOS table that keeps track of which drive was
last on, although I do modify the drive timeout value( as
is needed ).
Dwight
16 Jun
16 Jun
3:46 p.m.
In message <5.1.0.14.2.20060616093651.058e73b8 at mail.30below.com>
Roger Merchberger <zmerch-cctalk at 30below.com> wrote:
2) you keep in mind it's a one-shot-wonder. You
can't print a half-page,
then save the other half-page for later - once it's been heated by the
toner, it's done for. It either gets expensive, or you have to save up your
projects for one go.
Oh yes you can!
1) Print the PCB layout onto a sheet of blank paper
2) Cut a piece of transfer material to the size of the printed layout, plus
about half an inch on each side
3) Use a laser printer label to stick the transfer material onto the paper
4) Load the paper into the printer's manual feeder and reprint the layout
onto it.
That's what I've done with Press-n-Peel and the Staples photo paper (which
used to work until they changed supplier), and it's never done any damage to
my printer. Just make sure you use laser printer labels, not ordinary type-on
/ write-on labels. Unless, that is, you enjoy the idea of removing very
sticky glue from your printer's imaging drum and transfer rollers...
--
Phil. | Kitsune: Acorn RiscPC SA202 64M+6G VF+UniPod
philpem at dsl.pipex.com | Cheetah: Athlon64 3200+ A8VDeluxeV2 1G+180G
http://www.philpem.me.uk/ | Tiger: Toshiba SatPro4600 Celeron700 256M+40G
19 Jun
19 Jun
3:20 a.m.
New subject: Wanted: IBM 029 or 129
Still looking for an IBM 029 or 129 keypunch, preferably in working
order. Reply privately if you have one available, or have a lead. This
is for my private collection.
Mike Loewen mloewen at cpumagic.scol.pa.us
Old Technology http://ripsaw.cac.psu.edu/~mloewen/Oldtech/
16 Jun
16 Jun
2:46 p.m.
On Friday 16 June 2006 01:27 am, Scott Quinn wrote:
A while ago (late '80s, early '90s) I heard a
suggestion for using copier
toner as PCB etch resist (draw on paper, copy onto overhead transparencies,
iron onto the PCB). Now that PCB layout software is available easily, as
are laser printers, has anyone here tried it? I'm wondering how well it
would resolve for finer-pitch DIP/SIP packages, or if the etchant would eat
through the traces.
This _is_ being done, and the technique is called "toner transfer" if I'm
remembering right. There were a couple of yahoo groups that were devoted to
this very subject.
The two tricky aspects of doing this were getting the right paper, so that
toner adhesion would be good and transfer to the copper would be also, and
you of course want to remove the paper at some point and leave the toner
behind, and also applying sufficient heat and in a consistent way to make
the transfer happen and adhesion good.
A few people were using the fuser portion of an otherwise defunct laser
printer to do the actual transfer part, and getting good results, as well
as a few other things.
A search on "toner transfer" in yahoo groups should turn some things up...
--
Member of the toughest, meanest, deadliest, most unrelenting -- and
ablest -- form of life in this section of space, a critter that can
be killed but can't be tamed. --Robert A. Heinlein, "The Puppet Masters"
-
Information is more dangerous than cannon to a society ruled by lies. --James
M Dakin
5:12 p.m.
On Friday 16 June 2006 10:46 am, Roy J. Tellason wrote:
On Friday 16 June 2006 01:27 am, Scott Quinn wrote:
I asked, and got pointed to Homebrew_PCBs at yahoogroups.com which I'd forgotten
about...
Hopefully there will be some folks in there who are actually doing it, and
can provide better info than my faulty recollections. :-)
--
Member of the toughest, meanest, deadliest, most unrelenting -- and
ablest -- form of life in this section of space, a critter that can
be killed but can't be tamed. --Robert A. Heinlein, "The Puppet Masters"
-
Information is more dangerous than cannon to a society ruled by lies. --James
M Dakin
A while ago (late '80s, early '90s) I
heard a suggestion for using copier
toner as PCB etch resist (draw on paper, copy onto overhead
transparencies, iron onto the PCB). Now that PCB layout software is
available easily, as are laser printers, has anyone here tried it? I'm
wondering how well it would resolve for finer-pitch DIP/SIP packages, or
if the etchant would eat through the traces.
This _is_ being done, and the technique is called "toner transfer" if I'm
remembering right. There were a couple of yahoo groups that were devoted
to this very subject. 
3:12 p.m.
A while ago (late '80s, early '90s) I heard a
suggestion for using
copier toner as PCB etch resist (draw on paper, copy onto overhead
transparencies, iron onto the PCB). Now that PCB layout software is
available easily, as are laser printers, has anyone here tried it? I'm
wondering how well it would resolve for finer-pitch DIP/SIP packages,
or if the etchant would eat through the traces.
A friend and I are trying to build some surface mount boards using
this concept right now. We're working from notes here:
http://www.fullnet.com/u/tomg/gooteepc.htm
It's tricky at best. We seem to be having trouble with getting the
toner to stick where single lines are a ways from other stuff. I'm
looking into alternate papers, different printer, etc.
We haven't tried etching yet, so I can't speak to whether we'll have
problems with the etchant eating into the fine lines.
De
3:30 p.m.
On 6/16/2006 at 11:12 AM Dennis Boone wrote:
It's tricky at best. We seem to be having trouble
with getting the
toner to stick where single lines are a ways from other stuff. I'm
looking into alternate papers, different printer, etc.
We haven't tried etching yet, so I can't speak to whether we'll have
problems with the etchant eating into the fine lines.
I for one would be very interested to hear if and how you were able to get
good fine-resolution PCB traces with this system. When I tried it, it was
still being trotted out as an idea and it was very much inferior to the
photoresist process.
BTW, photo sensitized clad board is still available, but it's not cheap.
These folks bought the assets of Kepro:
http://www.dalpro.net/
Given some of the prices for boards and chemicals, it might be quite a bit
cheaper to send the artwork out to be prototyped.
Cheers,
Chuck
6776
days inactive
6779
days old
30 comments
13 participants
participants (13)
-
ard＠p850ug1.demon.co.uk -
cclist＠sydex.com -
cisin＠xenosoft.com -
compoobah＠valleyimplants.com -
dkelvey＠hotmail.com -
drb＠msu.edu -
hilpert＠cs.ubc.ca -
kth＠srv.net -
mloewen＠cpumagic.scol.pa.us -
nico＠farumdata.dk -
philpem＠dsl.pipex.com -
rtellason＠verizon.net -
zmerch-cctalk＠30below.com