6502.org

New Guy here, from Canada no less. Anyways thank you to Garth for giving me the webforum link, I have been reading a lot of the postings. I however never used a 6502, as I mainly have used Atmel AVR's.

This project is based on the Atmel AVR's but I hope its acceptable that I post it here with my introduction.

I was (key word) going to design a hand held calculator, but after talking to Garth, looking over this site, and stuff. I decided I am going to pull a "HP" on my calculator project. Design a capable workbench solution, then downsize its available expansion for the hand held version (similar to the HP-67 Hand held and HP-97 Desktop calculators). So cause of this I am going to focus on the desktop version first.

My Central Processor will be a ATmega644PV (64Kb Flash, 40DIP socket) with the following tied to it using I2C:

• uM-FPU v3.1 Math Co-Processor (supports 32-Bit Floating Point Math)
• 4Mb EEPROM (4x 24AA1025)
• DS1307 Real Time Clock IC
• ATmega16 (to run all the graphics for a 128x64 LCD)
• AT90S8515 (Keyboard Controller for Calculator pad & Alpha Pad)
• ATmega644PV (Runs the System Bus)

The Purpose of a dedicated system bus chip is the fact I will be able to have the program code on the main chip running just the Interpreter and Human Interface software. While the System Bus chip worries about how to handle the expansion cards in the system.

CPU wishes to check for new media on FDD -> Page to SysBus for Storage -> SysBus page to Expansion cards for Storage -> Storage Units responds -> SysBus Pages back to CPU "Storage Found" and the details of the storage.

The expansion cards will run on the SPI interface, to keep things simple with a unique talk protocol to handle the kind of requests I want in my little system. The Expansion cards will all have a ATtiny88 as its interface with the SysBus so I don't have to worry about the rest of the card's interface being compatible with the unique SPI bus, just interface it with the ATtiny88's I2C or strictly parallel connector.

So far I know I am going to build a IEEE-488/HP-IB interface card, where the ATtiny will also hold all the functions to access the test equipment again without the CPU being involved. And a Floppy Drive Unit, how I am going to implement that just yet I am not sure, but over time I will figure it out. This project over all has a large time frame as I am back in college and it will be a part time project. However I hope to have it completely done by the end of April of 2011 (end of my 2nd year).

By the way if you wish this is my website: www.northerndtool.com ... mainly mechanical as that is what I am good at (Went to college for Tool & Die), electronics are a side hobby I've been into.

Dimitri

New guy, with no 6502 experience?... But Atmel AVR experience?... I say welcome aboard!
Daryl here and others have interfaced the 6502 to Atmel products. You will learn alot, and hopefully teach others too... There's good people here.

Awk! One of those Canadian dudes who no doubt cheered when the USA lost the gold medal hockey skirmish. Welcome aboard.
You don't know what you're missing. There's no shortage of 65xx-ish stuff around here. Soon you will be designing something that uses the one true microprocessor. Of course, my personal recommendation is you go with the W65C816S. Think of it as a 6502 on steroids.

working out on an AVR these days....prefer my 65C02 soooo much better...

C is one wierd assed language...

///old school

Already learned a lot browsing the boards. Thinking my project will take longer then I planned now.
You know, I was cheering, however I must tell you I root for the Vikings during the other (NFL) season.
I am thinking about it, due to reading up on the forums, and reading up on the STD Bus that Garth mentioned to me has made me think the best way to implement it is using a real microprocessor and not a micro controller. Yes I was reading up on the STD-80 bus instead of paying attention at college today.

However still in debate, a new STD back plane board seem to be expensive. May decide to implement a "STD-μC" system, doesn't exist yet, but I still have been thinking about it. Depends on how easy I feel it will be to use a 6502 on a microcontroller based I/O card system. Plus I must admit I've always been a "Write the code quickly in C, assemble the board, and watch it work" type, I honestly learned more about the underlaying computer hardware reading this board then I knew before. Sure I have been building great PC's for years, but thats assembling purchased components not really needing to know the hardware underneath.
I learned C first, so I kinda get it. I honestly learned Basic on a IBM PCjr. That was a fun experience, using a then 20 year old computer which was 5 years older then me (I'm only 22 now).

Dimitri

Thank you Garth.

Reason its going to take more time is cause of instead a one board solution I was thinking a multiboard approach. All the core functions will be on one board, the I/O will be on the other cards. Plus I want to check out the viability of using a real microprocessor with time with the system to learn more about the underlying hardware in a mC or computer.

Reading the STD-80 interface books I downloaded I got a few ideas for a "STD-μC" type of expansion. That will allow me to keep the same basic system while allowing me to upgrade/replace smaller units, instead of a whole board.

So on that thought, I am thinking something similar but not quite STD.

• Pins 1-4 - 5V Supply and ground. (same as STD)
• Pins 7-14 - Parrellel Data bus. (same as STD)
• Pins 15-29 Odd - 8 bit Address Bus. (same as STD)
• Pins 16-30 Even - Data Bus 2. (STD A8 to A15 same pins but D8 to D15)
• Pins 31-38 - SPI Slave Select (up to 8 cards in order ie card slot 1 is pin 31)
• Pins 43-44 - Slave to Master interrupt handling. (same as STD)
• Pins 47-48 - Resets. (same as STD)
• Pins 49-51 - SPI Bus. (49 Clock, 50 MISO, 51 MOSI)
• Pins 53-56 - +/-12V and GND (same as STD)

Highlights of the system

• Data Bus 2 can be used to transfer data to all graphics cards regardless of bus addressing, such as having a RCA video and a LCD controller for a built in LCD. Using generic commands both can output without the need for CPU to give specifics on output.
• Data Bus 1 and the address bus to access stuff in a more "standard" way.
• Interrupt Handling for the slaves/secondary master to request use of the bus.
• A built in SPI bus to serially access the expansion cards.
• The SysBus controller would on reset ask for all the expansion cards to over the SPI line send the labels of all board commands available to it to store with is address, then check for any parallel based cards. So when the user commands the CPU to do something not on the CPU board and the CPU asks the SysBus controller it knows what card to command before hand.
• All code will be platform non-specific as no knowledge of the other hardware would be needed by the user or the CPU. Just like a HP-41 using labels to access pre-built in or pre-programmed functions.

Dimitri

As a monstrously huge Forth proponent (folks at work are now starting to poke fun at me for it), I often hear things like this from other Forth folks, but nobody ever explains why this is.

However, developing bug-free code 10x as fast is not a Forth-only thing. You can do it in C too. I've done it.

The secret is test-driven development, a more modern version of the development practices that first appeared with Forth, but the practices themselves apply generally. Reading a book titled Thinking Forth, you'll often read accounts of how learning to hack in Forth was instrumental and beneficial to folks learning to write good software quickly in other languages too.

One of the reasons this is the case is that Forth is a completely untyped language. You get *NO* assistance from the language in ensuring your code is in good shape, modules are mutually compatible with each other, etc. So when things go wrong, the results are positively disasterous. Like someone who learns not to touch hot objects after burning themselves on a pan of boiling water, so too do you quickly learn techniques of coding that inherently result in reduced bug counts and greater reliability.
Another myth if taken out of context. Forth is more memory efficient because it doesn't include all the standard library features that C provides. Few C compilers cull the linked binary to include only those modules explicitly needed and their immediate dependencies. As a result, C programs include procedures and data structures unrelated to the problem being solved.

However, if you do use these features, you will find C is no more or no less efficient than Forth. In fact, you might end up finding C as more efficient because C does not store "word headers" in with the binary of the program (this information is kept in separate linkage sections, used by the loader to perform address fixups, but then discarded thereafter). Many Forth implementations let you compile "headless" words too, but it's rare to do so.

But, really, with today's memory capacities, the incentive to code headless words isn't as strong.
For the 6502 and 65816, I'd wager that Forth's performance is actually better. For the AVR series, this is not really the case.
More than anything else, this is Forth's unique selling point. The ability to hold a veritable conversation with your computer is unbelievably liberating.

If you're interested, please subscribe to my RSS feed here:

http://www.falvotech.com/blog2/blog.fs/rss

I will be posting a series of articles pertaining to architectural patterns in Forth on my blog.

Oh, and yeah, notice the ".fs" extension? I invite you to read this article for an explanation:

http://www.falvotech.com/blog2/blog.fs/articles/1002

So has the interactiveness been improving in recent years, and can you write or modify a tiny part of the code and try it immediately now without re-compiling other parts of your code (let alone the whole thing)? After I set up the very simple interacitve Forth system I used to develop the last set of ATE with, the engineering manager who had just gone to another company (but whom I still had contact with) said they had just spent $8,000 on a system to develop in C on the 68HC11 and it was not able to do what I could there in Forth. He was very impressed.

By the way, I like your Forth word "REPLACES". I had done similar things and thought about doing what you did there, but never did it myself.

This depends.

In general, the answer is no, but some IDEs permit incremental compilation which approximates this capability. Microsoft's Visual Studio permits this, for example, albeit with some limitations.

Even so, the 10x doesn't come from what you describe. And, I'll tell you why -- Forth is a hyperstatic global environment, which means that new definitions shadow old ones, like so:
So, if you interactively debug code by on-demand definitions at the OK prompt, you end up with half-complete reimplementations of what you're working on in the first place, AND you have to transcode it all into source form to keep what you've worked on anyway. I've never derived any significant benefit from on-the-fly code redefinitions in Forth. Never. Not once.

Instead, I put all my code in a set of blocks, and when I need to, I just reload the application from scratch. It's fast enough to not even be an issue. On contemporary hardware, compilation speed is so fast that it's done before I lift the finger off the ENTER key.

Which now brings us to why coding 10x in C is possible: harddrives and GHz-speed CPUs. While not as fast as a blink of the eye, test-driven development strongly encourages breaking modules into small components which compilers can slash through quite quickly. A non-recursive make file makes for damn fast recompiles too (another reason to avoid the typical GNU-style recursive make system like the black plague that it is). Adding insult to injury, some IDEs, like Eclipse, are actually capable of compiling your code long before you even tell it to save your file.

So yeah, with the right tools, you can have very rapid turn-around times. With the right set of development practices, you can have very bug-free code.

I still prefer Forth of course -- I find Forth overwhelmingly more expressive than C. And, the tool-chains are much simpler to get working too (my beef with the Arduino was NOT the use of C, but rather getting all the pieces to play nice with each other). However, if it's one thing cc65 demonstrates, the language is not the toolchain, and cc65 compiles and runs perfectly out of the box.

I think that if we're going to do Forth a service in the future, we need to stop being so antagonistic towards other languages, and learn from each other. The C community has changed a great deal since 1982.
Well, I can't speak for people who are willing to spend such large sums of cash for their compiler environments. I'd just assume use the GCC tool-chain for this work. It's free, despite the time investment getting the pieces to work together.

Although, I'm curious to learn what you could do in Forth that they couldn't do in C. I'd like to know in the greatest detail you can recall, because I'm willing to bet you I can disentangle the Forth-the-language-benefits from Forth-the-development-process-benefits, and you just might be surprised at how many things in the latter category apply to C as well. I might also outline serious defects in your coding methodology as well, and why TDD addresses them.

Professionally, I work primarily with Java and Python at a software-as-a-service shop, and we are fully capable of issuing up to 16 software releases per week. That's 16 revisions of our public-facing software per week. (We don't actually make this many releases per week, of course; but I have seen cases where 4 sign-offs have occurred in a single day.) We can push 20, but we reserved one day per week as "no deployments" day. We average about 4 releases per week.

With only about 200 or so engineers on staff, do you really think that switching to Forth would significantly enhance our productivity?

Right, and while there is some value in this, on the whole I think it's a wash. I find test-driven development techniques works better on the whole.

TDD is a practice where you maintain two programs at once. The first is a collection of tests which can be run in any order, and which exercises the various components of your production code. The second program, obviously, is your production code. The trick is to iterate in a loop of writing one test first, then writing just enough production code (however stupidly simple it is) to make that one test pass. For any given iteration, you'll find that this does take a longer time than the traditional Forth-style interactive development process. However, the corresponding time spent debugging is substantially reduced, particularly since you have an ever-growing body of executable specifications which you can refer to both for correctness checking and also to serve as an example on how to use something (what was the order of those stack arguments again? Did I need to NUL-terminate that string or not? Etc.).

And, you might find that you need to change entire swaths of code because you coded yourself into a corner. Or, it's not compatible with a customer's new requirements, etc. This happens. With your interactive approach, you start anew, but you have no way of ensuring your changes retain compatibility with the rest of the software you've written. With TDD, you have a body of tests to back you up. Yeah, some of those tests are going to change along with your production code changes. But, unless you're starting completely from scratch, you won't be changing every test (all at once, at least), so TDD still delivers more value.

My HDLC implementation, despite being grossly incomplete at the moment, falls under 202 lines of of production code. I have 303 lines of tests backing those production lines.

This brings me to another great advantage of Forth -- succinctness. C is quite verbose. TDD in C has a ratio of 4:1 to 10:1 test-to-production lines of code. The reason for this is, in C, you often have many branches inside a function. Every if, while, do, ?: operator, and switch statement represents a branch to one or more targets. That basically means that every one of those branch targets needs to be exercised by your tests.

With Forth, you can factor your code so finely that many of your decisions and their effects can be pulled into an independently tested chunk, which then gets re-used in other code. So, TDD with Forth tends to have about 1.5:1 code test-to-production code. This makes sense when you consider that a word should have no more complexity in it than a single IF statement, or BEGIN/WHILE, etc.
Again, in what context? Observe that Forth, Inc. targets embedded markets primarily, and that means they're working against hardware engineers, not software engineers. Or, if they are software engineers, they've obviously never worked a day in their lives in a software-as-a-service shop, where releases are done several times a day. When you have that kind of market-driven pressure to keep up, it's sink or swim, and believe me, you do find ways to swim.

I find, as a general rule, hardware engineers make the absolute worst software engineers you can imagine. I note that Chuck Moore made the same observation in one of his fireside chats. They have a tendency to write spaghetti code, they tend not to test edge cases, etc. Many embedded organizations also tend to be caught up in documentation-heavy methodologies, like CMM, Sigma-6, and related practices. I have no problem with any of these if they're adequately justified, but coding takes a back-seat to things like design review meetings, code certifications and sign-offs, etc. Forth shops tend not to have such processes in place, based on conversations with professional Forth coders. That accounts for a major boost in productivity too.

Another thing to remember is that Forth, Inc. is a small fry in a big ocean of competing, and increasingly more popular, embedded technologies. They will make any claim they need to ensure their revenue stream continues.

Before I learned TDD, I also believed the 10x figure was unique to Forth (and to Lisp, for Forth and Lisp have the same interactivity aspect). After learning TDD, however, I find I'm just as productive in C (by which I mean that I can pump out comparable quantities of code with comparable feature sets) as I am in Forth.
What you describe above is one of the sole justifications behind any IDE (it's where the "I" in IDE comes from -- Integrated). Eclipse is a great example, like I mentioned earlier. Designed originally for Java, but since expanded for other languages, when you "save" a file, it not only saves the source, but kicks off the compiler as well. At least for Java, it'll also (under some circumstances) kick the compiler off even before you click the Save button (you can tell Eclipse to auto-save every few minutes). The Arduino IDE is another example which allows you to reflash the microcontroller without leaving the IDE, with a single mouse-click.

Anyway, my point here isn't to hijack this thread (we should move it to the Forth section of the forum). My point is that Forth productivity is due to its processes and development culture, not an intrinsic in the language itself.

That being said, Forth's lack of type safety forces you to adopt these processes as a required means of getting code working and retaining maintainability. Coding in Forth is a skill, and if you ask me, it's very much a skill worth honing.

Like Garth, I enjoy Forth, and encourage others to use it. After working with it since 1995, it is my all-time favorite programming language. However, I have very different reasons for recommending it to others:

(Mike: The \[list\] tag seems broken in the forums.)

* Forth is unbelievably succinct, yet extremely expressive once you understand the coding conventions used.

* Instantaneous recompile times makes iterative development so effortless you'll wonder how you could get by before.

* Exploiting Forth's hyperstatic global environment relaxes symbol collision issues you'd otherwise have in most other languages.

* You tend not to name variables, but rather individual processing steps. I find greater value in knowing what something is doing, not what it's doing it with.

* Once you know the language, well-written Forth code talks to the human reviewer, not to the computer. (Chuck Moore's insistence that subroutines in Forth be called "words" is not an accident.)

* You can expand the language with the constructs you need to ensure the previous point holds. Parser generators, finite state machines, etc. all physically look like their ideal representations before "Domain Specific Languages" became a house-hold word.

and there's more too, but I can't quite list them out right at the moment.

Well to be fair I probably only need 10 digits of precision accurately. After all we have significant figures to deal with so 10 should be plenty. Floating point probably is not necessary. The co-processor is a solution in my head to save cycles on the 8-bit uC so it doesn't need to worry about doing any math. Concentrating on running the OS-like software and the interpreter.
I might just be a small time hobbyist, but something tells me over all my code looks like spaghetti too. I have written C++ programs with so many functions being built on top of each other my "running" code sometimes has been a dozen lines. I have always tended to copy/replicate others code and integrate it into my project. I've always told people who I've talked to about programming, that I am more of a integrator then a programmer.
Go right ahead and keep hijacking. I am learning new things so I am happy, and hijacking is normal on boards.

Dimitri

Well, without actually looking at the code, I can't tell. But, well-factored code generally tends to have procedures smaller than 30 lines. Functions calling functions sounds pretty well factored to me.

On the other hand, I've had to maintain classes with single methods exceeding two thousand lines of code. That's always a lot of fun. :-/

A great example of this kind of non-modular spaghetti code is forever glorified in a video published by Object Mentor (a group of software engineering consultants who, mostly, know their trade very well). Imagine trying to maintain code like this:

http://vimeo.com/9981123

(warning: when I last hit this video, it failed to come up. It looks like Vimeo is having some problems. But, it played just fine a few days ago, so service will likely be restored in a day or two.)
And, I think this is a perfectly fine practice (and I would claim is a prerequisite to learning how to program productively), as long as your project isn't for sale. Projects for sale will inexorably need maintenance over time as customer requirements change, and so you will end up spending more and more and more money on making those changes.

The best practice is to (1) integrate the stuff, (2) test it to make sure it all works, and (3) refactor so that the stuff is more maintainable, and finally, (4) test again and make sure you didn't regress.
Nothing wrong with that. I just think it's worthwhile to practice techniques to enhance maintainability, that's all.

The priority should always be on getting something working. Refactor only after this goal is achieved. The benefits of refactoring, however, pay off over the long-term, not the short-term. You won't see the benefit right away. It'll only become apparent when someone says, "I need you to change FOO to BAR. Can you do that by next week?" If you can apply your changes within schedule, and without cursing to yourself under your breath about how hard it is to debug the code, you're refactoring correctly.


Of course, I speak as a senior test engineer. My job is to help reduce maintenance costs while concurrently enhancing productivity and the bottom line.