Atari Disk Speed vs C64 (stock and modded)

[Mazzspeed]

Here's a close up of the USB to serial board used, with FT232 chip. If anyone is interested...

 

[zylon]

On 4/8/2021 at 7:46 AM, youxia said:

In some cases, like the Faery Tale I mentioned, it was. It made the game (a huge cRPG ported from Amiga) practically unplayable for somebody without a fastloader. It's what the actual reviewers said back then.

 

Otherwise it was just an inconvenience: I sure as hell would prefer a "slow" 1541, even without any speed up thingies, to the tape deck I was stuck with ?

I actually went back to my 1541 w/fastload, over the SD2IEC setup I tried. Using the disks was easier. My 1571 on other system is actually faster, and so is my 1050, when it works. At least for single load games, as I seldom get beyond that on Atari.

[Mazzspeed]

56 minutes ago, zylon said:

I actually went back to my 1541 w/fastload, over the SD2IEC setup I tried. Using the disks was easier. My 1571 on other system is actually faster, and so is my 1050, when it works. At least for single load games, as I seldom get beyond that on Atari.

That's because you're not running JiffyDOS and mounting D64's requires Basic V2 open and close commands.

 

There's two things every Commodore 64 must have:

 

1. The JiffyDOS v6.01 kernel and the corresponding 1541 ROM's as they contain the faster drivers.

2. A 1541 UII+. Getting the 1541 UII+ will cover point one as it comes with a JiffyDOS kernel that the C64 can boot off.

 

JiffyDOS contains the extended CMD-HD commands when used with the SD2IEC. Namely:

 

@CD:Name - For entering the directory called Name (Current Directory).

@MD:Name - For making a directory called Name. (Make Directory).

@RD:Name - For removing a directory called Name. (Remove Directory).

 

To mount a D64 on the SD2IEC, you treat it like a directory to mount it, so:

 

@CD:D64 - Will mount a .D64 with the name 'D64'.

 

Likewise:

 

@$ - A short directory listing. Alternatively you can press F1.

@$=T - A long directory listing with time stamps.

@#11 - Enter drive number 11, substitute 11 with the number of your desired drive. Alternatively, press [Ctrl] & [D] to cycle between available drives.

 

There are many, many more commands, that's just the basics. With the SD2IEC you will hit speeds in excess of 8000B/s not a problem in the world running the JiffyDOS kernel as the SD2IEC contains the needed ROMs (drivers). You also need to make sure you download the patched SD2IEC version of the game, many new releases come with both the standard D64 and the SD2IEC patched version.

 

Edited April 20, 2021 by Mazzspeed

[carlsson]

7 hours ago, Mazzspeed said:

There's two things every Commodore 64 must have:

 

1. The JiffyDOS v6.01 kernel and the corresponding 1541 ROM's as they contain the faster drivers.

2. A 1541 UII+. Getting the 1541 UII+ will cover point one as it comes with a JiffyDOS kernel that the C64 can boot off.

Heh. I don't have either, and have been happily using my C64 (from time to time) for 35 years.

 

However I do have both TFC3 and more relevant AR6, plus a classic uIEC/SD enabled with 1581 ROM so I can take advantage of the AR6 turbo loader for single filed programs. I have a feeling that the majority of operations you can do with JiffyDOS, I can do as well with the AR6 plus that I get poke finder, sprite killer etc in the same product.

[Mazzspeed]

30 minutes ago, carlsson said:

Heh. I don't have either, and have been happily using my C64 (from time to time) for 35 years.

 

However I do have both TFC3 and more relevant AR6, plus a classic uIEC/SD enabled with 1581 ROM so I can take advantage of the AR6 turbo loader for single filed programs. I have a feeling that the majority of operations you can do with JiffyDOS, I can do as well with the AR6 plus that I get poke finder, sprite killer etc in the same product.

The thing is: With a 1541 UII+ you'll get the FCIII, AR 4.2 PAL, AR 6.0 PAL, RR 3.8g PAL, SS 5.2 PAL, TAsm/codenet PAL, AR 5.0 NTSC, RR 3.8y NTSC, SS 5.22 NTSC, TAsm/codenet NTSC, Epyx Fastloader, GeoRAM, Custom 8k ROM, Custom 16k ROM, Custom 16k Ultimax ROM, Custom RR ROM as well as JiffyDOS 6.01 included. Furthermore, you can run these cart's along with JiffyDOS 'and' a 16MB REU 'and' a 16MB ram drive...

 

JiffyDOS 6.01 kills any fastloader cart out there. Especially when running S-JiffyDOS ROM's on the emulated 1541's.

 

AR6 won't allow for directory handling as well as D64 mounting as far as I'm aware. Fastloader carts got me through the 80s and 90s, but JiffyDOS smashes the lot of them, especially with CMD-HD extended commands.

Edited April 20, 2021 by Mazzspeed

[carlsson]

FWIW, the sd2iec firmware page I quoted early on in this thread listed quite lower numbers for JiffyDOS but perhaps those relate to an earlier version of the protocol. Also I bought my AR6 in c:a 1990 so it is not a new purchase, factoring in the fact that the 1541 Ultimate series always were 3X the SD2IEC (but I know there are reasons why).

 

Commands for directory handling are straightforward, you just need to add a quote, e.g. @"CD:C64", @"CD:IMAGE.D64", @9 to change device, $ for directory, %:* for load and run the first file. Obviously you can use any extended command like @"XR:blahblah", @"XW" etc that the device supports.

[Mazzspeed]

10 minutes ago, carlsson said:

FWIW, the sd2iec firmware page I quoted early on in this thread listed quite lower numbers for JiffyDOS but perhaps those relate to an earlier version of the protocol. Also I bought my AR6 in c:a 1990 so it is not a new purchase, factoring in the fact that the 1541 Ultimate series always were 3X the SD2IEC (but I know there are reasons why).

 

Commands for directory handling are straightforward, you just need to add a quote, e.g. @"CD:C64", @"CD:IMAGE.D64", @9 to change device, $ for directory, %:* for load and run the first file. Obviously you can use any extended command like @"XR:blahblah", @"XW" etc that the device supports.

I hate the quotes.

 

Under JiffyDOS, you don't need the quotes. Do the fastloader carts support partitioning? The JiffyDOS ROM for the drive is still referred to as version 5.x, but it's designed for the JiffyDOS 6.01 kernel. As I stated earlier, I use S-JiffyDOS ROMs on my emulated 1541's for a notable improvement in speed under the JiffyDOS kernel.

 

Until you really use JiffyDOS, it's hard to explain just what you're missing. I think the FCIII fastloader is one of the fastest out there, I'm exceeding the speed of the FCIII using the JiffyDOS 6.01 kernel with S-JiffyDOS ROM's for the emulated 1541's.

[carlsson]

I never tried to create partitions on the SD card, but I would assume that is a feature of the sd2iec rather than a feature of the tool to load files. The quote is required because AR6 has built-in commands for file copier and whole disk copier that are activated with e.g. @C which is why you add a leading quote to break parsing. Sure, if that is a big issue, it is not a solution but it is a somewhat bold step to claim that JiffyDOS and Ultimate-II+ are more or less essential to every casual and/or power user of a C64.

 

Then again, I'm sure there are people here in the A8 camp that would propose various hardware solutions that are essential to every Atari user too, though there may be different opinions on what really is essential.

Edited April 20, 2021 by carlsson

[Mazzspeed]

13 minutes ago, carlsson said:

I never tried to create partitions on the SD card, but I would assume that is a feature of the sd2iec rather than a feature of the tool to load files. The quote is required because AR6 has built-in commands for file copier and whole disk copier that are activated with e.g. @C which is why you add a leading quote to break parsing. Sure, if that is a big issue, it is not a solution but it is a somewhat bold step to claim that JiffyDOS and Ultimate-II+ are more or less essential to every casual and/or power user of a C64.

 

Then again, I'm sure there are people here in the A8 camp that would propose various hardware solutions that are essential to every Atari user too, though there may be different opinions on what really is essential.

I can honestly state that I class the U1MB and the SIDE2/3 as essential requirements for the A8, as well as 64k base ram...

 

The 1541 UII+ is quite simply, hands down, the one device every Commodore 64 user must have - It's that good.

[Mazzspeed]

Just to add. As stated previously, the SD2IEC is essentially a modern CMD-HD, so it supports the extended CMD-HD commands under JiffyDOS (CMD made JiffyDOS).

 

In relation to partioning, that means you can list partitions using the '=P' switch. So: @$=P will list all available partitions. To switch partitions, you use the command:

 

@CPx - where 'x' = The desired partition number and @CP means 'Current Partition'. The uIEC/SD uses the same firmware as the SD2IEC, both support the 1581 in the form of D81's - I'm not too sure what you mean when you state you have 1581 ROM's enabled?

Edited April 20, 2021 by Mazzspeed

[sanny]

On 4/9/2021 at 1:24 PM, mdivancic said:

Agreed. I will not run a C64 machine without JiffyDOS. God awful slow without it plus the other features are well worth it. 

 

I once had a SpeedDOS C64 back in the day. Quite impressive speed and good copy programs (supporting copy-protected disks). It used an extra parallel cable between C64 and 1541.

 

How does it compare to JiffyDOS?

 

regards,
chris

[carlsson]

4 hours ago, Mazzspeed said:

I'm not too sure what you mean when you state you have 1581 ROM's enabled?

Since the sd2iec series don't emulate the drive CPU as you are well familiar with, what those do is to sniff the data sent from the computer in order to detect commonly used fastloaders and simulate a response to those. That is why the sd2iec after all works with Epyx Fastload, The Final Cartridge 3, JiffyDOS, custom loaders based on pure Dreamload etc, but are unable to cooperate with any custom fastloader the computer is trying to reprogram the drive with. Even a modified version of the Dreamload routine is likely to fail, if it behaves differently than the original.

 

The thing is that the Action Replay Mk VI (and probably also Mk IV, V) have a very complex turbo routine for 1541 drives, that was difficult to simulate. If the response is missing, the cartridge loader falls back on the slow Kernel loader we all dislike and loathe. However the AR has a different routine for 1581 drives that is much more straightforward to react to, so what you do is to take a 1581 ROM dump and put on the SD card, then issue a @XR (or is it @R, don't remember) command that enables file based emulation according to the ROM file. It will trick the AR thinking you're having one huge 1581 drive in the other end and it can use its turbo all the way.

 

If you're using TFC3 or Epyx Fastload, you don't need to take this step since their fastloaders already are supported by the sd2iec.

 

Unfortunately, the Easyload routines on the VIC-20 crap out if you use the 1581 emulation so in the rare case I combine my uIEC/SD with the Mega-Cart, I have to temporarily disable the 1581 emulation to have Easyload work properly, and then re-enable it again once I go back to the C64.

Edited April 20, 2021 by carlsson

[Mazzspeed]

9 hours ago, sanny said:

 

I once had a SpeedDOS C64 back in the day. Quite impressive speed and good copy programs (supporting copy-protected disks). It used an extra parallel cable between C64 and 1541.

 

How does it compare to JiffyDOS?

 

regards,
chris

I believe that would have been Dolphin DOS. JiffyDOS has better command structures, I think I'm getting speeds that would be roughly similar to Dolphin DOS, but I'm not too sure as I've never used it. The best I can say is I'm getting speeds that better the Commodore SFD1001 drive with it's parallel IEEE-488 interface, so I assume I'm getting speeds as fast, if not faster, than Dolphin DOS.

 

You can enable a virtual parallel Dolphin DOS interface on the Ultimate 64. I have a clear 64C case made from the original casts here that was always going to be used for an Ultimate 64, but I never got around to actually purchasing the motherboard...

[_The Doctor__]

Reasons Divisor 0 fails, cable too long or inferior, SIO compliance caps (rx tx and handshake line plz), fake ftdi or flakey max chip, bad solder, bad crimp, bad connector, bad swipes, bad solder joints at SIO port pins/mb, bad pokey, bad cpu, and rarely bad PIA mucking up the works... You should be able to get divisor zero from just about any Atari... aside from timing issues and the like, but you should see PBI device issues if that's the case...

Edited April 21, 2021 by _The Doctor__

[Mazzspeed]

2 hours ago, _The Doctor__ said:

Reasons Divisor 0 fails, cable too long or inferior, SIO compliance caps (rx tx and handshake line plz), fake ftdi or flakey max chip, bad solder, bad crimp, bad connector, bad swipes, bad solder joints at SIO port pins/mb, bad pokey, bad cpu, and rarely bad PIA mucking up the works... You should be able to get divisor zero from just about any Atari... aside from timing issues and the like, but you should see PBI device issues if that's the case...

Well the caps have been removed resulting in divisor 1 being rock stable and none of your other points are the case. Whether it's the USB to Serial board (which I doubt), or it's an A8 issue, is fairly moot unless an individual wants to just keep buying USB2SIO adapters looking to hit some jackpot that may not exist as it may not be the adapter that's at fault based on what I'm reading here. Essentially, divisor 0 isn't guaranteed. As evidenced by the posts of others here related to their experience with the 600XL.

 

Working in the auto trade, I have to tools to crimp the terminals in the SIO plug, plus they were also soldered to the connectors in question. The ground also acts as a shield. It's a Duinotech board bought from a reputable local supplier, I see no evidence the FTDI chip is a fake.

 

However, as stated, I'm happy I obtained divisor 1. Essentially, most of the time all data runs off either the SIDE3 loader or off the SIDE3 as a PBI HDD anyway. SIO is just used for image transfer and to connect to a virtual N: and R: device via FujiNet-PC.

Edited April 21, 2021 by Mazzspeed

[_The Doctor__]

Whatever you settle for and makes you happy. It's perfect then.

Plenty of folks are just fine with their cars even if there's problem that needs attention, just turn up the radio... technical service bulletins be damned lol...  if it's only a problem driving over 56 miles an hour why bother balancing those tires or some expensive harmonic balancer in that there engine. Just don't drive that fast and it won't be an issue. I get it. I just don't suggest it for most folks is all.

 

 

[Mazzspeed]

13 minutes ago, _The Doctor__ said:

Whatever you settle for and makes you happy. It's perfect then.

Plenty of folks are just fine with their cars even if there's problem that needs attention, just turn up the radio... technical service bulletins be damned lol...  if it's only a problem driving over 56 miles an hour why bother balancing those tires or some expensive harmonic balancer in that there engine. Just don't drive that fast and it won't be an issue. I get it. I just don't suggest it for most folks is all.

 

 

Hangon, you're blaming the user here, and there's nothing to state the user is at fault - In fact there's plenty of evidence in this very thread to state the user isn't at fault.

 

Essentially, divisor 0 isn't guaranteed - It's that simple. I went from a maximum of divisor 5 to a maximum of divisor 1 just by removing the caps off the SIO lines, in itself that indicates there's most likely no issue with the FTDI board itself. Furthermore, other people have reported the same issue.

 

This is coming from an individual that is currently building an engine using very expensive components including Manley forged pistons and conrods as well as ARP studs and King race bearings for their car...

 

EDIT: I can remove the handshake cap and see if that helps, thanks for the suggestion. Hell, I could just remove all of the caps in question at the end of the day.

Edited April 21, 2021 by Mazzspeed

[+Stephen]

49 minutes ago, Mazzspeed said:

EDIT: I can remove the handshake cap and see if that helps, thanks for the suggestion. Hell, I could just remove all of the caps in question at the end of the day.

I'll tell you that none of the 3 custom PCBs I've built in the past few years use the caps.  Also, I did that on my 130XE and it's fine.  Then again, I am a heathen for daring to desecrate these coveted museum pieces.  So don't follow my advice, you're liable to get your ass chewed out for it.

[Mazzspeed]

37 minutes ago, Stephen said:

I'll tell you that none of the 3 custom PCBs I've built in the past few years use the caps.  Also, I did that on my 130XE and it's fine.  Then again, I am a heathen for daring to desecrate these coveted museum pieces.  So don't follow my advice, you're liable to get your ass chewed out for it.

Well, I removed all the caps (and if anyone feels like chewing my ass out over that, I'm ready), and divisor 0 is now stable under RespeQt and mostly stable under FujiNet-PC after multiple runs. It makes me wonder how many people actually inspect logs to monitor for stability at divisor 0, as under FujiNet-PC the transfer actually sounded fine. If you were using no more than the SIO sound, you'd be none the wiser - Having said that, I don't think it's as easy to monitor the standalone FujiNet in real time like you can via terminal running FujiNet-PC (it may even be more stable due to the fact it's mounted directly to the SIO port with no leads whatsoever):

 

 

 

 

 

Once again, it's interesting how I'm still just short of Facuai's results at divisor 0, and I can see there were absolutely no errors using the same 512 bytes/sector blank image.

 

 

Edited April 21, 2021 by Mazzspeed