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).

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

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.

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

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!

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

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.

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

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.


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.

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

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.


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.

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

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.

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

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.


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.


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.

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