I need the help of a veteran programmer and mathematician for this request.

What I need, specifically, is an assembly subroutine that takes any four-digit hex number and converts it into a four-digit decimal number,using the LEAST amount of code possible. And yes, the fact that the decimal number is also four digits max means the hex number need not go over 270F in hex (9999 in decimal)

That's nothing new. There are a couple of short articles on it linked in the code page, at about the middle of http://6502.org/source/

Also remember that if you sacrifice code size, you often end up with an explosion in data size. If the algorithms linked to above do not work, you'll have no choice but to resort to table-lookup mechanisms, which may well take upwards of 2KiB just in table space alone.

My apologies-- Earlier I was just looking at new messages without regard to where they were or what the titles were. I just realized you said "816" and not "6502", and that you posted under "Forth". My answer above was not really relevant for either one.

Forth normally converts number bases in a way that is very compact codewise, using things that are already in any Forth. It uses the same method and the same code whether you want to convert base 16 to base 10 or base 7 or any other base. The numbers are normally stored and handled in hex, and you only convert to and from the other bases when it's time for non-hex I/O.

You can do this in any language. Put your desired base (10 in this case, or $0A) in a variable. Forth calls it BASE . Using the integer division routines that are already there for other uses, divide your hex number by the content of BASE and take the remainder. That's your least-significant digit. Divide the first number by the content of BASE again, and take the remainder again. That's the next digit. Loop until the number you started with becomes zero after all these integer divisions. It's not much different for non-integer work.

In Forth, if you want a numeric output string, start with your number at the top of the stack, make sure you have the desired base in BASE, and say

0 <# #S #>

(You would remove the zero if your input number is already double-precision; but you had an unsigned, single-precision integer.) This removes the number at the top of the stack and puts the address and count of the string containing the output. The <# starts the pictured numeric output string, #S adds digits right-to-left until there's nothing left of your input number, and #> finishes the string and puts the address and string length on the stack.

Or to just print it, if you're already in the desired base and have already selected the desired output device ( CONSOLE , PRINTER , COM1 , whatever ) and the hex number is at the top of the stack, just do

.

(pronounced "dot"). It does the same thing as the above plus TYPE . It takes two bytes. Is that good enough for "the least amount of code possible"?

If you need a 65816 Forth kernel, I have one, but it still needs some more organizing to make it easy for someone else to pick up and understand. This one has a lot of things beyond the basics, like interrupt and alarm service, trig, log, and square-root functions, time and calendar functions, more program structures, and tons of other things that no longer come to the top of my head since I haven't looked at it in so many years. It has hundreds of primitives, so the performance is really good for an indirect-threaded implementation. Many of the things that are normally colon definitions in other Forths are primitives in this one. That would take too much code space to do for the 6502, but on the '816, the primitive version was not only way faster than the secondary, but often was even shorter as well, and quick to write.

Garth,

I'm interested in getting a version of Forth working for the SBC-3 platform. I don't know anything about Forth, but am willing to learn.

If you can supply some basic info on how the input/output hooks into it, I might be able to make modifications to get it to work.

Since you have a 65816 version, I'd like to start with it.

Any thoughts?

Daryl

If you want to learn Forth, I strongly recommend reading Leo Brodie's "Starting Forth" first.

http://www.forth.com/starting-forth/

However, do not stop there. The proceeding text only details the mechanics of coding in Forth; the actual act of solving real problems in any programming language involves practice and acquired skill. Pay particular attention to patterns of coding practices, program structure, etc. Over time, you'll notice that, even though they might do completely different things, routine A and routine B might be structured so similarly, that you just know that some underlying principle applies to both.

These kinds of observations give rise to things such as design patterns (see http://c2.com/cgi/wiki?DesignPatternsBook), which are elements of design concentrating how abstract data types and/or objects relate to each other.

The same concept applies to coding as well -- a collection of Forth-related coding practices is contained in the book Thinking Forth, also by Leo Brodie, and also online:

http://thinking-forth.sourceforge.net/

I should point out that the patterns contained in Thinking Forth don't always apply just to Forth; many of the concepts are so general that they apply to other languages as well.

In fact, many of the practices you read about today in so-called "agile" development practices have been formalized in Thinking Forth decades before "agile" became a house-hold word. The only real recent innovation in the agile community is that of test-driven development, but TDD's practicality could come about until object-oriented programming and polymorphism became common-place and easier to use in languages. But that's OK, because you can also program iteratively using formal methods too.

In fact, all Forth programmers, to some extent, already employ formal methods in their programming without actually realizing it. The foundation for all formal verification of software, the Hoare Triple, looks like this: {P} S {Q}. This is saying two things:

1. IF condition Q is true (because we measured it, or because of some observed artifact elsewhere), when we know that the condition P must be true because of S.

2. IF condition P is true, then because of S, we know that Q must also be true.

This should be setting off alarm bells all over the place to those who code in Forth here; as Forth coders, we tend to write these kinds of things differently:

: S ( P -- Q ) ... ;

Yes, that's right, the humble stack effect notation is really a degenerate form of a Hoare Triple.

What makes formal methods "formal," of course, is their reliance upon first-order logic and its associated notation instead of single letters. For example, ANSI Forth's COUNT word has the documented effect:

( c-addr1 -- c-addr2 u )

However, this doesn't say anything truly useful: given a character address, return a character buffer. The relationship between these two entities remain unclear -- you have to read the full body of the description for COUNT to realize what's happening.

Were we to use formal notation, it'd be rewritten something kind of like this:

( caddr-1 -- caddr u, where: caddr-1 c@ u = caddr-1 isFetchable? and )

This explains to us the following:

* caddr-1 stores the character 'u'. Now, as you'll undoubtedly learn in the Starting Forth book, (caddr u) pairs are used to describe character buffers, so you'll understand that 'u' must be a length.

* caddr is 1 greater than caddr-1, and therefore, _this_ is the actual start of the character buffer. Hence, a "counted string", when stored in RAM, appears as a length byte followed by that many bytes of data.

* 0 <= u < 256 (for an 8-bit byte machine), so no buffer can exceed 255 bytes.

* We find that caddr does NOT need to be memory accessible!! For example, on a Commodore 64, $D000-$DFFF is the I/O space. Suppose we happen to store a zero-length buffer at $CFFF. COUNT will still work as expected -- it'll return a valid 0-length buffer on the stack. But, caddr will be $D000, which is pointing at I/O, not RAM.

So, in a nice, concise format, we have described the entirety of what COUNT does, and with this, we can actually prove an implementation conforms to this interface description. Once this proof has been made, the "stack effect" for the word can be taken as truth, and thus, you now can use it to reason about whatever other Forth code you've written that uses it.

Interestingly enough, some folks actually use COUNT as a means of iterating over every character in a string. According to the weakest precondition and postcondition of COUNT, this is well within its normal realm of use, even though the name COUNT implies it wasn't its intended purpose.

maybe this can help: http://www.forth.org

A little question: are you interested using forth as a o.s. or simply a language? i mean in your sbc-3...

Just a bit of a plug: If you look at the Silicon Valley's FIG pages (http://www.forth.org/svfig), you'll find that I'm giving a talk Feb 28th.

Daryl, you're a great member to have here. You are probably making things happen more than any of the rest of us right now.

The book Samuel suggested, "Starting Forth," is still kind of the standard, which is why it has been put online even though the last edition was made over 20 years ago. It is still be relevant because Forth is a rather timeless approach, and the usefulness of the book is not limited by the technology of its day. When you understand the approach (which is easy, but requires some re-molding of thought), you can carry it into newer technologies-- bigger address spaces and discs, nicer full-featured editors, better video, etc..

The book is humorous, interesting, and easy to understand. Even the photo of the author on the "About the Author" page in the front makes him look like one of those light-hearted fellows who's the life of every party-- or office. You will really enjoy the book. At least the one Samuel gave the link to has all the funny little pictures, unlike another posting of it online which did not have them, much to my disappointment. (I'm still glad I got mine back when it was still in print though!)

The next one would be "Thinking Forth" by the same author, Leo Brodie. Although it gives you more tools in your thinking processes for Forth, it's really about improving programming skills, something which can be applied to other languages as well, as Samuel mentioned.

Getting into Forth in about 1990 was a little slow for me because I had Brodie's book which kind of assumed you had something to practice on, and I had a handheld HP computer with a Forth module which had some small differences and its manual assumed you had previous Forth experience. A bit of a chicken-and-egg situation. Still, I was interested enough to get going.

Not long after, I decided to use my newfound love (Forth) at work for the automated test equipment shown in my project pages on this website. We bought a metacompiler that ran on the PC to make the Forth material that went into the target computer's EPROM. The better way to do it, if I hadn't been so green at the time, would have been to get a 6502 Forth source to assemble with an assembler, which is what my '816 Forth is. But even if you only had a really basic, small Forth in place, whether in ROM or loaded from mass storage, it can compile and assemble more and build itself up and extend itself to your heart's desire.

Wally Daniels who's on this forum has been using my '816 Forth for several years on a 65265. I doubt that all the bugs are out, but I'm not aware of any right now. Someday I really do need to finish cleaning up the documentation for distribution. The fact that I haven't finished that job is why it's not posted on this website yet. You're welcome to what I have, but it might be good to first get a free Forth to run on the PC to practice on when you read the book. The free Forth won't compare to the performance and luxuries you'll get if you buy from Forth, Inc., but I think it will make it easier to get a handle on the basics before you get into the details of the internals. Going straight to an assembly source for the kernel itself won't be easy if you hardly have any idea of what then end result is supposed to do.

I was just looking at forth.org's (not Forth, Inc.'s at forth.com) website and I see it hasn't been updated in a year and a half but I followed a link to http://www.figuk.plus.com/4thres/systems.htm which has Pygmy Forth v1.5 linked just above the middle of the page. Samuel, I think you've used that one haven't you? Would it be a good one for Daryl to start with? Or do you have another recommendation for a beginner?

Whatever route you chose, I can help you with getting your I/O going. I think you will quickly see how to do it, but it would still be good to keep checking with others. When you're new at it, you will miss a lot of really elegant but non-obvious ways to solve problems, and you'll go about them in a way that may work but is more difficult, takes you longer, runs slower, and takes more memory.

I should look at your SBC info (is it up to date on your website?) and see if I can write or modify some basic I/O words for you in a way that runs right out of the box. That would eliminate a lot of frustration on your part. I can't spend much time at it right now, but if it's mostly a matter of changing some VIA addresses and I/O bit assignments, that shouldn't take too long. What won't be quick is if I have to learn something like a new LCD or video instruction set. OTOH, if you already have assembly-language routines working for those, we can probably just make the Forth words use them. Once your display and RS-232 are working, you can use a text editor on your PC to try other things interactively and quickly get more things going.


If you have used and gotten proficient at programmable HP RPN calculators from their heyday around 1980, especially the HP-41, you're half way to Forth, since it's stack-oriented and has no punctuation. (Even things that look like punctuation in Forth are words.)


When you get into Forth, you'll see right away how to address I/O and make all the I/O words you want.

Thanks for the link!

Not knowing the in's and out's, its hard to say. It would be nice to be able to offer both. Since SBC-3 is RAM-based, either could be easily accomodated.

What would be your suggestion?

Daryl

I have used Pygmy in the past -- v1.4. Not sure how 1.5 differs.

For absolute beginners, though, this depends on your platform. If you're using Linux or BSD, I would strongly encourage the use of GForth. GForth is smart enough to configure its memory map to try to catch stray pointers (which happens a lot in Forth if you're new). It won't catch them all, but, you'll find that most illegal memory references will be caught. If you tried this same thing in Pygmy, you'll corrupt the binary in RAM, and you'll crash the DOS environment.

Be aware that the Starting Forth text online has been updated for ANSI Forth systems. In particular, iForth and SwiftForth systems are referenced. GForth is also an ANSI-compatible implementation (in fact, it is the reference implementation).

This is why I advocate GForth for learning Forth now.

For Windows systems, I probably would go with either SwiftForth or iForth, again, because the book is (re)written to those implementations.


Regarding I/O:

Under the hood, Forth's management of I/O will be unique for every Forth system you use. Adapting Garth's Forth to the SBC-3 will prove a unique experience from, say, porting pForth. It has to be, for there is never one way to accomplish I/O, and each Forth system has its own assumptions.

In this regard, Forth is like C -- it lacks any language-defined I/O or memory management primitives. ANSI's attempts to standardize the core wordset comes from a desire for a standard library of words. It's best to think of ANSI's Forth definition as though it were Forth's equivalent to the standard C library. It's incomplete, sometimes limiting, and so obviously designed by committee. But, it exists, it's portable within reason (even to CPUs which lacks a hardware return stack, much to my consternation), and it's provided Forth with a new level of respect in the industry (which isn't saying much, but . . .).

Thanks for all the suggestions and resources. I'll take some time to digest it. I have a lot of projects on my plate so this one may get put on hold for a while.

My website is up to date. The SBC-3 I/O is located in two of the source files. the SPI.asm has the keyboard routines and RS-232 routines. The text.asm had the display commands. Memory assignments are in the sbcos.asm file. I am still using TASS to assemble the files. I created a macros.inc that holds all of the 65816 commands. The dis-assembly looks a little odd in places because of the macros, but it does compile correctly.

Back to work on the SPI interface for now....

Daryl

i'm not sure i'm the right person to give you suggestions, maybe i can write down my thought: forth is a system not just a language, and please remember that it's only an opinion.
it's possible to encapsulate the language in a single call, but like other "languages" like java, forth require a rich memory map and lanch-and-hope control.
As i write in other post, i love forth, so please dont misunderstand me.
i'm trying to make a port in c# (god forgive me!) of the original fig-forth lang, but my actual approach is to build an memory area where the forth words plays...not like an emulator but not so far: few hard coded words and lot of f-code.
so, i think that in a sbc, the simplest and quick way is a forth that boot and take the full control as like as an o.s.
i really wanna know other opinion about that because i dont know other more forth modern approach.

Modern Forth systems are languages that run under host OS environments. However, nothing in ANSI explicitly forbids modern Forth systems from subsuming the role of an operating system either. It's an implementation detail.

Makes sense, but I think you would still do well to get a free Forth to toy with on the PC while reading the book for stack operations, defining words, making decisions, looping, variables, strings, etc.. When you decide it's time, we should probably talk on the phone so I can understand a few things about your drivers and stuff better (and quickly!), and then it would be good if you could loan me a working system so I can put the Forth on it and get it going, then give you the files modified for your particular I/O (which primarily means the 816HDWR.ASM INCLude file and the accompanying 816HDWR.FTH which is kind of a shadow file that just shows the more-readable Forth version of the assembler source in the .ASM file). It would dramatically increase the chance of success if I can give it the time to make the system such that anyone can get immediate results. I've kind of wanted to do that for a long time, and now you have the hardware for sale and you're interested in the Forth as well. How much free ROM space do you have left?


SwiftForth is $400, and iForth is €100. I have no doubt they will be better than the free ones, but my idea here was just to start getting your feet wet with the basics, which I was hoping you would be able to do with GForth or Pygmy Forth if you don't want to spend the money.