6502.org Forum  Projects  Code  Documents  Tools  Forum
It is currently Sun Nov 24, 2024 7:25 am

All times are UTC




Post new topic Reply to topic  [ 32 posts ]  Go to page 1, 2, 3  Next
Author Message
PostPosted: Thu May 26, 2022 10:07 pm 
Offline

Joined: Tue May 24, 2022 12:15 pm
Posts: 14
Location: Oslo/Norway
Hi all,

A few years ago I tinkered with building various 8088 computers, some were SBC's, some were stacks of PC/104-connected boards.
This time, I thought I'd give the 65C816 a shot. Would be fun to get a hardware project going again, plus I'd love to get into 65xxx assembly and try to build the ROM more or less from scratch.

I've attached a pdf of the schematics and I'd really appreciate it if I could get some feedback! Good/bad design, dumb decisions, anything goes! :)

Some design considerations:
- ROM is 12KB, starting from 0x0D000 - but the whole chip is also mapped in its entirety up in 0x80000. This is in order to be able to try my luck with flashing it from a running system. The SST39SF0x0 uses various command sequences for erasing/writing which requires addresses that would otherwise collide with RAM/IO.
- VIA to drive a simple square wave "pc speaker" + bit bang an SD card module over SPI
- The ATF22V10C uses CLK to qualify /WR, (VDA|VPA) to qualify /UARTCS and /VIACS
- 74AHCT logic
- I would start with a 2 MHz oscillator (1 MHz CLK) and work my way up from there

What I'm most unsure about is the 24-bit addressing demultiplexing, timing, and whether I need to qualify any additional signals (for instance, should VDA|VPA be used for qualifying /RD and /WR in general?).

Again, any input would be greatly appreciated!

PS. The name of this project is "Vic-65" for now. Kinda lame, but I thought it would be fun to use Vic, because of the obvious reference to the VIC-20 but also the fact that I'm actually working for a company called Vic.ai.


Attachments:
vic-65_05-26-2022.pdf [402.37 KiB]
Downloaded 78 times
Top
 Profile  
Reply with quote  
PostPosted: Fri May 27, 2022 1:50 am 
Offline

Joined: Sat Dec 30, 2017 3:19 pm
Posts: 116
Location: Detroit, Michigan, USA
Welcome! It's really nice to see another 65816 build.. :)

eivind wrote:
The ATF22V10C uses CLK to qualify /WR, (VDA|VPA) to qualify /UARTCS and /VIACS


The clock should qualify both /RD and /WR. The /UARTCS and /VIACS are good as you have them though.

Quote:
What I'm most unsure about is the 24-bit addressing demultiplexing, timing, and whether I need to qualify any additional signals (for instance, should VDA|VPA be used for qualifying /RD and /WR in general?).


What is your concern about the timing on the bank address?

/RD and /WR should not be qualified with VPA or VDA; they are normally only part of chip select logic, which you've already done.

Another couple random thoughts:

1.Your I/O ranges are awfully big, though I understand it uses less logic to decode fewer bits. Generally I make my I/O ranges 32 bytes, which is already twice as big as the register window of your VIA or UART.
2. The pulldown resistors on your data bus are likely not necessary and are just going to increase the current needed to pull lines high.

Quote:
PS. The name of this project is "Vic-65" for now. Kinda lame, but I thought it would be fun to use Vic, because of the obvious reference to the VIC-20 but also the fact that I'm actually working for a company called Vic.ai.


I like it!


Top
 Profile  
Reply with quote  
PostPosted: Fri May 27, 2022 2:57 am 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8514
Location: Midwestern USA
eivind wrote:
This time, I thought I'd give the 65C816 a shot.

Welcome to the 65C816 club!

Some thoughts on your design:

  1. I’d keep RN1. However, its common connection should be to VCC, not ground. RN1 will prevent the data bus from floating when the bus transceiver is in the high-Z state, which condition could theoretically inject noise into the system. With RN1's common at VCC instead of ground, devices with TTL outputs, e.g., the SRAM, will have less work to do in getting the data bus up to a solid logic one. TTL outputs are generally able to pull down harder than up, so the resistor will add negligible burden.

  2. I recommend you place a 100 µF low-ESR electrolytic in parallel with C19. Both capacitors should be as physically close to the MAX238’s VCC pin for best operation. It’s best to keep the traces between the charge pump caps and the MAX238 as short as possible.

  3. R6 and R7 could be combined into a single four-pin, non-bused resistor network to save some space. The 33 ohm values are probably too low. I use around 120 in my units.

  4. R1, R2 and R3 could be in a four-pin, bused resistor network, again to save some space.

  5. R16 is unnecessary. Instead, connect the DUART’s X1 clock input (pin 36) to VCC through a 470 ohm resistor, per the NXP data sheet.

  6. VDA and VPA should not be used to qualify /RD or /WD. Those outputs are meant for qualifying chip selects so as to avoid problems that may be caused by undefined address bus conditions during some cycles of some instructions.

  7. You’ve got SPKR connected to the 65C22 and to the DUART. Is that intentional? If possible, outputs OP4-7 of the DUART should be reserved for future use. I use them in my designs as channel-specific IRQ outputs to improve the performance of the data I/O parts of my interrupt handler.

So when do you plan to build it?

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!


Top
 Profile  
Reply with quote  
PostPosted: Fri May 27, 2022 4:11 am 
Offline
User avatar

Joined: Fri Dec 11, 2009 3:50 pm
Posts: 3367
Location: Ontario, Canada
jmthompson wrote:
Welcome! It's really nice to see another 65816 build.. :)
Yes indeed -- I'll second that wholeheartedly! :)

jmthompson wrote:
/RD and /WR should not be qualified with VPA or VDA; they are normally only part of chip select logic, which you've already done.
Uh... okay, on this point I'm a little more cautious.

I do agree it can sometimes be useful to qualify chip select logic using VDA and VPA. The goal is to prevent any devices from being accessed by the invalid address that's present during a so-called "dead cycle."

But think about it. If a device has /RD and /WR inputs then withholding /RD and /WR will very definitely prevent any access. (Duh.) Or, you can prevent access by withholding Chip Select. Same result. My point is that both methods render access 100% impossible. This means the designer has freedom to choose one method or the other, according to preference and circumstances.

IOW, it can sometimes be useful to qualify chip select logic using VDA and VPA. Or, alternatively, it can sometimes be useful to qualify /RD and /WR using VDA and VPA. Neither is wrong. (But it would perhaps be a waste of resources to do both.) I hope I've been clear on this point regarding /RD and /WR.


Shifting the focus somewhat, and at the risk of straining folks' attention span, I'll touch briefly on another point. Our concern pertains to the invalid address that's present during a so-called dead cycle... and it's worth remembering that some devices don't need protection from invalid accesses. Many I/O devices do, but the overwhelming majority of memory devices do not. (This can be determined.) And, for reasons I won't explain here, it turns out that omitting protection for memory devices means VPA can be ignored. This is quite significant, as it grants some design freedom.

I refer interested readers to this post and the one that follows it. They explain how a canny designer can usually arrange to ignore VPA altogether and use VDA only, resulting in faster, simpler glue logic.

-- Jeff

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html


Top
 Profile  
Reply with quote  
PostPosted: Fri May 27, 2022 7:34 am 
Offline

Joined: Tue May 24, 2022 12:15 pm
Posts: 14
Location: Oslo/Norway
Thanks for the warm welcome, guys! :D So nice to see such an active retro forum as this, can't believe I didn't look into 65xx before - guess I was just so fascinated by x86 since that's what I grew up with in the mid-80's.

jmthompson wrote:
What is your concern about the timing on the bank address?

Not the bank address specifically, just everything in general. I was kind of intimidated by watching Adrien Kohlbecker's youtube videos going into details about timing requirements.

jmthompson wrote:
Your I/O ranges are awfully big, though I understand it uses less logic to decode fewer bits. Generally I make my I/O ranges 32 bytes, which is already twice as big as the register window of your VIA or UART.

Yeah I know they're wastefully big ranges. As you say, it's for saving decode bits. I'd like to keep all of that stuff in the 22v10 if possible, and I'd only save 2-3 KB if using one or two extra address lines anyway.
Edit: Did my math wrong, I'd be saving 4-6 KB, maybe worth looking into actually!
Edit2: Yep, that compiled just fine in WinCupl. Had to remove VPA, but as I understand it, that will still be perfectly adequate, using only VDA for IO qualifying.

jmthompson wrote:
The clock should qualify both /RD and /WR.

Yep, I've changed the PLD code to include CLK qualifying the /RD as well, thanks!

BigDumbDinosaur wrote:
I’d keep RN1. However, its common connection should be to VCC, not ground. RN1 will prevent the data bus from floating when the bus transceiver is in the high-Z state, which condition could theoretically inject noise into the system. With RN1's common at VCC instead of ground, devices with TTL outputs, e.g., the SRAM, will have less work to do in getting the data bus up to a solid logic one. TTL outputs are generally able to pull down harder than up, so the resistor will add negligible burden.

That's interesting, I'll definitely make that change! As for pull-up strength, would it make sense to raise the R a bit? Isn't 1k a bit low as far as pull-ups goes for an application such as this...?

BigDumbDinosaur wrote:
I recommend you place a 100 µF low-ESR electrolytic in parallel with C19. Both capacitors should be as physically close to the MAX238’s VCC pin for best operation. It’s best to keep the traces between the charge pump caps and the MAX238 as short as possible.

Good idea!

BigDumbDinosaur wrote:
R16 is unnecessary. Instead, connect the DUART’s X1 clock input (pin 36) to VCC through a 470 ohm resistor, per the NXP data sheet.

Ah yeah, I missed that from the datasheet, thanks!

BigDumbDinosaur wrote:
You’ve got SPKR connected to the 65C22 and to the DUART. Is that intentional?

It is most definitely not! :shock: I have no idea how that got in there! Should only be connected to the 65C22.

BigDumbDinosaur wrote:
If possible, outputs OP4-7 of the DUART should be reserved for future use. I use them in my designs as channel-specific IRQ outputs to improve the performance of the data I/O parts of my interrupt handler.

Care to explain this a bit further? How would these channel-specific IRQ's be read by the '816 with its single IRQ input?

BigDumbDinosaur wrote:
So when do you plan to build it?

As soon as possible! :D Need to order most of the parts and do the PCB layout, then I'll get it made by JLC (whom I've used lots of time in the past with great success).
Very reassuring to have y'all give me the thumbs-up first! ;)

I've updated the schematic, will replace some of the resistors with networks if needed for space later.


Attachments:
vic-65_05-27-2022.pdf [404.82 KiB]
Downloaded 57 times
Top
 Profile  
Reply with quote  
PostPosted: Fri May 27, 2022 3:41 pm 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8514
Location: Midwestern USA
eivind wrote:
BigDumbDinosaur wrote:
If possible, outputs OP4-7 of the DUART should be reserved for future use. I use them in my designs as channel-specific IRQ outputs to improve the performance of the data I/O parts of my interrupt handler.

Care to explain this a bit further? How would these channel-specific IRQ's be read by the '816 with its single IRQ input?

What I did in my POC V1.2 and V1.3 units, both of which have two DUARTs, was connect OP4-7 of each DUART to the inputs of a 74ACT540 inverting bus driver, and assigned the ACT540 a spot in the I/O memory map. When the 816 processes an IRQ and gets to the part that processes serial I/O, it reads from the ACT540, which returns a bit pattern according to which channel(s) is(are) interrupting. A set bit means the channel is interrupting, otherwise it is quiescent. The ACT540’s inputs are pulled up to VCC, since OP4-7 are open-drain when configured to mirror channel IRQs.

I've got the circuit rigged up so the RxD IRQs are bits 0-3 and the TxD bits are 4-7. Channel A’s RxD IRQ appears as bit 0 and the channel’s TxD IRQ appearing as bit 7. This arrangement makes it possible to use logical shifts on a single byte value within a loop to determine which channels need processing, instead of having to read and mask each channel’s status register to see if it is interrupting. See the attachments for the circuit and the IRQ code. In particular, the code illustrates how to fully utilize the DUARTs’ channel FIFOs for maximum throughput per IRQ serviced.

Attachment:
File comment: POC V1.3 Serial I/O Circuit
SIO.pdf [49.98 KiB]
Downloaded 45 times
Attachment:
File comment: POC V1.3 IRQ Handler
pocv13_irq.txt [13.99 KiB]
Downloaded 48 times

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!


Top
 Profile  
Reply with quote  
PostPosted: Fri May 27, 2022 4:51 pm 
Offline

Joined: Tue May 24, 2022 12:15 pm
Posts: 14
Location: Oslo/Norway
Thanks, BDD! That is indeed several clever pieces rolled into one package! :) I must say, I also found your 28L92 interface- and driver documents very helpful!
What about the data bus pull up resistor values, would you go with 1k or higher? Do you use this in your POC V1.3 at all?


Top
 Profile  
Reply with quote  
PostPosted: Sat May 28, 2022 8:06 am 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8514
Location: Midwestern USA
eivind wrote:
What about the data bus pull up resistor values, would you go with 1k or higher? Do you use this in your POC V1.3 at all?

3.3K should be good.

V1.3 doesn’t have the data bus pullups, but V2.0 does. It wasn’t necessary with 1.3 because it doesn’t have a data bus transceiver. 2.0 does.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!


Top
 Profile  
Reply with quote  
PostPosted: Sat May 28, 2022 9:02 am 
Offline

Joined: Tue May 24, 2022 12:15 pm
Posts: 14
Location: Oslo/Norway
BigDumbDinosaur wrote:
3.3K should be good.

Great, thanks!

I didn't originally think so, but it looks like I'll be able to cram everything onto a 100x100mm 4-layer board - that'll reduce the JLC production price drastically to only $8 for 5 boards! 8)


Top
 Profile  
Reply with quote  
PostPosted: Sun May 29, 2022 1:20 am 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8514
Location: Midwestern USA
eivind wrote:
BigDumbDinosaur wrote:
3.3K should be good.

Great, thanks!

I didn't originally think so, but it looks like I'll be able to cram everything onto a 100x100mm 4-layer board - that'll reduce the JLC production price drastically to only $8 for 5 boards! 8)

I can remember when five PCBs of that size cost 400 bucks, and that was for two layers.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!


Top
 Profile  
Reply with quote  
PostPosted: Sun May 29, 2022 12:38 pm 
Offline

Joined: Tue May 24, 2022 12:15 pm
Posts: 14
Location: Oslo/Norway
Getting there...


Attachments:
Vic-65-rendered.jpg
Vic-65-rendered.jpg [ 578.88 KiB | Viewed 1296 times ]
Top
 Profile  
Reply with quote  
PostPosted: Mon May 30, 2022 7:54 am 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8514
Location: Midwestern USA
eivind wrote:
Getting there...

Looks pretty good—nice, compact layout. Have you routed the traces yet?

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!


Top
 Profile  
Reply with quote  
PostPosted: Mon May 30, 2022 10:53 am 
Offline

Joined: Tue May 24, 2022 12:15 pm
Posts: 14
Location: Oslo/Norway
BigDumbDinosaur wrote:
Looks pretty good—nice, compact layout. Have you routed the traces yet?

I have - boards are in production and parts are ordered! 8)


Top
 Profile  
Reply with quote  
PostPosted: Fri Jun 10, 2022 10:53 am 
Offline

Joined: Tue May 24, 2022 12:15 pm
Posts: 14
Location: Oslo/Norway
Finally got the boards in, and assembled one. Still waiting for a couple of the IC's in the mail, but looking good so far.
One thing I didn't know about was that most (all?) USB-C connectors apparently are made for 0.8mm PCB's - that made soldering a bit of a challenge.
Also, I totally forgot about USB-C requiring a power-delivery negotiation. In the simplest form, the two CC pins should be tied to GND through 5.1k resistors. I'll get around this for now by using a "dumb" power source that doesn't care about these things, but something to keep in mind for another revision.


Attachments:
Vic-65-assembled.jpg
Vic-65-assembled.jpg [ 2.95 MiB | Viewed 1191 times ]
Top
 Profile  
Reply with quote  
PostPosted: Fri Jun 10, 2022 8:05 pm 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8514
Location: Midwestern USA
eivind wrote:
Finally got the boards in, and assembled one.

Board looks good. Nice and dense.

Is there a bypass capacitor on both sides of the 65C816's socket? Can't tell in the photo.

Quote:
One thing I didn't know about was that most (all?) USB-C connectors apparently are made for 0.8mm PCB's - that made soldering a bit of a challenge.

I’ve never been able to figure out how a standard that has eight or nine different and incompatible connectors can call itself “universal.” :D

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!


Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 32 posts ]  Go to page 1, 2, 3  Next

All times are UTC


Who is online

Users browsing this forum: No registered users and 52 guests


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: