I think a reasonable game-machine could be built out of the PIC24FJ256DA210.
It is designed to be a business machine with a 640x480 display, but it also has a 480x272 display that seems more appropriate for games --- it doesn't have sprites, but I wasn't enthusiastic about sprites anyway because the games tend to all look alike because they all involve a few objects chasing each other around in flatland (Ms. Pacman and the ghosts, for example) --- a 32 Mhz. PIC24 has enough horsepower to repaint the entire frame-buffer on every heart-beat, and given no rules for how this is done there is plenty of opportunity for creativity in what the game looks like.

The PIC chip provides a lot of features, such as all the video support, ADC for voice synthesis, USB for program development, etc.. It would be pretty much a single-chip board --- build the board for $20 and sell it for $200 --- should have more that 5 customers pretty soon...

If anybody wants to work with me on this, send me a PM.

I notice a lot of things! One of the things that I have noticed is that you posted non-working code. The Forth data-stack is 16-bit, not 8-bit, so you need two INX and two DEX.

I also notice that you aren't considering using OSX to allow the (offset,S),Y addressing-mode to be used with X rather than S, which would be useful for cases in which a pointer to a struct is on the data-stack.


If I was going to "map some dedicated stack hardware into DP" then I would be making a major modification to the 65c816. If I'm building a new processor, I would use the TOYF that I designed to support Forth.


To be blunt, I don't think you have a positive contribution to make to Forth --- you are driven by arrogance and informed by ignorance --- I recommend that you just stick with C; you can continue to toss vague insults at Forth by saying that it "operates in a strange manner," and all of your fellow C programmers will applaud your genius, or at least your loyalty.

OK, let's not attack people - it's sufficient to criticise ideas. If you just can't agree with someone, ignore them. A stream of rebuttals and counter-rebuttals is not productive, and degrades the forum for everyone.

I've seen some example code from Garth's 65c816 Forth, and it would likely be an order of magnitude slower than C code --- that is too slow to bother with --- he is using ITC (indirect-threaded-code) that has the advantage of being very compact (in the 1970s when Charles Moore invented ITC, a micro-controller might have only a 2KB EPROM), but it is not appropriate for the 65c816 that likely has 64KB of code memory and 64KB or more of RAM. STC is a lot more efficient, especially with peephole-optimization, but the 65c816 needs better support for using the X register as a data-stack pointer.

Speed is not necessarily required for micro-controller applications, so Garth's ITC Forth could still be useful. By many accounts, the most important feature of Forth is interactive development. You can execute code from the command-line and get immediate response. You can write short test functions on the command-line and execute them immediately. This is very useful! In most cases, a board doesn't do what the electrical engineer says that it does. This is because the hardware design is bad, the electrical technician built a bad board, or because of environmental issues such as EM pollution. From the command-line, it is possible to test the board and find out what it does. This is done before the program is written. Also, I have seen many cases in which the electrical technician has a test suite of Forth functions that he or she uses to test the boards after building them --- he or she is not actually a Forth programmer, but just knows enough about Forth to use the test functions on the command-line (there are actually more women than men doing this, probably because they have a lighter touch on the soldering iron than your typical ham-handed man).

Anyway, it is a straw-man argument to say that a 65c816 Forth is faster than a 65c02 Forth, because I never said otherwise. Obviously, if you have 16-bit registers then that is going to be faster than 8-bit registers.

My point is that the 65c816 is not fast enough. It is a bad design. William Mensch was opposed to using prebytes, such as are used on the MC6809, but the result was that his ISA is too redundant and has too many missing features.
If you have an OSX prebyte to switch S and X in the next instruction, then you can get rid of the offset,S addressing-mode because it is redundant to the offset,X addressing-mode. You can also get rid of the (offset,S),Y addressing-mode and replace it with a (offset,X),Y addressing-mode that could be used for S instead of X with an OSX prebyte (this would not only support Forth, but would support arrays of pointers to structs in zero-page).
Also, if you have an OAY prebyte to switch A and Y in the next instruction, then all of the instructions (ADC, EOR, etc.) that use A and a memory value can use Y and a memory value also.
If he didn't have so much redundancy in the ISA, he would have had more room in the 256-opcode space to add more instructions. For example, he could have added a Y addressing-mode so the instructions that use A and a memory value could use A and Y instead. This would be a kind of inherent addressing-mode as there would be no operand, and it would be quite fast --- normally the result would end up in A, but given the OAY prebyte the result could end up in Y.

I liked the 65c02. I wrote a Forth cross-compiler that ran under MS-DOS UR/Forth and generated code for the Apple-IIc (I actually had a Laser-128). This was compatible with ISYS Forth that ran on the Apple-IIc. This generated faster code than any C or Pascal compiler of the day --- I doubt that it would generate faster code than Walter Bank's 65c02 C compiler --- but for its time period, it was quite efficient.
I used my cross-compiler to write a program to do symbolic math. My program could do derivatives of equations and then simplify the results. My program could also plot functions on the graphics screen and display equations using math symbols and Greek letters. My goal was to do integrals, but I found that to be beyond the capabilities of the 65c02 --- I had really pushed the capabilities of the 65c02 quite a lot already.
The 6502 does have some bad features (for example, INC and DEC should set the CF the same as ADC or SBC do). For the most part though, the 6502 was a good design --- the (zp),Y addressing-mode was pretty awesome.

Nowadays I think the 65c02 is obsolete. The 65c02 is designed for big programs (such as my symbolic-math program). It has the (zp),Y addressing-mode that provides good access to big data-structures. Nobody wants to use an 8-bit processor for big programs now though. People use 16-bit or 32-bit processors for big programs now.

In its day, the 6502 was better than the Z80 for big programs because (zp),Y provided better access to data-structures. The 6502 was better than the Z80 for small micro-controller programs too, because the 6502 had less interrupt-latency due to having only a few 8-bit registers to save/restore.
Both the 6502 and the Z80 were obsoleted by the MC6809 though, and the MC6809 was obsoleted by the MC68000-family, and the MC68000-family was obsoleted by the ARM --- the ARM Cortex dominates now, and will likely to continue doing so all the way through the 21st century (it is more than powerful enough for any micro-controller application) --- nobody is going to be interested in an 8-bit game-machine now.

People still use 8-bit processors for small micro-controller programs. The 8051-family has been popular for three decades, and continues to be popular. The STM8 is gaining some steam. I designed my 65ISR for small micro-controller programs. It should be significantly easier to program than the 8051-family, that lacks an indexed addressing-mode. It should be more efficient than the STM8 because the STM8 gets bogged down in entrance and exit code for ISRs --- the 65ISR (as the name indicates) is intended to have very little interrupt latency (it has less than the 65c02, and low interrupt-latency was always the hallmark of the 65c02).


It is obvious that William Mensch wanted to support C programming, so he added the offset,S and (offset,S),Y addressing-modes, but he was failing to support Forth.

If he doesn't want to support Forth, then I don't want to support his 65c816.

The 65c816 ISA was designed to support C, so supporting Forth is going to require contorted programming. I would do that if I was getting paid --- I'll do most anything for money, so long as it is not immoral or illegal, and I'm totally okay with implementing bad ideas --- do you want to hire me to write a Forth for the 65c816?
You've already said on this forum that you will never be convinced that Forth has any value, so I'm expecting that you are not going to hire me --- you don't actually believe what you said: "a well-written Forth kernel tends to be quite efficient (efficiency being one of the hallmarks of Forth)"

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

While that may be mostly true (one man's obsolete is another man's perfect fit), you are on a 6502 forum, so it would be nice to get just a little love for it.

Imma stop you right there.

In general computing the 68000 was obsoleted by the x86. In embedded systems it was obsoleted by the PowerPC (the 68360 and CPU32 cores lived a long life... with CPU32 cores still available from NXP). After doing modestly in the 90s as a rival to Atari STs, Amigas and early IBM PC clones, Acorn's Archimedes line (for which the Acorn RISC Machine - the ARM - was developed) quietly died... pretty much taking the company with it. As I recall it was actually Apple, with their Newton handheld that directed them towards selling the ARM, with its excellent power profile, into embedded systems. Now ARM is everywhere, as you say, but they still haven't made inroads into servers and desktops - though they keep trying (e.g. with ARMv8 cores). ARM cores are pretty expensive to license, and now I wonder if RISC V (the new kid of the block, and a response to high licensing fees) is going to eventually take them down. ARM is so entrenched, I suspect that will take decades, though (just like the CPU32 cores are still available and, no doubt, in use by those same "perfect fit" people).

The question wasn't to me, but FYI if I wanted a Forth on any system, I'd want to hire a language expert.

If you look at the list of top programming languages (https://www.tiobe.com/tiobe-index/ being one such example) you'll see (unordered) C, C++, C#, Java, Javascript, Python, VisualBASIC, Go, Perl, etc. These are the relevant languages of modern times. Forth has some niche use-cases, but it's uncommon, and I think it's a stretch to ask for people to adopt your pet language.

If you proceed with your PIC idea then the best of luck to you. It does look like a capable little chip.

Bit of a digression here, but this thread seems to be digression city...



I think there might be two, or even three, halves to that story. AIUI, ARM was spun out from Acorn at the time of the Newton, because Apple wanted their CPU supplier not to be a direct competitor in the computer market. But then Steve Furber tells the story that Robin Saxby was anxious to find a way out from under its owners - it couldn't grow a commodity business and become self-sufficient with Apple and Acorn demanding all their technical attention. And that's where the licensing model came in, giving the cashflow to become more effectively independent (the power to say no).

The third half of the story is that Apple was able to keep itself afloat when in deep trouble by selling a massive tranche of ARM shares, even at a loss, to generate cash. Maybe in 1998. So Apple helped ARM get started, and some years later got a life-saver from that:


- from Cult of Mac although Hauser is quoted as saying Sculley did this, whereas here we read that it was Jobs.

Thanks for those details and for the links. I hadn't heard any of that before! Fascinating.

You keep saying this, but it's simply not true. Most arcade machines up to the 3d era were sprite based, and pulled off ridiculously varied and high quality graphics. The SNES and NeoGeo games didn't look all alike (except when the genre called for it). Only the earliest of games just used singular sprites for little rectangles running around the screen.

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

That is a subjective opinion that (to me) has no basis in fact. Whose yardstick (or meter stick) was used to determine that Garth's 65C802 code would likely be an order of magnitude slower than C code?


No straw man argument was made in that regard. I was speculating. As I am not a Forth user, I can only speculate on relative performance. It is you who is expressing opinions about the slowness of Forth running on an '816.


The 65C816 is "not fast enough" for what? It was certainly "fast enough" for the Apple ][gs, in which had it been clocked as fast as the production 65C816 of the time could go, would have made the MacIntosh not look so good.


In what respect and compared to what?


How do you know what Bill Mensch was opposed to? The 65C816 design evolved as it did due to Apple's requirements that it be able to execute 65C02 code without alteration. This was in addition to the native mode features that were designed in to support what Apple wanted to accomplish with the ][gs. Had Mensch elected to use prefix bytes, as you advocate, the backward compatibility demanded by Apple would not been possible. Looking back at it, Mensch's design cleverly maintained the clarity and efficiency of the 65C02 ISA, all the while offering 16 bit performance, broader stack management and greater memory addressing range.


Noted.


Yet the 65C02 continues on in the present day in huge volumes. That doesn't sound "obsolete" to me.


Actually, it is neither obvious or true. The 65xx architecture predates K&R C by several years and at the time Bill Mensch commenced with the 65C816 design (c. 1982), C was not all that well known outside the UNIX world. While it is likely Bill Mensch knew about C, there would not have been any logical reason to try to change the 65xx ISA to support that specific language, especially considering there was no official language standard at the time (nor would there be until 1989).


Bill Mensch is a designer of general purpose microprocessors, not a software engineer. By definition, a general purpose microprocessor is not tied to a language or operating environment. Support for any language is the job of compiler and interpreter designers, not hardware engineers.


Repeating that won't make it true.


No, thanks.


I don't recall ever saying Forth has no value. It has no value to me in my professional and hobby computing activities, but patently has value to others.

As for my comment about a Forth kernel's efficiency, yes I do believe what I wrote—I otherwise would not have written it. Properly written Forth kernels tend to be economical with machine resources, which is what defines efficiency at the hardware level. In that regard, Forth is no different than any other operating environment, even one as primitive as a machine language monitor.

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

Yes, I now vaguely recall that from long ago. There was a write-up on it in the Wall Street Journal, along with some alarmist speculation that Apple was about to close up shop. It was from the time when PC technology was rapidly catching up with the Motorola 68K machines and the future of the 68K in desktop computing was starting to look bleak. That had to be scary to Apple, given the huge investment they had in the Mac.

Interestingly, it was also around that time that the proprietary minicomputer market was starting to crumble from the onslaught of RISC machines, as well as the realization that the 80386/80486 could efficiently run a genuine UNIX kernel in protected mode. Most of those soon-to-be-obsolete minicomputers were powered by the 68K.

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

Hugh, i think still think you need to lay out some more design goals for this project. Most of what you respond is negative about other ideas, but we're left scratching our heads as to what direction you're actually striving for. As a game machine, what sort of sample game idea, given some sort of sample hardware & software architecture it could take advantage of, would exemplify your ideal?

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

In some ways I'm inclined to agree with Hugh. Certainly Michael's M65c02A sets a very high standard for Forth performance, and it'll trounce an '816 running Garth's Forth.

Yes, compact. Which goes hand in hand with being slow. And, as noted, 2KB EPROM's are a thing of the past. Can we agree it's alright to look at slightly bulkier alternatives?

You mentioned Forth using STC (subroutine threaded code), which indeed is quite a lot faster than ITC. I don't understand your comment about the '816 needing better support for X as a data-stack pointer (for the most part I find it adequate). Be that as it may, there's at least one other fast alternative -- namely, Forth that uses DTC (direct-threaded-code).

I guess I'm saying we need more points of comparison than just sluggish ITC vs M65c02A, which are at opposite extremes, performance-wise.

-- Jeff

ETA: when I say "at opposite extremes," I mean within the context of various Forths -- all of which tend to be remarkably performant, even the comparatively slow ones. Garth's ITC application illustrates this.

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

If the 65816 was responding to desires by Apple, then C support certainly wasn't a criteria, notably since Apple was heavily invested in Pascal back then. Pascal was manifest as both native Pascal compilers (used by the Lisa, Macintosh, and IIGS), as well as the UCSD Pascal Runtime running on the Apple ][ series. The '816 would have been a pretty good target for the P-Machine.

Now, stack addressability is a pretty common technique in most scoped high level languages. Pascal was notable for its multiple, nested scopes (something C does not have).

The 6502 was a pretty good Forth processor, not sure why the '816 would have been crippled by running Forth. All of the languages would have had to fight the 16b/24b addressing nature of the machine. 8086 faced the same problem, but the 8086 relied on a 16bit segment register vs '816 8 bit bank register. But I don't know how much that would have really mattered in practice.

The Z80 has several prefix bytes. Similarly, there are several articles about how you can do the things that the prefix byte instructions do -- without using the prefix byte instructions to save time and cycles. Not sure how much of a fan base prefix bytes really have in the Z80 community.

Finally, contrasting something like the M65c02A, something made with 40 years hindsight and modern tools for simulation compared to the '816 which had work started probably about 5 years after the 6502, is a bit unfair. I don't know much about the M65c02A, but what kind of transistor budget would it require in contrast to the '816, which along with 6502 interoperability no doubt loomed over many design decisions.

Something that really helps in discussions such as these, I think, to avoid them becoming heated and becoming an expanding tree of point-by-point rebuttals, is to phrase controversial opinions as opinions. No-one minds anyone finding some particular piece of hardware or software not to be elegant, or useful, or ideal, but you'll often find someone with the opposite view. Saying that something is so, as if it were a truth universally acknowledged, just brings argument. In my opinion.

The other thing that's worth being careful about is throwing in every observation that comes to you: if you raise five points in a post, you might get five responses, and if those are not on-topic, you've got a sprawling thread on your hands. It's very cheap and easy to start a new topic, and if when doing that you find your nugget of wisdom doesn't quite hold up as a new thread, well, you know what to do.

Having said that... about the 65816. Two observations, if I may: it was made with very limited resources, and it was to be backward compatible. In that situation, if the thing ever comes to market, I think you'll find it won't contain every feature which might have been useful.