Live data from Hacker News

Robot Game: Comparing 6502 C, Assembly, and Forth

calc6502.com

11–20 of 37 posts

Re: Robot Game: Comparing 6502 C, Assembly, and Forth

#11
post #4

Unfortunately, it seems that for all practical purposes, and as much as we love it, 6502 in all its (still existing) incarnations is all but dead.Even MIPS has been dying, albeit slowly and painfully. The unpleasant truth is that as we now all know that ARM is currently the only sane choice for a hobbyist project (see, for example, Color Maximite 2), and we can only hope that RISC-V will someday replace it in the han…

"What is sane for a hobbyist project" depends on the project and the wills of the designer.

I've built a couple of 6502 based systems now and added VGA output and floppy support which probably would've been easier with an ESP32 or something but my goal was to learn how to do this the hard way.

Re: Robot Game: Comparing 6502 C, Assembly, and Forth

#12
post #9

Earlier quoted context omitted.

I think the writer use case takes no benefit from Forth. He already has some code and is trying to translate and optimize it. In this case, none of the advantages of Forth matter because he is not doing the development interactively. He was also tied to an existing code architecture that is alien to Forth. A Forth programmer starting from scratch would certainly design things in a way that makes more sense to Forth.…

OP here. This is a really interesting point. My strategy was to keep the highest level functions/words like DrawTile or DrawMenu while writing the underlying Forth and subwords from scratch focusing on performance. Do you have any suggestions that would make "more sense to Forth" as you say?

Not the GP, but I'd recommend the latest edition of _Thinking Forth_[0]; there's a PDF but the soft-cover is worth picking up. It helped change the way I think about Forth (hah), and really, programming in general.

[0] - http://thinking-forth.sourceforge.net/

Re: Robot Game: Comparing 6502 C, Assembly, and Forth

#13
post #4

Unfortunately, it seems that for all practical purposes, and as much as we love it, 6502 in all its (still existing) incarnations is all but dead.Even MIPS has been dying, albeit slowly and painfully. The unpleasant truth is that as we now all know that ARM is currently the only sane choice for a hobbyist project (see, for example, Color Maximite 2), and we can only hope that RISC-V will someday replace it in the han…

I suppose it depends on the kind of hobbyist. If you want to learn how to code for the 6502, for nostalgia's sake -- a powerful motivator for many hobbyists -- then learning to code for ARM will not scratch that itch.

You can always emulate the 6502, it doesn't have to be the real hardware.

Re: Robot Game: Comparing 6502 C, Assembly, and Forth

#14

Earlier quoted context omitted.

Yes, FORTH is an elegant alternative to BASIC on very small systems, not something you should expect high performance from.

To mirror asguy's comment, this only tells us about the performance of this particular FORTH engine, it doesn't tell us about the performance inherit to FORTH (which of course doesn't exist, it's down to the engine). Whether anyone has made a sophisticated optimising FORTH for 6502, I don't know.

>this only tells us about the performance of this particular FORTH engine

Yes, exactly. Whatever its other qualities may be, I suspect this particular Forth has overlooked some pretty obvious low hanging fruit, performance-wise. In this[1] post we learn that LOOP puts a 1 on the stack then falls into +LOOP. Although there's elegance (and a memory saving) to that approach, I'm startled that they didn't provide a dedicated definition for LOOP instead. AIUI, implementing LOOP as an instance of +LOOP substantially and needlessly increases the complexity of what gets executed. Yes, I know premature optimization should be viewed with suspicion, but if profiling were performed it's hard to believe LOOP wouldn't be a hot spot! So, I constructively suggest that in this respect at least (and perhaps there are others) this Forth engine could benefit from some tuning up.

[1] http://forum.6502.org/viewtopic.php?p=76849#p76849

Re: Robot Game: Comparing 6502 C, Assembly, and Forth

#15
The 6502 is still doing hundreds of millions of units a year, and is still a terrific introductory processor that is comparatively easy to wrap your head around, especially if you are interested in board bring up from scratch. (Compare the requirements to boot a 68000 to a 6502 into a nop loop, for example.)

The 6502 is far from dead.

Re: Robot Game: Comparing 6502 C, Assembly, and Forth

#16

The 6502 is still doing hundreds of millions of units a year, and is still a terrific introductory processor that is comparatively easy to wrap your head around, especially if you are interested in board bring up from scratch. (Compare the requirements to boot a 68000 to a 6502 into a nop loop, for example.) The 6502 is far from dead.

Glad to hear it! I first learned assembly for 6502 on the Apple ][, and found it indeed easy to wrap my head around. Great machine, great architecture, TED II Editor/assembler was amazing...

Re: Robot Game: Comparing 6502 C, Assembly, and Forth

#17
post #4

Unfortunately, it seems that for all practical purposes, and as much as we love it, 6502 in all its (still existing) incarnations is all but dead.Even MIPS has been dying, albeit slowly and painfully. The unpleasant truth is that as we now all know that ARM is currently the only sane choice for a hobbyist project (see, for example, Color Maximite 2), and we can only hope that RISC-V will someday replace it in the han…

A big part of the appeal of the 6502 is with the retro community. If your goal is write an NES game (and there’s quite an active community doing just that) then you have no other choice than to learn the 6502.

That’s fine though. The 6502 is a classic CISC processor with a fairly high level instruction set. This makes it fun for humans to program. I think where people get into trouble is when they try to bring up these complicated tool chains and high level languages. That’s a mistake. Program the 6502 directly in assembly with a nice macro assembler. It’s the best way to go.

Re: Robot Game: Comparing 6502 C, Assembly, and Forth

#18
It's kind of a funny coincidence that I also wrote a very similar looking game which I also called "Robot Game" at some point, and I also rewrote it at multiple points in time in different languages:

* Starting in Visual Basic 3 in 1999 (http://www.az2000.de/projects/robot/),

* then later in Object Pascal / Lazarus in 2006 (http://www.az2000.de/projects/robot2/),

* and recently in Python in 2017 (https://github.com/albertz/PyOverheadGame).

Re: Robot Game: Comparing 6502 C, Assembly, and Forth

#19
> This brings us to one of the main shortcomings of Forth. If you need to access more than three local variables at once (in the body of a loop for example) there is just no convenient way to do so. [...] Consider the variables used in this C function that draws 1 bit-per-pixel images with optional rounded corners: > int DrawTile1bpp

Looking at the C version, the argument "tile" is used once in the function, to get the pointer to the tile. The pointer could be passed directly: one less local. x and y are passed only to calculate an address, this address could be passed directly - there are only three calls to this function, it might be worth the DRY exception.

t0 seems to be always 0, except when it is undefined.

The t_height, t_with are just offsets in the tile structure. This locals can go away too - probably eating the cost of fetching them each time is more effective than the cost of all the stack juggling done to avoid it. This reminds me a word from a Chess great master: "don't waste time trying to save one".

trans_row only exists to set skip_pixel, it seems one of them can go away. The logic seems to be "unless trans_row and something, do something". The C version might actually be more verbose than necessary.

Finally, the edge_style complicates a lot the logic. Using one function to do different things because it is so simple to "just add another parameter" is typical in many HLL, and often result in awful spaghetti code.

What a Forth programmer would do is to write one function for each edge style and see what the have in common. More often than not, they share a lot of subwords, so that having one function for each case is not more expensive than one function for all cases.

I suggest doing that with the C version and see what happens.

> Without parenthesis or commas, there is no way to tell just by looking at the code which of those are functions, which ones are variables, which of them are inputs to the others, or what any of them return. Forth fans will say that that information is available in the stack comment for the word's declaration, but that assumes that the programmer bothered to create one. Even if they did, you have to search in several places in the file to figure out what is instantly obvious if the same code were written in a language like C or Python. It's easy to see why people criticize Forth for being "write only." If you translated the line above into C, it could be doing any of the following:

Actually even in C some follow certain naming conventions - like #defines being all caps, member things being prefixed by m_, etc. And you can do that in Forth too. Once again, "write only" has more to do with the author than wit the language.

Re: Robot Game: Comparing 6502 C, Assembly, and Forth

#20
post #9

Earlier quoted context omitted.

I think the writer use case takes no benefit from Forth. He already has some code and is trying to translate and optimize it. In this case, none of the advantages of Forth matter because he is not doing the development interactively. He was also tied to an existing code architecture that is alien to Forth. A Forth programmer starting from scratch would certainly design things in a way that makes more sense to Forth.…

OP here. This is a really interesting point. My strategy was to keep the highest level functions/words like DrawTile or DrawMenu while writing the underlying Forth and subwords from scratch focusing on performance. Do you have any suggestions that would make "more sense to Forth" as you say?

Although it does not directly help, it gives the general idea:

http://www.ultratechnology.com/levels.htm

Post reply on HN