fredc@petsd.UUCP (02/26/87)
I'm Posting this for a friend: He's building a memory board, that will auto-config, and wants to throw a timer on board. The problem is: He needs to add a clock/timer chip to the expansion bus but doesn't want it to make it auto-config. Is there an address that the clock timer could reside at where we could read it a power up and set the time. This would make the design of the memory board much simpler. It seems like overkill to have to auto-config a timer when you are only going to read it once on power up (and at reset). Any info/thoughts on the subject would be greatly appreciated. Fred Cassirer ^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v God is Real. ( Unless otherwise explicitly declared, or implicitly defined)
miner@ulowell.UUCP (02/27/87)
In article <957@petsd.UUCP> fredc@petsd.UUCP (Fred Cassirer) writes: > He's building a memory board, that will auto-config, and wants to > throw a timer on board. The problem is: > He needs to add a clock/timer chip to the expansion bus but doesn't want > it to make it auto-config. Is there an address that the clock..... The way auto-config works is on a per board basis. In other words, if you have a memory board that also has a clock, a 68881, crash recovery logic, a corkscrew, whatever, it all boots as a single board. > It seems like overkill to have to auto-config a timer when you are > only going to read it once on power up (and at reset). This is the purpose of auto-config, many devices just need to be initialized at boot time. The PAL on your friends board contains information stating the amount of memory required by it; n-Meg bytes + clock-register-bytes (you might have to make this a multiple of 64K). You have to tell the system that you want the clocked mapped to memory! If you just stick it at the end of your ram the Amiga will not know it is there and may map another device at that address. At boot time when the system says hello to memory board it will check for a driver routine. Have the driver read the clock registers and set the time. Why not take advantage of a great feature supplied by the system? -- Rich Miner !ulowell!miner Cntr for Productivity Enhancement 617-452-5000x2693
ins_anmy@jhunix.UUCP (03/02/87)
I think Commodore should develop and make available a chip that does autoconfig. Such a chip would be programmable to respond in the right way to autoconfig signals. This would make life easier for commercial developers and those who merely want to do some hardware hacking (maybe C-A could sell the chips preprogrammed too). Using this chip, it would be easier and less expensive to design boards for the Amiga. Boards would be available faster, and at a lower price. I am assuming some things here, which may not be correct. First, that currently autoconfig is difficult to design. Second, that such a chip can be built. -- Norman Yarvin (seismo!umcp-cs | ihnp4!whuxcc | allegra!hopkins) !jhunix!ins_anmy "We all know what UNIX is. It's an operating system with no dick, so it can't screw you."
miner@ulowell.UUCP (03/04/87)
In article <4506@jhunix.UUCP> ins_anmy@jhunix.UUCP (Norman Yarvin) writes: >I think Commodore should develop a chip that does autoconfig.... >I am assuming ... that currently autoconfig is difficult to design. I think you should take a look at the hardware docs from Commodore; conforming to autoconfig is not a difficult task. There are about five chips needed: a PAL, a latch, an address comparator, a few logic gates & a few pull up and pull down resistors. The autoconfig circuit responds to a couple of bus signals and then lets the Amiga read nibbles from its PAL and latch in a base address for the plug in card (PIC). The only unusual requirement is that you need access PAL programmer, but if you want to be able to store product specific information in each card a programmable mechanism like PALs is required. >...would be easier and less expensive to design boards for the Amiga. >Boards would be available faster, and at a lower price. It does not seem as though it would not be worth the development time and cost ($$$) to develop a special chip, plus it would still require a PAL. -- Rich Miner !ulowell!miner Cntr for Productivity Enhancement 617-452-5000x2693
grr@cbmvax.UUCP (03/04/87)
In article <4506@jhunix.UUCP> ins_anmy@jhunix.UUCP (Norman Yarvin) writes: > > I think Commodore should develop and make available a chip that does >autoconfig. Such a chip would be programmable to respond in the right way to >autoconfig signals. > > This would make life easier for commercial developers and those who >merely want to do some hardware hacking (maybe C-A could sell the chips >preprogrammed too). > > I am assuming some things here, which may not be correct. First, that >currently autoconfig is difficult to design. Second, that such a chip can be >built. Please check the "Schematics and Expansion Specifications" document available from Commdore. It gives an example of how to implement auto-config for a memory board. It is not particularly complicated or expensive. We have talked about an 'AEAC' chip (All Encompassing Auto-Config), but at this point it has little cost advantage over the PAL implementation. -- George Robbins - now working for, uucp: {ihnp4|seismo|rutgers}!cbmvax!grr but no way officially representing arpa: cbmvax!grr@seismo.css.GOV Commodore, Engineering Department fone: 215-431-9255 (only by moonlite)
grr@cbmvax.UUCP (03/07/87)
In article <1109@ulowell.cs.ulowell.edu> miner@ulowell.cs.ulowell.edu (Richard Miner) writes: > >The way auto-config works is on a per board basis. In other words, if you >have a memory board that also has a clock, a 68881, crash recovery logic, >a corkscrew, whatever, it all boots as a single board. This is not necessarily true. If a board has features and/or allocatable memory that cannot be described at one shot, then a board can auto-config as several pieces. There is a bit in the auto-config specification that declares that a board does have multiple devices, although it's not clear that setting this bit will make anything different happen. -- George Robbins - now working for, uucp: {ihnp4|seismo|rutgers}!cbmvax!grr but no way officially representing arpa: cbmvax!grr@seismo.css.GOV Commodore, Engineering Department fone: 215-431-9255 (only by moonlite)