hardware solution for direct access to video ram

[Tom Tkacik]

In article <2434 at itivax.iti.org> scs at itivax.iti.org (Steve Simmons) writes:
>botton at laidbak.UUCP (Brian D. Botton) writes:
>
>>  Hi netlanders.
>
>Hi yourself.  Nice introductory article.
>
>>  This article is fairly long as is gives the theory and step-by-step method
>>for constructing a daughter board that allows user level code to access the
>>video ram on a 3B1. . . .
>
>Usually these hardware article make me nod my head sagely and wish I
>wasn't such an idiot with a soldering iron.  However, there are some
>interesting implications....

>Using a similar scheme is it possible put >4M in the Unix-PC?  This
>should be of great interest to the mondo combo people and the X people.

This is an interesting idea.  But I do not think that it is possible.
I see three problems which will prevent it from working.

1) Memory map RAM.  To add more memory, the memory management must be
increased.  Page Mapping RAM goes from  0x400000 to 0x4007ff.  This could
be doubled to allow another Meg, because there is nothing in the
0x400800 to 0x400fff range.  But I think that timing would be a problem.
The way that page mapping works requires very fast page mapping RAMs, and
I am not sure that a fast enough circuit could be designed on a 
daughter board.  (I would like to here someone prove me wrong :-).

2) The kernel must know that another 4Meg exists.  I am not sure what is
involved, but I do know that the current kernel will have to be modified.
Can anybody say that this really is a minor change?  I have my doubts.

3) The killer.  Where to put another 4Meg.  The address space defined
by Convergent is really designed with the current 4Meg limit.
They split it up into 4 4Meg partitions.
	1) Fast memory -- RAM		(400nsec access)
	2) Fast I/O    -- video ram etc.
	3) Slow memory -- ROM		(900nsec access, or is it 1usec?)
	4) Slow I/O    -- misc. I/O devices

There is no place left to address more memory.  It looks like the fast I/O
only uses 0x400000 to 0x4fffff, and that perhaps we could steal
0x500000 to 0x7fffff (3Meg).  Well, 3Meg is still better than none, and
at least it is in the fast access area, so there would be no speed penalty.
Unfortunately, as Brian Botton mentioned, the address lines are not fully
decoded so that 0x400000 looks like 0x500000, 0x600000, and 0x700000.
The addressing would have to be reworked, to fully decode the I/O in this
range.


It is an interesting idea, and if these points are really minor, and
someone thinks it can be done, I am willing to help try.

Any more comments?

---
Tom Tkacik		GM Research Labs,   Warren MI  48090
uunet!edsews!rphroy!megatron!tkacik
"If you can't stand the bugs, stay out of the roach-motel."  Ron Guilmette
-- 
---
Tom Tkacik		GM Research Labs,   Warren MI  48090
uunet!edsews!rphroy!megatron!tkacik
"If you can't stand the bugs, stay out of the roach-motel."  Ron Guilmette