jgreco@csd4.milw.wisc.edu (Joe Greco) (03/02/89)
In-Reply-To: <89Feb10.182236est.2718@godzilla.eecg.toronto.edu>; from "Marcel LeBlanc" at Feb 10, 89 4:04 pm Word-of-the-day: tommy ] Since nobody else seems to be responding to our postings on speeding up file ] transfers, I decided to respond by mail. BTW, I used a section of your ] posting to introduce the topic of file operation speedup in another posting. I think I missed it.... ah well ] Anyway, here are a few of my comments (since you did ask about SS V4) :-). ] [...] ] >That sounds fine, 'cept there's no reason that you'd need to buffer ] >with IEEE, and sending a block to the REU would cause a bad Z-Modem ] >block. RAMDOS (or any REU access) will momentarily suspend the CPU's ] >operations to perform the transfer. ] ] True, and the same applies to using fast serial routines. You will loose ] characters while you are saving to disk. This is why I wanted to use a very ] large buffer, so that you wouldn't be dropping packets very often. ] Otherwise, the only solution left is to use IEEE drives. This is a perfectly ] acceptable solution in your case, but not for most others, including me. Well, as Geoff suggested, perhaps the SLOW serial routines can be worked a little (or the RS232 drivers) in such a way that they don't interfere. I don't like the idea of dropping packets at all.... ] >Well, how does it help me? Does SSVx have anything desirable that ] >either a BusCard II, ISEPIC, and/or SysRes doesn't? I'm open minded.. ] ] That depends on what you're looking for in a cartridge. Buscard II and ] SysRes give you an IEEE port and great BASIC extensions. There may be The BusCard II also gives BASIC 4.0, a reasonably indecent minimonitor (remember that speed test in ML I posted? :-) and other miscellaneous things. ] thousands of people out there with IEEE drives, but there are millions who ] use serial drives like 1541/71/81. By comparison, Isepic is a dinosaur. Agreed, at least in terms of "breaking utilities".... But what more does SS V4 really provide? ISEPIC hasn't run into any problems on the programs I've used it on. > It works for it's limited range of uses, but even for these it's very slow > and cumbersome. SS V4 doesn't give you an IEEE interface (I know, that > alone means you aren't interested :-( ), or the same variety of basic > extensions that you get from Sysres (BTW, SS V4 doesn't have BASIC > extensions on ROM, if you want these something like Sysres works fine). Just because SS V4 doesn't give an IEEE interface doesn't mean that I'm not interested. But would SS V4 work WITH a BusCard II? If SS V4 offers anything of true interest to me, and works with my systems, I'm interested. > What SS V4 does give you, is the fastest serial loaders on the market. 12x > speed increase for 1541 & 1581 (INDEPENDENT OF INTERLEAVE), and about 8x for > 1571 (dependent on interleave). Epyx FastLoad and most other cartridges > give you about 5.5x increase for load, nothing for save. SS V4 also gives > you a very powerful ML monitor (it's great for debugging software; you can > "Freeze" a program to examine it, make modifications, then resume it as if > nothing had happened, without every going to disk). It also includes a That would be nice, as long as it is not "corrupted" by unusual settings on the machine. That's one of the gripes I have with the Card's monitor.... the BBS environment messes it up. :-) > range of other utilities, such as capturing screens to disk or printer > (including standard or multi-color bitmaps), capturing sprites for editing, > the fastest disk copier I have seen for 1541/71/81 (in any combination, > including partition support for 1581), programmable function keys I find the problem with programmable function keys is that they tend to get really messy, especially with programs that expect to be able to use them. This brings up a more general question: Overall, how "compatible" IS this beastie? > (pre-programmed and re-programmable), an auto-booting feature (when you > reset your machine, you are presented with a menu of 'configurations', if > you don't select one within about 30secs, it times out and tries to boot > from device 8. This would allow software such as BBS's to survive power > failures.), and a few more that I'm probably forgetting. That's a nice feature. Too bad it's already part of my Kernal. ;-) > Of course since SS V4 ties up your cartridge port, you can't use an IEEE > interface, so there's no need for SS to try to support IEEE disks. Good IEEE interfaces allow you to plug in something else. One system at home had a 1750, BusCard II, and B.I.-80 plugged in all at once. (grin) > See you on comp.sys.cbm! Let's move this back to c.s.c.... it's a little slow right now, anyways. > Marcel A. LeBlanc | University of Toronto -- Toronto, Canada > leblanc@eecg.toronto.edu | also: LMS Technologies Ltd, Fredericton, NB, Canada > ------------------------------------------------------------------------------- > UUCP: uunet!utai!eecg!leblanc BITNET: leblanc@eecg.utoronto (may work) > ARPA: leblanc%eecg.toronto.edu@relay.cs.net CDNNET: <...>.toronto.cdn > -- jgreco@csd4.milw.wisc.edu Joe Greco at FidoNet 1:154/200 USnail: 9905 W Montana Ave PunterNet Node 30 or 31 West Allis, WI 53227-3329 "These aren't anybody's opinions." Voice: 414/321-6184 Data: 414/321-9287 (Happy Hacker's BBS) "Never put off until tomorrow something that you can get out of doing today." -- jgreco@csd4.milw.wisc.edu Joe Greco at FidoNet 1:154/200 USnail: 9905 W Montana Ave PunterNet Node 30 or 31 West Allis, WI 53227-3329 "These aren't anybody's opinions." Voice: 414/321-6184 Data: 414/321-9287 (Happy Hacker's BBS)
leblanc@eecg.toronto.edu (Marcel LeBlanc) (03/07/89)
In article <1376@csd4.milw.wisc.edu> jgreco@csd4.milw.wisc.edu (Joe Greco) writes: >In-Reply-To: <89Feb10.182236est.2718@godzilla.eecg.toronto.edu>; from "Marcel LeBlanc" at Feb 10, 89 4:04 pm >] thousands of people out there with IEEE drives, but there are millions who >] use serial drives like 1541/71/81. By comparison, Isepic is a dinosaur. > >Agreed, at least in terms of "breaking utilities".... > >But what more does SS V4 really provide? ISEPIC hasn't run into any >problems on the programs I've used it on. I think it's safe to assume that I've tested both of these on far more programs than most users have. Some programs are not copyable using capture techniques. But ISEPIC chokes on many programs that it should be able to handle (SS V4 handles these with ease). >> It works for it's limited range of uses, but even for these it's very slow >> and cumbersome. SS V4 doesn't give you an IEEE interface (I know, that >> alone means you aren't interested :-( ), or the same variety of basic >> extensions that you get from Sysres (BTW, SS V4 doesn't have BASIC >> extensions on ROM, if you want these something like Sysres works fine). > >Just because SS V4 doesn't give an IEEE interface doesn't mean that >I'm not interested. But would SS V4 work WITH a BusCard II? If SS V4 >offers anything of true interest to me, and works with my systems, I'm >interested. I've never tried it with a BusCard II, so I can't say. >> What SS V4 does give you, is the fastest serial loaders on the market. 12x >> speed increase for 1541 & 1581 (INDEPENDENT OF INTERLEAVE), and about 8x for >> 1571 (dependent on interleave). Epyx FastLoad and most other cartridges >> give you about 5.5x increase for load, nothing for save. SS V4 also gives >> you a very powerful ML monitor (it's great for debugging software; you can >> "Freeze" a program to examine it, make modifications, then resume it as if >> nothing had happened, without every going to disk). It also includes a > >That would be nice, as long as it is not "corrupted" by unusual >settings on the machine. That's one of the gripes I have with the >Card's monitor.... the BBS environment messes it up. :-) The monitor on SS V4, as well as most other features (except wedge, F-keys), will work in any machine state. I have never found a machine configuration that interferes with the monitor. As a test, try: $2000 ldy #0 lda #some_byte_value loop sta $0000,y iny bne loop inc loop+2 ldx loop+2 cpx #$10 ;erase 0 to $1000 bcc loop endless jmp endless This will overwrite all of memory from 0 to $1000. You can interrupt this with SS V4, enter the monitor, then RESUME without any difficulty. Just for fun, add some code to turn on NMI and IRQ interrupts from the CIAs or the VIC chip (raster IRQ), put the interrupt service routines in the RAM at $E000-$FFFF or $D000-DFFF, turn on any display mode, or anything else you can think of, and none of this will make any difference to the operation of SS V4. You will still be able to interrupt, make modifications with the monitor, and resume execution. Except for a few bytes on the stack generated by the interrupt, nothing will be corrupted by SS V4. >> range of other utilities, such as capturing screens to disk or printer >> (including standard or multi-color bitmaps), capturing sprites for editing, >> the fastest disk copier I have seen for 1541/71/81 (in any combination, >> including partition support for 1581), programmable function keys > >I find the problem with programmable function keys is that they tend >to get really messy, especially with programs that expect to be able >to use them. This brings up a more general question: Overall, how >"compatible" IS this beastie? I haven't found any programs where the F-keys interfered, but I can't say that I've tried that many. If you do find a program where they interfere, you can disable the F-keys separately from the wedge and the fast loader/saver. If you haven't disabled the wedge, you can enable/disable any of these from the wedge, or you can use one of the menus in SS V4 to enable/disable features individually. All things considered, I think it's safe to say that SS V4 is AT LEAST as compatible as the classic Epyx FastLoad. Marcel A. LeBlanc | University of Toronto -- Toronto, Canada leblanc@eecg.toronto.edu | also: LMS Technologies Ltd, Fredericton, NB, Canada ------------------------------------------------------------------------------- UUCP: uunet!utai!eecg!leblanc BITNET: leblanc@eecg.utoronto (may work) ARPA: leblanc%eecg.toronto.edu@relay.cs.net CDNNET: <...>.toronto.cdn
jgreco@csd4.milw.wisc.edu (Joe Greco) (03/09/89)
In comp.sys.cbm article <89Mar7.154848est.2399@godzilla.eecg.toronto.edu>, leblanc@eecg.toronto.edu (Marcel LeBlanc) wrote: ]>That would be nice, as long as it is not "corrupted" by unusual ]>settings on the machine. That's one of the gripes I have with the ]>Card's monitor.... the BBS environment messes it up. :-) ] ]The monitor on SS V4, as well as most other features (except wedge, F-keys), ]will work in any machine state. I have never found a machine configuration ]that interferes with the monitor. As a test, try: ] ] $2000 ldy #0 ] lda #some_byte_value ] loop sta $0000,y ] iny ] bne loop ] inc loop+2 ] ldx loop+2 ] cpx #$10 ;erase 0 to $1000 ] bcc loop ] endless jmp endless ] ]This will overwrite all of memory from 0 to $1000. You can interrupt this ]with SS V4, enter the monitor, then RESUME without any difficulty. Just for ]fun, add some code to turn on NMI and IRQ interrupts from the CIAs or the ]VIC chip (raster IRQ), put the interrupt service routines in the RAM at ]$E000-$FFFF or $D000-DFFF, turn on any display mode, or anything else you ]can think of, and none of this will make any difference to the operation of ]SS V4. You will still be able to interrupt, make modifications with the ]monitor, and resume execution. Except for a few bytes on the stack ]generated by the interrupt, nothing will be corrupted by SS V4. You haven't told us anything about the monitor itself, though. Is it a decent monitor? Does it follow the "Commodore" style? Built in single line assembler? One of my favorite things to look for is to see if the load command has an option for relocating load.... I seem to recall one particularly horrid cartridge based monitor, and I suspect it was the one in "Fastload." ]>I find the problem with programmable function keys is that they tend ]>to get really messy, especially with programs that expect to be able ]>to use them. This brings up a more general question: Overall, how ]>"compatible" IS this beastie? ] ]I haven't found any programs where the F-keys interfered, but I can't say ]that I've tried that many. If you do find a program where they interfere, ]you can disable the F-keys separately from the wedge and the fast ]loader/saver. If you haven't disabled the wedge, you can enable/disable any ]of these from the wedge, or you can use one of the menus in SS V4 to ]enable/disable features individually. All things considered, I think it's ]safe to say that SS V4 is AT LEAST as compatible as the classic Epyx ]FastLoad. That's not saying a whole heck of a lot. ;-) Now.... any users of SS V4.... let's pose it like this. Has anyone had any bad experiences? Had to unplug the thing? Any positive comments? ANYTHING? :-) -- jgreco@csd4.milw.wisc.edu Joe Greco at FidoNet 1:154/200 USnail: 9905 W Montana Ave PunterNet Node 30 or 31 West Allis, WI 53227-3329 "These aren't anybody's opinions." Voice: 414/321-6184 Data: 414/321-9287 (Happy Hacker's BBS)
leblanc@eecg.toronto.edu (Marcel LeBlanc) (03/14/89)
In article <1481@csd4.milw.wisc.edu> jgreco@csd4.milw.wisc.edu (Joe Greco) writes: >In comp.sys.cbm article <89Mar7.154848est.2399@godzilla.eecg.toronto.edu>, leblanc@eecg.toronto.edu (Marcel LeBlanc) wrote: ... >]SS V4. You will still be able to interrupt, make modifications with the >]monitor, and resume execution. Except for a few bytes on the stack >]generated by the interrupt, nothing will be corrupted by SS V4. > >You haven't told us anything about the monitor itself, though. Is it >a decent monitor? Does it follow the "Commodore" style? Built in >single line assembler? One of my favorite things to look for is to >see if the load command has an option for relocating load.... > >I seem to recall one particularly horrid cartridge based monitor, and >I suspect it was the one in "Fastload." Yes, the monitor does follow the popular "Commodore" style. It has all of the standard monitor commands, plus a number of extensions. It has bi-directional scrolling, a drive monitor mode (this makes all commands work in the drive's memory instead of the computer memory), a dos wedge, and other extensions like sector read/write. The line assembler allows much more flexibility in entering operands than most other single line assemblers. For example, the default number base is 16, so you don't have to enter those stupid "$" signs. Also, you can omit leading zeros, and you can enter numbers in decimal or "character". stupid monitor smart monitor A 0340 LDA #$41 A 340 LDA #"A" A 0342 LDX $C350 A 342 LDX +50000 A 0345 LDY $033F A 345 LDY 33F Anyway, you get the idea. The same applies to all commands, not just the line assembler. (Of course, you can still use the style in the first column if you want.) Yes, the load command "L" does indeed allow an optional load address parameter. I agree that the FastLoad monitor was difficult to get used to. It did occasionally have it's uses though. In particular, I like the format of the hunt command (I don't remember exactly what it was called) which allowed you to define a range of values that would be accepted as a match. >]I haven't found any programs where the F-keys interfered, but I can't say >]that I've tried that many. If you do find a program where they interfere, >]you can disable the F-keys separately from the wedge and the fast >]loader/saver. If you haven't disabled the wedge, you can enable/disable any >]of these from the wedge, or you can use one of the menus in SS V4 to >]enable/disable features individually. All things considered, I think it's >]safe to say that SS V4 is AT LEAST as compatible as the classic Epyx >]FastLoad. > >That's not saying a whole heck of a lot. ;-) Agreed. :-) >Now.... any users of SS V4.... let's pose it like this. Has anyone >had any bad experiences? Had to unplug the thing? Any positive comments? The various versions of SS have been reviewed by a number of different magazines, like Compute's Gazette, RUN, Ahoy, etc, and by some users group newsletters. All the reviews that I have seen have praised SS, and always ranked it above it's competitors. I haven't seen any reviews of V4 (which was released in early Dec '88) from North American magazines (yet), but it was reviewed by a magazine based in the U.K. in Feb '89. In fact, they put a picture of SS V4 on the cover (I'm blushing :-) ). Needless to say, they liked it. Somebody in another posting asked about ads. You can find ads describing the features of SS V4 in a number of low to no content magazines such as the ones listed above. Since only Joe seems to be responding to these postings, I'll probably go back to using mail in the future. :-( I wonder how many people actually read comp.sys.cbm? Still wondering, Marcel A. LeBlanc | University of Toronto -- Toronto, Canada leblanc@eecg.toronto.edu | also: LMS Technologies Ltd, Fredericton, NB, Canada ------------------------------------------------------------------------------- UUCP: uunet!utai!eecg!leblanc BITNET: leblanc@eecg.utoronto (may work) ARPA: leblanc%eecg.toronto.edu@relay.cs.net CDNNET: <...>.toronto.cdn
jbond@escargot.UUCP (Jeremy Shepherd) (03/17/89)
In article <89Mar13.150034est.2398@godzilla.eecg.toronto.edu> leblanc@eecg.toronto.edu (Marcel LeBlanc) writes: (stuff deleted) > >Since only Joe seems to be responding to these postings, I'll probably go >back to using mail in the future. :-( I wonder how many people actually read >comp.sys.cbm? > I do! Every day! Please do reconsider going back to using only mail for this series of articles. Even though I've not yet commented, I find them interesting and informative. >Still wondering, > >Marcel A. LeBlanc | University of Toronto -- Toronto, Canada >leblanc@eecg.toronto.edu | also: LMS Technologies Ltd, Fredericton, NB, Canada >------------------------------------------------------------------------------- >UUCP: uunet!utai!eecg!leblanc BITNET: leblanc@eecg.utoronto (may work) >ARPA: leblanc%eecg.toronto.edu@relay.cs.net CDNNET: <...>.toronto.cdn Jeremy B. Shepherd ("...tektronix!tessi!escargot!jbond") or just ("jbond@escargot") "Have you never wanted to do anything that was dangerous? Have you never wanted to look beyond the clouds and the stars, or to know what causes the trees to bud, and what changes a darkness into light?" -Balderston/Fort/Faragoh/Florey