Whatever happened to SCOPY?

[Jeffrey Worley]

From the time I got the construction set I've been using Scopy to make disk images and to duplicate disks.  It was just an awesome utility.  SDX has no Scopy, doesn't know Scopy, won't even load Scopy from the SDCS.  What do we use now for sector copying and imaging (native to the atari, not .atr).  I liked it not least of which because it accepted command line input, like a good Sparta utility ought to.  IIRC it had a menu mode if invoked without arguments.

 

Best,

 

Jeff

 

[Kyle22]

31 minutes ago, Technoid Mutant said:

From the time I got the construction set I've been using Scopy to make disk images and to duplicate disks.  It was just an awesome utility.  SDX has no Scopy, doesn't know Scopy, won't even load Scopy from the SDCS.  What do we use now for sector copying and imaging (native to the atari, not .atr).  I liked it not least of which because it accepted command line input, like a good Sparta utility ought to.  IIRC it had a menu mode if invoked without arguments.

 

Best,

 

Jeff

 

Try this one.

 

scopy.zip

[Jeffrey Worley]

7 minutes ago, Kyle22 said:

Try this one.

 

scopy.zip 2.55 kB · 1 download

Hey it works!  Why?  What's different?

 

Best,

Jeff

[+Nezgar]

Was going to say... I used scopy extensively with SDX BITD and today... handy to keep a collection of disk images within a SIDE2 partition to write out to real floppies in a pinch.

 

It's only limitations are its kinda klunky assumptions of the fastest order to read and write sectors in "standard" Atari interleave, or UltraSpeed interleave when using a US Doubler 1050.

 

Ie.. Disks formatted by ICD's own US Doubler intended for "standard" 1x SIO lay down a slightly optimized interleave, which SCOPY will read using a sector order that is then slower than just reading sectors sequentially.

 

When writing disks using scopy using non-ultraspeed format to a Happy 1050, its alternate sector write order triggers the happy to flush (write out) the track buffer after only half of the sectors are sent, as sector 18 of each track is sent early, and a noticible 'pause' between two bursts of sectors being sent for each track. Writing to the 18th sector of any track on a Happy 1050 triggers a write buffer flush.

 

It also seems to do weird things sometimes with Dual/Enhanced density disks...

[Jeffrey Worley]

44 minutes ago, Nezgar said:

Was going to say... I used scopy extensively with SDX BITD and today... handy to keep a collection of disk images within a SIDE2 partition to write out to real floppies in a pinch.

 

It's only limitations are its kinda klunky assumptions of the fastest order to read and write sectors in "standard" Atari interleave, or UltraSpeed interleave when using a US Doubler 1050.

 

Ie.. Disks formatted by ICD's own US Doubler intended for "standard" 1x SIO lay down a slightly optimized interleave, which SCOPY will read using a sector order that is then slower than just reading sectors sequentially.

 

When writing disks using scopy using non-ultraspeed format to a Happy 1050, its alternate sector write order triggers the happy to flush (write out) the track buffer after only half of the sectors are sent, as sector 18 of each track is sent early, and a noticible 'pause' between two bursts of sectors being sent for each track. Writing to the 18th sector of any track on a Happy 1050 triggers a write buffer flush.

 

It also seems to do weird things sometimes with Dual/Enhanced density disks...

IIRC there are command line switches to order high-speed sector skew or not.  I forget.  I will play with it some.  Thanks a lot brother.

 

Jeff

[+Nezgar]

2 hours ago, Technoid Mutant said:

IIRC there are command line switches to order high-speed sector skew or not.  I forget.  I will play with it some.  Thanks a lot brother.

Yep, "/H" . With that switch, when writing, if using a US Doubler 1050, it formats using ultraspeed interleave, and writes sectors (mostly) sequentially. IIRC, I observed it writing 2-18, then 1 last for each track. On a US doubler this would reduce the delay between track steps. On a Happy, it would cause a write buffer flush before the last sector was sent. I also recall it might also account for the end of track gap and use a slightly altered order to read 1 sector number earlier when crossing the gap...

 

Theres a previous topic where I also wrote a bit about this too...  

 

Edit: In a recent post from @jhugard of the NCT Turbo 810, corrected me about my use of "skew", where "interleave" should be the correct term for the order of sectors on a track. "Skew" would refer to alignment of sectors on one track compared to the next. In SpartaDOS and US Doubler, incorrect use of "skew" is prevalent.  But I fully agree with him after thinking about it.

[+Larry]

I'm curious about the history of SCOPY and why it isn't in the toolkit?  Does anyone know? Was SCOPY "official" or a user-written utility that became very popular?  I don't think it was in the original Construction Set, was it?

 

Maybe there is a better replacement now? Kyle22 has posted a copy that evidently has been fixed, so perhaps made it to the Toolkit on a previous version?  Is the source available?

 

-Larry

[+bf2k+]

It was in the v3 Construction Set.  I have original disks here.

[Mclaneinc]

Never heard of the thing, you learn more every day...

[flashjazzcat]

6 hours ago, Larry said:

Maybe there is a better replacement now?

I've never used SCOPY, but the sector copier in the SDX toolkit is called HDSC and it works well. It's worth reading the toolkit documentation.

[+Nezgar]

I found SCOPY.COM on the SpartaDOS 3.2d disk dated 20-Nov-1985, size 3582 bytes, identifies itself as "SCOPY Ver 1.2". Is this the one that doesn't work with SDX?

 

I found SCOPY.COM dated 16-Sep-1986 on the Side 1 of the R-Time 8 disk. My "SpartaDOS Construction Set - 3.2d & 2.3e" disk also has the same file date & size. SpartaDOS Toolkit 3.2d does not have it:

 

Lastly, the one included in version 3.2f, when FTe took over, I suspect its literally just a few byte changes to change the banner text "(C) 1985 ICD Inc." to "(C) 1994 by FTe". The time/date stamp is till 16-Sep-1986, 3594 Bytes just like the one from 3.2d...

[+Larry]

3 hours ago, bf2k+ said:

It was in the v3 Construction Set.  I have original disks here.

I didn't dig out my SDCS disks, but did look through the manual and didn't see it listed. But good to know it was "official."

[Jeffrey Worley]

4 hours ago, flashjazzcat said:

I've never used SCOPY, but the sector copier in the SDX toolkit is called HDSC and it works well. It's worth reading the toolkit documentation.

Gentle reminder taken gracefully.  I didn't really explore the docs.  I usually do if they are tree-killing, but the digital ones get a gloss usually.  That said, I've done some exploring in the man pages on the X command and I didn't know there were new arguments.  I tried all of them and none help get moe working.  The load but don't run option works, but moe doesn't execute, just bumps memlo.

 

Best,

 

Jeff

[flashjazzcat]

I downloaded the BBS archive presented in the other thread but still do not know what I'm supposed to do with it. A disk image I can simply mount and launch the application from would be really useful.

 

[Faicuai]

16 hours ago, Nezgar said:

(...)

 

Edit: In a recent post from @jhugard of the NCT Turbo 810, corrected me about my use of "skew", where "interleave" should be the correct term for the order of sectors on a track. "Skew" would refer to alignment of sectors on one track compared to the next. In SpartaDOS and US Doubler, incorrect use of "skew" is prevalent.  But I fully agree with him after thinking about it.

 

Seems in complete agreement with the teachings and lessons I got from IndusGT Doubler (+CP/M toolkit) author, when exploring, testing and refining his wonderful creation.

 

What is generally known as "sector skew" is non-sense (in the context of a single track).

[_The Doctor__]

correct the sectors only skew if a custom interleave is used on each successive track...

when a disk is laid out so that the next sector is arriving just in time for the read to occur even across tracks...  that skew is even faster than the standard interleave method (incorrectly labeled skew) that has been employed thus far.

[1050]

4 hours ago, flashjazzcat said:

I downloaded the BBS archive presented in the other thread but still do not know what I'm supposed to do with it. A disk image I can simply mount and launch the application from would be really useful.

 

It's like Disk Communicator producing a .DCM with ARCing the disc information. Just Sparta's version of that.

 

scopy.zip

[Jeffrey Worley]

4 hours ago, 1050 said:

It's like Disk Communicator producing a .DCM with ARCing the disc information. Just Sparta's version of that.

 

scopy.zip 13.15 kB · 3 downloads

Here's a copy of the bbs as it is now.  It is set up to boot and run from disk, as it isn't working with X at the moment.  So if you boot it without the xcart (cold /c), it'll run.  I think the Fast command is at the start of Waitcall, so BXL is what's needed, but only for that one line of the whole thing.  From the batch files you can see what support the bbs needs before running.  I use Rverter, but you can use whatever driver your hardware supports, or none, if you have a black box or Mio.  I ran it on the bb just fine years ago.

 

As you will see from the bbs.bat file, I found the utilities I got in the other thread work pretty well for time support for u1mb in sd32.  There's still something funky going on but it is a lot better.

 

Best,

 

Jeff

fjcbbscopy.zip

[flashjazzcat]

7 hours ago, 1050 said:

It's like Disk Communicator producing a .DCM with ARCing the disc information. Just Sparta's version of that.

 

scopy.zip 13.15 kB · 3 downloads

Sorry: I was unclear. I know what an ARC file is and unARCing and viewing the contents is no problem at all, but I could not find the MOE executable.

 

2 hours ago, Technoid Mutant said:

Here's a copy of the bbs as it is now.  It is set up to boot and run from disk, as it isn't working with X at the moment.  So if you boot it without the xcart (cold /c), it'll run.  I think the Fast command is at the start of Waitcall, so BXL is what's needed, but only for that one line of the whole thing.  From the batch files you can see what support the bbs needs before running.  I use Rverter, but you can use whatever driver your hardware supports, or none, if you have a black box or Mio.  I ran it on the bb just fine years ago.

 

As you will see from the bbs.bat file, I found the utilities I got in the other thread work pretty well for time support for u1mb in sd32.  There's still something funky going on but it is a lot better.

 

Best,

 

Jeff

fjcbbscopy.zip 525.8 kB · 2 downloads

Thank you. I will have a look at it later 

[flashjazzcat]

It appears that BASIC XE extensions install a RAM-based OS which crashes with the SIDE OSS BASIC XE ROM on exit to DOS owing to a failed attempt at OSS bank selection at $D834 (by writing to $D508). So the extensions would need patching to work with the SIDE BASIC XE ROM, and that's before we do anything else.

 

There are a few redundant (irrelevant to SDX) commands in the batch file (BASIC ON, etc), but even when I manually start BASIC XE and run BOOTBBS, the system crashes at location $0004 after first corrupting the stack.

 

I tried the same procedure with a real BASIC XE cart (well, a real emulated one) on a 1088XEL setup. Extensions load perfectly well with a standard XL/XE OS, but BOOTBBS again crashes at location $0004. Quite a mess.

Edited September 8, 2019 by flashjazzcat

[Jeffrey Worley]

2 hours ago, flashjazzcat said:

It appears that BASIC XE extensions install a RAM-based OS which crashes with the SIDE OSS BASIC XE ROM on exit to DOS owing to a failed attempt at OSS bank selection at $D834 (by writing to $D508). So the extensions would need patching to work with the SIDE BASIC XE ROM, and that's before we do anything else.

 

There are a few redundant (irrelevant to SDX) commands in the batch file (BASIC ON, etc), but even when I manually start BASIC XE and run BOOTBBS, the system crashes at location $0004 after first corrupting the stack.

 

I tried the same procedure with a real BASIC XE cart (well, a real emulated one) on a 1088XEL setup. Extensions load perfectly well with a standard XL/XE OS, but BOOTBBS again crashes at location $0004. Quite a mess.

I've not used bxe. Basic XL or plain rev C.

[flashjazzcat]

24 minutes ago, Technoid Mutant said:

I've not used bxe. Basic XL or plain rev C.

I see. I think I had this confused with something else.

 

Nevertheless, it still crashes at location $0004, even with Rev. C BASIC.

[Jeffrey Worley]

4 minutes ago, flashjazzcat said:

I see. I think I had this confused with something else.

 

Nevertheless, it still crashes at location $0004, even with Rev. C BASIC.

Oh, I forgot.  Set up a drive 7 in spartados format for the error.dat file.  It will hang if you don't.  Ooops.

[flashjazzcat]

3 minutes ago, Technoid Mutant said:

Set up a drive 7 in spartados format for the error.dat file

Aha... an improvement. Now it crashes at $0699.

 

[Jeffrey Worley]

2 minutes ago, flashjazzcat said:

Aha... an improvement. Now it crashes at $0699.

 

My bbs.bat file assumes the z: handler for the U1MB is enabled in the bios.  Else you have to load a zhandler from disk ala the BBSORIG.bat file.