make certain part of extended ram invisible for SDX... how?

[Marius]

Hi!

 

I'm not a regular SDX user. From time to time I use it.

I have a battery backupped ramdisk, which I use for coding projects.

 

I have a 256K ramdisk configured (4x 64K blocks start pages are $23, $43, $63, and $a3)

 

The other 256K is free for use (4x 64K blocks start pages are $83, $A3, $C3 and $E3)

 

I do not want that any program or dos touches those first 256K, since there might be data on it that I do not want to be overwritten.

I know: it is my own responsibility to make a good backup of that data... but still, my question is:

 

Can I configure SDX in some way, that it only sees the 256K memory at page $83 and up?

 

I couldn't find this in the manual.

 

Thanks!

[atari8warez]

I don't think there's such a feature in SDX, it would have been nice to have it though. On a different note, why do you use a Ramdisk when there are flash memory card solutions around? (I am pretty sure you have some too). My IDE Plus 2 tested with RWTEST is 2.5 times faster then the SDX ramdisk, if speed is not the reason, what is?

Edited April 29, 2014 by atari8warez

[Marius]

I am coding 99% of the time and I have my partitions write protect. A lot of my projects do I/O on harddisk and I do not want to risk corruption of my partitions.

 

So I use a RAM disk but only half of it (the usual not used banks) to do temp. Saving of source and object files. My RAM disk is battery backupped, so I can even switch off atari and run 130xe software and keep RAM disk contents.

 

But as soon as I jump to SDX suddenly my entire RAM disk is on risk since I can not map out a certain part of it.

[1050]

What is your regular DOS flavor? I don't think you are going to get SDX to play fair, it will take what it is configured to by startup files but that only covers size concerning extent of system layout IIRC, and not individual control of specific banks as would be needed to protect the ramdisk contents set up by the prior DOS. Easier to make your regular DOS ramdisk avoid SDX banks used for system use - those could be the same as currently used for temp storage. Chances are you have much more control of individual banks used on your regular DOS than you can get with SDX. Just my two cents. Other option is to move the ramdisk contents to the hard drive while you run SDX.

[Marius]

Yes. Now I make sure I move everything indeed.

 

Most of the time I use XDOS. That is a very nice, and very small DOS written by Stefan Dorndorf.

 

I probably want something that is completely against SDX philosophy and technical design. I thought it must be possible, since you can configure almost anything, but I probably was wrong.

[flashjazzcat]

I'd advocate using a hard disk. If you're concerned about data corruption when testing programs, use a spare "scratch" CF card. That said, SDX uses extended banks "last first" in order to maximise compatibility with software which uses extended RAM without reference to SDX's allocation system. Indeed, if you run SDX in OSRAM and install minimal drivers, there's no reason for it to populate extended RAM at all.

Edited April 29, 2014 by flashjazzcat

[atari8warez]

Yes. Now I make sure I move everything indeed.

 

Most of the time I use XDOS. That is a very nice, and very small DOS written by Stefan Dorndorf.

 

I probably want something that is completely against SDX philosophy and technical design. I thought it must be possible, since you can configure almost anything, but I probably was wrong.

 

In my opinion you're absolutely right, SDX could (and depending on the user base demand for such a feature, should) allow the user to configure how much of the extended memory is reserved for it's own use. So far I've only seen you mentioning this so the chance of getting it implemented is, I would say slim at best, but who knows maybe Konrad has some free time in his hands otherwise you would have to do with the workarounds suggested by FJC above.

Edited April 29, 2014 by atari8warez

[flashjazzcat]

If all of the RAM accessed via PORTB is battery-backed, another logical approach would be to use SDX's own RAMdisk driver to format and access the RAMdisk. Providing the driver was always called with the same size parameters, this would ensure the non-volatility of its contents and guarantee that SDX itself would never attempt to use RAMdisk banks for any other purpose. Every time the RAMdisk driver is installed, the content will be the same as the last time the machine was powered down.

 

But in Marius's case, it rather seems that the RAMdisk is handled at the OS SIO level by some custom operating system (unless I misunderstand), and that the intention is to format it with a DOS 2.x compatible file system so it might be shared between SDX and other disk operating systems which are somehow preferable under certain circumstances. Since SDX is the operating system (unlike its disk-based predecessors), however, I wouldn't expect the inability to "map out" areas of hardware to be seen as a major deficiency. SDX already provides hands-down the best memory management facilities of any A8 DOS, and is the only DOS I'm aware of which doesn't require applications to perform a song and dance in order to establish which extended banks are free and not occupied by file system drivers, buffers, or RAMdisk sectors.

 

SDX maintains a table of free extended banks (all banks in the system, minus DOS allocated banks) which - as well as being user-accessible - can be modified by allocating extended banks via DOS's API. In fact it would probably be easy to write a small tool which silently allocates all the desired banks at the beginning of a session, so that DOS won't allocate them again.

 

Of course, regardless of how carefully DOS and the user manage extended banks, any application which does not observe the SDX memory allocation mechanism and which instead performs a hard-scan for PORTB banking bits will be capable of trashing not only SDX but any extended banks which DOS has been asked to avoid. Something to bear in mind when testing software which is capable of more serious mischief (i.e. trashing hard disk partitions).

Edited April 29, 2014 by flashjazzcat