How do I use disks? Complete NOOB.

[GDMike]

I have a TI with a PEB, TIpi, SAMs 1meg card(sold by arcade shopper these days, s finalgrom,  an F18A video enhancement, still being made by a group member, and Don't forget the Classic 99 emulator and the MAME emulator. Awesome stuff.

[dabone]

On 11/6/2021 at 10:22 PM, Sinphaltimus said:

"I can write images to the disks using my greaseweazle."

 

Can you tell what format you are writing to? 

 

I think you'll get the most out of Double Sided Single Density at 40 Tracks. 

There is an 80 Track mod depending on what kind of floppy drive you have and success will depend on what kind of floppy Disk you are using.

 

 

 

I tried one SSSD disk and one DSSD disk, both read the directories fine. Both are written using a 360K drive using a greaseweazle f7 lightning plus. I just downloaded the .dsk files, and used the hcx software to convert them to hfe.

Edited November 8, 2021 by dabone

[+arcadeshopper]

I tried one SSSD disk and one DSSD disk, both read the directories fine. Both are written using a 360K drive using a greaseweazle f7 lightning plus. I just downloaded the .dsk files, and used the hcx software to convert them to hfe.

Reading the directory is not a proper test as it is entirely contained at the first part of the disk.. formatting on the ti will give you the full test of every sector

Sent from my Pixel 6 Pro using Tapatalk

[apersson850]

The TI doesn't have a DOS in the meaning of a built-in set of commands to format disks, copy files etc. There is support for some actions, but you need some kind of command module or other software to use most of the functions.

[dabone]

3 hours ago, arcadeshopper said:

Reading the directory is not a proper test as it is entirely contained at the first part of the disk.. formatting on the ti will give you the full test of every sector

Sent from my Pixel 6 Pro using Tapatalk
 

 

Here's how I tested.

 

[+Ksarul]

Good test--and your drive/controller combination is formatting both sides of the disk to give you 180K.

[Sinphaltimus]

Can you post a picture of the catalog on the disk you transferred the hfe image to? 

This way we can see what kinds of files are on it and possibly tell you how to load and run one of the programs.

[dogcow]

On 11/9/2021 at 5:58 AM, apersson850 said:

The TI doesn't have a DOS in the meaning of a built-in set of commands to format disks, copy files etc. There is support for some actions, but you need some kind of command module or other software to use most of the functions.

In the case of the Commodore 64, the 1541 disk drive provided a rudimentary OS, implemented in BASIC. E.g. LOAD “*”,8,1

 

And the Apple II was generally a matter of starting the computer with the disk inserted and it would just boot to the software.

So does the TI not have something similar to either of these? When a disk drive (PEB or standalone) was purchased for the TI, what did the documentation advise? Did it come with a disk operating system on cartridge? Or was it Wild West, where every commercial disk had a different method for loading?

 

[+Ksarul]

3 hours ago, dogcow said:

In the case of the Commodore 64, the 1541 disk drive provided a rudimentary OS, implemented in BASIC. E.g. LOAD “*”,8,1

 

And the Apple II was generally a matter of starting the computer with the disk inserted and it would just boot to the software.

So does the TI not have something similar to either of these? When a disk drive (PEB or standalone) was purchased for the TI, what did the documentation advise? Did it come with a disk operating system on cartridge? Or was it Wild West, where every commercial disk had a different method for loading?

 

The TI followed several conventions for disk use.

 

Disk management was accomplished with a disk manager program. TI produced cartridges with the disk manager software on them, but there were also generic and hardware specific (read: tuned to specific third-party hardware) disk managers as well.

 

BASIC could load applications using "OLD DSKx.yyyyyyyyyy" where x was the disk number (between 1-3 for some controllers, and 1-4 for others) and yyyyyyyyyy was the filename (note, the TI file system is case sensitive). You could also load from a specific "Disk" by specifying the disk's header name: "OLD DSK.xxxxxxxxxx.yyyyyyyyyy" where xxxxxxxxxx is the disk name and yyyyyyyyyy is the file name on the disk.

 

Lastly, when using Extended BASIC, the system would check DSK1 for a program named "LOAD" when starting BASIC. If the program was there, it would autoload it and execute the program without any required action on the part of the user.

 

I hope this helps. . .

[HOME AUTOMATION]

7 hours ago, dogcow said:

When a disk drive (PEB or standalone) was purchased for the TI, what did the documentation advise? Did it come with a disk operating system on cartridge?

I believe the DISK MANAGER II, cartridge came bundled with the TI DISK CONTROLLER.

Edited December 7, 2021 by HOME AUTOMATION

[Casey]

8 hours ago, dogcow said:

In the case of the Commodore 64, the 1541 disk drive provided a rudimentary OS, implemented in BASIC. E.g. LOAD “*”,8,1

 

And the Apple II was generally a matter of starting the computer with the disk inserted and it would just boot to the software.

So does the TI not have something similar to either of these? When a disk drive (PEB or standalone) was purchased for the TI, what did the documentation advise? Did it come with a disk operating system on cartridge? Or was it Wild West, where every commercial disk had a different method for loading?

 

Just to add to what others have said:

TI BASIC (And Extended BASIC) have commands built in for loading and saving programs and manipulating files (OPEN, DELETE, PRINT#, INPUT#, etc).  None of these commands are device specific, but the file name portion of the command indicates which device it is to be sent to (similar to a device number for the Commodore).

 

Where Commodore machines send commands to the disk drive to do things like format, copy, etc - TI uses a cartridge to do those things.  Disk Manager (and Disk Manager 2) were the official TI cartridges, but as mentioned, other vendors produced their own that worked with their hardware.

 

When you bought a disk drive for a TI, you needed to purchases a disk controller if you didn't have one (either a standalone peripheral device or a card for the PEB).   The disk controller included the Disk Manager (or Disk Manager 2) cartridge as part of the package.  I assume that would be the same with the non-TI controllers.

[+arcadeshopper]

Cataloging a disk requires a program on the TI because the disk catalog is basically a flat file. You can type one in in basic or use the cartridge that came with the disk controller. The program is in the disk controller manual

Sent from my Pixel 6 Pro using Tapatalk

[apersson850]

Common actions like formatting a disk and generic file copying are built into the disk controller's device driver. But from BASIC (the basic (pun intended!) machine), you can't reach these functions. So while you can write programs in BASIC that creates, writes and read data files for your programs, you can't just copy a file without knowing the content of it. But the software in the disk managers know how to do that, and they frequently use the provided subprograms in the disk controller to do it. That's how a disk manager, originally written for one disk controller, can operate with a completely different one. The disk controllers have different chips on board, but they do provide a common interface to the upper level.

 

In some cases, like if you run a different operating system than the one provided with the machine, the new operating system will use nothing but physical sector access to the disks. It will then create a completely different file system than the machine's proprietary one on the disk.

Edited December 8, 2021 by apersson850

[GDMike]

That's something I need to learn as well, I know little about the"Levels" when it comes to filing.

I don't know the difference of Level 0 and level 5, not sure there's a "6". And I'd like to know what that looks like as far as code.

But I think it's fascinating.

[+Lee Stewart]

1 hour ago, GDMike said:

That's something I need to learn as well, I know little about the"Levels" when it comes to filing.

I don't know the difference of Level 0 and level 5, not sure there's a "6". And I'd like to know what that looks like as far as code.

But I think it's fascinating.

 

For the TI controller, there are only three levels. Here is an excerpt from TI’s GPL Interface Specification for the 99/4 Disk Peripheral (V2.0 03-28-1983):

 

 

...lee

[HOME AUTOMATION]

2 hours ago, GDMike said:

And I'd like to know what that looks like as far as code.

These are a good read...

 

ros0.txt

ros2.txt

ros3.txt

ros4.txt

ros5.txt

ros6.txt

ros7.txt

[GDMike]

2 hours ago, HOME AUTOMATION said:

These are a good read...

 

ros0.txt

ros2.txt

ros3.txt

ros4.txt

ros5.txt

ros6.txt

ros7.txt

Good ole Gary

[GDMike]

3 hours ago, Lee Stewart said:

 

For the TI controller, there are only three levels. Here is an excerpt from TI’s GPL Interface Specification for the 99/4 Disk Peripheral (V2.0 03-28-1983):

 

 

...lee

Ahh. Ok. Level 3 is where I seem to want to be these days 

[apersson850]

What you can do depends on where you start from.

If you work in BASIC, you can only use level 3. You have to add assembly support to access the lower levels. 

If you use Pascal under the UCSD p-system, then all three levels are available from Pascal directly.

And so on, for the different available languages.

[GDMike]

5 hours ago, apersson850 said:

What you can do depends on where you start from.

If you work in BASIC, you can only use level 3. You have to add assembly support to access the lower levels. 

If you use Pascal under the UCSD p-system, then all three levels are available from Pascal directly.

And so on, for the different available languages.

Thanks for that insight and Merry Christmas to you and yours. Yes, I'll be in assy. For this one. But looks like I'll just be needing to write and read records developed in a PAB.

[+mizapf]

19 hours ago, GDMike said:

Level 3 is where I seem to want to be these days 

BTW, in contrast, in PC operating systems all files are merely streams of bytes, so there is not really a level 3 there. Home computers had this level 3, the C64 also had SEQ and REL files beside PRG.

[+OLD CS1]

30 minutes ago, mizapf said:

C64 also had SEQ and REL files beside PRG.

Yup, but aside from the RELative file, all files can be handled the same way.  I can open a USR, PRG, or SEQ file and read each byte-for-byte in the exact same way.  REL files work in addressable records, but within the records can be virtually anything.  That is, each record can be organized into fields accessible with an INPUT# statement, have spurious data which you fetch with GET#, or a mix of both if you know the structure (which you should as the programmer -- just refer to your fastidious documentation.)

[apersson850]

Somewhere, at some level, you have to handle the records, or you can't do random access of records in a file.

The native file system in the TI basically has three structures:

• PROGRAM file. A memory image, which is intended to be read and written as a whole, in one single operation.
• SEQUENTIAL file. A file consisting of a stream of records of varying lengths (VARIABLE). Since the length is different, it's impossible to calculate where a certain record is. If you want to read record 100, you have to start from the beginning and count the records. Which you don't want to do. Typically used for text files, where the line length is different for each line. The system will keep track of where you are, so you can read any number of records and be sure when you read one more, it will be following the one you read before.
• RELATIVE files. A file consisting of records, where all records are of the same size (FIXED). Thus you can easily calculate how far from the start of the file you'll find record number 100. You can read and write to any random record in any order.

Each file has a name, and occupies a certain area on the disk. The area doesn't have to be contiguous, but a file can be spread out over several clusters of sectors on the disk. Performance suffers, but flexibility is great. This system is used by BASIC, for assembly programs etc. From BASIC, this is what you can see. From assembly, you are free to handle disks as you like. You can even write your own control program for the disk controller, something I've only found useful a few times.

If you use the basic system in Forth, a disk is instead seen as a number of blocks (screens). There is no concept of named files. Forth versions implementing files do exist.

The UCSD p-system uses its own file system. Files are named and you can do random access to data files, as well as sequential access to text files. There are also special file formats for files containing program code, text, graphic images etc.

Files have to be contiguous. If you want to append data to an existing file, there must be a "hole" behind it, or it's impossible. If the next file starts right after the one you want to expand, then you have to move files around on the disk to create an open space. Very efficient, but not flexible. The operating system, which in this case does include support for file and disk operations in the part of the operating system that's known as the Filer, has special functions to help you do this.

The main reason to use the p-system is to run Pascal programs. Already on Pascal level, you can select to access files according to level 1, 2 or 3, whichever works for the application you are making.

Edited December 10, 2021 by apersson850

[RickyDean]

Okay, I've just picked up a GreaseWeazle and am trying to read my first SSSD disk. The help files are a bit cryptic. Does someone known the proper sequence I need to read a TI single density, single side? Double Density/ Double side? and what would be the best file to read out as? I want to do this part first then the same for cp/m disks. Right now I keep getting "Command Failed: GetFluxStatus: No Index", trying to see what I'm doing wrong, using the "command>gw read --drive 1 --raw --tracks="c=0-39:h=0:step=2" c:/gw/a.1.hfe". Thanks

Edited September 21, 2023 by RickyDean
additional content

[RickyDean]

I used this and got an .hfe file. "gw read --drive 1 --raw --tracks="c=0-38:h=0:step=2" c:/gw/ze.1.hfe::bitrate=500"

 

Had to use 38 because when I used 39 I got this:

 

C:\Users\Ricky\Downloads\greaseweazle-1.15.1-win64\greaseweazle-1.15.1>gw read --drive 1 --raw --tracks="c=0-39:h=0:step=2" c:/gw/ze.1.hfe::bitrate=500
Reading c=0-39:h=0:step=2 revs=3
T0.0: Raw Flux (95553 flux in 1029.80ms)
T1.0: Raw Flux (128869 flux in 996.17ms)
T2.0: Raw Flux (143070 flux in 982.41ms)
T3.0: Raw Flux (141111 flux in 986.05ms)
T4.0: Raw Flux (119056 flux in 1504.21ms)
T5.0: Raw Flux (125930 flux in 961.64ms)
T6.0: Raw Flux (124440 flux in 927.20ms)
T7.0: Raw Flux (123240 flux in 1177.22ms)
T8.0: Raw Flux (126755 flux in 896.91ms)
T9.0: Raw Flux (127027 flux in 1176.62ms)
T10.0: Raw Flux (116948 flux in 1114.98ms)
T11.0: Raw Flux (113717 flux in 1370.80ms)
T12.0: Raw Flux (119453 flux in 1116.52ms)
T13.0: Raw Flux (126335 flux in 851.14ms)
T14.0: Raw Flux (132269 flux in 839.78ms)
T15.0: Raw Flux (132655 flux in 830.53ms)
T16.0: Raw Flux (134118 flux in 821.65ms)
T17.0: Raw Flux (134244 flux in 833.99ms)
T18.0: Raw Flux (135421 flux in 864.15ms)
T19.0: Raw Flux (134334 flux in 810.74ms)
T20.0: Raw Flux (134339 flux in 804.97ms)
T21.0: Raw Flux (132956 flux in 798.60ms)
T22.0: Raw Flux (121664 flux in 754.23ms)
T23.0: Raw Flux (123178 flux in 773.71ms)
T24.0: Raw Flux (125025 flux in 785.16ms)
T25.0: Raw Flux (123459 flux in 788.59ms)
T26.0: Raw Flux (127553 flux in 786.19ms)
T27.0: Raw Flux (124375 flux in 781.49ms)
T28.0: Raw Flux (126369 flux in 772.26ms)
T29.0: Raw Flux (125907 flux in 781.03ms)
T30.0: Raw Flux (124392 flux in 776.79ms)
T31.0: Raw Flux (124830 flux in 766.45ms)
T32.0: Raw Flux (128863 flux in 757.50ms)
T33.0: Raw Flux (125019 flux in 761.93ms)
T34.0: Raw Flux (122432 flux in 756.94ms)
T35.0: Raw Flux (122202 flux in 751.85ms)
T36.0: Raw Flux (122698 flux in 740.63ms)
T37.0: Raw Flux (122909 flux in 744.22ms)
T38.0: Raw Flux (122172 flux in 748.17ms)
T39.0: Raw Flux (134462 flux in 737.87ms)
** FATAL ERROR:
HFE: Track too long to fit in image!
Are you trying to create an ED-rate image?
If so: You can't. Use another image format.