_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

I am pretty dubious of the coprocessor idea because I think it is a waste of resources.

A coprocessor that handles I/O doesn't speed up I/O very much --- instead it speeds up the main program because the main program isn't being interrupted --- the main program isn't necessarily doing anything time-critical, so speeding it up isn't necessarily the #1 priority.

The coprocessor that handles I/O speeds up I/O because it has its own registers, so these don't have to be saved and restored to the stack. This can be done more easily by having shadow-registers similar to the PIC24 that get switched in for the ISR.

A coprocessor is an interesting thought though. It doesn't need as many registers, so in this regard it uses less resources than the shadow-register idea. My design at this time is based on the MC6805, but is smaller --- it doesn't have an S register or support a return-stack --- ISRs can't be interrupted, and ISRs can't call subroutines.

Is the Parallax Propeller the only system available that uses coprocessors? Has anybody every tried a dual-core 65c02 or some such thing? I mentioned this previously on this forum --- I was told that bus contention is a problem on the 65c02 because almost every instruction accesses memory --- this isn't actually a problem though because I'm assuming that the coprocessor has its own memory, and only the alternate-bank is shared.

You can imagine a coprocessor tuned to the I/O device which can read the status register and the data register and more or less DMA into memory. Especially if it has a dual bus architecture: one bus for the peripheral and another bus to the memory (which would be shared with the main processor).

Regarding the T flag, I agree that VM interruptions are best done on the transition between VM instructions. However, the way I've done it is to have the IRQ handler selfmod the central NEXT routine to jump out elsewhere. This is often done in a single byte, so it's safely atomic, with no extra overhead or tests in the non-interrupt case. It seems that with the T flag, NEXT would have to have a software check for interrupt. While it's cheaper than checking some byte in RAM for the flag bit BIT or something, the selfmod way is faster & shorter still in software, and takes no additional hardware resources.

However, if NEXT is inlined at the end of instruction implementations, because the ISA allows it to be that small, then selfmod wouldn't be appropriate.

_________________
WFDis Interactive 6502 Disassembler
AcheronVM: A Reconfigurable 16-bit Virtual CPU for the 6502 Microprocessor

I'm going to call that else-modified code! (We used it on the ARM in the PiTubeDirect code: faster 6502 emulator because the instruction dispatch was modified in the event of an interrupt and otherwise just ran at full pelt.)

Howdy Hugh, I looked here and found your text on the 65VM02 enhanced CPU so no need to send me a copy.

I will say this site looks like a very interesting place with lots of good discussions going on. I'm sorry to say I have never worked with the 6502 but I think it's about time. I find it fascinating that CPUs that are 40 year old still keep being used, it speak volumes on the usability and cost of the device, it takes a licking and keeps on ticking.

I'm planning on the later part of this year to build a 6502 CPU of some sort, I see Mouser still carries the part, and they have a 14MHz CMOS part for a couple of dollars. My planned build will be a very simple CPU with 64K of RAM and some shadow EPROM to start up the system with a serial port being the only other device on the board. It will use Forth as the OS/Monitor/Compiler for it.

I remember reading about enhanced 6502 devices that have 16 bit instructions and register, and are way faster than the original device, I can't remember what the device is but I'm sure that looking around this site I will see mentions of it. Eventually I want to implement a 6502 like device on an FPGA so I'm interested in other persons enhancement to the 6502. For the FPGA version I would want an enhanced version with 16 bit and extra registers to make it more powerful as a learning exercise.

On your Forth for your device I think you are being very generous with your estimate of the resources required and I think you would be able to do it with half of that amount. Currently I'm working on a project to create a portable Forth system using byte code (token threaded in Forth parlance) and it's seem that it will end up taking less that 6K of code for a eForth system with 200+ words. Right now I'm on the planning stage but I will start coding this weekend.

Hello to everyone here, after reading some on the 6502 I'm sorry that I did not work more with it as it's a very interesting and simple CPU that looks quite a nice device to work with. I came very close to buying a Jolt CPU and later I regretted not doing so, I mostly worked with i8080 (Altair serial #17) and Z80s in the 70's and 80s with some MC6809 and MC68000 work too. I'm currently retired due to health issues so I have time to revisit some of the wonderful time I had working with these CPUs and try out some that I didn't get a chance to work with.


Cecil Bayona - k5nwa

_________________
Cecil Bayona - k5nwa

Hi Cecil, and welcome! There have been lots of discussions about enhanced 6502s - I made something of an index here:
Index of threads for improved 6502 and derived architectures
It's possible you're remembering the 65Org16, which is fast and 16 bit, and had some derived implementation too with more registers. You'll find links in the above post.

I understand what you mean about a selfmod NEXT --- that won't work for me though because I use a NEXT macro at the end of every primitive --- your technique would require every primitive to end in JMP NEXT which would slow the Forth system down too much.

I have a new version of the document (attached).

I got rid of the T-flag, as well as several other new instructions. The design is simpler now than what I had previously. It should be more efficient though, because now IP is only used for byte-code execution and I have FLDA and FSTA for accessing data in the alternate-bank.

The next thing for me to do, is to write a simulator --- I can then begin writing my Forth and my multitasking OS --- with the simulator I can test my code and not have to speculate on what is needed.

I may have to put the T-flag back in --- I think it should be possible however, to do a task-switch in the middle of a primitive --- I don't really want the T-flag because the BTC inside of NEXT is going to slow down Forth (generally speaking, NEXT is the big time-sink in any threaded Forth system, so even one extra instruction in NEXT can make a difference overall).

The bug was in my CMOVE that I wrote myself in the document. I have a new version now that should work --- still untested though, because I haven't yet written a simulator.


Well, the Z80 was more convenient to use --- you didn't have to test I/O ports to determine what caused the interrupt --- you got sent down a vector to the appropriate ISR (I have something quite similar now in the 65VM02 design).

The Z80 interrupt latency was higher than the 6502 though --- you are right that the 6502 had the fastest interrupt response of any 8-bitter of its day.

The story on the ARM is that the Acorn computer used the 6502, but they needed a more powerful processor. They liked the 6502's fast interrupt response time though, so they didn't want to switch to the MC68000 because it has a slow interrupt response (saving all those 32-bit registers takes a lot of time). For reasons unknown, they rejected the 65c816, although that would seem to be the obvious choice. They built the ARM (Acorn Risc Machine) instead, and it has register banks for ISRs so no need to save and restore registers to the return-stack. Later the ARM got sold to an American company and the ARM acronym came to mean: Advanced Risc Machine.


No, when I said D I meant the D register of the 65VM02 (8-bit register that points to the page that the direct-page is located on).

I didn't mean the D-flag which indicates decimal-mode and is in the P register. I'm just leaving decimal support alone --- it is not something that I use --- it should be left alone though, for legacy code.


Well, in my new 65VM02 design, this would be done in hardware rather than in software.


Well, in my new 65VM02 design, I have a VIRQ interrupt in addition to IRQ and NMI. It saves A in addition to P and PC, but it doesn't save X and Y as they may not be modified in a short simple ISR.

Hello Cecil --- glad to see you make it over to this forum --- there are still 6502 enthusiasts in the year 2017, which tells you that the 6502 was a good design.

I have read about several upgrades on the 6502 that give it 16-bit registers --- the most well-known is the 65c816 from Western Design Center (used in the Super Nintendo game-machine, although it is obsolete now).

My own experience with processor design was the MiniForth processor from Testra done in 1994/1995 (I wrote MFX the assembler/simulator and Forth compiler for it). This was built on the Lattice isp1048 PLD. In those days, registers were very expensive in regard to chip resources, which is why the MiniForth has so few registers. Nowadays, FPGAs have a lot more resources. Still though, I think the number of registers and how big they are, is the primary factor in regard to how big the FPGA needs to be, which translates directly into dollars. So, rather than upgrade the 65c02 from 8-bit registers to 16-bit registers, I'm sticking with the original design using 8-bit registers even though an upgrade to 16-bit registers would likely boost the speed a lot. My priorities are low-power and low-cost --- if high-speed were my first priority, I would just use the ARM or one of the other super-fast 32-bit processors available these days.

Another reason why I'm interested in sticking close to the original 65c02 design, is that there is Verilog code for the 65c02 available, some of which is public-domain --- by sticking with the original design I simplify the job --- I don't know anything about Verilog, so I want to keep the job as simple as possible, so I have some chance of success.

Actually, the MPU in the SNES was the Ricoh 5A22, not the 65C816. The 5A22 incorporated the '816 core, minus a few functions (no ABORT interrupt, for example), but also added quite a few capabilities that tailored the device to its role as a game console processor, rather than a general purpose processor. The 65C816 was originally designed to be used in the Apple IIgs, which is where it had its largest market penetration.

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

Interrupt latency does not stop at the first instruction of the IRQ handler, though. Saving the registers and identifying the source are also part of the latency. Having a vectored interrupt, even it takes more cycles to start, can be faster in the end, because it saves time having to poll all interrupt sources.

edit: forgot important word.

Hmm, I would have said that ARM was spun out of Acorn as a jointly owned venture. (Acorn's shareholding in ARM was a major source of Acorn's wealth and the reason for its ultimate demise.) Acorn were seeking higher performance than the 6502, and demanded fast interrupt response for their system architecture. They had surveyed the available MPUs and wanted more performance than they could get from existing offerings. (They did produce a 65816 machine, a 32016 system, and an x86 system, and there was at least one 68000 third-party system. So the existing choices were well understood.) As WDC had demonstrated that a tiny team could make a processor, and as the then-recent RISC research showed promise, Acorn went ahead with their own small team and made ARM.

That certainly is true if there are many active interrupt sources. That would not describe most 6502 systems. Using the Commodore 128 as an example, it had exactly two possible IRQ sources: the VIC and CIA #1. In C-64 mode, disregarding specific programming to the contrary, only the CIA is an IRQ source. In C-128 mode, only the VIC is an interrupt source, unless other arrangements are made. Hardly a good case for a vectored interrupt system.

My POC V2.1 unit has a total of four possible IRQ sources: the two DUARTs, the SCSI controller on the host adapter and the real-time clock. Only the DUARTs and SCSI are programmed during POST to generate interrupts. Three possible sources to poll is not that burdensome. However, I may eventually scale up the programmable logic to where it would include a priority interrupt encoder that would not only identify the specific interrupt source but would also setup the go-to address to service that source. As it would be the CPLD doing that work, not the 65C816, the interrupt latency would not be compromised.

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

On the other hand, the Z80 business systems had a lot more peripherals with interrupts, including multiple floppy disks, serial ports, real time clocks, and even built-in modems.