anakin@gpu.utcs.toronto.edu (Anakin Research) (12/07/88)
Firstly let me thank all of you who have contributed to the
discussion about the 32-bit wide memory for the LUCAS board. I have
read and digested your comments and here is what I've come up with.
While I'm in a thanking mood, Thanks to all of you who
have bought the LUCAS project. I have shipped 120 boards and have
another run in the works, deliverable on the 23rd of the month. I
am so glad that hackers still exist, so on to the memory board.
Proposed 32-bit LUCAS Memory Design REV #2
~~~~~~~~ ~~~~~~ ~~~~~ ~~~~~~ ~~~~~~ ~~~ ~~
256K X 4 vs. 1Meg X 1. The principal reason for 256K X 4 chips
is so that people can upgrade their memory in 1 Meg. chunks. I know I
can't afford 4 Meg. all at once, but yes 1 Meg. X 1 chips are slightly
cheaper. So having looked at the possibilities I believe it is possible
to lay the board out in such a way as to be able to use either. Unless
I get a real surprise at layout time it will be a jumper selectable
option. From my preliminary investigation it does look doable. If anyone
has seen such as layout I would love to have my learning curve shortened.
I am sorry but I don't feel it would be wise to make the memory
board able to use 256K X 1 chips. Size is a problem and the chief reason
this has been requested is to use memory chips that people may already
have in memory boards. I need to use 100 ns. chips and there are a variety
of chips in various memory boards, some of which I'd be incompatible
with and would need further jumper blocks. Size is the big problem though
so again, my appologies to those who requested this.
To auto-config or not. Seems that the answer is yes. I have a paper
design in which this could be auto-configable or not depending on the
jumper block and if the auto-config stuff is present. I am now looking
at a way to remote a switch mounted on the back of the AMIGA so you could
select this option at boot time. Dave Haynie makes a valid comment about
DMA. I put DMA support on the LUCAS board and I have had one report of
LUCAS working fine with a home-brew DMA hard disk controller. I have no
DMA devices an haven't properly tested this feature. Seeing as one report
does not confirm that LUCAS supports DMA is there anyone else out there
who has a LUCAS board who can confirm or deny this. I hope I have
understood Dave's comments correctly, if I'm missing something perhaps
Dave will enlighten me.
I have decided that the 8428 DRAM controller is the one I will
use. It is about as fast as the economics of memory will allow us to
go and I believe we will be able to get some interleave access to help
the speed along.
KICKSTART in 32-bit space. Things are alittle clearer but not
nailed down yet. So far I have two legal ways to accomplish this.
1) Remap kickstart space to a set of ROM sockets. I could not
provide these ROMS but I could write a program to read your ( the one
you own) Kickstart disk and make hex files that you could then have
blown into eproms. Legally I believe this is O.K.
2) I could remap 256K of the 32-bit wide DRAM into Kickstart
space after copying it from the old Kickstart space. This is a little
clumsy as it would require a configuration program in your boot sequence,
but if I understand the general feeling out there, this is no big deal to
most of you. Also you would lose 256K of DRAM.
Games which take over the system would indeed not be
able to benifit from this approach, but I don't think that is a big
deal as they will still run. I am still looking for a game which is
better than defining DSACK1 in an asyncronous '020 design.
I COULD STILL USE SOME COMMENTS ON THIS POINT!
Someone came up with the idea of buying two sets of kickstart
ROMS one for the upper 16 bits and one for the lower 16 bits with half
the space not used. Although I am not going to use this idea, I thought
it was a wonderful workaround and still causes me a smile.
BTW. Thanks to Evan Sidoriak for his hack of the 68000 and the
LUCAS board residing together, switch selectable at boot time. I haven't
done it yet but several of my buddies are giving it a whirl. I post how
they made out.
Brad Fowles
BIX anakin.1
USENET anakin@utgpu
daveh@cbmvax.UUCP (Dave Haynie) (12/10/88)
in article <1988Dec7.095943.21876@gpu.utcs.toronto.edu>, anakin@gpu.utcs.toronto.edu (Anakin Research) says: > Checksum: 21609 > Dave Haynie makes a valid comment about DMA. I put DMA support on the LUCAS > board and I have had one report of LUCAS working fine with a home-brew DMA > hard disk controller. I have no DMA devices an haven't properly tested this > feature. Seeing as one report does not confirm that LUCAS supports DMA is > there anyone else out there who has a LUCAS board who can confirm or deny > this. I hope I have understood Dave's comments correctly, if I'm missing > something perhaps Dave will enlighten me. There are actually two DMA-related issues. The first of these is basically, will the '020 card respond to a DMA request in a 68000 compatible way. In other words, will it grant bus mastership to a DMA card without causing any problems. While on the surface the 68000 and 68020 DMA mechanisms look the same, there are some synchronization and timing issues that may have to be addressed, depending on the board design. All the commercial 68020 boards are designed to allow DMA to occur. The other question, and the one I was really commenting on, is the "can a DMA device talk to my 32 bit memory". This feature definitely complicates the design of the memory board, in that it requires the memory be able to act as both 32 bit wide memory (during CPU access) and 16 bit memory (during DMA access). Neither the CSA nor the Ronin board allow 16 bit DMA into 32 bit RAM; the A2620 does, but it most definitely made the A2620 RAM design more complex. My feelings on the autoconfig issue is that, if your memory is in the 24 bit address space of the 68000 (as is all autoconfig memory), it should allow 16 bit DMA. CSA put their RAM outside of the 24 bit space, which I think is a good solution to the non-DMA memory. This lets you easily tell DMA device drivers which memory they can and can't access. Ronin allows their memory to show up in the autoconfig space without allow DMA, and that makes configuration more complicated. In fact, their suggestion is to confine DMA to CHIP RAM, which is a definite performance hit. While it's possible to do better than that, and as a hacker project, the folks doing this will certainly be better informed on system setup issues than the average street Amiga user, this is still something to consider. > Brad Fowles -- Dave Haynie "The 32 Bit Guy" Commodore-Amiga "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: D-DAVE H BIX: hazy Amiga -- It's not just a job, it's an obsession