65 XE vs. C64 Commercial

[Bryan]

But on the plus side you could upload your own code to the 1541 and have it run native on the drive. by doing these you could implement a pretty fast disk turboloader.

 

or there's the good old action replay cartridge

 

C= should have sacked (no pun intended..ok maybe) the guy who wrote the original loader.

 

-Bry

[Goochman]

810 - 70K

1050 - 127K (lame)

XF351 - 360K - was supposed to be available for the XE line but came out late

 

there were many mods to 'fix' the 1050 for 180K disk formatting.

 

However,

For base to base comparisions you could grow corn waiting for the C64 drive to load

 

But on the plus side you could upload your own code to the 1541 and have it run native on the drive. by doing these you could implement a pretty fast disk turboloader.

 

or there's the good old action replay cartridge

 

True - I was just pointing out the OEM flaws from Atari and C= - I think they didnt have time to write a proper DOS so the original 1541 is similar to tape with regard to loading IIRC - I could be waaaaay off, but it wasnt much faster

[Fröhn]

True - I was just pointing out the OEM flaws from Atari and C= - I think they didnt have time to write a proper DOS so the original 1541 is similar to tape with regard to loading IIRC - I could be waaaaay off, but it wasnt much faster

 

The DOS itself is not that bad, it's quite ok actually. The problem is that "last minute serial transfer routines". Originally they planned to do the transfer based on hardware handshaking and shift registers but some bugs in the hardware kept it from working. When the engineers saw that they wouldn't keep the deadline when fixing that, they implemented some lame (very lame actually) software transfer routines. This all happend long before the C64, but the C64 still had to suffer from that. Anyway, just replacing the serial transfer routines by faster ones you could easily speed up loading 10 - 15 times (so you see, the other routines are not that bad).

[emkay]

The DOS itself is not that bad, it's quite ok actually. The problem is that "last minute serial transfer routines". Originally they planned to do the transfer based on hardware handshaking and shift registers but some bugs in the hardware kept it from working.

 

This is one of the "pro C64" argues I still hate...

Look at the quote... It shows that original C64 and 1541 Floppy could not do faster in 1983/84. Even SID (5 revisions) and other chips are updated in the years and the C64 grew better. BUT! : Everyone is talking about the "great C64" from 1983. And that is a fact that is not given! And I hate that Commodore propaganda in 1983 comparing with everything but an ATARI in power and price...(even when they stole some techniques from ATARI)

The only mess at ATARI was the "not upgrading" the 8-bit computers for a too long time(1979 to 1985)

Commodore did real upgrades on their systems "every year" and that was a benefit.

But, a C64 with a 1541 was not capable to do, what a C64-II with a 1541-II could do.

So please stick to authentical argues...

[TMR]

This is one of the "pro C64" argues I still hate...

Look at the quote... It shows that original C64 and 1541 Floppy could not do faster in 1983/84. Even SID (5 revisions) and other chips are updated in the years and the C64 grew better. BUT! : Everyone is talking about the "great C64" from 1983.

 

That's not the case, the C64 didn't change in ability during it's lifespan and the only reason for the redesign of the board in 1985/6 was cost related rather than an enhancement. No feature was added to the initial design of the C64, the last machine off the production line was pretty much the same as the first barring a few bugfixes in the VIC-II which happened in the first year so any software that looks good on a T2 pack C64 revision E (the last manufactured) will look exactly the same on 1982 revision breadbin. The only exception to this is one issue of the new board that came about when the changeover happened that can't actually linecrunch, so one rather cool demo effect stopped working on those machines.

 

The SID was changed yes, but only in that the filter strengths altered from revision to revision and there's nothing to stop any 6581-based machine having it's SID swapped out with any other 6581-based unit. My own work machine for many years until i got my C128D came with a 1984 issue chip which is incredibly filter heavy, i changed it for a 1983 issue.

 

Commodore did real upgrades on their systems "every year" and that was a benefit.

 

Commodore never upgraded the C64. Even the C128 doesn't count, the C64 mode functions identically to a stock 1983 issue breadbin, that was the point of the mode.

 

But, a C64 with a 1541 was not capable to do, what a C64-II with a 1541-II could do.

 

Yes it is.

 

Nothing changed between the 1541 and the 1541-II either, the mods were purely cost related; the power supply was taken external to reduce overheating (which saved money in returns, although the external supplies were not always as reliable), the board was cost reduced but still retained all the original specs and the case redesigned to match the 1571 but a stock 1982 issue built-for-VIC20 1541 and a stock 1982/3 breadbin can and does still load at 25 times the speed limit Commodore set on the drive and possibly faster if the drive is well aligned.

 

The C64 serial device system, as Frohn says, is a throwback to before the birth of the C64 itself; Commodore used IEEE for the PET and it was faeces off an earth mover fast, but they had to pay licence fees for the standard. So when the VIC was on the drawing board it was decided to produce a custom system and the VIC was originally kitted out with an incredibly fast disk system that would leave everything else standing. But at the very last minute before the machine's release (too late for anything to be done without Commodore missing a Christmas market) a very major fault was found and the six pin serial standard cobbled together to get the thing out of the door.

 

When the C64 was being built, IEEE was still not an option and, because the 1541 drive was already out there along with a printer and other peripherals that tied into the six pin serial, it was decided that the C64 should have the same system and maintain backward compatibility. Eventually, the 264 series used a parallel system similar to the one originally designed for the VIC20, which is why a Plus/4 and a 1551 will toast just about anything short of an Amstrad CPC loading from 3" floppy and even then it's a damned close match. That's what the C64 could have been...

[emkay]

 

 

That's not the case, the C64 didn't change in ability during it's lifespan and the only reason for the redesign of the board in 1985/6 was cost related rather than an enhancement.  

 

Sorry... But i cannot admit here.

I know some C64(I) that did not do anything exept of the known standard. So in the boards and chips are slightly changes done, to give more stability to the machine (I don't know all of them because I am no C64 User at all) ... and the resulting "higher coding level" abilities

Firstly a C128 I had for a span of 14 days at home, did all "upgrades" but we still had to wait 20-60 minutes while loading games like Sanxion or Test Drive.

So we played Drop Zone multiple times on the XL (which was loaded in a minute without any speeder) until a game was loaded on the C128. Wasn't there a "fast" Dolphin Dos?

[TMR]

Sorry... But i cannot admit here.  

I know some C64(I) that did not do anything exept of the known standard. So in the boards and chips are slightly changes done, to give more stability to the machine (I don't know all of them because I am no C64 User at all) ...

 

No stability was gained even after the initial fixes to the VIC-II, functionally speaking the only real change was what happened to the colour map when the screen is cleared (on the old chip it's set to the cursor colour, on the new it's set to the screen colour). The only thing changed was reliability (the early machines were prone to dying on their arses) and that's not the same thing... =-)

 

As i said, the functionality of the C64 never changed, any code i write will execute on a 1983 issue machine regardless of if i use a 1983 issue, 1985 hybrid (old board, new case), SX-64, C128 or even an emulator - the ROMs supplied with CCS and WinVICE are essentially the same as the ones in the 1983 issue breadbin.

 

and the resulting "higher coding level" abilities

Firstly a C128 I had for a span of 14 days at home, did all "upgrades" but we still had to wait 20-60 minutes while loading games like Sanxion or Test Drive.

 

The loader on Test Drive was total shyte and the one on Sanxion isn't really all that much better, try loading an original of Uridium off disk and it'll toast either despite being the same size as Sanxion in memory.

 

A stock C64 with software accelleration can load a 200 plus block file in about six seconds, these speeders weren't used on many commercial games because they were either not integrated with protection systems or (as Commodore themselves decided when they dialed down the speed on the loaders they later licenced) deemed not reliable enough on an only moderately well aligned disk drive to be used.

 

So we played Drop Zone multiple times on the XL (which was loaded in a minute without any speeder) until a game was loaded on the C128.

 

You should try it from tape, then we're talking a whole different ballgame... 30 minutes, if memory serves compared to about six on the C64?

 

Wasn't there a "fast" Dolphin Dos?

 

Dolphin DOS, JiffyDOS and a few others are ROM replacements for both the C64 and drive and use parallel connections. Generally, they're very fast, pulling about 40-50 times stock speed and a match for just about anything going on the 8bit front as well as giving a few 16bit machines a run for their money too.

[emkay]

Sorry... But i cannot admit here.

I know some C64(I) that did not do anything exept of the known standard. So in the boards and chips are slightly changes done' date=' to give more stability to the machine (I don't know all of them because I am no C64 User at all) ...[/quote']

 

No stability was gained even after the initial fixes to the VIC-II, functionally speaking the only real change was what happened to the colour map when the screen is cleared (on the old chip it's set to the cursor colour, on the new it's set to the screen colour). The only thing changed was reliability (the early machines were prone to dying on their arses) and that's not the same thing... =-)

 

 

Yes... it was like to fix beta issues. And that was reason enough, not to buy such machine in the first time...

 

 

Wasn't there a "fast" Dolphin Dos?

 

Dolphin DOS' date=' JiffyDOS[/b'] and a few others are ROM replacements for both the C64 and drive and use parallel connections. Generally, they're very fast, pulling about 40-50 times stock speed and a match for just about anything going on the 8bit front as well as giving a few 16bit machines a run for their money too.

 

TMR... this is a point, I will not discuss because I cannot check it on real hardware.

 

But where to calculate on?

Sanxion has about 230 blocks and is loaded half an hour, so you would have 300 baud.... 50 times faster? That would be 15000 baud

I know from the AMIGA a speedup for the Floppy that enhances the speed and the 880K were loaded at half the time...But even this was not built in in standard due to Hardware-issues...

[TMR]

Yes... it was like to fix beta issues. And that was reason enough, not to buy such machine in the first time...

 

Except that one "fault" is pretty much a non issue, Skywave/Cosine used a 1982 issue C64 for all his music work because the machine functioned (and functions, i believe) perfectly.

 

See the reason... allmost every game that could have been fun to play, was "killed" by the loading time.

 

But that's not Commodore's fault, in the case of Test Drive 2 it's also not particularly well programmed so it spends a lot more time loading than it really needs for all the pretties. Again i'll point at Uridium for an example, loads like the clappers and isn't a particularly fast scheme.

 

Even here I would search for HW-Issues. Mostly a manufacturer reduces the Hardware to give allways stability. But ... clever as they are... they leave the possibility to get more out of the machine at the users own risk.

 

Commodore always played safe, they licensed the SuperNova tape loading scheme from Novagen and later John Twiddy's Cyberload and, despite both systems being tried and tested "in the field" over a number of years, they deliberately dialed the speed down.

 

But where to calculate on?

Sanxion has about 230 blocks and is loaded half an hour, so you would have 300 baud.... 50 times faster? That would be 15000 baud

 

i just ran a trial, i made a 202 block file by filling the memory from $0801 to $cfff with copies of the BASIC ROM and simply writing the whole lot out to disk. Using the standard DOS and taking the timing from the point i hit enter on the load command to when BASIC returns to the ready prompt, that file takes around 2m10s to load. With an Action Replay in place it took nine and a half seconds.

 

Anything going slower than that is doing something daft, like loading in large, colourful presentation pictures without any form of compression.

[Bryan]

This argument is largely silly. One could fault Atari for not shipping GTIA's from the start as well. The rush to market often requires that mistakes be made and fixed later. The original 64 provided a huge amount of functionality right out of the box.

 

That said...

 

See the reason... allmost every game that could have been fun to play, was "killed" by the loading time.

 

But that's not Commodore's fault, in the case of Test Drive 2 it's also not particularly well programmed so it spends a lot more time loading than it really needs for all the pretties. Again i'll point at Uridium for an example, loads like the clappers and isn't a particularly fast scheme.

 

I would argue this is mostly Commodore's fault. If the drive was faster out-of-the-box, then there would be little opportunity for games to take so long to load. There might be an easy fix, but you can't expect every software vendor to be cognizant of it and willing to use it. Besides, I doubt game sales were affected much by load time.

 

Another major flaw of the 1541 was the absence of a device 8,9 switch. The software method of configuring 2 drives was a serious inconvenience.

 

-Bry

[Goochman]

The 810 or 1050 didnt provide the most elegent drive switch mechanism either - I wonder why this was ignored back then? Getting 2 drives was ok, but getting drive 3 or 4 configured took some patience - Then again the Apple was prob the worst of the bunch

[Bryan]

The 810 or 1050 didnt provide the most elegent drive switch mechanism either - I wonder why this was ignored back then?  Getting 2 drives was ok, but getting drive 3 or 4 configured took some patience - Then again the Apple was prob the worst of the bunch

 

I have no problem with the 810/1050 method. You set it once and forget it.

The 1541 forgets its setting when turned off (unless you do a hardware mod).

 

Oh yeah, I would also fault Atari for the poor video quality of the XL line and the missing Chroma output.

 

-Bry

[TMR]

This argument is largely silly.

 

Maybe it is silly, but he started it! [stamps foot petulantly =-]

 

I would argue this is mostly Commodore's fault. If the drive was faster out-of-the-box, then there would be little opportunity for games to take so long to load.

 

There's a difference between a game taking ages to load because the hardware drags it back and a game taking ages to load because it's badly designed and reloads over the same block of memory several times to show pretty pictures and intro sequences. Yes, the hardware loader is slow but under three minutes for 50K isn't the half an hour that gets bandied around during these discussions.

 

There might be an easy fix, but you can't expect every software vendor to be cognizant of it and willing to use it.

 

Test Drive 2 was released in 1989, even Commodore were using third party fastload schemes by then!

 

Another major flaw of the 1541 was the absence of a device 8,9 switch. The software method of configuring 2 drives was a serious inconvenience.

 

Now that is something i won't argue with... =-)

[Bryan]

This argument is largely silly.

 

Maybe it is silly, but he started it! [stamps foot petulantly =-]

 

Yeah, let's get back to something we can all agree on. Boy the Apple II was a piece of garbage!

 

-Bry

[walter_J64bit]

C64 vs. Atari that takes me back! I have say this Commodore has the better monitors!

[emkay]

This argument is largely silly. One could fault Atari for not shipping GTIA's from the start as well. The rush to market often requires that mistakes be made and fixed later. The original 64 provided a huge amount of functionality right out of the box.

 

Do you still try to judge over people's decisions you still know? Thanks.

Is it your opinion? So please tell us your opinion.

 

 

See the reason... allmost every game that could have been fun to play' date=' was "killed" by the loading time.[/quote']

 

But that's not Commodore's fault' date=' in the case of [b']Test Drive 2[/b] it's also not particularly well programmed so it spends a lot more time loading than it really needs for all the pretties. Again i'll point at Uridium for an example, loads like the clappers and isn't a particularly fast scheme.

 

I would argue this is mostly Commodore's fault. If the drive was faster out-of-the-box, then there would be little opportunity for games to take so long to load.

 

Another question is, why ATARI used capacitors to reduce signal strength. Without them, the 1050 could be 5 times faster and write in DD from the beginning...even the data on the discs was saved for a bigger live-span.

But even out of the box... you could easiely write a small relational database in Basic and give it 800 (or more by up to 4 Disk-Drives) entries and "bip bip bip" the search was finished... The C64 did take a similar time to check the directory only.

 

 

 

There might be an easy fix, but you can't expect every software vendor to be cognizant of it and willing to use it. Besides, I doubt game sales were affected much by load time.

 

I think, if my beard was not growing while loading such a game or "Test Drive" was more flowing in Gameplay, there would have been fun to use it. Even Boulder Dash... switching on the XL...playing Boulder Dash was fun until the last level...on C128 it was like chewing a peace of wood... a.s.o.

Heck.... even Roland on the Ropes(CPC) was more fun to play...

[TMR]

I think, if my beard was not growing while loading such a game or "Test Drive" was more flowing in Gameplay, there would have been fun to use it.

 

Nope, even with a speeder patched in it's only an average game at best - Power Drift was released a year after Test Drive 2 and it runs from a single load and plays far better. =-)

 

Even Boulder Dash... switching on the XL...playing Boulder Dash was fun until the last level...on C128 it was like chewing a peace of wood... a.s.o.

 

Uh, after Boulderdash has loaded once that's it and it plays from memory - hardly the same league as Test Drive 2 is it?

[Heaven/TQA]

ok.... my 2 cents regarding disc drive...

 

i missed a fastloader, hyperload or whatever for:

 

- the damned 1010... (remembering loading ages for dimensionX and other tapes, luckily they had this biutiful music as background...)

 

why did no 3rd party ever used a kind of fastloader? you "just" need to enhance the baudrate of the pokey timers???

 

- the 1050

 

very fast at beginning but after that you could not do any software hack? or did i missed a fastloader? all where kind of hardware hacks...

 

i had turbo1050 enhancement, new sector skew via software etc... but you would need to reformat your discs etc... and no compatibility by OS with the 180k... (ok...sio routines are capable to do it but in practice?)

 

ok. never had the speedy1050 hardware "buffered" enhancement...

 

so even the 19200 baud wasn't fast enough at the end of the day...

 

so...all was kind of hardware enhancements but not via software? why was it possible for c64? and not from atari? driven faster just via clever code???

 

hve

[Heaven/TQA]

and preloading a f...ing dos just to read the directory is crap imho...

(not talking about game dos bootloaders etc...)

 

have i told you that i have a baseball shirt with "LOAD "$",8,1"??? no kidding...

 

hve

[emkay]

I think, if my beard was not growing while loading such a game or "Test Drive" was more flowing in Gameplay, there would have been fun to use it.

 

Nope, even with a speeder patched in it's only an average game at best - Power Drift was released a year after Test Drive 2 and it runs from a single load and plays far better. =-)

 

On the other way... Test Drive 2 did play much more better on an ST or AMIGA .-)

 

Even Boulder Dash... switching on the XL...playing Boulder Dash was fun until the last level...on C128 it was like chewing a peace of wood... a.s.o.

 

Uh, after Boulderdash has loaded once that's it and it plays from memory - hardly the same league as Test Drive 2 is it?

 

Ofcourse they are completely different games. I tried to explain that a C64 never was a fun machine to me as the ST never was a fun machine to me. So I am happy I still own an ATARI XL and an AMIGA 2000 besides of my actual PC Hardware =-)

[emkay]

ok.... my 2 cents regarding disc drive...

 

i missed a fastloader, hyperload or whatever for:

 

- the damned 1010... (remembering loading ages for dimensionX and other tapes, luckily they had this biutiful music as background...)

 

why did no 3rd party ever used a kind of fastloader? you "just" need to enhance the baudrate of the pokey timers???

 

 

I never used it, but there WAS a fastloader for tapes.

 

 

 

- the 1050

 

very fast at beginning but after that you could not do any software hack? or did i missed a fastloader? all where kind of hardware hacks...

 

i had turbo1050 enhancement, new sector skew via software etc... but you would need to reformat your discs etc... and no compatibility by OS with the 180k... (ok...sio routines are capable to do it but in practice?)

 

 

"very fast at the beginning" you say it.

The problems you are mentioning are still "Drive" Problems, not Computer-Problems. SIO is a comfortable bus-system (similar to USB) which was able to use ~100kb/s from the beginning. By using PBI or Cartridge Slot 60kByte/s via data-polling were no problem. But there was no official drive for that available.

 

ok. never had the speedy1050 hardware "buffered" enhancement...

 

so even the 19200 baud wasn't fast enough at the end of the day...

 

 

This is, why you have to split argues pro & contra by years and revisions, and not in general ...

As I said before... in 1986 I would never have bought an ATARI 8-Bit. In 1983-84 it was the better choice ....

 

so...all was kind of hardware enhancements but not via software? why was it possible for c64? and not from atari? driven faster just via clever code???

 

hve

 

The biggest unanswered question is: Why did ATARI cripple their 8-Bit hardware from the beginning to the end?

[Bryan]

Do you still try to judge over people's decisions you still know? Thanks.

 

I can't figure this sentence out.

 

-Bry

[emkay]

Do you still try to judge over people's decisions you still know? Thanks.

 

I can't figure this sentence out.

 

-Bry

 

Only a Judge is able to do judgement. If you are no judge so please tell us your opinion and nothing more ....

[Bryan]

Do you still try to judge over people's decisions you still know? Thanks.

 

I can't figure this sentence out.

 

-Bry

 

Only a Judge is able to do judgement. If you are no judge so please tell us your opinion and nothing more ....

 

This thread started out being about an Atari commerical but the way you're going at it looks more like a 20 year old flame war. You did get my opinion: Arguing about this stuff is silly.

 

Another question is, why ATARI used capacitors to reduce signal strength. Without them, the 1050 could be 5 times faster and write in DD from the beginning...

 

The reason the 1050 couldn't do DD is because it doesn't have enough RAM for DD sectors. It has 128 bytes for "scratchpad" use, and 128 bytes for a sector buffer. The US Doubler simply adds more RAM and a new ROM.

 

so...all was kind of hardware enhancements but not via software? why was it possible for c64? and not from atari? driven faster just via clever code???

 

Atari drives have their code in ROM with no extra RAM to store faster loading routines. It takes an internal upgrade to speed up the drive.

 

and preloading a f...ing dos just to read the directory is crap imho...  

(not talking about game dos bootloaders etc...)

 

It's a trade off. The Atari allows automatic booting which is very nice for games (plus an Atari BBS could reboot itself if power went out).

 

-Bry

[TMR]

so...all was kind of hardware enhancements but not via software? why was it possible for c64? and not from atari? driven faster just via clever code???

 

Atari drives have their code in ROM with no extra RAM to store faster loading routines. It takes an internal upgrade to speed up the drive.

 

On the C64, IRQ loaders (disk systems that work on runtime whilst a couple of interrupt driven routines play music and so forth) push alternative transfer routines into the drive's RAM but most of the fastest software-based speeders don't use it and simply up the transfer rate at the C64's end. This is easily demonstrated by loading one file, powering the drive down and up to clear it's memory and loading a second file, the 25 times faster software-based loader i have knocking about will quite happily survive a drive reboot in this way.

 

and preloading a f...ing dos just to read the directory is crap imho...  

(not talking about game dos bootloaders etc...)

 

It's a trade off. The Atari allows automatic booting which is very nice for games (plus an Atari BBS could reboot itself if power went out).

 

The C128 supports autobooting, i'm not sure why the C64 doesn't have it but i suspect it's yet another legacy issue; the PET can't do it and the C64 BASIC (and thus the DOS) and the drive controller software in the 1541 is based on the same software as the PET drives used.