dilwyn wrote:Dave wrote:The possibility of making more romdisqs does exist - if Tony Firshman is interested. That said, his design does use the very smallest flash chips that are near-impossible to solder by hand. I would have used a larger flash package and made the PCB 5mm wider just to make them much easier to assemble, but Tony is a design optimisation perfectionist.
How feasible would it be to make a SD card or compact flash card that plugged into the EPROM slot like a RomDisq and used adapted RomDisq drivers (with permission of course)?
Not knowing the first thing about the drivers, I have no idea if it would be easier to write new drivers from scratch.
Also, I don't know if the drivers were ever designed to go beyond the 8MB max RomDisq at the time - would a larger memory RomDisq be feasible?
The simplest thing to build on a ROM slot would be an SD card interface. I should say that there are several sub-specias of SD card and not all of them are easy to use on a QL - the ever present problem of 3.3V power supplies and logic. That being said most (perhaps 99%) of SD cards have a so-called SPI mode. The normal way a SD card works is using a nibble-serial protocol, 4 by 4 bits are read in and out, using a clock line and two control lines. In the SPI mode, the SD card becomes purely serial, with one input, one output, one clock and one select line, plus a reset, so 4 outputs, one input. Serial SPI flash is also an alternative, and these are now obtainable in 8M bytes and even higher capacity, although they come as small SO 8 pin case chips!
There are however two problems to solve.
Unless a clock is generated on the board and a substantial amount of logic in the form of a CPLD is included, it would not be even nearly as fast as a ROMdisq because the ROMdisq reads data byte-wide. Reading it serially makes the hardware trivial, 4 output pins and one input pin, but it's slow. An alternative would be a CPLD based parallel to serial conversion, most of these support very high clock rates so data transfer would be as fast as it can be on the ROM slot.
Then, there is a problem peculiar to the QL ROM slot - the ROM slot can't do writes. The ROM select line is not generated when the CPU writes to the ROM slot addresses, and there is no RDWL line to tell the hardware data should be written even if it was. The way this is normally handled is to 'write by reading' and that in turn is done by a trick. A 256 byte area of addresses is decoded out of the total 16k reserved for the ROM slot, and whenever the CPU reads from that area, a hardware latch captures which one of the 256 addresses in that area was read, i.e. the offset within that area. This is a single byte offset and it's then used as data to be written into the Flash chip in the next cycle, which provides the address to write to, in a similar manner. Because of this writes take at least twice as long as reads do. Moving the data to be written onto the address lines by means of applying an offset is done in software.
Both of these can and for the ROMdisq were solved by a small Lattice CPLD on the ROMdisq board. However, the ROMdisq uses byte read/write so parallel to serial and vice-versa conversion is not needed. What is needed is a clever driver.
The actual Flash takes quite a long time to write the data, easily 10-20 times as long as it takes to read. Also, you cna only write zeroes into the flash - once a zero is written into any bit, it cannot be returned to one except by erasing the contents, and while you can attempt to write any byte randomly, you can only erase a whole sector, which in modern large chips can be 64k in size, and this fills the entire sector with all ones (FFh).
Also, the number of writes (making 1s to 0s) to a single address is limited (the flash wears out) but with modern flash memory this is not as big a problem as it's usually between 100000 and 1000000 times, guaranteed (depending on actual technology, there are several sub-variants).
For these reasons the driver needs to be quite sophisticated and keep traxk of what goes where for the least amount of erasing, and in some cases it needs to actually read and re-write parts of sectors to optimally use them.
Largely the same is done within serial Flash ROMs, the only real difference being that it's serial. In some cases serial Flash has smaller sectors.
However, with a SD card, the actual data written already has a sector structure similar to the one the QL uses on other kinds of storage. The actual SD card is a LOT more clever than the raw flash chip. Not only does it buffer written data and then writes the whole buffer at once, it also handles error protection and correction, and all the rest that is needed to optimize what goes where to make it all appear as a random sector access medium, such as a floppy or hard drive - except for it being very quick since there are no mechanical parts to move. Using something like the Qubide or similar driver for the basis of a SD card driver is a much more logical route.
Unfortunately, there is one more problem to solve, and that's where to put the driver for this ROMdisq replacement. The ROMdisq handled this quite elegantly by using its similarity with regular ROM to store the driver within itself. Because the sector containing the driver must not be erased because this would erase the driver itself, the entire first sector of the flash was 'sacrificed' to contain it. If I recall correctly, the ROMdisq uses a directly mapped 4k 'window' at the start of the ROM slot address range for reading, and it's setu up so the 4k that appears there is the start of the driver. The first thing it does is copies itself into RAM. A page swithcihn mechanism is then used to map the entire capacity of the ROMdisq into these 4k, one 4k chunk at a time as needed. The remaining 12k of addresses are used to perform the 'write by reading' algorithm, which also includes writing which 4k block of flash is to be mapped into the initial 4k ot rhe ROM slot.
Regarding the flash chips themselves, all of them have the same pin pitch and actually are not that difficult to solder if you know the simple trick
but larger sizes migrated into a different case because all of the available pnes on the existing one got used up so no more were available for extra address lines needed to address larger capacities.
As a footnote, there is also so-called NAND flash, which is used inside flash media of all kinds from USB keys to SSDs. This is a parallel flash chip in terms of word width (usually 8 or 16 bits per chip) but it's read and written sequentially. In other words, it does not have address lines - the internal organization is sectored but the sector size is fairly small (1 to 4 k) and you actually write special data to tell it what sector you want, then either read or write all the data in the sector sequentially, just like using a floppy or hard drive. Sizes up to 1 gigabyte are available on a single chip, BUT the data error detection ad correction is left to the user, either to be implemented in software or hardware (a so-called NAND flash controller). The secotrs in this device have quite a few extra words, designed to implement forward error correction, because the flash chip is NOT guaranteed for all bits working - only that data can be properly written and read using redundant data encoding, which is why each sector has extra words. It's possible to handle all this is software (the problem of limited numbers of write cycles to the same location remains!) but it's complicated and tedious, even though it's the most cost-effective technology and the hardware interface itself is simple. An intermediate step towards something like a real media flash is a flash chip with an integrated flash controller. Currently these are somewhat expensive, but they are much easyer to use as they retain the sequential interface, but handle the data error correction and prevent superfluous writes to the same sectors. However, both of these have no provision for code storage like a normal flash chip. There is also a type of mixed flash which does, these are used in mobile phones to reduce the chip count because space is at a premium in that application, but they are not standardized yet, expensive and usually come only in very low poer versions and in packaging which is simply not solderable by a human (like uBGA etc.).
So, it seems we are stuck with ROMdisq or one could make a bus version (and dispense with the odd way data is written) and modify the ROMdisq driver to use this. I once talked with Stuart H while he was developing the ROMdisq CPLD and I know it was done using a method called schematic capture, ehre you draw a schematic of the hardware using standard blocks like TTL and CMOS chips, and the software then converts it to logic equations and compiles it into a CPLD. This design method was only available for certain Lattice CPLDs and as far as I know it's not supported any more (the programs were actually free once...). As far as the ROMdisq driver, it's Copyright Tony Tebby, so no idea if and how the sources would be available. Knowing Tony's style of programming, I wouldn't be at all surprised if the driver could cater for different flash organisations and sizes, probably through a set of define statements...
