I'm a newbie to the 6502 CPU, I have worked with the 8080, 8085, Z80, MC6809, and MC68000 before designing hardware and software.

I'm retired now and have time to work on hardware/software projects so I want to try out a 6502 design, I looked on eBay and was shocked by the prices for old 6502 PCs in any cases I want to build one myself. I looked on Mouser and I was pleasantly surprised that both the 65C02 and 65C816 are available for just a couple of dollars in DIP40 format.

I'm thinking that maybe I should design a 65C816 board as that device can emulate a 65C02 and its native enhance form so one get two CPUs for the price. Any problems with that thinking?

I'm thinking of making it a simple board with 64K to 256K of RAM and some Phantom EPROM, a large capacity serial Flash chip, a serial port, and maybe a parallel port of two. I would talk to it with the serial port and a terminal emulator. Most likely I would use eForth for the OS/Monitor/Development system.

Are there some reasonable boards available that are decent? Otherwise I would layout a simple two layer board after wire-wrapping a prototype to verify the hardware design.

Any comments or suggestions is appreciated.

Thanks

_________________
Cecil Bayona - k5nwa

Hi Cecil,

I don't know whether there are some people here who would/could sell you something that suits your needs, I just want you to remind that there are two more variants of the 65C02: the W65C134 which is a µC based on the 65C02 and the W65C265 which is based on the 65816. Both are available as mid priced SBX-boards at Mouser. Much information about the latter you can find in http://forum.6502.org/viewtopic.php?f=1&t=3552. Perhaps BitWise has a spare memory expansion board.

Starting off the 65C816 is a good idea. Too many shy away from it because it is somehow perceived as too complicated or too hard to program. Starting with the 65C816 gives you the opportunity to get familiar with the 6502 assembly language and then open the 65C816's native mode door and take advantage of features that don't exist in the 8 bit world.

My opinion is you will learn more and probably enjoy the hobby more if you design and built your own unit, instead purchasing something that someone else designed. I would not recommend going the microcontroller route, as you will be insulated from much of the low-level logic that you would have to work out by using a discrete MPU, RAM, ROM, etc. The 65C816, like the other WDC 65xx devices, can be gotten in PDIP40 or PLCC44, the latter which is my preference for use on PCBs. PLCC44 can be used on a wire-wrapped unit, but compatible sockets are pricey.

As for eForth being a working environment, that is a step above writing a basic firmware for your machine. eForth, from what I've read about it, doesn't appear to support any kind of primitive input/output, e.g., reading keystrokes. Ting's discussion clearly indicates that his 8086 reference build calls MS-DOS APIs to handle all outside world interactivity. You are going to have to have enough code in place to talk to the hardware of your machine before you can get anywhere. That is going to entail 65C816 assembly language.

Also, I am curious as to how eForth would act as a machine language monitor. A machine language monitor has to be able to touch the bare metal in order to do its job. That's not a specialty of Forth.

Anyhow, there is a lot to read around here, as a number of members have scratch-built 65C02 and 65C816 hardware. Reading up on all of that should give you plenty of ideas on how to get started.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Hi Cecil,
for sure, if you take care, you can put in an '816 as a near-pin-compatible substitute, and indeed it powers up in a 65c02 compatible mode. You might want to check Grant Searle's pages for a minimal system design. And Garth's 6502 primer has lots of resources.
http://searle.hostei.com/grant/6502/Simple6502.html
http://wilsonminesco.com/6502primer/

A cringe-worthy claim, BDD. Although it's slightly above my current skill level, I will counter-claim that there are many Forthers with a modicum of coding under their belt who could easily whip out a simple BIOS in a few hours, and an interactive terminal-style ML monitor in a few more (the ML monitor could be developed incrementally and interactively on the native hardware as soon as eForth came to life). The majority of it would consist of high-level "definitions" that could later be selectively "tuned" with a sprinkling of assembly language, on the off-chance that the compiled definitions weren't efficient enough.

Mike B.

Ah, but then the BIOS no longer is exclusively Forth, eh?

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Well, I claim (without immediate proof) that it is certainly possible to write a complete BIOS exclusively in high-level Forth, including device drivers and interrupt handlers. Performance of the compiled code may become an issue and require a sprinkling of assembly language to spruce it up, but that's certainly not a given. Also, a couple dozen eForth "primitives" simply must be coded in machine language, but that's a different face of the die.

Mike B.

Forth certainly lets you read and write and bit-twiddle the I/O ICs' individual registers, and I have done keypad scanning in Forth. As far as getting "down to the metal," the only thing I can think of that Forth does not really let you do directly is twiddle processor flags; so if you want for example to clear the interrupt-disable flag, you would use the Forth assembler to write a primitive, something like this:

which would set up the header and make the code field address point to the first byte of the body (which is the CLI here, the first of only two instructions), and set the current vocabulary to the assembler vocabulary. END-CODE is only for housekeeping at compilation time (or assembly time in this case), and doesn't lay down any bytes. Headers can be omitted if you're metacompiling for a target system which won't leave a compiler available to the user (if you just want them to run the application and not get into things they shouldn't).

The above assumes direct or indirect threading. If you're doing subroutine-threaded Forth, you might as well just put the single CLI instruction byte inline, rather than calling a subroutine that does a CLI.

Forth can be used as an extremely capable monitor though. It's really luxurious in a possibly unexpected way.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

The 'monitor' of Sun machines - the one you get to when you enter 'Stop A' - is written in Forth.

As can be the firmware of PCI cards, IIRC.

[/quote]
Starting off the 65C816 is a good idea. Too many shy away from it because it is somehow perceived as too complicated or too hard to program. Starting with the 65C816 gives you the opportunity to get familiar with the 6502 assembly language and then open the 65C816's native mode door and take advantage of features that don't exist in the 8 bit world.

My opinion is you will learn more and probably enjoy the hobby more if you design and built your own unit, instead purchasing something that someone else designed. I would not recommend going the microcontroller route, as you will be insulated from much of the low-level logic that you would have to work out by using a discrete MPU, RAM, ROM, etc. The 65C816, like the other WDC 65xx devices, can be gotten in PDIP40 or PLCC44, the latter which is my preference for use on PCBs. PLCC44 can be used on a wire-wrapped unit, but compatible sockets are pricey.

As for eForth being a working environment, that is a step above writing a basic firmware for your machine. eForth, from what I've read about it, doesn't appear to support any kind of primitive input/output, e.g., reading keystrokes. Ting's discussion clearly indicates that his 8086 reference build calls MS-DOS APIs to handle all outside world interactivity. You are going to have to have enough code in place to talk to the hardware of your machine before you can get anywhere. That is going to entail 65C816 assembly language.

Also, I am curious as to how eForth would act as a machine language monitor. A machine language monitor has to be able to touch the bare metal in order to do its job. That's not a speciality of Forth.

Anyhow, there is a lot to read around here, as a number of members have scratch-built 65C02 and 65C816 hardware. Reading up on all of that should give you plenty of ideas on how to get started.[/quote]

[/color]
Most likely I will end up buying 10 65C816 in 40 pin dip as I already have 40 pin wire-wrap sockets and Qty 10 since I want more that a few, and 10 is the first price break.

Since the beginning Forth has been the OS/Monitor in small machines, not much interfacing is needed serial in and out so that is part of the job. A Bare metal interface is not a big issue as it will include an assembler so specialised words dealing with the hardware will be added after the basic porting, words, for example, to enable/disable the interrupts.

Currently, I'm working on creating my own version of a portable eForth that can easily be migrated to other CPUs, it's, mostly written in Forth itself with a small amount of C, if as CPU is used often enough then the C portion is re-written in assembler to speed it up further.

This looks like it will be an interesting project as this CPU appears on the surface to be quite fast and in reading articles in the past the 6502 was quite efficient so the 65C816 with it's 14Mhz or higher clock and enhanced instructions should be quite fast.

_________________
Cecil Bayona - k5nwa

Tor wrote:

The 'monitor' of Sun machines - the one you get to when you enter 'Stop A' - is written in Forth.

That is a huge monstrosity, it very large over a MB in size, I like the smaller Forth such as eForth, being just a few KB in size and quite fast. Forth makes an excellent monitor with a lot of the basic functions being built in, and it's easy to expand to add words with a special function.

Once finished and documented I plan to release it so whoever wants to use it may do so.

_________________
Cecil Bayona - k5nwa

barrym95838 wrote:

BigDumbDinosaur wrote:

... Also, I am curious as to how eForth would act as a machine language monitor. A machine language monitor has to be able to touch the bare metal in order to do its job. That's not a specialty of Forth ... [ emphasis added ]

A cringe-worthy claim, BDD. Although it's slightly above my current skill level, I will counter-claim that there are many Forthers with a modicum of coding under their belt who could easily whip out a simple BIOS in a few hours, and an interactive terminal-style ML monitor in a few more (the ML monitor could be developed incrementally and interactively on the native hardware as soon as eForth came to life). The majority of it would consist of high-level "definitions" that could later be selectively "tuned" with a sprinkling of assembly language, on the off-chance that the compiled definitions weren't efficient enough.

Mike B.

You are correct in its history it was quite common for Forth to handle the bare metal of the hardware, actually I prefer it to anything else to handle the bare metal because of it being interactive you can hand type your code to test it and get it working right. Even today it is very successful in working with embedded PCs where Forth has to handle all the hardware, a 65C816 is a simple device compared to an ARM or MSP430 device yet Forth handles all the built in hardware just fine in those devices. I have eForth for the esp8266 device and Forth handles it just fine, including the wireless technology.

_________________
Cecil Bayona - k5nwa

BigEd wrote:

Hi Cecil,
for sure, if you take care, you can put in an '816 as a near-pin-compatible substitute, and indeed it powers up in a 65c02 compatible mode. You might want to check Grant Searle's pages for a minimal system design. And Garth's 6502 primer has lots of resources.
http://searle.hostei.com/grant/6502/Simple6502.html
http://wilsonminesco.com/6502primer/

Thanks for the link, I already had Grant Searle's pages site bookmarked as he has some excellent but simple designs for various CPUs, I plan to visit it and glean what I can from it when I get started in laying out a board. Mine will be a simple design but it little more complex that his but in the same spirit.

65C816 CPU @ 14Mhz
256K of 10ns RAM
16KB-128KB of EEPROM with write capability, and Phantom Shadow capability.
1-2 Serial ports with RS232C interfaces.
16-32 bits of parallel interfacing with a couple of LEDs, this can be general purpose I/O
CH375B/CH376 Solid state disk interface. A wonderful inexpensive device to emulate a Floppy/Hard Disk from SD card or USB stick.
Make the Control/Address/Data buses available on a header for future expansion.

ftp://imall.iteadstudio.com/Modules/IM1 ... 009001.pdf

It will be a sellable item, unfortunately, there would be a small market for it.

_________________
Cecil Bayona - k5nwa

That "monitor" is a slow-moving bloated mess that made Jim Butterfield's Supermon for the PET/CBM computers look look like a race horse in comparison. I've had the dubious pleasure of mucking about in it. A classic example of poor programming language choice. Had it been written in assembly language or even K&R C it would have been several times faster.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!