Software that requires 2 floppy disks?

[jrhodes]

Is there a list of software (games or otherwise) that needs 2 floppy disks?

Please note, i am not talking about software designed for 2 (or more) floppy drives, like i.e. a disk copier that copies from DSK1. to DSK2.

No, i mean software that is spread out over multiple disks.

Like the game "Who's Behind The Mexican UFO's?", which is on two floppy disks, you actually need to change disks at one point in the game to continue.

In fact, that is the only example i can come up with...

Multi-disk software just wasn't done on the TI very much, huh?

[HOME AUTOMATION]

...seems like disk size/density, used to factor into that.

[jrhodes]

So that one single game is really the only thing for TI that needed 2 floppies?

Actually, aside from the bookmark file (which is identical on both disks), i think you can dump all the files together from both disks into a directory and play it just fine from classic99/TIPI.

Wow, i was really hoping there was at least something out there, but looks like there just isn't.

Edited July 21, 2020 by jrhodes

[+FarmerPotato]

53 minutes ago, jrhodes said:

Is there a list of software (games or otherwise) that needs 2 floppy disks?

Please note, i am not talking about software designed for 2 (or more) floppy drives, like i.e. a disk copier that copies from DSK1. to DSK2.

No, i mean software that is spread out over multiple disks.

Like the game "Who's Behind The Mexican UFO's?", which is on two floppy disks, you actually need to change disks at one point in the game to continue.

In fact, that is the only example i can come up with...

Multi-disk software just wasn't done on the TI very much, huh?

All the InfoCom games. The interpreter and first game file were loaded into memory from disk 1. The bigger, random access game file was on disk 2.

 

[pixelpedant]

Adamantyr's (as yet unreleased) Realms of Antiquity is distributed across three disks by default, so that's one example (or soon-to-be example).  And it seems like multiple volumes would be inherently required on a NanoPEB, given that device's (in this case insufficient) 400KB volumes.  Though presumably very few will ever use 1MB SAMS with a NanoPEB. 

[Ed in SoDak]

Legends and its sequel, as shipped on two SSSD disks.

 

Probably several BBS programs worked best on a multi-disk setup.

Edited July 21, 2020 by Ed in SoDak

[apersson850]

It's not a single program, but rather an operating system and a development suite. But the p-system runs with one ROM-disk (on the p-code card) and separate disks for Editor, Filer, Compiler, Assembler and Linker. But only disk space may prevent you from placing them all on one disk, so it's not a system that must have multiple floppies.

[atrax27407]

Infocom games can be loaded from a single disk if it is of large enough capacity. It must be DSDD.

[+FarmerPotato]

10 hours ago, Ed in SoDak said:

Legends and its sequel, as shipped on two SSSD disks.

 

Probably several BBS programs worked best on a multi-disk setup.

I think BBS would be in the category of "requires 2 drives". At least!

 

Though, Techie (Monty Schmidt) and TICOMM (John Clulow), at least in the versions I saw, worked fine with one disk.

 

My TI-Net BBS software assumed 2 drives, DSSD (TI Controller).  It came on 2 DSSD disks.

 

The program would be in drive 1 (it would run game programs, so it had to re-load the main BBS after that). Messages and other files could be on either drive.  You could also move the assembly routines and LOAD to their own disk, because they weren't needed again after the first startup. (saves 100 sectors of DIS/FIX 80 uncompressed object code.. later I used Barry Boone's SYSTEX to squish that down.)

 

Matt Storm and I both had the CorComp mini-expansion system with 2 drives, so DSDD. His BBS ran on that hardware, but I ran my BBS for a while with a P-Box, TI disk controller and 2 half-heights, I think.

 

 

[+FarmerPotato]

I remember a lot of Apple ][ graphical adventure games that required 2 or more disks. That doubled the possible images. You'd switch the disk at one point into the game, but switch back when you returned to the early areas.  One that I recall was Mask of the Sun (Apple ][) which had a long sequence of scenes that played while Raoul was driving your car around a mountain road. They had plenty of space, so why not. 

 

But other than Return to Pirate's Isle, I don't know of any for the TI.

 

Does Tunnels of Doom count? We had cartridge ROM/GROM unlike other micros.

 

 

[+Ksarul]

There were a lot of things that used multiple disks--but in most cases, that was because they were being distributed on SSSD media. Most of the time you could combine them into one disk if you had a DD controller. There were exceptions though--the graphics files for a lot of the graphics utilities really needed to be on one or more disks, separate from the program disk. Also, things like FORTRAN, TI BASE, The Editor/Assembler, and other utility programs strongly suggested your program disk be separate from your data disk to ensure that you didn't accidentally destroy your main disk. Didn't Asgard's Spell Checker require several floppies or a hard disk to work right?

[Omega-TI]

There is one I used to use all the time that required three drives...

  

DSK1. The program itself and some associated files.

DSK2. Graphics required by the program.

DSK3. Logging of data generated by the program.

 

IIRC it ran in Extended BASIC and also needed the CorComp Triple Tech Card.

[+FarmerPotato]

I used Draw-A-Bit on a school project, to draw bitmap screens. It had a lot of overlay code on its disk so you couldn't remove it. Since each save file took 49 sectors (bitmap mode) you needed a second disk for saves. But it was distributed on 1 SSSD, I think. Maybe the printing program was sold separately, but it would fit on Disk 1.

 

TI-Artist... if you wanted fonts handy, there was no upper limit! I resorted to having TI Artist in one drive, and swap a fonts disk and my save disk in the other. I think I settled on 1 or 2 fonts and just copied those to my save disk.  My friends and I spent a LOT of time designing labels for floppy disks and booklets. It took years to use up a box of 250 Avery disk labels, but it finally happened.

 

[apersson850]

Thinking about it, I've actually used a program that worked best using four disks, although it could run with three.

This was a disk catalog program, capable of showing disk catalogs for several disks.

The idea was that you put a disk in a drive, and gave a command to read the disk. If the name of the disk wasn't recognized by the program, it would be assigned a unique number. This number was stored in an unused part of sector 0, together with a special "number valid" marker. A date code for the last time read was also stored.

Then the file catalog was read from the disk. File name, type and size were stored in a database, together with a reference to which disk ID the files were stored on. A separate data base of the disk numbers and names was also stored. An index data base, by which the files could be referenced in alphabetical order was also created and stored.

After reading a number of disks, the program would allow you to list the files on the disk, without the disk actually being present, list all disks containing a certain file name or DIS/VAR 80 files or whatever you searched for. Very handy if you remembered a certain file name, but couldn't remember on which disk it resided. You could re-read the same disk again, in which case the data base entries were updated if anything had changed on the disk.

General library files, character definitions and such was on disk one, the program with its tailor-made libraries on the second, the disk/file database on a third and the disk to be read, when cataloged, was in the fourth drive. But technically, there was nothing preventing all code files to be on the one and same disk.

That's the  most disk intensive program I had.

[Omega-TI]

A program like that would awesome for the TIPI.  Imagine running a program that would scan all subdirectories, the programs within each subdirectory and send a listing to Pi.PIO.  If any duplicates of the same size are found the program could put an asterisk in the first column of the printout next to the filename.

[apersson850]

It was very handy when I had 100+ diskettes and sometimes dim memories about where a file was. Unfortunately it was a bit beyond the capacity of the TI I had at that time. If I have had a RAMdisk large enough to hold the databases, then I think it would have been feasible. Less than 50 disks worked fine, but beyond 100 it was just too slow.

Note that there was also a search engine. It was not just possible to produce a printout.

Edited July 21, 2020 by apersson850

[Ed in SoDak]

I created a three-disk setup using Funnelweb as the primary disk. I set up its custom menus to point to the various programs. Instead of DSK1, DSK2, DSK3 I used their disknames, i.e. DSK.FW4.DU, DSK.XB.LOAD, etc. It would find them no matter which drive they were in.

 

 

[Ed in SoDak]

3 hours ago, apersson850 said:

...This was a disk catalog program, capable of showing disk catalogs for several disks.

 

I rewrote an XB LOAD program to help create a master database of all my floppies. I included room for a unique disk number, its location, category and description of each disk and file on the disk. It would optionally print a running disk catalog as you read each floppy and appended the catalogs to a pair of DV-80 files. Using TI-Base, I created a batch file that read in the DV-80 so it could be sorted or searched.

 

Too bad it didn't work correctly in emulation using MacV9T9 nor would it print, but I was able to modify it so at least the DV80 lister worked. I need to see if it's plays better under Classic 99.

[apersson850]

Sounds like an approach to accomplish the same thing as the program I described. Maybe with the difference that I could re-read the same diskette, and the database would be updated. Didn't have to read them all once again.

[+adamantyr]

On 7/20/2020 at 5:41 PM, pixelpedant said:

Adamantyr's (as yet unreleased) Realms of Antiquity is distributed across three disks by default, so that's one example (or soon-to-be example).  And it seems like multiple volumes would be inherently required on a NanoPEB, given that device's (in this case insufficient) 400KB volumes.  Though presumably very few will ever use 1MB SAMS with a NanoPEB. 

Three 360k disks, to be exact. If a 180K version is supported it will have six disks. (Load, Game, four world disks). It goes without saying I would urge the use of TIPI for the best experience.

On 7/20/2020 at 8:36 PM, Ed in SoDak said:

Legends and its sequel, as shipped on two SSSD disks.

Legends II actually is on three disks. The last disk just contains the character converter and some end game sequences though. In terms of content amount, the two games are the same size.