Jump to content
IGNORED

SAMS and TI Extented Basic


fabrice montupet

Recommended Posts

I know that the subject regularly comes back here, the proof that there is a real and significant expectation for the users: The SAMS management under TI Extended Basic.
I would like to know if there a project under development that will add assembly SAMS access subroutines? Maybe I missed an response to this question in a thread. In this case, I'm sorry for the duplicate question. If not, please someone can tell me?
I well know that RXB offers this feature but even if at a time I was tempted by this (however good) language, I finally never used it. For my own use the lack of being able to compile programs, like XB256/XB compile do very fine, makes forget all the features RXB offers.

  • Thanks 1
Link to comment
Share on other sites

          SAMS           subprogram                            PAGE  S1
          -------------------------------------------------------------
 
          Format         CALL SAMS(address-boundry,page-number[,...])
 
                         CALL SAMS(address-boundry,numeric-variable
                         [,...])
                           
                         CALL SAMS(command [,...])

 
          Description
 
          The SAMS command will only work with a SAMS memory card.
          The address-boundry is a value in Hexadecimal denoted by
          2 is >2000 or 3 is >3000 or A is >A000 or D is >D000  
          EXAMPLE: CALL SAMS(3,page-number[,...])
          This 3 stands for >3000 hexidecimal address boundry.
          CALL SAMS uses boundry symbols upper case only.   
          i.e. 2 = >2000, 3 = >3000, A = >A000, B = >B000, C = >C000,
          D = >D000, E = >E000 and F = >F000 
          SAMS turns on the read/write lines of SAMS mapper registers          
          stores the value into the mapper register chosen. Less wasted 
          pages results in more memory available.Page numbers can be 
          from 0 to 16383 so it is hard to explain this easy. 
           See 16383 would be >FFFF hexidecimal 64 Meg SAMS. Pages 0 to 
          255 would be a 1 Meg SAMS, Pages 256 to 511 would be a 2 Meg 
          SAMS, so on up to page 7935 to 8191 would be 32 Meg SAMS.
           Pages 8192 to 16383 would be above 32K Meg SAMS so RXB 2020
          handles 64 Meg SAMS, but not tested above 32 Meg yet.
          (*Note: 16384 to 32767 would be for above 32 Meg to 64 Meg.)
           A addtional new feature in 2020 RXB SAMS is use of upper 24K
          memory can now be switched, but of course care must be taken
          or will crash XB by removing the program running SAMS from 
          upper 24K. Imagine 8 Meg XB program swapping lines. 
           The order of changing 4K pages does not matter thus a
          CALL SAMS(A,55,3,34) example is put 4K page 55 SAMS Memory 
          at >A000 and 4K page 34 at >3000

          Original SAMS commands like ON, OFF, MAP or PASS still work.
          "ON" turns on Mapper Registers. 
          "OFF" turns off Mapper Registers.
          "MAP" turns on Map Mode so pages can be changed.
          "PASS" default mode making the SAMS just like a normal 32K.          


         
 

  • Like 1
  • Confused 2
Link to comment
Share on other sites

          PLOAD          subprogram                            PAGE  P5
          -------------------------------------------------------------
 
          Format         CALL PLOAD(memory-boundry,"access-name")
 
                         CALL PLOAD(contant,string-variable)
 
          Description
 
          The PLOAD subprogram loads ONLY program image files created
          by PSAVE. PLOAD is the opposite of PSAVE. PLOAD is a faster
          version of CALL LOAD. PLOAD has the speed of a hidden loader
          and is much easier to use. PLOAD loads any 4K boundry in 32K.
           Memory boundries are 2, 3, A, B, C, D, E, F (upper case).
          i.e. 2 is >2000 or 3 is >3000 or A is >A000 up to F is >F000
          Removing the zeros made more sense then adding 3 zeros.
           Unlike CALL LOAD the PLOAD and PSAVE subprogram will work
          without CALL INIT being used first. Remember to turn on the
          interrupts if the program has them. Or the program support
          will not work. See ISROFF and ISRON.
          NOTE: 4K of VDP memory MUST be free for PLOAD to function or
                a memory full error will result. Always place the
                PLOAD command at the top of the RXB program.
 
          Programs
 
          This line loads a previously | >100 CALL PLOAD(2,"DSK2.MOUSE
          saved programs image files.  | ",3,"DSK2.MOUSE2")
          This line turns on the mouse | >110 CALL LINK("MSON")
          (program would continue here)|
                                       |
          This line load a previously  | >100 CALL PLOAD(B,"DSK1.DUMP"
          saved program image file.    | )
          This line turns on interrupt | >110 CALL ISRON(16384)
          within program.              |
          This line links to support   | >120 CALL LINK("DUMPIT") ! 
          address DUMPIT routine.      | link to Program Support
                                       |

Link to comment
Share on other sites

          PLOAD             subprogram                         PAGE  P6
          -------------------------------------------------------------

          PLOAD is faster then CALL LOAD as it loads Program Image vs
          LOAD which is stuck with slow uncompressed DF 80 files.


          Options
          SAMS users will find this a easy way to load RXB AMS support
          into lower 8K.
          EXAMPLE:
                  >100 Z$="DSK1.PAGE" 
                  >110 FOR L=0 TO 15 STEP 2
                  >120 CALL SAMS(2,L,3,L+1)
                  >130 CALL PLOAD(2,Z$&STR$(L),3,Z$&STR(L+1))
                  >140 NEXT L
                  >150 CALL XB("DSK1.MAINPROGRAM",1) 
      
           The above program would load RXB SAMS pages 0 to 15 into
           SAMS memory from files named PAGE0 to PAGE15 on disk 1. 
           Then would set CALL FILES 1 and RUN "DSK1.MAINPROGRAM" 
           with 64K of Assembly support for RXB. (16x4K=64K)

          See SAMS, ISROFF, ISRON, EXECUTE, and MOVES.

Link to comment
Share on other sites

2 hours ago, fabrice montupet said:

I know that the subject regularly comes back here, the proof that there is a real and significant expectation for the users: The SAMS management under TI Extended Basic.
I would like to know if there a project under development that will add assembly SAMS access subroutines? Maybe I missed an response to this question in a thread. In this case, I'm sorry for the duplicate question. If not, please someone can tell me?
I well know that RXB offers this feature but even if at a time I was tempted by this (however good) language, I finally never used it. For my own use the lack of being able to compile programs, like XB256/XB compile do very fine, makes forget all the features RXB offers.

Just that you should try something before you poo poo on it!

Do you have any way to load 32Meg of Assembly or anything on SAMS so easy?

I will wait to see something so easy to use compiled or not.

 

  • Confused 2
Link to comment
Share on other sites

23 minutes ago, fabrice montupet said:

You disappoint me. I often said that RXB was a good language but it doesn't corresponds to my needs. Please, accept it and don't make me say what I never  said.

 

 

RXB is just XB with added routines, and not hard to add RXB CALL SAMS to XB 110 and I provide the source code in GPL and Assembly to do so in RXB for years now.

I just ask that you give credit to me for what I have done and you can use my GPL routines for your own version of XB with SAMS support.

Link to comment
Share on other sites

11 minutes ago, fabrice montupet said:

I asked if someone is currently developing assembly routines that support SAMS under TI Extended Basic that will can be compiled with the compiler embedded with XB256.  I never said that I will develop such routines.

 

To bad I have a working proven system that was first released in 2001 that would be over 20 years ago, but you want something not done or completed yet.

You would think someone in 20 years could come up with something?

Wait what is wrong with mine?

Link to comment
Share on other sites

You make a good job and I'm sure that you have pleasure to regularly add functions to RXB but it clearly doesn't suits to every TI extended Basic programmers. As I already said, RXB programs can't be compiled, so they can't be simply published as stand alone as E/A5 programs like many other XB programs with XBGDP. For me, it is a real lack.
I will not wait 20 years (not sure I will still be among us in 20 years and able to use my lovely 99/4A ), because the SAMS support would just permits me some acceleration access to DATAs in my programs that are currently working using disk files operations. I am already happy with XBGDP,  SAM support would just be the icing on the cake. I can live without SAMS support but not without the XB256 features and its great compiler.
I am not alone hoping SAMS support with Extended Basic, maybe it will be developed soon or not, let us see.

 

Edited by fabrice montupet
Link to comment
Share on other sites

RXB is a base to use for last 20 years? Why the insistence on using 30-year-old XB 110 is silly.

Might as argue why use compiler at all?

Just as silly of an argument.

Like why make new games or any software? 

Just stick with the oldest on purpose not that it is better but that it is the oldest?

Not like XB256 will work with only a console like XB or RXB can do....what exactly is the main argument for not compiling RXB?

Same commands mostly and you want SAMS support....just such a weird viewpoint to an obvious answer.

  • Confused 1
Link to comment
Share on other sites

28 minutes ago, RXB said:

RXB is a base to use for last 20 years? Why the insistence on using 30-year-old XB 110 is silly.

Might as argue why use compiler at all?

Just as silly of an argument.

Like why make new games or any software? 

Just stick with the oldest on purpose not that it is better but that it is the oldest?

Not like XB256 will work with only a console like XB or RXB can do....what exactly is the main argument for not compiling RXB?

Same commands mostly and you want SAMS support....just such a weird viewpoint to an obvious answer.

Why the insistence on pushing RXB on Fabrice Montupet, when he was CLEAR that he did NOT want it, is silly!

Your shooting yourself in the foot! Even when you are being 100% correct about RXB!

I must say that when I see how you react, I am hesitant to start to using RXB. What if I say the "wrong" thing! Ask a stupid question! Hmmm, better to stay safe ;) PS! Not questions, just what I think. And maybe something you can consider or maybe not! Just a friendly thought!

But in the end, "You do you and I do me!"
 

  • Like 2
Link to comment
Share on other sites

53 minutes ago, RXB said:

RXB is a base to use for last 20 years? Why the insistence on using 30-year-old XB 110 is silly.

Might as argue why use compiler at all?

Just as silly of an argument.

Like why make new games or any software? 

Just stick with the oldest on purpose not that it is better but that it is the oldest?

Not like XB256 will work with only a console like XB or RXB can do....what exactly is the main argument for not compiling RXB?

Same commands mostly and you want SAMS support....just such a weird viewpoint to an obvious answer.

You're boring me.  You say about anything... I said that I use XB256 (since many many years), it is always updated, I use the excellent 2018 "Jewel" version.
I don't want to waste anymore time to talk to you. You're unable to accept that someone don't use your RXB and it is not the first time that I notice that on AtariAge.
All what you've achieved is to show about you an aggressive and obtuse person.  I will stop to follow all your threads.

  • Like 1
Link to comment
Share on other sites

I have been mulling the idea of developing assembly language support routines for XB to access the SAMS card.

As a matter of fact I now may have an acute need to do so because I am hitting a wall with my current mixed XB/assembly development project where I am running out of memory despite having used the entire lower 8K of the expansion RAM in addition to the upper 24K, with only 2K left and lots to do still.

The main issue with the SAMS is that one can only store data in it but it does not solve the problem of running out of program space in XB, unlike assembly where you could just swap code sections at will.

Could there be a way to swap XB code sections between the SAMS and the expansion RAM?

  • Like 6
Link to comment
Share on other sites

3 minutes ago, Vorticon said:

I have been mulling the idea of developing assembly language support routines for XB to access the SAMS card.

As a matter of fact I now may have an acute need to do so because I am hitting a wall with my current mixed XB/assembly development project where I am running out of memory despite having used the entire lower 8K of the expansion RAM in addition to the upper 24K, with only 2K left and lots to do still.

The main issue with the SAMS is that one can only store data in it but it does not solve the problem of running out of program space in XB, unlike assembly where you could just swap code sections at will.

Could there be a way to swap XB code sections between the SAMS and the expansion RAM?

https://www.unige.ch/medecine/nouspikel/ti99/superams.htm#High-level

 

Quote

Brad Snyder created "XBpacker", an utility that allows to store several Extended Basic programs in the SuperAMS card, or even one huge XB program written in a modular fashion.

 

Haven’t seen this program but if it’s out there, perhaps it fits your purpose or at least the ideas behind could be utilized if you decide to build something similar.

  • Like 4
  • Thanks 1
Link to comment
Share on other sites

16 minutes ago, Vorticon said:

I have been mulling the idea of developing assembly language support routines for XB to access the SAMS card.

As a matter of fact I now may have an acute need to do so because I am hitting a wall with my current mixed XB/assembly development project where I am running out of memory despite having used the entire lower 8K of the expansion RAM in addition to the upper 24K, with only 2K left and lots to do still.

The main issue with the SAMS is that one can only store data in it but it does not solve the problem of running out of program space in XB, unlike assembly where you could just swap code sections at will.

Could there be a way to swap XB code sections between the SAMS and the expansion RAM?

It's a good news ?  Hope that you'll have free time to begin this project.

Data only storage would already be a great solution for programs manipulating a large database.

  • Like 1
Link to comment
Share on other sites

14 minutes ago, retroclouds said:
Quote

Brad Snyder created "XBpacker", an utility that allows to store several Extended Basic programs in the SuperAMS card, or even one huge XB program written in a modular fashion.

Haven’t seen this program but if it’s out there, perhaps it fits your purpose or at least the ideas behind could be utilized if you decide to build something similar.

Thank you for this information. I never saw this "XBpacker" around. Using it would be an other good solution for very large programs.

  • Like 1
Link to comment
Share on other sites

I have found this very interesting information:

 

From MICROREVIEWS for August 1995 MICROpendium by Charles Good

XB PACKER v1.2 by Brad Snyder

This utility allows users to make practical use of an AMS 128K or 256K memory expansion card.  With XB Packer you can load up to 10 XB programs into a 256K AMS card (5 into a 128K card).  These XB  programs all reside in bank switched CPU memory and can be run in any of several ways.  You can manually switch memory banks from XB command mode and enter RUN, or you can run the programs from XB Packer's menu by entering the number next to the program's menu listing, or let the programs automatically call and run each other.
 I find XB Packer really user friendly.  When you turn on your system you run the EA5 program ABOOT to set up the AMS card.  Then you go back to the title screen, insert the XB module, and run XB Packer from XB.  Once XB Packer is loaded you can use SHIFT/FCTN to change memory banks and a little display at the top of the screen tells you which of the 10 (or 5) banks you are in.  From XB command mode go to bank 1 and enter OLD DSK1.XBPROG#1.  Then SHIFT/FCTN to bank 2 and OLD DSK1.XBPROG#2, etc, loading XB programs into as many of the 10 banks as you want.  At any time you can press SHIFT/CTRL to bring up a menu from which you can RUN a program in any bank.  You can put custom titles in this menu to specify the name of the program in each bank.  When you have loaded all the banks you want you can, with one command mode CALL LINK, save all the banks at once back to disk along with their menu titles in a special format.  Next time you use XB Packer you can, with another CALL LINK, automatically load all the XB programs and their menu entries from disk (or ramdisk or hard drive) back into their repective memory banks, all in one continuous operation.  
 Thus, once you get a group of XB programs set up the way you want them it is never again necessary to load them manually one at a time into each memory bank.  The autoload of a group of programs can be set up so that a program in a specified bank immediately starts running after all banks are loaded. You also have the option of displaying the menu of program titles after an autoload so the user can select which program to run first. At any time from a running program pressing SHIFT/CTRL will get you back to the menu.
 Any program in any bank acts as if it were a self contained XB program.  You can stop a running program with FCTN/4, edit the program and save it to disk, OLD in another program, etc. You can then switch banks from command mode by pressing SHIFT/FCTN and RUN or edit programs in other banks.  XB Packer seems compatible with the various gram based extended extended basics.  I have tried XB Packer with TI XB enhanced with Art Green's GUMS, with RXB v1002, and with Tony Kneer's XB v2.3 all with no obvious incompatibilities.
 Probably the most practical use for XB Packer is with a series of XB programs that load and run each other, programs that contain statements like RUN "DSK1.NEXTPROG" as part of their code.  To make this work just replace each RUN "DSK1.NEXTPROG" with CALL LINK("BANK",x) where x is a memory bank number.  When a running under XB Packer reaches this code, XB Packer will switch to the specified bank and immediately RUN the program in that bank. Having XB programs call other XB programs this way is very fast, faster than RUN from ramdisk and much faster than from floppy disk.
 There are a couple of limitations to XP Packer.  One- you can ONLY load runable XB programs into the AMS mamory banks when using XB Packer. If your XB program reads data files or assembly language files, these files still have to be on a disk or ramdisk.  Two- XB programs run under XB Packer can't have any imbeded assembly code.  If you RUN an XB program with imbeded assembly code under XB Packer the program will appear to run properly, but the assembly code will overwrite XB Packer so that bank switching is no longer possible.  If a CALL LINK to another bank is attempted you will get an XB error message.  This is a significant limitation.  Most of the better XB packages that load parts of themselves into memory as needed have assembly calls. This is true of Bill Gaskill's Mail List Manager, which would be a great candidate for running under XB Packer except for a little bit of assembly code found in only one of its separate XB program pieces. If an XB program listing says SYSTEX near the beginning this means the program contains assembly code and probably won't properly bank switch to other programs in other banks. I hope Brad Snyder will write a version of XB Packer that puts its assembly code in low memory.  This would result in less memory available for XB code but would not interfere with the imbeded assembly code code contained in many of the better XB programs available today.
 To use XB Packer you must have an AMS 128K or 256K card in the Pbox. The AMS card and XB Packer have been successfully tested by me on a 40 and 80 column (AVPC 80 column card) 99/4A system.  AMS doesn't work with a Geneve.  XB Packer is part of the software package given to purchasers of the AMS card.  Included is on disk documentation and a demo set of music XB programs all set up to batch load into the AMS and play from the XB Packer menu.  XB Packer is fairware and the author requests only a $5 donation.
ACCESS:
Brad Snyder (XB Packer author); 4260 Cedar Drive, Walnutport PA 18088 

 

  • Like 4
Link to comment
Share on other sites

2 hours ago, fabrice montupet said:

I have found this very interesting information:

 

From MICROREVIEWS for August 1995 MICROpendium by Charles Good


XB PACKER v1.2 by Brad Snyder

This utility allows users to make practical use of an AMS 128K or 256K memory expansion card.  With XB Packer you can load up to 10 XB programs into a 256K AMS card (5 into a 128K card).  These XB  programs all reside in bank switched CPU memory and can be run in any of several ways.  You can manually switch memory banks from XB command mode and enter RUN, or you can run the programs from XB Packer's menu by entering the number next to the program's menu listing, or let the programs automatically call and run each other.
 I find XB Packer really user friendly.  When you turn on your system you run the EA5 program ABOOT to set up the AMS card.  Then you go back to the title screen, insert the XB module, and run XB Packer from XB.  Once XB Packer is loaded you can use SHIFT/FCTN to change memory banks and a little display at the top of the screen tells you which of the 10 (or 5) banks you are in.  From XB command mode go to bank 1 and enter OLD DSK1.XBPROG#1.  Then SHIFT/FCTN to bank 2 and OLD DSK1.XBPROG#2, etc, loading XB programs into as many of the 10 banks as you want.  At any time you can press SHIFT/CTRL to bring up a menu from which you can RUN a program in any bank.  You can put custom titles in this menu to specify the name of the program in each bank.  When you have loaded all the banks you want you can, with one command mode CALL LINK, save all the banks at once back to disk along with their menu titles in a special format.  Next time you use XB Packer you can, with another CALL LINK, automatically load all the XB programs and their menu entries from disk (or ramdisk or hard drive) back into their repective memory banks, all in one continuous operation.  
 Thus, once you get a group of XB programs set up the way you want them it is never again necessary to load them manually one at a time into each memory bank.  The autoload of a group of programs can be set up so that a program in a specified bank immediately starts running after all banks are loaded. You also have the option of displaying the menu of program titles after an autoload so the user can select which program to run first. At any time from a running program pressing SHIFT/CTRL will get you back to the menu.
 Any program in any bank acts as if it were a self contained XB program.  You can stop a running program with FCTN/4, edit the program and save it to disk, OLD in another program, etc. You can then switch banks from command mode by pressing SHIFT/FCTN and RUN or edit programs in other banks.  XB Packer seems compatible with the various gram based extended extended basics.  I have tried XB Packer with TI XB enhanced with Art Green's GUMS, with RXB v1002, and with Tony Kneer's XB v2.3 all with no obvious incompatibilities.
 Probably the most practical use for XB Packer is with a series of XB programs that load and run each other, programs that contain statements like RUN "DSK1.NEXTPROG" as part of their code.  To make this work just replace each RUN "DSK1.NEXTPROG" with CALL LINK("BANK",x) where x is a memory bank number.  When a running under XB Packer reaches this code, XB Packer will switch to the specified bank and immediately RUN the program in that bank. Having XB programs call other XB programs this way is very fast, faster than RUN from ramdisk and much faster than from floppy disk.
 There are a couple of limitations to XP Packer.  One- you can ONLY load runable XB programs into the AMS mamory banks when using XB Packer. If your XB program reads data files or assembly language files, these files still have to be on a disk or ramdisk.  Two- XB programs run under XB Packer can't have any imbeded assembly code.  If you RUN an XB program with imbeded assembly code under XB Packer the program will appear to run properly, but the assembly code will overwrite XB Packer so that bank switching is no longer possible.  If a CALL LINK to another bank is attempted you will get an XB error message.  This is a significant limitation.  Most of the better XB packages that load parts of themselves into memory as needed have assembly calls. This is true of Bill Gaskill's Mail List Manager, which would be a great candidate for running under XB Packer except for a little bit of assembly code found in only one of its separate XB program pieces. If an XB program listing says SYSTEX near the beginning this means the program contains assembly code and probably won't properly bank switch to other programs in other banks. I hope Brad Snyder will write a version of XB Packer that puts its assembly code in low memory.  This would result in less memory available for XB code but would not interfere with the imbeded assembly code code contained in many of the better XB programs available today.
 To use XB Packer you must have an AMS 128K or 256K card in the Pbox. The AMS card and XB Packer have been successfully tested by me on a 40 and 80 column (AVPC 80 column card) 99/4A system.  AMS doesn't work with a Geneve.  XB Packer is part of the software package given to purchasers of the AMS card.  Included is on disk documentation and a demo set of music XB programs all set up to batch load into the AMS and play from the XB Packer menu.  XB Packer is fairware and the author requests only a $5 donation.
ACCESS:
Brad Snyder (XB Packer author); 4260 Cedar Drive, Walnutport PA 18088 

 

Damn.. this just gave me an idea with what I could possibly do with Foxit...

  • Like 1
Link to comment
Share on other sites

Cool ways to do something. Only difference is the problem of when using SAMS memory to switch SAMS memory where do you store the pages used?

RXB actually uses variables in VDP while GPL switches pages, this eliminated the problem of where without sacrificing some SAMS space.

This seems to be a big problem for Assembly to do.

Also, why all the memory managers are to be complicated and RXB has never had this issue.

1. Memory map is not in SAMS RAM.

2. Memory switcher is not in SAMS RAM.

3. Switching memory in SAMS RAM is not worth the problems in 1 and 2 above.

Link to comment
Share on other sites

When Chris from Asgard asked me to make access for his Memory card and handed me a 128K one (128K SAMS) I asked who else was working on it.

He got me in touch with Joe Delekto who really helped me out and quickly discovered the huge snag using any memory switching cards.

Where the hell is a safe spot to put the memory manager and switching routines.

Lower 8K? No as that is where you put your support for TI Basic and XB.

Upper 24K yea but where top of memory >FF00 would be bad for XB but best for TI Basic or Assembly.

Upper 24K yea but >A000 is used by XB so somewhere like >B000 would cause the least problem for XB or TI Basic or Assembly.

 

This is exactly why you do not see any standard for SAMS memory managers or the location of one in Assembly for 20 years.

Edited by RXB
Link to comment
Share on other sites

25 minutes ago, RXB said:

When Chris from Asgard asked me to make access for his Memory card and handed me a 128K one (128K SAMS) I asked who else was working on it.

He got me in touch with Joe Delekto who really helped me out and quickly discovered the huge snag using any memory switching cards.

Where the hell is a safe spot to put the memory manager and switching routines.

Lower 8K? No as that is where you put your support for TI Basic and XB.

Upper 24K yea but where top of memory >FF00 would be bad for XB but best for TI Basic or Assembly.

Upper 24K yea but >A000 is used by XB so somewhere like >B000 would cause the least problem for XB or TI Basic or Assembly.

 

This is exactly why you do not see any standard for SAMS memory managers or the location of one in Assembly for 20 years.

 

That is indeed an issue, the places I can think of:

1. Keep one SAMS page always mapped and store the mappings there, obviously that reduces the overall availability.

2. Store the pages mapped in scratchpad memory (that's an issue when doing XB, not so if you are running a standalone assembly language program, e.g. cartridge)

3. Use VDP memory (as you said)

4. Run FG99 cartridge in advanced mode and store the mappings there, aka. same as when storing in a supercart

5. In the DSR space if there's memory there, e.g. when using RAMDISK, ROS

 

Edited by retroclouds
  • Like 3
  • Thanks 1
Link to comment
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.
Note: Your post will require moderator approval before it will be visible.

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...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...