RXB - Rich Extended Basic

[+Lee Stewart]

 

But disk image are write protected, right?

 

Nope—just not completely implemented. Back when I needed level-2, direct-sector writes for testing TI Forth, @Tursi changed Classic99 to accommodate them. However, as I recall, file writes are not implemented for disk images.

 

...lee

[+Lee Stewart]

We were talking about being able to catalog files from XB. Not knocking Classic99 but it does not use a normal format for DISKS hence SECTOR access does not work.

 

It should not be a problem for disk images.

 

...lee

[Tursi]

We were talking about being able to catalog files from XB. Not knocking Classic99 but it does not use a normal format for DISKS hence SECTOR access does not work.

Yes, and that's why I kept my comment brief and just to the one point. All of Classic99's formats are "normal", I did not invent a single one of them. Sector access works completely normally on disk images (read AND write), and sector reads work for the index sectors 0-127 (if there are that many files) on TIFILES and V9T9 folders. So you can catalog just fine from RXB in Classic99, I just tested it.

[RXB]

Yes, and that's why I kept my comment brief and just to the one point. All of Classic99's formats are "normal", I did not invent a single one of them. Sector access works completely normally on disk images (read AND write), and sector reads work for the index sectors 0-127 (if there are that many files) on TIFILES and V9T9 folders. So you can catalog just fine from RXB in Classic99, I just tested it.

Long before I ever used a emulator I was only using a real TI so many things I wrote were like this example.

 

Try and run this program from RXB version 1005 and see what happens.

100 ON ERROR 140
110 N=N+1
120 D$="DSK"&CHR$(N)&"."
130 CALL CAT(D$)
140 CALL HPUT(12,12,D$,14,12,"DRIVE#="&STR$(N))
150 IF N<255 THEN 100
160 END

[Tursi]

Long before I ever used a emulator I was only using a real TI so many things I wrote were like this example.

 

Try and run this program from RXB version 1005 and see what happens.

100 ON ERROR 140
110 N=N+1
120 D$="DSK"&CHR$(N)&"."
130 CALL CAT(D$)
140 CALL HPUT(12,12,D$,14,12,"DRIVE#="&STR$(N))
150 IF N<255 THEN 100
160 END

Works fine here. If you thought it was failing, it's probably because you used CHR$(N) and expected the first pass to match "DSK1". You have to wait for it to count up to 49 before that happens. (Because you're appending the ASCII character, not the digit.)

[Willsy]

Rich,

 

If N starts at zero then that program is bugged. It's not a displayable character. N would have to start at 49 for it to work.

 

I think the problem is located between the chair and keyboard (as these things often are, especially in my experience!)

[RobertLM78]

 

 

130 D$="DSK"&STR$(N)&"."

 

 

 

[CantStopClicking]

 

 

130 D$="DSK"&STR$(N)&"."

 

 

 

 

That program is buggered.... shouldn't that be 120?

[RXB]

Rich,

 

If N starts at zero then that program is bugged. It's not a displayable character. N would have to start at 49 for it to work.

 

I think the problem is located between the chair and keyboard (as these things often are, especially in my experience!)

Works fine on a real TI as that is what I tested and wrote that program on.

I also demoed that at a Ti Faire and it worked with my CorComp drives and Horizon RAMDISKS.

 

And that is the reason for:

100 ON ERROR 140

 

From RXB you can do this:

CALL CAT(49) or CALL CAT(1)

CALL CAT(57) or CALL CAT(9)

CALL CAT(65) or CALL CAT(A) ! If A=65 and you have a RAMDISK named DSKA

CALL CAT("DSK1.") or CALL CAT(D$) ! D$ can be a path on hard drive or disk

 

RXB CAT is a smart cataloger that figures out what you want.

Edited February 25, 2015 by RXB

[Willsy]

RXB CAT is a smart cataloger that figures out what you want.

Ah! Okay, that's pretty cool!

[Tursi]

Works fine on a read TI as that is what I tested and wrote that program on.

I also demoed that at a Ti Faire and it worked with my CorComp drives and Horizon RAMDISKS.

 

And that is the reason for:

100 ON ERROR 140

 

From RXB you can do this:

CALL CAT(49) or CALL CAT(1)

CALL CAT(57) or CALL CAT(9)

CALL CAT(65) or CALL CAT(A) ! If A=65 and you have a RAMDISK named DSKA

CALL CAT("DSK1.") or CALL CAT(D$) ! D$ can be a path on hard drive or disk

 

RXB CAT is a smart cataloger that figures out what you want.

Might I remind you that I /have/ real hardware?

 

All those options are nice, but you are trying to "CALL CAT("DSK~.")", where '~' is ASCII character 1. I suggest you try that again on your hardware, instead of just saying it works! (All the options you listed there work fine in Classic99 except for 'A', since I don't have lettered drives.) Smart as it may be, that's not a valid device name.

 

The nice thing in Classic99 is that you can see exactly what the DSR is asked to do. For instance:

 

CALL CAT(1)

DSR opcode >0 on PAB >08CE, filename DSK1.
Opening DSK1. on drive type FIAD
PAB requested file type is IF0
Allocating file buffer 0
DSR opcode >2 on PAB >08CE, filename DSK1.
Read 0x26 bytes drive 1 file  (Fixed record 0) to >0900
Read 0x26 bytes drive 1 file  (Fixed record 1) to >0900
Read 0x26 bytes drive 1 file  (Fixed record 2) to >0900
...

'1' queries "DSK1", as expected. Also, there's no sector access anyway, it's using the directory read method.

 

CALL CAT(49)

DSR opcode >0 on PAB >08CE, filename DSK1.
Opening DSK1. on drive type FIAD
PAB requested file type is IF0
Allocating file buffer 0
DSR opcode >2 on PAB >08CE, filename DSK1.
Read 0x26 bytes drive 1 file  (Fixed record 0) to >0900
Read 0x26 bytes drive 1 file  (Fixed record 1) to >0900
Read 0x26 bytes drive 1 file  (Fixed record 2) to >0900
...

Also asks for DSK1, as expected (interesting and clever idea to handle!) (And "1" works as well)

 

But with the unusual ASCII string of "DSK\x1.":

 

CALL CAT("DSK"&CHR$(1))

NO debug at all. The I/O Error 00 does not come from Classic99. It's easy to see why, RXB searches the DSRs for a matching string and doesn't find one. I breakpointed inside the emulator to make absolutely sure - remember the DSR does not do the devicename search!

 

You typoed in your example program when you copied it here, that's all. It actually works in that incarnation if you let it count up (I don't know why the ON ERROR doesn't trigger, but it's not related to Classic99's DSR because the DSR is not called until the first valid string). STR$ instead of CHR$ would have worked, so would CHR$ without the "DSK" part.

Edited June 25, 2014 by Tursi

[RXB]

RXB does EXPECT all device names to only have 3 characters. EXAMPLES:

DSK#.

WDS#.

SCS#.

HDK#.

 

Tursi you did not understand that I used to own a couple of Horizon 4000 RAMDISK and the names were:

DSK5.

DSK6.

DSK7.

DSK8.

DSK9.

DSKA.

DSKB.

DSKC.

DSKD.

DSKE.

DSKF.

DSKG.

DSKH.

 

I think Classic99 should support this like the Horizon RAMDISK as then we could have about 100 disks we could use.

[Gary from OPA]

There is something different for sure on how Classic99 handles 'catalog' of drives, as my RAMOS program is broken on it when trying to do directories, but it works on real iron and on MESS and on Ed's old V9T9 emulator.

 

And I agree with RXB, it would be nice to see Classic99 handle 'emulation' of Horizon or at least the feature of using alpha drive letters, giving more drives available if the user so wishes.

Edited July 1, 2014 by Gary from OPA

[RXB]

There is something different for sure on how Classic99 handles 'catalog' of drives, as my RAMOS program is broken on it when trying to do directories, but it works on real iron and on MESS and on Ed's old V9T9 emulator.

 

And I agree with RXB, it would be nice to see Classic99 handle 'emulation' of Horizon or at least the feature of using alpha drive letters, giving more drives available if the user so wishes.

Thanks Gary!

 

RXB can handle any letter for a drive letter.

Then entire idea was if the device does not exist then the GPL DSR will handle the problem so no need to check for validity.

 

Example: DSK!. up to DSK_.

Of course DSK.. would error out as the DSR checks for the Period in the wrong place.

[Tursi]

There is something different for sure on how Classic99 handles 'catalog' of drives, as my RAMOS program is broken on it when trying to do directories, but it works on real iron and on MESS and on Ed's old V9T9 emulator.

That's certainly not enough information for me to diagnose or fix it. And this is where I stand, people going "it doesn't work right" but not providing any details doesn't help in any way.

 

But yes, there is something "different". It's a completely different DSR than anything that was out in the day. If RAMOS is making any assumptions about side effects, memory locations, anything other than simply sending a PAB to the DSR, then it is likely to fail. I don't have too much sympathy for programs that do that, since they are equally likely to fail on other devices. But if it's totally limited to the device interface, then I'll happily fix whatever Classic99 is doing wrong.

 

At any rate, the intention of the folder emulation in Classic99 was that you use Windows Explorer to manage your files, and things are directory emulation are a 'nice to have'. They are limited to 10 characters for filename, and 127 files in a folder (although both of these can be overridden if you open the directory in a slightly different manner). If you need those side effects or accurate reproduction of the original disk controller, use the TI Disk Controller emulation instead.

 

And I agree with RXB, it would be nice to see Classic99 handle 'emulation' of Horizon or at least the feature of using alpha drive letters, giving more drives available if the user so wishes.

It's not hard to add internally, but it means a rework of the configuration GUI. I don't see the value: The Horizon RAMdisk was limited to disks of 2880(?) sectors, Classic99's disks have no limits. The RAMdisk was limited to 127 files in a folder, Classic99's disks have no limits. No case has been made for how having more than 10 unlimited hard drives on your TI makes development of new software easier? It sounds like just another 'nice to have'.

 

You guys are more trying to reproduce your old setups, and I get that, but Classic99 isn't really targeted towards reliving the old days. In some areas it's a deliberate rebellion against them. Still, I hear the feedback and we'll see.

[Gary from OPA]

That's certainly not enough information for me to diagnose or fix it. And this is where I stand, people going "it doesn't work right" but not providing any details doesn't help in any way.

Sorry, was not planning on giving enough info for you to fix it, but I will when I am back to work on playing with updating the RAMOS program again. -- Thanks.

[+InsaneMultitasker]

Thanks Gary!

 

RXB can handle any letter for a drive letter.

Then entire idea was if the device does not exist then the GPL DSR will handle the problem so no need to check for validity.

 

Example: DSK!. up to DSK_.

Of course DSK.. would error out as the DSR checks for the Period in the wrong place.

 

Not sure why we would want to add so many drives with Classic99's existing capabilities? Also, any program can use any drive letter, so long as the programmer allows for it. As you point out, the DSR will handle the problem.

 

However, this applies only to level 3 access. Level 2 direct access is based on unit number and will not necessarily function as you expect....

[Willsy]

I think Classic99 should support this like the Horizon RAMDISK as then we could have about 100 disks we could use.

Classic99 gives you ten drives, each with unlimited capacity. What's the point? What would the benefit be?

[sometimes99er]

Classic99 gives you ten drives, each with unlimited capacity. What's the point? What would the benefit be?

I'm about doing something within the settings of the original and popular TI-99/4A. I don't see much point in expanding the TI with this and that making it something that only a few had, used or even developed for (hundreds may have them today one way or another, but then you might argue to go Full Monty and in effect move on to modern stuff. Now, if I do a game for the bare bone TI these days, I too, can be accused of getting out of line (my knowledge and time frame is what it is), and yes, sorry, but that's what I was here for.

Edited July 2, 2014 by sometimes99er

[+Ksarul]

Actually we have lots of nice cartridge boards that allow you to develop for the bare console, Sometimes99er. That meets your design goal while allowing you to design things that use more space than was available back in the day but which can be used by any user who purchases the product from you as a complete cartridge package. That is a good thing. We even have Rich's RXB running on one of the ÜberGROM boards now--so even software that once required access to a GRAM device will run on a stock console with some form of 32K card.

[sometimes99er]

I commented on the goal of ending up with a 100 disks or ten drives. I'm not saying it's not nice to have, and if someone wants it, fine. You may store many things there or whatever, I just don't see any application or game coming, happening to require 100 disks or ten drives. Nice with the sky as the limit, but actually, some original bare bone confinement or early eighties TI setup has, as I see it, much unexplored potential. But then I'm thinking games that push original "limits" and not RTC, 80 columns or a 100 disks. If I really wanted those I think I'd slide to another baby of mine, - the Amiga.

 

Edited July 3, 2014 by sometimes99er

[RXB]

 

Not sure why we would want to add so many drives with Classic99's existing capabilities? Also, any program can use any drive letter, so long as the programmer allows for it. As you point out, the DSR will handle the problem.

 

However, this applies only to level 3 access. Level 2 direct access is based on unit number and will not necessarily function as you expect....

Actually the Program I posted in first place works fine on a normal TI with CorComp or Myarc or RAMDISK drives.

There is no reason that my program I am working on could not do the same thing on all devices for Storage on DISK or Hard Drives.

 

I will let the cat out of the bag here. I am working on a GPL OS and RXB utility to find a Directory or Disk Name or File from a single command.

 

EXAMPLE:

 

CALL SEARCH("UTIL1",F) ! Search all drives for UTIL1 and show all Files with the name UTIL1 and the path to those files if more than fits on screen then push space bar to continue.

 

CALL SEARCH("BAG",F,20) ! Search all drives for "BAG" and show all Files with name "BAG" in name and the path to those files but limit the number to 20 but can also use space bar.

 

CALL SEARCH("FUN",D) ! Search all drives for "FUN" and show all Directories that contain "FUN" in Directory name and the path to that Directory.

 

I may make a version that puts these into a String Array Variable so the correct path could be used per user selection.

Edited July 2, 2014 by RXB

[RXB]

Classic99 gives you ten drives, each with unlimited capacity. What's the point? What would the benefit be?

Ok the answer is FILE NAMES!!!

I can not search by DISKNAME in Classic99 like I can in a Hard Drive or RAMDISK both of which are not supported in any fashion.

 

As I have to limit my access to cut and paste a flie into Classic99 vs in a REAL TI just RUN "DSK.WINDYXB.LOAD" or RUN "DSK.Funnelweb.FW" or RUN "WDS.VOLNAME.SUBVOLNAME.FILENAME"

 

Now this is the way Tursi wants Classic99 to stay, but that is also why I have started to learn MESS as that is closer to a real TI as I love path names to find and run files.

[RXB]

I commented on the goal of ending up with a 100 disks or ten drives. I'm not saying it's nice to have, and if someone wants it, fine. You may store many things there or whatever, I just don't see any application or game coming, happening to require 100 disks or ten drives. Nice with the sky as the limit, but actually, some original bare bone confinement or early eighties TI setup has, as I see it, much unexplored potential. But then I thinking games that push "limits" and not TCP, RTC, 80 columns or a 100 disks. If I really wanted those I think I'd slide to another baby of mine, - the Amiga.

 

I on the other hand disassemble stuff and may have many projects going at same time so I need tons of disks to use quickly and hate having to go back to Windows and find the files then make a copy then load them then check what I was doing. It is a distraction I did not have on the real TI.

 

Also I may have 4 versions of the same project going different approaches at same time.

LIke I have 4 versions of a new RXB I am working on presently.

 

Also I hate having to use \DSK\ as when I make a utility I have to go back and edit all the Source to work outside of Classic99 only Environment.

[+InsaneMultitasker]

Actually the Program I posted in first place works fine on a normal TI with CorComp or Myarc or RAMDISK drives.

There is no reason that my program I am working on could not do the same thing on all devices for Storage on DISK or Hard Drives.

 

I will let the cat out of the bag here. I am working on a GPL OS and RXB utility to find a Directory or Disk Name or File from a single command.

 

EXAMPLE:

 

CALL SEARCH("UTIL1",F) ! Search all drives for UTIL1 and show all Files with the name UTIL1 and the path to those files if more than fits on screen then push space bar to continue.

 

CALL SEARCH("BAG",F,20) ! Search all drives for "BAG" and show all Files with name "BAG" in name and the path to those files but limit the number to 20 but can also use space bar.

 

CALL SEARCH("FUN",D) ! Search all drives for "FUN" and show all Directories that contain "FUN" in Directory name and the path to that Directory.

 

I may make a version that puts these into a String Array Variable so the correct path could be used per user selection.

Cool idea. Could you dump the results into an array versus on screen?