6502.org Forum  Projects  Code  Documents  Tools  Forum
It is currently Sun Nov 10, 2024 8:38 am

All times are UTC




Post new topic Reply to topic  [ 430 posts ]  Go to page Previous  1 ... 7, 8, 9, 10, 11, 12, 13 ... 29  Next
Author Message
PostPosted: Wed Jan 30, 2019 2:00 am 
Offline

Joined: Fri Jan 25, 2019 5:40 am
Posts: 346
Location: Knoxville, TN
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)


Top
 Profile  
Reply with quote  
PostPosted: Wed Jan 30, 2019 4:44 pm 
Offline

Joined: Fri Jan 25, 2019 5:40 am
Posts: 346
Location: Knoxville, TN
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.


Top
 Profile  
Reply with quote  
PostPosted: Wed Jan 30, 2019 6:14 pm 
Offline

Joined: Mon May 21, 2018 8:09 pm
Posts: 1462
Yes, those are for other I/O devices. The 3-to-8 decoder is part of your address decoding circuitry.


Top
 Profile  
Reply with quote  
PostPosted: Thu Jan 31, 2019 12:44 am 
Offline

Joined: Fri Jan 25, 2019 5:40 am
Posts: 346
Location: Knoxville, TN
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)

Attachment:
rs232.PNG
rs232.PNG [ 124.15 KiB | Viewed 758 times ]


Top
 Profile  
Reply with quote  
PostPosted: Thu Jan 31, 2019 2:06 am 
Offline

Joined: Fri Jan 25, 2019 5:40 am
Posts: 346
Location: Knoxville, TN
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.


Top
 Profile  
Reply with quote  
PostPosted: Thu Jan 31, 2019 4:16 am 
Offline

Joined: Sat Dec 13, 2003 3:37 pm
Posts: 1004
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.


Top
 Profile  
Reply with quote  
PostPosted: Thu Jan 31, 2019 4:19 am 
Offline

Joined: Fri Jan 25, 2019 5:40 am
Posts: 346
Location: Knoxville, TN
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


Top
 Profile  
Reply with quote  
PostPosted: Thu Jan 31, 2019 6:23 am 
Online
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10975
Location: England
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.


Top
 Profile  
Reply with quote  
PostPosted: Thu Jan 31, 2019 2:15 pm 
Offline

Joined: Fri Jan 25, 2019 5:40 am
Posts: 346
Location: Knoxville, TN
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.


Top
 Profile  
Reply with quote  
PostPosted: Thu Jan 31, 2019 2:42 pm 
Offline

Joined: Fri Jan 25, 2019 5:40 am
Posts: 346
Location: Knoxville, TN
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?


Top
 Profile  
Reply with quote  
PostPosted: Thu Jan 31, 2019 2:58 pm 
Online
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10975
Location: England
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.)


Top
 Profile  
Reply with quote  
PostPosted: Thu Jan 31, 2019 3:12 pm 
Offline

Joined: Fri Jan 25, 2019 5:40 am
Posts: 346
Location: Knoxville, TN
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.


Top
 Profile  
Reply with quote  
PostPosted: Thu Jan 31, 2019 3:23 pm 
Offline

Joined: Fri Jan 25, 2019 5:40 am
Posts: 346
Location: Knoxville, TN
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)


Top
 Profile  
Reply with quote  
PostPosted: Thu Jan 31, 2019 3:36 pm 
Offline

Joined: Fri Jan 25, 2019 5:40 am
Posts: 346
Location: Knoxville, TN
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.


Top
 Profile  
Reply with quote  
PostPosted: Thu Jan 31, 2019 4:08 pm 
Offline

Joined: Fri Jan 25, 2019 5:40 am
Posts: 346
Location: Knoxville, TN
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


Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 430 posts ]  Go to page Previous  1 ... 7, 8, 9, 10, 11, 12, 13 ... 29  Next

All times are UTC


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to: