Shopping list for 6502 experiments

[BigDumbDinosaur]

barnacle wrote:

BigDumbDinosaur wrote:

Quote:

Cat-5 has 8 wires; 4 white, and 1 red, 1, green 1 blue, 1 brown.

That is slightly incorrect.  The four “white” wires in CAT5 UTP (also CAT3 and CAT6) are supposed to be white with color stripes that match with the solid colors to which they are paired.

To clarify the clarification; the 'red' mentioned above is actually orange.

I’ve seen examples that appeared closer to red than orange, but you are correct that it is supposed to be orange.

Quote:

To keep things moderately simple, the 1-5 colours are repeated through the cable; the trace colours change with each group of five: white, red, black yellow violet. If the cable is more than fifty pairs, it starts again at the beginning; 100 pair cables were common. Which means you have to keep an eye on which colour lives with each group; I once had to rewire an entire studio (in Kiev!) where the original wireman had not realised that.

100-pair cables here are similar, although sometimes the slate pair is referred to as grey.  I, fortunately, never had to terminate a 100-pair cable, but did do a couple of 50-pair ones.  Talk about tedious work...!

As for the studio in Kiev, one has to wonder if it is still standing. 

[nrrd]

I've been away, read the Primer, had a thought about the memory map I want to implement, and have come up with the following scheme.

The rational for it is that it should be simple but flexible. The idea is that there is always 32KB of low RAM, minus the 256B at the top of the RAM for the I/O.
The upper 32KB is either ROM or RAM, and can be swapped in banks.
Bank 0 is ROM, so that on reset the ROM will be enabled.
Banks 1 to 127 are also ROM, but don't need to be installed - you can use as many lines from the 273 as desired.
Banks 128 to 255 are RAM. Again, these don't need to be installed or used. Weird behaviour is that bank 128 will mirror the low RAM, but I think that is fine.
I've drawn the schematic to have a 512KB RAM and 512KB ROM, as these don't cost much more than a 128KB RAM and ROM. A RAM / ROM expansion could use the remaining 3 lines from the 273

This seems to me to be a good way to organise and use the RAM / ROM, but let me know if it's not. I acknowledge my Newbie-ness!

I'm quite pleased with the number of gates - I did a whole page of logic simplification for the first time since I did my Computing and Maths degree 30 years ago! However, there is 5 NAND gates, and it would be great to remove one to get them down to a single quad NAND chip.

Please provide any comments. I need to check the timings and phases to make sure I've got the signals conditioned by the clock correct.
Thanks!

(Edit: re-uploaded the schematic in a readable with eyes format)

[barnacle]

Watch the response time of that 74hc30 - pushing 30ns, a lot slower than some others in the family. Might be an issue for your decoding speed...

Neil

[nrrd]

barnacle wrote:

Watch the response time of that 74hc30 - pushing 30ns, a lot slower than some others in the family. Might be an issue for your decoding speed...

Neil

Thanks. The 74AHC132 looks like a better chip - maximum propagation time of 6.5ns at 5V.

(Also a Neil - Hello!)

[BigDumbDinosaur]

barnacle wrote:

Watch the response time of that 74hc30 - pushing 30ns, a lot slower than some others in the family. Might be an issue for your decoding speed...

Yep!  Better to use a 74AHC30 or a 74ACT11030 (former preferable), with a substantially faster prop time.  You have quite a bit of cascading glue logic, which will introduce more prop delay than you probably want.

I have to question the use of that much ROM.  Just what-all are you planning to put in there?  Also, your decoding is too granular for discrete logic...a 256 byte I/O window is the province of PLDs, not discretes.

74ahc30_NAND_8input.pdf

74AHC30 8-Input NAND

(247.76 KiB) Downloaded 16 times

74act11030_NAND_8input.pdf

74ACT11030 8-Input NAND

(387.73 KiB) Downloaded 16 times

[nrrd]

BigDumbDinosaur wrote:

barnacle wrote:

Watch the response time of that 74hc30 - pushing 30ns, a lot slower than some others in the family. Might be an issue for your decoding speed...

Yep!  Better to use a 74AHC30 or a 74ACT11030 (former preferable), with a substantially faster prop time.  You have quite a bit of cascading glue logic, which will introduce more prop delay than you probably want.

In my defence, it is written as 74AHC30 on the schematics! However - Mouser doesn't have these in PDIP, so an alternative will have to be found. I'll check out the other chip you mentioned.

BigDumbDinosaur wrote:

I have to question the use of that much ROM.  Just what-all are you planning to put in there?  Also, your decoding is too granular for discrete logic...a 256 byte I/O window is the province of PLDs, not discretes.

The price differential between a 128KB SST39SF Flash ROM, and a 512KB one is £0.79. I might never fill even 10% of it, but you never know. Also, with the banking, it will be easy to have 8 x 32KB ROMs in effect.

I don't really understand your comment about the 256 byte I/O window. The logic is not too complicated and is not too dissimilar to what you used on your POC 1.3 (which is great, I've been studying it a lot). Even if I expanded the area to 2KB, it would still use the same number of chips, with the same propagation delay.

Edit - counting the chips from the A15 line through to ~{A15} to ~{CS_IO} to ~{BANK_CS} to BANK_LD to HIRAMEN is 5 chips, so that is potentially a lot of delay. Might be time to think again.
Edit (2) - the RAM speed is 55ns. I assume it is best to keep propagation delay below this, and preferably below half of this?

Thanks.

[barnacle]

nrrd wrote:

In my defence, it is written as 74AHC30 on the schematics!

Mea culpa. For my eyes are old and my knees are knackered, and I failed to zoom in the diagram sufficiently!

Neil

[AndrewP]

Two thoughts occurred to me off the top of my head.

Instead of using a 74HC137 you could instead use the faster 74AHC138 as you're using the latch in transparent mode (/LE tied to ground)

I'm not sure the NAND gate U7C is entirely working as expected. If the address decoding generating /bankcs finishes before PHI2 goes hign the '273 will trigger early and latch whatever is still sloshing around on the databus at that time. It will then trigger again as PHI2 falls at the end of the cycle correctly latching the databus. Probably not a problem as you're not using the ROM at that time but worth bearing in mind that there'll be glitches on a15e to a18e.

[BigDumbDinosaur]

nrrd wrote:

Edit - counting the chips from the A15 line through to ~{A15} to ~{CS_IO} to ~{BANK_CS} to BANK_LD to HIRAMEN is 5 chips, so that is potentially a lot of delay.

Yes it is.  If you look at POC V1.3’s glue logic, you will see I have no more that two gates between the MPU and RAM, ROM or I/O (the 74AC138 decoder).

Regarding the 74AHC30, the 74ACT11030 is functionally identical and is available in PDIP (part number SN74ACT11030N from TI).  My one caution with using 74AC logic is the aggressive output may causing substantial ringing if your construction is not good.  Running 74AC logic on a breadboard is far from ideal.

74AHC logic has the prop time of 74AC, but the gentler edges of 74HC.  Either way, proper bypassing is de rigueur for stability.

Quote:

Edit (2) - the RAM speed is 55ns. I assume it is best to keep propagation delay below this, and preferably below half of this?

You can go pretty fast with 55ns RAM if you correctly utilize it.  However, with your current design, the glue logic will likely get in the way before the RAM’s performance becomes an issue.

[nrrd]

BigDumbDinosaur wrote:

nrrd wrote:

Edit - counting the chips from the A15 line through to ~{A15} to ~{CS_IO} to ~{BANK_CS} to BANK_LD to HIRAMEN is 5 chips, so that is potentially a lot of delay.

Yes it is. 

It's even worse, as I didn't count the two chips between HIRAMEN and ~{RAMEN}. So it is 7 in total to set the status of ~{RAMEN}.

Thanks everyone, back to the drawing board / EDA. Doesn't the 6502 Primer says that newbies invariably over-complicate their glue logic?

[plasmo]

You can design a 6502 SBC without any glue logic and run it fairly fast at 14Mhz, viewtopic.php?f=4&t=6455&start=75#p114984

[BigDumbDinosaur]

nrrd wrote:

Doesn't the 6502 Primer says that newbies invariably over-complicate their glue logic?

Something to that effect...and it is true.  Newbies are aghast if they don’t use every last byte in the 65C02’s address space for...something. 

POC V1.3 has 48K of base RAM ($000000-$00BFFF), 12K of ROM ($00D000-$00FFFF) and 64K of extended RAM ($010000-$01FFFF).  I “wasted” 4K on I/O ($00C000-$00CFFF).    This was the result of the design requirement I set back when I designed POC V1.0, which was to have no more than two gate delays in the address decoding logic.  Does it bother me that I’m wasting all that I/O space?  Not at all! 

A simplified version of the glue logic I designed for POC V1.3 can be adapted to the 65C02, producing a workable memory map for hobby purposes.

65C02 Glue Logic

The above is a four-chip solution that will readily handle 30+ MHz with 74AC or 74AHC logic.  74AHC logic should be used if possible to make the physical construction a little less touchy.

For more address-decoding granularity, it is advisable to consider programmable logic rather than more discrete gates.  PLDs were developed to avoid the deleterious effects on performance as glue logic density is increased.  A single 22V10 GAL can do what the above does, all the while exhibiting a constant prop delay, regardless of the address bus conditions (the Atmel ATF22V10-7 has a pin-to-pin prop time of 7.5 nanoseconds).  Also, use of a PLD allows you to narrow the I/O window size without incurring more prop time.

With all that said, I recommend your first build be with discrete logic so you can get real comfortable with how it all works.  If you have access to a decent scope or, better yet, a logic analyzer, an evening spent making observations can be very instructive.

[nrrd]

I've made a new, refined version, mostly after studying Big Dumb Dinosaur's POC 1.3.
I've widened the I/O to 1KB, and used all the enable gates on the 138 to simplify the logic.
I've also added the 08 and gates on the extended address lines as I realised that, without them, the user would have to reset the 273 before accessing the low RAM (first 32KB). This way they can set up the bank and then use low RAM and the bank without incurring an extra instruction to reset the 273.

There are still quite a few gates. 4 to set the bank, and 3 to select the ROM or RAM chip.
However, I've convinced myself that this does not add up to 7 as setting the bank will be done the instruction before accessing the memory. So it is 4 to set the bank, and then 3 to access the memory. Let me know if my assumptions about this are incorrect!

I've got to decide whether to take this forward. The other options are:
1. use a 65c816 or
2. use a 68000 (with apologies to the entire forum!) I know 68k from my Amiga days
3. build a predefined system or kit (but which one?)

Thanks!

[BigDumbDinosaur]

nrrd wrote:

I've widened the I/O to 1KB, and used all the enable gates on the 138 to simplify the logic.

I've also added the 08 and gates on the extended address lines as I realised that, without them, the user would have to reset the 273 before accessing the low RAM (first 32KB). This way they can set up the bank and then use low RAM and the bank without incurring an extra instruction to reset the 273.

First off, where it says “$8400 - $FFFF : (31KB) BANKED RAM/ROM” on your drawing, it doesn’t tell the reader what determines if RAM or ROM will appear in that range.  You probably should set up a little table that indicates what bit pattern does what when written to U5 (bank register).

Speaking of U5, I think you have a booby-trap waiting for you in how you are accessing it.  On a write, gating U2A with Ø2 will work, as U5 will only read in the bit pattern when it has been selected and Ø2 subsequently makes a low-to-high transition.  That’s all well and good.  But...

Suppose, due to some ham-fisted programming, U5 gets selected during a read cycle.  What do you think will happen to U5 when Ø2 goes high?    Hint: you will likely mutter naughty words under your breath as you reach for the reset push button. 

Quote:

There are still quite a few gates. 4 to set the bank, and 3 to select the ROM or RAM chip.  However, I've convinced myself that this does not add up to 7 as setting the bank will be done the instruction before accessing the memory.

Timing-wise, your bank register selection glue logic is good enough—the 74AC00 can manage single-digit prop times, and the 74AC138 is in that range as well.

I don’t think you have too many options with controlling RAM and ROM selection, due to the banking scheme you are using.  Your glue logic actually favors the ROM, which sees only two gates between itself and the raw address bus.  ROM will be selected within 12ns after the address bus has settled.  RAM, having one more gate delay, should be ready to go in 18ns after the address bus has settled.

Based upon timings I have observed with several 65C816s, I am of the opinion the address bus will be settled no more than 12ns after the fall of the clock.  That being the case, RAM would be awake 30ns after the fall of the clock, which equates on paper to 16 MHz capability.  Practically speaking, this circuit’s clock ceiling will be determined by the RAM or ROM speed—whichever is slower, not the glue logic.

Quote:

I've got to decide whether to take this forward. The other options are:
1. use a 65c816 or
2. use a 68000 (with apologies to the entire forum!) I know 68k from my Amiga days
3. build a predefined system or kit (but which one?)

You won’t learn as much from choice #3, nor will you get as much satisfaction, since someone else will have done the brain-work and possibly the construction as well.

Choice #2...well, it ain’t a 6502-family system... 

Choice #1 should be your next project, as the 65C816 handles large address space far more gracefully than possible with a 65C02.  Plus there are all those new instructions that give you a quantum leap in power, not to mention having 16-bit registers at your disposal.

Choice #4 is to go with your banking scheme, but do it with a couple of GALs.  One GAL can provide the chip select glue logic (the “glue logic GAL”), and the other GAL can act as the bank register.  The entire mess can be encapsulated in a pair of 22V10s, which are available from Atmel in speeds down to 7.5ns, which is the worst-case pin-to-pin prop time using combinatorial logic. 

Of the 22 signal pins on each GAL, 10 can be configured as inputs or outputs, and the remaining 12 would be inputs.  Outputs can be configured to act as D-flops, thus making it possible to synthesize the AC273.  The work of U1, U2A and U4 would be done by the glue logic GAL.  U7’s function would be handled by the bank register GAL by wiring A15 to one of that GAL’s inputs.  U2 can remain for your read/write logic, with one of U2’s gates available to act as an inverter if needed.

You would have a design that could conceivably run beyond 20 MHz with wait-stating.  However, building it in discrete logic will be more instructive.  Decisions, decisions! 

[nrrd]

Thanks as always Big Dumb Dinosaur. I think I'm getting somewhere now, and learning lots.

BigDumbDinosaur wrote:

First off, where it says “$8400 - $FFFF : (31KB) BANKED RAM/ROM” on your drawing, it doesn’t tell the reader what determines if RAM or ROM will appear in that range.  You probably should set up a little table that indicates what bit pattern does what when written to U5 (bank register).

I was thinking about this and it occurred to me that the 6502 is little endian, so the way it is set up at the moment is:

Code: Select all

$0000 = ROM BANK 1
$8000 = ROM BANK 2
$4000 = ROM BANK 3
$C000 = ROM BANK 4

$0001 = RAM BANK 1 (mirrored low RAM)
$8001 = RAM BANK 2
$4001 = RAM BANK 3
$C001 = RAM BANK 4

I think this is correct? But it is not how I want it to workt. What I really want is:

Code: Select all

$0000 = ROM BANK 1
$0001 = ROM BANK 2
$0002 = ROM BANK 3
$0003 = ROM BANK 4

$8000 = RAM BANK 1 (mirrored low RAM)
$8001 = RAM BANK 2
$8002 = RAM BANK 3
$8003 = RAM BANK 4

I think I just need to reorder the output from the latch to do this.

BigDumbDinosaur wrote:

Speaking of U5, I think you have a booby-trap waiting for you in how you are accessing it.  On a write, gating U2A with Ø2 will work, as U5 will only read in the bit pattern when it has been selected and Ø2 subsequently makes a low-to-high transition.  That’s all well and good.  But...

Suppose, due to some ham-fisted programming, U5 gets selected during a read cycle.  What do you think will happen to U5 when Ø2 goes high?    Hint: you will likely mutter naughty words under your breath as you reach for the reset push button. 

I was thinking about this when I couldn't sleep at 5:30 this morning. I can just qualify it with the write line, but I have to make sure I haven't changed the phase of the clock.