SatanDisk - news & history

about february of 2006 started to think about SatanDisk (internal project name is/was MMC Devil)
14. april 2006 first version of PCB drawn in Eagle (Light Edition)
27. may 2006 I realized that some additional electronics is needed for the concept of SatanDisk to improve the signal timing on the ACSI bus, the idea was to use XILINX XC9536XL as the additional electronics (a bridge between ACSI and AVR) - the bridge.
8. june 2006 The logic of the bridge was done in Verilog HDL
11. june 2006 Version of PCB with the bridge was done, electrical components ordered from local dealer

The name SatanDisk was proposed by gwEm and because I really like it, this is now the public name of this project!

14. june 2006 Schematics of SatanDisk drawn and published.

Started to write the firmware (without real HW to test it on). Low level IO functions for communication with the ST through the bridge done (not tested), also added the functions to access the SD/MMC cards from the AVRLIB  library (which is written by Pascal Stang). Some corrections were needed because AVRLIB is designed for AVR-GCC and I'm using ImageCraft C.

16. june 2006 PCB of SatanDisk is done, almost all components soldered.

Part of the IDE Devil code used for the SCSI part of SatanDisk. The FirmWare has now functions to access ACSI bridge, SD/MMC card over SPI and functions to understand SCSI (SW) protocol. Nothing is really tested, just writing without functional HW. It now takes 29% of Atmel's ATmega16 flash memory.

17. june 2006 SatanDisk prototype done - all parts soldered.

I bought a Kindston 512 MB MMC card (price was 13 Euro).

HW partially tested - AVR and MMC part should be OK (I can program the AVR through ISP). MMC card is detected, but I have some trouble with reading it's capacity using CSD register (probably error in the source-code). Reading and writing of sectors of the MMC card works OK. I'm using now 'size guessing'.

My own JTAG cable for XILINX programming finished, had some trouble with it. The problem was solved with shorting the cable between XILINX and JTAG cable. Bridge seems to work, but there's trouble with the A1 latched through bridge (seems not to work).

Almost all FW is now written (but not tested). The testing and fixing of FW will follow when I'll got the bridge (XILINX) working.

18. june 2006 Fixed the reading of CSD register, so the determining the exact size of the card works OK. But I've found out, that the 512 MB is a marketing trick (just like with HDDs) - the card has exactly 1'003'520 sectors of size 512 B, this means that the card has really 513'802'240 bytes, so it's only 490 MB of real space! So this is the reason why 'size guessing' failed to detect my card as 512 MB (it couldn't read the sectors at about 512 MB so it told me, that it's only 256 MB card).

Fixed reading of the A1 line through bridge (error in FW, not bridge) and... HEUREKA, IT WORKS! The HDDRIVER can detect SatanDisk, HDDRUTIL can partition the card . Seems like the FW I wrote without real HW works good! But I can't initialize paritions  and install HDDRIVER using HDDRUTIL - this might be because I'm doing something wrong (bad partition sizes, types, or anything), and I hope that this is not because of some bug in SatanDisk. Well, I'll check on that later...

OK, so now I know the bridge works great (it can communicate with ST with no problems in DMA and PIO mode).

19. june 2006 I added some extra debuging output from SatanDisk and it seems that the HDDRIVER has some trouble reading bootsector (sector 0) - SatanDisk returns error when trying to read sector 0. This is strange, because it has to read and write it when the HDDRUTIL does the partitioning.

But the drive can be partitioned by SCSITOOLS, the HUSHI can be installed and the ST will boot from the disk with HUSHI... I wonder what's wrong with HDDRIVER.

I also don't understand why the SCSITOOLS detects the drive as 513 MB instead of 490 MB (division by 1000 for kB and not 1024?), so it tries to reach sectors that are out of range when partitioning. HDDRIVER does this correctly.

In the debug output I also found out that the HDDRIVER tried to use the SCSI commands:

  • 0x46 - GET CONFIGURATION
  • 0x1A - MODE SENSE(6)
  • 0x5A - MODE SENSE(10)

but since I didn't implement them (they are not mandatory), the HDDRIVER must live without them.

20. june 2006 Something went wrong and... the card stopped to respond. I thought that I made some bug in the code, but it was really the card. After I bought a card reader and tested that card in it, I was completely shure that it's the card. After checking of the schematics of SatanDisk I discovered, that the problem is connected Atmel ISP programmer and the MMC card at the same time, because they use the same data lines (SPI interface of Atmel) and when the ISP programmer is connected, the MISO line gets signal at level of 5V from programmer, and that is the reason of why the card is damaged (MMC cards work at 3.3V). Well, I got a new card now .
21. june 2006 The strange thing was that HDDRUTIL can partition the card, but can't install HDDRIVER on it and HDDRIVER can't find any partitions. The SCSITOOLS can partition the card and install HUSHI which can boot without a problem. So I was trying to figure out where's the problem... And I've found out, that HDDRIVER can't read sector 0 when using ICD format of SCSI commands. And then I discovered that I was reading wrong command bytes from the ICD format of SCSI command from the internal buffer of AVR - the right index in the command field should have been 8 and 9 and I had 7 and 8 (because the ICD format adds offset of 1 to the index). So now the HDDRUTIL can initialize partitions and install the HDDRIVER...

But the HDDRIVER crashes (4 bombs) when booting the ST from SatanDisk now... Have to check on that later. But now I like HUSHI more than HDDRIVER .

(Later on)

OK, so I've kicked out the gebug info which was sent when reading and writing sectors (was slowing down a bit, also might have caused time-outs on ST) and the ST boots with HDDRIVER like a charm . Now I have to add the 'format' function (now it is only faked by returning no error) for quick card erasing, test and improve the transfer speed and the SatanDisk is finished...

22. june 2006 I've tried to copy some larger files (not too large, only 250kB) on the card and I discovered that there's some trouble with data corruption - the program failed to luch (after loading I've got TOS error #35). I'll have to check on that.

Also I tried to implement the 'format' command and it erases the drive quickly, but the HDDRUTIL behaves bit different than I expected - it should use command 'REQUEST SENSE' to check on the progress of formating, but instead it forces some sector reading and writing even if the drive tells him that it's busy because of formating...

The speed of the drive is aprox. 100kB/s - this isn't very fast, but it is still very usable (I will try to improve that).

26. june 2006 So it seems that a change should be done in the HW of SatanDisk. As I learned from one discussion about connecting MMC/SD cards to 5V logic, the voltage dividers (as used in SatanDisk HW now) between AVR and the MMC card are good only for low speeds and for high speeds there should be a 'level shifter' (like 74LVC245) used. It's not that it won't work in high-speed mode with the voltage dividers, but some errors in transfer may occur (due to capacitance of MMC card inputs and the resistor values used in the dividers there's a limit of the transfer speed - a delay created by this fictive RC combination can be calculated). So for now (for this prototype) I degraded SatanDisk speed to about 10kB/s (this will be raised back to 100kB/s or more when the level shifting will be remade in HW).

I've also found a serious bug when I was trying to do some speed tests - occasionally (about 3 sectors of 200) the data gets corrupted - it looks like one byte gets lost and the sector then contains the the 2nd byte on the 1st position, the 3rd byte on the 2nd positions, etc. I don't know where exactly I should search for this bug (FW, HW, SW) and I must do some test to find it... (if I ever will find it - as it occures occasionally, it will be hard to find).

19. july 2006 Because I'm in UK, I can't do the fixing of SatanDisk. But I've drawn a new PCB...
24. july 2006 Simple test utilities done and added on web.
25. july 2006 New version of test utilities based on NOAHDI sources instead of using BIOS function rwabs.
26. july 2006 I decided to kick out the switch from SatanDisk which was for setting the ACSI ID of SatanDisk. The new version of firmware stores the ID in the EEPROM of AVR. This ID is set to 0 by default, but can be changed using a new utility which I made (SET_ID). It's based on NOAHDI sources.

The new firmware is published (fw003) and is not tested with real HW. Also kicked out some some crap formating simulation and some optimalization of loops - kicked out the things that don't need to be in the DMA_read, DMA_write, PIO_read, PIO_write functions to speed things a bit up. Now there is a need of calling functions DMA_readBefore, DMA_readAfter, etc., before and after the use of any DMA_read and other bridge functions.
27. july 2006 The new version of final PCB without the ACSI ID switch is on the web.
12. october 2006 The bridge logic was remade, it should be a bit better, faster, safer.
15. october 2006 The new bridge was tested and it appears to work very bad - some bytes got lost in every sector, etc. I wonder where the error could be - if the DMA is too slow, or is there some trouble with the cable (shielding) or are there some glitches...

I loaded back the old bridge and old FW and tested it... With the old bridge some bytes get lost in less cases, but they still do. The test shows that with the older bridge the bytes was lost on sector 0, 7, 15, 51, 200, 212 & 306 (this is much less than in every sector with the never bridge).

30. october 2006 I took a look on the signal lines of the ACSI lines near the XILINX chip with an osciloscope and I've found out that I need some additional rezistors on the the signal lines of ACSI bus. A picture of the CS signal is here.
5. november 2006 Somehow I iterated to version of bridge which does the data transfer OK (none of 2 MB was lost or screwed), but the SatanDisk halts on some commands randomly (I don't know why yet), also some extra delays are put in the code. I will have to find the bugs, but I'm almost pissing my pants from the feeling that it's almost done .
6. november 2006 So... The SatanDisk is working fine. It still has some bugs, but this seems like the first version that is usable.
Summary:
  • working SatanDisk - no bytes lost or screwed
  • if you interupt the SatanDisk when working (when reading, writing) then the SatanDisk or the ST may keep hanging until the next next restart of ST and / or SatanDisk
  • not tested with other ST/FM/E and SD/MMC card, so it still may require lot of testing, fixing and improving
  • the data transfer speed: Write - 37 kB/s, Read - 50 kB/s - not much, but I don't know if I can improve this one
  • kicked out the switch for setting the SatanDisk's ID - now this is set via software from ST - tested and working
22. november 2006 I've done some testing and I'm still unable to get some SD cards initialized (MMC cards work fine) - the SD cards work bit differently than MMC cards in the SPI mode.

The transfer speed is aprox. 120 kB/s when reading - the previous tests were with my utility, the new speed results were from pure TOS when loading some bigger application.

I've done some changes in the code - some were bug-fixes, other were improvements. It still has some trouble with my 1040 ST - when it's turned on, it fails to read the sector 0xBD when loading the HDDRIVER. If you then reset the ST, all will work no problems (even for another 10 or more resets of ST), but the first booting after turning on causes the trouble... Will have to take a closer look at this...

23. november 2006 The new version of bridge was done and the problem of booting after turning on is fixed
14. - 17. december 2006 The new (double-sided) PCB was done, components soldered on the new PCB, tested and it's working fine. New version of bridge was done (with correct pinout for the new PCB).
30. december 2006 The interrupt driven data transfer mechanism in Atmel didn't help to improve the transfer speed (for now...).

Not-waiting-for-the-card-to-finish-the-erasing bug was fixed. Also the bug of my implementation of the SCSI-2 function READ(10) was fixed.

Tested with 1 GB MMC card and it works fine. (The card is Kingston 1GB MMC mobile (very small) card).

3. january 2007 The SD cards now work! (I was inspired by sample code from Doxygen and improved the firmware). Even if the MMC and SD cards have differences, they are working now... Tested with Panasonic 16 MB SD card and SanDisk 1 GB SD card (Ultra-II).

Fixed the invalid size of disk returned in the SCSI-2 function GET_CAPACITY (bad indexing of field: 0,1,3,4 instead of 0,1,2,3) and also the number decremented by one (GET_CAPACITY returns number of last sector, not the total number of sectors). The fixed firmware isn't on the web yet, because I found some problem which occures when the ACSI ID of SatanDisk is different than 0) - I will fix that in the following day(s).

4. january 2007 The problem with ACSI ID not booting was not in the SatanDisk, but in the HDDRIVER settings - I didn't had enabled booting from other ID than 0. Just enabled the other IDs (HDDRUTIL -> Settings -> Devices & partitions) and it works fine. The new firmware is available for the download.

Today I've tested the SatanDisk with all my ATARI computers, and it works on all of them:

  • STFM (TOS 1.02)
  • STE (TOS 2.06)
  • Mega ST1 (TOS 1.02)
  • Mega STE (TOS 2.05)