Compilation of Emails between Fred and Tim. Nov 2005. Hi Tim, Berry Harmsen had many good things to say about your programming and debugging utilities today at the Faire :) Ha, Somebody is showing off my stuff! That's good. Berry asked me to come with to Chicago this year. But I don't know what to do over there for the rest of the time. I looked at the website you mentioned at e-groups about the Disk-on-a-chip, but at first glance Idon't see any difference between this device and a compactflash card with an Ide-Cf-card converter print. Anyway the Disk-on-a-chip looks better. I added a CALL IDEDIR("IDEx.PATH") this week. Now I'm busy with a CALL IDELOAD("IDEx.PROGRAM") The load call works, the program is running, but I don't see anything readable on the computer screen. When stopping the program the system hangs. More things to add to the DSR I suppose. I don't know where to put the code savely to start the just loaded program. Fred ;-) ----- Original Message ----- From: "Insane Multitasker" To: Sent: Sunday, November 13, 2005 2:47 AM Subject: Re: IDE/ SCSI / HFDC DSR and partitioning Berry Harmsen had many good things to say about your programming and debugging utilities today at the Faire :) I meant to ask him if anyone in your user groups has experimented with hte Disk-On-Chip devices made by M-systems? 32-pin DIP devices which have varying sizes. Imbedding one in a TI or Geneve would be wonderful :) Of course, there are so many things that are being created lately. But I feel your DSR is a wonderful step in the righht direction, if only we could find cheaper, easier to configure devices for everyone! More reading of the MDOS DSR tonight... I will track down these bugs yet! Tim From: "Fred G. Kaal" To: "Insane Multitasker" Subject: Re: IDE/ SCSI / HFDC DSR and partitioning Date: Fri, 4 Nov 2005 19:25:42 +0100 Thanks, It is nice to communicate with somebody again about programming for the TI and exchanging some ideas. Apart from that fellow in germany with 8 SCSI devices connected to his TI it is maybe a good idea to invest what most (Geneve) user have connected to their SCSI card. I have for instance only one harddisk connected (SCS1) and a ZIP-drive (SCS2). I can use a second partition on the harddrive, so this will become SCS1 and SCS2 and the ZIP-drive wil be SCS3. Maybe it is handy to have a spare devicename for uuuh ... 3rd partition or second ZIP-drive or whatever, thus in Mdos to have maybe 4 SCSI devices available could be enough. Don't have to create 24 SCSI devices just to be able to never create 3 partitions on every drive. Just food for thought. Two days ago I was not so sure again about my partitioning method but when discribing the inner workings to you I feel it is a proper way to do it for the TI. I hope you will find a method and programming space to glue it into Mdos. I leave the IDE-DSR for what it is now for a week or so and work a bit on my third C99 optimizer so that I have a bit more programming space for Dm2k and Du2k. After this I try to add a CALL IDEDIR command as requested by Bill Sulivan. I don't think it is a good idea to have an update every week. regards. Fred ;-) ----- Original Message ----- From: "Insane Multitasker" To: Cc: Sent: Friday, November 04, 2005 4:19 AM Subject: Re: IDE/ SCSI / HFDC DSR and partitioning One thing I realized today is that MDOS does not have the capability to exceed three devices (SCS1,2,3) without some additional code UNLESS I am misunderstanding the DSR. The TI does not have this restriction, as each DSR is separate. I will need to redouble my efforts. You have given me more to read and re-read :) Thank you. It has been some time since I have had the opportunity to discuss DSR-related programming with anyone. Tim From: "Fred G. Kaal" To: "Insane Multitasker" Subject: Re: IDE/ SCSI / HFDC DSR and partitioning Date: Thu, 3 Nov 2005 18:44:01 +0100 Hi Tim, I will re-read this later to digest and understand. It has been a LONG week at work, and it is only Wednesday! Ugh. When I answered you're e-mail last evening also couldn't think straight about how to write a clear story. I considered your second partition option today at work. Didn't had something better to do! I even thought about no partition table at all because the size of a part is allready inclosed in the sector 0 of a partition: number of AU * AU/sector equals the number of 256 bytes sectors and divide this by two and you get the number of 512 byte sectors on a SCSI or IDE drive. So theoreticly: If a partition exists then the next partion can be created directly behind that partition. A problem with this method is: when 2 devices are attached to the controller, lets say SCS1 and SCS2 and both devices are formatted and you would like to add a second partition on the first device so that the names SCS1 and SCS2 are linked to the first device and SCSI3 would become the second device how you're going to do this? You must be able to tell the DSR that youre writing sectors outside the first partition and when the initializing is ready the new arrangment must be effectuated immediatelly so that even a third partition can be createdin on the first device. Also enough devicenames must be added to the DSR to be able to reach all the different partitions. (Only saw one person who indeed added 8 SCSI drives to his SCSI controller!) Now I try to explain how I have done it in the IDE-DSR: At the moment DU2k only allow partitions on the first device, but the DSR allows partitions on both the IDE master and slave drive (can't check if it works properly because I don't have enough hardware). Internally the DSR is filling in partition parameters (size, offset, initialized flag, and physical [or hardware] device number). Maximum number of IDE devices is 4 for now. The power-up routines reads sector 0 of the first device and checks if it is an ordinary sector 0, or that this sector contains a partition table. If it is an ordinary sector 0, this device is IDE1 whith a size of MAXAU * AU/SEC / 2 in 512 bytes sectors and an offset of 0x0000 on the disk. I'm calculating in 512 bytes sectors here because in this way I didn't have to change any code in the DSR itself but only had to add the offset and check the bounderies at the moment a 'real' sector number is determined. If sector 0 contains a partitiontable the first partition goes to IDE1, the second to IDE2, the third to IDE3 and the fourth to IDE4. If not all devicenames are used, the DSR does the same check for the second possible IDE device. For every partition the sector 0 is checked to see if that partition is initialized. If so a flag is set in this partitions parameter table. Now the DSR is able to quickly determine if a partition can be used or that the DSR can return an error 6 immediatelly. At this stage the IDE devices can be used and there is no confusion for the DSR what devicename belongs to what partition on what device. When reading and / or writing sectors, which is also allowed for uninitialized partitions, the DSR also takes the partition offset and partitions size into account. The initialize routine in Du2k only have to be changed a little bit for this method. For both SCSI and IDE devices the drive identification is read from the device via the DSR. In the drive identification the maximum number of 512 byte sectors is recorded. This number of sectors is OK to use if no partitions are involved. In the case of an IDE device the DSR also looks at the partition parameters read from the physical drive. If the drive parameters are asked for the DSR also adds the partition size and offset to the drive identification record (for ide this could be at offset 128 and is 8 bytes long). If there is no partition this 8 bytes are zeroed. Now, when Du2k determines the maximum number of available sectors (512) it first checks the 4 byte number at offset 132 (partition size) and if this is zero the number of sectors of the drive identification is used as in the normal way. The second trick added in the IDE-DSR was a method of writing sectors outside a partition. The first partition always starts at the first sector (512) or second TI-style sector (256). When a partition must be added or removed from the partition table Du2k must be able to read from and write to the real sector 0. To accomplish this the most significant bit is set in the sector number. When this bit is set, the DSR clears the partition offset and maximize the partition size and resets the most significant bit in the sector number. This sectornumber is now directly used for reading or writing a sector. This trick works for an IDE device because only an 28 bit sectornumber can be used so a maximum drive size is 137Gb of which a can use now 1Gb devided in 4 partitions of 260Mb. btw: FAT32 is actually FAT28! After fooling arround with the partitiontable, Du2k calls the powerup routine again so that the new table is used for determing the new IDE device list. This is done because it was very confusing when creating or adding a new partition and you are only able to initialize this partition after a reset of the computer. To answer to your question "can I use Du2k to create partitions on a SCSI device" The first thing Du2k does is a ROMPAGE! When I remove this and do the same tricks as describeb above for the SCSI DSR it must be possible. I also want to add this to the SCSI DSR so that it also works on the TI99! but I don't think I found/hvae the right SCSI source code to create a prom or code for the flash loader. Your partition idea sounds do-able on the Geneve, though the partitioning would need to be written outside of the level 1/2/3 routines and directly in the read/write code. The IDE 1/2/3 routines also doesn't know anything about partitions. When a DSR call is made the DSR determines what to do, calls the right 1/2/3 routine and a sectornumber (256 bytes TI-style) is calculated/determined as usual. Every sector (TI-style) the IDE-DSR holds, has a 6 byte parameter field which tells the sectorread and sectorwrite routine if this TI-style sector is the lower or upper half of a 512 byte sector and the offset of this 512 byte sector. The moment the TI-style sectornumber is converted to the 512byte sectornumber, the partition offset is added and a range check is done. Hope this story is more clearer than the previous one. SCSI DSR question/remark: Does the SCSI DSR in MDOS also here and there confuses the number sectors allocated with the number of AU's allocated? This behaviour can be seen in action if a SCSI device has more then 1 sector per allocation unit, the EOF offset is > 0 and not the last sector of an AU is used. When copying a file like this from SCSI to i.e. a floppy the file on the floppy gets to many sectors. Also when viewing the contents of this file with Dm2k this behaviour takes place. This is something the read-file-info (0x24) does! Also one of the reasons why I want to get my hands on the SCSI-DSR! I wish this was holiday time! Me to! At the moment the job at home is more interesting than what I do at work! regards, Fred ;-) Hi Tim, Yes I did. Just finished it this week and about to release in a few days. Added code to Du2k to create a maximum of 4 partitions on an IDE drive and changed the powerup routine of the DSR and recognizes a VIB (volume information block) or a PT (partition table). Partition table is at sector 0 with an unique name, an ID of 'PT' and a number of allocation units of >FFFF witch is an illegal value for a normal drive (maximum AU is normally >F800). See enclosed partitiontable.txt. At work I had to create FAT16 and FAT32 code for reading CF-cards in OS9 and also had to find out how partition tables work on a PeeCee and because this was not to difficult I added it to my IDE-DSR. The IDE-DSR now recognizes a device with and without a partition table. Check if the device and/or what partitions are initialized and if so allows the normal functions (open, close, read, write, load, save etc). There was a pittfall with reading and writing sectors. When creating the PT I had to write to sector 0 and 1 of the physical disk , when reading or writing to a device (IDE1 throught IDE4) when i.e. initializing I had to write to sector 0 through 31 of a logical disk. For this trick a set the most significant bit of the 32bit sector number which then means reading from or writing to sectors of the physical disk.And ofcourse reading and writing of sectors of an uninitialized disk must always be possible (second pittfall). I choose sector 0 for the PT after a lot of consideration. Also thought about using some bytes in the normal sector 0 to define another partition but I thought that this is the best solution. Partitions now doesn't know about each other and the DSR have to sort things out. Because of the standard sector size of 512 bytes on a IDE device al partitions start at an even sector of 256 bytes which is always at the beginning of an 512 bytes sector. The DSR also checkes that reading and writing sectors stays in the right partition. The last thing I would like to add to the IDE-DSR is to use a minimum of 2 sectors (256 bytes) per allocation unit so that for sectors with file-data the DSR doesn't have to read lower or upper parts of 512 bytes sectors. I suppose it will give the DSR some better performance.