What I'd more rather see is /SYNC on pin 19, matching up with RC2014's similar /M1 signal, and then /IO0 on pin 26, where /SYNC was, matching up with RC2014's /IORQ signal, becuase that would be a very satisfying symmetry (and make bus conversion boards marginally easier to build). For existing stuff that seems to affect just CPU boards (another cut and jumper) and the Debug board (also just a two cut-and-jumper) and any similar boards anybody's built. So which is more advantageous: more sensible bus or mods to probably rare boards plus a second mod to each CPU board that's already been modded anyway?

I don't really have a good answer to that question, so I'd love to hear others' thoughts!

_________________
Curt J. Sampson - github.com/0cjs

It may be informative to list existing RC6502 and RC6502-like boards and see how the proposed bus assignments can be adjusted to fit these boards. We can also brainstorm on future designs and how the proposed bus can help or hinder future designs.
Bill

Yes, that is my plan. I've already done some of the work for this in the RC6502 Bus document where for each signal I list all the boards (from that repo) that use it and how they use it.


Yes please!

_________________
Curt J. Sampson - github.com/0cjs

My initial thought is that SYNC is a signal that probably follows the "should just be twisted pair jumped" rule.

/IOEN or /IO0 on Pin 26 decoding at minimum 256 bytes would sound reasonable to me on first suggestion.

I look forward to what you compile about existing boards.



My vote would be a more sensible bus at the sake of having to mod the few existing boards (if folks really want to interoperate). It would certainly easy to design a "reference" bus converter card that's just tall enough to also have a jumper or two, and e.g. if we remove SYNC from the bus, a twisted pair header dedicated for SYNC.

_________________
https://github.com/Individual-Solid/

I believe that SYNC is needed for DMA in at least some circumstances (maybe most that involve halting the CPU). A 6502 won't halt during a write cycle but will instead first complete the write. So, if I'm rembering correctly, peripherals like the Commodore 64 REU would wait for a SYNC, assert the halt line, and then wait a certain number of cycles to allow the CPU to complete any possible write cycles before taking the CPU off the bus.

_________________
Curt J. Sampson - github.com/0cjs

This picture shows my collection of PC boards that work with a RC6502-like bus. My version of RC6502 bus is defined here; of interest to our current discussion, the clock is on pin 21, external select is on pin 26, and pins 35-40 are not defined. The single-board 65C02 and VGA-PS2_keyboard boards (bottom right and top right, respectively) are designed specifically for the RC6502-like bus. The quad serial board (middle right) is designed for RC2014 or RC6502 buses depending on jumper selections. The 3 boards on the right form a standalone 6502 computer with its own mass storage, VGA interface, keyboard, I2C, console I/O, and four high-performance serial channels. the LED display board and prototype board on the left were designed for RC2014 bus because they use CPLD for decoding, they can be reprogrammed for RC6502. The backplane to host these board is an official 5-slot RC2014 backplane. The SBC 6502 by itself can be coverclocked to 29.5MHz, but I expect it to run slower when it is plugged into the backplane driving other boards. Currently the 4-board system is running at 14.7MHz; I have not try to find its upper frequency limit yet.
Bill

If you restrict DMA to CMOS variants, these DO halt on writes when RDY gets asserted. May be easier than defining extra logic to count/detect writes during RDY.

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/

Oh, that's good to know! Though when building things like clones of '70s and '80s microcomputers, you may be required to use NMOS unless you're willing to be somewhat incompatible.

_________________
Curt J. Sampson - github.com/0cjs

The question just then is if these clones need to have that DMA. Having RDY on the bus gives you both options, clone without DMA or CMOS with DMA.

Besides I think SYNC is not needed for DMA, just wait three cycles after assigning RDY like the VIC-II. Using SYNC to find a cycle for halting the CPU may be treacherous. IIRC you can have SYNC but the next cycle can be a write, if IRQ or NMI was triggered.

I really used SYNC only to single step, which would probably be on the CPU board anyway, or for a No-Execute trap which is probably way too complicated for such a system.

So I'd vote for not having SYNC on the bus.

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/

The the Commodore 64 is both NMOS and uses SYNC on the expansion bus for DMA, IIRC.

It's also needed for peripherals such as various kinds of debug boards, arrangements like KimKlone, and so on. It seems really a useful signal (though perhaps not for you), so while I'm willing to put it on the list of "we could consider moving this off the bus if we run out of pins," I don't really think it belongs in the "so obviously useless on a bus that we should just dump it now" category.


Actually, single-step/debugging/etc. seems to me a classic use for a separate board, since it's something you might well not use on a regular basis and thus not want to devote space to it on every CPU board (including SBCs) you build.

Edit: BDD just posted an opinion that one should stop the CPU only when SYNC is asserted. This reminds me that I think back when I was looking at how the C64 REU works I also thought, "why can't one just assert RDY or /HALT any time and just wait at least three cycles?" I don't recall the answer I got to this, if I ever even got one. But going back and looking at the C64, the 6510 has no SYNC pin, so obviously that wasn't being used for anything DMA-related or otherwise.

_________________
Curt J. Sampson - github.com/0cjs

Thanks for mentioning Kimklone (aka the KK Computer), Curt. For newcomers and others interested in a 'C02 upgraded with 6 new registers and 44 new instructions there's a one-page overview here. And it's Old School. (I built the KK Computer in 1988.)

Yes, and even comparatively simple schemes can use SYNC to powerful advantage. For example, here is a fairly trivial circuit for an output port that requires merely one clock cycle per operation. Single-instruction debugging is another imporant use for SYNC.

-- Jeff

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

Is there any update on the specs available? I don't see the /IOSEL line discussed above on https://github.com/tebl/RC6502-Apple-1- ... ter/Bus.md

Also, my goal would be to have an easy implementation for a backplane that can use both RC2014 and RC6502 IO boards. So, I would try to keep signals as compatible or at least similar/comparable. Like:

19: SYNC - similar function as M1
21: Phi2. And doing away with all the other clocks. In my experience Phi2 suffices, and should be created by the CPU board as the CPU may be running at higher speeds / in sync with video etc that is not on the bus anyway.
23, 26: this could be /MEMSEL and /IOSEL or similar to select two address ranges
25: I need to check but if there is an inverted R/-W (i.e. W/-R) would that actually work for RC2014 boards without change then? RDY would need to go elsewhere then, if at all needed.

This way I think if R/-W is appropriately qualified with the clock for RC2014 and direct for RC6502 both types of boards could be used, right?

_________________
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/

I've kinda let this slide for a bit, unfortunately, so it's still sitting on my todo list where it's been for about a year. (Though this recent discussion helped out quite a bit.)


Well, the backplanes are of course already physically compatible, but if you're talking about having boards that can work on both, that's rather more complex because not only some of the control signals but the protocols for how they're used are different. I doubt that there are many situations where a board could make good use of both SYNC in Mototorla and M1 in Intel systems.

That said, yes, my aim would be to try to restore as much commonality even for different signals that serve similar purposes, since that at least reduces developer error a bit and probably makes "switchable" boards easier.


Yeah, I've not actually received a definitive answer to When Φ2 should be used over Φ0, but at this point it seems pretty safe just to entirely ditch the two extra clock lines added by RC6502 and use just the one already defined by RC2014 as the system clock.


RC2014 /IOSEL seems a prime candidate for re-use as an IO select in RC6502 since that would seem to potentially increase the ability of boards to work across both, if anything. /MEMSEL I'm not so sure about, but perhaps it might make sense to define it as a select for "external memory" for CPU boards that are either not full or use bank switching? That would seem to work.


RDY is definitely needed on RC6502; it's vital for DMA, amongst other things. The annoying thing here is that though the Z80 also has a similar pin, /WAIT is not on the standard (40-pin) RC2014 but, but only the extended (80-pin) bus (pin 25 of row 2). So I'm inclined to leave RDY where its, since there is no for an inverted R/W on the bus anyway (anybody that needs something like that can generate it with an inverter, the exact same way the CPU board would do it), and that it least places it next to /WAIT pin on extended-bus RC2014 boards, making jumpering easier.

But on the other hand, there's your idea of:

Hmm. Is it really that simple? This is the sort of thing where I'd be a lot more comfortable if I saw a detailed description of why this actually works (including a timing analysis) and an example of it working. (Examples could be built with an adapter board, perhaps, if one doesn't want to hack on a CPU board directly.)

_________________
Curt J. Sampson - github.com/0cjs

that's what I was thinking about

Yes thought about that after posting...


I'd have to check timing still but my understanding is that write is when both IOSEL and WR are active independent from the clock. IIRC I looked that up for a UART board I built for 6502 machine.

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/

In fact looking at http://www.z80.info/zip/z80cpu_um.pdf it could be more difficult depending on the type of device used.

The z80 sets /mreq and /iosel only when Ax are valid and /wr only when Dx are valid to accommodate for transparent latch type devices. So, those type of devices would only work with further qualification of the select and r/-w lines.
Also, if devices rely on the clock (unlikely in my opinion as this just complicates without gain?) It would not work as well.

On the other hand the UART as an example seems to use a register based design and works fine with just phi2-qualified selects ... it doesn't even have a clock input http://www.6502.org/users/andre/csa/duart/csaduart.png

So, it really seems to depend on the devices...

_________________
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/