65XX SBC general help and color display help needed

[backspace119]

So after much deliberation on my part, I think I might be jumping straight to a NTSC/PAL video out, with text display as the first target.

My reasoning here is, there have already been a few successful designs made with NTSC/PAL that I could potentially use, and I've had trouble finding a nice LCD (the largest I've found is 40x4 characters, and it's very expensive. There are 20x4 boards that are cheaper, but I don't think I'll be able to get enough text on the display to do a whole lot with it (80 characters total is pretty small)).

The very, very good news is, I actually found a project (albeit for arduino) that makes use of the chip mentioned earlier in this thread. You can find it here. I could order one of these shields and set it up to work with the 65816 (the whole setup works over SPI, and the chip takes care of the heavy lifting) or I can just look at the schematic he has here and integrate it into my board (or build a daughter board).

At any rate, I think the implementation I found for this chip is going to be a very valuable resource for doing my own video setup (that doesn't involve programming a go between MCU)

I think this is probably the best route, but I'm always open to suggestions (or places to get large text panels that may be easier to interface than this)

[backspace119]

An update, I've began laying out the schematic (again, somehow I guess the program crashed while I was gone or something, wasn't open and my schematic was gone) and I've decided to incorporate the 28L92 (in plcc package from mouser) since I'm already having to use a plcc for the 65SPI. Because of this, I can use the documentation for it and make it a lot easier to integrate it as a DUART.

I do have a question though, and I think BigDumbDinosaur may know the answer. In the documentation on integrating the 28L92, it states to use a 3 to 8 converter for selecting the UART, listing the other 7 outputs as "fill as necessary" or similar. Are the other pins for other IO chips? Or are the other pins used within the UART somehow? If anyone knows the answer drop it here, I'll post the schematic once it's more fleshed out.

[Chromatix]

Yes, those are for other I/O devices. The 3-to-8 decoder is part of your address decoding circuitry.

[backspace119]

Chromatix wrote:

Yes, those are for other I/O devices. The 3-to-8 decoder is part of your address decoding circuitry.

Thanks for the help.

I've just finished setting up the backend of the RS232 circuit (address decoding is on its way to it, just have to uncomplicate my memory map) Here's a picture of the relevant area of the schematic, does it look right to everyone?

(BTW, I've been making KiCad parts like crazy, if there's somewhere that, when I'm done, I can put all these parts so others can have access and use them in the future that would be great)

[backspace119]

So, the big road block I keep hitting in address decoding is this:

Since I'm using the upper 8 bits of the address space (A16-A23) do I need to qualify the IO and EEPROM by passing all of A16-A23 through nor gates and then ANDing that with their normal qualification?

Also, I should mention I've reduced my memory to 32KB, since it's hard to find chips larger than this that are fast and in DIP packaging. so addresses above 7FFF are now available to EEPROM and IO, which is making me consider using 16K eeprom and leaving 16K space for IO.

All input is appreciated, and thanks for all the help so far.

[whartung]

This:

backspace119 wrote:

So, the big road block I keep hitting in address decoding is this:

Since I'm using the upper 8 bits of the address space (A16-A23) do I need to qualify the IO and EEPROM by passing all of A16-A23 through nor gates and then ANDing that with their normal qualification?

And:

Quote:

Also, I should mention I've reduced my memory to 32KB, since it's hard to find chips larger than this that are fast and in DIP packaging. so addresses above 7FFF are now available to EEPROM and IO, which is making me consider using 16K eeprom and leaving 16K space for IO.

Contradict each other a bit.

If you're only using the lower 64K, you don't need to decode A16-A23 at all.

[backspace119]

whartung wrote:

This:

backspace119 wrote:

So, the big road block I keep hitting in address decoding is this:

Since I'm using the upper 8 bits of the address space (A16-A23) do I need to qualify the IO and EEPROM by passing all of A16-A23 through nor gates and then ANDing that with their normal qualification?

And:

Quote:

Also, I should mention I've reduced my memory to 32KB, since it's hard to find chips larger than this that are fast and in DIP packaging. so addresses above 7FFF are now available to EEPROM and IO, which is making me consider using 16K eeprom and leaving 16K space for IO.

Contradict each other a bit.

If you're only using the lower 64K, you don't need to decode A16-A23 at all.

Sorry, I meant the initial flat ram in the first 16 bits is now only 32k, I'm still going to use Garth's 4MB memory module, addressed in the top 8 bits

[BigEd]

Do you want to restrict your I/O mapping to Bank 0? It would be conventional to do so, but it's a free choice. If your I/O mapping were as large as say 16k (pretty much the simplest possible decoding) then "wasting" 16k of each 64k bank might feel wrong. But if your I/O mapping were as small as 256 bytes, you might not care so much.

What this exposes is the interplay of your system design decisions and your software environment. How do you intend to use the many high banks of your machine? In particular, do you expect them to be contiguous, so a structure reached by a three-byte pointer might span a bank boundary? (Maybe a structure can even be larger than 64k?)

Choices, choices... this is the nature of engineering.

[backspace119]

BigEd wrote:

Do you want to restrict your I/O mapping to Bank 0? It would be conventional to do so, but it's a free choice. If your I/O mapping were as large as say 16k (pretty much the simplest possible decoding) then "wasting" 16k of each 64k bank might feel wrong. But if your I/O mapping were as small as 256 bytes, you might not care so much.

What this exposes is the interplay of your system design decisions and your software environment. How do you intend to use the many high banks of your machine? In particular, do you expect them to be contiguous, so a structure reached by a three-byte pointer might span a bank boundary? (Maybe a structure can even be larger than 64k?)

Choices, choices... this is the nature of engineering.

Ya, since day one this design has been a new choice every 5 minutes.

I worked on it last night, I think this is how I want the memory map to go and I have an idea I'll explain afterward for it:

Address map:

• 0x000000 0000 0000 0000 0000 0000 0000
  RAM - 32k
  0x007FFF 0000 0000 0111 1111 1111 1111
  
  0x008000 0000 0000 1000 0000 0000 0000
  I/O - 16k
  0x00BFFF 0000 0000 1011 1111 1111 1111
  
  0x00C000 0000 0000 1100 0000 0000 0000
  ROM - 16k
  0x00FFFF 0000 0000 1111 1111 1111 1111
  
  0x010000 0000 0001 0000 0000 0000 0000
  RAM2 - 4M
  0x40FFFF 0100 0000 1111 1111 1111 1111

and I've been thinking about adding a "ROM2" above RAM2 that has some more EEPROM space (also, the low EEPROM space (0x00C000-0x00FFFF) will be writable via a selectable dip switch, so once I'm confident the machine won't write garbage over my fresh kernal/bios/boot up sequence, I can develop updates on the machine for itself. I may do the same for ROM2 if needed).

My idea right now is, I can do some "normal" address decoding in the low order 16 bits, by this I mean a setup that's fairly standard, like the 3 to 8 decoder for IO, and using the highest address lines to select ROM and deselect RAM. Then, I can run the top 8 bits through 3 triple input nor gates, and run their output through a single triple input or gate (kicad didn't have one of these in DIP format so I just used 2 more nor gates which ends up at 3 gate delays). I can then take the result from this and us it to deassert all CEs for any chip that's in the low order 16 bits, thus creating a sort of 2 part system. I'm going to look around today for a DIP format triple input OR gate, and that will keep me at 2 gate delays for this high order mask.

[backspace119]

I think I've figured out the low 16 bit decoding by staring at the binary till it gave me an answer

A15 && !A14 == IO (A11, A12, and A13 through 3-8 decoder for 8 devices)

!A15 == RAM

A15 && A14 == ROM

and then use the "mask" I mentioned in my last post to turn off all low order devices (RAM, ROM, 3 to 8 ) when I'm addressing in the top 8 bits.

Does this seem about right?

[BigEd]

You might consider the 74X30 which is an 8 input NAND, and maybe the '688 or simlar as a byte wide comparator. (See here.)

For your high-bank ROM decode, perhaps you can just use A23? Redundant (incomplete) address decoding is normal! Perhaps think of the multiple-appearance ROM as populating bank FF downward and the big RAM as populating bank 01 upwards. (The big RAM actually appears from 01 to 7F, but from 41 upwards is duplicated.)

[backspace119]

BigEd wrote:

You might consider the 74X30 which is an 8 input NAND, and maybe the '688 or simlar as a byte wide comparator. (See here.)

For your high-bank ROM decode, perhaps you can just use A23? Redundant (incomplete) address decoding is normal! Perhaps think of the multiple-appearance ROM as populating bank FF downward and the big RAM as populating bank 01 upwards. (The big RAM actually appears from 01 to 7F, but from 41 upwards is duplicated.)

Possibly, I'm going to look at high bank decoding in a bit, I want to have the first 16 bits decoded to all the base stuff for the machine (since it can technically run without the 4M RAM and however much extra ROM is in the top 8 bits). Thanks for the inputs on chips, I think Kicad doesn't have every type of 74xxxx chip out there in its standard libs, but I can always make more to use more appropriate chips.

[backspace119]

BigEd wrote:

You might consider the 74X30 which is an 8 input NAND, and maybe the '688 or simlar as a byte wide comparator. (See here.)

For your high-bank ROM decode, perhaps you can just use A23? Redundant (incomplete) address decoding is normal! Perhaps think of the multiple-appearance ROM as populating bank FF downward and the big RAM as populating bank 01 upwards. (The big RAM actually appears from 01 to 7F, but from 41 upwards is duplicated.)

Looking at it, I think I can use just the 688, with half its inputs tied to ground (and enable tied to ground) and I end up with an active high enable signal for the low 16 bits (if P = Q output is 1)

[backspace119]

Having an active high LOW16E (my signal for the low 16 enable) actually really helped a lot, I was able to use existing gates to finish up the wiring.

Now, the one thing that I'm still working on is what to qualify with phi2 and what not to qualify. I think that the SRAM CS\ needs to be qualified with PHI2, and possibly the CS\ for the EEPROM, the IO RDN\ and WRN\ signals are already qualified it as per the documentation on the 28L92 that was linked here earlier.

I think it matters that I put the qualification on CS of chips and not OE of chips, because the problem is the 65XX holds the RW high a hair longer than PHI2 is low, so the problem is writing, (and I guess bus contention with OE as well, but CS gets both). If so, I think I can qualify the SRAM and EEPROM fairly simply, and tie their OE inputs to the CS or to address bits that make sense.

[backspace119]

I started looking more closely at the EEPROM chips I had pulled up on mouser. Their access latency is pretty high, at 150ns, which, at a 1Mhz clock isn't a problem, but at the 5Mhz clock I'm planning, it is.

Should I change the qualification of EEPROM from phi2 low to VPA | VDA high? Would this give me enough time to access it? (The write operation seems to be kind of weird, although I have WE\ behind a dip switch so I can leave writing to eeprom disabled until I have it figured out)

Here's the datasheet