+jedimatt42 Posted June 6, 2020 Share Posted June 6, 2020 I'd like to add commands Force Command to list the volume names on a nanopeb, and manipulate the mounts... I see the code in the fbForth manual for manipulating the mounts, but I cannot find any data on how to list the volumes. Does anyone have specification or code that details how to list the volumes? Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted June 6, 2020 Share Posted June 6, 2020 31 minutes ago, jedimatt42 said: I'd like to add commands Force Command to list the volume names on a nanopeb, and manipulate the mounts... I see the code in the fbForth manual for manipulating the mounts, but I cannot find any data on how to list the volumes. Does anyone have specification or code that details how to list the volumes? As you probably know, the fbForth manual only knows how to temporarily mount nanoPEB/CF7+ volumes. There is code in block #69 of the current FBLOCKS for permanently mounting volumes, but you must know which volume you want to mount, which still does not answer your question. Fred Kaal (@F.G. Kaal) is the person to contact for this information. It has been more than a year since I last looked at his code and, even then, I was a little asea. I can tell you that his code uses a subset of the IDE interface to read 512-byte sectors, half of which are not used for actual TI sectors. The permanent mounts are recorded somewhere in the beginning of the CF, but I am not much help with the details. I do not think there is a table of volumes. I think that each volume’s header must be read to discover its name and format status, but my memory is not as good at my present age as it used to be. ...lee 4 1 Quote Link to comment Share on other sites More sharing options...
+InsaneMultitasker Posted June 6, 2020 Share Posted June 6, 2020 I wrote down the following in 2016 and as far as I know, never pursued it any further. I also cannot attest to its viability or accuracy at this time. ------ VDP locations for mounted volume numbers: 3FFA FFFA dsk1 3FFC FFFC dsk2 3FFE FFFE dsk3 An initialized nano volume contains DSK in the VIB -save current drive map stored in VDP [special pointers to the 3 mapped volumes] -determine max volumes by querying IDE parameters and calculating based on each volume = 1600 sector/volume x 512 byte/sector - mount volume 1 LOOP: -read volume sector 0 -if DSK is present in VIB, disk is initialized - calculate free/used sectors - display volume name - store the volume number for selection later (since we may skip uninitialized volumes) - increment volume number - copy volume into the VDP parameter and/or call mount - halt when we reach max volumes (or when mount process errors?) Restore the volume mappings in VDP 3 Quote Link to comment Share on other sites More sharing options...
+jedimatt42 Posted June 6, 2020 Author Share Posted June 6, 2020 @InsaneMultitasker Thanks, those VDP addresses can't be right, ( unless that's just pre munged for write ) But, sure, just iterate over all the volumes and 'try' to get the volume name.. I can get it in the volume record, or get an error... Genius. Quote Link to comment Share on other sites More sharing options...
+InsaneMultitasker Posted June 6, 2020 Share Posted June 6, 2020 Yea, a lot of my stuff from that period is suspect, as I've mentioned before. This intel is from another doc in the same folder. DSK1 EQU >3FFA DSK2 EQU >3FFC DSK3 EQU >3FFE The Mount command saves volume settings on the primary drive so that when the console is restarted or powered up, the settings will be restored [no idea what the 'primary drive' referred to but this does seem to agree with what Lee was saying earlier] 3 Quote Link to comment Share on other sites More sharing options...
Stuart Posted June 6, 2020 Share Posted June 6, 2020 From Jaime 14(!) years ago: "... a few bytes of sector 0 are used to keep track of mounted disks. When you run CALL MOUNT in Basic, the setting is written to sector 0. Thus, when restart the console even after turn the power off, the disk mount information is retained." 1 2 Quote Link to comment Share on other sites More sharing options...
Tursi Posted June 7, 2020 Share Posted June 7, 2020 (edited) I can't remember the exact bytes, but yes, three words in sector 0 of the first disk image are used to store the mount information. But that's only for persistence - if you don't care about persistence then changing VDP memory is enough. Make sure you don't change the mount while files are open! As for the volumes themselves, every 800k is the next volume - there's no file structure on the disk. Although disk images are only 400k in size (and they ALL are, regardless of formatted size), every other byte is discarded (data is on the even-numbered bytes). So all you do is read the sector every 800k and see if it has a TI DSK header in it. Classic99 has hardware-level emulation of the CF7 with reasonable Compact Flash simulation, so you can test a lot of it. I think I already gave you the data, but it's enabled with a [CF7] section in the configuration: [CF7] BIOS=D:\work\ti\cf7+\CF7+_DSR.bin Disk=D:\work\ti\Disks\work_cf7.bin Size=268435456 The CF7/BIOS key is the emulation enable - delete that line to turn it off. When enabled, it takes over DSK1-3. Size must be a power of 2 and you should provide the Disk file at the same specified size (it's okay if it's got no data in it). Just booting to the title page will write the first sector with the default mount information for you to see. The words are little endian, and in terms of the TI disk sector, the offsets are 21-22, 23-24, and 25-26 (edit: Fred's offsets are correct, I was misreading the dump). If you are looking on the CF card itself, every other byte is ignored, so double those values. As far as I can see it handles mounts up to 65535, although I haven't tested if it calculates the addressing correctly that high when it actually tries to access the disk - that'd be a nearly 50GB Compact Flash card. Edited June 7, 2020 by Tursi 2 2 Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted June 7, 2020 Share Posted June 7, 2020 (edited) On 6/6/2020 at 10:50 PM, Tursi said: As far as I can see it handles mounts up to 65535, although I haven't tested if it calculates the addressing correctly that high when it actually tries to access the disk - that'd be a nearly 50GB Compact Flash card. Though it does appear (from @Tursi’s post below) that the DSR’s MOUNT subprogram can, indeed, handle as many as 65535 volumes (50.00 GiB or 53.69 GB), I had used Guillaume Tello’s (@moulinaie) XMOUNT (for XB) for guidance and mistakenly thought that the DSR’s MOUNT subprogram only expects 4, right-justified decimal digits in a counted ASCII string, which would max at 9999. That many volumes would occupy 7.63 GiB, half of which, as you pointed out, is wasted space. So, it would appear that an 8 GiB card is the practical maximum. Of course, I think storage media are now rated in multiples of 103 (kB) rather than 210 (KiB), ergo 7.63 GiB, being equivalent to 8.19 GB, obviously, will not fit on an 8 GB card—so, the next size up would be needed. If that is 16 GB, nearly ¾ of it would be wasted! ...lee Edited June 8, 2020 by Lee Stewart CORRECTIONS 2 Quote Link to comment Share on other sites More sharing options...
+OLD CS1 Posted June 7, 2020 Share Posted June 7, 2020 1 hour ago, Tursi said: Classic99 has hardware-level emulation of the CF7 with reasonable Compact Flash simulation, so you can test a lot of it. I think I already gave you the data, but it's enabled with a [CF7] section in the configuration: You brilliant, beautiful bastard. 3 Quote Link to comment Share on other sites More sharing options...
F.G. Kaal Posted June 7, 2020 Share Posted June 7, 2020 (edited) For a permanent mount the volume number(s) must be written to the first sector of the CF-card: Offset 20/21: Value >AA03 Offset 22/23: Volume number DSK1 (16 bit value) Offset 24/25: Volume number DSK2 (16 bit value) Offset 26/27: Volume number DSK3 (16 bit value) But should also be set in VDP RAM while the program is running (and want to use the last mounts): >3FF8 = >AA03 >3FFA = Vol# DSK1 (1-x) >3FFC = Vol# DSK2 (1-x) >3FFE = Vol# DSK3 (1-x) (last version of Cf2k is from 2016 btw) Fred Edited June 7, 2020 by F.G. Kaal 5 2 Quote Link to comment Share on other sites More sharing options...
Tursi Posted June 7, 2020 Share Posted June 7, 2020 17 hours ago, Lee Stewart said: The DSR’s MOUNT subprogram expects 4, right-justified decimal digits in a counted ASCII string, which would max at 9999. That many volumes would occupy 7.63 GiB, half of which, as you pointed out, is wasted space. So, it would appear that an 8 GiB card is the practical maximum. Of course, I think storage media are now rated in multiples of 103 (kB) rather than 210 (KiB), ergo 7.63 GiB, being equivalent to 8.19 GB, obviously, will not fit on an 8 GB card—so, the next size up would be needed. If that is 16 GB, nearly ¾ of it would be wasted! Hmm... but I can type "CALL MOUNT(65535)" and see >FFFF written to the flash card. I tested this both in emulation and in hardware. Academic, I know, but the larger values work. 1 Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted June 8, 2020 Share Posted June 8, 2020 5 hours ago, Tursi said: Hmm... but I can type "CALL MOUNT(65535)" and see >FFFF written to the flash card. I tested this both in emulation and in hardware. Academic, I know, but the larger values work. I stand corrected. I was going strictly on the info I got from Guillaume Tello (@moulinaie). I even remembered that wrong! His XMOUNT routine only used a max of 9999. That is where I stopped reading, I guess. He even said the same thing you said: LIMITATION: 1) V value can't be more than 9999 for the XMOUNT routine and the same for DSKINF (9999 volumes with 400kb each = close to 4Gb, so a 8Gb CF card (because CF7 only uses half of the capacity) 2) V value can't be more than a word value in all cases (65535), 50Gb CF card. I only implemented the 9999 max in fbForth as Guillaume did for his XMOUNT. I suppose I should see what happens with a different ASCII string. ...lee 1 1 Quote Link to comment Share on other sites More sharing options...
WhataKowinkydink Posted June 8, 2020 Share Posted June 8, 2020 Doesn't CALL MOUNT require two inputs in the argument? i.e., CALL MOUNT(1,10) Quote Link to comment Share on other sites More sharing options...
+OLD CS1 Posted June 8, 2020 Share Posted June 8, 2020 Just for fun: CALL MOUNT works without the closing parenthesis. Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted June 8, 2020 Share Posted June 8, 2020 1 minute ago, WhataKowinkydink said: Doesn't CALL MOUNT require two inputs in the argument? i.e., CALL MOUNT(1,10) Yes. @Tursi must have been typing too fast. For it to have worked, he would have typed “CALL MOUNT(2,65535)” to mount volume #65535 as DSK2. ...lee 1 Quote Link to comment Share on other sites More sharing options...
WhataKowinkydink Posted June 8, 2020 Share Posted June 8, 2020 3 hours ago, OLD CS1 said: Just for fun: CALL MOUNT works without the closing parenthesis. Hehehe - I too discovered that - by accident Quote Link to comment Share on other sites More sharing options...
+jedimatt42 Posted June 20, 2020 Author Share Posted June 20, 2020 I have the easy stuff working... but I'd like to get into the harder part... knowing how many volumes are allowed based on the actual CF card... So... does the community have a ROM saving tool, or do I have to write one to get the nanopeb DSR over to classic99? -- @F.G. Kaal Do you have any notes on how to come up with the max Volumes? A really old version of the documentation exposed the notion that there are a number of memory mapped ports for what looks like LBA addressing extensions ... Does reading the card size require direct interaction with the compact flash card? Quote Link to comment Share on other sites More sharing options...
Stuart Posted June 20, 2020 Share Posted June 20, 2020 You can get the total number of sectors on the card (and hence calculate the number of volumes supported) from the IDE "Identify" command, which returns certain parameters from the CF card. The CF7 documentation (copy attached) talks about a CFINFO program which gets and displays this information; this program isn't mentioned in the later NanoPEB documentation, possibly because Jaime found it unreliable - he mentions that it doesn't work with Lexar CF drives. Disassembling parts of this might be useful. If you want to play around directly with IDE commands, the attached CF7 documentation also contains the CF7 IDE port addresses (you mentioned these above, not sure if you actually had a copy or not). Not sure if the same port addresses are used throughout the CF7/NanoPEB range. I designed an IDE interface for my TM990 system, notes from which might be useful: -- The tables in the upper right corner of [http://www.stuartconner.me.uk/tm990/hardware_projects/tm_990_ide_interface_sch.pdf] may help to understand use of the IDE registers and their mapping to port addresses (I use a similar set of separate read and write addresses to Jaime). -- My code for doing simple operations over the IDE interface [http://www.stuartconner.me.uk/tm990/hardware_projects/tm_990_ide_interface_source_code.pdf]. CF7 Instructions (with read and write addresses).pdf 1 1 Quote Link to comment Share on other sites More sharing options...
Tursi Posted June 21, 2020 Share Posted June 21, 2020 18 hours ago, jedimatt42 said: I have the easy stuff working... but I'd like to get into the harder part... knowing how many volumes are allowed based on the actual CF card... So... does the community have a ROM saving tool, or do I have to write one to get the nanopeb DSR over to classic99? I'll send you the copy I have. The DSR doesn't attempt to determine the size of the card nor does it validate that you are trying to write to legal sectors. It just does the write and if the card doesn't throw an error, it calls it good. The manual I have suggests to just keep formatting till it fails to see how many volumes you can use, and that ended up being more or less valid for me. 1 2 Quote Link to comment Share on other sites More sharing options...
F.G. Kaal Posted June 25, 2020 Share Posted June 25, 2020 On 6/20/2020 at 8:33 AM, jedimatt42 said: I have the easy stuff working... but I'd like to get into the harder part... knowing how many volumes are allowed based on the actual CF card... So... does the community have a ROM saving tool, or do I have to write one to get the nanopeb DSR over to classic99? -- @F.G. Kaal Do you have any notes on how to come up with the max Volumes? A really old version of the documentation exposed the notion that there are a number of memory mapped ports for what looks like LBA addressing extensions ... Does reading the card size require direct interaction with the compact flash card? Here you are ... in a mix of c99 and assembler. This is a part from Cf2k. It is wat it is mentioned in this thread before: Read the CF id. Offset 14 (long value [4 bytes]) is number of 512 byte sectors (capacity) Divide by 1600 to get the number of volumes that fits on this CF- card. Upper half of the sectors are wasted. crusrc=CF7CRU; /* Set CRU address */ cf7id(DATSCN); /* Read CF id, lcpyl(srcsec,&DATBYT[14]); /* copy long value to srcsec */ ldivs(srcsec,1600); /* divide by short value 1600 */ CfTotVol = srcsec[1]; /* number of volumes, apearently <= 255 ?? */ good thing you asked ... now I know/found why it is <= 255 in Cf2K Fred Cf2k8.c99 3 Quote Link to comment Share on other sites More sharing options...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.