Transfer Arc HD to PC
tomnewcomb
to find it still working. I've also noticed there are Arc Emulators
available for PC's.
The question is: how can I transfer my 80Mb Arc hard disc to my PC for
use in an emulator? My Arc has no networking capabilities, and the
thought of transfering it 800K at a time via floppy is too horrible to
contemplate.
Is there any program in existance to help me do this, via serial or
parallel for example? (And a corresponding PC program to collect it,
obviously.)
This must be something that someone's done before. Had a search but
couldn't find anything, sorry if this is a faq!
John Kortink
<tom.n...@comlab.ox.ac.uk> wrote:
It should be, it comes up every month at least.
One way is Zerilink :
http://web.inter.nl.net/users/J.Kortink/home/software/zerilink/index.htm
John Kortink
--
Email : kor...@inter.nl.net
Homepage : http://www.inter.nl.net/users/J.Kortink
GoMMC, the ultimate BBC/Master storage system :
http://web.inter.nl.net/users/J.Kortink/home/hardware/gommc
Quilljar
to archive all files into zips otherwise there will be hell to sort out. It
can be done.
Quilljar
see http://client.webshots.com/album/194691959rhDQFi
Do not reply personally, all such emails go into my spam filter
David Holden
On 1-Jun-2005, "Quilljar" <wykehill-...@yahoo.co.uk> wrote:
> I did it once by Iomega zip which you might be able to borrow. Don't
> forget to archive all files into zips otherwise there will be hell
> to sort out. It can be done.
If you mean a parallel port zip drive then not on an A3000 it can't.
--
David Holden - APDL - <http://www.apdl.co.uk>
Andrew Wickham
John Kortink wrote:
> On 1 Jun 2005 11:12:45 -0700, "tomnewcomb"
> <tom.n...@comlab.ox.ac.uk> wrote:
>
> >Just rescued my A3000 after a 10 year stint in the attic, and surprised
> >to find it still working. I've also noticed there are Arc Emulators
> >available for PC's.
>
> One way is Zerilink :
>
> http://web.inter.nl.net/users/J.Kortink/home/software/zerilink/index.htm
>
Does an A3000 have a suitable parallel port? I'd understood Zerilink
was for newer hardware (A5000 and later) only.
Rgds,
Andrew
John Kortink
wrote:
I'm sorry, you're right. I thought it had the combo
I/O chip.
Must get round to making ZeriLink compatible with
(some of) those machines (will be bit-I/O though,
very slooooooooow).
Tim Hill
tomnewcomb <tom.n...@comlab.ox.ac.uk> wrote:
> how can I transfer my 80Mb Arc hard disc to my PC for
> use in an emulator?
Searching the web turned up:
http://www.apdl.co.uk/isv/snet.htm
which seems just the ticket unless you have a modern PC with no serial
port.
--
To leave BT's billing and reduce your phone bill by up to a half,
to obtain your own spam-proof address, or to contact me, visit
www.invalid.org.uk or email postmaster at invalid dot org dot uk
(To avoid spam, email to 1...@invalid.org.uk is deleted unread).
... "God, the best maker of marriages, combine your hearts in one !" Henry V, Act v, Sc.2
tomnewcomb
SerialNET looks quite appropriate (I remember getting the serial
upgrade for my A3000), and I've just got hold of a serial cable.
Now I'm tempted to have a go myself. It's been a while, but I remember
calls to SYS FileCore could serialise the HD image, then calls to
FX/VDU could pipe it out via the serial - I can look up the details.
No idea how to collect it at the other end. Brief search reveils DOS
command Copy COM1 filename, perhaps in conjunction with the Mode
command, but looks doubtful these will work on my Win2k machine????
Quilljar
> On 1-Jun-2005, "Quilljar" <wykehill-...@yahoo.co.uk> wrote:
>
>> I did it once by Iomega zip which you might be able to borrow. Don't
>> forget to archive all files into zips otherwise there will be hell
>> to sort out. It can be done.
>
> If you mean a parallel port zip drive then not on an A3000 it can't.
Yes you are right Dave, it was my old Risc PC (Which IIRC you bought off me
:-)
Cheers
Andrew Wickham
Have you got/access to download Kermit? I've used it via serial from
Win2K to Win98 and vice versa, and most of the various terminal
emulators for RISC OS should be able to send to it.
Rgds,
Andrew
ne...@rtrussell.co.uk
> No idea how to collect it at the other end. Brief search reveils DOS
> command Copy COM1 filename, perhaps in conjunction with the Mode
> command, but looks doubtful these will work on my Win2k machine????
Write a trivial BBC BASIC program? The (free) evaluation version of
BBC BASIC for Windows is more than capable of opening a serial port
and copying bytes to a file. Although the program is limited to 8K,
you can still create a file of any size! There's an example program
supplied for transferring files from a BBC Micro, which could no
doubt be modified to do what you want.
BBC BASIC for Windows can be downloaded from:
http://www.rtrussell.co.uk/products/bbcwin/download.html
Richard.
http://www.rtrussell.co.uk/
To reply by email change 'news' to my forename.
druck
> Now I'm tempted to have a go myself. It's been a while, but I remember
> calls to SYS FileCore could serialise the HD image, then calls to
> FX/VDU could pipe it out via the serial - I can look up the details.
> No idea how to collect it at the other end. Brief search reveils DOS
> command Copy COM1 filename, perhaps in conjunction with the Mode
> command, but looks doubtful these will work on my Win2k machine????
This should still work. Remember to use the /b flag on the copy, otherwise it
copy binary data properly.
---druck
--
The ARM Club Free Software - http://www.armclub.org.uk/free/
The 32bit Conversions Page - http://www.quantumsoft.co.uk/druck/
Jason Tribbeck
> Just rescued my A3000 after a 10 year stint in the attic, and surprised
> to find it still working. I've also noticed there are Arc Emulators
> available for PC's.
>
> The question is: how can I transfer my 80Mb Arc hard disc to my PC for
> use in an emulator? My Arc has no networking capabilities, and the
> thought of transfering it 800K at a time via floppy is too horrible to
> contemplate.
There is actually another possibility - although I've not tried it.
There's an ADFS partition read capability for Linux - so you could put
the HD in a Linux box, and copy the data over.
If you need it on Windows, you may find something like Knoppix will
allow you to mount it (I don't know if Knoppix has ADFS support), and
your Windows drive, and simply copy it over.
--
Jason Tribbeck
newsm...@tribbeck.com - 20K download limit - anything larger won't
be received.
Chris Evans
<URL:mailto:tom.n...@comlab.ox.ac.uk> wrote:
> Thanks for all the replies.
>
> SerialNET looks quite appropriate (I remember getting the serial
> upgrade for my A3000), and I've just got hold of a serial cable.
We have the software at half price at the moment:
http://www.cjemicros.co.uk/micros/individual/prodpages/ISV-SERIA.shtml
> Now I'm tempted to have a go myself. It's been a while, but I remember
> calls to SYS FileCore could serialise the HD image, then calls to
> FX/VDU could pipe it out via the serial - I can look up the details.
> No idea how to collect it at the other end. Brief search reveils DOS
> command Copy COM1 filename, perhaps in conjunction with the Mode
> command, but looks doubtful these will work on my Win2k machine????
>
>
Chris Evans
--
CJE Micro's / 4D 'RISC OS Specialists'
Telephone: 01903 523222 Fax: 01903 523679
ch...@cjemicros.co.uk http://www.cjemicros.co.uk/
78 Brighton Road, Worthing, West Sussex, BN11 2EN
The most beautiful thing anyone can wear, is a smile!
David Holden
On 3-Jun-2005, Chris Evans <ch...@cjemicros.co.uk> wrote:
> In article <1117722088.3...@f14g2000cwb.googlegroups.com>,
> tomnewcomb
> <URL:mailto:tom.n...@comlab.ox.ac.uk> wrote:
> > Thanks for all the replies.
> >
> > SerialNET looks quite appropriate (I remember getting the serial
> > upgrade for my A3000), and I've just got hold of a serial cable.
>
> We have the software at half price at the moment:
> http://www.cjemicros.co.uk/micros/individual/prodpages/ISV-SERIA.shtml
Actaullt 2/3 price. But it's also on the Volume 3 RISC World CD which
costs just 9 GBP
tomnewcomb
today! If I remember correctly I lent my chips to K. Arthur in lower
sixth. If I ever see him again...
Anyway, the appropriate command on the PC seems to be
mode com1 baud=19200 data=8
copy com1 x
If I used the /b switch it says "Access denied" ??? But seems to
transfer control character fine without it -- except 26, which the PC
treats as EOF. I guess I'll have to escape them to something else then
do some global find+replace on the PC to swap them back.
So I now need to serialise the HD with calls to FileCore, and find out
exactly what format for disc images an emulator (Red Squirrel) will
take. (It's an internal IDE btw.)
tomnewcomb
(Well, 0.0045 percent, but that's enough!)
A technician at work suggested I use a null-modem serial cable so that
the computers would synchronize. I got hold of one, but now the "COPY
COM1 filename" command just hangs...
It seems that the dos COPY command doesn't implement handshaking. Some
(very old) usenet posting suggest using INTERSVR/INTERLNK, but these do
not seem to be present in my Win2K.
Things I might try: BBC BASIC program suggestion; search for some
Windows serial file transfer programs... Kermit? It just seems odd I
can't do this from DOS.
Any suggestions gratefully received, although I realise this is getting
OT.
Adam
> That plan didn't work too well - the (18 hour) transfer was too lossy.
> (Well, 0.0045 percent, but that's enough!)
You could try what was recommended to me - e.g. use Linux and just plug
your drive into your PC:
Worked a treat for me :-)
Adam
--
Adam Richardson
Carpe Diem
tomnewcomb
spikey legs that slots into the acorn motherboard. It doesn't look like
it could directly talk to anything else...
News
I /think/ (long time since I saw mine) it's a standard 2.5" drive fixed
directly to the interface which then plugs into the motherboard.
Stuart
--
Stuart Winsor
From is valid but subject to change without notice if it gets spammed.
For Barn dances and folk evenings in the Coventry and Warwickshire area
See: http://www.barndance.org.uk
druck
> In article <1119091018....@o13g2000cwo.googlegroups.com>,
> tomnewcomb <tom.n...@comlab.ox.ac.uk> wrote:
> > The HD (Watford Electronics IDE) is an internal thing with lots of
> > spikey legs that slots into the acorn motherboard. It doesn't look like
> > it could directly talk to anything else...
>
> I /think/ (long time since I saw mine) it's a standard 2.5" drive fixed
> directly to the interface which then plugs into the motherboard.
2.5"? Its more likely to be a 5.25" drive if its from the Watford era.
Bryn Evans
> On 18 Jun 2005 News <SW_N...@dsl.pipex.com> wrote:
>
>> In article <1119091018....@o13g2000cwo.googlegroups.com>,
>> tomnewcomb <tom.n...@comlab.ox.ac.uk> wrote:
>> > The HD (Watford Electronics IDE) is an internal thing with lots of
>> > spikey legs that slots into the acorn motherboard. It doesn't look like
>> > it could directly talk to anything else...
>>
>> I /think/ (long time since I saw mine) it's a standard 2.5" drive fixed
>> directly to the interface which then plugs into the motherboard.
>
> 2.5"? Its more likely to be a 5.25" drive if its from the Watford era.
Keep up at the back - they WERE 2.5inch drives and if you have
asuitable data cable you can couple them to any other system. Usually
it is easier to dismount the drive from the interface board first. The
problem is that the data cable required is a special with a branch off
to connect to the power unit. This also applies to HCCS/ATM and BeeBug
produced drives (but Beebug used different formatting)
--
|) [
|)ryn [vans mail to - br...@bryork.com
tomnewcomb
don't personally have root access to one, but could surely find one.
Anyway, so I had my null-modem serial cable. On the ARC:
10REM>RD
20L%=&51D0000
30S%=16*1024
40D%=4:REM DRIVE NUMBER
50
60ONERROROSCLI"FX3 0":REPORT:END
70DIMB%S%
75*FX3 7
80FORA%=0TOL%-1 STEP S%
90 SYS"IDEFS_DiscOp",,9,(D%<<29)+A%,B%,S%
110 FORN%=0TOS%-1
130 VDUB%?N%
140 NEXT
160NEXT
170*FX3 0
On the PC (BBC BASIC for Windows):
10 PORT% = OPENUP "COM1: baud=19200 parity=N data=8 stop=1"
20 IF PORT%=0 THEN PRINT "NO COM1":END
30 FILE% = OPENOUT "DATA"
40 FOR N = 1 TO &51D0000
50 BPUT#FILE%, BGET#PORT%
60 NEXT N
70 CLOSE#FILE%
80 CLOSE#PORT%
After another 18hours, the Arc program finished and the PC program was
still waiting. The lossyness was 0.0053 percent, slightly higher than
with the normal serial cable.
Am I just expecting too much from serial? Is it expected to be this
unreliable?
I might just run it a few times and use diff3 or something to try and
piece it all together.
ne...@rtrussell.co.uk
> After another 18hours, the Arc program finished and the PC program was
> still waiting. The lossyness was 0.0053 percent, slightly higher than
> with the normal serial cable.
>
> Am I just expecting too much from serial? Is it expected to be this
> unreliable?
I'd be very surprised if it was the serial link itself contributing
to any losses. Without any handshaking/flow-control you are relying
on the PC accepting data at the incoming data rate without the input
buffer overflowing; this depends on the size of the buffer (probably
outside your control) the baud rate and the time taken to write to
disk. The last of these will depend on factors such as how
defragmented it is and whether any other processes are accessing the
disk at the same time.
One thing you can do is create a RAM buffer big enough to hold your
file then write it to disk in one go after the transfer is complete.
This will eliminate the disk write time from the equation. If you
were running the full version of BBC BASIC for Windows you could do
this by raising HIMEM, but I appreciate that you will want to do it
with the free version! So an alternative is to create the buffer
using the Windows API:
10 PORT% = OPENUP "COM1: baud=19200 parity=N data=8 stop=1"
20 IF PORT%=0 THEN PRINT "NO COM1":END
30 SYS "GlobalAlloc", 0, &51D0000 TO B%
40 FOR N% = 0 TO &51D0000-1
50 B%?N% = BGET#PORT%
60 NEXT N%
80 CLOSE#PORT%
90 OSCLI "SAVE DATA "+STR$~B%+" +51D0000"
100 SYS "GlobalFree", B%
Richard.
http://www.rtrussell.co.uk/
druck
> The suggestions about using a linux box are becoming more appealable. I
> don't personally have root access to one, but could surely find one.
>
> Anyway, so I had my null-modem serial cable. On the ARC:
The single byte copying on the PC end looks horrendously inefficent, but as
its on a PC its probably ok - grunt over brains.
> After another 18hours, the Arc program finished
Ouch!
> tand the PC program was still waiting. The lossyness was 0.0053 percent,
> slightly higher than with the normal serial cable.
>
> Am I just expecting too much from serial? Is it expected to be this
> unreliable?
Did you have hardware flow control enabled and software flow control turned
off at both ends?
> I might just run it a few times and use diff3 or something to try and
> piece it all together.
It would be better to read each sector and append a checksum word to the end
of it. The reading program can then detect which sector was incomplete. If
you make it a but more sophisticated the reader can sent acknowledgements if
its ok, or request it to be resent. Its worth putting in some more time with
the program if its going to take 18 hours before you know its failed.
ne...@rtrussell.co.uk
> The single byte copying on the PC end looks horrendously inefficent, but as
> its on a PC its probably ok - grunt over brains.
BBC BASIC for Windows buffers the BPUT# call into 256-byte blocks
before writing to Windows so the inefficiency isn't as bad as you
might think. Having said that, at 19200 baud it shouldn't make
much difference anyway.
I agree with your other points. Having to wait 18 hours before
finding out something is wrong isn't very satisfactory! A bit
of BBC BASIC flow-control code would help a great deal.
Richard.
http://www.rtrussell.co.uk/
tomnewcomb
druck wrote:
> On 23 Jun 2005 "tomnewcomb" <tom.n...@comlab.ox.ac.uk> wrote:
> > After another 18hours, the Arc program finished
>
> Ouch!
This isn't so bad. I'm pretty busy so can only play with this for ten
minutes every few days.
> Did you have hardware flow control enabled and software flow control turned
> off at both ends?
I don't know. I tried updating the BASIC program on the PC with:
10 PORT% = OPENUP "COM1: baud=19200 parity=N data=8 stop=1 odsr=on
octs=on dtr=on rts=on idsr=on"
but it didn't make any difference. I'm using a null-modem cable, so (as
I've been told) the computers should be sychronizing and there
shouldn't be any need for me to add flow control of my own.
druck
> druck wrote:
>> Did you have hardware flow control enabled and software flow control
>> turned off at both ends?
>
> I don't know. I tried updating the BASIC program on the PC with:
>
> 10 PORT% = OPENUP "COM1: baud=19200 parity=N data=8 stop=1 odsr=on
> octs=on dtr=on rts=on idsr=on"
>
> but it didn't make any difference. I'm using a null-modem cable, so (as
> I've been told) the computers should be sychronizing and there
> shouldn't be any need for me to add flow control of my own.
You certainly do need flow control with a null modem cable. I've found
CTS/RTS flow control is the most reliable, and this needs to be done at both
ends. On the RISC OS side use OS_SerialOp 0 to set the appropriate
handshaking bits.
ne...@rtrussell.co.uk
> You certainly do need flow control with a null modem cable. I've found
> CTS/RTS flow control is the most reliable, and this needs to be done at both
> ends. On the RISC OS side use OS_SerialOp 0 to set the appropriate
> handshaking bits.
At the PC end use SYS "EscapeCommFunction" as documented in the
BBC BASIC for Windows manual under 'Serial and Parallel I/O....
Modem control input/output'.