Jump to content
IGNORED

Force Command : kinda like command.com from 1985 (no TIPI required!)


Recommended Posts

11 hours ago, jedimatt42 said:

Oh, no I guess I don't cover the palette. Yes, I will implement this. It is my intent that it reset everything.

Yeah, reset covers everything BUT the palette, I think that was so you could run the stock system on a separate palette.

 

Link to comment
Share on other sites

  • 1 month later...

From this thread 

it looks like timestamps in ForceCommand don't work on the IDE controller... @rgjt which DSR are you using ? I assume it is Freds? 

 

And it looks like changing to the relative folder DSK1 is tripping.. can you cd to other directories? And can you show me the output of the DRIVES command, as well as LVL2 1000 , you might also try DIR 1000.DSK1. 

 

This will help me think about the cause while I revisit setting up MAME.

 

Reading the clock itself, I believe requires setting the CLOCK environment variable to IDE.TIME

 

I originally tested timestamps against something, either Myarc HFDC or IDE in MAME. 

 

 

  • Like 2
Link to comment
Share on other sites

2 hours ago, jedimatt42 said:

From this thread 

it looks like timestamps in ForceCommand don't work on the IDE controller... @rgjt which DSR are you using ? I assume it is Freds? 

 

And it looks like changing to the relative folder DSK1 is tripping.. can you cd to other directories? And can you show me the output of the DRIVES command, as well as LVL2 1000 , you might also try DIR 1000.DSK1. 

 

This will help me think about the cause while I revisit setting up MAME.

 

Reading the clock itself, I believe requires setting the CLOCK environment variable to IDE.TIME

 

I originally tested timestamps against something, either Myarc HFDC or IDE in MAME. 

 

 

Setting the CLOCK environment CLOCK=IDE.TIME did not work either. Still getting the 0-0-0 12:00AM time stamp.

I am using Fred's v15 DSR code for the IDE card.

 

I can change to other directories without any issues including on IDE2 and IDE3, just not the DSK1 directory even when tryingDIR 1000.DSK1.

The IDE card is setup at CRU >1000.

My old horizon ramdisk is setup at CRU >1200.

BTW, all of the cards in the PEB are factory TI hardware for the 32K memory expansion, FDC, and RS232.

For the console, it's the black 1981 copyright, FinalGrom99, USB keyboard and the F18A video. All of these are working perfectly.

 

See the attached screenshot for the other information that you requested.

 

BTW, I also tried MKDIR DSK2, DSK3, etc.... All generated the same type error. However, MKDIR DSK works just fine.

It appears that any number suffix with DSK causes the error. 

DSC_6155.JPG

Edited by rgjt
Additional comment on DSKx access.
  • Thanks 1
Link to comment
Share on other sites

20 minutes ago, jedimatt42 said:

Outside of Classic 99 (being hosted on a windows filesystem + additional considerations), The TI filesystem and device naming is completely case sensitive. 

You can have a case sensitive Windows file system if you want. I'm sure everything will break, but, it's an NTFS setting, not a Classic99 one ;)

 

  • Like 3
Link to comment
Share on other sites

Regardless, the file time stamp is not working on any program (9640Geneve Menu, BOOT by jj, Force Command) when listing the directory/disk contents using 80 column display with F18awith the IDE card and Fred Kaal's DSR v15.

To date, the only command that is able to read the clock is Fred's CALL IDETD statement. The time function isn't even available with DM2k. 

The IDE card's file stamping is obviously not compatible with the above programs unlike other hard drive controller cards by Myarc and Corcomp.

Hopefully, some programming wizard can figure out why the IDE card clock chip isn't compatible with these programs.  

Link to comment
Share on other sites

We hear you.

 

The DSR on the card does all the interaction with the chip. ForceCommand uses the DSR device IDE.TIME to read the clock. The timestamps are handles by the DSR when files are written, and they are returned in the 4A catalog protocol. 

 

ti99-geek.nl shows code to read this stuff from BASIC. ForceCommand uses those techniques, and they used to work. I have set up IDE in MAME and will begin debugging tonight.

 

This used to work... We'll get it working again.

  • Like 2
Link to comment
Share on other sites

That is sounding very promising indeed. Strange that it used to work and then the Murphy factor shows up out of the blue.

The time stamp feature is one of the features that I was looking forward to with the IDE card.

I appreciate all the effort and work that you have done and currently doing in your awesome force command.

 

  • Thanks 1
Link to comment
Share on other sites

3 hours ago, Tursi said:

You can have a case sensitive Windows file system if you want. I'm sure everything will break, but, it's an NTFS setting, not a Classic99 one ;)

For a fun time, enable case-sensitive filesystem on your Windows system drive.  Is a hoot.

  • Haha 1
Link to comment
Share on other sites

I quess this begs the questions, does this work on an Ide card that has one of the other rtc chip options? Was the rtc chip that Shift838 put on the cards he created, tested with Fred's dsr, to see if it worked the same as the others, to include time date stamping? Did the other rtc options properly time date stamp and show up on a listing on the idea card?

Edited by RickyDean
spelling
Link to comment
Share on other sites

48 minutes ago, RickyDean said:

I quess this begs the questions, does this work on an Ide card that has one of the other rtc chip options? Was the rtc chip that Shift838 put on the cards he created, tested with Fred's dsr, to see if it worked the same as the others, to include time date stamping? Did the other rtc options properly time date stamp and show up on a listing on the idea card?

As noted in a previous post, there are no issues with the RTC daughter board that Shift838 installs in the IDE cards.

Using Fred's DSR v15 CALL IDETD statement works perfectly every time showing the correct time and date.

Link to comment
Share on other sites

12 hours ago, jedimatt42 said:

We hear you.

 

The DSR on the card does all the interaction with the chip. ForceCommand uses the DSR device IDE.TIME to read the clock. The timestamps are handles by the DSR when files are written, and they are returned in the 4A catalog protocol. 

 

ti99-geek.nl shows code to read this stuff from BASIC. ForceCommand uses those techniques, and they used to work. I have set up IDE in MAME and will begin debugging tonight.

 

This used to work... We'll get it working again.

There's one thing that I noticed is that the sectors available and sectors used are not populated using the DIR command. This is specific to the IDE drives. The DISKNAME field is correct, but not the USED and AVAILABLE fields. These fields do get populated correctly when using DSK1 on CRU >1100 and my Horizon ramdisk (DSK3) on CRU >1200. 

You were probably aware of this bug already.

Thanks

Roger

 

 

DSC_6150.JPG

Edited by rgjt
Additional comments.
  • Thanks 1
Link to comment
Share on other sites

In a previous version of the IDE DSR, opening the catalog with record length 0 would get you the timestamp mode. in version 15 opening with record length 0 gets you the FIXED 38 mode. Explicitly asking for record length 146 gets the timestamps... 

 

So, I need to special case IDE to get the timestamps now... For all the other devices, and previously with IDE, I was able to examine the result of opening, and decide if I was getting timestamps or not the the length of record read into VDP... 

 

So, fixable.. 800163232_Screenshotfrom2021-05-2621-04-29.thumb.png.c47abc593b89ab65fede18e1b5b97296.png

 

I am still trying to figure out why CLOCK=IDE.TIME doesn't work... it works from BASIC.. I think my newer build of GCC is optimizing out some of my code since I tested this last.

Edited by jedimatt42
  • Like 2
Link to comment
Share on other sites

Well, that is the best news on this topic so far. 

Yes, IDE.TIME does work from Basic so that in itself confirmed its functionality.

I wonder why Fred changed it in the DSR version 15. There must be a good reason for it.

Thanks for the update.

Roger

Link to comment
Share on other sites

Oh, the volume size details come out as zero, because I don't know how to read the catalog record numbers if the number is greater than 9999 sectors.

 

If 'Available' ever gets below that, the number should be correct... so zero means 'more than enough' unless it actually means zero. :( 

 

I'll either have to studdy Appendix L of fbForth 2.0 manual and fix my implementation, or borrow an XMLLNK routine to let the console ROM do the work.

 

 

Link to comment
Share on other sites

18 minutes ago, rgjt said:

Well, that is the best news on this topic so far. 

Yes, IDE.TIME does work from Basic so that in itself confirmed its functionality.

I wonder why Fred changed it in the DSR version 15. There must be a good reason for it.

Thanks for the update.

Roger

 

Fred's own documentation on how to read a directory, from ti99-geek.nl: 

 

Quote

It is also a good practice not to define the record length, because when the record length is not defined, the peripherals DSR will (and should) fill this in. On some peripherals the record length is 38 bytes but when the peripheral is capable of time stamping the record length is 146.

@F.G. Kaal ??? 

  • Like 1
Link to comment
Share on other sites

10 hours ago, jedimatt42 said:

Oh, the volume size details come out as zero, because I don't know how to read the catalog record numbers if the number is greater than 9999 sectors.

 

If 'Available' ever gets below that, the number should be correct... so zero means 'more than enough' unless it actually means zero. :( 

 

I'll either have to study Appendix L of fbForth 2.0 manual and fix my implementation, or borrow an XMLLNK routine to let the console ROM do the work.

 

Maybe I can distill(?) that appendix a bit. Regarding the TI floating point (FP) number representation:

  1. First off, an eight-byte, TI FP, radix-100 number is represented in pseudo-scientific notation with a
    1. Sign bit, 
    2. Power-of-100 exponent (7 bits, excess-64 notation), and
    3. Seven-byte mantissa of radix-100 digits (0 – 99, each), normalized with centimal (radix-100) point after first digit.
  2. If the first word (MSW) is zero, the number is zero, regardless of the values of the remaining bytes.
  3. Bit 0 (MSb) is the sign bit. If set, the MSW is all that is negated (two’s complement).
  4. Remaining bits (1 – 7) of byte 0 (MSB) constitute the power-of-100 exponent in excess-64 notation, i.e., 64 is added to the actual exponent of -64 to +63 making it 0 – 127 (0 – 7Fh).
  5. Each digit (byte) of the mantissa can be 0 – 99 (0 – 63h), except that the first byte cannot be 0 (must be 1 – 99 [1 – 63h]) due to normalizing.

This means that the largest integer using all 7 bytes (centimal digits) of the mantissa is

99,999,999,999,999 (99 99 99 99 99 99 99) (hex 63 63 63 63 63 63 63)

and the exponent is 6, which in excess-64 notation = 6 + 64 = 70 (46h). This number, then, would be represented in the following 8 hex bytes as

46 63 63 63 63 63 63 63

For processing an FP number (x) known to be an integer (true for the catalog) without resorting to the console ROM’s CFI routine, you can do the following:

  1. If MSW = 0, x = 0
  2. If MSb = 1, x is negative. This probably will only should never happen for file type. , but, if it does, Note that x is negative and take the absolute value of the MSW before continuing.
  3. If positive MSW > 46h (exponent = 6), x cannot be an exact integer. Again, this should never happen because no TI “disk” is that big.
  4. Add 1 to the exponent (p) to see how many valid bytes (digits) there are. Any bytes beyond that should by 00h or the FP number is malformed. In any case, you only need to process the first p+1 bytes to form the integer.

E.g., the integer 10149 has the following FP representation in 16-bit hex words:

4201 0131 0000 0000

42h - 40h (64) = 2, so you must process 2+1=3 bytes to compose the integer—the rest ought to be zeroes as in the above example:

01 01 31 (centimal as hex) => 01 01 49 (centimal as decimal) => 10149 (decimal)

One more example to show trailing zeroes:

4301 0000 0000 0000

43h - 40h (64) = 3, so the first 3+1=4 bytes of the mantissa must be part of the integer:

01 00 00 00 (centimal) => 1000000 (decimal)

Hope I didn’t muddy the waters too much. |:)

 

...lee

Edited by Lee Stewart
CORRECTION
  • Like 3
  • Thanks 1
Link to comment
Share on other sites

12 hours ago, jedimatt42 said:

 

Fred's own documentation on how to read a directory, from ti99-geek.nl: 

 

@F.G. Kaal ??? 

 

The description of IDE DSR V04 in IDEDSRMAN.TXT shows:


V04    12/04/2006
    Added:  When opening directory with INPUT,FIXED 146 instead of just
            INPUT, FIXED [38] now possible to read file/directory
            creation timestamp and last change timestamp, sequence is:
            name, type (0-6), recordlength, size,
            creation timestamp second, minute, hour, month, day, year,
            change timestamp second, minute, hour, month, day, year.
            For a directory is change timestamp all zero.
            In order for timestamping to work the clock must be set
            with: CALL IDESC(hour,min,sec,dow,month,day,year)

 

 

The square brackets arround [38] suggests that 38 is optional so I suppose that this functionality is since 12/04/2006 and I also suppose the functionality is the same is the HFDC (because that was my big example how things work). And the short version of reading a directory is default because then the functionality is still the same as with the good old TI diskcontroller and even when using the reading directory example in TI basic in the diskcontroller manual still functions fine when using IDEx. instead of DSKx. as device name.

 

This being said then this:

 

"It is also a good practice not to define the record length, because when the record length is not defined, the peripherals DSR will (and should) fill this in. On some peripherals the record length is 38 bytes but when the peripheral is capable of time stamping the record length is 146."

 

must be a mistake in my documentation.

 

Edited by F.G. Kaal
  • Thanks 1
Link to comment
Share on other sites

I tried CALL IDESC(hour,min,sec,dow,month,day,year) as per your post and it doesn't work, bad statement.

The CALL IDESC(hour,min,sec,month,day,year) works. It appears the "dow" is not required in the above IDESC call statement.

After CALL IDESC is executed, the CALL IDETD displays the correct time and date.

 

However, to date I have not been able to get any 80 column menu program that supports the file stamp to actually display the file time stamp with the IDE card using DSR v15 that has the clock daughter board BQ4802 clock chip. 

I've tried the BOOT jj 1989 version, the Geneve9640 Boot Menu and ForceCommand.

Jedimatt42 is in the process of "fixing" this issue for his ForceCommand program.

I've given up on the BOOT jj and the Geneve9640 directory displays that apparently support the file stamp. They don't work with the IDE card DSRv15 on an actual TI99/4a system with F18A video upgrade.

 

Link to comment
Share on other sites

36 minutes ago, F.G. Kaal said:

V04    12/04/2006
    Added:  When opening directory with INPUT,FIXED 146 instead of just INPUT, FIXED [38] now possible to read file/directory creation timestamp and last change timestamp, sequence is: 

  • name, type (0-6), recordlength, size,
  • creation timestamp second, minute, hour, month, day, year,
  • change timestamp second, minute, hour, month, day, year.

For a directory is change timestamp all zero. In order for timestamping to work the clock must be set with:

CALL IDESC(hour,min,sec,dow,month,day,year)

 

I wondered why the time stamps took 108 bytes more than the 38 for name (11), type (9), record length (9) and size (9). Now I know. If anyone else was wondering, each of those numbers takes 9 bytes—1 byte for length (always 8 because each number is an 8-byte floating point number) and 8 bytes for the number. Each date, then, takes 6 x 9 = 54 bytes. Two timestamps, of course, take 108 bytes.

 

...lee

  • Like 3
Link to comment
Share on other sites

5 hours ago, F.G. Kaal said:

 

The description of IDE DSR V04 in IDEDSRMAN.TXT shows:


V04    12/04/2006
    Added:  When opening directory with INPUT,FIXED 146 instead of just
            INPUT, FIXED [38] now possible to read file/directory
            creation timestamp and last change timestamp, sequence is:
            name, type (0-6), recordlength, size,
            creation timestamp second, minute, hour, month, day, year,
            change timestamp second, minute, hour, month, day, year.
            For a directory is change timestamp all zero.
            In order for timestamping to work the clock must be set
            with: CALL IDESC(hour,min,sec,dow,month,day,year)

 

 

The square brackets arround [38] suggests that 38 is optional so I suppose that this functionality is since 12/04/2006 and I also suppose the functionality is the same is the HFDC (because that was my big example how things work). And the short version of reading a directory is default because then the functionality is still the same as with the good old TI diskcontroller and even when using the reading directory example in TI basic in the diskcontroller manual still functions fine when using IDEx. instead of DSKx. as device name.

 

This being said then this:

 

"It is also a good practice not to define the record length, because when the record length is not defined, the peripherals DSR will (and should) fill this in. On some peripherals the record length is 38 bytes but when the peripheral is capable of time stamping the record length is 146."

 

must be a mistake in my documentation.

 

That makes my day :) for 2 reasons:

 

1. It makes more sense that the default would tend toward compatibility with legacy software. 

2. Oops, I implemented TIPI to default to the 146 byte mode if 0 is requested.

 

Now I'll have to figure out if fixing TIPI will break MDOS, but that's a discussion for another time/thread.

 

In the meantime, I'll change ForceCommand to try 146, and if that errors, retry with 38...

  • Like 2
Link to comment
Share on other sites

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...