Potential way to get rid of one 6522 VIA chip and save the board cost

tepigu

New Member
Dec 2, 2019
1
0
1
Hello, I've been following The 8-bit Guy for quite a big while now. Recently I was reminded of this project and took a look at the current design.

before.png

According to the current prototype board and emulator implementations, there are currently two 6522 chips in use and not all ports and timers are fully utilized as seen from the above picture. Which might be the artifact from starting with a working VIC-20 board and modifying it from there. I noticed that there is a way to completely remove one of them while retaining all of the used ports intact, resulting in a cheaper board while having way more features for the software.

Just use a 65816 CPU like originally intended.

after.png

From my recent searches in Mouser, turned out that all the 65xx chips I mentioned earlier are at the same price of $6 (yes, free 16-bit upgrade), while all of the 74xx chips required to demux the data/bank lines combined cost less than a dollar. Also, 65816 memory banking can be fully done even in emulation mode.

Thanks for reading this proposal, I hope that this will be considered for future usage in the Commander X16 project without causing more issues. Also, I can provide help for implementing these changes in the emulator and ROM if you want (I have a GitHub account which I can provide if you are interested, and I have experience in writing demos for 6502-based systems before).
 
  • Wow
Reactions: codewar65

BruceMcF

Active Member
May 19, 2019
150
49
28
But they are not gambling on whether or not there is going to be data contention in the 65816 bus cycle ... they are going to try it and see if it works after they have a working board with the 65c02. So a design that requires the 65816 as opposed to one that might optionally have the 65816 replace the 65c02 is not going to be contemplated.
 
Last edited:
  • Like
Reactions: grommile and Panda

GregZone

Member
Sep 29, 2019
34
24
8
So, you're basically just adding the Address / Data bus demuxing required for a fully implemented 24bit Address bus 65C816 system.

This overlooks the current 64K memory map design, which also means you are missing a 2nd latch (or port) for the ROM bank switching (ie. ROMB0, ROMB1, ROMB2?).

It has already been stated that the memory map is now locked in.

Personally I would just stick with the flexibility of the 2nd 65C22. :)
 
  • Like
Reactions: BruceMcF

BruceMcF

Active Member
May 19, 2019
150
49
28
So, you're basically just adding the Address / Data bus demuxing required for a fully implemented 24bit Address bus 65C816 system.

This overlooks the current 64K memory map design, which also means you are missing a 2nd latch (or port) for the ROM bank switching (ie. ROMB0, ROMB1, ROMB2?).
It's also failing to implement RAM bank, which needs to be able to be both written and read and which only affects the data read for addresses $A000-$BFFF.

In other words, it is, indeed, a way to implement the CX16 memory map which doesn't actually implement the CX16 memory map.

It's not really a cost saving for the design if it fails to implement the design.