65c816 help

[kc5tja]

GARTHWILSON wrote:

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?

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

[8BIT]

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

[ptorric]

8BIT wrote:

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

[kc5tja]

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.

[GARTHWILSON]

Quote:

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.

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?

Quote:

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

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.

[8BIT]

The IO (including text generation, SPI keyboard and RS-232, and xmodem transfer, takes under 5K. There is 27K open. Alternatively, since the memory is all RAM, the Forth code could be downloaded from a PC or eventually the IDE interface, without the boot ROM's size restriction.

I have just the one assembled SBC-3. I have two unclaimed boards left, and may choose to build them and sell them assembled and tested. If so, I would be able to send you one as a loaner. Time will tell. I was considering modifying my Simulator to support the SBC-3 model. If I can do that, then development would be much easier.

So much to do....

Daryl

[GARTHWILSON]

27K is definitely enough for a Forth with a lot of nice features that aren't found in the other free ones (or even some rather expensive ones). If it's in ROM, some people (like myself) would just leave that EPROM in there all the time, so it's there without loading, like the BASIC was on the C64. When I want to try something in assembly, I just use the assembler that's part of my Forth.

I would probably just take advantage of entry points in your pre-written display and RS-232-sending routines, making only minor DP RAM-address changes to them if necessary for Forth's DP use. Other pre-written things that use interrupts, like RS-232 reception and maybe the keyboard, may need minor modification to integrate them with Forth's interrupt service. It is possible to make an assembly-language ISR transfer into high-level Forth if desired in order to report an error condition to the user and give him choices as to how to correct it. Those things are easier to do if you don't have to do them in assembly. If the user wants to change how any of this works, he'll have the full source code to do with as he pleases. The ISRs (interrupt-service routines) can be loaded at start-up and then changed by the user if he wishes, even if they're in ROM-- not that he will change the ROM itself, but rather that he can de-activate ISRs, change their priority, re-direct them, etc., on the fly with pointers that are kept in an array in RAM. The Forth words to do this easily are included.

[kc5tja]

GARTHWILSON wrote:

Quote:

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

SwiftForth is $400, and iForth is €100.

SwiftForth is available as a free download. It will lack the source code and other useful libraries, but should be plenty sufficient to learn from:

http://www.forth.com/swiftforth/trial-system.html

iForth used to have a free evaluation download. However, I no longer see the link.

If you want neither Swift nor iForth, then I'd try to find a Win32 distribution of gforth.

However, again, remember that ANSI's specifications only covers so much. Ultimately, something in Starting Forth will differ from the ANSI spec, and that's why I encourage using an environment as close as possible to what's listed in the book.

Like I'd said earlier, ANSI Forth is somewhat similar to ANSI C in this regard. People looking to learn C today rarely do so with the expectation that they'll use a VT-100 terminal to access a mainframe; yet, that's about all the standard C libraries cover. The more advanced exploitations of C are rarely considered "standard" (e.g., writing COM objects in C, command-line parsing for DOS or Unix shell commands, etc.), and often requires specific compilers (e.g., each compiler has a unique inline assembly syntax, and its own flavor of the standard C libraries often with embellished interfaces). This is such a problem, in fact, that most open-source tools must explicitly be "pre-configured" via a packaged configure script. It's not uncommon for the configure script to exceed the compiled program in length!

Knowledge can be transferred, of course; you just have to be observant, but that requires experience, which I'm not assuming the reader has yet. Everything I've said above applies to different Forth implementations too. This is why I advocate sticking with SwiftForth if the book he's following is also written with SwiftForth users in mind.