Minimal DSR providing TI BASIC loadable programs

[+FarmerPotato]

 

Imagine a card that has a lot of complicated CALL subprograms in DSR ROM.

 

Let's call it a WIDGET. You want a quick way to get some useful parameters set, in order to verify the device works. The obvious way is a short BASIC program.

 

My idea is to embed a few loadable TI BASIC programs in a DSR ROM.

 

The minimal DSR would have a device name WIDGET and support opcode LOAD only.  Is there a technical reason why this could not be done?

 

For example: Imagine a config-type program that will offer a short menu:

 

OLD WIDGET.CONFIG
LIST

10 PRINT "WIDGET OPERATING MODE? (1-2)"
20 PRINT "1. LOCAL"
30 PRINT "2. REMOTE"
40 INPUT A
50 IF (A<1)+(A>2) THEN 10
60 IF A=2 THEN 200
100 CALL WIDSET(0, 1)
110 CALL WIDSET(4, 5, 5, 128, 6, 47, 7, 129) 
120 CALL WIDSET(8, 5, 9, 128, 10, 47, 11, 129) 
130 CALL WIDRUN(2)
140 STOP
200 CALL WIDSET(0, 2)
210 CALL WIDSET(4, 11, 5, 0, 6, 49, 7, 129) 
220 CALL WIDSET(8, 5, 9, 128, 10, 47, 11, 129) 
230 CALL WIDRUN(3)
240 END

Then

OLD WIDGET.DEMO
RUN
-- suitable short demo program --

 

Q. Why not just provide these on disk?
A. Because the WIDGET operates nicely on a standalone console

 

Q. Why not just provide these on a cartridge?
A. Because I told you the WIDGET operates nicely on a standalone console. Maybe it's a screen dumper and CONFIG chooses your printer mode!

 

Q. Why not just provide one CALL to do the config or demo?
A. Besides TI BASIC code provides the right capability and is more instructive.   The user may want to make a quick edit to CONFIG.

 

 

 

Imagine if the disk controller had come with the CATALOG program built-in.

 

TI BASIC users might have said:

OLD DSK.CATALOG
RUN

 

and got the usual program into memory immediately.

 

[Reciprocating Bill]

 

Quote

Imagine if the disk controller had come with the CATALOG program built-in.

 

The Myarc disk controller does essentially that. Call Dir(1) displays a catalog of dsk1 in TI-BASIC (and all the Extended BASICs). No need to OLD a program in - it is built into the DSR.

Edited March 4, 2021 by Reciprocating Bill
accuracy

[+acadiel]

@Fred Kaal and I have developed something almost exactly like this. (Except this is a read only file system for cartridge ROMs.). The DSR is operational and has been prototyped on one of Fred’s existing boards. @ksarul just needs to develop the final hardware. It’s called the ROMDisk. :-)

Dunno if Fred is here and wants to speak up on it, but he’s done an amazing job. We just need to get the sidecar hardware out for the simple pass thru DSR ROM for it. And the utility support program to build the rom images.

Why? Because you can run any combination of assembly from the ROM and have support files (BASIC programs or data files) located on the same ROM. How many programs have “support files” like Adventure?

The little DSR “dongle” so to speak is a stripped down IDE DSR and will be pass thru. Very minimal.

[Asmusr]

6 hours ago, acadiel said:

@Fred Kaal and I have developed something almost exactly like this. (Except this is a read only file system for cartridge ROMs.). The DSR is operational and has been prototyped on one of Fred’s existing boards. @ksarul just needs to develop the final hardware. It’s called the ROMDisk. 🙂

Dunno if Fred is here and wants to speak up on it, but he’s done an amazing job. We just need to get the sidecar hardware out for the simple pass thru DSR ROM for it. And the utility support program to build the rom images.

Why? Because you can run any combination of assembly from the ROM and have support files (BASIC programs or data files) located on the same ROM. How many programs have “support files” like Adventure?

The little DSR “dongle” so to speak is a stripped down IDE DSR and will be pass thru. Very minimal.

If it was be used from TI-BASIC, wouldn't a GROM DSR work as well? And with an UberGROM cartridge, would it be possible to have both XB and a GROM DSR on another base that could be used to load programs from a ROM disk?

[Tursi]

1 minute ago, Asmusr said:

If it was be used from TI-BASIC, wouldn't a GROM DSR work as well? And with an UberGROM cartridge, would it be possible to have both XB and a GROM DSR on another base that could be used to load programs from a ROM disk?

Yep.. my E/A Complete cartridge originally included a GROM DSR that handles the LOAD opcode only, in order to load the editor and assembler. (I think I later found Thierry's disassembly and just replaced the DSR completely).

 

This is the code/notes I took:

 

DSR GPL Source.txt

 

[+acadiel]

23 minutes ago, Asmusr said:

If it was be used from TI-BASIC, wouldn't a GROM DSR work as well? And with an UberGROM cartridge, would it be possible to have both XB and a GROM DSR on another base that could be used to load programs from a ROM disk?

ROMDisk is meant for more than just TI BASIC.  It's meant to work as a device DSR (by adding a simple DSR ROM) for anything that needs to address a static set of files on a "disk".  It could be anything from TOD files for TOD, Adventure files for Adventure, E/A editor and assembler (even though this is duplicating functionality of Tursi's E/A complete), an executable on cartridge that needs to talk to data files, you name it.    Literally, you can use up to 2MB of cartridge ROM for a "disk drive" for things that don't change.  This could make more accessible data files for programs for less experience programmers, for example, who want to program something large.

 

From Fred:

Hi all,

Just a quick message about the progress I have made with the RomDsk DSR.
See also the enclosed pictures.

The DSR is now operational, it maybe need some fine tuning but that depends on the further plans and ideas. The size if the DSR is now 4Kb ROOT @ >4000-4FFF (>90C2 bytes) and 4 Banks @ >5000-5FFF of which 1 bank is empty (Bank 0 basic calls size >0B26 bytes, Bank 1 init and character definition size >0644 Bytes, Bank 2 is empty is 2 Bytes,  Bank 3 is file functions >0C1A Bytes).

Level 3 functions implemented: open, close, read, rewind, status, load.
Level 2 functions implemented: read sector, read direct file information.
Device names implemented: DSK1, DSK2, DSK3, DSK

The standard TI file handling can be uses, i.e. DSK1.FILENAME, but also by using the volume name of a disk image, i.e. DSK.VOLUMENAME.FILENAME
(b.t.w. this is not an option DM2K can use because .VOLUMENAME is a sub directory name for DM2K)

Used some basic functions from another DSR (TiBus) I'm currently working on and because this is a RomDsk DSR the prefix is ROM (this als prevents all kind of confusions on my test system):
CALL ROMDSK    - shows the status of the found DSK images
CALL ROMDIR     - shows the contents of a DSK image
CALL ROMEXE     - load and executes a E/A option 5 program
CALL ROMPWD  - print working directory

After power up for the very first time the working directory is DSK1. after that the working directory is whatever device name was used for the last time.

The CALL ROMDIR and ROMEXE can use the following (meybe not much use for this because there is not really a directory structure):
CALL ROMDIR("DSK1")
CALL ROMDIR(".")
CALL ROMDIR

CALL ROMEXE("DSK1.FILENAME")
CALL ROMEXE(".FILENAME") 

. is this directory + the file name: .FILENAME
.. is previous directory + the file name: ..FILENAME
... is current device name + the file name: ...FILENAME

In this case the . .. and ... all results in the same because there is no directory structure.

To Prevent empty gaps between DSK images I have added an offset (in number of 256 byte sectors) at the rom table. This is because an DSSD disk (720 sectors) ends at a 4Kb boundary. If a second DSK image is added to the ROM module then it is not needed to add 4Kb of unused space to let the second image begin at the start of a bank.  Because the DSR is calculating the Bank# and offsets it is only nescesarry to define the Bank# of the first DSK image. The Bank# and offset of the second and third DSK image can then be calculated by using the Bank#, offset and disk size of the previous DSK image. This prevents a lot of headaches ;-)

DR#IDT    EQU >A55A         DiskROM identity
DR#END  EQU 0                  Data type end of table
DR#DSK  EQU 1                  Data type is DSK image
DR#BIN   EQU 2                  Data type is binary data

DR#TBL    EQU >7F00        Address of DiskROM table
DR#FDT   EQU 22              Offset first data type
DR#TYP   EQU 0                Offset data type
DR#BNK  EQU 2                Offset bank number
DR#DOF  EQU 4                Offset in bytes of the data in this bank
DR#SZE   EQU 6                Offset data size in bytes (2B(
DR#LEN   EQU 10              Length of this record

* For the fist disk images the bank number must be defined and the image
* starts at the beginning of a bank; data offset is >0000 sectors.
*
* For the seconds and third disk image the bank number and data offset
* kan be calculated by the RomDisk DSR. In this case the bank number
* must be defined as >0000.
*
* The offset of the data in a bank of a disk image is in multiples of
* 256 bytes (whole sectors). For other types of data the offset in a
* bank is in the range of 0 to 8191 bytes.
*

*----- HEADER -----*
DR$TBL   DATA DR#IDT         DiskRom table identification  (2B)
DR$TTL   TEXT 'DiskROM'     Title     (16B)
               BYTE 0,0,0,0,0,0,0,0,0
DR$VRS  TEXT '1.00'              Version   (4B)

*----- DSK 1 -----*
DR$TYP   DATA DR#DSK       Data type (2B)
DR$BNK  DATA >0001          Data bank number (2B)
DR$DOF  DATA >0000          Data offset (2B)
DR$SZE   DATA >0000          Size in bytes (4B) binary data, Not needed for DSK img.
               DATA >0000

*----- DSK 2 -----*
         DATA DR#DSK            Data type (2B)
*       DATA >0017               Data bank number (2B)        (disk size DSK1: 720 sectors/32 sectors per 8Kb =22.5 banks == >16+Bank# DSK1 = >17)
*       DATA >0010               Data offset (2B)                     (0.5 bank is 4Kb is 16 sectors [16 * 256 = 4096 bytes = 4Kb])
        DATA >0000               Data bank number (2B)   must be calculated
        DATA >0000               Data offset (2B)               must be calculated
        DATA >0000               Size in bytes (4B) binary data, Not needed for DSK img.
        DATA >0000
       
*----- DSK 3 -----*
        DATA DR#DSK         Data type (2B)
        DATA >0000            Data bank number (2B)  must be calculated
        DATA >0000            Data offset (2B)              must be calculated
        DATA >0000            Size in bytes (4B) binary data, Not needed for DSK img.
        DATA >0000
       
*----- END -----*
        DATA DR#END         Data type (2B)
*---------------*

For now the device names are fixed DSK1, DSK2 and DSK3. If this need to be variable (more DSKx names) then I suggest that we add this to the above table. This can be some index number (1, 2, 3 .. n) or an ASCII character so that DSKA and DSKR is also possible or the complete device name (max is 7 characters per TI specification). 

 

[+FarmerPotato]

On 3/4/2021 at 6:51 AM, acadiel said:

@Fred Kaal and I have developed something almost exactly like this. (Except this is a read only file system for cartridge ROMs.). The DSR is operational and has been prototyped on one of Fred’s existing boards. @ksarul just needs to develop the final hardware. It’s called the ROMDisk. 🙂

Dunno if Fred is here and wants to speak up on it, but he’s done an amazing job. We just need to get the sidecar hardware out for the simple pass thru DSR ROM for it. And the utility support program to build the rom images.

Why? Because you can run any combination of assembly from the ROM and have support files (BASIC programs or data files) located on the same ROM. How many programs have “support files” like Adventure?

The little DSR “dongle” so to speak is a stripped down IDE DSR and will be pass thru. Very minimal.

 

That is awesome.  I only imagined having a demo program or two inside.

 

I had no idea there were so many cool things using built-in file systems! 

 

I really like the idea of E/A Complete, or an Adventure cartridge with games inside!

 

And ROMDSK just seems to do everything imaginable...

 

[+acadiel]

7 hours ago, FarmerPotato said:

 

That is awesome.  I only imagined having a demo program or two inside.

 

I had no idea there were so many cool things using built-in file systems! 

 

I really like the idea of E/A Complete, or an Adventure cartridge with games inside!

 

And ROMDSK just seems to do everything imaginable...

 

Gotta love Fred.  I wrote the operational spec and he had it developed out within two weeks.  He’s pretty amazing!

 

The sidecar DSR that allows you to use the cart space as a file system will have space left in it (banks a plenty) - so if we want to use any other space in there as “standalone DSRs”, we sure can in the future.  So, plenty of opportunity for expansion!

 

[+retroclouds]

ROMDSK is an amazing project and am very interested in it. Are there any details on progress/current state?

Can you share details on the sidecar PCB? Will it have pass-through?

 

My use case is a bit different. I’m currently working on my 80 columns editor Stevie (64K cartridge image for finalGROM) and want to have the option to load files from the cartridge image itself (e.g. instruction manual, basic, extended basic programs)

Stevie requires SAMS as it is designed for handling big files (e.g. tested with 100Kb-500Kb file), hence my question on pass-through.

 

[+OLD CS1]

I definitely see some interesting opportunities here.  Am I wrong to think of this like a far more functional MINIMEM DSR found in the Mini Memory module, using ROM space instead of RAM, as well as a number of BASIC support sub-programs directed at the module's ROM filesystem?

 

A read-only solid-state disk for the cartridge port?  As well, since it appears to occupy CRU space, it would not be functional with QI consoles?

[+RXB]

31 minutes ago, OLD CS1 said:

I definitely see some interesting opportunities here.  Am I wrong to think of this like a far more functional MINIMEM DSR found in the Mini Memory module, using ROM space instead of RAM, as well as a number of BASIC support sub-programs directed at the module's ROM filesystem?

 

A read-only solid-state disk for the cartridge port?  As well, since it appears to occupy CRU space, it would not be functional with QI consoles?

The DSR in the Mini Memory is a GPL DSR, I used the same one from Miller Graphics to make a GRAM DISK, but also one for RAMDISK in 32K.

I did a demo using this and put 532K into SAMS doing this in that demo.

[+FALCOR4]

The HRB4000B is a PEB card and not a sideport attachment but, if you wanted to use it you could split the card into two (two CRU addresses), use one as a RAMDISK and then put your custom DSR into the other.  You would have 6k of writable DSR space (actually 12k if you want to "trampoline" between two pages) and you would have access to half of the memory that is on the card for apps/etc.  Just another thought for the heap.

[+FarmerPotato]

Wow, this is more technology than I guessed was out there. 
 

my use case is to put a 8K EPROM DSR in my FORTI or FORTI2 sidecars.
 

You have a game cartridge plugged in. You go to BASIC, load CONFIG from built in DSR. Run that to configure FORTI sound system. Then BYE and play the game. Sound through >8400 is translated in the way you selected.
 
 

you might choose to map voice 1 to some instrument and voice 2 to another.
 

If this works out with how the game was programmed to use voices, you get nice music. Think of Alpiner. Or the TOD theme song. 

 

it has to be a sidecar ROM to work on a standalone console,  with a game cartridge already plugged in. 

 

(The DSR skips the power up reset the second time through. ) 

Edited July 12, 2021 by FarmerPotato

[+acadiel]

On 7/10/2021 at 3:19 AM, retroclouds said:

ROMDSK is an amazing project and am very interested in it. Are there any details on progress/current state?

Can you share details on the sidecar PCB? Will it have pass-through?

 

My use case is a bit different. I’m currently working on my 80 columns editor Stevie (64K cartridge image for finalGROM) and want to have the option to load files from the cartridge image itself (e.g. instruction manual, basic, extended basic programs)

Stevie requires SAMS as it is designed for handling big files (e.g. tested with 100Kb-500Kb file), hence my question on pass-through.

 

It's another thing on the pile... we simply need to make a pass thru DSR board for the side with the ROMDisk DSR ROM on it.  Fred had something mocked up - but it should be a super simple board for someone to do (if they have the time.)

 

Fred might want to author the utility to actually build the ROM - I haven't checked with him yet.  He might make it part of TI99Dir - or someone else can take a stab at it based on the specs.