Jump to content
Sign in to follow this  
jrhodes

32k ramdisk program with filename, OPEN support?

Recommended Posts

Is there a 32k ramdisk utility that has support for saving and loading a file/program to the 32k, and accessing it via a filename?

In the archive i uploaded sometime ago, there is a 32k ramdisk program that i am using, and i can CALL LINK("SAVE") to put a program into the 32k, and CALL LINK("LOAD") to recall it.

What i would like though, is to be able to do CALL LINK("SAVE",FILENAME) to save to 32k, and CALL LINK("OPEN",FILENAME) to open it like it was a file on disk.

For instance, i could have a high score file stored in the 32k ram, and run the main game from tape.

The program would open the scores file from 32k, just like it would from disk.

So instead of OPEN #1:"DSK1.SCORES" i would do CALL LINK("OPEN",FILENAME) or something similar.

As long as i keep the power on, i could retain the scores file in the 32k.

 

Anyway, being able to treat the 32k like a real disk, with filenames and the like, would be pretty neat.

You could even store 2 seperate programs in the 32k, if they were both small enough.

 

----------------------------------

I really no longer care about the subject originally at hand.

As such, any further replies to this thread will go without reply from me.

Edited by jrhodes

Share this post


Link to post
Share on other sites

I have something that does exactly that and works with the SAMS too.

Share this post


Link to post
Share on other sites

I have something that does exactly that and works with the SAMS too.

 

Hi RXB,
Would you be able to provide more detail? This would be very useful for the following:
- I have added 32K in my console but with a bigger RAM (256K) that can be paged through unused 9901 outputs. The extra banks could be used as a storage device (needs battery backup)

- Been thinking of adding DSK emulation though the sideport with RAM and an Arduino with SD card capability. The RAM would be loaded with a modified TI Disk Controller ROM at startup by the Arduino providing reading/writing TI disk images on the SD card.

BTW there is also an Arduino shield with Ethernet and SD so maybe even a tiny TCP/IP stack would be possible :-)
Jochen

Share this post


Link to post
Share on other sites

Ok RXB 2015 has CALL BSAVE("DSK#.FILENAME") and CALL BLOAD("DSK#.FILENAME") these save or load the lower 8K to/from disk.

 

RXB 2018 removed these and replaced them with CALL PSAVE(address,"DSK#.FILENAME") and CALL PLOAD(address,"DSK#.FILENAME) these save or load boundary locations in 4K to/from disk.

There are boundaries at >2000, >3000, >A000, >B000, >C000, >D000, >E000 , >F000 which the 4K areas of the 32K in the TI99/4A

So instead of typing the entire address a shorthand exists as just the first digit or letter for the boundaries.

i.e. 2 = >2000 or C= >C000 or F = >F000 address

 

Example to save entire 32K to disk:

CALL PSAVE(2,"DSK5.MY2000",3,"DSK5.MY3000",A,"DSK5.MYA000",B,"DSK5.MYB000",C,"DSK5.MYC000",D,"DSK5.MYD000",E,"DSK5.MYE000",F,"DSK5.MYF000")

This single line will save the entire 32K to disk 5, and of course change PSAVE to PLOAD and it will load into 32K from disk 5

 

Thus PSAVE and PLOAD were originally designed for SAMS but will work fine with no SAMS needed too.

 

As for why not entire 32K single routine Program images routine?

We are limited to VDP size so 14K is max as you need screen and to read it, which means 3 files minimum for Program Image.

I did work on a Internal Fixed 255 file routine but was much slower, so opted for a broader solution that could be used with or without the SAMS.

Edited by RXB
  • Like 2

Share this post


Link to post
Share on other sites

I am going to demo in a week or so how to load Funnel Web, DM2000 and others all loaded into 32K of SAMS and switch programs and replay what they were doing then go back to where you left off.

Edited by RXB

Share this post


Link to post
Share on other sites

Rich, that sounds like a pretty neat feature, but that is not really what i was asking about.

I am not trying to save the 32K contents to disk.

 

I want to be able to refer to a file/program stored in the 32k as a file, with its own name.

say i have a program loaded into xb, and use the ramdisk program i uploaded here with the command CALL LINK("SAVE") to store it in the 32k.

I can recall it with CALL LINK("LOAD"), but it does not have a filename.

 

I want a way to give that file/program a name that i could use to refer to it, something like

32K.FILENAME instead of DSK1.FILENAME

Thus, i could refer to a file or program stored in the 32k ramdisk inside of a OPEN command, something like

OPEN #1:"32K.FILENAME"

 

Assuming the programs or files in question were small enough, i hope to be able to store multiple files / programs in the 32K and give them each a unique name.

So you could have both

32K.MYPROG

and

32K.TESTING

as two separate files or programs, both able to referenced by their unique filenames.

Edited by jrhodes

Share this post


Link to post
Share on other sites

Just where are you going to store all these names?

I am curious where all this memory is at to store the names?

Not to mention ADDRESS as they all have to have a starting address too.

Share this post


Link to post
Share on other sites

Original question: Is there a 32k ramdisk utility that has support for saving and loading a file/program to the 32k, and accessing it via a filename?

Answer: no, apparently

 

So there is no way to do what this topic asked.

OK then, end of topic.

Edited by jrhodes
  • Like 1

Share this post


Link to post
Share on other sites

You can sort of do what you want with the Editor/Assembler cartridge or Mini Memory, but I think with a maximum of 2 (maybe 3) files and limited to TI BASIC.

 

You can use the 4K of the Mini Memory module as a file named MINIMEM, and the upper 24K of the 32K memory expansion as a separate file named EXPMEM2. You *might* be able to use the lower 8K of the 32K memory expansion as a file named EXPMEM1 but I’m not sure if that works right or not (and it may work with Editor/Assembler but not Mini Memory - I’m not quite sure.)

 

That may be too limited for what you want to do though...

Share this post


Link to post
Share on other sites

Jrhodes,

 

Are you Jim Rhodes, formerly of the Lexington, KY Bluegrass group back in the 80's?

 

Anyways, back to your question. There is something similar, but not exact, to what you are asking if the source code is available. That would be the Myarc 512K DSR code. You could save programs in the memory of that memory expansion card. It had a DSR doing the file saving rather than a Call Link command. I think the DSR code (source??) is on whtech that may help if you need to custom write/borrow anything.

 

I think all you need to do is to rethink your approach on the Call Link (Save/Open) use. Either way, it will be a small section of assembly code and what you are doing is essentially paging memory in/out from what I gather.

 

Your assembly code can either use "assigned" memory areas to specific memory pages if you want to minimize overhead assembly code, or you can get elaborate consuming a whole lot of memory with File tables and File Descriptor records. Obviously, if you do not have to worry about bitmap tables and specific filenames, you can eliminate all the file lookup/location code and have hardcoded addresses to go to.

 

I think what you are describing isn't that hard, it is just how elaborate you want it to be. The more elaborate it is, the less space you are going to have for program storage, etc.

 

My 2 cents.

 

Beery

  • Like 1

Share this post


Link to post
Share on other sites

There was several programs that did something similar to what you want:

1. GRAM KRACKER had GRAMDISK that put files into the extra GRAM bank and you could recall them from a menu using a command CALL MENU

2. Assembly program PDISK that was phoney disk that could save a single XB program into lower 8K and you could recall it with CALL LINK("LOAD")

Here is a RXB demo using it.

 

Share this post


Link to post
Share on other sites

Here are two possibilities:

1 - The simplest is to combine the XB programs into a large XB program with a menu that lets you select a program. This could use all 24K of ram, and you could put stuff like high scores, players names, etc. into low memory via CALL LOAD or a special A/L subroutine.

2 - CALL LOAD(-31888,0,0,0,0) will turn off the 32K, which forces XB to run programs from VDP ram. The neat thing about this is you can still use the 32K for assembly routines. You could have a short A/L sub in low memory that can copy programs from VDP memory into ram, both high and low memory as needed. Another sub could find the program, put it into VDP memory, set the pointers in scratchpad and run the program. You'd have to have a name table so the subroutine could find the program in the table and see where it is in ram. One limitation of this is that the programs can be no larger than around 12K, but you could have almost 32K of memory in which to store them.

  • Like 1

Share this post


Link to post
Share on other sites

Has anyone written a GROM/GPL based DSR that uses SAMS as a volatile RAM disk? I know it wouldn't work with all those assembly programs that use a DSRLNK that doesn't scan GROM headers, but for building into a version of BASIC it should be fine.

Share this post


Link to post
Share on other sites

Has anyone written a GROM/GPL based DSR that uses SAMS as a volatile RAM disk? I know it wouldn't work with all those assembly programs that use a DSRLNK that doesn't scan GROM headers, but for building into a version of BASIC it should be fine.

Yep me.

RXB version 5.55 had CALL PDISK that used the Lower 8K as a RAMDISK.

(GPL version of XBRAMDISK that would save/load 8K XB programs into Lower 8K)

Later in RXB 2001 I released CALL AMSBANK that allowed switching out Lower 8K banks.

But instead of PDISK I uses GPL CALL MOVES that would move any type of memory to anytype of memory.

And created CALL BSAVE or CALL BSAVE to save/load using disk.

 

Now in RXB 2018 I have CALL PSAVE or CALL PLOAD that only does 4K save/load instead, but works with any RAM in 32K memory.

Edited by RXB

Share this post


Link to post
Share on other sites

Yep me.

RXB version 5.55 had CALL PDISK that used the Lower 8K as a RAMDISK.

(GPL version of XBRAMDISK that would save/load 8K XB programs into Lower 8K)

Later in RXB 2001 I released CALL AMSBANK that allowed switching out Lower 8K banks.

But instead of PDISK I uses GPL CALL MOVES that would move any type of memory to anytype of memory.

And created CALL BSAVE or CALL BSAVE to save/load using disk.

 

Now in RXB 2018 I have CALL PSAVE or CALL PLOAD that only does 4K save/load instead, but works with any RAM in 32K memory.

 

That's not a DSR, is it? I'm talking about something with an attached device name so you could use SAVE SAMS.MYPROG and OLD SAMS.MYPROG.

Share this post


Link to post
Share on other sites

 

That's not a DSR, is it? I'm talking about something with an attached device name so you could use SAVE SAMS.MYPROG and OLD SAMS.MYPROG.

Well my old PDISK was both a CALL and a DSR

CALL PDISK

and

OLD PDISK

or

SAVE PDISK

or even

LIST "PDISK"

all did the same thing, looked to see if a program was saved in PDISK and if a program was there would load it into XB.

If nothing was in PDSIK yet it moved the XB program into PDISK memory.

 

Now to clear PDISK you used a CALL LOAD(8192,0,0)

 

(RXB never needs a CALL INIT to use CALL LOAD as RXB does not check, was a stupid idea from TI to do that.)

Edited by RXB

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
Sign in to follow this  

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...