Source for IWM Chips?

[Gorgonops]

Yeah, I've tried it, and the 5.25 drive doesn't show any signs of life at all. I was also told by a couple of other people with Lirons that it wouldn't work.

You're right, I looked it into it myself and I'd come to the erroneous conclusion it could host both kinds of disk based on some poorly-worded sources.

- A CPLD or FPGA. Design #2 needs the CPLD to emulate the IWM. I don't think it's possible to emulate the IWM entirely in a microcontroller, for the same speed reason as the ROM. Design #1 also needs a CPLD to act as basic glue. There are too many signals on the Apple II bus to send them all over that 20-pin floppy cable without some kind of intermediate buffer or logic.

So, here's where my point basically is. The Apple II's bus slot has 50 pins and a DIP-package IWM has 28, but the IWM only communicates with the computer using 16 pins. Googling up a picture of a Liron card it looks like it consists of an IWM, a ROM, a 74LS245 octal bus transceiver (kind of curious why it needs that), and some NAND gates which I assume are there to decode the ROM and device address spaces. (The Apple II's slots are already partially decoded.) The IWM itself needs access to an 8 bit bidirectional data bus, four address lines (one of which also effectively acts as the read selector), a device select, a couple clocks, and a reset line.

As you note, it's pretty sketchy to try to directly follow the 1mhz signals on the Apple II's bus with perfect synchronicity by just bit-banging lines with an MCU. (We're looking at cycle times in the 250ns ballpark.) That's why you want a CPLD and, well, you have one in the floppy EMU, right? The IWM has 5 8-bit registers (state, mode, status, handshake, and data), so... again, just skimming the documentation it looks to me if your CPLD can latch those registers and keep them updated with latency less than a few microseconds emulating the IWM directly on the FloppyEMU hardware should be doable. So... *if* that's the case, then it seems to me you should be able to make a card that combines both approaches, IE, it uses the ROM and most of the rest of the schematic from the Liron card, but the interface to the FloppyEmu is at the "IWM socket" level instead of the disk port level. The one thing you lose is the ability to drive "real" disks with the card, but considering the only thing the Liron is really good for is the UniDisk 3.5" and a few vanishingly rare SmartPort hard drives would that really be a loss? Of course, this idea falls down if you don't have 16 available I/Os on the FloppyEMU's 20 pin port(*). (* Or maybe more like 14. I kind of suspect you don't really need the clock inputs, since you're not actually going to be driving the IWM's internal state machine.)

Anyway, yes, in the end the card doesn't have a much lower parts count than a replica Liron (it's just missing the IWM itself), but not needing an IWM is the whole point. The 74xxx logic is dirt cheap.

 

[bigmessowires]

You're right, I looked it into it myself and I'd come to the erroneous conclusion it could host both kinds of disk based on some poorly-worded sources.

What's strange is that the IWM should be a direct replacement for the Disk II controller card. If you took the ROM from a Disk II card and put it in the Liron, I think it would work fine as a Disk II controller.

Floppy Emu Model B has 13 uncommitted I/Os on the 20-pin disk connector, which I think is not enough to directly interface the Apple II bus. I also can't change inputs into outputs relative to the normal firmware, without risking somebody toasting their board with the wrong firmware.

So I've started looking more into designing the Liron clone (or maybe a Liron + some extra features). It's probably going to be a CPLD with a ROM, but I'm also looking at a possible single-chip solution with a Cypress PsoC, which is a 5V microcontroller with a small amount of programmable logic. I have an IWM model in Verilog about 60% written. I'm guessing it'll fit in a smallish 64-macrocell CPLD. Too bad most 5V-tolerant CPLD families are extinct, and most of the ones that remain are only 5V tolerant when they're powered, which I can't always guarantee. The gradual disappearance of 5V chips of all types is one of the biggest roadblocks for new retrocomputing designs. For CPLDs, I think Lattice ispMACH 4000ZE is the only true 5V-tolerant option remaining, but others can be used with the addition of external diodes and resistors, or external level-shifters. 

 

[NJRoadfan]

What's strange is that the IWM should be a direct replacement for the Disk II controller card. If you took the ROM from a Disk II card and put it in the Liron, I think it would work fine as a Disk II controller.

There are pictures floating around of an IWM based Disk II controller that Apple prototyped. Don't know if they actually sold though. The rumor as to why was cost of production. Ironic considering the IWM design was supposed to be cheaper to make than the discrete logic.

Photos here: http://www.retro.co.za/ccc/apple2/disks-and-controllers/

In theory, one should be able to modify a bog standard Disk II card, replacing the boot PROM with the Liron card's firmware (with ROM decoder logic), and land up with an equivalent card. Disk II cards and the parts that they are made of are very easy to source, so its worth a shot going down that route.

 

[bigmessowires]

In theory, one should be able to modify a bog standard Disk II card, replacing the boot PROM with the Liron card's firmware (with ROM decoder logic), and land up with an equivalent card. Disk II cards and the parts that they are made of are very easy to source, so its worth a shot going down that route.

I don't think that would work. The IWM can directly replace the Disk II controller's discrete logic, but it also adds some new features. Some of those features are used by the Liron firmware. So from what I've seen, the Liron card should be physically capable of functioning as a Disk II controller, but the reverse isn't possible.

 

[Gorgonops]

What's strange is that the IWM should be a direct replacement for the Disk II controller card. If you took the ROM from a Disk II card and put it in the Liron, I think it would work fine as a Disk II controller.

I suspect the reason it can't do double-duty is related to the slot/firmware architecture of the Apple II. In the IIc the IWM is mapped to the slot 6 device location (which it shares with the Disk][-compatible PROM code) but the Smartport *code* resides at a virtual slot... 5, I believe, just like the IIgs, so even though they're sharing the same IWM it *looks* like two different devices from a firmware standpoint.

It does make me wonder if it'd be possible to put a Disk][ Boot PROM on a Liron card, place it in slot 6, and then cook up a modified version of the Liron ROM code that knows the hardware is sitting in slot 6 and itself resides on a ROM-only card in Slot 5, or some other half-*55ed solution like that.

Floppy Emu Model B has 13 uncommitted I/Os on the 20-pin disk connector, which I think is not enough to directly interface the Apple II bus. I also can't change inputs into outputs relative to the normal firmware, without risking somebody toasting their board with the wrong firmware.

Yeah, the risk of melting something if it were plugged in elsewhere with the alternate firmware goes without saying.

With only 13 lines, well... you need D0-D7, which are bidirectional, and inputs A0-3. That's 12. You might not need Q3 or FCLK, so that leaves /RESET and /DEV, which puts you one over. So, yeah, I guess it's just not going to work without spinning a new version of the FloppyEMU. So never mind.

(How about making a version on a new PCB that has the 50 pin Apple II connector *and* a 20 pin header? Use a couple inputs on the MCU to detect whether the device is plugged into a slot or wired up like a stand-alone disk drive and enable the requisite mode accordingly?)

There are pictures floating around of an IWM based Disk II controller that Apple prototyped. Don't know if they actually sold though. The rumor as to why was cost of production. Ironic considering the IWM design was supposed to be cheaper to make than the discrete logic.

I'm not surprised, really. The Disk ][ controller has 8 chips verses three but they're *very* cheap parts. Apple seemed to have a problem early on when they got into ASICs with actually making them cheaper than the parts they were supposed to be replacing. (They were really late in the game on that, too. Apple didn't really start going down the ASIC road until the early 80's while, say, Commodore, was churning out weird 65xx chip variations for their machines from almost day one. Easy for them to do, of course, given they purchased MOS.)

 

[bigmessowires]

It does make me wonder if it'd be possible to put a Disk][ Boot PROM on a Liron card, place it in slot 6, and then cook up a modified version of the Liron ROM code that knows the hardware is sitting in slot 6 and itself resides on a ROM-only card in Slot 5, or some other half-*55ed solution like that.

I like that idea, and it sounds like it would work. It is kind of ugly though. I wish I understood more about the Apple II software architecture.

With only 13 lines, well... you need D0-D7, which are bidirectional, and inputs A0-3. That's 12. You might not need Q3 or FCLK, so that leaves /RESET and /DEV, which puts you one over. So, yeah, I guess it's just not going to work without spinning a new version of the FloppyEMU. So never mind.

It's worse that that. FCLK is definitely needed, and probably Q3 too. The card itself may need RW for a buffer, even if the IWM doesn't use it directly. But what really kills it is the need for the CPLD to also handle all the address decoding and glue logic for the ROM. There are some odd behaviors, like accesses to one address range automatically enable the card in another shared address range, until a third "magic" address is referenced. So that requires 8 more address lines, /IOSTROBE, /IOSELECT, plus the ROM output enable...

(How about making a version on a new PCB that has the 50 pin Apple II connector *and* a 20 pin header? Use a couple inputs on the MCU to detect whether the device is plugged into a slot or wired up like a stand-alone disk drive and enable the requisite mode accordingly?)

For longer term, that's a good idea. It might require some creative board shapes. 

I've now mostly finished my Verilog model for the IWM plus the related address decoding stuff. Using the Xilinx tools it's 59 macrocells, 40-something registers, and 37 I/Os. There are a couple of little details still to resolve, and I didn't implement all of the IWM behaviors, but only the parts I believe are used by the Liron firmware. I'm sure it has lots of bugs, but hopefully it's close enough that I can iron out the details in testing.

Now comes the part-selection step. Do I stick with XIlinx XC9500-series CPLDs, which I know fairly well, but which have burned me in the past due their asterisk next to "5V tolerant"? Should I jump to a new vendor and family I know nothing about, and use the Lattice 4000ZE that's truly 5V tolerant? Should I just stick a bunch of level shifters on the board, so that it doesn't matter if the CPLD is 5V tolerant? What about the ROM - should I try to use a 5V ROM? Would it be cheaper and/or easier to use an FPGA with more than 4K of space for ROM inside than to use an actual separate ROM chips? So many decisions to make.

What about programming - JTAG header on the board is good for the CPLD, but what about the ROM? Do I need to program it externally before soldering? Should I use a through-hole ROM in a socket so it can be removed for reprogramming? What about JTAG indirect programming of the ROM?

Will the end user be able to reprogram the CPLD and the ROM, to fix bugs and add new features? The way it's looking now, the answer is no, which is a little scary. The proposed device doesn't have a microcontroller, nor any kind of storage that new firmware could be loaded from. So it's either going to be a fixed function device, or it would require an external programmer, or return it to "the factory" (me) for reprogramming, or maybe it can be reprogrammed by software running on the Apple II.

How about the physical interface? To be a true Liron clone, it would need a female DB-19. I already cornered the world's supply of male DB-19s, and don't really want to go through all that again. A 20-pin ribbon cable connector would be fine for Floppy Emu, but without some cable hackery it wouldn't allow for connecting up a real Unidisk 3.5 or other Smartport drive.

Does a modern CPLD have enough drive current to drive the Apple II bus directly, when it's fully populated with 7 cards? The docs spend lots of time talking about fanout issues, so maybe not. Do I need a 74LS245 bus drive to isolate everything from the Apple II bus?

What kind of debugging stuff is needed? LEDs? Test points? Extra headers? 

So many questions! Even when the IWM part is largely done, the other project components are just getting started.

 

[Gorgonops]

There are some odd behaviors, like accesses to one address range automatically enable the card in another shared address range, until a third "magic" address is referenced. So that requires 8 more address lines, /IOSTROBE, /IOSELECT, plus the ROM output enable..

So... I'm sold on it not being practical to try to hook an unmodified floppy emu straight up to the Apple II bus without some glue, but I'm kind of concerned here you're overestimating how much you actually need. These behaviors you're describing are built into the Apple II, not implemented separately on each card. Here's a really useful book if you haven't seen it yet:

https://archive.org/details/understanding_the_apple_ii

It has a good chapter on how the I/O switches in the Apple II work. And, if you look at the schematic for the Disk II controller on page 242 you can see an example of how they eliminate the need to put decoding on the card. See how the boot PROM and the computer side of the controller hardware (consisting of a latch and a data register) are just sitting on D0-7 and A0-7, there's no decoding hardware? They can do that because the PROM and the controller are getting separate select signals on bus pins 1 and 41 respectively, controlled by those magic soft switches.

What this boils down to in this case is, for instance, you were replicating a straight Disk II controller you don't need your CPLD to worry about ROM select, it's already handled. (If you look at pictures of Apple II cards you'll find it's not unusual for them to have extremely minimal circuitry, just a PROM and an I/O chip. All the decoding you'd have on an S-100 or ISA card is unnecessary.)

I'm sure you already know this, I was just a little worried from your description of your IWM verilog model that you might be thinking it needs to incorporate some behavior it actually inherits from the slot controller.

 

[bigmessowires]

The Disk II controller can get away with a simpler behavior, because it only has a 256 byte ROM. That fits entirely within the pre-decoded address space for the slot, so you're right it doesn't need any extra address decoding stuff. The Liron has a 4K ROM, so it's a little bit more complicated. First, it presents a different 256 bytes in the pre-decoded address space depending on which slot it's in (which seems unnecessary to me). Second, it also uses the 2K shared address space at $C800-$CFFF. Any memory reference to its 256-byte slot space will set a latch that also enables it on the 2K shared address space. A memory reference to $CFFF clears the latch. The process is described on page 7 of this Apple doc. I've mapped out all the discrete logic on the Liron card and made a schematic of the equivalent circuit, so I'm just copying what it does. Most of the chips you can see on the Liron card are actually devoted to this behavior, and not to the disk functions. Fortunately it boils down to just a few lines of Verilog, but it does need many I/Os.

 

[Gorgonops]

Most of the chips you can see on the Liron card are actually devoted to this behavior, and not to the disk functions. Fortunately it boils down to just a few lines of Verilog, but it does need many I/Os.

Okay, that makes sense. It occurred to me after posting that if the Liron had a bigger-than-256-byte ROM and needed to use the shared space that could require extra glue. I just wasn't entirely clear if you were just posting about that or a need to fully decode the slot.

Still, one thing I'll note about that; the circuitry in the manual only amounts to a few gates. (The Liron just uses a few 74LS series parts to do it.) My suggestion about just hanging the FloppyEmu "off the IWM socket" was actually for you to literally do that, IE, you just copy the Liron schematic but wedge the Floppy Emu in in place of the IWM. I pulled up the price list for my favorite local electronics joint and it looks like the cost for all the 74LSxx on the Liron (including the '245 buffer) would be about two bucks. (This is for thru-hole, SMT is a little more expensive.) Considering you're sort of stuck making the circuit board the size of an Apple II card anyway (IE, the minimum possible size of the board is still going to be the 2.5"-ish inch length of the edge connector by at least an inch or two, bigger if you're going to use a regular 28 pin EPROM) would it *really* necessary for the CPLD to handle this part? *That* is why I was thinking you could pull it off if you only had enough lines on the FloppyEMU to replicate the IWM's bus needs.

 

[Gorgonops]

First, it presents a different 256 bytes in the pre-decoded address space depending on which slot it's in (which seems unnecessary to me).

*That* is actually pretty interesting, enough so I'm curious if there's a disassembly of its ROM anywhere. Only possible reason I can think of is if the ROM breaks Apple's rule (or guideline, anyway) of only using relative addressing so it can be slot agnostic. Maybe that's necessary for some reason for the code it maps into the extended page?

 

[bigmessowires]

You can find the Liron ROM online, I think I got it from bitsavers.org or archive.org, but there's no disassembly that I'm aware of. From my analysis, the 256 bytes for each slot are functionally identical, but they have a dozen or so hard-coded references to other addresses in that slot. I don't know why Apple did it that way, instead of writing position independent code. My guess is they already knew they needed at least 2048 + 256 bytes of ROM, which from a practical standpoint meant a 4K ROM. Given that they already had enough ROM space, it was probably just less hassle to duplicate the 256 byte section 8 times, with small changes in each one, than to remap the same 256 bytes of position independent code.

Yeah, you could probably throw some 7400-series logic on the board to do the address stuff, instead of using the CPLD for that. Maybe additional 7400-series parts could also somehow reduce the number of required off-board signals to a number that fits the existing Floppy Emu cable. One nice thing about that approach is everything could be a 5V part, without worries about level conversion or need for a voltage regulator. But I'm still not convinced that's a better solution in terms of cost, design complexity, or features. I get that you want to avoid having a CPLD on the card talk to a CPLD on the Emu, because it's kind of redundant, but I guess it doesn't bother me. It also means I can change the card's logic through firmware if I need to later, can re-use the existing Floppy Emu firmware and Liron ROM as-is, and can retain the mostly-useless but cool feature of working with a real Unidisk 3.5 or other Smartport devices. On the other hand, I'm not clear what the "win" would be from eliminating the CPLD on the card. Maybe the data rate could be faster if it's not limited to real disk I/O standards. However, that's also possible with an on-card CPLD and new firmware/ROM on both ends.

Cost probably shouldn't be the overriding concern at this point, though it's good to keep in mind. One thing that may not be obvious is the cost of assembly for a chip can often be more than the cost of the chip itself, for something like a 7400-series IC. Some places charge a certain amount per part for assembly, depending on its size and pin pitch. Others charge a fixed amount per pin, which is a little strange, but it works. Usually it's something like 1 to 4 cents per SMD pin for hobby scale or low volume production. So for a hypothetical 24-pin 7400 part that costs $0.25 in bulk, you could pay another $0.24 to $0.96 to have it soldered to the board. That puts solutions with many discrete 7400 parts at a disadvantage relative to integrated solutions using fewer chips.

 

[Gorgonops]

Yeah.

Don't get me wrong, BTW. Despite all the blather it's not like I'm against using a separate piece of programmable logic to emulate the IWM or anything like, especially if you're already well on the way to getting a working Verliog replacement put together and the cost of said logic is really only $4 or so. Mostly I was just toying devil's advocate-ishly for the concept of pulling off some Woz-ish feat of tacking the existing FloppyEMU hardware onto an Apple II slot with just spit and bailing wire. (You also seemed rather more opposed to going with the "recreate the IWM in a separate hunk of silicon" route when the thread started.) By no means is it the "right" way to do it, and in fact it comes with significant drawbacks, like the need to cook up a completely separate firmware for the FloppyEMU that reconfigures its interface pins in a manner incompatible with its normal operating mode.

Now, switching to alternative devil's advocate mode... As laid out earlier, the alternative way (that gets you out of emulating the IWM at all) is to write a new Apple firmware that directly sets up a ProDOS block device interface and uses a proprietary communication protocol between the floppy EMU and the Apple. It sounds like you've already ruled that out because you lack the knowledge on the Apple II software side, and that's a great excuse, but... just for fun I'm going to drop this direct link here because it's such an amazing piece of work:

Block Device Boot firmware for the PD8/Psuedodisk II

What's amazing about this is, if I understand it correctly, is they fit an entire ProDOS "driver" into the 256 byte slot area, no extended ROM. How they did it is basically all the ROM has in it beyond the simple "load first sector" bootloader is code to communicate with the AVR chip they used over an 8-bit I/O port. Instead of providing 6502 routines for the various ProDOS/block device primitives (which is why you need that 2K of common-address-space ROM on the Liron) it just sends ProDOS command straight across the communication bus to the MCU and lets it interpret it, so basically all the 6502 is ever doing is either waiting for the AVR or copying bytes from or writing them to a single port address. (IE, there's no GCR encoding/decoding loops, etc.) I can't help but be impressed by the genius of it.

So... what if instead of an IWM you slapped a fast UART on a card and used the existing read/write pin assignments for Disk II mode as the communication channel? (it seems this would get you around the "you could melt something with the alternate firmware" concern.) The Apple2Pi board, which interfaces a Raspberry Pi via bitbanged serial on the Pi side uses two chips, a 6551 and a single 74LS04 to interface with the Apple II bus. The one thing prominently missing from the setup is the clock generator for the 6551; that's supplied by an output on the Raspberry Pi. If you could somehow source a clock signal from either the FloppyEMU or the II's bus with a simple divider circuit then all you need to add to the hardware is your 256 byte ROM. Then it's "just" a matter of getting the FloppyEMU to directly interpret ProDOS commands received over the serial link...

... anyway, yeah, I'll shut up now.

 

[Gorgonops]

two chips, a 6551 and a single 74LS04 to interface with the Apple II bus

Of course, what's really sad, I suppose, is Jameco wants $3.95 for a 6551. So your IWM-in-a-CPLD still might not cost any more than that.

(*edit: Not that you necessarily would need to use a 6551, in principle any UART would do, or even a pair of shift registers, but still...)

 

[NJRoadfan]

The source to the ROM on the original CFFA cards is available online as a good example. Regarding ROMs, usually the 2K sized ROMs map the first 256 bytes to $Cx00-CxFF, and the whole 2K (including the same first 256 bytes) to $C800. The upper 2k on 4k ROMs is usually bank switched by writing to an I/O port on the card.

 

[bigmessowires]

Thanks for the reminder. I did take a brief look at the old CFFA ROM a while ago.

And yes, when I began this thread I was looking to avoid the need to clone the IWM. But now I've (mostly) done it, so that's that a problem.

I've finished version 1 of the IWM model, though I have no idea yet if it works. But the finished size is at an awkward boundary, and has me thinking more about part selection. Using the Xilinx tools, it fills almost all of a 72-macrocell CPLD. I didn't try other vendor tools, but I assume the compiled size would be similar. The trouble is that 64 or 72 macrocells is effectively the cut-off for "cheap" CPLDs, and if you want anything more than that it costs twice as much and has twice as many pins, which cost twice as much to assemble. 

As of this moment, the IWM model does fit the 72 MC Xilinx CPLD, so I could conceivably use that. But it's so close to full, I'd have zero wiggle room to fix bugs or add new features later. So that's probably not a great idea.

The next step up is a 128 MC CPLD. But for less than the cost of that, I could get a low-end FPGA instead, which is a lot more powerful. I'd have to add 5V level shifters everywhere for the FPGA, but the total cost should still be less than a 128 MC CPLD, so it's very tempting. It would give me more than enough headroom for the IWM design, and maybe some future extra goodies. With an FPGA, maybe a future firmware update could turn the card into a universal drive controller for 5.25 inch, 3.5 inch, and smartport drives. Or it could be reconfigured as something totally new, like the Carte Blanche.

Relatively speaking these parts are still very cheap. The low-end of the Lattice Mach XO family is about $2/each in quantities of 100. Add level shifters for another $1 or so. Maybe some extra voltage regulators or other stuff would be needed too. 

The biggest drawback to jumping to the Mach XO FPGA is that it would require a big investment in learning and tools setup. I already know the Xilinx CPLDs well, so I can bang out a new Xilinx CPLD design quickly and have confidence it'll work. I'm a little reluctant to jump ship to something new.

 

[techknight]

IF you got an FPGA, it would work more toward your benefit because then you can store the ROM internally, so the FPGA code contains the ROM as well as the decode logic, etc.. 

 

[bigmessowires]

Yes, great point, and I think that's exactly what I'm going to do. But even 4KB of simulated ROM is a lot to squeeze into a low-end FPGA like the ones I'm considering. The lowest model has no user flash or embedded block RAM, and the next model has only 2 or 3 KB. I think I can squeeze the 4KB ROM into that with some tricks.

Stepping up to the FPGA with user flash increases the cost yet again, unfortunately, but it's going to make my life so much easier for design and programming and testing. If the cost is $2 more per board, and I have lifetime sales of 100 units, that's $200 lost. But if it saves me 50 hours of time and hassle then it's totally worth $200 to me.

Another idea (that totally violates the KISS principle) is to use a serial EEPROM for storing code and things. They are dirt chip and can store a couple of megs, but they can't be directly interfaced to the Apple II bus. Even with the FPGA acting as a translator, they're not fast enough to respond to bus memory accesses in real-time. But if I'm writing my own ROM code, I can write a small routine that causes a 2 KB block to be read from EEPROM into a block RAM in the FPGA, and waits until it's ready before jumping to the address of the code that was loaded. 

I did some hunting around, and female DB-19 connectors are still fairly easy to find... for now.

 

[techknight]

Thats why you use an SPI based EEPROM to store everything, and the FPGA code reads the SPI eeprom and converts it to parallel data, Also some FPGAs require the use of an EEPROM to load its matricies and boot up. 

SPI read times are fairly fast. I dont see how it can be slower than an Apple 2 bus considering the thing barealy over a megahert? 

Worse comes to worse, if you had an FPGA with enough RAM, you could just shadow the ROM from eeprom during first power up/reset. Have the card hold the bus until its ready. 

 

[bigmessowires]

Apple II bus runs at 1 MHz, but you don't get a valid address and enable signals until about 400ns before the end of the clock cycle. Unfortunately that's not really enough time to read from SPI flash on the fly and present it as parallel data to the bus. You have to send over an address (16 bits?) and read back the result (8 bits), and there's possibly some delay between the two steps. Even if there's no delay, that's 24 bits of serial data transmission in 400ns, requiring a 60 MHz minimum SPI clock speed. Well, maybe that would be on the edge of working. If I ever get some hardware, I'll try it.

Actually I'm not sure if SPI flash is even byte addressable, or if you can only request a specific page rather than a specific byte.

My plan was more like your second suggestion of shadowing the ROM. But I can only shadow a couple of KB at a time, so it would be like bank switching, with a fetch of the new block from flash each time. I was planning to create some way that ROM code (running from non-bank-switched ROM) could poll to see if the bank switch was finished, but I like the idea of holding the bus. How do you do that -- the RDY signal? I'm not sure if that would interfere with any other timing-sensitive actions that might be happening.

Anyway, I'm getting close to a finished prototype design, using an FPGA with 8KB of block RAM that can hold 8KB of "ROM" code for the Apple II. More than enough for the Liron ROM plus whatever else I can dream up, I hope. 

 

[bigmessowires]

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. So it's close to being fast enough for direct, on-the-fly reading from the Apple II bus, but probably not quite there. Maybe a slightly faster chip or some other fudge factor would be enough to make it work.

I'm not sure the FPGA can generate an 85 MHz clock though. I think it has a nominal 133 MHz internal oscillator, which you can divide down by an integer factor, so the next slowest speed would be 66 Mhz.

One last thought - the ROM has to be bank switched no matter what, because the Apple II slot only has a 2K window of address space. So even if I had a giant parallel ROM that could provide all the data fast enough, or a super-fast SPI memory, I would still need to design some kind of bank switching mechanism anyway. That's a natural place to insert the "wait until read from external memory is complete" code, and then shadow the next 2K into FPGA internal RAM.