Convenience & Storage Format

[Tursi]

99% of software doesn't care about the physical disk layout. If you're simulating the underlying file device with FIADs anyway, it doesn't matter how those FIADs are represented on the host system. MAME doesn't support FIADs anyway, so your software isn't really affected.

[+mizapf]

You know, according to the MAME philosophy it's actually not interesting how many programs care about the physical layout. My point is quite simple: Preserving software in ZIPs as single files is not as accurate as the DSKs, so they are not equivalent, as Rasmus implied. (The best format in that sense is HFE, of course.)

 

Suggestions of this kind sound somewhat like dropping DSK, and this would make MAME unusable, at least for new software. Maybe it is understandable that I fight for keeping it ...?

[Opry99er]

That is a nice video, Ohm.

[Omega-TI]

That is a nice video, Ohm.

 

Thanks Owen. Thank's for letting me know. Believe it or not, it's received two dislikes, "apparently" one each from Russia and France.

Oh well, can't please everyone.

[Asmusr]

You know, according to the MAME philosophy it's actually not interesting how many programs care about the physical layout. My point is quite simple: Preserving software in ZIPs as single files is not as accurate as the DSKs, so they are not equivalent, as Rasmus implied. (The best format in that sense is HFE, of course.)

 

Suggestions of this kind sound somewhat like dropping DSK, and this would make MAME unusable, at least for new software. Maybe it is understandable that I fight for keeping it ...?

 

What I said, or meant to say, is that in the matter of acting as a container/name space, a disk image and a zip file are equivalent. I'm not concerned about preserving old software but about distributing new software that we make. My software has never seen a physical floppy disk before it's released.

[+InsaneMultitasker]

Seems there are a two discussions here - one related to means for distributing loadable content and the other related to how best to access/read/write files. A ZIP file mounted as a disk sounds great for distribution and segregation. Perhaps the files could be unzipped into a temporary location (folder or memory) while the ZIP is "mounted", then rezipped when dismounted. Write a routine that can take the zipped files and move some or all of hem into a disk image, just like how TIDIR can move files from a PC folder into a disk image, and you have the best of both worlds.

[+mizapf]

If I understood correctly, you think about some similar mechanism as with the RPKs for cartridges, something like "-flop1 diskimage.zip". Things are not that simple, however. Cartridges are immutable, and the included dumps actually reflect the physical locations; mind that some time ago I actually split all combined dumps into dumps that correspond to the circuits. Cartridges with internal RAM or NVRAM create separate NVRAM files outside of the cartridge file.

 

In MAME, when you operate on the disk, all the typical low-level operations are performed, including sector allocation. If you have some software that accesses sectors directly, these sectors will have to be saved as well, even when they are not allocated to disks (e.g. when you format the disk, or think about Forth, copy protections, or sector editors). Now if you have such a ZIP file format, when you want to unmount it, we not only need to store changes in the files but changes that occured to any sector. You will end up with something like a DSK file, disguised as a ZIP file, which would also require consistent updating from that time on.

 

The longer I think about that, the more am I certain that this will not be feasible or even reasonable in MAME.

[Tursi]

Suggestions of this kind sound somewhat like dropping DSK, and this would make MAME unusable, at least for new software. Maybe it is understandable that I fight for keeping it ...?

Dude, nobody is going to drop DSK. It would be nice if every time someone tried to update the system it didn't become a battle to stay compatible with the 1981 hardware. We get it. MAME reproduces the original system (except for the enhancements like enhanced keyboard, 16-bit RAM, etc). We have tons of tools for moving files between the various formats, and plenty of people who WANT that original experience.

 

We also have plenty of people who want NEW experiences, and we have support for them too. The files themselves are portable. So MAME people can make a DSK image and share it. Non-MAME people can pull the files off a DSK and use that. 99% of the time, nothing is lost. In those 1% of other times, we all support the DSK format - every single emulator.

 

What's frustrating to me is you took a fantastic cartridge format that was flexible enough and portable enough to be the new standard for cartridge emulation in the entire community - RPK, and as soon as it looked like others might implement it, you ripped out all the useful metadata and compiled it directly into MAME. I don't know if that was also a fight for relevance or just incidental, but I wish we could instead work together instead of trying to keep the various emulator groups fragmented on purpose.

[RXB]

 

Some things would be nice to have for sure, but lately the hard drive route has not been a viable option for many of us due to lack of availability and the expense of that classic hardware. The last time I saw the asking price of a TI-99/4A compatible hard drive controller on Ebait... (well, this is a family thread so I better not tell you what word came out of my mouth).

 

At the time, for me, the HDX gave me the capability I needed at a fraction of the price. I suspect that's one of the reasons the FlashROM 99 is currently so popular, it gives people the ability to easily and cheaply get stuff off the Internet and onto their TI so they can have some fun.

 

My excitement level is growing as I hear rumblings of something new and cool in the works... (to be continued)!

Hmmmm I am not asking for a Hard Drive CARD! I am saying set up your NEW DEVICES LIKE A HARD DRIVE!

 

Look using CALL MOUNT or some routine to set up what path to use is disadvantages and anti TI99/4A in design.

 

What is TI like is just going to ANY CART or ANY PROGRAM and typing:

 

WDS#.Volume.Subvolume.file

 

 

It makes absolutely no sense to have to load utility first to find the right DSK to load and only then can you type in DSK#.FILE

 

Look what I am saying is a 1 step process for the USER is better and more TI like vs a 2 step process to do exactly the same thing.

 

I always think in terms of doing things in the least number of steps and the least complicated manner.

 

Also consider this comcept. From most carts like REA or RXB or XB2 or XB2.7 CALL CAT("WDS#.Volume.SubVolume") will work fine!

(Mind you the name WDS# is just as valid as SCS# or IDE# or HD# or RD# they all work!)

Edited March 11, 2017 by RXB

[+mizapf]

I merely wanted to comment on Rasmus' thought about distributing new software as a zip file of TI files, and the implied question whether this is sufficient. My answer is that it would be inconvenient for MAME users because MAME cannot make use of FIAD, and someone (maybe the author, maybe me, someone else) would have to create a DSK image from that zip file.

 

As for the RPK, the story is a bit different that it may seem at first sight.

 

In fact, RPK is still there because I insisted on keeping it in MESS/MAME. (Remember that I am only one developer in MAME at Github rank #26.) RPK was introduced some years ago, but the other developers continued work on it and released the ZIP file containers about a year later, when all cartridges were already available and working as RPK. The shortcoming of the ZIP solution was that only existing cartridges were considered, but no new developments. This gave enough reason to keep RPK for us.

 

The RPK support was moved from the MAME core to the TI-99 subtree, so no other system in MAME is currently using it. Also, in the core there is a check whether the argument of the "-cart" option contains a period or not: If it is "-cart exbasic", the ZIP-based software list is used; if we have "-cart exbasic.rpk", the argument is passed through, and my special RPK loader may load the file. If the other devs once decide to remove that check, or that they "need" the period for something else, the RPK support would be offline from one day to the next.

 

There are ongoing works for creating a ZIP-based support for new cartridges; essentially, they contain the metadata inside the ZIP file, so they very much resemble the RPKs, with the only difference that the contained metadata file is structured differently, and the cartridge file ends in ".zip" and not ".rpk". For the existing cartridges, the metadata is contained in the MAME distribution for good reason - to ensure the authenticity of the software. But if we decided to create, for instance, a patched Extended Basic, we could create a new zip file, include the metadata file and the dumps, and everything is fine. I am pretty sure that once the software list / zip file system supports everything from the RPK system, I will have no good reasons anymore to insist on keeping it.

[+Lee Stewart]

...

Look using CALL MOUNT or some routine to set up what path to use is disadvantages and anti TI99/4A in design. What is TI like is just going to ANY CART or ANY PROGRAM and typing:

 

WDS#.Volume.Subvolume.file

 

It makes absolutely no sense to have to load utility first to find the right DSK to load and only then can you type in DSK#.FILE

...

 

Your protestations to the contrary notwithstanding, “CALL MOUNT()” is very TI-like. It is equivalent to removing/inserting a diskette from/into a drive (DSK1, DSK2 or DSK3). And—finding the desired volume to mount with a utility (CF2K, CFMGR, ...) is exactly analogous to sorting through a box of diskettes to find a likely diskette, using a utility like Disk Manager II to see if the desired program/file is on the diskette and repeating the process until it is found. Just as with diskettes, a separate listing of volume contents and locations to peruse before selection, though time-consuming to produce, is always better than having to check through the volumes when you need a file.

 

...lee

[RXB]

 

Your protestations to the contrary notwithstanding, “CALL MOUNT()” is very TI-like. It is equivalent to removing/inserting a diskette from/into a drive (DSK1, DSK2 or DSK3). And—finding the desired volume to mount with a utility (CF2K, CFMGR, ...) is exactly analogous to sorting through a box of diskettes to find a likely diskette, using a utility like Disk Manager II to see if the desired program/file is on the diskette and repeating the process until it is found. Just as with diskettes, a separate listing of volume contents and locations to peruse before selection, though time-consuming to produce, is always better than having to check through the volumes when you need a file.

 

...lee

Lee

There is no removing or inserting a disk in a Hard Drive format, it is always there. Thus why would you need this extra step all the time as I am NOT USING DISKS!

 

And most Disk Managers do work with Hard Drives, Boot, RXB , XB2.7, FW and many others all will catalog a Hard Drive with no extra steps involved without having to MOUNT / UNMOUNT

 

Again all I am asking is dump the goofy extra step and use Hard Drive versions as it is faster and less steps to do exactly the same thing.

 

The only exception is when you need DSK1. only for some software, but those can be edited by sectors or file to fix this issue.

Edited March 11, 2017 by RXB

[+Lee Stewart]

...

 

I see your point, Rich. I was merely objecting to your saying it was not very TI-like.

 

...lee

[+InsaneMultitasker]

Mounting disks and using hard drive style paths are not mutually exclusive. If you want to use a program that will ONLY work with a floppy device, because it will only accept 15 characters or a disk number, you would need to "mount" the disk, even if that disk points to a different path. You can't force a hard drive path down a floppy-only program's throat.

For those who had or know about the Myarc HFDC, you may recall its ability to emulate a disk image on a hard drive? Similar concept, except now the idea is to make a folder look like that disk image, while keeping your files neatly tucked away on something other than a floppy disk.

 

From my perspective, it seems there is a tendency for many of the remaining enthusiasts to get hung up on what "must" be done for full compatibility with every program, every device, and every emulator. Pushing for compatibility is a good thing, yet not everyone here cares if something new is 100% compatible with every prior scenario. If we stuck to that mantra, we'd still be using TI boxcar peripherals and 300 baud coupler modems, and typing in our programs instead of loading them from some device.

[RXB]

Mounting disks and using hard drive style paths are not mutually exclusive. If you want to use a program that will ONLY work with a floppy device, because it will only accept 15 characters or a disk number, you would need to "mount" the disk, even if that disk points to a different path. You can't force a hard drive path down a floppy-only program's throat.

I am curious what programs ONLY accept 15 characters for a path name?

I have never ever seen such a program myself.

 

I have seen program using only disk number but these are easy to sector edit and fix.

Example: Change DSK#.PROGRAM to WDS2.MYLOADER

 

Really rare for this not to work.

And this is not forcing it as the Program has no idea there is a difference between hard drive vs floppy unless it is hard coded sector only access.

Edited March 12, 2017 by RXB

[+InsaneMultitasker]

I am curious what programs ONLY accept 15 characters for a path name?

I have never ever seen such a program myself.

 

I have seen program using only disk number but these are easy to sector edit and fix.

Example: Change DSK#.PROGRAM to WDS2.MYLOADER

 

Really rare for this not to work.

And this is not forcing it as the Program has no idea there is a difference between hard drive vs floppy unless it is hard coded sector only access.

There are plenty of programs with disk numbers / short paths. I wasn't referring to sector editing or fixing programs, and I certainly would have no desire to put all of the programs, especially ones with LOAD programs, into one root folder.

[RXB]

There are plenty of programs with disk numbers / short paths. I wasn't referring to sector editing or fixing programs, and I certainly would have no desire to put all of the programs, especially ones with LOAD programs, into one root folder.

I made a simple RXB program that does this, it loads almost everything. I even made a program to create a LOAD program in XB:

100 ! RUN this program to       create a load program       that loads and runs         EA5, EA3, BASIC, and        XB programs from DISK       or HARD DRIVE.
110 ! STEP ONE: Put in the      Path of the DV80 USER       file that creates           the LOAD program.
120 ! STEP TWO: Put in the      path where to catalog       and want the LOAD           program to be saved.
130 ! STEP THREE: If done       then press enter, if        you want to add more        directorys put in path.
140 ! STEP FOUR: When you       press ENTER then the        LOAD program is created     and saved to the disk.
150 CALL VERSION(V) :: IF V<2E3 THEN PRINT "VERSION TO OLD TO CONTINUE!" :: END
160 DISPLAY AT(1,3)ERASE ALL:"RXB CREATES A LOAD PROGRAM"
170 CALL HPUT(5,3,"EXAMPLE:",7,3,"PATHNAME:DSK1.",9,3,"PATHNAME:DSK.DISKNAME.",11,3,"PATHNAME:WDS1.DIR.")
180 CALL HPUT(13,3,"PATHNAME:WDS1.DIR.SUB-DIR.",15,3,"PATHNAME:WDS.VOL.DIR.")
190 CALL HPUT(17,3,"PATHNAME:WDS.VOL.DIR.SUB-DIR.",19,3,"(Where to save result.)",23,3,"PATHNAME:")
200 ACCEPT AT(23,10)BEEP:M$
210 CALL CLEAR :: PRINT "Creating USER file DV80-LOAD"
220 OPEN #1:M$&"DV80-LOAD",VARIABLE 80,DISPLAY,OUTPUT
230 PRINT #1:"NEW"&CHR$(13)
240 PRINT #1:"100 ! RXB LOAD PROGRAM"&CHR$(13)
250 PRINT #1:"110 DIM P$(48),Y$(48),T(48)"&CHR$(13)
260 PRINT #1:"120 @=1::CALL VERSION(V) :: IF V<2E3 THEN PRINT "&"""&"VERSION TO OLD TO CONTINUE!"&"""&" :: END"&CHR$(13)
270 PRINT #1:"130 CALL COLOR(ALL,16,2) :: CALL SCREEN(2) :: RESTORE"&CHR$(13)
280 PRINT #1:"140 DISPLAY AT(1,3)ERASE ALL:"&"""&"* RXB LOAD PROGRAM *"&"""&CHR$(13)
290 PRINT #1:"150 DISPLAY AT(6,1):"&"""&"ACTIVE KEYS ARE:"&"""&": :";
300 PRINT #1:"""&"E = UP CURSOR"&"""&":"&"""&"X = DOWN CURSOR"&"""&":";
310 PRINT #1:"""&"S = LEFT CURSOR"&"""&":"&"""&"D = RIGHT CURSOR"&"""&CHR$(13)
320 PRINT #1:"160 DISPLAY AT(14,1):"&"""&"SPACE BAR = NEXT PAGE"&"""&": :"&"""&"C = DIRECTORY"&"""&": :"&"""&"1-9 = CATALOG DISK"&""";
330 PRINT #1:" :: CALL HPUT(24,3,"&"""&"PLEASE WAIT..."&"""&")"&CHR$(13)
340 PRINT #1:"170 IF @ THEN CALL HPUT(24,3,"&"""&"PRESS ANY KEY TO CONTINUE!"&"""&")::CALL BEEP::CALL KEY("&"""&"""&",3,K,S)::@=0"&CHR$(13)
350 PRINT #1:"180 CALL CLEAR::N=1"&CHR$(13)
360 PRINT #1:"190 Y=1::Z=3::CALL CHAR(128,"&"""&"080C0EFFFF0E0C08"&"""&",129,"&"""&"103070FFFF703010"&"""&")"&CHR$(13)
370 PRINT #1:"200 FOR C=4 TO 16 STEP 12 :: FOR R=1 TO 24"&CHR$(13)
380 PRINT #1:"210 READ P$(N),Y$(N),T(N)"&CHR$(13)
390 PRINT #1:"220 IF T(N)=0 THEN 260"&CHR$(13)
400 PRINT #1:"230 CALL HPUT(R,C,Y$(N))::IF C=4 THEN CALL HPUT(R,1,CHR$(T(N))) ELSE CALL HPUT(R,32,CHR$(T(N)))"&CHR$(13)
410 PRINT #1:"240 N=N+1::IF N=49 THEN N=48::GOTO 260"&CHR$(13)
420 PRINT #1:"250 NEXT R::NEXT C"&CHR$(13)
430 PRINT #1:"260 CALL HCHAR(Y,Z,128,1,Y,Z+11,129)"&CHR$(13)
440 PRINT #1:"270 CALL KEY(3,K,S)::IF K=67 THEN CALL CLEAR::INPUT "&"""&"PATH:"&"""&":X$::CALL CAT(X$)::CALL KEY("&"""&"""&",3,K,S)::GOTO 130"&CHR$(13)
450 PRINT #1:"280 CALL HCHAR(Y,Z,32,1,Y,Z+11,32) :: IF K>48 AND K<58 THEN CALL CAT(K) :: CALL KEY("&"""&"""&",3,K,S)::GOTO 130"&CHR$(13)
460 PRINT #1:"290 IF K=69 OR K=11 THEN S=Y::Y=Y-1::GOSUB 390::IF G=32 THEN Y=S"&CHR$(13)
470 PRINT #1:"300 IF K=88 OR K=10 THEN S=Y::Y=Y+1::GOSUB 390::IF G=32 THEN Y=S"&CHR$(13)
480 PRINT #1:"310 IF K=83 OR K= 8 THEN Z=3"&CHR$(13)
490 PRINT #1:"320 IF K=68 OR K=9 THEN Z=15::CALL GCHAR(Y,Z+1,G)::IF G=32 THEN Z=3"&CHR$(13)
500 PRINT #1:"330 IF K=32 THEN 340 ELSE 360"&CHR$(13)
510 PRINT #1:"340 Y=1::IF POS(P$(N),"&"""&"!........!"&"""&",1) THEN 130"&CHR$(13)
520 PRINT #1:"350 GOTO 180"&CHR$(13)
530 PRINT #1:"360 IF K=13 THEN 420"&CHR$(13)
540 PRINT #1:"370 IF K=43 OR K=61 THEN N,X=0::GOTO 140"&CHR$(13)
550 PRINT #1:"380 GOTO 260"&CHR$(13)
560 PRINT #1:"390 IF Y<1 THEN Y=24"&CHR$(13)
570 PRINT #1:"400 IF Y>24 THEN Y=1"&CHR$(13)
580 PRINT #1:"410 CALL GCHAR(Y,Z+1,G)::RETURN"&CHR$(13)
590 PRINT #1:"420 IF Z=15 THEN T$=P$(24+Y)&Y$(24+Y)ELSE T$=P$(Y)&Y$(Y)"&CHR$(13)
600 PRINT #1:"430 IF Z=3 THEN CALL GCHAR(Y,1,S) ELSE CALL GCHAR(Y,32,S)"&CHR$(13)
610 PRINT #1:"440 IF S=1 THEN CALL EALR(T$) ELSE IF S=5 THEN CALL EAPGM(T$) ELSE IF S=4 THEN CALL XBPGM(T$)"&CHR$(13)
620 PRINT #1:"450 IF S=9 THEN CALL USER(T$)::END"&CHR$(13)
630 PRINT #1:"460 IF S<>2 THEN 130 ELSE CALL EAED(T$)"&CHR$(13)
640 CALL CLEAR :: ON ERROR 670
650 CALL PROTECT(M$,"LOAD",0)
660 DELETE M$&"LOAD"
670 DISPLAY AT(1,1)ERASE ALL:"* INPUT DIRECTORY FOR LIST *"
680 CALL HPUT(5,3,"EXAMPLE:",7,3,"PATHNAME:DSK1.",9,3,"PATHNAME:DSK.DISKNAME.",11,3,"PATHNAME:WDS1.DIR.")
690 CALL HPUT(13,3,"PATHNAME:WDS1.DIR.SUB-DIR.",15,3,"PATHNAME:WDS.VOL.DIR.")
700 CALL HPUT(17,3,"PATHNAME:WDS.VOL.DIR.SUB-DIR.",19,3,"PATHNAME:(ENTER TO EXIT)",23,3,"PATHNAME:")
710 ACCEPT AT(23,10)BEEP:_$
720 X=0 :: IF LEN(_$)=0 THEN 1120
730 DIM TYPE$(6),F$(128)
740 TYPE$(1)="DIS/FIX"
750 TYPE$(2)="DIS/VAR"
760 TYPE$(3)="INT/FIX"
770 TYPE$(4)="INT/VAR"
780 TYPE$(5)="PROGRAM"
790 TYPE$(6)="DIRECTORY"
800 OPEN #2:_$,INPUT,INTERNAL,FIXED 38
810 INPUT #2:A$,J,J,K
820 CALL CLEAR :: DISPLAY _$;" -  DISKNAME= ";A$:"AVAILABLE= ";K;" USED= ";J-K
830 DISPLAY:"FILENAME   SIZE    TYPE    P":"---------- ---- ---------- -";
840 INPUT #2:A$,I,J,K
850 T=ABS(I) :: IF LEN(A$)=0 THEN GOSUB 1030 :: GOTO 670
860 DISPLAY: :A$;TAB(12);J;TAB(17);TYPE$(ABS(I));
870 IF ABS(I)=5 THEN 910
880 IF ABS(I)=6 THEN 930
890 B$="  "&STR$(K)
900 DISPLAY SEG$(B$,LEN(B$)-2,3);
910 IF I>0 THEN 930
920 DISPLAY TAB(28);"Y";
930 IF T=4 AND K=254 THEN 950
940 IF T=5 THEN 950 ELSE 960
950 PRINT :: DISPLAY AT(24,1)BEEP:"XB or EA program? (X/E/ )  ?" :: GOSUB 1020 :: IF W=88 THEN T=4 :: GOTO 1010 ELSE IF W=69 THEN 1010 ELSE IF W=32 THEN 960 ELSE 950
960 IF T=2 AND K=80 THEN 970 ELSE 990
970 PRINT :: DISPLAY AT(24,1)BEEP:"VIEW/BATCH/  (V/B/ ) ?" :: GOSUB 1020 :: IF W=66 AND K=80 THEN T=9 :: GOTO 1010
980 IF W=86 AND K=80 THEN 1010 ELSE IF W=32 THEN 840 ELSE 970
990 IF T=1 AND K=80 THEN 1000 ELSE 840
1000 PRINT :: DISPLAY AT(24,1)BEEP:"EA OBJECT FILE? (Y/N) ?" :: GOSUB 1020 :: IF W=89 THEN 1010 ELSE IF W=78 THEN 840 ELSE 1000
1010 X=X+1 :: F$(X)=A$&","&STR$(T) :: GOTO 840
1020 CALL KEY("",3,W,S) :: RETURN
1030 PRINT: :"! Creating program list.": :"PLEASE WAIT..."
1040 IF X=0 THEN 1090
1050 FOR Y=1 TO X
1060 PRINT #1:STR$(1000+@)&" DATA "&_$&","&F$(Y)&CHR$(13)
1070 @=@+1
1080 NEXT Y
1090 PRINT #1:CHR$(13)
1100 CLOSE #2
1110 RETURN
1120 CALL CLEAR :: PRINT "PLEASE WAIT..."
1130 @=@+1
1140 PRINT #1:STR$(1000+@)&" DATA !........!,"&"""&"""&",0"&CHR$(13)
1150 PRINT #1:"SAVE "&M$&"LOAD"&CHR$(13)
1160 PRINT #1:"! New loader on disk and"&CHR$(13)
1170 PRINT #1:"! named LOAD, USER finished."&CHR$(13)
1180 PRINT #1:"! Please delete file:                                   "&M$&"DV80-LOAD"&CHR$(13)
1190 CALL CLSALL
1200 CALL USER(M$&"DV80-LOAD")

This XB program will create a XB LOAD program that will load Basic, XB , EA3, EA5 and even C programs.

It can handle up to 160 program paths of 26 characters each path.

Show me another Loader that can do that many of any type of TI programs please?