schultzd@kira.uucp (David Schultz) (07/31/90)
Two unrelated questions: 1.) (For a friend)... I know this has been hashed out already, so just e-mail a reply. I need the details of how to hook up a 1.44M drive to the ST. I remember it involved adding an extra clock line. I also remember someone making some kind of "smart" driver to switch between 720K and 1.44M. Can someone help me out and mail me all the DETAILS on this? 2.) Is there any program that allows you to use a floppy drive as swap space to get more memory in an ST. I realize this would be painfully slow, but until I can afford more mem, it would have to do. It would be infinitely more helpful on a nig hard drive. (Set aside an x meg partition on the hard drive and treat it as internal memory. Virtual mem on the ST!!!) -- ~~~~~~~ "We are building a fighting force of EXTRA-ORDINARY MAGNITUDE," ~~~~~~~ schultzd@egr.msu.edu | Dave Schultz, Michigan State University schultzd@cpsin.cps.msu.edu | Dept. of Computer Science ~~~~~~~~~~~~~~ "You have our gratitude." -- Kentuck Fried Movie ~~~~~~~~~~~~~~~
muts@fysaj.fys.ruu.nl (Peter Mutsaers /100000) (08/01/90)
schultzd@kira.uucp (David Schultz) writes: >2.) Is there any program that allows you to use a floppy drive as >swap space to get more memory in an ST. I realize this would be >painfully slow, but until I can afford more mem, it would have to do. >It would be infinitely more helpful on a nig hard drive. (Set aside >an x meg partition on the hard drive and treat it as internal memory. >Virtual mem on the ST!!!) Without a MMU this is impossible I think. Because you cannot have contiguous memory anymore, the MMU must make it look like contiguous. Another possibility is overlays. Then you must split larger programs in parts that fit in the memory, and if you jump to another part, another overlay comes in. I think the new Turbo C for the PC only has added automatical management of overlays. -- Peter Mutsaers email: muts@fysaj.fys.ruu.nl Rijksuniversiteit Utrecht nmutsaer@ruunsa.fys.ruu.nl Princetonplein 5 tel: (+31)-(0)30-534504 3584 CG Utrecht, Netherlands
nut@wet.UUCP (adam tilghman) (08/04/90)
In article <1990Jul31.165603.20869@msuinfo.cl.msu.edu> schultzd@kira.uucp (David Schultz) writes: >Two unrelated questions: > > ... (something regarding 1.44Mb floppies)> > >2.) Is there any program that allows you to use a floppy drive as >swap space to get more memory in an ST. I realize this would be >painfully slow, but until I can afford more mem, it would have to do. >It would be infinitely more helpful on a nig hard drive. (Set aside >an x meg partition on the hard drive and treat it as internal memory. >Virtual mem on the ST!!!) If you are using just a plain-vanilla 68000 in your machine, this is completely impossible. If you have installed a 68010 in your ST (I tried it, and was in the process of hacking TOS to work with the '010, but lost interest), there MIGHT be a way to do it (the 68010 has some _really crude_ method built-in for handling memory swaps). If you somehow shove a 68030 into your ST's 68000 socket, you would then be able to use the '030's built-in PMMU (paged memory management unit) to do the dirty work for you (the "Virtual" INIT for the Mac does this, and I would assume something similar could be whipped up by some intrepid ST programmer. Adam Tilghman e >-- >~~~~~~~ "We are building a fighting force of EXTRA-ORDINARY MAGNITUDE," ~~~~~~~ >schultzd@egr.msu.edu | Dave Schultz, Michigan State University >schultzd@cpsin.cps.msu.edu | Dept. of Computer Science >~~~~~~~~~~~~~~ "You have our gratitude." -- Kentuck Fried Movie ~~~~~~~~~~~~~~~ -- == Adam G. Tilghman - Trendy Quote: "Beware of Greeks bearing Trojans!" == ============ Bang-Path UUCP: {uunet | ucbvax}!unisoft!wet!nut ============ =============== Disclaimer? My employer? What, me work? ================
arsen@sparkyfs.istc.sri.com (Tom Arseneault) (08/08/90)
In article <1407@wet.UUCP> nut@wet.UUCP (adam tilghman) writes: >completely impossible. If you have installed a 68010 in your ST (I tried >it, and was in the process of hacking TOS to work with the '010, but lost >interest), there MIGHT be a way to do it (the 68010 has some _really crude_ >method built-in for handling memory swaps). If you somehow shove a 68030 >into your ST's 68000 socket, you would then be able to use the '030's >built-in PMMU (paged memory management unit) to do the dirty work for you >(the "Virtual" INIT for the Mac does this, and I would assume something >similar could be whipped up by some intrepid ST programmer. > > Adam Tilghman Why not try the 68070 from Signetics. I have only read the data sheet but it seems to be a nifty chip, it has a built in mmu (a little limited in that it will only handle either 8 2Mb pages or 128 segments of up to 128kbytes each, I may be reading this wrong but I'll need the hardware manual to find out for sure), 2 DMA chanels, a UART, and a I^2C interface (a syncrounos serial port). It uses a 30Mhz xtal but cuts it in half for internal use so it runs at 16Mhz. It is in a 84-Pin PLCC package and the pins are mostly the same, a few extras to handle the internal stuff. It is supposed to be object code compatible with the 68000 and costs about $50 small quantity. This could be an interesting hack, using a jato board to get upto running at 16Mhz with out killing the ST and to supply a 68881. You would then mount the 68070 some support electronics and the jato board on another daughter board and voila you have a ST with unlimited virtual memory (a lot of patching to the operating system of course so that the machine will allow memory access above 4Mb with out an error, or trap the error and use it? And to allow swapping). You can then add another serial port (2 if you want to use the I^2C lines), rewrite the file system to use one of the DMA ports (will speed up the file system when using multitasking systems) and lots of other things I have not even touched on. This is all assuming that you could even interface the 68070 to the ST, should be possible but its the hidden gotchas that hurt the most. A point of fact, the _really crude_ method mentioned above is nothing more than allowing the 68010 to restart an instruction after servicing a bus exception. A 68000 will start on the next instruction and you will lose the previous instruction witch will probably result in your system crashing in massive flames. I rather resent Motarola for say that it "supports Virtual Memory/Machine" when infact you still require a MMU to do that stuff. Anyhow this was just my thoughts on how one might realy screw up a perfectly good ST. Thomas J. Arseneault arsen@itstd.sri.com
kawakami@monsoon.Berkeley.EDU (John Kawakami) (09/10/90)
In article <1407@wet.UUCP> nut@wet.UUCP (adam tilghman) writes: >In article <1990Jul31.165603.20869@msuinfo.cl.msu.edu> schultzd@kira.uucp (David Schultz) writes: >> >>2.) Is there any program that allows you to use a floppy drive as >>swap space to get more memory in an ST. I realize this would be >>painfully slow, but until I can afford more mem, it would have to do. >>It would be infinitely more helpful on a nig hard drive. (Set aside >>an x meg partition on the hard drive and treat it as internal memory. >>Virtual mem on the ST!!!) > > If you are using just a plain-vanilla 68000 in your machine, this is >completely impossible. If you have installed a 68010 in your ST (I tried Well, not practical, not nice, not useful, but definitely possible. You (the intrepid programmer) write a new malloc which returns pointers to pointers: aka handles. The pointer returned is a pointer into a table; the table is made up of pointers to memory fragments. Toss in some swapping algorithms and you have a private VM system which can defrag memory and do other neat stuff. If you are the of the TOS-sux-so-I'll- install-my-own-OS types, this would not be unfathomable. Z John Kawakami kawakami@ocf.berkeley.edu ucbvax!ocf.berkeley.edu!kawakami Amateur crank! My Atari Macks!
entropy@rice-chex.ai.mit.edu (enthalpy) (09/11/90)
In article <1990Sep10.105324.26957@agate.berkeley.edu> kawakami@monsoon.Berkeley.EDU (John Kawakami) writes: In article <1407@wet.UUCP> nut@wet.UUCP (adam tilghman) writes: >In article <1990Jul31.165603.20869@msuinfo.cl.msu.edu> schultzd@kira.uucp (David Schultz) writes: >> >>2.) Is there any program that allows you to use a floppy drive as >>swap space to get more memory in an ST. I realize this would be >>painfully slow, but until I can afford more mem, it would have to do. >>It would be infinitely more helpful on a nig hard drive. (Set aside >>an x meg partition on the hard drive and treat it as internal memory. >>Virtual mem on the ST!!!) > > If you are using just a plain-vanilla 68000 in your machine, this is >completely impossible. If you have installed a 68010 in your ST (I tried Well, not practical, not nice, not useful, but definitely possible. You (the intrepid programmer) write a new malloc which returns pointers to pointers: aka handles. The pointer returned is a pointer into a table; the table is made up of pointers to memory fragments. Toss in some swapping algorithms and you have a private VM system which can defrag memory and do other neat stuff. If you are the of the TOS-sux-so-I'll- install-my-own-OS types, this would not be unfathomable. No! You would still have to handle the case where someone actually tries to _access_ data that has been paged out (you mean you have to be able to read it back??). This entails first of all being able to recognize an interrupt caused by accessing memory that was paged out (this part might be possible) but after paging that data back in, you have to be able to continue from the interrupt as if nothing had ever happened. The fact that this is not a supported operation on the 68000 makes it unlikely that such a program could be written. nick Internet: ncastellano@eagle.wesleyan.edu || entropy@ai.mit.edu Bitnet: ncastellano@wesleyan.bitnet Citadel: Sinkhole!dEADHEAd [@mast.citadel.moundst.mn.org] Sniktnet: snikt!entropy
gl8f@astsun7.astro.Virginia.EDU (Greg Lindahl) (09/11/90)
In article <10562@life.ai.mit.edu> entropy@rice-chex.ai.mit.edu (enthalpy) writes: >No! You would still have to handle the case where someone actually >tries to _access_ data that has been paged out (you mean you have to >be able to read it back??). This entails first of all being able to >recognize an interrupt caused by accessing memory that was paged out >(this part might be possible) but after paging that data back in, you >have to be able to continue from the interrupt as if nothing had ever >happened. You are describing transparent virtual memory. There are other kinds, and perhaps the original poster is willing to live with virtual memory where he is required to explicitly ask for the memory, and release it when he's done. The Mac does this, and Windows 286 does this. -- "Perhaps I'm commenting a bit cynically, but I think I'm qualified to." - Dan Bernstein
blee@plains.NoDak.edu (Blaine Lee) (09/11/90)
In article <10562@life.ai.mit.edu> entropy@rice-chex.ai.mit.edu (enthalpy) writes: >In article <1990Sep10.105324.26957@agate.berkeley.edu> kawakami@monsoon.Berkeley.EDU (John Kawakami) writes: > > In article <1407@wet.UUCP> nut@wet.UUCP (adam tilghman) writes: > >In article <1990Jul31.165603.20869@msuinfo.cl.msu.edu> schultzd@kira.uucp (David Schultz) writes: > >> > >>2.) Is there any program that allows you to use a floppy drive as > >>swap space to get more memory in an ST. I realize this would be > > [many theories and ideas deleted] I don't know a whole lot about hardware yet, but I do know that it would be possible to do this to a small extent. For multi-tasking enviroments. The method is to swap out entire envirments, that is start one program in the core memory, then when you need to start another large program, swap out the core image and start with a full amount of core space again. If you followed my explination, you will realize that this does not support vertual memory, but rather allows many processes with the full physical memory (minus the kernel and screen, etc...). And if you followed up to here you also realize that you will need one hell of a modified malloc, and a process swapper/kernel/scheduler. Although I would guess that RTX or MINT05 would be a place to start. PS: please don't tell me this _won't_ work as my Tandy 16b sitting next to my ST. is a testiment that a 68000 will do it...slowly. Blaine Lee blee @ plains.nodak.edu
hvaalde@cs.vu.nl (Aalderen van Harold) (09/11/90)
entropy@rice-chex.ai.mit.edu (enthalpy) writes: >be able to read it back??). This entails first of all being able to >recognize an interrupt caused by accessing memory that was paged out >(this part might be possible) but after paging that data back in, you >have to be able to continue from the interrupt as if nothing had ever >happened. The fact that this is not a supported operation on the >68000 makes it unlikely that such a program could be written. it is even worse, suppose the data that is paged in is executable code it is unlikely that you can put the code segment at exectly the same place as it was before, so in the worse possible case you have to relocate the complete program. And what about those parts of TOS,AES,VDI, etc that expect certain data at specific adresses. So even if you have the hardware to support paging, you still have to hack the complete TOS to support it too. Harold van Aalderen, (hvaalde@cs.vu.nl)
kawakami@volcano.Berkeley.EDU (John Kawakami) (09/21/90)
In article <10562@life.ai.mit.edu> entropy@rice-chex.ai.mit.edu (enthalpy) writes: >No! You would still have to handle the case where someone actually >tries to _access_ data that has been paged out (you mean you have to >be able to read it back??). This entails first of all being able to >recognize an interrupt caused by accessing memory that was paged out Not with the scheme I described. First, you need a table of all the memory pages. For simplicity's sake, make it an array: struct memptr{ word *memaddr; word statusbits; } /*sorry I don't know*/ /*how to use bitfields*/ struct memptr pagetable[4096]; /* arbitrary */ Then you need to write mallocs which don't return pointers to memory fragments but indices into the pagetable. (actually, you need to write something at a lower level than malloc) int malloc(int size) { /*blah blah*/ /* figure out which block to allocate*/ /*see where in memory or disk that block really is and*/ /*set some status bits*/ return pagetableindex<<offsetbits; } Then you need to write a "use" function. From now on, instead of de- referencing with the asterisk, as in *XvarPtr=1010; you use *(deref(XvarPtr))=1010; Of course you have a macro for this kind of call. #define use(n) *(deref(n)) void *deref(int index) { /*look up the block by first taking the low order bits which specify*/ /*the offset into the block: offset=0x000000FF & index */ /*then you shift to find the block index index=index>>offsetbits*/ /*check the status bits to see where the block is (in memory or on disk)*/ /*if it is on disk swap something out and swap that page in*/ return actualladdress+offest; } Then you publish docs telling people to use the deref() func or they will have funny things happen to their programs. I've made this seem easier than it looks. There are extensions you can do as well. Maybe a new func which will set a protect bit so a page will not be swapped out, a func to unset it, and then you can use normal dereferencing instead of handles in between the set and unset of the protect bit. This is not a nice way to have things done, but it is not uncommon. MacOS and Windows 2 do this, as someone pointed out. Some languages have this built in so program fragments can be swapped in and out: instead of a pagetable there is a functiontable. John Kawakami kawakami@ocf.berkeley.edu ucbvax!ocf.berkeley.edu!kawakami Amateur crank! My Atari Macks!