| Posted By
unclouded
on 2020-04-23
05:47:06
|  Overclocking PAL 264s
I was just reading at https://problemkaputt.de/pagezero.htm#c16plus4specs that it's possible to overclock a PAL machine by putting it in to NTSC mode but that the color output will be faulty. Would the color look wrong even in the top and bottom borders, or if the video output were disabled altogether?
|
|
Posted By
MCes
on 2020-04-23
06:43:43
 | Re: Overclocking PAL 264s
When you switch the TED from PAL to NTSC mode will be changed also the relationship between the clock and the timings, numbers of lines, refresh rate...
the video output will be out of ALL video standard, not only the colour coding...
you have to "close" to black the active screen (it will double the CPU speed also into the closed screen time),
closing to black will be the best camouflage technique to prevent on old CRT monitor a not syncronized black/white image, but for a lot of LCD TV could appear the label:"no-signal".
The PAL JiffyDOS use this technique: when it load files the screen is closed to black and the speed is overclocked to @2,2MHz (NTSC mode with PAL quartz)
|
|
Posted By
MMS
on 2020-04-25
16:14:48
 | Re: Overclocking PAL 264s
@MCes,
Does it mean, that the JiffyDOS could be faster on the 264 series, than on C64 (with the same drive?)
In this stage the +4 CPU is ~2x faster than the 6510 at 1MHz.
|
|
Posted By
gerliczer
on 2020-04-25
03:24:05
| Re: Overclocking PAL 264s
Most probably not. Overclocking the Plus/4 CPU does not accelerate the drive in any significant way.
|
|
Posted By
MCes
on 2020-04-25
04:57:30
| Re: Overclocking PAL 264s
@unclouded, I agree with you, may be that JiffyDOS during serial communications use the bit on the TED register that impose always the "half clock" (now 1.1MHz) that is not less than 1MHz (the clock inside the drive 1541, so sufficient for the protocol performing), in this manner the 1.1MHz clock is CONSTANT, and it's important to perform a correct serial protocol, may be that outside the "output byte serializer routine " the clock is doubled, so the other works can be faster: time can be gained, but not much.
This is just my opinion about the system possibilities, I don't know if the jiffydos routines do this.
|
|
Posted By
MMS
on 2020-04-26
04:12:07
| Re: Overclocking PAL 264s
@gerliczer
Actually the 1541 loading was not THAT slow because of the 1541 only, but the receiving part (C64, Plus/4) could not get the data fast enough.
Just see the fastloaders, without any HW modification, there could be big differences in speed. Certainly they used different routines for loading at both sides.
This is one of the potentials Commodore lost, and really sorry they managed this way: C64 (and Plus/4) was treated to be a game computer due to the slow speed of the data storage devices, especially 1541. It is just not Now it is confirmed, that acceptable speed does NOT require hardware bit handling, just a better/more efficient communication between the computer and floppy drive, I mean an improved, backwards compatible kernel. Easyscript was one of the most advanced word (editor) of the time, but the speed of floppy drive eliminated the possibility of professional use (OK, the 80 character per line would be also nice)
I wish Commodore would have been smarter and buy JiffyDOS from Mark Fellows and would ship the products with this feature from the factory, maybe with an extra switch for full backwards compatibility. The cost uplift of the change would be almost nothing with 5-10 times speed increase.
Imagine a C64 factory release (package) with Jiffy C64/II, Jiffy 1541/II, GEOS + 256K RAM upgrade, how much it could be a game changer, same speed and capability as an early Apple Classic Macintosh.
Certainly Plus/4 cand 1551 could be upgraded with these features too (I know that Jiffy was developed after Plus/4 release, but was very close)
About the possible speed difference between the C64 and Plus/4 Jiffy due to CPU speed difference:
In case JiffyDOS the data package also changed (AFAIK): so not only the speed of the communication, but the way of communication changed between two devices (using more lines for data transfer).
So, if the receiving end is faster in case of Plus/4 (or able to do handle the bits faster, faster CPU to handle things), then again there could be a difference between the speeds, like the difference between the different fastloaders.
As currently I have no C64 with Jiffy (though I have an 1541 with Jiffy) I cannot 100% compare the speeds, but I think it will worth a try with a 200block file.
We know the typical loading times:
https://www.c64-wiki.com/wiki/JiffyDOS
|
|
Posted By
gerliczer
on 2020-04-26
05:45:17
| Re: Overclocking PAL 264s
@MMS
So, if we overclock the CPU of a JiffyDOS equipped C16/C116/C+4
- will the JiffyDOS equipped 1541 be able to load the next block any faster from disk?
- will the JiffyDOS equipped 1541 be able to transfer the data any faster without breaking the protocol?
Well, my two answers would be no. Therefore, I can't see any significant improvement in transfer speed. But I'm curious, what do I miss in your view?
|
|
Posted By
Chronos
on 2020-04-26
14:35:27
 | Re: Overclocking PAL 264s
I just thinking about overclocking generates more heat to our precious CPU and kill it faster... Is it worth it in any way??
|
|
Posted By
MMS
on 2020-04-26
14:42:12
| Re: Overclocking PAL 264s
What if there are existing waitstages in the C64 Jiffy protocol due to limited CPU power (and will not exist on Plus/4)?
This is what you missed in my view.
@Chronos
This is what I pointed few months ago. Mad confirmed, that some of the decompressor routines using this feature to make quicker finish of the tasks.
Maybe it would be worth to measure the CPU temperature in this stage by an expert, right?
But Jiffy is a great development on an existing platform. I wish it would exist with 1551 too (though I do not own that drive), what could be the speed with more paralel bits?
(Jiffy with 1541: 200 blocks in 12 seconds, AFAIK using only two wires for data transfer)
|
|
Posted By
siz
on 2020-04-27
02:02:29
| Re: Overclocking PAL 264s
JiffyDOS for the 1551 is absolute pointless. JiffyDOS is a protocol to speed up serial routines while maintaining compatibliity with all the existing drives and supporting multiple devices on the bus.
Yes, the TCBM protocol of the 1551 could be sped up with custom KERNAL and drive DOS but that has nothing to do with JiffyDOS.
And gerliczer is right: the bottleneck of JiffyDOS speed is the speed of the drive mechanics not (only) the protocol.
And I'd kindly like to ask everyone to avoid switching the TED between PAL and NTSC in their software because my RetroTink 2x loses sync every time that happens.  That's why I had to patch JiffyDOS plus/4 to remove $ff1d writes. 
|
|
Posted By
MMS
on 2020-04-27
14:26:40
| Re: Overclocking PAL 264s
I will prevent to happen in all my SW releases (counter = 0  )
Yes, I meant a similar stuff to JiffyDOS with the parallel TCBM.
The 4.5 times speed increase compared to the damn slow 1541 IEC is not impressive at all
TCBM has 8 bit data bandwidth, while the IEC uses only 1 bit for data. The protocol is just too complex.
The design team had a chance to develop a blazing fast device could directly load data into the computer, as they had everything. 8 bit data bus, two handskahe bit, extra control board, simple communition channel (no daisy chain)
This chance lost, despite using a big and arkward controller paddle.
The transfer speed is even slower than IEEE-488, was already a 10 year old protocol. Instead of using the existing IEEE-488 protocol, or creating a faster version, they created an even slower, new protocol, with full of unnecessary handshakes.
I am not impressed.
|
|
Posted By
gerliczer
on 2020-04-28
02:25:56
| Re: Overclocking PAL 264s
OK, MMS. Let's do some sort of "on back of a napkin" calculation:
The nominal rotational speed of a 1541/1551 is 300 RPM. That means 0.2 sec for each revolution. Reading one sector (meaning 256 useful bytes for the calculation) needs, depending on which track holds it, ~9500..~11500 micro-secs (overestimated). Let's assume 10000.
Somewhere I read that transferring one byte in 1541 IEC protocol takes 800 micro-secs (net time). Therefore transferring 256 bytes equals 204800 micro-secs. Altogether 214800.
Let's assume that TCBM protocol accelerates transmission to 8x of IEC. That means 25600 micro-secs. Add the 10000 of sector read and the total will be 35600.
214800/35600 is around 6.
What we omitted from the calculation are:
- sector read delay (up to about 180000 micro-secs - well, hello gorgeous)
- GCR decoding time (AFAIK, 1551 does that at about twice the speed of 1541)
- and transfer setup, synchronisation and administration overhead.
Still not impressed?
|
|
Posted By
MMS
on 2020-04-28
18:16:07
| Re: Overclocking PAL 264s
I understand the calculation.
Still the fact is that half of the bits transferred between 1551 and the 264 are handshake bits.
So with a less complex protocol (without changing any hardware) 20-30% increase could be easily reached.
As I read in an article, even the current slow protocol does not count with memory and TED status (it could explain the speed, but no).
Apple II's floppy disc drive DISC II also uses GCR coding, and still much faster with a 20 pin cable (15KB/sec), certainly it has it's own controller card (but 1551 had too).
"Both the Atari 8-bit and Commodore 64's disk drives' throughputs were much slower than the Disk II's 15 KB/s, seriously affecting their ability to compete in the business market.".
Because with Commodore drives during saving and loading you just wait wait, wait, and it is not not efficient from the point of business, this time is lost.
This Apple DISC II and it's controller was available since 1979, so there was an existing example of a fast GCR device on the market.
I know 1551 was based on existing mechanism and rotation speed, and C= wanted to reach full backwards compatibility with 1541. (not happened)
On the other hand as the 1541 was fully compatible with the 264 series, so C= could keep it for hobby machines, and could create a more serious "killer" business drive for home office (as 264 marketed by Commodore), like an 1MB SFD-1001 drive with cheaper cable and simple IEEE interface in the dongle, with proper speed. TCBM is definitely a downgraded IEEE-488 interface.
Nope, they made a second small "hobby" floppy drive at a rather high price (controller dongle), and the speed is not as fast as it could be. and the housing is too brittle :-O
|
|
Posted By
TomHX
on 2020-04-29
06:08:46
| Re: Overclocking PAL 264s
Check Csory's latest fastloaders for 1551. It uses the maximum possible data bandwith for both devices (1551, +4). This solution makes possible to load data _almost_ directly from floppy data sectors to +4 RAM with on-the-fly GCR decoding and _non-sequential_ loading. The accessing order of the sectors is the loading order, but the memory address order.
Faster is not possible without changing the drive's RPM.
|
|
Posted By
MMS
on 2020-05-01
11:45:46
| Re: Overclocking PAL 264s
THX !
OK, so some speed test on emulator (unfortunately I have no 1551).
I choose Csory's Elite, it is 205 blocks long, very close to the 203 block long PRG used for testin on C64 Jiffy.
It would be great to test it on real config, but currently have no time for that.
So loading times of 205 (203 n C64) blocks as per my own measurements and available doc.
Certainly it has a +/- 1-2 sec deviation, proper starting and stopping, so 1541 loading of Elite +4 could be 125 secs, not 127 (all tested two times, but eh...)
C64 stock 1541 (203 blocks PRG loading): 124 sec
C64 Jiffy 1541 (203 blocks PRG loading): 12 sec This is the 10x factor.
Plus/4 stock 1541 (205 block PRG loading): 127 sec (YAPE1.1.5)
Plus/4 stock 1551 (205 block PRG loading): 63 sec (YAPE1.1.5) - (...) and not 4.5x as stated (correction: few years ago clarified it is 2.2x only)
Plus/4 stock 1551 (205 block PRG loading): 64 sec (YAPE1.1.5) - (...) and not 4.5x as stated (correction: few years ago clarified it is 2.2x only)
Plus/4 Csory 1551 V4 (205 blocks): 6.1 sec :-O (YAPE1.1.5) - with Csory's fastloader the 1551 is 20x faster, than a stock 1541, and 2x faster than Jiffy. WOW!
Plus/4 Csory 1551 V4 (205 blocks): x.x sec (Plus4emu 1.2.10) - with Csory's fastloader 1551 emulation crashed with BREAK ERROR...
Csory's V4 fastloader (with switched off screen) clearly shows what does 8 bit parallel loading means, 20x of the speed of stock 1541 on IEC.
Loading 205 blocks in just 6 seconds! THIS is impressive! Evidently much better than Jiffy.
On the other hand the emulated stock 1551s in this test showed only 2x speed increase compared to stock 1541 loading, on both emulators I use.
Updated remark here: IEEE-488 floppy drives from C= on the same 8bit data bandwidth are 4x faster than IEC
These results surprised me a little.
-16-20 sec loading time (6-8x) is what I would expect from a stock 1551, with 8x more data bandwidth (data bit), but we know, it did not happen.
-2.2x faster speed is less impressive, but still a noticeable increse compared to 1541
-2x speed increase with 8x more data lines is not so impressive, so maybe only an emulation bug.
Maybe it is only an emulation issue, but as both emulators I used for the testing showed almost the same result with stock 1551...
|
|
Posted By
gerliczer
on 2020-04-29
11:14:38
| Re: Overclocking PAL 264s
This made me remember one similar test that I run ages ago. The results are here
|
|
Posted By
MMS
on 2020-04-29
13:49:11
| Re: Overclocking PAL 264s
@gerliczer
Thank you for reminding me that old thread! I almost forgot it.
Yeah, it was a very intensive discussion back then, and was ages ago
Lot of nice calculations done.
I may do some extra tests with some other 1541 fastloaders too.
Csory's 1551 V4 fastloader is rather close to the theoretical maximum speed of 1551 Litwr calculated (8.6KB/s VS 10KB/s, although later he mentioned, that maybe the limit with 1551 is just 4KB/s--> with Csory's fastloader this limit definitely broken, but only emulated 1551 tested yet)
What happened since the old thread?
At my side:
-I bought an SFD1001 drive, Litwr highlighted, as "one of the most astonishing HW from C=". Huge capacity.
-I bought az IECtoIEEE adapter, able to use IEEE-488 drives on +4/C64 with IEC slow speed.
Works, but slow as an 1541. No fastloader exists.
-I have a C16 equipped with JiffyDOS, and pretty fast with SD based IEC devices
-It turned out that my IEC2IEEE adapter is based on ATMEGA8L microcontroller, and it is just too slow to handle JiffyDOS speed handshake signal from IEEE device at 8MHz --> with JiffyDOS just freezes
-OFF1: the mentioned ATARI GUI now has a nice video:
https://www.youtube.com/watch?time_continue=72&v=ZcMSILGQmGA&feature=emb_logo
-OFF2: SymbOS has improved support for different HWs, including an external MSX GFX card. Pretty impressive
https://www.youtube.com/watch?v=plQf9_7zPSA
|
|
| |
Copyright © Plus/4 World Team, 2001-2024 |
