26 June 2021, 22:01 | #21 |
Registered User
Join Date: Jul 2019
Location: Poland
Posts: 308
|
Of all the copiers I tried among the decades, the fastest were:
1. SuperDuper 2. Rattle Copy 3. D-Copy |
27 June 2021, 13:51 | #22 |
Registered User
Join Date: Oct 2009
Location: Germany
Posts: 3,326
|
I can remember of a copy program collection disk around 30 years ago on my A500. It had the common up/down scroll menu selection and I think it was in (dark) blue. There were a lot of programs (maybe 10?). Some or most had the usual nice looking GU like XCopy had. One or some turbo copy programs were (insane) very fast and I thought they must make a fake copy. Copy a disk in under 10 seconds (sounded like a machinegun)?! I didn't trust, can't be a valid copy but did some tests and in surprise the copy worked. Just in case someone can remember this collection disk.
|
27 June 2021, 21:12 | #23 |
Registered User
Join Date: Jul 2019
Location: Poland
Posts: 308
|
It probably was a dos disk with not much data and bitmap copy mode (which copies only used sectors). Every decent program had such option.
|
28 June 2021, 12:16 | #24 |
Registered User
Join Date: Apr 2017
Location: Cambridge
Posts: 136
|
|
28 June 2021, 14:11 | #25 | |
Defendit numerus
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 54
Posts: 4,536
|
Quote:
No idea if it can be 'inserted' as a custom module in KS1.x. |
|
03 July 2021, 02:05 | #26 |
Registered User
Join Date: May 2005
Location: Cheshire, UK
Age: 57
Posts: 322
|
Asides from actual read speed, I quite like the "illusion" of read speed.
I sometimes put data on same side of the disk so the loading "sounded" faster As a small aside, I coded a music disk set for DCS back in the day and put a neat trick in the boot-code. I wanted the intro to start immediately (like in Global Trash by TSL) but not with a little sample loop, with actual PT music that continued as the rest loaded. I managed to squeeze the intro sequence, PT player and the first bit of the module + 1 instrument into the first track (about 11k? iirc) The loader carried on and loaded and stitched the rest of the loading tune onto the back of the stub. I think this was the only time this was ever done with a full PT music track/continuation demo on the Amiga? Yes, TSL did it first with a single sample, but I'm not aware of any other trackmo/multi disk effort that did this. Please let me know if I'm wrong. Oh, the prod that this was done in was Sonic Attack by DCS if you want to check it out. |
03 July 2021, 10:20 | #27 |
Registered User
Join Date: Jun 2016
Location: europe
Posts: 1,097
|
I did something similar.
Track0 was main loop, loader&support code, first effect and first part of the sample that was played immediately, and which was actually used in the module and was removed from the pattern row, and copied into its proper location within module. And I didn't load track0, I reused trackdisk's MFM buffer to decode it for a super fast start, while I was loading track1 that contained the rest of the sample being played, PT player, some gfx, etc. Module was split into a few out of sequence chunks (or should I say time-based chunks) that were from track2 on. |
03 July 2021, 12:03 | #28 | |
Defendit numerus
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 54
Posts: 4,536
|
Quote:
In your case it's a bit dangerous: what if the bootblock is in fast-ram? (KS2.0+ does it ) |
|
03 July 2021, 12:21 | #29 |
Registered User
Join Date: Jun 2016
Location: europe
Posts: 1,097
|
That was ~25 years ago. Nowadays I just reuse a2 IO request with modified length of size of a track and let the system do the work.
And to be more precise, I checked the old code, I only did the MFM trick with KS1.x, otherwise track0 was loaded (didn't work on a4000, a0 pointed to something else). But back then during the newbie days it was good enough (and all about 0% OS usage :P), it worked fine with OS killed and cpu decoding. |
03 July 2021, 12:29 | #30 | |
Defendit numerus
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 54
Posts: 4,536
|
Quote:
Take a look at the code of many commercial games/programs; as well as using 'dirty' tricks they were also poorly written.. |
|
13 August 2024, 22:11 | #31 |
Registered User
Join Date: Jul 2015
Location: The Netherlands
Posts: 3,464
|
Apologies for the thread necromancy, but there's something I wonder about regarding disk drive read speeds. Amiga disk DMA through Paula uses 3 DMA cycles per scanline, which gives it something like 1878 bytes/frame or 93900 bytes/second of bandwidth. Now this is encoded data so you'd still need to decode it. Using standard MFM, this translates into 46950 bytes/second of decoded data.
This is way more than the floppy drive delivers (which is about 20-25KB/sec decoded data). Yet, when I look in WinUAE using the visual DMA debugger in cycle exact mode with 1x floppy speed, the DMA seems to be in-use for entire frames at a time when reading from disk. Why is there such a large difference? The only reason I can think of is that those cycles might be used to account for timing differences, but that feels slightly weird to me. Anyone know what's going on here? |
13 August 2024, 22:44 | #32 |
Registered User
Join Date: Jun 2016
Location: europe
Posts: 1,097
|
Some of the data is wasted (when you load a full track you also load a gap between the last and the first sector). A decent amount of metadata is used and discarded: sync words, sector headers (sector/track info, checksums, some unused space).
The rest is suboptimal parallelization and safety (read/decode/timings), I guess. |
14 August 2024, 00:12 | #33 |
Defendit numerus
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 54
Posts: 4,536
|
Normal DD floppy MFM cells are 2us.
The amiga uses a multiple (as with anything clocked in hardware) of the bus cycles, to be precise 7, for the cell duration. For simplicity, let's take a PAL system, with BUS frequency (CCK) = 3546895 Hz and 227 cycles per line. This implies an MFM cell duration of 1/CCK*7=1.97356us (so tracks written by Amiga are naturally slightly longer than normal, but absolutely within tolerance). In a line of 227*1/CCK~=64us, how many 2ns cells can I write? Of course 32. Potentially how many cells per line can be written by Amiga? 16*3. So @roondar, surely what you saw are 2 channels always full and practically the third almost empty Why 'almost'? Because, as said, the amiga cells are slightly faster than the standard and also (on read) the slight variations in motor speed can 'generate' more cells on the track. Another reason to see the third available channel used 'more often' is when the track to be read (perhaps protected) is 'long'. |
14 August 2024, 00:23 | #34 | |
Registered User
Join Date: Jul 2015
Location: The Netherlands
Posts: 3,464
|
Quote:
Thanks for explaining it! P.S. I had written my question from my memory of what I saw in WinUAE, and I did not actually remember that one of the three channels was empty some or most of the time in the Visual DMA Debugger Edit: I'm not entirely sure I get it fully yet. If the Amiga reads/writes roughly 32 cells in a scanline and cells represent transitions rather than bits, I'd expect two cells to form one bit (assuming what I found about MFM cells is correct). This would come out to 16 bits per scanline => 5008 bits per PAL frame => 31300 bytes per second in encoded form, which would represent ~15650 bytes per second when decoded. That seems too low, so I'm sure I'm still missing something here. Last edited by roondar; 14 August 2024 at 00:46. |
|
14 August 2024, 08:18 | #35 | |
Defendit numerus
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 54
Posts: 4,536
|
Quote:
By MFM encoding it is possible to uniquely define that a pair of consecutive cells give a bit. This is a grand total of approximately 32/2*313*49.92~=250kbit/sec, that is exactly the maximum theoretical decoding speed for a DD floppy. You would have had the same result if you started from the assumption that a bit requires x=2*2us -> 1/x=... Last edited by ross; 14 August 2024 at 08:57. Reason: better 'cells' description |
|
14 August 2024, 11:21 | #36 | |
Registered User
Join Date: Jul 2015
Location: The Netherlands
Posts: 3,464
|
Quote:
You are of course correct. My misunderstanding arose from the fact that I thought the 250kbit/sec represented data that still needed to be decoded from MFM, but it represents the data rate of decoded data. And then it all does make sense: the 250kbit/sec (~30KB/sec) is a theoretical maximum, not the actual speed you get. Since the Amiga gets to 20-25KB/sec, this fits. Thanks again. Next time I'll try to only do these kind of tech things when I'm fully awake |
|
14 August 2024, 11:39 | #37 | |
Defendit numerus
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 54
Posts: 4,536
|
Quote:
But non-standard/long/modified-MFM tracks or quality loaders can increase the values you indicated quite a bit |
|
14 August 2024, 14:17 | #38 | |
Ex nihilo nihil
Join Date: Oct 2017
Location: CH
Posts: 5,157
|
Quote:
|
|
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
Thread Tools | |
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Can Amiga read/write to Atari ST floppy disks? | Blitter | Retrogaming General Discussion | 23 | 28 February 2020 03:49 |
Add ability to select PC floppy drive so you can read ADF files from PC Floppy | Unicron | request.UAE Wishlist | 6 | 07 February 2017 16:12 |
Easynet Floppy read errors | berkley | support.Apps | 1 | 14 October 2016 03:10 |
read amiga floppy disk on a pc | reddwarf4ever | support.FS-UAE | 2 | 12 January 2016 13:45 |
Amiga 1200 Floppy read errors. | atarisucks | support.Hardware | 1 | 18 May 2007 22:27 |
|
|