65c816 "Core"

[BigDumbDinosaur]

barrym95838 wrote:

I just did a brief search and found the 28LV010 which appears to have a DIP version ... is this not available or not applicable for some reason?
[Edit: might be for aerospace use, so rare and expensive?]

It's a radiation-hardened part. Digi-Key says the DIP version is obsolete, and they have no stock.

As for the price...ouch!

[floobydust]

GamerFox wrote:

I am a little bit angry right now. It seems like there are no DIP EPROM or EEPROMs that work on 3.3V, meaning I might have to jack up the main rail to 5V or add a PLCC32 socket for one of Atmel's 3.3V offerings (the OTP EPROM and the EEPROM are not pin compatible in PLCC32).

Arrow Electronics has the AT28BV256 EEPROM in SOIC in stock. It's the same pinout as the DIP version and Proto-Advantage has an adapter to convert to 28-pin DIP. I'm using this setup in my 3.3V prototype project. It's a 200ns part, and I'm running it at 4 MHz.

[GamerFox]

Here is some more progress.

[BigDumbDinosaur]

GamerFox wrote:

Here is some more progress.

I see 74HC parts in there running on 3.3 volts. That's going to be slow. I recommend 74LVC parts, which are substantially faster on 3.3 volts.

Also, what's with all those gates connected to the bank bits latch? You're only using A16-A18, so why make it so complicated and, as well, throw in tons of logic delays? You can achieve what you want with a 74AC563 (which runs fine on 3.3 volts, with only a small degradation in performance) and a 74LVC11. The 563 is the inverting version of the 573 latch, meaning its outputs are /Q instead of Q. The LVC11 is a triple-input AND.

You'd connect the 563's D inputs the same as the corresponding 573 D inputs, and connect the /Q outputs to the LVC11. If the bank is $00 and only if it is $00, the LVC11's output will be high.

On the CPLD, you've got GCLK1 connected to reset. Why? The GCLR input is there for that purpose. Also, what's the plan with IRQ being connected to the CPLD?

[GamerFox]

BigDumbDinosaur wrote:

GamerFox wrote:

Here is some more progress.

On the CPLD, you've got GCLK1 connected to reset. Why? The GCLR input is there for that purpose. Also, what's the plan with IRQ being connected to the CPLD?

That's the way the pinout is on Darryl Rictor's 65SPI project (https://sbc.rictor.org/65spi2.html). I don't know of any other way to convert from 8-bit parallel to SPI, since it seems all the SPI/parallel interfaces on the market are designed to be SPI peripherals and not hosts?

(of course, another solution is to bit-bang the FRAM with one of the 6522s and to have the display be a parallel device, but that eliminates the SD card possibity...)

[GARTHWILSON]

GamerFox wrote:

(of course, another solution is to bit-bang the FRAM with one of the 6522s and to have the display be a parallel device, but that eliminates the SD card possibility...)

Why would it eliminate it?

[GamerFox]

Oh yeah, I wasn't thinking clearly, that would only require an additional select line wouldn't it?

[GamerFox]

Here's the latest draft, including the 65C22s. I'm using port A of VIA 1 solely for SPI applications. I'm thinking of having SPI2 be 5V, and maybe putting a PS/2 connector and/or a simple 7-button keypad on 1-B. I'd use a TXB0104 to handle the shifting between 3V3 and 5V but what should I link the OE line on that to?

[kernelthread]

It seems a bit of a waste to have a 128K RAM chip on there and only use 48K of it. Is there any way you could make top 64K appear in bank 1?

[BigDumbDinosaur]

GamerFox wrote:

Here's the latest draft, including the 65C22s. I'm using port A of VIA 1 solely for SPI applications. I'm thinking of having SPI2 be 5V, and maybe putting a PS/2 connector and/or a simple 7-button keypad on 1-B. I'd use a TXB0104 to handle the shifting between 3V3 and 5V but what should I link the OE line on that to?

You misunderstood my earlier post. The 563 is for generating a set of inverted bank bits for use by the glue logic. You still need the 573 to generate the bank bits that connect to A16-A18 of the SRAM. As you have it right now, the A16-A18 signal seen by the SRAM is "upside down."

[BigDumbDinosaur]

kernelthread wrote:

It seems a bit of a waste to have a 128K RAM chip on there and only use 48K of it. Is there any way you could make top 64K appear in bank 1?

He's got a bank latch in there wired to A16-A18 on the SRAM, which covers the full extent of the SRAM. However, see my above post.

[kernelthread]

There are two RAM chips in the schematic - a 128Kx8 used to cover the area from 0x000000 to 0x00BFFF, and a 512Kx8 used to cover the area from 0x010000 to 0x07FFFF. You could ditch the 128Kx8 chip entirely and use the 512Kx8 one to cover both areas. This would save a 32 pin DIP package and quite a lot of board area.
Also, the fact that the A16-A18 supplied to the RAM are inverted isn't necessarily an issue provided that the CPU is the only bus master in the system (which seems to be the case). It could, of course, be a bit confusing if you try to probe the system with a logic analyser.

[GamerFox]

kernelthread wrote:

There are two RAM chips in the schematic - a 128Kx8 used to cover the area from 0x000000 to 0x00BFFF, and a 512Kx8 used to cover the area from 0x010000 to 0x07FFFF. You could ditch the 128Kx8 chip entirely and use the 512Kx8 one to cover both areas. This would save a 32 pin DIP package and quite a lot of board area.
Also, the fact that the A16-A18 supplied to the RAM are inverted isn't necessarily an issue provided that the CPU is the only bus master in the system (which seems to be the case). It could, of course, be a bit confusing if you try to probe the system with a logic analyser.

He's right -- by doing some logic rerouting, I was able to eliminate the 128K and use the 512K to cover all of the RAM area.

If I do make a design that requires DMA, then I'll put a '573 in parallel with the '563 for memory logic.

65816-comp.pdf

(220.51 KiB) Downloaded 75 times

e: Actually, wouldn't replacing U102 with a '573 and U201 with a 74LVC27 fix the problem too?

[GamerFox]

Latest update! Added FRAM and the SD card sheet.

Now, some questions I have (besides the usual "is everything correct" one):

• I want to hook up a 7-button keypad, preferably on 1-B. How would I go about doing that?
• Should I add RS-232 capability, and if so, can I use a Maxim 3111E on the SPI bus?
• This web page about using SD in SPI mode says that initialization requires 74 clock pulses to the SD card's CLK pin at between 100 and 400 kHz. How would I go about setting this up?
• What RTC should I probably be looking at?

errata: SW102 is meant to have the label "NMI"

[drogon]

GamerFox wrote:

Latest update! Added FRAM and the SD card sheet.

Now, some questions I have (besides the usual "is everything correct" one):

• I want to hook up a 7-button keypad, preferably on 1-B. How would I go about doing that?
• Should I add RS-232 capability, and if so, can I use a Maxim 3111E on the SPI bus?
• This web page about using SD in SPI mode says that initialization requires 74 clock pulses to the SD card's CLK pin at between 100 and 400 kHz. How would I go about setting this up?
• What RTC should I probably be looking at?

errata: SW102 is meant to have the label "NMI"

You have 7 pins free on VIA1 - Port B, so that's easily a 2 x 4 matrix to give up to 8 buttons leaving one IO free...

So - draw 4 lines vertically, and 2 horizontally and at the intersections put a switch - then to read you turn each of the 2 row pin on in turn and sample the 4 row pins and decode the result... You'll need to take care of debounce, but that's fairly easy in software so no need to bother with extra hardware for that.

For the SD card - well, when in doubt, use brute force[1], so a software loop to toggle the clock pin the right number of times with a delay (poke a value onto T1 and wait until it reaches zero). then carry on. My '816 board also uses SD, but it's all done from the ATmega side, however the principle is the same for the setup - I simply set the speed slow, then send 10 bytes of 0xFF, so 80 bits rather than the 74, but the 74 is a minimum, so it works well.

As for the "should serial" question - only you can really answer that. I'd say 'yes' then it gives you the ability to use e.g. xmodem to get data to/from the SD card without going through the cycle of power off, move SD card, read/write, power up, etc. ...

RTC - Use the one that's easiest to write code for.... And if you have a working SPI bus then maybe one with an SPI interface would be a good start?

-Gordon
[1] Ken Thompson