|
Post by eslapion on Jul 23, 2016 5:35:00 GMT
If you own a Xoomfloppy adapteryou probably know there a nice piece of software for this adapter which allows using a 1571 drive to write back G64 images directly to a 5.25" floppy disk.
This is only possible with a 1571 because of the drive's ability to support burst transfer modes that are as fast as if you had a parallel cable.
Now, I have asked Peter Rittwage if it is possible to make a software for the C128 which could dump the data of a G64 file stored on a 1581 drive or even in a 512k REU to a 1571 drive. After all, all 3 components involved do support burst transfer modes too. He said it is impossible and he gave me a nice CPU cycle chart to prove his point.
The problem I have with that is that the CPU inside the 1571 which receives the data is no faster than the C128's own CPU. If the 1571 can receive the data at a certain rate from the Zoom floppy, how come the C128 in FAST mode can't send it just as fast ? Especially if you take a break between each track, prepare the data in the C128's RAM to organise it in a way maximizing transfer speed over the CIA's serial port.
On top of that, I can easily ensure all the CIAs involved are actually 8521 chips.
|
|
wegi
KIM-1 User
Posts: 35
|
Post by wegi on Sept 15, 2017 1:38:34 GMT
But... we talking about 1571 in GCR mode as could remember 1581 it's MFM only. So probably different times to byte read generate they are. Today we can buy 512KB static RAM for $1. Special in 1571 (I don't know 1581 never had) we have free CIA ports (for banking additional 512KB static RAM) and can be immediatelly read all disk to RAM. After this no problem with transwer or GCR decode etcetera.
Edit:
Also I guess here (1581) can be the DMA controller for read block to RAM...
|
|
|
Post by eslapion on Sept 17, 2020 10:53:41 GMT
But... we talking about 1571 in GCR mode as could remember 1581 it's MFM only. So probably different times to byte read generate they are. Today we can buy 512KB static RAM for $1. Special in 1571 (I don't know 1581 never had) we have free CIA ports (for banking additional 512KB static RAM) and can be immediatelly read all disk to RAM. After this no problem with transwer or GCR decode etcetera. Edit: Also I guess here (1581) can be the DMA controller for read block to RAM... It is totally irrelevant that the 1581 operates in MFM, it's only used to store the G64 file because it is almost 400kB in size. The data is already in GCR form in a G64 file. NibWrite operates on a PC fitted with Zoomfloppy.
|
|
|
Post by oziphantom on Sept 18, 2020 4:54:22 GMT
why don't you get the 1581 to send data to the 1571 and just bypass the 128 altogether as Maverick Copier?? does when you do 71-71 copies. Both the 81 and 71 run at 2Mhz and the both have Burst.
|
|
|
Post by eslapion on Sept 19, 2020 11:41:02 GMT
why don't you get the 1581 to send data to the 1571 and just bypass the 128 altogether as Maverick Copier?? does when you do 71-71 copies. Both the 81 and 71 run at 2Mhz and the both have Burst. That sure seems like an interesting idea but there is a problem with this suggestion. Let's assume I format a 3.5" floppy in the native 1581 format and put a G64 file on it. I would have to have the C128 send a piece of code to the 1581 telling it how to parse the file, extract the GCR code for a single track's data then send this data to the 1571. The problem is once the parsing code is downloaded to the 1581's RAM (the 1581 has 8kB of RAM), there will not be enough 1581 RAM left to hold the GCR data for a complete track. If you just use the 1581 as a means of storage for the G64 file, you can get the C128 to load the GCR data from the G64 file at slow speed one track at a time. Once a complete track is in the C128's RAM, the C128 can send it to the 1571 at full speed. Then read the next track at slow speed from the G64 file and so on.
|
|
|
Post by oziphantom on Sept 19, 2020 14:07:39 GMT
the 128 can still conduct though right?
1581, load Sector X, Track Y 1581, Skip X bytes, then Transfer Y bytes to 1571
I would think this code would easily fit in 1-2 pages
|
|
|
Post by eslapion on Sept 22, 2020 15:52:07 GMT
the 128 can still conduct though right? 1581, load Sector X, Track Y 1581, Skip X bytes, then Transfer Y bytes to 1571 I would think this code would easily fit in 1-2 pages That doesn't work at all. First, the content of the G64 file has to be parsed in order to know exactly what part represents a track and exactly what portion has to be sent to the 1571 and tell the 1571 to record the incoming data to exactly what track. Since the point is to dump to a real 5.25" floppy with tough protection, the Y bytes you mention must comprise a complete single track and be transferred in a single shot, exactly like you would do using a parallel cable. This doesn't fit in a 1581's RAM if a portion of it is already taken up by code. I suggest you check how NibWrite works. It uses a XUM1541 and the high speed serial port of the CIA in the 1571 as a substitute for a parallel cable. However the XUM1541 is attached to a PC with USB and it has more RAM built-in. IMHO, you're still better off loading the information piece by piece into the C128's RAM (from a file on a 1581 or from an SD2IEC or from an REU) until you know you have the content of a full track and once you know you have exactly the correct data and know exactly where to record it, the C128 snds it at full speed to the 1571. Making yourself dependent on having a 1581, a 1571 and a C128 is not a good idea.
|
|
|
Post by oziphantom on Sept 23, 2020 6:54:53 GMT
8K holds a 1581 sector with room for the OS and to spare, which is larger than 1541 sector right? In that worse case you need 21*256 = 5,376 but then it is GCR so 5 bits per 4 thus 5376*5/4 = 6720. Thus you have 1472 bytes left to do _wait lda CIA STX Value eor #value sta CIA inc _addr+1 bcc + inc _addr+2 dey bmi _done + ldx Address jmp _wait
you even have room to unroll it need be to get more clocks back for other things. There is nothing stopping you from downloading it to the 128 first, looking at the data you have, work out what needs to be done. Tell the 1571 what it needs, then tell the 1581 what part of the data it needs to send. The idea was the 1581 has a faster CPU ( in that the 1581 runs at 2mhz and doesn't clock stretch to 1mhz on I/O access allowing it to write/read the CIA port at 2mhz) and it has no VIC DRAM refresh cycles as it has SRAM.
However you state the 128 method alone won't work, and that you want to use either a 1581 and/or an REU so I fail to see why this dependency is a bad idea for you?
However ignoring all of this. You might find my upcoming EF128 handy. You have 1MB of ROM you can write so you can pack the G64 file in a very specific way so you know ahead of time what goes where, sort it etc. But I have a DataPort to the ROM that can handle ( at the moment its 8K of increment but this might drop if I can get another feature working and I need the space ) so to send data to the SSR port you would just do
LDA $DE04 STA $DC0C ; waste some clocks LDA $DE04 STA $DC0C ; waste some clocks LDA $DE04 STA $DC0C ....
|
|
|
Post by eslapion on Sept 23, 2020 12:00:07 GMT
8K holds a 1581 sector with room for the OS and to spare, which is larger than 1541 sector right? In that worse case you need 21*256 = 5,376 but then it is GCR so 5 bits per 4 thus 5376*5/4 = 6720. Thus you have 1472 bytes left to do _wait lda CIA STX Value eor #value sta CIA inc _addr+1 bcc + inc _addr+2 dey bmi _done + ldx Address jmp _wait you even have room to unroll it need be to get more clocks back for other things. There is nothing stopping you from downloading it to the 128 first, looking at the data you have, work out what needs to be done. Tell the 1571 what it needs, then tell the 1581 what part of the data it needs to send. The idea was the 1581 has a faster CPU ( in that the 1581 runs at 2mhz and doesn't clock stretch to 1mhz on I/O access allowing it to write/read the CIA port at 2mhz) and it has no VIC DRAM refresh cycles as it has SRAM. However you state the 128 method alone won't work, and that you want to use either a 1581 and/or an REU so I fail to see why this dependency is a bad idea for you? However ignoring all of this. You might find my upcoming EF128 handy. You have 1MB of ROM you can write so you can pack the G64 file in a very specific way so you know ahead of time what goes where, sort it etc. But I have a DataPort to the ROM that can handle ( at the moment its 8K of increment but this might drop if I can get another feature working and I need the space ) so to send data to the SSR port you would just do LDA $DE04 STA $DC0C ; waste some clocks LDA $DE04 STA $DC0C ; waste some clocks LDA $DE04 STA $DC0C .... The essence of the problem is to have a C128 dump the content of a G64 file onto a 1571 using a similar high speed serial trick as the one used by NibWrite with a XUM1541. I see absolutely nothing in your code that can get us any closer to a solution. You simply persist in only seeing the need to read sectors on a 1581 which can be one of many different types of storage device having big enough a capacity to store a file of nearly 400kBytes. In order to transfer a complete track of data at 500kbps, the whole track must be in the RAM of the device sending it and you absolutely cannot do that with a 1581 if the code necessary to parse the file (and extract a specific track's data) is in RAM. Plus it excludes to possibility of working with anything else (such as an REU or an SD2IEC, perhaps an FD-2000 or CMD-HD) which is ridiculous. Added edit: If you add 8k of RAM to a 1541 or 1571 -something you get with ether a SuperCard or a RAMBoard - then the drive has a total of 10k of RAM which is enough to hold more than 1k of code to tell the drive what to do and hold a complete track's GCR data. The 1581 has a total of 8k of RAM so from the start this is a dead end.
|
|
|
Post by oziphantom on Sept 23, 2020 14:54:23 GMT
and you keep talking about needing to parse it. So let me spell it out a little more READ from 1581 TO 128 128 makes sure this data is what it wants Send to 1581 a 1541 Track is 6,720K leaving you 1472K for code, data or whatever else, and this code only has to do the transfer to the 1571. As you won't be reading from the Disk during this transfer it doesn't matter what its OS wants. You upload the GCR Track and the "burst to 1571" code to its RAM each time you give it a new track. This code doesn't need to parse the g64 file, it only job is take code from my RAM and send it to the 1571 via burst. But the real question is what is the limit of code cycles that you have been shown, that shows a 128 is not fast enough. Is a 1581's CPU fast enough, it will only be as fast as the 1571's? the EF128 ( Easy Flash 128 ) code takes LDA $DE04 4 ; read byte from Easy Flash Port STA $DC0C 4 ; write byte to CIA SSR which means you can transfer a byte in 9 cpu cycles + CIA data rate transfer. Is this fast enough? Given a CIA can only transfer a byte in what 4 clocks per bit so 32clocks( 1Mhz clocks). Now the 128 has ample time to waste. You would be doing lda $de04 sta $dc0d ; 8 clocks ; waste 24 clocks asl $100,x ; 7 clocks make sure x is 0 or something low asl $100,x ; 7 asl $100,x ; 7
lda $00 ; 3 = 24 clocks
lda $de04 sta $dc0d ; 8 clocks ; waste 24 clocks asl $100,x ; 7 clocks make sure x is 0 or something low asl $100,x ; 7 asl $100,x ; 7 lda $00 ; 3 = 24 clocks lda $de04 sta $dc0d ; 9 clocks basically unroll a loop of 256 of these, then on the last one you have 24 clocks, to do
dey ; 2
bne + ; 2 if not taken ; need to waste 19 clocks here
jmp start ; 3
+ ; done
|
|