+FarmerPotato Posted March 3, 2021 Share Posted March 3, 2021 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. 3 Quote Link to comment Share on other sites More sharing options...
Reciprocating Bill Posted March 4, 2021 Share Posted March 4, 2021 (edited) 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 4 Quote Link to comment Share on other sites More sharing options...
+acadiel Posted March 4, 2021 Share Posted March 4, 2021 @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. 3 1 Quote Link to comment Share on other sites More sharing options...
Asmusr Posted March 4, 2021 Share Posted March 4, 2021 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? 1 Quote Link to comment Share on other sites More sharing options...
Tursi Posted March 4, 2021 Share Posted March 4, 2021 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 4 1 Quote Link to comment Share on other sites More sharing options...
+acadiel Posted March 4, 2021 Share Posted March 4, 2021 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). 7 Quote Link to comment Share on other sites More sharing options...
+FarmerPotato Posted March 5, 2021 Author Share Posted March 5, 2021 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... Quote Link to comment Share on other sites More sharing options...
+acadiel Posted March 6, 2021 Share Posted March 6, 2021 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! 4 Quote Link to comment Share on other sites More sharing options...
+retroclouds Posted July 10, 2021 Share Posted July 10, 2021 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. 2 Quote Link to comment Share on other sites More sharing options...
+OLD CS1 Posted July 10, 2021 Share Posted July 10, 2021 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? 1 Quote Link to comment Share on other sites More sharing options...
RXB Posted July 10, 2021 Share Posted July 10, 2021 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. 3 Quote Link to comment Share on other sites More sharing options...
+FALCOR4 Posted July 10, 2021 Share Posted July 10, 2021 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. 4 Quote Link to comment Share on other sites More sharing options...
+FarmerPotato Posted July 12, 2021 Author Share Posted July 12, 2021 (edited) 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 1 Quote Link to comment Share on other sites More sharing options...
+acadiel Posted December 27, 2021 Share Posted December 27, 2021 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. 1 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.