65VM02

[Hugh Aguilar]

sark02 wrote:

Hugh Aguilar wrote:

I've talked to other HDL guys about the 65VM02, but none were enthusiastic --- they point out that there are much more powerful processors available nowadays for only a few dollars --- they seemed to think that the 65VM02 was a dumb idea and that I should go look at a calendar (note that this is not 1984 anymore).

Don't let them discourage you. Regardless of its practical utility, there's a special challenge in trying to squeeze more out of an 8-bitter like the 6502; especially with its limited register model. It would be an easier first HDL project, I think, to implement a 32-bit processor with 32 GPRs (think: MIPS or RISC-V). Although there's some satisfaction to be had there, and you'd get tools (like an assembler and C compiler) for free, you wouldn't be doing anything new. You seem to be having fun designing your own extensions, and I think it's going to be immensely satisfying seeing it come to life in an FPGA.

Rock on.

Thanks for the encouragement!

A lot of professionals are overly full of their own professionalism. They act like every project needs to be cutting-edge, and using last year's technology would make them hopelessly out of date. Every project is all about super high-speed performance! They won't be happy until a micro-processor is available that bends space-time and provides results before they are asked for --- and then they would complain that it draws too much amperage --- that is the downside of having a miniature black-hole inside of your chip...

The reality is that waiting a few microseconds for a result is usually okay. There is still plenty of use for 8-bit micro-controllers. I'm not saying that the ARM isn't cool in its own way, but it is not something that I'm personally interested in (although if somebody wanted to pay me to write ARM code, I wouldn't turn them down).

[Arlet]

Quote:

I was thinking about how cool it would be to have an experimenter board similar to those, but based on the 65VM02.

There are plenty of affordable FPGA eval boards out there with various I/O ports that you could turn into such a platform.

[sark02]

Hugh Aguilar wrote:

A lot of professionals are overly full of their own professionalism.

For people who do embedded systems for a living, the selection of processor is a serious thing with many considerations. Even a solo contract developer will be given constraints in time or cost or volume that exclude certain paths, or customer requirements for specific technologies (processor, language) that override personal preference.

• I'd prefer a microcontroller over a discrete processor, for design simplification and tools support.
• I'd prefer a 32-bit machine over an 8 or 16-bit machine, as it makes for easier development in my opinion.
• I'd prefer C over C++ or any other high level language as it's the most well know language in embedded systems, with a small runtime and with plenty of accessible libraries
• I'd prefer to use a packaged toolchain over rolling my own
• I'd prefer to keep assembly code to a minimum, as it's the least maintainable option over the long term.
• I'd prefer to use a vendor IP core in an FPGA or ASIC, over open source, due to proper test integration support; esp. when it comes to closing timing and help with physical design issues.

I've written plenty of assembly language in my time, but unless a function has to operate without functioning memory, is too low level for 'C', or is proven time-critical, it's not worth the effort trying to outperform a compiler. Keep the eye on the goal, which is delivering a functioning project, under budge and on time (ha ha), with proper documentation, that can be maintained by other engineers.

Now, with that self-indulgent diatribe over, that's business. For personal and hobbyist stuff, don't let anyone tell you what is or isn't relevant. If you want to write a 6502 emulator for the Apollo Guidance Computer, in its native assembler, then... well yes you're certifiable in some respects, but maybe eccentric is the better word. Point is: if it's fun for you then it's worth your time. You might find like-minded folk who want to help or advise, and you might find people who think your efforts are useful in their own projects, which is great validation... but I hope you enjoy it either way.

Good luck with the simulator!

[Hugh Aguilar]

sark02 wrote:

Hugh Aguilar wrote:

A lot of professionals are overly full of their own professionalism.

For people who do embedded systems for a living, the selection of processor is a serious thing with many considerations. Even a solo contract developer will be given constraints in time or cost or volume that exclude certain paths, or customer requirements for specific technologies (processor, language) that override personal preference.

• I'd prefer a microcontroller over a discrete processor, for design simplification and tools support.
• I'd prefer a 32-bit machine over an 8 or 16-bit machine, as it makes for easier development in my opinion.
• I'd prefer C over C++ or any other high level language as it's the most well know language in embedded systems, with a small runtime and with plenty of accessible libraries
• I'd prefer to use a packaged toolchain over rolling my own
• I'd prefer to keep assembly code to a minimum, as it's the least maintainable option over the long term.
• I'd prefer to use a vendor IP core in an FPGA or ASIC, over open source, due to proper test integration support; esp. when it comes to closing timing and help with physical design issues.

I've written plenty of assembly language in my time, but unless a function has to operate without functioning memory, is too low level for 'C', or is proven time-critical, it's not worth the effort trying to outperform a compiler. Keep the eye on the goal, which is delivering a functioning project, under budge and on time (ha ha), with proper documentation, that can be maintained by other engineers.

Now, with that self-indulgent diatribe over, that's business. For personal and hobbyist stuff, don't let anyone tell you what is or isn't relevant. If you want to write a 6502 emulator for the Apollo Guidance Computer, in its native assembler, then... well yes you're certifiable in some respects, but maybe eccentric is the better word. Point is: if it's fun for you then it's worth your time. You might find like-minded folk who want to help or advise, and you might find people who think your efforts are useful in their own projects, which is great validation... but I hope you enjoy it either way.

Good luck with the simulator!

Thanks for your encouragement!

Roughly speaking, there are three kinds of projects:

1.) Professional in which a few boards will be built, so developing software is the primary expense, and the cost of the hardware is not significant.

2.) Professional in which thousands of boards will be built, so the cost of the hardware is the primary expense, and the expense of developing software is secondary.

3.) Hobbyist.

You are describing #1.
I agree that a 32-bit board with C as the programming language and a packaged tool-chain is the way to go. The use of non-mainstream processors would only be an option if you have already developed your own tool-chain for one of them. There are professionals around who do everything using a particular off-beat processor, but they have been doing this for decades and they are good at it.

For #2, you may chose from a wide variety of non-mainstream processors --- the 65VM02 or 65c816 would be options --- assembly-language or Forth would be options.

For #3, there are no rules! This is where the 65VM02 is at right now --- I make up my own rules as I go, on a day to day basis --- that is pretty much the definition of "fun" in any context.

[GARTHWILSON]

I occasionally do some consulting for a company that makes propulsion units for small satellites. It's the #1 kind of project above, where they make very few units and the cost of the processor is immaterial. They mainly use the 16-bit MSP430 for the controllers. So far, I have not been involved in the software itself, but I recently tested a controller, and in all the operations it has, I didn't see anything that required anywhere near what the the MSP430 can do, performancewise. The most important thing they needed was all the I/O pins and modules, which they've maxed out. They use C just because it's what the main programmer is familiar with and there was an off-the-shelf development system for it.

[Hugh Aguilar]

GARTHWILSON wrote:

I occasionally do some consulting for a company that makes propulsion units for small satellites. It's the #1 kind of project above, where they make very few units and the cost of the processor is immaterial. They mainly use the 16-bit MSP430 for the controllers. So far, I have not been involved in the software itself, but I recently tested a controller, and in all the operations it has, I didn't see anything that required anywhere near what the the MSP430 can do, performancewise. The most important thing they needed was all the I/O pins and modules, which they've maxed out. They use C just because it's what the main programmer is familiar with and there was an off-the-shelf development system for it.

There is a radiation-hardened version of the MSP430?

The RTX2010 was used in the Philae mission that has been in the news. There aren't many radiation-hardened processors available, so the RTX2010 continues to be used although the RTX2000 is considered to be obsolete in Earth-bound applications --- the ARM is the mainstream.

I would expect the RTX2000 to be roughly comparable to the MSP430 performance-wise.

Maybe NASA will decide to use the 65VM02 in space --- that would be pretty cool!

[GARTHWILSON]

Hugh Aguilar wrote:

There is a radiation-hardened version of the MSP430?

I'm attaching the test results which show it was found to endure the radiation plenty well for the application. (It says on the front page, "APPROVED FOR PUBLIC RELEASE; DISTRIBUTION IS UNLIMITED.")

Quote:

The RTX2010 was used in the Philae mission that has been in the news. There aren't many radiation-hardened processors available, so the RTX2010 continues to be used although the RTX2000 is considered to be obsolete in Earth-bound applications --- the ARM is the mainstream.

I would expect the RTX2000 to be roughly comparable to the MSP430 performance-wise.

I doubt it. The RTX2000 routinely did 16 Forth MIPS at 12MHz.

Quote:

Maybe NASA will decide to use the 65VM02 in space --- that would be pretty cool!

I'd be delighted; but I won't hold my breath.

[Hugh Aguilar]

GARTHWILSON wrote:

Hugh Aguilar wrote:

I would expect the RTX2000 to be roughly comparable to the MSP430 performance-wise.

I doubt it. The RTX2000 routinely did 16 Forth MIPS at 12MHz.

Do you mean that the RTX2000 was significantly faster than the MSP430, or vice-versa?
I'm not familiar with either processor. I just know they are both 16-bit.
I read up on the MS430 and found that it has a pretty orthogonal straightforward architecture that should be an easy target for Forth, C, or anything else. The MSP430 can address up to 1MB of memory using a bank-switching scheme.

With the 65VM02 I'm aiming at a somewhat different kind of application area:

1.) Has a lot of data --- that is why there is 16MB of far memory.

2.) Has a lot of I/O --- that is why there are MIRQ interrupts in the current design --- an alternate plan (better but more difficult to implement) is to have a coprocessor(s) that does the I/O and uses buffers in far memory.

3.) Is complicated enough to make a multi-tasking OS and a high-level language worthwhile.

4.) Doesn't require the speed of a 16-bit processor --- most of the time is spent in processing I/O in ISRs written in assembly-language, rather than doing calculations in the main-program that require a lot of Forth MIPS or any other kind of MIPS.

5.) Low cost and low power consumption.

It is quite possible that designing my own processor is foolishness --- there may be existing processors that do all of this already, and do it better than any funky design of my own based on 1980s technology --- it is mostly just for fun, to see what could be done with the 65c02 while still keeping to the basic 8-bit design.

[GARTHWILSON]

Hugh Aguilar wrote:

Do you mean that the RTX2000 was significantly faster than the MSP430, or vice-versa?

I suspect the RTX2000 was the hotter performer, as far as processing power goes, since it routinely did 16 MIPS, and Forth MIPS to boot, and 60MIPS peak. The MSP430 can supposedly do 16MIPs, but not Forth MIPS, and the 16MIPS is not taking off for the instructions that take more than one cycle. Wikipedia says,

• "Instructions generally take 1 cycle per word fetched or stored, so instruction times range from 1 cycle for a simple register-register instruction to 6 cycles for an instruction with both source and destination indexed.
  
  The MSP430X extension with 20-bit addressing adds additional instructions that can require up to 10 clock cycles. Setting or clearing a peripheral bit takes two clocks. A jump, taken or not takes two clocks. "

Quote:

I read up on the MS430 and found that it has a pretty orthogonal straightforward architecture that should be an easy target for Forth, C, or anything else.

Brad Rodriguez has ported his CamelForth to the '430.

Quote:

It is quite possible that designing my own processor is foolishness --- there may be existing processors that do all of this already, and do it better than any funky design of my own based on 1980s technology --- it is mostly just for fun, to see what could be done with the 65c02 while still keeping to the basic 8-bit design.

Ever since I saw an article in a magazine about 45 years ago about a man who made his own electric car, including the body, I've thought it would be cool to do that. (He did use chassis parts from the junk yard though, so he didn't have to make things like the steering, suspension, brakes, and rear end.)

[Hugh Aguilar]

GARTHWILSON wrote:

Hugh Aguilar wrote:

Do you mean that the RTX2000 was significantly faster than the MSP430, or vice-versa?

I suspect the RTX2000 was the hotter performer, as far as processing power goes, since it routinely did 16 MIPS, and Forth MIPS to boot, and 60MIPS peak. The MSP430 can supposedly do 16MIPs, but not Forth MIPS, and the 16MIPS is not taking off for the instructions that take more than one cycle.

What is speed needed for?

In the old days (up through the early 1990s), speed was an issue. For example, Testra's motion-control board for the laser-etcher based on the Dallas 80c320 was too slow, so Testra introduced the MiniForth processor that was less expensive and higher speed than the competitor's MC68000 board. Now the MiniForth has been ported to an FPGA and is much faster (maybe 20 or 40 times faster; quite a lot). It would smoke the RTX2000 or MSP430 easily. It seems like it would literally smoke the machine too --- there are physical limitations to how fast a mechanical contraption using gears and belts can move before smoke starts coming out.

With the 65VM02 my goal is to support high-level language programming (with the byte-code VM) and support a multi-tasking OS (with the D register and EXA instruction, etc.). These are conveniences for the programmer --- these features would allow programs to be written more quickly than they could be written using C on an MSP430, and execute more quickly too --- I'm not trying for super high-speed though, as I can't think of any application that needs this.

GARTHWILSON wrote:

The MSP430X extension with 20-bit addressing adds additional instructions that can require up to 10 clock cycles.

What is 1MB+ memory needed for?

In the old days, memory was an issue. Most of the processors were limited to 64KB and this was a problem in some programs, and those bank-switching schemes were terribly inconvenient.

On the 65VM02, the byte-code is pretty compact compared to the machine-code on almost any processor, so programs should be smaller. A 128KB system should support very big programs --- I doubt that anybody is going to complain that their program is too big to fit.

The far-memory can be as much as 16MB, which is a lot more than the 1MB that the MSP430 addresses, but it is less convenient because the only instructions that access it are FLDA and FSTA, both of which use (direct), Y addressing with a three-byte pointer in the direct-page. I'm primarily thinking of the far-memory being used as a RAM-disk to hold files that go to or from a desktop computer via a UART.

One application that uses a lot of memory is TCP/IP. The eZ80 was provided with 16MB total memory for the purpose of supporting TCP/IP. I don't know anything about TCP/IP though. What would the 65VM02 need to support this?

Another thing that I don't know anything about, is USP. This requires hardware support. USP is a lot faster than a basic UART --- but I don't know why transferring files at high-speed is needed --- my 65c02 cross-compiler had the Apple-IIc target and MS-DOS host talking at 19,200 baud, which was adequate for my purposes.

I was told that all cars sold in America and Europe (except Toyota) use a PowerPC variant with an eTPU coprocessor for I/O. The 65VM02 isn't going to be as powerful as that. I don't know why such a powerful system is needed though. Car engines still run at about 5000 rpm max, the same as they did in the 1980s. For an eight-cylinder car, that is 80,000 times per second that you have to turn a spark on or off, which is once every 12.5 microseconds. I would expect that a 25 Mhz. 65VM02 with a coprocessor for I/O could be fast enough to do this --- the multi-tasking OS should work well for keeping track of all the inputs from the various sensors --- this is the kind of application that I would hope the 65VM02 could be used for.

Who would care though? Saving a few dollars on the cost of the computer isn't going to have a significant effect on the profit-margin of a car that is sold for tens of thousands of dollars. The car manufacturers would likely stick with the PowerPC/eTPU system because they already have the code written, and it is more than powerful enough, whereas a marginal system might prove to be too slow.

[GARTHWILSON]

Hugh Aguilar wrote:

GARTHWILSON wrote:

Hugh Aguilar wrote:

Do you mean that the RTX2000 was significantly faster than the MSP430, or vice-versa?

I suspect the RTX2000 was the hotter performer, as far as processing power goes, since it routinely did 16 MIPS, and Forth MIPS to boot, and 60MIPS peak. The MSP430 can supposedly do 16MIPs, but not Forth MIPS, and the 16MIPS is not taking off for the instructions that take more than one cycle.

What is speed needed for?

That was only because you said, "I would expect the RTX2000 to be roughly comparable to the MSP430 performance-wise." As I said earlier though, I didn't see anything in the thruster controller that required much computational speed.

Quote:

With the 65VM02 my goal is to support high-level language programming (with the byte-code VM) and support a multi-tasking OS (with the D register and EXA instruction, etc.). These are conveniences for the programmer --- these features would allow programs to be written more quickly than they could be written using C on an MSP430, and execute more quickly too --- I'm not trying for super high-speed though, as I can't think of any application that needs this.

I like that.

Quote:

GARTHWILSON wrote:

The MSP430X extension with 20-bit addressing adds additional instructions that can require up to 10 clock cycles.

What is 1MB+ memory needed for?

Again it was just in reference to the MSP430's speed, bringing the average MIPS down possibly well below the MHz. I'm sure I myself will never have a use for more than 64K of program space, but data is another matter. And in the case of a RAM file chain, including executable files, it's nice to be able to run them wherever they are and not have to first bring them into the first 64K.

Quote:

One application that uses a lot of memory is TCP/IP. The eZ80 was provided with 16MB total memory for the purpose of supporting TCP/IP. I don't know anything about TCP/IP though. What would the 65VM02 need to support this?

It has been done on the 6502 (see http://oliverschmidt.github.io/ip65/ and https://duckduckgo.com/?q=uIP+TCP%2FIP+ ... cal&ia=web ), but I have not looked into it, including to know how much memory it leaves for other things.

Quote:

Another thing that I don't know anything about, is USP.

USB?

Quote:

This requires hardware support. USP is a lot faster than a basic UART --- but I don't know why transferring files at high-speed is needed --- my 65c02 cross-compiler had the Apple-IIc target and MS-DOS host talking at 19,200 baud, which was adequate for my purposes.

And if it weren't adequate, even the 6551 was specified to be able to do at least 115,000 bps if you don't use the internal baud-rate generator, and other UARTs will go faster. RS-422 can do 10Mbps at 40 feet, and RS-485 can do 35Mbps at 33 feet. Both can go at least 90kbps at 3/4 mile. USB can only go 16 feet. I understand that USB is much too complex for the technician to write his own drivers, he can't make up his own cables, can't really troubleshoot it, etc.. I don't know how they can call it "universal" (in "universal serial bus") if there are nine kinds of connectors and male and female of each, or call it a bus if normally one connector only goes to one device. Edit, 10/17/18: I was looking for a USB cord for something and I picked up cords with four of the smallest USB connectors I happened to have on my desk and rubber-banded them together for a picture. Actually, none of these fit the USB connector on my Samsung Sprint phone. That one is yet another size, just a hair wider than the widest one here:

Quote:

Who would care though? Saving a few dollars on the cost of the computer isn't going to have a significant effect on the profit-margin of a car that is sold for tens of thousands of dollars. The car manufacturers would likely stick with the PowerPC/eTPU system because they already have the code written, and it is more than powerful enough, whereas a marginal system might prove to be too slow.

Having the NRE and tool-up already done doesn't keep them from changing the tail lights every year, or from making $300 headlights that are only good for one model, and one side of that model, when a $10 round or rectangular one would do. (Maybe the special ones cost even more now. My mother-in-law broke one ten years ago and bought a replacement and I installed it. The part was $300, and it was a lot harder to install than the old round or rectangular ones.)

[BigDumbDinosaur]

Hugh Aguilar wrote:

I was told that all cars sold in America and Europe (except Toyota) use a PowerPC variant with an eTPU coprocessor for I/O. The 65VM02 isn't going to be as powerful as that. I don't know why such a powerful system is needed though. Car engines still run at about 5000 rpm max, the same as they did in the 1980s. For an eight-cylinder car, that is 80,000 times per second that you have to turn a spark on or off, which is once every 12.5 microseconds.

Your math could use some adjusting. The V-8 that powers my Mercury Marquis sedan has a 6000 RPM redline. At that speed, the engine makes 100 revolutions per second and being a four-stroke design, fires each cylinder 50 times per second. Hence the engine would be firing a cylinder at 2.5 millisecond intervals.

The reason today's automobiles have that computational power is because a lot more is being controlled than just when to send some juice to the spark plugs. Precise adjustments have to constantly be made to fuel mixture, ignition timing and in some engines, valve timing, all in an effort to produce the best possible combination of power, fuel efficiency and exhaust cleanliness. Adding to the workload is transmission control, as shift points in most automatic transmissions are now electronically determined, based upon engine loading at any given RPM, the fuel rate and other factors. The engine control package (ECM) also regulates coolant temperature with much greater precision than in the past, as running the engine as hot as possible without compromising reliability improves thermodynamic efficiency.

In order to do all this, many inputs are needed to sense engine operating conditions and all must be serviced in real time at a very rapid rate. Complicating matters, just about all of those inputs are analog, not digital. Further complicating matters, most of the ECM's outputs are also analog. I think your 65VM02 probably wouldn't cut it in this environment. Even the 65C816 running at the maximum clock rate would have trouble keeping up with the processing load.

Quote:

This requires hardware support. USP is a lot faster than a basic UART --- but I don't know why transferring files at high-speed is needed --- my 65c02 cross-compiler had the Apple-IIc target and MS-DOS host talking at 19,200 baud, which was adequate for my purposes.

I don't know why as well. After all, a 300 baud modem worked fine with a Commodore VIC-20. BTW, I assume you mean USB, not USP.

I can't speak for others around here, but if you did as much software development as I have done you would conclude that there is no such a thing as a computer that is fast enough. I run the interface between POC and my Linux development box at 115.2Kbps and wish I could run it faster. Even gigabit Ethernet seems a bit slow at times.

———————————————————————
Edit: Fixed a ham-fisted math error.

[Dr Jefyll]

BigDumbDinosaur wrote:

Your math could use some adjusting. The V-8 that powers my Mercury Marquis sedan has a 6000 RPM redline. At that speed, the engine makes 100 revolutions per second and being a four-stroke design, fires each cylinder 50 times per second. Hence the engine would be firing a cylinder at five millisecond intervals.

BigDumbDinosaur wrote:

I think your 65VM02 probably wouldn't cut it in this environment. Even the 65C816 running at the maximum clock rate would have trouble keeping up with the processing load.

Hard to say. There's presently no basis for comparison, as we don't yet have a clock rate for Hugh's FPGA-based design. But I suspect both would be adequate. ECM's probably use hardware timers to execute the most timing-sensitive tasks, and likewise the complexity of the analog I/O you mention is largely hidden from the CPU.

[Hugh Aguilar]

BigDumbDinosaur wrote:

Hugh Aguilar wrote:

I was told that all cars sold in America and Europe (except Toyota) use a PowerPC variant with an eTPU coprocessor for I/O. The 65VM02 isn't going to be as powerful as that. I don't know why such a powerful system is needed though. Car engines still run at about 5000 rpm max, the same as they did in the 1980s. For an eight-cylinder car, that is 80,000 times per second that you have to turn a spark on or off, which is once every 12.5 microseconds.

Your math could use some adjusting. The V-8 that powers my Mercury Marquis sedan has a 6000 RPM redline. At that speed, the engine makes 100 revolutions per second and being a four-stroke design, fires each cylinder 50 times per second. Hence the engine would be firing a cylinder at five millisecond intervals.

Okay, my math was screwed up badly. Your calculation seems to be correct.

5 milliseconds is actually very pedestrian --- even 1980s processors can do that --- I think GM used a 6803 and Mitsubishi used their '740.

BigDumbDinosaur wrote:

The reason today's automobiles have that computational power is because a lot more is being controlled than just when to send some juice to the spark plugs. Precise adjustments have to constantly be made to fuel mixture, ignition timing and in some engines, valve timing, all in an effort to produce the best possible combination of power, fuel efficiency and exhaust cleanliness. Adding to the workload is transmission control, as shift points in most automatic transmissions are now electronically determined, based upon engine loading at any given RPM, the fuel rate and other factors. The engine control package (ECM) also regulates coolant temperature with much greater precision than in the past, as running the engine as hot as possible without compromising reliability improves thermodynamic efficiency.

In order to do all this, many inputs are needed to sense engine operating conditions and all must be serviced in real time at a very rapid rate. Complicating matters, just about all of those inputs are analog, not digital. Further complicating matters, most of the ECM's outputs are also analog. I think your 65VM02 probably wouldn't cut it in this environment. Even the 65C816 running at the maximum clock rate would have trouble keeping up with the processing load.

With a lot of I/O it would help to have multiple interrupts. The 65c02 or 65c816 would have a problem because they only have the IRQ and NMI, so each interrupt has to poll a lot of I/O ports to figure out what tripped the interrupt. The 65VM02 has MIRQ3, MIRQ2, MIRQ1, MIRQ0, IRQ, and NMI. This is still not enough.

It is not really a matter of raw processing power --- it is more a matter of being able to handle a lot of interrupt lines.

On this subject, does anybody actually use BRK for anything? My 65VM02 is 65c02 compatible at this time, but I'm thinking about getting rid of BRK and breaking compatibility. This would be done to free up that bit in the P register to be used as another interrupt-mask similar to the M-flag, but for another level of interrupts. Another possibility is to get rid of decimal mode, which almost nobody uses, which would simplify the processor and also free up the D-flag.

There is actually a lot of cruft in the 65c02 that could be discarded. I already mentioned the (direct,X) addressing-mode, which almost nobody uses. There is not very much legacy 65c02 code around that anybody cares about, so strict compatibility with the 65c02 may not be very important.

BigDumbDinosaur wrote:

Quote:

This requires hardware support. USP is a lot faster than a basic UART --- but I don't know why transferring files at high-speed is needed --- my 65c02 cross-compiler had the Apple-IIc target and MS-DOS host talking at 19,200 baud, which was adequate for my purposes.

I don't know why as well. After all, a 300 baud modem worked fine with a Commodore VIC-20. BTW, I assume you mean USB, not USP.

I can't speak for others around here, but if you did as much software development as I have done you would conclude that there is no such a thing as a computer that is fast enough. I run the interface between POC and my Linux development box at 115.2Kbps and wish I could run it faster. Even gigabit Ethernet seems a bit slow at times.

Yes, I meant USB --- that was a typo.

I still don't know of any reason why transferring files in and out of a desktop computer has to be done quickly --- this is not real time --- also, the maximum memory is 16MB, so even at fairly slow speeds there isn't going to be a noticeable delay.

[GARTHWILSON]

Hugh Aguilar wrote:

With a lot of I/O it would help to have multiple interrupts. The 65c02 or 65c816 would have a problem because they only have the IRQ and NMI, so each interrupt has to poll a lot of I/O ports to figure out what tripped the interrupt. The 65VM02 has MIRQ3, MIRQ2, MIRQ1, MIRQ0, IRQ, and NMI. This is still not enough.

I think the spark timing is the only thing that has to be pretty accurate in terms of microseconds. Engine speed and load aren't going to change significantly in 10ms, let alone 10µs, so valve timing would be maintained mechanically after the computer dictates what it should be for the next so many revolutions, as would be the case for the mixture; and temperature sensors won't respond to millisecond changes anyway. I don't have any idea how quickly oxygen sensors respond. The slow stuff can all be polled, not requiring interrupts. For the ignition timing, it is critical for the computer to know the shaft position though, and some sort of resolver-to-digital converter, or shaft position sensor, would probably have to be interrupting the processor at a furious rate. A possible alternative would be that the ignition timing is taken care of in a separate circuit (possibly even a microcontroller's module that's not part of the processor itself), where the processor gives it a shaft offset angle telling it when to fire, so the processor doesn't need to "bit-bang" it. In that sense it would be like the processor sending a UART a byte and then going away to do something else while the UART takes care of the timing.

Quote:

On this subject, does anybody actually use BRK for anything?

I haven't used it since my 6502 class in 1982, and my ISRs never waste time checking for it. Some programmers have used it in multitasking operating systems though.

Quote:

There is actually a lot of cruft in the 65c02 that could be discarded. I already mentioned the (direct,X) addressing-mode, which almost nobody uses.

I use it all the time.