|
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 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 oziphantom on Sept 24, 2020 4:54:00 GMT
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. That is exactly what I said here:- 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. Sure at the upmost highest detail you can't keep the 1581 OS and your data in RAM at the same time. But you don't need to. When you are sending the data to the 1571 the drive will be doing nothing but running your tight send data loop(and that code should easily be under 256 bytes). So you are free to take over however you wish. Once you have done the transfer you just reset the drive so it restores back to normal and you can then load the next bit from the 1581, then install your data and code again, rinse repeat. 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. You can get up to 64 2mhz cycles but as you will need to read/write to IO you may get stretching which may eat a cycle.
|
|
|
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 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 oziphantom on Sept 25, 2020 7:48:57 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.
|
|
|
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 oziphantom on Sept 26, 2020 11:12:19 GMT
wire the SRQ and CLK line up to a data port pin on the user port. Simple cable adapter to make. Then convert each byte into a bit value, and add the clock value toggle write it to the REU twice. Then set the REU to write to a fixed location, set it to the CIA Data Port and then start the transfer. This way you will get the data output at clock/2.
|
|
|
Post by eslapion on Sept 26, 2020 13:45:30 GMT
wire the SRQ and CLK line up to a data port pin on the user port. Simple cable adapter to make. Then convert each byte into a bit value, and add the clock value toggle write it to the REU twice. Then set the REU to write to a fixed location, set it to the CIA Data Port and then start the transfer. This way you will get the data output at clock/2. That sure seems like a potent trick. The REU is unaffected by the need to perform instructions; it will just dump its content directly to the CIA's data port at the maximum speed of the bus. On a C64, disable the display when this happens and you don't even have to worry about the badlines stealing cycles. Even the refresh cycles occur during the VIC-IIs half cycles. Could you have a small example piece of code ? Added edit: There seems to be a serious problem with your suggestion; the REU's controller is designed to transfer data to/from a series of consecutive addresses in the C64/C128 and the REU's RAM. You set the start address in the C64/C128 RAM, the start address in the REU's RAM, the number of bytes to transfer and finally the direction of the transfer. It's impossible to tell the REU to transfer a series of values to one single (fixed) address.
|
|
|
Post by oziphantom on Sept 26, 2020 16:23:50 GMT
There are demos where they change $d020 per clock
see
$DF0A: ADDRESS CONTROL REGISTER Controlls the address counting during DMA. If an address is fixed, not a memory block but always the same byte addressed by the base address register is used for DMA. Bit 7: C64 ADDRESS CONTROL (1 = fix C64 address) Bit 6: REU ADDRESS CONTROL (1 = fix REU address) Bits 5..0: unused (normally all set)
So you want to set bit 7 of DF0A to keep the C64 addresses fixed.
|
|