Reverse engineering rare hardware

[Dave]

If you give me a schematic, I'll build it.

[RWAP]

There is definitely a market for disk interfaces out there.

At the moment, this is what is really holding back the QL - whilst the ZX81 and Spectrum have seen a huge resurgence in interest and new software, this has mainly been driven by the availability of disk interfaces (be it IDE interfaces, SD card or CF interfaces) and network cards - meaning that people can easily get software onto them downloaded from the internet, or a PC without the long delays and reliability issues over cassette tapes.

Even the Z88 has seen some resurgence of interest mainly due to the vastly improved OZvm emulator and porting of it to more than one operating system.

The QL market has suffered from 2 things in particular - lack of new software development, and the fact that microdrive cartridges are failing left right and centre. The traders on ebay pushing the prices up for very old software does not help - as people look at the listings and think that they may as well sell whatever QL items they have whilst the prices are extremely high (although not that much actually seems to sell !).

[afx]

And ... would be possible to emulate RomDisQ?

[Dave]

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.

[dilwyn]

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?

[Nasta]

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...

[Nasta]

If you give me a schematic, I'll build it.

If you can find out where the Trumpcard keeps it's ROM, and what addresses it uses for the WDC1772, I could do it easily. The actual RAM expansion bit is dead easy - 2x 512k x 8 SRAM, one GAL. And there would be plenty of space and free pins left in the GAL. I know SOMEONE had the TC and TCII schematic, Ron Dunnet for sure as he soldered up the remaining stock of boards once Miracle stated making the GC and then SGC. Also, I think he had the PAL chips or the equations for them...

[MemoryLaneComputing]

The simplest thing to build on a ROM slot would be an SD card interface.

This has of course already been done. The hardware designs, Verilog source for the CPLD and the QL drivers all exist as the QL-SD which I developed in collaboration with Peter Graf. In fact, the working prototypes were demonstrated at the last but one Quanta workshop. There was a version for the ROM socket and a version that plugged into one of the internal ROM sockets.

Memories it seems are rather short (not yours, Nasta, because I don't think you were active in the debate when this all happend) but the QL world seems to exist in a kind of Cyclic Temporal Anomaly, where ideas and concepts go round and round in a loop of infinitely repeating cause and effect but never make the jump to true linear time

Anyway, the reason that the QL-SD went no further was twofold:

1) There were problems with achieving reliability across all QL platforms - especially Super Gold Cards. There wasn't ever an agreement on the solution to this problem.

2) Not enough people wanted one to make it possible to recoup the initial investment in production.

Anyone interested should probably contact Rich at RWAP who is currently flying that particular flag.

Best,


Adrian

[thorsinclair]

Hi Adrian,

good to see you! I remember very well your products, prototypes and efforts and I was sad when I read that you were going to stop !

As I understand Dave is very motivated and active and Nasta and other members here are giving very good input. I hope that all this competence brought together will lead to new developments.

Money should not be the showstopper - we could try to collect the money upfront, kind of a kickstarter which could be organized her in the QL Forum.

What do you think?

Best,
T

[JonB]

I had a long chat with Rich yesterday, and the conclusion was "get a Trump Card and floppies".

Well, it's all on order. Another chunk of cash sails off into "Retro Computer Heaven"..