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
65c816 help
-
GARTHWILSON
- Forum Moderator
- Posts: 8773
- Joined: 30 Aug 2002
- Location: Southern California
- Contact:
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.
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.
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.
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.