Hello,
don´t you beat me please. A probable solution to as well the MMU
footprint as also 6809/6809E compatibilty could be the usage of a CPLD,
which irons out the 6809/6809E differences and enables to shrink the MMU
layout to four chips (EPM7218SLC84 as 84-pin CPLD, 2x CY7C185 for page
mapping storage, 74HCT245 for isolating the data buses of the MMU
underneath).
The CPLD could be easily programmed via a JTAG connector with a 6809 or
a 6809E personality to meet the suggested CPU type. It has enough macro
cells for the MMU and the 6809/6809E logic switches.
Joe
Am 30.10.2013 12:03, schrieb Andrew Lynch:
> Hi
>
> Well this is an example of the kind of trade off discussions we are going to have. As you point out there is limited PCB real estate so we are going to have to make choices. Not everything is going to fit.
>
> I am fond of the 6802 due to history with that chip. Although if I had to choose between it and more robust 6809 support (NitrOS9, etc) I would probably go with the robust 6809 support at the expense of the 6802.
>
> The issue as I see it is we need to settle on a design and layout a PCB. That will help us assess how much real estate is available and remains for "nice to have" features like the jumpers/pull-up resistors for 6802 compatibility. However, if by going down the 6809 path further with the MMU it in turn causes additional complexity with the 6802 support then I can see it going away.
>
> At the moment it is all sort of in the abstract though. In terms of priority, I would say 6809 first, 6502 second, and then 6802. We were able to take advantage of a very nice set of commonality of the 6502/6802 due to selecting subset of each to maximize a common mode on the 6x0x HP however that may no longer work.
>
> Thanks and have a nice day!
>
> Andrew Lync
>
>
> --------------------------------------------
> On Wed, 10/30/13, John Coffman <johninsd-***@public.gmane.org> wrote:
>
> Subject: Re: [N8VEM: 16436] new 6x0x board project - LS612 caution
> To: "n8vem" <n8vem-/***@public.gmane.org>
> Date: Wednesday, October 30, 2013, 6:03 AM
>
> To say the 6502 and 6802 have
> common pinouts is a serious misstatement. Yes, the VCC and
> two VSS pins are in the same place. The address and data
> lines are in the same place.
> Beyond the above, 4 signals are on the same
> pins:
>
> 6502
> 6802pin 4 /IRQ
> /IRQpin 6 /NMI
> /NMIpin 40 /RESET
> /RESETpin 34 R/W
> R/W
>
>
> But there are 7 differences:
> 6502
> 6802pin 2 RDY input
> /HALT inputpin 3 clock out
> MRDY input
> pin 5 unused VMA
> outputpin 7 SYNC out BA
> (bus available) outpin 39 clock 2 out
> EXTAL inputpin 38 /SetOvfl in
> XTAL (grounded w/ osc input on EXTAL)
> pin 37 clock 0 in E bus clock
> output
> Two more pins are different, but are NoConnects
> on the 6502, so they present no problem:pin 36
> n.c. RAM enable
> (connected to pin 35 on
> the original schematic)
> pin 35 n.c. VSTANDBY
> (4.0 - VCC) (connected to pin 36 on the
> original schematic)(BTW: the original schematic
> connects these two backwards? Is the 6802 documentation
> incorrect? Or are they backwards on the previous board?
> I've seen only the schematic. I haven't checked
> the board.)
>
> The original schematic took some
> shortcuts:pin 2 was pulled high. The 6502 could
> not insert wait states.pin 3 could be jumpered to
> the MRDY signal on the board for the 6802; but there was no
> provision to connect it to pin 2 for the 6502.
> pin 5 was not connected; the board did not use the 6802
> VMA signal.pin 7 was not connected; the 6802 had
> no DMA capability. Design spec for the new board calls for
> ECB DMA capability.pin 38 was tied to GND for the
> 6802 osc. input requirement. The 6502 worked perpetually
> with the Set Overflow signal asserted. I don't know
> the s/w implications of this.
>
> Pins 37 and 39 were properly jumpered between Osc
> input and E clock output.
> With all the peripherals intended for this ATX/6U
> board, we are rapidly running out of real estate. The MMU
> alone adds 7-10 chips. I think a simpler I/O decode will
> cut a couple of chips. DMA capability will add
> chips.
>
> Building a board to support 2 CPU's is a goal
> in itself. [6502/6809]. The addition of the MMU was
> specifically for the 6809 to run a port of NitrOS level
> 2.
> If multiple (3) CPU's are the goal of the
> project, then I say forget the MMU.
>
> If a mapped 6809(E) is the goal, then scotch the
> multiple CPU idea entirely.
> The original target for this project was to take
> the 6x0x chips and add all the peripherals to make a
> complete computer-on-a-board. The mention of mapped NitrOS
> level 2 has muddied the waters.
>
> STOP REWIND What are we
> building?
> --John
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> On Tue, Oct 29, 2013 at
> 7:14 PM, Andrew Lynch <LYNCHAJ-/***@public.gmane.org>
> wrote:
>
>
>
> HI
> Yes, the 6502 and 6802 are
> very similar pin-outs. There is hardly any difference at
> all.
>
> The jumpers required are
> minimal on the 6x0x host processor.
>
>
> Maybe two or three and a
> pull up resistor? They are nearly common pin
> outs.
>
> Thanks and have a nice
> day!
>
>
>
> Andrew Lynch
>
> From: n8vem-/***@public.gmane.org
> [mailto:n8vem-/***@public.gmane.org]
> On Behalf Of Dan Werner
>
>
> Sent: Tuesday, October 29, 2013 8:30 PM
> To: N8VEM
> Subject: Re: [N8VEM: 16427] new 6x0x board project -
> LS612
> caution
> Yes the 6802 works and we do
> have a port of Flex running on it. The 6802 is pin
> compatible with the 6502 with the jumpers set
> properly.
>
> Dan
>
> On Tue, Oct 29, 2013 at 2:21 PM, John Coffman <johninsd-***@public.gmane.org>
> wrote:Dan,
>
> Have you actually run a 6802
> in the former board. The 6502 and 6802 pinouts are so
> different that it seems a forest of jumpers are required to
> allow both chips in the same slot. I count a 7 pin
> difference.
>
> You had a provision to enable
> the 128 bytes of 6802 on-chip RAM, and to battery back it,
> but there was no address decode to prevent a data bus
> conflict when the RAM was read. Likewise, there was no
> provision to watch for a power failure and to drop the RAM
> enable before power dropped too low.
>
> Full support for a 6802 is
> going to take a good bit of board space. Since the 6809
> executes a superset (so Motorola claims) of the 6802
> instruction set, I am formally proposing to the group to
> drop all 6802 support.
>
> --John
>
> On Tue, Oct 29, 2013 at 6:28
> AM, Andrew Lynch <lynchaj-/***@public.gmane.org>
> wrote:
>
> Hi
>
> Ultimately what features are added to the 6x0x will come
> down to a decision based on PCB real estate. The new form
> factor (6U & ATX) are hard limited to ~58 square inches.
> There is an upper limit to how many components can be added
> to the board and still be able to trace route successfully.
> We had a prototype board schematic and PCB layout ready to
> go but those have been scrapped when we decided to add in
> the MMU functionality.
>
>
>
> John is working on the new schematic and I will work the PCB
> layout once he gets it stable. I think we can get the MMU
> to fit but it will be tight resulting in a much denser
> board. The current layout has four rows; IO connectors,
> large chips, smaller chips, and power circuitry. To make
> the MMU work we will need to add in a fifth row of parts
> which is going to soak up any real estate which had been
> used for trace routing.
>
>
>
> I recommend holding off on any more additions until we know
> the state of the PCB layout from the MMU set of changes.
> If there is space available for additional components we
> should consider it then. It sounds like only an additional
> 573 latch and probably some jumpers but does it affect other
> components? I don't know but we should wait to see the
> most recent PCB layout before committing to more changes.
> As the board fills up and gets tighter the impact on trace
> routing from adding components increases
> exponentially.
>
>
> Thanks and have a nice day!
>
> Andrew Lynch
>
>
> --------------------------------------------
> On Tue, 10/29/13, Ian May <fps16xn3-***@public.gmane.org>
> wrote:
>
>
>
> Subject: Re: [N8VEM: 16421] new 6x0x board project - LS612
> caution
> To: n8vem-/***@public.gmane.org
> Date: Tuesday, October 29, 2013, 8:58 AM
>
>
> Why not just
> replace the 6502 with a WDC65C816? The WDC65C816 costs a
> $1
> more than the WDC65C02 ($7.95 vs $6.95 at Jameco). Both
> are
> current production and available from Jameco, Mouser and
>
>
> other sellers. The WDC65C816 goes into emulation mode
> after
> reset and behaves exactly like a 6502 (without the bugs
> but
> the 65C02 bit manipulation instructions are not
> provided).
> Changing to native mode is done via software. The penalty
> is
>
>
> a slightly different pin-out which will require changes
> to
> the 6502/6802 selection system. The data and low 16 bit
> address lines are on the same pins as the 6502. The
> '573
> latch for the high address lines would need jumpering to
>
>
> force it to zeros in 6802 mode. There is no PHI2 out but
> WDC
> don't recommend using that on the WDC65C02 either.
> Documentation is here http://www.westerndesigncenter.com/wdc/documentation.cfm
>
>
> . I would recommend reading the data-sheets there and the
> assembly language programming manual.
>
>
> So downside, changes to 6802/65C816 selection jumpers
> and one extra '573 latch. Upside, you can still run
> it
>
>
> as a 6502 but you can also use 16 bit mode and have a 24
> bit
> address bus.
>
> Cheers,
>
> Ian.
>
>
> On Mon, Oct 28, 2013 at
> 8:17 PM, Borut <bkorosin-***@public.gmane.org>
>
>
> wrote:
>
> John,
>
> LS612 was just an assumption based on previous posts and
> it
> doesn't impact what i wanted to say.
>
> (But i like the approach described here: http://nouspikel.group.shef.ac.uk/ti99/superams.htm#74LS612
>
>
> )
> The 6x0x board at the moment supports 3 CPUs. It could,
> with
> the help of an additional small board, support an
> additional
> CPU.
>
> 65816 is a 16 bit version of 6502 with higher address
> lines
> (a16 - a23) multiplexed with data bus.
>
>
> Additional board would contain 65816 and demultiplex this
> address lines, bypass the MMU and directly connect this
> additional address lines to the board.
>
> That way, 65816 could directly address the whole memory
>
>
> space.
> The one 'request' i have is to put a small header
> with this additional address lines from MMU somewhere
> close to 6502 socket and to do it in a 0.1 inch spacing,
> so
> it is easier to
>
> develop the additional plug-in board using a prototyping
>
>
> board.
> I had this same problem with existing 6x0x board when i
> connected a propeller to 6821 and wanted to tap some
> signals
> from
> P14 and P15 connectors. The pad positions between
> components
> are not in 100 mils raster so it is necessary to do some
>
>
>
> wire bending and the construction can't be so tight.
> Since this new board is redesigned, such a small change
> would facilitate experimenting (for me).
>
> The same approach, using an additional board, has been
> used
>
>
> before, but my 6x0x boards are newer versions, so i
> can't comment on
>
> how useful was it.
>
>
> Andrew,
>
> The reset circuit on both of my 6x0x works very
> unreliably,
> so i replaced it with a dedicated one chip cpu monitor.
>
>
> What are other builders experiences with this part of the
> board?
>
>
> Borut
>
> Dne ponedeljek, 28. oktober 2013 01:16:21 UTC+1 je oseba
> John Coffman napisala:
> Borut,
> I think the idea of using the LS612 is dead.
>
>
> I've proposed a 7 chip MMU along the lines of what
> I
> sent as a schematic. 4K pages, 512K RAM, 512K ROM.
> I/O
> mapped to one page.
>
>
> Watch for posts on the Wiki.
> =================================
>
>
> BTW: can anyone tell me why this board has 2
> CPUs? They are not code compatible.
>
>
> --John
>
>
>
> On Sun, Oct 27, 2013 at
> 4:25 PM, Borut <bkor...-***@public.gmane.org>
> wrote:
>
>
>
>
> In case we include a MMU like 74LS612, which would
> extend the number of address lines, would it be possible
> to
> bring these new address lines
>
>
> somewhere close to the 6502 socket in 0.1 inch raster and
>
>
> add a header for them?
> That way it would be possible to populate the board
> without
> the MMU but instead of 6502 CPU use an additional board
> which would
> include 65816 and a latch plus some logic and could
> directly
>
>
> address the whole memory.
>
>
> Something like 6502 processor on the first version on
> 6x0x
> board.
>
> Borut
>
> Dne sobota, 26. oktober 2013 01:33:12 UTC+2 je oseba John
> Coffman napisala:
>
>
>
>
>
>
>
>
>
> Oscar,
>
>
>
> These pages you pointed me toward had me
> befuddled.
> Then it dawned
> on me that the datasheet for the LS612 was the
> source of
> my
> confusion. So ....
>
>
>
>
>
>
>
> ******** CAUTION
> ********
>
>
>
> To All:
>
>
>
> TI labels bits differently from Intel,
> Zilog,
> Motorola, NatSemi,
> ... , and most of the world (except IBM).
>
>
>
>
>
> On the Z80, for example, D0 is the LSB, and D7 is
> the
> MSB. In
> addresses, A0 is the LSB and A15 is the MSB.
>
>
>
> For the LS612, bit numbering is just the opposite:
> D0
> is the MSB,
>
>
> and D7 is the LSB. Addresses get complicated,
> since A0
> is the MSB
> and A15 is the LSB, on a 16-bit machine. But the
> number of the LSB
> changes when you have 24 address bits.
>
>
>
> Logical addresses:
>
>
>
>
>
> Z80: A15 A14 A13 ... A2 A1 A0
>
> TI: A0 A1 A2 ... A13 A14 A15
>
>
>
> Now, when the LS612 maps addresses,
>
>
>
>
>
>
>
> A0 A1 A2 A3
> A4 ... A13 A14 A15
>
> becomes,
>
> A0 A1 A2 A3 A4 A5 A6 A7 A8 A9
> A10
> A11 A12 ... A21 A22 A23
>
>
>
> Maybe others were not confused, but I sure was.
>
>
>
>
>
> --John
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> On 10/25/2013 07:09 AM, oscarv wrote:
>
> Andrew,
>
>
>
> >> Also the current design has a 128KB
> SRAM
>
>
> which could be
> easily upgraded to 512KB but beyond that
> requires
> new components
> and layout.
>
>
>
>
> 512K is IMHO perfect for a base board. A 6809
> with
> 512K/MMU is
> (ahem) "Historically Representative"
> of
>
>
> high-end 6809 machines.
> Even the vibrant Coco3 community seems to see
> little
> benefit in
> more than 512K, from what I've read.
>
>
>
> >> What is the 74LS612 approach? I
> have no
>
>
> idea how to
> change the schematic or what other chips,
> components, etc are
> needed.
>
>
>
> I think the
> page here (link) is an extremely useful
> read -
> half-way
>
>
> through it shows the schematic of 612 and
> 512K
> srams.
>
> Also, Ruud
> Baltissens 612 page is useful.
>
>
>
> I was slow in picking this up, but apparently
> the
> LS612 is not
>
>
> exactly an exotic. It (or
> versions of it) hide in every PC/AT.
>
>
>
>
>
> Regards,
>
>
>
> Oscar.
>
>
>
>
> --
>
> You received this message because you are
> subscribed
>
>
> to the Google
> Groups "N8VEM" group.
>
> To unsubscribe from this group and stop
> receiving
> emails from it,
> send an email to n8vem+un...-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
>
>
>
> To post to this group, send email to n8...-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
>
> Visit this group at http://groups.google.com/group/n8vem.
>
>
>
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>
>
>
>
>
>
> --
>
> You received this message because you are subscribed to
> the
>
>
> Google Groups "N8VEM" group.
>
> To unsubscribe from this group and stop receiving emails
> from it, send an email to n8vem+un...-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
>
>
>
> To post to this group, send email to n8...-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
>
> Visit this group at http://groups.google.com/group/n8vem.
>
>
>
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>
>
>
>
>
> --
>
> You received this message because you are subscribed to
> the
>
>
> Google Groups "N8VEM" group.
>
> To unsubscribe from this group and stop receiving emails
> from it, send an email to n8vem+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
>
>
>
> To post to this group, send email to n8vem-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
>
> Visit this group at http://groups.google.com/group/n8vem.
>
>
>
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>
>
>
>
> --
>
> You received this message because you are subscribed to
> the
>
>
> Google Groups "N8VEM" group.
>
> To unsubscribe from this group and stop receiving emails
> from it, send an email to
> n8vem+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
>
>
>
> To post to this group, send email to
> n8vem-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
>
> Visit this group at http://groups.google.com/group/n8vem.
>
>
>
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>
> --
> You received this message because you are subscribed to the
> Google Groups "N8VEM" group.
>
>
> To unsubscribe from this group and stop receiving emails
> from it, send an email to n8vem+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
> To post to this group, send email to n8vem-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
>
>
> Visit this group at http://groups.google.com/group/n8vem.
> For more options, visit https://groups.google.com/groups/opt_out.
>
> --
> You received this message because you are subscribed to the
> Google Groups "N8VEM" group.
> To unsubscribe from this group and stop receiving emails
> from it, send an email to n8vem+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
>
>
> To post to this group, send email to n8vem-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
> Visit this group at http://groups.google.com/group/n8vem.
>
>
> For more options, visit https://groups.google.com/groups/opt_out.
>
> --
> You received this message because you are subscribed to the
> Google Groups "N8VEM" group.
> To unsubscribe from this group and stop receiving emails
> from it, send an email to n8vem+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
>
>
> To post to this group, send email to n8vem-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
> Visit this group at http://groups.google.com/group/n8vem.
>
>
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>
> --
>
> You received this message because you are subscribed to the
> Google Groups "N8VEM" group.
>
> To unsubscribe from this group and stop receiving emails
> from it, send an email to n8vem+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
>
> To post to this group, send email to n8vem-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
>
> Visit this group at http://groups.google.com/group/n8vem.
>
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>
>
>
>
> --
>
> You received this message because you are subscribed to the
> Google Groups "N8VEM" group.
>
> To unsubscribe from this group and stop receiving emails
> from it, send an email to
> n8vem+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
>
> To post to this group, send email to
> n8vem-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
>
> Visit this group at http://groups.google.com/group/n8vem.
>
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>
--
You received this message because you are subscribed to the Google Groups "N8VEM" group.
To unsubscribe from this group and stop receiving emails from it, send an email to n8vem+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
To post to this group, send email to n8vem-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
Visit this group at http://groups.google.com/group/n8vem.
For more options, visit https://groups.google.com/groups/opt_out.