🚀 go-pugleaf

In article <587@viper.UUCP> john@viper.UUCP (John Stanley) writes:
>A question to Bill Wood on the PolyDisk ramdisk cartridge:
>   Bill, I've heard a few rumors that the documantation included with the
>PolyDisk includes enough hardware documentation to allow extending the
>amount of ram in the cart.  Is this true and if so, how difficult does
>it look?  Is there any indication as to what will need to be changed in the
>driver to have it support the extended memory?
>
>--- 
>John Stanley (john@viper.UUCP)
>Software Consultant - DynaSoft Systems
>UUCP: ...{amdahl,ihnp4,rutgers}!{meccts,dayton}!viper!john
Hello!
	Well! I must say the interest in the ramdisk cartridge is most
amazing. In answer to your question, no they don't supply information on
how to extend memory nor do they supply driver source. I called and
talked to them when the unit came in and they were not real excited
about releasing source. This is stupid since the driver is less than 2k
long and is not going to be to much of a problem to sort out. I am
having problems getting dissasm the disassembler posted a while back to
do it for me. I haven't checked into it very well but am suspecting that
the dissassembler either doesn't like the fact that the driver does not
allocate any space for the bss or else it is upset about the super calls
in the code since it will dissassemble itself.
	I don't have the circuit figured out completely yet either so
the following is possibly subject to change.
	The Polyram has a 4-meg address space. That is they (I think)
support 32 64k blocks. Memory reads are performed in the first bank of
the cartridge address space and they map the second bank of the
cartridge for the writes. I am not sure yet how they are doing this.
The 4-meg above came from a conversation with their engineers. 
	There is a way according to them to piggy-back more rams onto
the board but it requires cutting traces and they were not interested in
telling me how.
	The circuit consists of 31 IC's of which 16 are 256k dram. Five
of the chips are dual 4 to 1 multiplexers which I believe are used to
multiplex the addresses into the ram. I believe that the circuit can be
broken down into 4 major component areas: refresh timer, clock control,
address multiplexers and ram. This would make sence if they were
decoding a one meg address space as a piggyback expansion would suggest.
Another piece of evidence is that it takes 10 bits at a time for address
generation in a one meg space and they have 10 total multiplexers. They
use a ls123 timer for refresh timeout. That is they do nothing at all
about refresh when the system is running since the activity on the
cartridge address buss is enough to refresh the ram. The timer is
necessary to keep the memory alive when a reset occurs since the address
buss 'hangs' while the button is held down, and of course with a battery
backup it becomes necessary. The clock control is just a mapping of the
highest bit of the address to a clock chip expansion board. I am pretty
sure of this since their people said that you would have to disable the
clock control to go from a 2-meg space to a 4-meg space.
	The rest of the chips are simple ttl glue and a couple of byte
wide latches. I tend to think that synthesizing a write line is pretty
easy if you are willing to live with two or possibly three cartridge reads
for every write into the external address space. A base address with an
offset of 0-255 would allow the address buss to be used as a 'data'
buss, it then becomes necessary to do something similar to setup an
'address' buss and a write line.
	All in all, I think the circuit is pretty simple and elegant. I
can kind of understand their unwillingness to disclose to much since
there are sure to be several 'imatations' in the near future. I am going
to expand this one to one meg just as soon as I figure out how since I
am about 200k short of what it takes to get all of the compiler and
utilities out there that I want.
	I have not benchmarked this unit extensively but it is slower
than eternal.prg by what seems to be a factor of 2. This makes sence if
they must do two or several reads to the cartridge port to do a write.
In closing, I like this unit a lot and would recommend it to the rest of
you. 
	In a related matter, I have been porting the UNIX V7 compiler
to the ST for about the past year. I have been using it for the past
several months and it seems to work. I could KILL Atari for making text
files use \c\r as a line terminator. The problems this creates are
amazing. But on with the tale, This is a true 32-bit int compiler that
as you would expect runs a little slower than say MWC if you don't
declare shorts every chance you can. It will however handle really large
programs  and will allow you to build an array that is as large as the
memory you have. I feel that 32-bit ints are necessary to port some of
the better software -- common lisp comes to mind as does gnuemacs.
	Anyway, I called ATT about this to find out what restrictions
there are on V7 and was told that I could pass this work on to anyone
with a source license to V7 or greater. Well that includes just about
any site on usenet at this point in time. What's this got to do with
you? Well...I would be willing to give this stuff away but don't quite
know how to go about it. I suppose that if demand is not to heavy I
could make a tape or two assuming that a copy of a source license came
with the tape. 
	Cross compiling on a Vax has it's advantages are any of you
interested? Frankly, there is still more to be done on this, the VDI-AES
interface is not complete for instance. If you have any suggestions send
mail and I will try to figure out what to do.

			Bill Wood (!usceast!tech)