Re: DVG Multigame

How about a 74LS137? See data sheet at
http://www-s.ti.com/sc/psheets/sdls132/sdls132.pdf#xml=http://www-search.ti.com/search97cgi/s97r_cgi?action=View&VdkVgwKey=http%3A%2F%2Fwww%2Ds%2Eti%2Ecom%2Fsc%2Fpsheets%2Fsdls132%2Fsdls132%2Epdf&doctype=xml&Collection=TechDocs&QueryZip=addressable+latch%2A&

When pin 6 is high and pin 5 is low the output pins are enabled, otherwise they are
high (would go directly to *enable pins on EPROMS). In this case A15 would go to
pin 6 and pin 5 is grounded.

Pin 4 going low stores address on pins 1-3 which determine which output (only one
of the eight) will go low. This address stays latched when pin 4 is high.

Would seem to do what you want in only one chip.

Neil Bradley wrote:

> > > select which bank of 8K the vector generator should use.
> > >* Exclusive OR the PROM/VRAM output select (one half of L2) on the vector
> > > generator, and have it drive !OE on the vector EPROM (27256).
> > This seems like such a simple set of requirements, it seems a shame to
> > go to all the trouble of making a PAL - a couple of 74-series TTLs should
> > do just as well, I would think. An 'LS86 quad-XOR gate should handle the
>
> Well, I'm a hardware newbie, so whaddya expect? ;-)
>
> > OE* and inverted A15 problem, and an 'LS377 octal-D flip-flop to handle the
> > latching. (Actually, any old D-type flip-flop package should work, since
> > you don't seem to _need_ all eight bits, or any tristate outputs.)
> >
> > _Maybe_ a third quad-gate chip of some kind (NAND, NOR, etc.),
> > depending on how a "write to the 8000-FFFFh region" is to be decoded.
> > (Personally, if there's already some kind of Memory-Write-Enable signal
> > available, I would just look for A15 to go high while MEMW* goes low, and
> > have that condition generate a positive-going edge to the 'LS377 latch,
> > thusly: <<warning - bad ASCII art ahead! :) >>
>
> There isn't an A15/!MEMW qualifier unfortunately. A15 isn't used at all in
> production.
>
> > This, of course, assumes that both the CPU address and data buses
> > become valid a sufficient amount of time before MEMW* goes low, so the '377
> > latch can respond to the change in G* stage; if there's a timing issue
> > there, it would be better to hold G* low and then NOR the MEMW* and
> > CPU_A15* signals into the '377s CLK input.
> > I know, it's not as sexy as a PAL, but I'm a great believer in keeping
> > things simple and straightforward. :)
>
> Oh, me too. I just don't know any better. ;-)
>
> But how would we handle the 2 to 4 address decoder/enable on the vector
> generator? Two bits going in to select which part of the 1K area the
> vector generator owns and 4 not bits coming out. We need to do a !OE
> on 3 of the 4... wait a sec... an inverter would work here.
>
> Thanks for the * - Lemme go rethink this...
>
> Asteroids is relocating just fine. Asteroids Deluxe, however, is an
> entirely different story. It executes code out of the vector ROM! Bleugh!
> That'll be tougher to move.
>
> -->Neil
>
> -------------------------------------------------------------------------------
> Neil Bradley Seti@Home Hall of Shame on a 80386DX16, Intel 80387
> Synthcom Systems, Inc. 32MB RAM, Win 95 Status: 48.425% complete
> ICQ # 29402898 CPU Time: 1721 Hours 14 minutes 53.4 sec
>
> ---------------------------------------------------------------------------
> ** To UNSUBSCRIBE from vectorlist, send a message with "UNSUBSCRIBE" in the
> ** message body to vectorlist-request@synthcom.com. Please direct other
> ** questions, comments, or problems to neil@synthcom.com.

--
Windows:
32 bit graphical interface for a
16 bit patch for an
8 bit operating system written for a
4 bit processor by a
2 bit company that can't stand
1 bit of competition.
---------------------------------------------------------------------------
** To UNSUBSCRIBE from vectorlist, send a message with "UNSUBSCRIBE" in the
** message body to vectorlist-request@synthcom.com. Please direct other
** questions, comments, or problems to neil@synthcom.com.