Source for IWM Chips?

[techknight]

Well maybe caching would help speed issues. if you can "stay ahead" of the bus and cache pages of the EEPROM it may help. I dunno, I am just pissing in the wind at this point. Im sure youll figure it out somehow. 

 

[Gorgonops]

I just looked at the datasheet, and yes the SPI flash is byte addressable. As for the speed, at the highest SPI clock rates, you need to send 24 bits of address and then 8 dummy bits (during which the internal flash array is accessed), and then 8 bits of data will be clocked out. The max clock frequency in this mode is 85 MHz, and 40 clock cycles at 85 MHz is 471 nanoseconds.

Man, 85mhz? That's fast. A while back I was playing with some cheap-and-cheerful 32k SPI SRAMs on a Propeller dev board, and those only supported a maximum of 20mhz.

Assuming the flash devices are similar to the SRAMs it might be possible you could sort of "fudge" things at a substantially lower clock rate by leveraging the sequential read feature, IE, the SRAM I was playing with allowed you to load a starting address for the first byte, and then on subsequent reads get the address auto-incremented for the next byte. (The idea I was mucking with was modifying an 8-bit computer emulator for the Propeller that normally relied on a complex parallel-interfaced RAM peripheral to instead use SPI RAM with an as-minimal-as-possible performance hit by cleverly caching a handful of pages in the Prop's hub RAM, but I quickly realized I was over my head and didn't get much further than verifying that, yes, you can shove bytes back and forth to those things.) Since even at 20mhz you should be able to read *contiguous* bytes fast enough to keep up with an 1 mhz CPU it would seem in *principle* an FPGA with a modest amount of onboard RAM could function as a controller that keeps the delays... reasonable?

Of course, "reasonable" might still not cut it with the 6502 in particular. Unlike, say, the Z-80, which has built-in a mechanism to allow the CPU to insert wait states when dealing with slow memory devices the 6502 *really* wants everything on its bus to operate synchronously. It is *possible* to halt the 6502 to wait for a slow device, but it's tricky.

 

[epooch]

I bought an old corroded Mac Classic Logic board to harvest the SWIM off of it. I was going to try to make my own Liron card for the Apple II, but I don't think that makes a lot of sense based on the drives it is limited to.  I have a question though:

It is apparent that the Apple IIe needs the Liron and 3.5" Unidisk, or the Apple II SuperDrive controller card, to read an 800K drive. Each of those solutions has its own 65C02 and RAM to be able to cache data from the drive.

I though I might just be able to slow the drive down... I know the 400K drives from the Mac use PWM to control the drives speed, and the early Mac 800K drives do not, which causes a crash on the 64K Mac ROMs. However, the later Apple 3.5" Drive, (Apple p/n A9M0106) is compatible with a 64K ROM Mac.

Anybody know how they did this? Is the Mac really controlling the speed of the drive, or is it just sending the drive speed back, and still self-regulating?

If the Mac is really controlling the drive speed, it seems like this would be a good drive to slow down to be readable by an Apple II with just an IWM chip.

 

[Gorgonops]

II know the 400K drives from the Mac use PWM to control the drives speed, and the early Mac 800K drives do not, which causes a crash on the 64K Mac ROMs. However, the later Apple 3.5" Drive, (Apple p/n A9M0106) is compatible with a 64K ROM Mac.

Anybody know how they did this? Is the Mac really controlling the speed of the drive, or is it just sending the drive speed back, and still self-regulating?

The later drive that works with 64k ROM Macs is still completely self-regulating, IE, it ignores the PWM signal entirely. However, unlike the earlier 800k drives the newer drive apparently introduces enough noise onto the "TACH" feedback line to avoid the divide-by-zero problem documented here.

The idea of slowing down the drive does theoretically have merit, as it's been done before. The floppy drive controller in the Commodore Amiga only supported "double-density" data rates and because of how it was integrated into the chipset timings upgrading it would have been "difficult". The workaround was they sold specially modified 1.44mb floppy drives that only ran at 150RPM instead of 300RPM when a high-density disk was inserted, therefore making the bit rate the same. I guess in principle you could try similar modifications on a self-regulating 800k Apple drive mechanism to make it spin at a lower speed. But of course you'll have to cook your own disk drive controller ROM to understand the resulting Frankenstein device.

As an aside, I wonder if it's even possible to spin a 400k drive (IE, the one that *is* PWM controlled) at roughly half speed. I vaguely recall that the disk speed in the Apple drives varies between about 390 to just under 600 RPM; does the PWM thus allow you to vary speed through that whole range, or is there a minimum speed at which the motor has to spin?

 

[epooch]

My thought was to half the PWM frequency and double the TACH frequency so that the 800k controller would just work.  But I am sure there will be problems with jitter, etc, running it so far out of the specifications.

I think I am better off just looking into a modern buffering FIFO (or even a  microcontroller) that can take the place of the 65C02/RAM combination.

 

[Gorgonops]

My thought was to half the PWM frequency and double the TACH frequency so that the 800k controller would just work.

Which 800k controller? The "Liron" doesn't include any ROM support for driving the "dumb" (non-Unidisk) 800k disk drive. It implements the Smartdrive protocol, which runs at the same data rate as the 170k 5 1/4" disk drives and is a block-device protocol for "intelligent" devices. The Liron *might* be physically capable of driving the 800k drives except for the speed mismatch but I'd be hesitant to guarantee it, though, because the 800k drives use what are the stepping motor control lines on the 5 1/4" drives in a different manner; so do Smartdrive devices, but what I'm not sure if any support circuitry external to the IWM is needed to handle the different protocols.

(I suppose one thing you could do is see if you can find the schematics to compare the built-in drive controller on the Apple IIc (which is essentially equivalent to Liron, IE, it supports 5 1/4" and Smartdrive) to that in the IIc+. The IIc+ has a built-in 4Mhz accelerator, which is what allows it to run the same 800k drive as the IIgs without that whole "adding a separate CPU and buffer" thing. If the wiring from the IWM to the disk port is identical between those two models then, sure, the Liron could probably be convinced to talk to a speed-braked 800k drive, but you'll need ROM code for it similar to what's in the IIc+'s ROM.)

 

[epooch]

Sorry, that was vague. I was referring to modifying the I/O to the logic and drive controller in the 800k Drive. So the Sony's 800k drive controller would just work.

Hmm, I thought the SmartPort firmware in conjunction with the IWM was used to control the Apple 3.5" drives and the 'Intelligent" 3.5 UniDisk drive. But if the Liron ROM is a sub-set of the standard Smartport firmware (which makes sense), then I agree that IIc+ or IIgs ROM code would be needed.

Now I definitely think it would be easier to have a microcontroller sitting in between, translating SmartPort to 3.5" drive control and buffering data from the 3.5" drive. At that point, it is probably easiest to emulate a 65C02 and run the actual Rom from the Unidisk or Apple SuperDrive controller. 

Anyway, thanks for the help. This is all a lot clearer to me now.

 

[Gorgonops]

Hmm, I thought the SmartPort firmware in conjunction with the IWM was used to control the Apple 3.5" drives and the 'Intelligent" 3.5 UniDisk drive. But if the Liron ROM is a sub-set of the standard Smartport firmware (which makes sense), then I agree that IIc+ or IIgs ROM code would be needed.

It's undeniable the way Apple did things is incredibly confusing, that's for sure.

So, yeah, the issue is that the "dumb" 3.5 inch drive is basically a completely different animal from Smartport. Although I think they do share *some* similarities in how handshaking is handled with the re-purposed stepper motor control lines the actual data transfer mechanics are completely different. The Unidisk logically looks about the same as a Smartport hard drive, and transfers data at a "high level" to the memory buffer that's run by that second CPU. With the dumb 3.5" drive things basically work similarly to how they do with the 5 1/4" drives. It's a separate code path.

There are of course a number of devices out there that already emulate the SmartPort protocol to fake being a Unidisk 3.5" or (more commonly) a SmartPort hard drive, so if the goal is really just to do that with a device that reads real floppy disks you could probably start there. (The firmware for a number of those projects is open source.) I would sort of question if it's really worth the trouble given floppies are dead and all.

Here's a crazy idea for you: create a SmartPort-protocol "real floppy" that instead of using an Apple drive mechanism just uses a regular 3.5" PC floppy drive. Yes, they don't have speed control... but there's another way to skin that cat. Design the floppy controller on your device to vary the data rate instead. That's how the GCR system on old 8-bit Commodore floppy drives like the 8050 worked and it's actually a substantially better design.

 

[trag]

I kind of reached the TLDR point about 3/4 of the way through...

BMOW, would some 28C64-25 help?   I have a brick of several thousand in a 32 pin PLCC in the attic...