|
Post by eslapion on Sept 25, 2020 15:02:40 GMT
I think the 128s port will get a 2Mhz clock. When you write to it, it will be DEXX so you will get a clock stretch, but that will only be for the 1 cycle the write actually hits on. With careful code you could align your writes such that they happen on an odd cycle to avoid the stretch on the write. With the Ultimate you are still clocked to 1mhz on the port though right? so even if the CPU can hit the VIA fast enough it can still only send in 32 1Mhz clocks. If having the CIA clocked at 1mhz isn't a problem then the Easy Flash 128 solution will get you a byte as fast as the 128's CIA can send it. But if its not fast enough then a Ultimate won't help you. The key technical information here is that the CIA can only use its high speed serial port at clock/4 while the new VIA (W65C22N) can serial signal (shift register) at up to clock/2. So a CIA clocked at 1MHz IS a problem, the W65C22N clocked at 1MHz is not. The second most important technical information is the fact the Ultimate-64 can perform a write to the 1MHz cart port at almost every individual cycle. Assuming you use a dedicated parallel to serial converter (not a VIA or CIA), in theory, you could use the dot clock to run it instead of the CPU clock and signal reliably at 4Mbps. That's 8 times faster!
|
|
|
Post by eslapion on Sept 24, 2020 12:17:42 GMT
Now here is a new information I just got.
The venerable old MOS 6522 used in the VIC-20, all old 1540/1541 drives and the 1571 are no longer in production but there is a direct drop-in replacement that is 100% compatible which is still in production. That's the W65C22N from Western Design Center - this new chip has a very interesting trick up its sleeve.
In the VIC-20 and VIC-1540 disk drive, originally, the communication was supposed to be done using an 8 bit shift register which allowed for very fast serial transfers between the computer and disk drive. Unfortunately, the shift register in the original 6522 had a bug and since the VIC-20 only used rather small programs and files, Commodore engineers resorted to using bit-banging/programmed IO which eventually was also used on the C64. This led to the C64 being reputed for very slow loading and saving performances.
In the new W65C22N, the shift register is now bug free and can be used for serial transfer speeds up to Phi2/2. This indeed means plugging a W65C22N in the cartridge port of a C128 - assuming IO is still at 1 MHz - would allow it to signal almost twice as fast as it would be using a CIA. But then there is still the lost cycles in the transition and there are still refresh cycles taken away.
Then comes along the Ultimate 64, the new incarnation of the C64 created by Gideon Zweijtzer. With the new firmware 1.34 the CPU in there can run at up to 48 MHz. I checked the cartridge port with a scope and it still runs at normal speed (0.985MHz for PAL, 1.022 MHz for NTSC) but the CPU is so much faster that it can perform a write operation at almost every standard cycle.
I studied the IO1 line activity with a small ML loop to see exactly how fast I could push out write/s using various CPU speed settings with the main setting being NTSC. These are the write/s rates I got:
Normal (1MHz): 137k/s 2 MHz: 240.6k/s (1.75x) 3 MHz: 320.9k/s (2.34x) 4-16 MHz: 481.4k/s (3.51x) 20-48 MHz: 962.7k/s (7x)
Now assuming you put a W65C22N on a cartridge, I assume it would be possible to make a NibWrite for the Ultimate-64 without the need for a 1581 to act as a buffer.
|
|
|
Post by eslapion on Sept 24, 2020 11:38:19 GMT
"a 1541 Track is 6,720K leaving you 1472K for code, data or whatever else" - that's B, not K ... That part is not true for tracks which may have a good copy protection. Some of them are listed on Peter Rittwage's web site here: c64preservation.com/dp.php?pg=protection"No the 128 runs the I/O chips at 1 mhz at all times, this is to keep drive code etc sync'd. So the CIAs in the 128 always get a 1mhz signal, so the CIA will clock it out in 32 1Mhz cycles." I perfectly understood that. I was referring to a 'realtime' scale. If the high speed serial transfer operates at 500kbps, then it transfers 1 bit every 2 uS or 8 bits in 16 uS and that's 32 cycles for the CPU of a 1571 or 1581 running at 2MHz. In the case of a XUM1541, it doesn't even use a 6502 and it runs much faster than 2 MHz so it can pretty much do whatever signaling rate it wants. In the past, I couldn't figure out why the 1571 could receive at 500kbps from the XUM1541 but the C128 was not able to signal at such rate. Your explanation concerning the CIAs running at 1 MHz in the C128 sheds light on that. Added edit: Since the CIA's maximum SRQ rate is Phi2/4, the 1571 can send or receive at 500kbps but the real limit of the C128 is really around 250kbps so the CPU speed is not even the bottleneck here. The 1571's code required to operate in the manner described (receive and record) already exists. It's what NibWrite (the version which currently exist) sends to the 1571. However in the case of the 1581, what you're saying implies the data stored in the early pages of RAM for the proper functioning of the CBM OS could be simply be overwritten as the 1581 acts as a track data buffer for the 1571 and then the 1581 is just reset once operations are complete to correct the mess you caused by writing GCR data in there. The amount of space left for the 'burst to 1571' code remains very small.
|
|
|
Post by eslapion on Sept 23, 2020 17:55:19 GMT
and you keep talking about needing to parse it. ... 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). I have asked Peter Rittwage to give me again the small example piece of code he gave me back in 2016. I lost it!! He didn't remember about it. Yes, the G64 file format has a certain complexity to it. You can't just send it to the 1571 and NibWrite doesn't do that. It sends a whole track. You seem generally correct about the timing figures, 32 cycles (of 2MHz) per byte. I am now thinking, yes the 1581 is faster for the reasons you mentioned. What if the 1581 simply acted as a track data buffer ? The operations now become as follows: 1. The C128 loads the initial part of the G64 into its RAM until it recognizes the data for the 1st track to be recorded. 2. This specific GCR data is sent to the 1581 which just stores it in RAM 3. The C128 tells the 1571 it is about to receive data to be recorded on a track and tells it what track it is so the R/W is placed at the correct location 4. The C128 tells the 1581 to send the GCR track data to the 1571 and the 1571 records it 5. The C128 goes on parsing the G64 file to get the next tracks GCR data 6. If this is the last track go to step 7, if not, go to step 2 7. Stop all drives and end operations Does that make sense ? If the 1581 is only used as an intermediate track data buffer then the code in there can be very small. This leaves enough RAM for a complete track's GCR data. Added edit: Looks like the 1581's RAM memory map says you can't fit 7692 bytes in there... unusedino.de/ec64/technical/aay/c1581/ra81main.htm:-(
|
|
|
Post by eslapion on Sept 23, 2020 16:39:42 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? ... AFAIK, this is absolutely not how NibWrite works at all. For good reasons. BTW, this is the description of the G64 file format: www.unusedino.de/ec64/technical/formats/g64.htmlIt says in the GCR level data a single track (of the highest density) can hold is between 7692 and 7928 bytes. This would leave from 264 to 500 bytes for everything else including extra code, registers, etc... Total nonsense. It simply cannot be done that way.
|
|
|
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 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 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 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 eslapion on Sept 10, 2020 22:54:54 GMT
I was a trekkie. Two weeks ago, I discovered The Expanse and I am no longer a trekkie and I don't think I ever will be again.
Having a space/sci-fi show that properly portrays the laws of gravity and inertia is something very addictive.
|
|