anakin@gpu.utcs.toronto.edu (Anakin Research) (11/23/88)
I have been very heartened by the responce to the LUCAS Project
68020/68881 accelerator board for the 1000. It seems that indeed there
are many 1000 owners out there who have spent considerable money on their
machine and peripherals, who cannot afford to upgrade to the 2000 with an
'020 board installed. It is nice to know there are still hackers out there
to whom the idea of populating their own bare boards is a viable alternative
to the higher priced spread. Let me say now that I have appreciated your
comments on the LUCAS Project on the nets and in your letters, and that I will
try to keep the LUCAS Project alive.
Now that about 2/3 of the initial run of 120 LUCAS Boards has been
shipped, (This means I'm out of debt for the board costs), it is time to get
the 32-bit wide memory board in the works. I should have a first crack proto-
type ready for debugging in about a week. I thought it would be a good idea
to get your ideas about its configuration and functionality. Any comments,
design ideas, or critisisms would be welcome. I would enjoy a lively
discussion and it can only improve the end product. Again, in the spirit of
the LUCAS Project, I will try and keep end user price to a minimum.
Proposed Memory Design
~~~~~~~~~~~~~~~~~~~~~~
I will be using 1 Meg. DRAMS in a 256K X 4 configuration. This will
allow expansion in 1 Meg. increments as you can afford more memory. I plan
to have sockets for a maximum of 4 Meg.
I plan to use the National DRAM controller 8428D-70. This part though
a tad expensive $45.00 (U.S) will simplify the design and keep the chip
count down to a minimum. It also will allow me a quicker design path. (Free
time is becoming a precious commodity for me.) This controller will also
do some memory interleaving and should provide the optimum memory access speed
To auto-config or not to auto-config! It seems to me that there is a
slightly messy way to auto-config the 32-bit wide memory. By cutting the
config pin (12) on the exapansion connector, (it is just shorted to ground)
and bringing a new config line from the memory board to pin 12, this would
allow the memory to be autoconfiged first in the chain. Alternatively, we could
not hack at the board but use some addmem like program to configure the memory.
I would like to hear any comments on which way would be most efficent form a
software point of view.
Power considerations. I have been asked why on the LUCAS '020/881
board I provided so many 5 Volt pins on the 96 Pin DIN connector. It was
not to provide power for the memory board but to recieve power from it.
I plan to have a connector on the memory board which will accept the
connector from the power supply which currently goes to the mother board, and
then, of course, bus it from there to the mother board. This should allow easy
installation, and as a side effect improve the noise floor on the LUCAS
board.
I would like to move the kickstart area into this 32-bit wide path.
I must admit that I haven't given this enough thought and any ideas on how
this would be accomplished would be appreciated. I can prevent assertion of
*AS (Address Strobe) in the kickstart range and simply have ROMS on the LUCAS
memory board. This seems to me constitute a copywrite infringement. Anyone
understands the legalese of this and who could hopefully suggest an honest
workaround, please advise me.
I understand that many of you would like to have an MMU. I don't have
the neccessary software smarts to make this compatable with the proposed
unix environment for the amiga and I think other problems may be there as
well. I am certainly willing to discuss it. My fear is that this will
increase the cost of the board with perhaps little practical gain.
Brad Fowles
UseNet anakin@utgpu
Bix anakin.1
kgschlueter@violet.waterloo.edu (Kevin Schlueter) (11/25/88)
The design for the LUCAS 32 bit memory board sounds good. In my opinion, having the extra memory autoconfig is probably not desirable if it adds alot to the complexity of the hardware (an addmem like utility is fine and would allow us to easily disable the 32 bit wide RAM if necessary). Although I will almost certainly buy the 32 bit wide memory board, I wonder if a cache board isn't more in keeping with the LUCAS philosophy. Basically, it wouldn't require as many expensive memory chips and would still allow a reasonable speedup. As I am not a hardware expert, perhaps I'm missing an important reason why this would be unrealistic (perhaps the design would be too complex or too many exotic parts would be required).
anakin@gpu.utcs.toronto.edu (Anakin Research) (11/25/88)
In article <9987@watdragon.waterloo.edu> kgschlueter@violet.waterloo.edu (Kevin Schlueter) writes: >The design for the LUCAS 32 bit memory board sounds good. In my opinion, >having the extra memory autoconfig is probably not desirable if it adds >alot to the complexity of the hardware (an addmem like utility is fine >and would allow us to easily disable the 32 bit wide RAM if necessary). > >Although I will almost certainly buy the 32 bit wide memory board, I >wonder if a cache board isn't more in keeping with the LUCAS philosophy. >Basically, it wouldn't require as many expensive memory chips and would >still allow a reasonable speedup. As I am not a hardware expert, perhaps >I'm missing an important reason why this would be unrealistic (perhaps >the design would be too complex or too many exotic parts would be required). To make this user selectable a software fix to addmem instead of autoconfiging the memory is quite possible, and I shall consider it. As far as a cashe, yes they do get messy. I would love to put a address maskabke data cashe but it would really prolong development, (they ain't easy) and increase board real estate. I think I disagree that the cashe is more in the "LUCAS philosphy". The 32-bit wide upgrade path to '020 is vital to have a good generic performance increase. Indeed as I have said before, the '020 by itself is hardly worth it (1.4 times increase generically), it is the upgrade path to 32 bits to memory and FPU which make the performance really take off. It would, however, be very interesting to be able to experiment with various size cashes. I think it is a rapid process of diminishing returns beyond certain definable limits. Thanks for input Brad Fowles
sns@acp.OZ (Stuart Nixon) (11/26/88)
In article <1988Nov23.104910.15213@gpu.utcs.toronto.edu>, anakin@gpu.utcs.toronto.edu (Anakin Research) writes: > > Proposed Memory Design > ~~~~~~~~~~~~~~~~~~~~~~ > > I will be using 1 Meg. DRAMS in a 256K X 4 configuration. This will > allow expansion in 1 Meg. increments as you can afford more memory. I plan > to have sockets for a maximum of 4 Meg. How about using 1Mb x 1 RAM chips, as they are much cheaper. A quick scan of memory prices in Byte gives me : 1Mb x 1 bit, 100ns.... $40 256kx 4bits, 100ns.... $70 While I realise that this will mean the board must be populated with 4Mb or no memory, the saving in memory prices seems worth it, as 4Mb of x1 RAM is not much more expensive that 2Mb of x4 RAM. Also, here in Australia it is just about impossible to get hold of 256Kx4's, where as 1Mbx1's are readily available - cheaper than USA prices, interestingly. > I plan to use the National DRAM controller 8428D-70. This part though > a tad expensive $45.00 (U.S) will simplify the design and keep the chip > count down to a minimum. It also will allow me a quicker design path. (Free Sounds fine to me. The 8428 is a nice chip, I am told. > To auto-config or not to auto-config! It seems to me that there is a > [comments on various options deleted] > I would like to hear any comments on which way would be most efficent form a > software point of view. Me, I am happy to use AddMem. It also has the advantage that I can selectively disable the RAM if I choose for some reason at bootup (for example for memory tests, or for performance measurements) Any comments? > I would like to move the kickstart area into this 32-bit wide path. I read somewhere that moving Kickstart to 32bit RAM/ROM does not have that big an impact on speed. Perhaps Dave Haynie could comment? > Brad Fowles By the way: Well done on the LUCAS board! sns Stuart Nixon Software Phone : +61 9 322 6497 Uucp : ...{uunet,mcvax,ukc}!munnari!acp.oz!sns ACSnet: sns@acp.oz
ditto@cbmvax.UUCP (Michael "Ford" Ditto) (11/27/88)
In article <1988Nov23.104910.15213@gpu.utcs.toronto.edu> anakin@gpu.utcs.UUCP (Anakin Research) writes: > I would like to move the kickstart area into this 32-bit wide path. >I must admit that I haven't given this enough thought and any ideas on how >this would be accomplished would be appreciated. I can prevent assertion of >*AS (Address Strobe) in the kickstart range and simply have ROMS on the LUCAS >memory board. This seems to me constitute a copywrite infringement. Anyone >understands the legalese of this and who could hopefully suggest an honest >workaround, please advise me. How about this: The user buys *two* copies of the ROM from Commodore; you have one hooked to the "high" side of the 32-bit data bus, the other to the "low" side, with one chip's A1 tied high, the other low. Half of each chip would be unused, but it sure sounds legal! (This is not to imply that anyone should take my legal opinion seriously!) Perhaps someone who's looked at the '020 bus spec more recently than I could confirm that it would work... > I understand that many of you would like to have an MMU. I don't have >the neccessary software smarts to make this compatable with the proposed >unix environment for the amiga and I think other problems may be there as >well. From what I remember about the '851, it's probably "too late" (i.e. you would have wanted to design that in when you did the memory & 68000 bus interfaces). It basically has to go "between" the '020 and the memory. But on the other hand, it could eliminate the above question about 32-bit kickstart, since you can do that with MMU tricks. As for Unix compatibility, nobody else knows how to make that work either, since we haven't documented what is needed (basically some software setup that's done in the ROMs on the 2620). We also haven't announced whether or not we are going to document it, but I hope we will. -- -=] Ford [=- "The number of Unix installations (In Real Life: Mike Ditto) has grown to 10, with more expected." ford@kenobi.cts.com - The Unix Programmer's Manual, ...!sdcsvax!crash!elgar!ford 2nd Edition, June, 1972. ditto@cbmvax.commodore.com
aimania@killer.DALLAS.TX.US (Walter Rothe) (11/27/88)
Brad, one thing you might want to consider is making is upwards compatible
to a redesigned Lucas board with a 68030. The 68030 is capable of one
clock updates when loading the cache. If you allowed page mode accesses
when fetching sequential locations the board would have a longer life.
These faster accesses could also help with a faster 68020.
There are several observations/questions I had when a reviewed your
board as an aid to my own design work.
1) Dont you need a pullup resistor on AS00-.
2) Why shut off AS going to the Amiga during a coprocessor cycle. Nothing
should respond. Wouldnt it eliminate alot of the grant circuitry
if you did not shut if off? Why is the flip flop needed to generate Z2-.
3) Is there any problem caused by not buffering the address and data lines
to the memory board. It seems like the length of the cable could cause
reflections and crosstalk.
4) Why are the two flip flops in series needed for BGACK?
5) You mention in the article that DTPRELIM should have the same timing
as C1 high C3 low and that your circuit does this. It may or may not
do this depending on what state U9 comes up in and whether it is
synchronized with the Amiga. If it comes up synced, it should stay
synced though. This could be your parts selection problem. Depending
on the part you select, you will eventually get one that powers up
right.
6) What does the extra buffer generating BUFOUT do? Does it prevent a
race condition between the D and clock inputs of U11?
7) I dont understand how the 68K, in a standard Amiga, gets synced with
C1-C4 so that it doesnt put out an address strobe when C2 and C4 are
high. Does DTACK from accesses to standard memory come at a certain
time so that it gets synced with that. If there were only fast memory
in a system, would it ever get synced?
By the way, whats the going rate and minimum lot size these days for a
board like yours? Was it alot of hassle?
One final question. Has someone got your board to fit into the 2000?
--
Walter Rothe at the UNIX(Tm) Connection, Dallas, Tx
UUCP: {rutgers}!smu.killer.aimaniagrr@cbmvax.UUCP (George Robbins) (11/28/88)
In article <6236@killer.DALLAS.TX.US> aimania@killer.DALLAS.TX.US (Walter Rothe) writes: > > There are several observations/questions I had when a reviewed your > board as an aid to my own design work. > > 2) Why shut off AS going to the Amiga during a coprocessor cycle. Nothing > should respond. Wouldnt it eliminate alot of the grant circuitry > if you did not shut if off? Why is the flip flop needed to generate Z2-. Please, the Amiga expansion bus is a basically and extension of the 68000 processor lines with a system implementation that ignores the FC lines. Any cycles that can't be interpreted as memory cycles, (i.e. coprocessor cycles) must be hidden from the system/bus by supressing address strobe. Some 68020 adapters have neglected this detail, leading to less than reliable operation... > > > 7) I dont understand how the 68K, in a standard Amiga, gets synced with > C1-C4 so that it doesnt put out an address strobe when C2 and C4 are > high. Does DTACK from accesses to standard memory come at a certain > time so that it gets synced with that. If there were only fast memory > in a system, would it ever get synced? There are two levels of synchronization. First, the relation of the 7MHz processor cycles vs. the 3.58 Mhz memory cycle - for this, AS is clocked and DTACK asserted synchronous with the 3.58 MHz clocks so that the CPU just gets and extra wait state anytime it ends up on and odd cycle. Second, the relation between "processor" and "chip/video" side cycles - this is actually a bit weaker, whenever the processor tries to compete with the chips for memory access, it loses. Assuming memory bound operation, it will tend to alternate cycles without extra wait states being needed, however this is enforced more by the sequencing of chip and video refresh cycles than any direct means. For amusement, it is worth noting that the "processor side" and "chip side" flip each line so that the processor is apt to run on the "chip side" until the first video fetch or other chip activity. Note that some memory boards are a bit obstinate about clock relations and may insert wait states when out of sync, even though the system logic doesn't too much care on expansion bus cycles. Some day, I may actually understand all of this... 1/2 8-) -- George Robbins - now working for, uucp: {uunet|pyramid|rutgers}!cbmvax!grr but no way officially representing arpa: cbmvax!grr@uunet.uu.net Commodore, Engineering Department fone: 215-431-9255 (only by moonlite)
sjk@utastro.UUCP (Scot Kleinman) (11/29/88)
In article <1988Nov25.122705.23087@gpu.utcs.toronto.edu>, anakin@gpu.utcs.toronto.edu (Anakin Research) writes: > In article <9987@watdragon.waterloo.edu> kgschlueter@violet.waterloo.edu (Kevin Schlueter) writes: > >The design for the LUCAS 32 bit memory board sounds good. In my opinion, > >having the extra memory autoconfig is probably not desirable if it adds > >alot to the complexity of the hardware (an addmem like utility is fine > >and would allow us to easily disable the 32 bit wide RAM if necessary). The only problem with not making the memory autoconfig would be when using it (or wanting to use it) with disks that need to be booted where you can't change the startup-sequence to allow the running of an addmem type program. If you autoconfig it, this problem should never occur, and if you need to disable the memory, you can just boot-up with KS1.1, thus avoiding the autoconfiguration process. That is of cours, assuming you don't put the kickstart in ROM, something I would avoid because of this kickstart switching routine which I have found quite handy. Keep up the great work, though Brad! Scot sjk@astro.as.utexas.edu
rg20+@andrew.cmu.edu (Rick Francis Golembiewski) (11/29/88)
>The only problem with not making the memory autoconfig would be when using it >(or wanting to use it) with disks that need to be booted where you can't >change the startup-sequence to allow the running of an addmem type program. >If you autoconfig it, this problem should never occur, and if you need to >disable the memory, you can just boot-up with KS1.1 Actually, most of the programs that won't allow a modification of startup-sequence or startup from workbench are games (which I for one would not want to have 32bit memory for, after all most of the arcade games are fast enough without an accelerator...). Also, Booting with 1.1 is not the best of solutions (as many programs require 1.2, and there were a lot of things added from 1.1 to 1.2) and is usually a pain (ie how many of you have used 1.1 in the last 6 monthes? how many of you keep 1.1 in some backup box of disks collecting dust?) Also, consider that if someone revises the board for 2000/500 then they would be unable to boot with 1.1. Also it sounded as if auto-config would add complexity (and thus $$$) to the board. I can't think of any programs offhand that won't let you modify the startup sequence, but I can think of a couple that will die because of autoconfigured fastmem. As for chip configuration, 256Kx4 are more expensive, but getting 32 1Mx1 is also very expensive ($1280 at $40/chip [last price I've seen for 1Mx1]). Granted that you get 4 Megs, but I don't really think that I would actually make use of 4MB, and I don't have $1000 to spend on memory for the MINIMUM configuration, with 256Kx4 you get 1 MB for c. $300. I think that 1MB of 32 bit ram, should hold me for quite some time (especially since I've got 2MB of 16bit FastRam). +----------------------------------------------------------------------------+ | Disclaimer: Me? Post That, impossible I never post anything... | | TypetoYouLater(Everyone); --> "functional Good bye".... | | Rick Golembiewski [ Pronunciation is half the Battle, spelling the other] | +----------------------------------------------------------------------------+
daveh@cbmvax.UUCP (Dave Haynie) (11/29/88)
in article <527@acp.OZ>, sns@acp.OZ (Stuart Nixon) says: > Summary: How about 1Mb x 1 RAM chips? > Me, I am happy to use AddMem. It also has the advantage that I can selectively > disable the RAM if I choose for some reason at bootup (for example for memory > tests, or for performance measurements) > Any comments? As I mentioned to Brad on BIX, if the memory doesn't support 24 bit DMA, it really should be located outside of the 24 bit space, and at that point is can't be autoconfiged. However, you can probably do a little be better than a generic AddMem. It's reasonable to write a program that knows about that particular memory board. If you have different possible size options, the program could just as well snoop out how much 32 bit RAM is in place. And of course the memory list that's created could be named LUCAS-RAM or something like that. I may have an example program that does this completed soon (actually, I have one right now that does this kind of thing, but it's not fully working). >> I would like to move the kickstart area into this 32-bit wide path. > I read somewhere that moving Kickstart to 32bit RAM/ROM does not have that > big an impact on speed. Perhaps Dave Haynie could comment? Who, me? 32 bit wide ROM Kernel does help some. For instance, the FFP libraries are in ROM, and if you load them into 32 bit RAM, they'll run around 4x faster than out of the real ROM. Layers seems to go faster too. Lots of other stuff is blitter or I/O bound -- in those cases, you don't notice a speedup all that much. If you've got an MMU, this is a freebie. If not, it's probably worth some work, but it remains to be seen just how much. >> Brad Fowles > sns Stuart Nixon Software -- 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
daveh@cbmvax.UUCP (Dave Haynie) (11/29/88)
in article <5322@cbmvax.UUCP>, ditto@cbmvax.UUCP (Michael "Ford" Ditto) says: > Keywords: kickstart hardware hack > Summary: 32-bit kickstart: Two roms? > In article <1988Nov23.104910.15213@gpu.utcs.toronto.edu> anakin@gpu.utcs.UUCP (Anakin Research) writes: >> I would like to move the kickstart area into this 32-bit wide path. > How about this: The user buys *two* copies of the ROM from Commodore; you > have one hooked to the "high" side of the 32-bit data bus, the other to the > "low" side, with one chip's A1 tied high, the other low. Half of each chip > would be unused, but it sure sounds legal! (This is not to imply that anyone > should take my legal opinion seriously!) Perhaps someone who's looked at > the '020 bus spec more recently than I could confirm that it would work... That would work, assuming you didn't drive them too fast. They probably can go faster than the 68000/7MHz, but I'd have to check the specs to see what the limit is. >> I understand that many of you would like to have an MMU. > From what I remember about the '851, it's probably "too late" (i.e. you > would have wanted to design that in when you did the memory & 68000 bus > interfaces). It basically has to go "between" the '020 and the memory. That's true. Same kind of things apply to an external cache. Not much you can do with existing LUCAS boards to get the MMU in place. It would be pretty simple to relayout the LUCAS board for a 68030, and it's a heck of alot easier than redesigning it for a 68020 + 68851. Neither of which solve today's problems... > As for Unix compatibility, nobody else knows how to make that work either, > since we haven't documented what is needed (basically some software setup > that's done in the ROMs on the 2620). We also haven't announced whether > or not we are going to document it, but I hope we will. Me too. At the moment, the only way you could run Unix would be to leave a place that would accept the A2620 ROMs, and you'd have to clone some of the A2620 registers as well. No small task. Hopefully a better solution will be available, if we do provide documentation at a later date. In any case, you won't have Unix without an MMU. > -=] Ford [=- -- 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
daveh@cbmvax.UUCP (Dave Haynie) (11/29/88)
in article <6236@killer.DALLAS.TX.US>, aimania@killer.DALLAS.TX.US (Walter Rothe) says: > There are several observations/questions I had when a reviewed your > board as an aid to my own design work. > 1) Dont you need a pullup resistor on AS00-. If that's the 68000 AS*, there's one on the motherboard. > 2) Why shut off AS going to the Amiga during a coprocessor cycle. Nothing > should respond. Wouldnt it eliminate alot of the grant circuitry > if you did not shut if off? Why is the flip flop needed to generate Z2-. That really is necessary. Memory boards and Amiga motherboard memory doesn't respect the FC lines. So allowing AS through during an FPU or interrupt acknowledge cycle is going to cause trouble. > 7) I dont understand how the 68K, in a standard Amiga, gets synced with > C1-C4 so that it doesnt put out an address strobe when C2 and C4 are > high. Does DTACK from accesses to standard memory come at a certain > time so that it gets synced with that. Access to CHIP RAM forces this synchronization. CHIP RAM is really synchronous RAM, split between the 68000 and the CHIPs. The CHIPs don't handle asynchronous bus cycles like the 68000 can, so they always take their half of the cycle at the same time. DTACK* will be held off if the 68000 comes in out of sync. Once in sync, S2 (where AS* falls in 68000 terms) happens when C1 and C3 are both low. > If there were only fast memory in a system, would it ever get synced? It might not get synced. This never happens, though, since you can't operate without CHIP RAM, and the first RAM the system every touches is CHIP, since that's the only RAM we know about at startup time. > Walter Rothe at the UNIX(Tm) Connection, Dallas, Tx > UUCP: {rutgers}!smu.killer.aimania -- 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
bmacintyre@watsol.waterloo.edu (Blair MacIntyre) (11/29/88)
In article <QXYR08y00WB9EMFklH@andrew.cmu.edu> rg20+@andrew.cmu.edu (Rick Francis Golembiewski) writes: >As for chip configuration, 256Kx4 are more expensive, but getting 32 >1Mx1 is also very expensive ($1280 at $40/chip [last price I've seen >for 1Mx1]). Granted that you get 4 Megs, but I don't really think >that I would actually make use of 4MB, and I don't have $1000 to >spend on memory for the MINIMUM configuration, with 256Kx4 you get >1 MB for c. $300. I think that 1MB of 32 bit ram, should hold me for >quite some time (especially since I've got 2MB of 16bit FastRam). That get's my vote! I have a 1.5 Meg internal expansion ( ya, I'm gonna try that piggyback thing! ) so I don't need 4M - 2 would be what I want, then I can create a 1.5Meg RAD on my InBoard! But $1280?!?!!? There is _no_ chance of me coming up with that. $600, maybe, $300 for sure. So it's easy to see which way I'm leaning! -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= = Blair MacIntyre (bmacintyre@watsol.waterloo.edu) The Guy in Green ... = = "Don't be mean ... remember, no matter where you go, there you are." BBanzai= = "Don't wurry, be habby ..." =
lphillips@lpami.van-bc.UUCP (Larry Phillips) (11/29/88)
In <1988Nov23.104910.15213@gpu.utcs.toronto.edu>, anakin@gpu.utcs.toronto.edu (Anakin Research) writes: > I would like to move the kickstart area into this 32-bit wide path. > I must admit that I haven't given this enough thought and any ideas on how > this would be accomplished would be appreciated. I can prevent assertion of > *AS (Address Strobe) in the kickstart range and simply have ROMS on the LUCAS > memory board. This seems to me constitute a copywrite infringement. Anyone > understands the legalese of this and who could hopefully suggest an honest > workaround, please advise me. This reminds me of a little trick I used when I built my first computer. I had a bootstrap ROM (16 bytes.. whoopeee), and 1K of RAM. When the 'load/run' switch was in the 'load' position, the boot ROM was at location 0, and the ram was at $1000. When in the 'run' position, the ROM and RAM switched locations. The boot ROM accepted keystrokes on the hex keypad when the ROM was active, and placed them sequentially (2 strokes, one byte) into RAM. I would then press the 'reset' switch, toggle 'load/run' to 'run', and let the reset switch go, and the program I entered would run. The 'load/run' switch simply toggled address line 12, being attached to one leg of an exclusive OR gate, line 12 to the other leg. So... what about a PAL latch or a flip-flop that controls one address line such that we can transfer the contents of KS ROM to a chunk of RAM well out of the way of any currently used locations. We then write to the PAL or flip-flop location to toggle it. The toggling would (a) change the address of the newly written KS to the proper location, (b) write protect it, and (c) 'steer' any accesses to the 32 bit KS. Just a thought. -larry -- "Intelligent CPU? I thought you said Intel CPU!" -Anonymous IBM designer- +----------------------------------------------------------------+ | // Larry Phillips | | \X/ lpami.wimsey.bc.ca!lphillips or van-bc!lpami!lphillips | | COMPUSERVE: 76703,4322 | +----------------------------------------------------------------+
daveh@cbmvax.UUCP (Dave Haynie) (11/30/88)
in article <3414@utastro.UUCP>, sjk@utastro.UUCP (Scot Kleinman) says: > Summary: autoconfig or not? > > The only problem with not making the memory autoconfig would be when using it > (or wanting to use it) with disks that need to be booted where you can't > change the startup-sequence to allow the running of an addmem type program. The ONLY kind of programs that create this kind of situation are poorly programmed video games. In such cases, there's probably not a real good chance that the program being loaded will work with any of FAST memory, 32 bit memory, or 68020 CPU. So you're probably better off not doing the configuration. Plus the fact that it may be impossible to do a legal autoconfiguration with this memory, since such autoconfiguration requires that all autolinked memory be DMAable as well. > ...and if you need to disable the memory, you can just boot-up with KS1.1, > thus avoiding the autoconfiguration process. There are many programs that won't operate under OS 1.1. 1.1 is not a supported operating system, and if you ever feel you need to use it, think again. Either you're not being properly supported by your software vendor, you're confused, or you're too cheap to pay for an upgrade. > Scot > sjk@astro.as.utexas.edu -- 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
peter@sugar.uu.net (Peter da Silva) (11/30/88)
In article <5349@cbmvax.UUCP>, daveh@cbmvax.UUCP (Dave Haynie) writes: > in article <3414@utastro.UUCP>, sjk@utastro.UUCP (Scot Kleinman) says: > > The only problem with not making the memory autoconfig would be when using > > it (or wanting to use it) with disks that need to be booted... > The ONLY kind of programs that create this kind of situation are poorly > programmed video games [...] you're probably better off not doing > the configuration. I'll second this. I have 4 Meg of non-autoconfig memory in my machine and I'm glad of it. If I want to run some PC-ware junk that requires a boot, I can boot it without losing RAD: and VD0:. It's debatable whether "poorly programmed" or "callously designed" is a better description for games like this, by the way. -- Peter da Silva `-_-' peter@sugar.uu.net Have you hugged U your wolf today? Disclaimer: My typos are my own damn busines#!rne
sjk@utastro.UUCP (Scot Kleinman) (11/30/88)
In article <5349@cbmvax.UUCP>, daveh@cbmvax.UUCP (Dave Haynie) writes: > in article <3414@utastro.UUCP>, sjk@utastro.UUCP (Scot Kleinman) says: > > Summary: autoconfig or not? > > > >The only problem with not making the memory autoconfig would be when using it > > (or wanting to use it) with disks that need to be booted where you can't > > change the startup-sequence to allow the running of an addmem type program. > > The ONLY kind of programs that create this kind of situation are poorly > programmed video games. In such cases, there's probably not a real good > chance that the program being loaded will work with any of FAST memory, > 32 bit memory, or 68020 CPU. So you're probably better off not doing > the configuration. Okay, I guess this is a valid reponse. I hereby retreat from my original posting. I'm not sure about the ONLY, but the point you make is valid. > > ...and if you need to disable the memory, you can just boot-up with KS1.1, > > thus avoiding the autoconfiguration process. > > There are many programs that won't operate under OS 1.1. 1.1 is not a > supported operating system, and if you ever feel you need to use it, think > again. Either you're not being properly supported by your software > vendor, you're confused, or you're too cheap to pay for an upgrade. > Many of the programs I have that I run under 1.1 are from the public domain. Such support and upgrade is not always available. Confused? Always, but that's irrelevant here. Scot sjk@astro.as.utexas.edu Anything I say may or may not be what I mean. - Warren Peace.
gmg@hcx.uucp (Greg M. Garner) (12/01/88)
Brad: If you do decide to make the lucas memory autoconfig, how about putting a register bit in there somewhere that will disable the autoconfig sequence the next time the computer is rebooted. This would seem to me to solve all the problems associated with the choices between autoconfig and addmem aproaches (besides the obvious one of having to put auotconfig logic on the board). I wish I had a way to turn off my Starboard memory with a simple register write like that. On another note, can you tell me why you want to use 1meg Dram chips as opposed to 256K chips? I haven't looked at the design VS. cost tradeoffs so maybe I am missing something obvious. The Lucas board is exciting, keep em coming! Greg Garner 501-442-4847 USENET: ...!uunet!harris.cis.ksu.edu!hcx!gmg
eachus@mitre-bedford.ARPA (Robert Eachus) (12/02/88)
I may be missing something here, but given the nature of this project/board I would design it to take both some 256Kx4 bit chips and a set of 1Mx1 bit chips, say 4 MEG of by ones and 2 MEG of by fours. It shouldn't add much to the cost of the the board (since you don't have to do any switching, just detect which sockets are filled), and will allow most users to buy 1 MEG of memory now, and fill the board when the 1 MEG chips come down to $5 a pop. Robert I. Eachus with STANDARD_DISCLAIMER; use STANDARD_DISCLAIMER; function MESSAGE (TEXT: in CLEVER_IDEAS) return BETTER_IDEAS is...
mikhe@prefix.liu.se (Mike Henry) (12/02/88)
[I don't use lineeater fodder]
Wouldn't a simple DIP switch do the trick??
Let the user decide if he wants to autoconfig or not!!
I don't mind AddMem'ing because I think it's simple.
Others might not. Why make people do something that
they don't want to do, when it's soo simple to let
them have a freedom of choice??
My two cents... B^)
-Mike
--
INET : mikhe@majestix.liu.se ///
UUCP : {mcvax,munnari,ukc,unido}!enea!liuida!majestix!mikhe ///
ARPA : mikhe%majestix.{ida.liu.se,UUCP}@seismo.CSS.GOV \\\/// What
SNAIL: Mike Henry, Alsattersg. 3C:20, S-582 51 Linkoping SWEDEN \XX/ Else??