65XX SBC general help and color display help needed

[BigEd]

Generally speaking, I think, you should start an access as soon as you can. It's only stateful accesses which need to be held off until you're quite sure the right chips are enabled. So, CS should not be qualified by the clock, but the write signal should. To avoid contention, qualify OE with the clock: you set the access off early, but you don't drive the databus until later.

But many words have been spilt on the question of best practice for 6502 device decoding and I'm not sure where I'd look for a definitive description of best practice.

(Perhaps an interesting anecdote: I believe the (EP)ROMs on Acorn's Archimedes were always enabled at the beginning of every cycle, because they were so slow. Once the memory controller determined they weren't needed, they were (conditionally) disabled. This cost power but saved time, which was felt to be a good tradeoff.)

[backspace119]

BigEd wrote:

Generally speaking, I think, you should start an access as soon as you can. It's only stateful accesses which need to be held off until you're quite sure the right chips are enabled. So, CS should not be qualified by the clock, but the write signal should. To avoid contention, qualify OE with the clock: you set the access off early, but you don't drive the databus until later.

But many words have been spilt on the question of best practice for 6502 device decoding and I'm not sure where I'd look for a definitive description of best practice.

(Perhaps an interesting anecdote: I believe the (EP)ROMs on Acorn's Archimedes were always enabled at the beginning of every cycle, because they were so slow. Once the memory controller determined they weren't needed, they were (conditionally) disabled. This cost power but saved time, which was felt to be a good tradeoff.)

I'm going to look for that machine and see how they did it, in the mean time, here's a closeup of the WE\ OE\ and CS\ I have now:

look about right? I'm still worried that at 150ns it's being cut really close, so I may have to do what that other machine does.

[backspace119]

I honestly didn't expect to find this but here it is:

(no direct image because in the preview it took up my entire 4k monitor)
https://www.4corn.co.uk/archive/diagram ... iagram.jpg

If you look towards the center bottom right you'll see the EPROM chip, which has it's CE\ tied to ground, only the OE\ is ever qualified

I feel this is very close to the solution I need to be looking at, only qualify WE\ and OE\ to avoid bus contention and garbage writes

[backspace119]

Ok, so first off, I figured out my last schematic was wrong anyway, because I had the OE set like it was active high, when it's active low (and gate instead of nand gate) I've switched to a quad input nand gate with phi2\ included in the input, but phi2 has to go through an inverter to get phi2\, so this is 2 gate delays.

Here it is:

any ideas to get rid of that inverter so I only have one gate delay?

[drogon]

backspace119 wrote:

I honestly didn't expect to find this but here it is:

(no direct image because in the preview it took up my entire 4k monitor)
https://www.4corn.co.uk/archive/diagram ... iagram.jpg

If you look towards the center bottom right you'll see the EPROM chip, which has it's CE\ tied to ground, only the OE\ is ever qualified

I feel this is very close to the solution I need to be looking at, only qualify WE\ and OE\ to avoid bus contention and garbage writes

I think that's an Acorn System 1 board - this was a Eurocard based system. Odd the 1983 date though - I thought they were a year or 2 earlier than that.

-Gordon

[backspace119]

I feel like I can use VPA | VDA here instead of PHI2\ but getting VPA | VDA ends up with a gate delay itself

dragon wrote:

think that's an Acorn System 1 board - this was a Eurocard based system. Odd the 1983 date though - I thought they were a year or 2 earlier than that.

Interesting, I read a little bit about it on wikipedia as I was looking it up, it's a neat system.

[BigEd]

I don't think VPA and VDA are going to be so useful for this purpose: they are both valid for most of the clock cycle, changing fairly early. You need something like the clock, which distinguishes the early part of the cycle, when signals are not yet valid and are still changing, from the later part when they are valid and stable.

It might be worth reviewing previous adventures which played out here, such as Dolomiah's:
viewtopic.php?p=60915#p60915

[backspace119]

BigEd wrote:

I don't think VPA and VDA are going to be so useful for this purpose: they are both valid for most of the clock cycle, changing fairly early. You need something like the clock, which distinguishes the early part of the cycle, when signals are not yet valid and are still changing, from the later part when they are valid and stable.

It might be worth reviewing previous adventures which played out here, such as Dolomiah's:
viewtopic.php?p=60915#p60915

Thanks for the link, that's very informative and I'm going to rework my circuit a bit to be closer to that one. I realized I made a big issue here by qualifying on OE, because OE cannot be asserted when WE is asserted, for obvious reasons. so OE and WE should be asserted directly from RW and they should be done as quickly as possible (I actually already have a circuit that splits RW into two active low signals for the DUART, I can steal that and use it for OE and WE on RAM/ROM) So then, unfortunately I cannot leave CS tied to ground for the eeprom unless I explicitly further qualify it's OE and WE with the addresses that point to the EEPROM.

If I can ever get my head on straight I might have this thing worked out.

EDIT: Update, since my DUART write and read were already qualified with PHI2\ I've renamed them to WRITE\ and READ\ and they are now used throughout the circuit for OE and WE, the CS on each chip is not PHI2\ qualified and is only qualified with the required addresses for each chip. I think this is a simple solution, and actually may be faster as well (it's pretty much what was done in the post you linked I believe BigEd)

[backspace119]

On an unrelated note, I just found out something that may be kind of neat, I'll see if you guys think so.

Since the VIA has CS1 and CS2\ I could use a single output from the 3 to 8 decoder for 7 vias by attaching their CS1 inputs to A4,A5,A6...A10 (above A10 gets into the 3 to 8 decoder although honestly I could probably still use them, and end up with 10 VIAs on one output)

I was already planning a second VIA, so I think this is what I'll do for it, the other 6 outputs from the 3 to 8 are still unassigned (1 is DUART 2 is VIAS)

EDIT: I guess there's no reason I can't use A0 through A3 either, I was skipping them because they're used on the VIAs RS0 through RS3

[BigEd]

Using individual address lines as chip selects can be a good plan - IIRC the Asteroids cabinet does it. But you can't use those address lines for anything else, I don't think. If you need low address lines for register selects within a peripheral, I think you can't use them also for chip select of that peripheral - how would you access all the registers?

[GARTHWILSON]

Quote:

because OE cannot be asserted when WE is asserted, for obvious reasons

On most SRAMs (including mine), the OE\ input is ignored when WE\ is low. Having CS\, OE\, and WE\ all low at once is a valid write.

Quote:

so OE and WE should be asserted directly from RW and they should be done as quickly as possible

Starting the CS early on as Ed recommended is good (although in many cases not necessary for fast SRAM, which is available in speeds faster than anything else on the board). But assuming you do this, you absolutely must not assert WE\ before phase 2 rises. This is because WE\ is not guaranteed to wait until after the address is valid, let alone that it has given a decent setup time, and in fact it's not even guaranteed not to lead the address. IOW, if you don't wait for phase 2 to rise, you could be writing to an unintended address. You must make it impossible to write before phase 2 rises. (This is in the primer.)

About the address map: I haven't worked it out, but I expect it will be easier and result in fewer gate delays if you make your bottom 32KB of RAM to be part of the 4M memory module, rather than trying to make the module cover the second bank of the first 4MB through the first bank of the second 4MB. Yeah, you'll lose 32KB out of the 4MB; but it's a small price to pay for getting the other benefits.

[backspace119]

GARTHWILSON wrote:

On most SRAMs (including mine), the OE\ input is ignored when WE\ is low. Having CS\, OE\, and WE\ all low at once is a valid write.

The EEPROM chip I was looking at suggested that OE and WE must be used seperately, except I think it has a chip erase feature that uses both. I could be reading it wrong though EDIT: (although as you said, the SRAM is probably fine with them together)

GARTHWILSON wrote:

Starting the CS early on as Ed recommended is good (although in many cases not necessary for fast SRAM, which is available in speeds faster than anything else on the board). But assuming you do this, you absolutely must not assert WE\ before phase 2 rises. This is because WE\ is not guaranteed to wait until after the address is valid, let alone that it has given a decent setup time, and in fact it's not even guaranteed not to lead the address. IOW, if you don't wait for phase 2 to rise, you could be writing to an unintended address. You must make it impossible to write before phase 2 rises. (This is in the primer.)

Right, I mis-stated what I meant. both READ\ and WRITE\ are qualified with PHI2...except I may have qualified it backwards (I think I'm looking for PHI2 to go low rather than high, I'll have to check the layout)

GARTHWILSON wrote:

About the address map: I haven't worked it out, but I expect it will be easier and result in fewer gate delays if you make your bottom 32KB of RAM to be part of the 4M memory module, rather than trying to make the module cover the second bank of the first 4MB through the first bank of the second 4MB. Yeah, you'll lose 32KB out of the 4MB; but it's a small price to pay for getting the other benefits.

So, this may end up working better, but my reasoning so far was this:

1. I can run the machine without the 4M module, and it will run fine, just with a lot less memory
2. Even if the 4M module covers the bottom 32KB, wouldn't it still break the first 4M bank boundary? (I.E. there's 32KB in there that's dedicated to EEPROM and IO, so it would still go 32KB over the first 4M) <- I may be wrong on this part

I'll post the address decode schematic in just a minute, after I check how READ\ and WRITE\ are qualified with PHI2

EDIT: checked, it is correctly setup with PHI2 high being paired with READ\ and WRITE\

[backspace119]

Here's the address decoding, minus the EEPROM part (and individual address lines to the VIAs and 65SPI)

EDIT: ignore the HC/LS/etc on 74xx devices, I'm using standard libs in KiCad, when I make the BOM I'm going to get the fastest possible

[GARTHWILSON]

Quote:

So, this may end up working better, but my reasoning so far was this:

1. I can run the machine without the 4M module, and it will run fine, just with a lot less memory
2. Even if the 4M module covers the bottom 32KB, wouldn't it still break the first 4M bank boundary? (I.E. there's 32KB in there that's dedicated to EEPROM and IO, so it would still go 32KB over the first 4M) <- I may be wrong on this part

What I had in mind is that only the first 4MB of the memory map are used. Nothing from 4:0000 to FF:FFFF. The 4MB RAM goes from 00:0000 to 3F:FFFF; but when ROM or I/O are accessed, the RAM is disabled so the portion of RAM that occupies the same addresses space simply does not get used at all. 32KB of RAM in bank 0 is in a sense wasted, although it's a small price and well worth the rewards. I expect you'll find you can get away with simpler address decoding, and of course then you can forgo the 32KB RAM IC.

Another way to do it would be to put the 4MB RAM from 40:0000 to 7F:FFFF, and have a gap from 01:0000 to 3F:FFFF.

[backspace119]

GARTHWILSON wrote:

What I had in mind is that only the first 4MB of the memory map are used. Nothing from 4:0000 to FF:FFFF. The 4MB RAM goes from 00:0000 to 3F:FFFF; but when ROM or I/O are accessed, the RAM is disabled so the portion of RAM that occupies the same addresses space simply does not get used at all. 32KB of RAM in bank 0 is in a sense wasted, although it's a small price and well worth the rewards. I expect you'll find you can get away with simpler address decoding, and of course then you can forgo the 32KB RAM IC.

Another way to do it would be to put the 4MB RAM from 40:0000 to 7F:FFFF, and have a gap from 01:0000 to 3F:FFFF.

I think I like your alternate way here, since it allows me to still have my on board RAM (I'm really pushing for having the 4M module not be crucial to operation if possible). I'm not sure if the stack is allowed to span pages, but it could also allow me to have a hilariously large stack area if I put it at the very end of ram (and try not to run into it) and if it's not allowed, then oh well, I'll probably leave it set to its default on page 1.

I suppose having the RAM at the end of all that would help me get rid of my "mask" circuit, correct? I'm thinking at this point it would probably be difficult to add more EEPROM into the top 8 bits as well, and I might as well use serial eeprom behind the 65SPI if I need more, and just load what I get from there into RAM