Linards Ticmanis wrote: > David Empson wrote: > > > > The multi-bank auxiliary slot mechanism also goes against Apple's other > > memory expansion options for the 8-bit machines, which were designed > > around a standard slot with a narrow memory interface and address > > register in the I/O space, i.e. the Apple II Memory Expansion Card and > > the corresponding card for the IIc. > > So Apple did make Memory Exp. cards for the 8-bit machines beyond the > II+ Language Card and the IIe extended 80-col? Yes. The "Apple II Memory Expansion Card" works on all Apple II models with slots. It was typically supplied with 256 KB of RAM and is expandable up to 1 MB, using 256Kx1 RAM chips in sets of eight. It can act as a RAM disk in ProDOS or Pascal (you can even boot from it), and applications can also use it for data storage (via the SmartPort driver on the card); AppleWorks 1.3 is the first version which supported using this card as desktop space, if I remember right. I'm somewhat rusty on the other user-level details. I'm slightly more familiar with AE's RamFactor, which works on the same principle but has additional functionality. In particular, I forget whether Apple's card supports DOS 3.3. At the hardware level, the card uses four locations in the I/O space allocated to the slot to implement a three-byte address register and one-byte data register. Applications are not supposed to use this interface directly - the SmartPort driver on the card is the recommended method for doing data transfers between the card and main memory. The address registers are set to point to the desired location within the RAM on the card, then each read or write access to the data register will transfer a single byte between the card and the CPU, and will automatically increment the address register. Transferring a block of data can therefore be done by using a simple loop with a pointer to the main memory location and a fixed source/destination I/O address, which is faster than a typical memory copy involving both source and destination pointers. Since the card only provides access to a single byte at a time (through a single address), it isn't possible to execute code directly from the memory on the card - it has to be copied into the computer's main (or auxiliary) memory first. Random access to individual or small groups of data bytes is also ineffeficient, due to the overhead of rewriting the address register (plus the SmartPort call, if doing things properly). This is less of an issue when transferring reasonably large chunks of data. Note that since the card has a three-byte address register, it could theoretically support as much as 16 MB of RAM. (I don't know whether the upper four bits are actually implemented in hardware on Apple's card.) The RamFactor has the same basic design (with better firmware features), but it has an expansion connector which allows a 2 MB card to be piggybacked, for a total of 3 MB. In theory, the RamFactor could be extended to the full 16 MB address space. The Apple IIc memory expansion card (supported by the revision 3 and 4 firmware, and the last motherboard revision of the IIc) works on the same principles, and is 100% compatible at the software level. The Apple IIc+ memory expansion slot also works on the same basis, but I gather that the IIc memory expansion card doesn't work in the IIc+, possibly due to timing issues or some other hardware problem. -- David Empson dempson@actrix.gen.nz David Wilson wrote: > dempson@actrix.gen.nz (David Empson) writes: > >Yes. The "Apple II Memory Expansion Card" works on all Apple II models > >with slots. It was typically supplied with 256 KB of RAM and is > >expandable up to 1 MB, using 256Kx1 RAM chips in sets of eight. > > >I'm somewhat rusty on the other user-level details. I'm slightly more > >familiar with AE's RamFactor, which works on the same principle but has > >additional functionality. In particular, I forget whether Apple's card > >supports DOS 3.3. > > It does - IN#n will patch DOS to allow the card to be used as a 256KB or > 400KB disk (if I recall this correctly). Ah, good. I had a feeling that it did this, but couldn't recall how it hooked into DOS. The RamFactor lets you partition the card between at least DOS and ProDOS. > >At the hardware level, the card uses four locations in the I/O space > >allocated to the slot to implement a three-byte address register and > >one-byte data register. Applications are not supposed to use this > >interface directly - the SmartPort driver on the card is the recommended > >method for doing data transfers between the card and main memory. > > Yes. Looking at the source code (either disassembled or as listed in the > Technical Manual for the card) reveals that the Smartport firmware also > can read/write directly into Aux RAM. By "main memory", I meant "the normally addressable RAM of the computer", not specifically the motherboard RAM. I should have been clearer. > >The Apple IIc memory expansion card (supported by the revision 3 and 4 > >firmware, and the last motherboard revision of the IIc) works on the > >same principles, and is 100% compatible at the software level. > > The //c card is almost the same as the ][ card apart from the connector > and the lack of onboard firmware (the //c has the firmware on the > motherboard). I knew about the firmware. The rest makes sense - if the design works, why change it? > >The Apple IIc+ memory expansion slot also works on the same basis, but I > >gather that the IIc memory expansion card doesn't work in the IIc+, > >possibly due to timing issues or some other hardware problem. > > The code is highly optimised and I suspect that the ASIC cannot handle the > data throughput of an accellerated machine (my Transwarp //e had problems > with it as well) - the cache could improve things to the point that back > to back writes to (or reads from) the card could occur without giving it > time to increment its address registers (or perhaps perform refresh). > > One day I will try pessimizing the code and see if it works with my > Transwarp. "Pessimizing" - I like it. :-) It sounds like the same sort of problem that Apple had with AppleTalk on an accelerated IIgs, prior to System 6.0.1. - The accelerators were obeying the IIgs speed register if it was set to run in slow mode, but were going full tilt if set to fast mode. - Older versions of the AppleTalk driver were doing speed-critical timing while the CPU was set to fast mode. The combination of these two was throwing the timing out, resulting in communication errors. In 6.0.1, Apple changed the driver so that the time-critical stuff was done with the IIgs speed set to normal, which was obeyed by the accelerator. A similar solution could work in this case - if the slot is set to operate in slow mode, then the delays provided by the Zip or Transwarp (or the IIc+'s built-in Zip equivalent) should be sufficient to avoid issues with the code running too fast for the hardware. -- David Empson dempson@actrix.gen.nz