GARTHWILSON wrote:
I know 68K enthusiasts definitely like the programmer's model. It is more suitable for certain compiled languages like C. The 6502's extended set of registers is of course zero page, and the 816's is the direct page which is like zero page but renamed because it can be relocated, and every task can have its own DP. (The '816 is much better suited to things like multitasking and relocatable code than the 6502 is.) BigEd
observed, "With 6502, I suspect more than one
beginner has wondered why they can't do arithmetic or logic operations on X or Y, or struggled to remember which addressing modes use which of the two. And then the
intermediate 6502 programmer will be loading and saving X and Y while the
expert always seems to have the right values already in place."
My assembly language teeth were cut on the 6502 over 35 years ago. I know the 6502 inside and out and in fact still to this day remember the hex values for several dozen of the opcodes (not to mention ROM addresses, hardware register addresses, etc. of the machines I used back then). Years later, when I transitioned to the 68000, I remember initially being overwhelmed with the sixteen registers, but it didn't take long for me to adapt and begin using them advantageously. In my opinion, both processors can be rewarding for an experienced programmer to work with despite dramatic differences in architectural philosophy. I feel fortunate to have been able to spend time with both of them.
While it is a popular view that the zero page (or direct page on the 6809 or 65816) are like an extended set of registers, there are some fundamental differences in architecture between zero/direct page memory and registers having to do with the presence or absence of the memory bus between the register and the processor. I'd say zero/direct page memory are closer to cache memory than to extended registers myself.
GARTHWILSON wrote:
On the segmented memory, the 65Org32 (so-far-vaporware-only) all-32-bit 65816, the bank registers are 32-bit also, serving as offsets for various tasks' beginning addresses but eliminating the 64K boundaries. The 65816's bank boundaries are transparent in long addressing; but without using long addressing all the time, the key is to make the boundaries work for you instead of against you, just as one does with zero page (and on the '816, "direct page," since it can be relocated). The shorter addresses in operands and tables were a benefit especially when memory was far more expensive than it is today.
It was part of the snobbery of the day for 68000 programmers to look down on x86 programmers due to the segmented architecture. After all, why should the programmer concern himself with such details when his time was better spent focusing on efficient algorithms rather than worrying about whether or not he needed a far or near pointer when he added more lines to his code. Part of the elegance of programming the 6502 was the complex juggling act required of the programmer in keeping in mind and optimally using the very scarce CPU resources that were available to him. In fact this was a matter of pride that I'm sure extends to many of the old-timers on this group today. Yet it is precisely such limitations that generations of new architectures have sought to eschew (and rightfully so in my opinion). For is it not more valuable to enable the programmer to focus on algorithm design rather than resource management as he works?
GARTHWILSON wrote:
In the Apple IIgs, the '816 was definitely capable of more than 2.8MHz, but Steve Jobs wanted it held down because he didn't want the IIgs to make the Macs looks bad.
I believe The Woz was still at Apple at that time and I'm surprised that he would acquiesce to such demands, much less artificially limit the architecture in such a manner as to make it almost impossible to work around the limitations in all the time that has come since. All of the accelerators that I'm aware of have been relatively limited in that they have been unable to increase the bus speed itself and have instead only focused on adding speed and cache to the processor.
GARTHWILSON wrote:
I believe the 68K took 46 clocks for the interrupt acknowledge and interrupt sequence. The 816's is 8 clocks, one more than the 6502's, because it pushes the program bank. Programming manuals usually show ISR examples that are much longer than normally needed, just to cover all their bases, since they don't know your particular situation and they want to make sure they push and initialize everything including things you won't need in many situations.
I don't remember the interrupt latency on the 68K, but if its anywhere near 46 clocks then clearly it doesn't make a very good real-time processor. I understand the 6502 was designed to be an I/O processor from the beginning, so it stands to reason that it (and its descendants) would have good interrupt latency. OTOH, the 68000 was designed for computing and was used in many of the early workstations of the day.
GARTHWILSON wrote:
It is unfortunate that so many ICs are not available in DIP form; but fortunately we can get adapters that are easy to use, like this one from Jameco:
I have a mixed background as both a hardware and software engineer, so I'm no stranger to the many SMT to through-hole adapters out there. I frequently design multi-layer PC boards with high-density SMT parts on them but I have a technician do all the soldering. In my home workshop, I've done a few TQFP-100s in the recent past, but it's not my idea of fun:
Attachment:
DIPnTQFP.jpg [ 404.63 KiB | Viewed 1430 times ]
Having said that, nothing beats solderless breadboard for trying out new ideas or ideas. I am very impressed with the work that Oneironaut is doing with his Vulcan 74 project (to single out one of many impressive projects shared by members here). If I had no other choice, I'll use a surfboard (SMT to through-hole kludge) to enable me to use parts I can't find in any other format, or I'll just design an entire daughterboard I can easily interface to breadboard as I have done with CPLDs in the past (the source of my TQFP-100 soldering "fun"). But in this case there is a readily available off-the-shelf DIP part which I believe can be made to function as a high-performance UART that will afford no performance degradation to any 6502 system into which it is plugged, and which will have a software interface which will be virtually indistinguishable from the real thing. Well, those are my goals anyway, let's see how close I can get to them. And if I'm successful, I'll leverage the work to add SPI, I2C, and any of the other dozen or so hardware peripherals that make the PIC an attractive platform for embedded work.
GARTHWILSON wrote:
The 6522's shift register can only go one direction at a time, so you'd need two for full duplex SPI. I think all the SPI ICs I've used used only one direction at a time though, with dummy data going in the other direction. If you do use the SR, sending a byte is as simple as STA VIA_SR. 16 clocks later, you can do it again, if it's running at half the phase-2 rate. If you can get the next byte to send any sooner, you could check the status but it would be more efficient to just put in a NOP or something like that.
I appreciate the heads up on some of the things the 6522 can do. I added one to the parts order that went out earlier today and will play with it as soon as is practicable. I'm unconvinced that it will be even equal to a PIC for SPI communications, but I'm certainly open to sticking both of them on a 6502 bus and try them both out.
GARTHWILSON wrote:
I do like the I²C protocol a lot. I think very few devices can handle 5MHz clock rate, and other devices on the bus will need the slower clock rate just so they don't foul things up by responding incorrectly to start and stop conditions and addresses.
I only mentioned the 5 MHz clock rate because the standard now goes up to that rate. I haven't used anything faster than 1.2 MHz myself, and most of the hardware I work with is only rated to 400 kHz, with a few being limited to 100 kHz. I imagine a 14 MHz 6502 could bit-bang out the lowest rates itself if it didn't have anything else to do at the same time.
GARTHWILSON wrote:
I have only bit-banged both SPI and I²C myself. The
circuit potpourri page of my
6502 primer has circuits I've used, and links to accompanying source code, and also Jeff Laughton's tricks for fast (single-cycle) I/O with the 65c02. If you bit-bang with his tricks, producing a clock pulse, ie, a rising edge and a falling edge, takes a grand total of 2 cycles. Otherwise it takes usually 12, for INC, DEC, putting the clock line on a 6522's port's bit 0 so you can change just the one bit with these instructions. Put incoming data on bit 6 or 7 so you can test it with BIT without having to use AND.
Thank you for sharing your work with the community. Part of the reason I came here is because I could see there were a number of knowledgeable and enthusiastic people who all seem interested in sharing their knowledge and experience. I know few of my engineering peers would see the point of playing around with technology that was designed about four decades ago, but while there are still some differences of opinion here, that is not one of them.