I'd suggest you look at the schematics for the Commodore dual disk drives. They use two 6502 (one in a smaller package, the 6504) with inverted clocks. The databus is actually connected directly. Only the address bus is switched between the two CPUs, and only for the shared memory chip(s).

As for the delay on falling phi2 - IIRC the time it takes to switch the busses and disable the memory is plenty for the 6502 to take the value from the bus. The hold time, IIRC is pretty low. The datasheets are your friend for this.

http://www.6502.org/users/andre/petinde ... index.html

André

_________________
Author of the GeckOS multitasking operating system, the usb65 stack, designer of the Micro-PET and many more 6502 content: http://6502.org/users/andre/

Thank you. I cannot say anything about older 6502's, I have only worked with and researched the W65C02S. The datasheet there says that addresses, data, /RW, SYNC, etc, all come online during the PHI2-low cycle. Perhaps older ones act differently?

As far as the falling edge timing, you are probably right. But I am a super nervous person apparently, and it didn't affect my Video memory access at all. I'm also grabbing output data on the bus on the falling edge of PHI2 as well, so a little extra time for that stuff is nice as well. Thank you for the suggestions.

Chad

André, thanks for the link!



This was the crucially missing concept from my mental model.

_________________
"The key is not to let the hardware sense any fear." - Radical Brad

just to kinda throw my 2 cents into this, but couldn't you use the BE pin by connecting it directly to the CPU Clock?
that way the CPU would release both the data and address bus (and RWB) while PHI2 is low without compromising the CPU's functionality.
but question is, how much of a delay is there between BE being asserted and the address/data busses being tri-stated?

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

The interesting thing is that when BE does go low, it tri-states the address and data buses. But does that mean it is likewise not *receiving* data? The falling edge of PHI2 is when data is read into the 6502, so would that even be affected by BE at all? Writing happens during the PHI2-high phase, not on the falling edge. Just more thoughts to ponder. Thanks!

Chad

An address decoding scheme:




I hope!

_________________
"The key is not to let the hardware sense any fear." - Radical Brad

Someone (one of the greats of this forum) once told me to program for the system first and see if you like it's layout. Because I made a simulator using C++, I was able to quickly turn out some code that proved to me that my memory map was something I actually wanted. What do you have in mind for this machine? What are visions for how programs will function? What projects do you think you would/could develop using this platform? Have you tried any prototypes using software yet?

Just something to think about. This step is always very important to me too. I personally like minimizing glue logic so sometimes where things fall is because I wanted to reduce chip count.

Why I/O in zero page? As of now I think 50+ people have viewed your picture, and yet nobody has yet asked? I have seen a *few* systems use something similar to this, but many others I have talked to (on this forum) hold the zero page as 'sacred' in some regard. I personally don't use it at all as I am far too 'secular' for touching such holiness, but hey, to each their own. My personal favorites for I/O space are $0200-$03FF or $7F00-$7FFF, depending on what other glue logic I already have on the board.

What do you plan on hooking up to the I/O space? Just one VIA? An ACIA? both? 2+ VIAs? [ "What's another VIA?" - Garth Wilson ]

By chance, which Dual Port RAM did you buy? Could I know a part number so I can go look it up myself? I'm interested.

Just some questions, not really for my sake, but for yours. These are the things I think of, so just passing them off to you too But if you'd like to answer, I'm interested to read and learn!

Good work!

Chad

using up half the ZP for IO is quite a lot. and the only real advantages you get from IO in ZP are being able to use the 65C02's bit instructions and ZP Addressing modes on IO. but the obvious disadvantage is that it takes some of the space that would otherwise be used to fast temporary varibles and pointers. so you need to decide for yourself what you think would be worth more.
faster IO Access and bit manipulation, or having more RAM in ZP for pointers and fast variables?

atleast you can be sure that CC65 would work fine since it doesn't use a lot of ZP anyways.


i don't know which chip Paganini is gonna use, but so far i've been using the IDT7005S55J, 8kB of DPRAM in a PLCC Package, 55ns access time (pretty slow but still usable for lower resolution VGA). it's pretty cheap too, at ~2.80 EUR per chip on Utsource https://www.utsource.net/de/itm/p/532049.html (ignore the datasheet they show, it's for the IDT7006 instead of the IDT7005)
speaking of which, they also have the IDT7006 (16kB) for around ~4.90 EUR https://www.utsource.net/de/itm/p/7707742.html
I'm honestly tempted to get a couple of those and make a PC-like VGA card with 64kB of VRAM so it can do 320x200 @ 256 colors or 640x400 @ 4 colors.

Yes, that's exactly right... and it's normal for the decision to vary according to the situation. (Different situations present different challenges and priorities.)

It's also worth mentioning that IO in Z-page results in smaller code. And faster, yes (especially in light of the bit-test, bit-set and bit-clear instructions), but also for bytewise read, write and R-M-W.

In some situations the speed boost won't matter at all, but in other cases it can make or break your ability to reach a goal (such as meeting a hard timing deadline to input a data stream from an external device).

Just a reminder that in some situations you don't necessarily need maximal Z-page space for pointers and variables. Much of that need can be eliminated by using a virtual stack. As Garth says in his Stacks Treatise, "The resulting easier stack operations reduce the number of variables needed along with [reducing] the risk of overwriting data that another pending routine expects to find still intact."

-- Jeff

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

Hi Chad!

At the moment dual-port RAM seems to be really expensive (like $10 - $15 per 1K!) or just plain unavailable from Digikey / Mouser. After trolling eBay for a few weeks I finally got lucky and found a guy selling a lot of 18 NOS CY7C144 35ns ICs. At least, I hope I got lucky! These seem perfect, except that they're PLCC68. I ordered a PLCC68 breadboard adapter, but it hasn't arrived yet, so I haven't been able to test them. The seller was a US-based amateur radio guy with 100% feedback, so I'm hopeful. Anyway, it worked out to about $2.34 per IC, shipped (shipping was high, the ask for the lot was low) which seems OK to me. I doubt I need 18 of them so if you'd like me to shoot a few of them your way I'd be happy to.

About I/O in Zero Page:

I/O in Zero Page is Very Old Voodoo. It's not the first time I came across the idea, but one of the Compute II articles I linked to earlier has a succinct description: Of course, as soon as I started googling the idea I found Jeff's very thorough treatment of the topic.

If you think about the 6502 as a kind of hybrid RISC architecture, 128 general purpose registers seems pretty roomy (compared to 32 registers in a regular RISC processor). OTOH, if you think of ZP as a kind of slow CPU cache for system variables and such, even the full 256 byte page isn't very much. I can't answer every one of your questions because I'm kind of evolving this system step-by-step; but I do prefer to think of ZP as a big register file, rather than a tiny area of fast RAM. I realize these are only logical distinctions, but if I start thinking about register files I start thinking about (for example) how I can see a way forward for making a library of 32-bit operations by combining R00-R03 / R04 - R07 / R08 - R0B into 32-bit registers; whereas if I start thinking about RAM, I start thinking about how my jump tables won't be able to hold very many XINU system calls (if I ever get that far!) if they have to fit into 256 bytes.

Another way of looking at it is, if I eventually get this to the point where it really can operate as a video terminal for Blue April, fast I/O could be really handy. I don't know if I will need it or not; but it seems easier to make space for it now than to try and add it later if I want it and haven't got it!

As far as how much I/O, two VIAs, one or two ACIAs (do I need a separate one for RX and TX? I don't know how they work, yet), a CRTC (maybe), and some space for future expansion. I'd like to add some mass storage, at some point, and maybe some bank-switching. I've always kind of liked the idea of the cyber-decks from Neuromancer where you configure your system software by jamming in a big row of ROMs a la the BCC "sideways expansion."

_________________
"The key is not to let the hardware sense any fear." - Radical Brad

On to the next phase! Power / ground network and clock signals hooked up:



This version with the CRTC needs a slightly different clock logic from the one with gfoot's timing ROM:



Unfortunately I don't have any 3-input NAND gates; but I do have some 3-input AND gate, so I rolled my own, and added some good old fashioned "double inversion" buffering to make up for the delay. It's OK if LOAD_P lags a little, but I don't want it to get too far behind.

_________________
"The key is not to let the hardware sense any fear." - Radical Brad

https://www.amazon.com/POW3U-PowerBoard-3U-Power-Rails-Sided/dp/B0040Z6OYC/

I've been eyeing these BusBoard prototype boards for a while now, but I've held off ordering because I thought they were kind of expensive for just one. But, since the breadboard build I posted earlier this afternoon will probably be the last iteration before I switch to something more permanent (and after seeing the prices for similar boards from Europe - oof!) I went ahead and bit the button (as it were) earlier this week.

I dunno if I'm the lucky beneficiary of a warehouse mistake, or if the Amazon listing is just unclear, but my package just arrived, and it has poly bag of *10* PCBs. I'm pretty happy about this. I was worried about making soldering mistakes and messing up my single precious $12 board. Now I have plenty of wiggle room, and with more boards I have extra space to make something like Daryl Rictor's "book fold" SBC4.

_________________
"The key is not to let the hardware sense any fear." - Radical Brad

Sorry for the slow reply, but I like the look of this.

In particular, you've run several north-south power/gnd connections (the black, and the red & black) to complement the east-west rails within the central breadboards. The result is a grid, which offers various opportunities for return current to flow in whichever path(s) it wants. For any given signal current from Point A to Point B, the grid offers a reasonably proximate (albeit zigzagging) return path from Point B back to Point A... and that's what the return current wants. As much as possible, the return current wants to follow the same path as the signal current (because to do otherwise means a larger loop area and hence a larger inductance that needs to be charged up with magnetic field). It's "easier" for the return current to choose path(s) that don't require putting energy into a field.

The grid you've created is rather coarse, with only three north-south paths. (The ideal would be an X-Y grid so fine it's actually a plane.) But make no mistake, three paths is enormously better than what we often see on this forum, and that's a breadboard project with only one path perpendicular to the breadboard rails. In such a case there might be a few signals that enjoy a proximate return path, but the majority of the signals won't be so lucky. (It's not as much of a problem with older, slower chips such as NMOS '02s, but modern WDC CPUs have very abrupt transitions on their outputs, as do many modern RAMs. This is true even when running at low clock rates such as 1 or 2 MHz.)

Although I didn't highlight them, I see you've gone one step further and actually used twisted pairs (orange & white) to ensure that certain lines have an even more proximate return path. I assume the twisted pairs are for clock signals, and I'm glad to see that the twisted ground conductor attaches to local ground at both ends. (A wire that connects to ground at only one end does have a certain electrostatic shielding effect, but that's not especially helpful; what we need is for the return path to be a return path, and that means passing current from one end to the other.)

-- Jeff

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

Thanks Jeff! It is thanks to you and Garth that I know what to do at all! And it *does* work! Although I made an error (either conceptual or wiring, not sure which yet) somewhere in the final board so that the I/O isn't working, I can see on my scope that the CPU is waking up and driving the buses with nice clean signals.



Although it doesn't show in that "work in progress" photo, I carried on with the general procedure of connecting every IC's ground pin to both its flanking ground rails, just like the ones you've highlighted. Since the ICs tend to be arranged in columns, more or less, this results in a more grid-like return network. In particular, I added several more ICs for decoding logic, and I hooked up the RAM and ROM that are (in that photo) just hanging out down at the bottom of the picture not connected to anything.



Yes; I carried on using quite a few twisted pairs: for the clock signal, and for any control signal that had to go more than about 4 inches or so. One thing I tried to do for the wiring subsequent to that photo is that I ran the wires in "routing channels" along the bus bars rather than in "domes" over the ICs. This makes the wires longer than strictly necessary, but I was trying to get the signal / return paths close to each other as you just mentioned. I noticed that Radical Brad did this quite a lot in "Vulcan 74," and his signals travel much further than mine, without using twisted pairs. (Of course, he uses a lot of buffering too.) The best I could, I tried to connect the twisted pair grounds to the actual ground pins of the ICs connected by the signal wire they were accompanying, rather than just to some convenient location on the ground rails. I had to make some compromises though; with all these connections the ground rails and ground pins got pretty crowded!

_________________
"The key is not to let the hardware sense any fear." - Radical Brad