Megalextoria
Retro computing and gaming, sci-fi books, tv and movies and other geeky stuff.

Home » Archive » net.micro.atari16 » Using RAM disk with the DRI C-Compiler
Show: Today's Messages :: Show Polls :: Message Navigator
E-mail to friend 
Switch to threaded view of this topic Create a new topic Submit Reply
Using RAM disk with the DRI C-Compiler [message #268816] Tue, 25 February 1986 14:12 Go to next message
Anonymous
Karma:
Originally posted by: fxl

<pre>
Article-I.D.: ucbvax.8602251919.AA00661
Posted: Tue Feb 25 14:12:49 1986
Date-Received: Fri, 28-Feb-86 06:35:21 EST
Sender: usenet@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 20


I've had pretty good luck in speeding up the compile-link time by using
a 285K RAM disk. A RAM disk of that size is possible when you have TOS
in ROM, but no 1Meg upgrade. My total compile-link time went from 8minutes
to 2:30 minutes, by telling the compiler, assembler and linker to use C:
for temporary files, putting the libraries on C:, plus a few other small
files. It took me quite some time to figure out how to do this, but it was
worth it. Of course, once I get my 1Meg upgrade I'll put everything into
RAM disk, and I expect the compile-link time will go down even more.

Have any of you had similar experiences? I'll post my batch files, plus
a list of the files in RAM disk, if there is interest.

Franz Lanzinger
Advance Decision Systems
201 San Antonio Circle #286
Mountain View CA 94040
(415) 941 3912
fxl@ads-unix
(formerly fxl@aids-unix)
</pre>
Re: Using RAM disk with the DRI C-Compil [message #268836 is a reply to message #268816] Thu, 27 February 1986 10:16 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: pwp

<pre>
Article-I.D.: iuvax.54600005
Posted: Thu Feb 27 10:16:00 1986
Date-Received: Sat, 1-Mar-86 16:22:17 EST
References: <12317327@ucbvax.UUCP>
Lines: 8
Nf-ID: #R:ucbvax:-1231732700:iuvax:54600005:000:370
Nf-From: iuvax!pwp Feb 27 10:16:00 1986


Which RAM disk are you using? With the public domain RAM disk I am
using, things don't work after a few compiles. Removing all files
from the disk before each recompile seems to keep it going longer
but that is not convienent if you also put libraries on it.
(I tried to mail this, but my machine does not know how to reach you.)

Paul Purdom (purdom@indiana on CSnet).
</pre>
Re: Using RAM disk with the DRI C-Compil [message #268855 is a reply to message #268816] Sat, 01 March 1986 18:01 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: bammi

<pre>
Article-I.D.: cwruecmp.1424
Posted: Sat Mar 1 18:01:09 1986
Date-Received: Sun, 2-Mar-86 18:59:28 EST
References: <12317327@ucbvax.UUCP> <54600005@iuvax.UUCP>
Organization: CWRU Dept. Computer Eng., Cleveland, OH
Lines: 32

>
> Which RAM disk are you using? With the public domain RAM disk I am
> using, things don't work after a few compiles. Removing all files
> from the disk before each recompile seems to keep it going longer
> but that is not convienent if you also put libraries on it.
> (I tried to mail this, but my machine does not know how to reach you.)
>
> Paul Purdom (purdom@indiana on CSnet).

*** REPLACE THIS LINE WITH YOUR MESSAGE ***
The problem is not with the Ramdisk but with the version of tos you
are using. The later versions anf the rom tos fix the problem. One
caution about using floppies or ram disk to compile and link is
that you should have plenty of free space for temp. files. The linker
in particular does not tell you when it runs out of temp file space.
You realize that this happened when you end up with a ridiculusly
large/small .prg file after running relmod on the .68k file.

Will someone from Atari on this net hold the programmers who
wrote link68 and ar68 upside down for a little while for me :-).
Seriously, when are you going to upgrade these two very weak links in
the dev system? My biggest objections are the speed due to the brain
damaged ar format (at least provide a ranlib), link not understanding
pathnames, and link not informing the user of some errors. In fact i
see no reason to have a relmod at all, link should generate the
correct output (Gemdos is not cp/m68k remember!).
--
Jwahar R. Bammi
Usenet: .....!decvax!cwruecmp!bammi
CSnet: bammi@case
Arpa: bammi%case@csnet-relay
CompuServe: 71515,155
</pre>
Re: Using RAM disk with the DRI C-Compiler [message #268858 is a reply to message #268816] Sat, 01 March 1986 18:53 Go to previous messageGo to next message
luscher is currently offline  luscher
Messages: 7
Registered: May 1985
Karma: 0
Junior Member
<pre>
Article-I.D.: nicmad.8603012353.AA01723
Posted: Sat Mar 1 18:53:31 1986
Date-Received: Sun, 2-Mar-86 19:20:07 EST
References: <8602251919.AA00661@ucbvax.berkeley.edu>
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: /etc/organization
Lines: 16

I have done the 1meg upgrade for myself and a couple of others, but I
have yet to find a reasonable ramdisk! I am going to be doing a lot
of C and it sounds worthwhile.

Whose ramdisk do you use and where can I get one?? If it is public
domain can i send you some cash for your trouble in making a copy for
me? If it isn't public domain where can I buy one?

Also any pointers on how you set things up to use the disk would
be appreciated!

Thanks.

--
Jim Luscher / Nicolet Instruments / Oscilloscope Div.
5225 Verona Rd Bldg-2 / Madison Wi 53711 USA / 608/271-3333x2274
</pre>
Re: Using RAM disk with the DRI C-Compiler [message #282947 is a reply to message #268816] Sun, 02 March 1986 20:06 Go to previous messageGo to next message
esfraga is currently offline  esfraga
Messages: 10
Registered: June 2013
Karma: 0
Junior Member
<pre>
Article-I.D.: water.8603030106.AA10902
Posted: Sun Mar 2 20:06:14 1986
Date-Received: Sat, 8-Mar-86 05:25:49 EST
References: <8603012353.AA01723@nicmad.UUCP>
Sender: usenet@ucbvax.BERKELEY.EDU
Organization: U. of Waterloo, Ontario
Lines: 232

In article <8603012353.AA01723@nicmad.UUCP> you write:
> I have done the 1meg upgrade for myself and a couple of others, but I
> have yet to find a reasonable ramdisk! I am going to be doing a lot
> of C and it sounds worthwhile.
>
> Whose ramdisk do you use and where can I get one?? If it is public
> domain can i send you some cash for your trouble in making a copy for
> me? If it isn't public domain where can I buy one?
>
> Also any pointers on how you set things up to use the disk would
> be appreciated!
>
> Thanks.
>
> --
> Jim Luscher / Nicolet Instruments / Oscilloscope Div.
> 5225 Verona Rd Bldg-2 / Madison Wi 53711 USA / 608/271-3333x2274

At the end of this message is the source for a 360k ramdisk.
I got it on the net a long time ago and have been using without
any problems for quite a while.

In terms of how I use it, it depends on what I am working on.
If I am working on ST Basic and 1st-word together, which I do
quite often, put both of them on the ramdisk. This allows me to
switch from one to the other very quickly (in seconds!). When
compiling, I put most of the compiler and linker on the ramdisk,
leaving the libraries on floppy. I also put ME on the ramdisk.
This leaves enough room on the ramdisk to put the source and
compile very quickly. Linking takes time but I find that I
usually compile a lot more than I link (finding syntax errors,
etc.). I also have a 512k ramdisk (changed the entries in the
BPB structure). However, I can't seem to find the source right
now. If you want the 512 k ramdisk, I can mail you the uuencoded
binary. In fact, I can also mail the uuencoded binary for the
360k ramdisk if you wish.

============ source for 360k ramdisk follows ============
/* RAM DISK ACCESSORY Version 1.3 - 1986 Feb. 1.

Original: Version 1.1 Gert Slavenburg, Mountain View, CA.

Modified: 1.2: Reginald Knighton (213) 473-5202 [voice].
improved performance by over a factor of 3

1.3: E S Fraga - cleaned some things up. Does not
copy A: on boot up any more. No beeping either.

For Atari 520ST with RAM extension to 1 MByte.
Link this program with accstart,%1,osbind,vdibind,aesbind

This is the first, experimental version of the RAMdisk. It should
be installed as a DESK ACCESSORY on the Bootdisk. Before re-booting,
and thus activating it, the menu entry "install disk" should be used
to install drive "D" with icon-label "RAMDISK". Then save the desktop to
make the newly installed drive permanent.
Now re-boot end enjoy. (write protect if you're paranoid - I am)

You may get annoyed by my trick to let the RAMdisk give a beep every
30 seconds. This was a debugging tool for me to see if it's still
alive, and I get worried now if I don't hear it anymore...
To remove it, just replace the "beep" statement in procedure "sleep".

known bugs :
1) GEMDOS refuses to do full diskette copy to/from the RAMdisk. Don't
know why it does that, since the BPB's are identical.

Lots of fun - Gert
*/

#include "portab.h"
#include "obdefs.h"
#include "define.h"
#include "gemdefs.h"
#include "osbind.h"

struct bpb
{ WORD recsiz, /* see BIOS:rwabs.c for more info */
clsiz,
clsizb,
rdlen,
fsiz,
fatrec,
datrec,
numcl,
bflags;
};

/* stupid AES binding arrays - what a drag */

int contrl[12]; /* better find out what's REALLY NEEDED */
int intin[128];
int ptsin[128];
int intout[128];
int ptsout[128];

/* the variables below are really serious */

typedef LONG (*PFL)(); /* define "pointer to function returning a long" */
typedef WORD (*PFW)(); /* define "pointer to function returning a word" */

PFL getbpb; /* pointer to the systems original getbpb function */
PFW mediach; /* pointer to the systems original mediach */
PFL rwabs; /* pointer to the systems original rwabs */

struct bpb rdiskbpb = { 512, 2, 1024, 7, 5, 6, 18, 351, 0 };
/* same as Single Sided microdiskette */

int data[184320]; /* 720 sectors of 512 bytes */
/* same as Single Sided microdiskette */


LONG RDgetbpb(dev)
WORD dev;
{
if (dev != 3)
return( (*getbpb)(dev) ); /* pass all non-RAMdisk to old handler */
else
{ return( &rdiskbpb ); /* return our bpb */
}
}

WORD RDmediach(dev)
WORD dev;
{
if (dev != 3)
return((*mediach)(dev)) ; /* pass all non-RAMdisk to old handler */
else
return( 0 ); /* RAMDISK media never changes */
}

LONG RDrwabs(rw,buf,count,recno,dev) /* see page 5 of The Hitchhiker's Guide */
WORD rw; /* to the BIOS, 26 August 1985 Version */

/* int *buf; */ /* <------- classic code */

register long *buf; /* <------- new code */
WORD count, recno, dev;
{
/* int i, *p; */ /* <------- classic code */

register int i; /* <------- new code, declare register */
register long *p; /* for speed */

if (dev != 3)
return( (*rwabs)(rw,buf,count,recno,dev) ); /* pass it on */
else
{ if (rw > 1) rw -=2; /* we never change media anyway */
while ( count > 0 )
{ p = &data[((long) recno) * 256L];/* both casts necessary - C068 bug */
if (rw==0) /* read */

/* for (i=0; i<256; i++) *buf++ = *p++; */ /* <--- classic code */

for(i=0; i<32; i++) /* NEW read/write 16 bytes per loop cycle, */
{ /* 32 cycles for 512 bytes. Looking at the */
*buf++ = *p++; /* .s files, DRI C generates very tight code */
*buf++ = *p++; /* for this construct... */
*buf++ = *p++; /* */
*buf++ = *p++; /* modification by Reg Knighton */
}
else /* write */

/* for (i=0; i<256; i++) *p++ = *buf++; */ /* <--- classic code */

for(i=0; i<32; i++) /* NEW code for write, see read block above */
{
*p++ = *buf++;
*p++ = *buf++;
*p++ = *buf++;
*p++ = *buf++;
}

count--; recno++;
}
return(0L);
}
}

install() /* take over DISKIO vectors, MUST RUN AS SUPERVISOR */
{
long *bpbvect = 0x472;
long *rwvect = 0x476;
long *mcvect = 0x47e;
long *devset = 0x4c2;

getbpb = (PFL) *bpbvect; /* save old vectors */
mediach = (PFW) *mcvect;
rwabs = (PFL) *rwvect;
*bpbvect = RDgetbpb; /* install new ones */
*mcvect = RDmediach;
*rwvect = RDrwabs;
/* vectors set-up, include in deviceset : */
*devset = (*devset) | (0x8L);

}

sleep() /* sleep forever */
{ int i;
while (1)
{ i = evnt_timer(30000,0); /* wait 30 Sec. */
/* Bconout(2,7); /* BEEP to show I'm alive */
}
}

main()
{
register long int *ip;
register long cnt;

appl_init(); /* this is needed even to link - Yack !!!!!!! */

/*
* don't need to do this -- we just zero out the area.
* ESF
*/
/* Rwabs(0,data,720,0,0); /* copy drive A: into RAMdisk data array */

cnt = 92165;
ip = (long *) data;
while( cnt-- )
*ip++ = 0; /* zero out the whole thing */

xbios(38,install); /* INSTALL vectors in SUPV MODE */
sleep(); /* accessories never end ..... */
}

--

Eric S Fraga || esfraga@water.uucp
Dept of Computer Science || esfraga%water@waterloo.csnet
U of Waterloo || esfraga%water%waterloo.csnet@csnet-relay.arpa
</pre>
Re: Using RAM disk with the DRI C-Compiler [message #282949 is a reply to message #268816] Sat, 08 March 1986 02:38 Go to previous message
esfraga is currently offline  esfraga
Messages: 10
Registered: June 2013
Karma: 0
Junior Member
<pre>
Article-I.D.: water.257
Posted: Sat Mar 8 02:38:34 1986
Date-Received: Sat, 8-Mar-86 21:07:04 EST
References: <8603012353.AA01723@nicmad.UUCP> <8603030106.AA10902@water.UUCP>
Reply-To: esfraga@water.UUCP (Eric S Fraga)
Organization: U of Waterloo, Ontario
Lines: 16
Summary:


By the way, there was a slight bug in the Ramdisk source that I posted
(by mistake as I was trying to REPLY to a message that seems to have
come from some mailing list...) to this newsgroup a little while ago.

The 'cnt' variable gets set to 92165. That value should have been

cnt = 92160;

Otherwise, too much memory gets cleared! Sorry for any problems this may
have caused.
--

Eric S Fraga || esfraga@water.uucp
Dept of Computer Science || esfraga%water@waterloo.csnet
U of Waterloo || esfraga%water%waterloo.csnet@csnet-relay.arpa
</pre>
  Switch to threaded view of this topic Create a new topic Submit Reply
Previous Topic: Ram Upgrades
Next Topic: Foul language
Goto Forum:
  

-=] Back to Top [=-
[ Syndicate this forum (XML) ] [ RSS ] [ PDF ]

Current Time: Fri Mar 29 02:30:22 EDT 2024

Total time taken to generate the page: 0.01658 seconds