Hi, I'm new to this forum, and don't know if this is the best place for this post.

I program ARM & AVR firmware by day, and I have a little PCB layout experience as well. I'm an old EASy68K user, and cut my 68K assembly language teeth on an Atari ST, both of which I still enjoy.

A few years ago I used EASy68K to bring up a self-designed, 68008 single-board computer (I've had the parts sitting around since college). That got me thinking--even with the convenience of a PC desktop running 68k programs on a simulator far faster than the original processor could run them, I feel there's still something special about seeing your program run on real hardware. Maybe there's others that feel the same way.

Would anybody be interested in purchasing a small 68K computer specifically designed to be compatible with a subset of EASy68K's features? I'm thinking about designing something with a 68SEC000, which is still fairly cheap and available, and would interface nicely to 3.3V SRAM. It would have somewhere in the range of 256K to 1M of RAM, and probably 128K to 256K of flash for firmware, 1-2 serial port(s), and expansion headers. Some other possibilities for features would be the LEDs, switches, and 7-segment displays similar to the hardware window in EASy68K.

If you're interested, which features would be most desirable? Around what price would you consider paying? Realize that some EASy68K features (such as graphics and networking) would be either prohibitively expensive, or prohibitively time consuming, to implement for this type of project.

Thanks, prof. Kelly, for the fun.

Hi. I'd be interested in buying a 68000-based development board.

68000 CPUs can still be purchased, though Freescale only manufactures the '060 at a couple of hundred bucks per CPU. Second-source manufacturers will still sell you a 68k though.

I'd like it to have some obvious input/output methodology - buttons, switches, LEDs, etc. It also has to be programmable somehow. I guess you could load the program into Flash and get the 68k to execute it from Flash. You wouldn't need an operating system - that's the job of the programmer.

If you built one, I'd pay $200 for it.

Richard

I would *love* to build a dev. board to be as compatible as I can with EASy68K. Unless it were manufactured in some volume, the extra PCB area alone to mount the LEDs and switches for anything like the EASy68K Hardware window would make such a dev. board expensive. If you're willing to live without the LEDs and switches, or to build some of it yourself, I do have a couple of options that are probably doable for $200 or less.

Also, what time frame would you be wanting a dev board in?

Here are the options I can offer, in order of the speed of "getting it done:"

Option #1.

I have that 68008-based design I mentioned in my earlier post. It's a 10 MHz CPU with 128K RAM and 32K flash. For I/O it has the 68901 MFP chip, providing a UART, four 16-bit timers (one of which I've hard wired as the baudrate generator for the UART), 8 GPIO, and it can act as an interrupt controller.

On that design the UART is brought out to a DB-9 through an onboard RS-232 level translator, so it's ready to plug in to a PC. That's its primary method of I/O. Most of the 68901 I/O is brought out to 0.1" headers, as well as the address and data bus of the system.

I still have a couple 68008 chips (you can't even get those on eBay, I don't believe) and four or five 68901 on hand, and one each of the SRAM and flash chip I used. I'd have to order a PCB, most of the rest of the parts, and assemble it, but that system would most likely come in under $200 and be done in a couple of months.

Option #2.

DigiKey still has the 16 MHz 68SEC000 avaliable at $15.38 a pop, and they're pretty much just a lower power 68000 with the ability to run at 5V or 3.3V, and with either an 8-bit or 16-bit data bus. I have a handful on my desk as I type. I've been itching to build the 68SEC000 into a design for a while now. This option is still on the "drawing board," however, so honestly it'd likely be at least 6 months to complete a design.

Regarding programming, I program my prototype 68008 board using a Willem-style EPROM programmer I found on ebay. The flash chip is a 28-pin DIP mounted using an IC socket so that it can easily be be removed and reprogrammed. I was planning on doing something similar for a 68SEC000 board.

If you'd like to pursue either option further then reply to this post with how best to contact you.

Mate,

I think we should do something together. Compatibility with Easy68k isn't my highest priority, although it is essential to have some way of programming the thing. That's going to be the main problem, I think.

Whether use use the 68008 or 68SEC000 doesn't bother me. I want it to interface to RAM, preferably static to eliminate the need for refreshing. It should have a reset method of some type. And we need to be able to create a program in assembly or C and upload it to the EPROM/Flash and then make the CPU go.

All other input/output stuff I can add myself.

Contact me at richardcavell@mail.com

Richard

Yes, I'd be interested in such a board, as well as participating in this project (if that's welcome).

Your RAM targets seem about right to me, but I'd always prefer more flash (sure, 256K of assembly code is nuts, but eventually it would be nice to target such a board to GCC, etc.)

I took a (very small) part in the N8VEM Z80 CP/M project, and that was a fun experience because it was all "retro" - all thru-hole parts, 75LSxx logic gaes, no programmable devices (e.g. GAL) etc. For a small Z80 CP/M system, that was fun and somehow appropriate, and it was easy enough to support as a "kit" for people with a wide range of electronic assembly skills.

For a practical Easy68K compatible SBC, however, I'd prefer to see more modern components used (which seems to be where you're going). I am happy to see a 68HC000 device and 'modern' SRAM and flash chips. The 68K I/O chips will be a problem, however - they're obsolete (AFAIK). Using an 82Cx50 UART, for eaxmple, is more practical - but will require some 'glue' to make work nicely.

LED's and switches compatible with the Easy68K would be welcomed, either as an 'add-on' board or on the mainboard. Another possible solution for I/O would be to use a Propeller device to generate VGA compatible text display and handle PS/2 keyboard input. (There's an N8VEM board that uses the Propeller for just this purpose, so could likely work from that as a starting point - it was the exception to the "no programmable devices" edict).

Anyhow, yes, interested!

-tom

Great! I'm glad your interested. Input and, perhaps, help, is certainly welcome. I say "perhaps" because 1) as you can see from this thread you're just the second person to express interest, and 2) the only other person to respond has indicated he's ok with the design based on the older parts. I'm currently tweaking my prototype PCB with "old" parts according to his expressed interest.



First, I've already started work modifying the PCB layout of the prototype for 32-pin DIP flash chips, which will mean more flash (the 28-pin chips are very hard to find, anyway). Second, since the 68K series is a Von Neumann architecture, it is acceptable if not preferable to have a small amount of flash and a large amount of RAM. Practically, you'll need a PC to assemble/compile, and load any sizeable program to the board, so I doubt there'd be much disadvantage to loading it to RAM instead of to flash. The way the EASy68K program works is similar to having a SBC with *just* RAM, and it would be a similar program, load code, run paradigm.



I'd like to use newer components, and I actually have a handful of 68SEC000 chips on my desk as I type (I think the 68HC000 is now hard to get, but the 68SEC000 is still available through common sources). From my working 68008 prototype, though, it'd be a do over. I don't have a lot of free time at the moment, so this wouldn't be something I could do quickly.

As far as the support chips, the 68901 is *really* convenient for a SBC, but yes, a handful of newer parts could be substituted. I probably would use a UART from NXP, which makes some very capable UART chips, some of which are easier "glue" to the 68000 series.

The difficult 68901 function to replace would be the vectored interrupt capability. Vectored interrupts are *really* nice for learning to write interrupt handlers. The 68901's 8 GPIO pins can be configured with each pin interrupt on a unique vector. That's more or less impossible to replicate efficiently with 7400 series logic and would require some nontrivial programmable logic.

Of course, the hardware for auto-vectored interrupts is easy, but personally I'd rather have vectored interrupts than newer parts using auto-vectored interrupts. It makes interrupt handling significantly easier and faster. You don't have to have any shared interrupt vectors. Your ISR doesn't have to go asking devices which one requested the interrupt.



I certainly have no "purist" qualms about using programmable logic or microcontrollers on this...and yes, I've done the bit banged video as well (NTSC rather than VGA, and on an AVR). The problem with all these features, as much as I would like them, is cost and time.

The components themselves aren't prohibitively expensive, but the PCB space taken by LEDs, switches, buttons, and all the rest could mean tens of dollars of cost. PCBs manufactured in small quantities are pricey, and they are priced based on board area.

By the way, my existing prototype brings the address bus, data bus, and a strobe signal indicating when the off-board address space is being addressed to 0.1" headers. My idea was to make it the basis for a modular design. So, the extra features you mentioned *could* be added as (an) additional PCB(s), even to the "old" design.

Thanks again. Let's keep the conversation going.

Mark

Hi Mark!



Yes, by all means, 32 pin DIP for flash. I've got scads of TSSOP-32 chips, but I can make DIP carrier boards for those.



My only reason for having a non-token amount of flash would be to allow the possibility of standalone operation, or having multiple boot images installed (e.g. be able to boot into EhBasic, or some monitor program, or...) Also, flash is cheap enough, and smallish flash chips are hard to find (as you mentioned already).



As for my 'inventory'; I've got about 10x DIP48 68008-8, about 30x 68901 in PLCC, a few DIP48 68901, and about 10x DIP40 68681. I'd love to use these (saved from scrap a long time ago).

The 68008 in DIP48 is a bit frustrating because it's limited to 1MB address space, and /IPL0 and /IPL2 inputs are sharing a pin (so IPL is limited to 0, 2, 5, or 7). Another shortcoming of the 68008 (vs. 68EC000, for example) is that /VMA is not bonded out.



Fully agree! Yep, I'm right there with you - it makes an awful lot sense to keep a 68901 in the circuit, if only for the purpose of being able to to bask in the glory of vectored interrupts. All the more desirable with a DIP48 68008 where there's only three interrupt levels to play with. I took another look at the 68901 UM and realize that the UART isn't so crappy after all; seems as if it will support 19.2kbps with a 3.686MHz xtal.



Again, I fully agree. I've already gotten the "front panel" and das Blinkenlights nostalgia bugs out of my system. Spending $50-ish on mechanical hardware that won't really get used is not so interesting to me, at this point.

A general comment: to me, the primary benefits of an SBC that is "EASy68K compatible" are:

1) a (wonderful) windows-based IDE and simulator.
2) a well defined and standardized BIOS (i.e. TRAPs for IO, etc)

Perhaps a good starting point is to determine the MINIMUM system hardware and BIOS configuration, and then we can freely build above/beyond the minimum to our heart's desire.

For example, the 68008 system you described seems a good candidate, but maybe tweak things a bit:

10 MHz MC68008 CPU (mine are all 8 MHz...sob..weep..)
128K RAM --> maybe bump up a bit?
32K flash --> maybe bump up to 128K (i.e. 1Mbit Flash)
68901 MFP
- UART terminal connection
- vectored INT controller

Beyond that, I think it's A-OK if you and I and others end up with drastically different hardware. I think this is almost a given:

1) we all have different "parts on the shelf" at our disposal - it's painful and expensive to track down these old devices in very specific packages. (my experience from the N8VEM CP/M project)
2) different philosophy on "glue" logic implementation - I'll almost certainly use a MAX7000 CPLD (I have 'em, I know 'em, I like 'em) for address decode, missing VMA logic, DTACK/BERR/VPA generation, clock tree, etc. Others may want to use GALs, or 74xx, for their own designs.

That being said, when I get around to making a 68008 system, I'll certainly make the Schematic and PCB fab files available and offer to sell at cost any excess PCB (I tend to use OSHPARK, and so the minimum lot size is 3 pcs) to anyone that wants them.



I agree! tomcircuit at the domain that sounds a bit like "bee whale"

-tom

The 8MHz part will easily overclock to 16MHz and even to beyond 20MHz with care.


You can get 512KB RAM in a 32 pin DIP, I'll have to go look up the part #.


I usually use a 68681 and a 68230.

One day I'm going to finish my 68030 design, which is not a lot more complicated than a 68008 design.

Lee.

That's nice to hear, Lee. I've long suspected that I could push an 8MHz part to 10MHz, but it never even dawned on me about trying to go much faster than that. 20 MHz - wow.

Going to 10 MHz is just fine, because that yields a 1 MHz '6800' synchronous bus, which in turn can be used with my CBM 6581 SID sound chips. (a complete analog synth on a chip)



I've got a half-dozen 25 MHz 68EC020 in PGA that I've held on to for years. I figured I'd cut my teeth on a 68008 SBC first, then work up to the 68020. So, any tidbits you care to share about designing with the "younger brothers" of the venerable 68000/8 would be most welcome!

-tom

I'd wanted to get a hold of some 68EC020 a while back, but it seems they've pretty much gone extinct now. I do have a couple 68340 microcontrollers with Motorola's CPU32 core--quite similar to the EC020 from all I've read. I've been putting off using it in a layout because doing the layout is going to be a challenge. Quite apart from the fine pitch QFP package, which I have little experience with soldering yet, there are several power and ground pins on every side of the chip, and it'll take either a 4-layer PCB (expensive) or some clever routing on a 2-layer PCB to get all the signals out from around and between the power pins.

Regarding the 48-pin package 68008 and the VMA signal, I put on my SBC design the recommended circuit for generating VMA off-chip from VPA, CLK, and E using a 74HCT series pair of flip-flops. If you want VMA, it's there--but that's another reason the older chip might be better--the 68SEC000 doesn't provide VPA, VMA, or E.

Also, while I don't think I'd ship anyone an overclocked SBC (if someone's paying me for it, I want to make sure it's got the best chance of working well for them) I'm just using a standard, DIP-8-style, 4-pin oscillator. Replacing the 10 MHz can with a higher frequency oscillator would be pretty easy.

Contact me via email and I'm confident that a 68EC020 chip and matching socket will find their way to you...



Two words: "drag soldering". Assuming you own a good soldering iron (e.g. Metcal or Hakko) there are special "hoof" tips available that make soldering fine pitch devices a snap. I loathe spending hours soldering 0.5mm pitch devices one pin at a time, using a needle tip and under a loupe, before I learned about drag soldering. Search for it on YouTube, there are some awe-inspiring videos there that nicely demonstrate the technique.

Any possibility to move forward a bit? Hammer out a memory map and minimum system configuration?

-tom

Minimum config .. 512KB RAM, 128KB flash, MC68008, MC68681, MC68230

Lee.

My prototype system has the following memory map:



That way I didn't have to deal with remapping RAM after boot. In a future design I'd go ahead and add a remap soft switch.

@lee, your proposed memory map is simple, which is good. However, the I/O section in your proposal lies outside the range that can be accessed using 16-bit addresses (Absolute Short addressing mode, e.g. ).

Since the 68000 exception vectors *have* to be at $0000 I like to take advantage of the 68000 "feature" that it treats word-sized address operands as signed numbers and put I/O in the range of $FFFF8000 - $FFFFFFFF (decimal -1 to -32768). You probably already know, but putting I/O there makes accessing peripheral registers more efficient, and 32 K of I/O space seems like plenty to me.

In case someone reading this thread doesn't know about it (I sure thought it was a neat trick the first time I saw it) the assembler will generate an Absolute address operand in the above address range as a 16-bit number instead of a 32-bit number. When decoding the instruction the CPU reads the address as a 16-bit number and sign extends it to 32-bits.

For example, one of the first instructions in my monitor code for my prototype PCB sets up the Vector Register of the 68901 so that it can feed back the correct range of interrupt vectors to the CPU during an interrupt acknowledge. The line of assembly (with comment removed and equates resolved) is Instead of the assembler generating machine code for a 32-bit operand it generates the machine code .

I would propose something more like:



In terms of peripherals, DigiKey has some of the NXP UART chips I mentioned, the SCC68681, and the SCC68692, both of which are practically drop-in replacements for the 68681. As for the 68230 I'm not quite sure what it gives me over the 68901 besides the extra GPIO.

Also, I'd love the 68EC020, but I'm not 100% sure how to contact you via email.

If you want EASy68K compatibilty you must have RAM from $00000000. The remapping is easily done with a 74LS164 to generate the MAP signal and only affects the fetching of the reset vectors.


Availability mostly but also nearly all the systems I have with a PIO chip use the 68230. I don't have any 68901s nor have I ever seen one in the wild.


I don't think the gain is at all signficant but it would not be any work to swap the ROM and I/O sections. Both areas would need to have the cache disable active on 68020s and above to allow writing to flash to work.


I think everything that is not RAM should be at $FFFx.... that way you can have as much RAM as can be addressed without having to change any code. The same address map can be used on a DIP 68008, PLCC 68008, a 68000 or even a 68030.

Lee.

Great discussion, guys!

On the topic of memory map...

I like Lee's point that the logical addresses of "not-RAM" should be $FFFxxxxx to give processors "more endowed" than the DIP48 68008 room to grow the RAM. I also agree that RAM starting at $00000000 is MUST as far as I'm concerned. As Lee mentioned, the MAP circuit is trivial. (e.g. Mot AN897)

It seems the logical map for an EASy68K compatible system could be:

$00000000-$FFEFFFFF --> RAM
$FFF00000-$FFFDFFFF --> 896 KB Flash
$FFFE0000-$FFFFFFFF --> 128 KB I/O

A 20-bit addr DIP48 68008 would physically implement the above as:

$00000 - $7FFFF --> 512 KB RAM
$80000 - $DFFFF --> 384 KB Flash (starts at $FFF80000!)
$E0000 - $FFFFF --> 128 KB I/O

A 24-bit addr 68xxx would physically implement the above as:

$000000 - $EFFFFF --> 15MB RAM
$F00000 - $FDFFFF --> 896 KB Flash (starts at $FFF00000)
$FE0000 - $FFFFFF --> 128 KB I/O

Therefore, for a MINIMUM system, the DIP48 68008 dictates that 512KB is the largest possible base RAM size, and 384KB is the largest possible base Flash size. I'm OK with 256 KB Flash as a base size, as that's easily obtainable (e.g. 2x 29F010 or 1x 29F020)

I think that RAM usage in practice, however, will be a bit tricky. The application will have to know that RAM at logical $xxx80000 will map to flash on a 20-bit addr system, and RAM at logical $xxxF0000 will map to flash on a 24-bit addr system. How to easily manage this?

This memory map proposal also accommodates Mark's desire to have more efficient access to the top 32K of the I/O space. Like Lee, I also do not this as being terribly important, but I am certainly fine with I/O located at the top of the memory map, provided that there's enough space devoted to I/O in total. I think 128KB of I/O space should be more than sufficient.

-tom