I have been following this discussion with interest. I am open to the idea of making additions to the EASy68K simulated hardware (PIA etc) in order to make it fully compatible with the resulting hardware.

Thanks for the offer. For me the fun in all this is to see my code actually run on real hardware, and I think that's a fun feeling to pass on.

profkelly wrote:

There is also the possibility that I might be able to purchase 25 of these boards for use in my class.

To me this argues for a newer CPU rather than the 68008, unless someone has more than 25 hanging around (robust or no, I'm sure some of them will need to be repaired or replaced from time to time).

profkelly wrote:

A board designed for classroom use must be (safe, reliable and student proof). I don't think it is necessary to duplicate all of the EASy68K hardware on the board. An isolated interface that the students can use to connect to a vector board would be perfect. I'll have them wire their own LED displays and switches.

A couple of clarifying questions, here. I think it hardly bears mentioning (were it not for the sad frequency with which it turns out not to be true) that by "safe" you mean the board is safe for the people using it. I power my prototype with a switching 5V supply with a barrel connector purchased at a surplus electronics store. To me a barrel connector on the board for D.C. power, a good, off-the-shelf switcher, and perhaps an additional fuse are safe enough to me in regard to electrical concerns.

I've read, though, that with the move to reduce hazardous chemicals in the manufacture of electronics, and specifically the removal of flame retardant in the manufacture of today's PCBs, even a lithium coin cell provides enough power to cause combustion in some instances. I've seen combustion happen firsthand with a device I've helped test (it was powered by a 70-odd Watt switching regulator, not a coin cell, and the switcher behaved completely within spec the entire time the PCB was slowly burning up). I'm not sure there's much any of us could do to guarantee against that kind of failure except to unplug the boards at night.

So if "reasonably" safe is a barrel connector, a fuse, and a decent switching, wall-wart power supply, what are you looking for on the continuum between "reasonably" safe and "extremely" safe?

Regarding "reliable" and "student proof," the primary enemy is likely to be static electricity, with a close second being connecting something backwards or otherwise incorrectly. The standard approach I've seen with plug-and-play type electronics (i.e. USB devices) is to clamp each conductive path to the outside world with surge suppression diodes or other similar devices, and to use connectors that will not mate incorrectly. On a board like this that approach would be somewhat expensive given all the bus signals we're discussing exposing via headers, and given the desire for some standard header/connector for the interface.

Newer ICs might fare worse in the student proof department. Some of the older chips can prove surprisingly reliable. The PIA in my aforementioned AIM65 only had 5 or 6 working pins on its PORTB by the time I really learned the ropes. But the chip itself still functioned except for the blown pin driver circuits on those failed pins. If I gave that same abuse to a contemporary microcontroller my guess is the entire IC would be damaged and probably fail, not just the pin driver circuitry.

In summary, could you help me understand a little better what you feel to be reliable and student proof?

So if "reasonably" safe is a barrel connector, a fuse, and a decent switching, wall-wart power supply, what are you looking for on the continuum between "reasonably" safe and "extremely" safe?

Reasonably safe as you describe it is sufficient.

maalper wrote:

Regarding "reliable" and "student proof," the primary enemy is likely to be static electricity, with a close second being connecting something backwards or otherwise incorrectly.... In summary, could you help me understand a little better what you feel to be reliable and student proof?

External connections need to be immune to bad student wiring. Assuming logic level voltages only, I'm not talking about protection from wiring 12v or higher to an input. If the hardware is all on the board (switches, 7-seg LEDs, etc.) then that will not be an issue. If a PIA or similar device is made available for students to connect to then it needs to be protected. It also needs to be in a socket and have easy to find replacements.

Oooh, I hate it when the forum's owner and moderator hijacks a thread!

So, really, I think that the board that Prof. Kelly and Mark have been discussing is a bit different than what Mark, Lee, I have been discussing up to that point.

Prof. Kelly's requirements are for a "student-proof", serviceable, SBC. I used to teach comp arch/assembler at Lawrence Technological University (also in Michigan!) and so know full well how much these SBC can get abused, the importance of spares, etc. In other words - I get it, and think that his requirements are very sensible.

But this thread originated and grew around the idea of a 68008 (obsolete) SBC that is EASy68K compatible, not student-proof. Probably not even hobbyist-proof The requirements for a "mass produced" student-proof SBC are much more constrained than I'm willing to work within. I think we got pretty far along those lines (esp. in light of the amazing body of BIOS work that Lee disclosed a couple weeks ago). We agreed upon a 6821 PIA, a RAM and FLASH footprint, a 68681 DUART, and omit the LEDs and switches. The latter could be supported via an "expansion bus".

The good news is that I see a great deal of commonality between these two topics - the student-proof SBC and my own 68008 board will have vastly different schematics and PCB, but a shared BIOS for these two systems to enable EASy68K compatibility should be possible. So, I see these two topics as being quite complementary, not opposed. Any chance that the discussion on the more serviceable and "mass produced" student-proof SBC that Prof. Kelly is after could move to a new thread?

I don't want the original topic's momentum to die - a lot of good stuff got hammered out. In fact, as I see it, only a very few items remain - I think it's a good idea to follow through on Mark's proposed standard for an expansion bus, for example. As for me, I've been a bit distracted lately and haven't posted anything here, but I've been sketching up block diagrams and made a lot of headway on schematic capture for my own EASy68K compatible system. I'll post some observations in a subsequent post.

-tom

Last edited by TomCircuit on Sun Nov 25, 2012 8:10 pm, edited 2 times in total.

1) IO Processor (IOP)We discussed using the second DUART channel for some misc IO activities. I like this concept, and recently discovered that there was another homebrew 68K project (check out the Kiwi computer at http://www.ist-schlau.de/ - it's nearly matching what I'm after in almost all respects, and then some!! Awesome!)

I propose that the IOP and handle at a minimum: satisfying the 68K power-on-reset requirements (RESET and HALT pulled low for at least 100ms), a manual reset switch interface, and a real-time clock (RTC) interface.

My motivation for this proposal:

Certainly the reset circuitry is easy enough - the proven 555 timer, some OC gates or NPN BJT for the inversion and drive of HALT and RESET...but this all can be done with a uC and still handle other tasks. There are so many RTC solutions that it could be helpful to "abstract" the RTC via the IO Processor (IOP). I'll probably use the DS1302, because I know them and have them on-hand already. The DS1302, like many RTC chips, is not really so nice to bit-bang with a uC - in this case, it has a bidirectional data line that needs to be broken into DI and DO.

I envision the IOP being a "slave" to the 68K - send a command for RTC info, send another command to set RTC, send a command to RESET the 68K, etc.

I'll add a PS/2 keyboard interface feature to my own IOP - sure, not everyone needs this, but it's easy enough to do, and I want it, so I'll do it. I can fit all this into a (close your eyes, Mark!) a PIC16F688 in its cute little 14 pin package with internal 8 MHz oscillator. I'll for sure make the PIC code available to anyone that's interested once I complete it.

2) SD Card supportI was waffling a bit on whether to put the SD card SPI interface on the other side of the serial IO processor (e.g. PIC, ARM, whatever) or map it directly into 68K address space. I've opted for the latter, it should work out to be much faster, and simplify the command protocol within the IOP. I propose a simple 8-bit r/w port - so the 68K can bit-bang the SD card SPI signals. Bit banging can be made a bit easier by making the port r/w (i.e. written bits can be read-back). Easy to include the SD card Write Protect and Card Detect status bits in the readback latch, also. A spare bit from the write latch can be used for an LED for "SD card in use" indicator. A 3.3V LDO VREG is required (SD is 3.3V) and using HCT 245 for readback and LVC 574 for write latch makes the 5V/3.3V translation a breeze.

3) PIA interfaceA lot was said on this. I'm going to map the PIA into 6800 peripheral space. The main objection to this was that that more modern 68K devices do not have the 6800 interface. The WDC 65C21 can be interfaced asynchronously, or some programmable logic can be employed to provide the missing 6800 interface (e.g. some steering logic around a 74HCT646 latched xcvr is really all it takes). I'll go the latter route if/when I get to the 68EC020 SBC.

At the risk of re-opening an old wound - I've found a stash of Z80 CIO chips (like the 6821 PIA, but more timers and supports vectored INT's and INT chaining!) that *appear* that they could interface to the 68K without too much hassle - anyone have any experience with making Zilog Z80 peripherals play nice with the 68K? These are $9 from mouser in the USA, for example, so not so much more expensive than the 65C21 PIA from WDC, but much more capable. I'm happy to drop this subject if we're all OK with the 6821 (or Mark's work-alike enhanced 6821 PIA circuit).

4) Interrupt strategyThe 68008 in DIP48 supports only 3 interrupt levels - 2,5, and 7. I think that the DUART should be level 7 (it's the "host port", after all) and obviously support vectored INTs. I think that the PIA should be level 2 (if it get an INT at all) and (naturally) autovectored (note, if Z80 CIO is used, this could be vectored also)I think that the interrupt level 5 should be reserved for "future expansion" - I imagine that Lee will want to use LVL5 for a PIT and I think Mark and I would use it for an MFP, for example.

Of course, a non DIP 68008 and other 68K uC devices have all 7 levels available, so this is really a constraint only for us that want to use these darn DIP48 68008's.

5) CPLDI'll plan to use an Altera MAX7000 series EPM7128 in PLCC84 package. I've got about 21 free pins, and I'm sure I'm fine in terms of macarocells. These are parts I know and own, so that's why I use them.

6) other peripheralsMy TMS9918/V9938 video and 6581 SID sound and other IO will be on a second board, interconnected via some sort of "standardized" bus (Mark had some suggestions towards this, that I need to review). I think that the standard needs to be electrically defined, but I don't expect any sort of "physical" standard to be adhered to.

7) DUART clock generationI'll assume a packaged 29.4912 MHz oscillator for a "fast" CPLD clock (for internal states) and then divide this by 8 internally to obtain the 3.6864 MHz clock required by the DUART. I'm tempted to also divide 29.4912 MHz by 3 to get 9.8-ish MHz for the 68K. Anyone know if the 68K would needs CPUCLK to have a 50% duty cycle? I'd like to get a ~10 MHz CPUCLK to produce a ~1 MHz ECLK to make the 6581 SID chips happy. Worst case I'll toss down another oscillator, but I would prefer to avoid having two asynch clocks running amok inside the CPLD.

8 ) bus arbitrationI really like Mark's suggestion about a "helper" MCU to master the bus...but I'm not going to bite on that right now. It doesn't really have any effect on BIOS design, anyhow, so it's pretty transparent to EASy68K compatibility. So, I'm going to pull BR high with a resistor and leave that temptation for later...

I know that there are a zillion ways to accomplish the stuff I rambled on about here - but I'm very interested in hearing from others with helpful hints and suggestions, and also some feedback on the proposal for the IOP functionality, SD card interface, and the possible replacement of 6821 PIA with Z80 CIO. (flames cheerfully accepted on the last point)

@lee, sorry to hear about the cat mishap! I hope you get to feeling better soon.

I'd like to take this thread a *slightly* different direction, for a moment. I agree we're converging on an architectural "skeleton" for a system, which could then have a common BIOS for the different "flavors." There are many advantages to this approach. Some of the biggest advantages are related to the time and effort required to implement BIOS firmware. I think the result of this will be a better system (or really a small family of systems) than if any one of us designed it by ourselves.

Since I started the thread back in 2010 I feel I'm not "hijacking" the thread by saying that *my* original purpose was to see if I could get enough people interested in the *same* design, a design as compatible with EASy68K as possible, that we could order PCBs and (at least some of the) components in quantity, and each of us could pay a bit less to get the hardware. Concretely, I was hoping to build a SBC in a quantity somewhere between 5 and 50 where PCB houses and electronics suppliers start offering quantity discounts.

Professor Kelly's post does indeed outline a SBC that is by necessity different than what we've been discussing. For me it is (I think) the first request or suggestion that has the potential of meeting my original purpose for the thread. Many of you seem set on implementing your own individualized SBC based on the skeleton we all agree upon, but implemented and laid out with different components. For you the "classroom" version is a divergence. For me, however, it might justify the time and effort required for me to implement the thing (since I already designed and built a 68008 SBC, albeit with fewer features). For others it may be their best way of purchasing something they can actually use, since not all of us have the background to design and build the thing ourselves.

So, please take this in the spirit it is intended--as a reframe of our conversation. I don't need to have this discussion, or the resulting design, go "my way" by any means, but I do suggest we think about those who might want to purchase a completed design rather than do the design work themselves.

Since I started the thread back in 2010 I feel I'm not "hijacking" the thread by saying that *my* original purpose was to see if I could get enough people interested in the *same* design, a design as compatible with EASy68K as possible, that we could order PCBs and (at least some of the) components in quantity, and each of us could pay a bit less to get the hardware.

Fair enough, Mark. You did, indeed, start the discussion rolling.

Also, I really intended the "hiijack" comment as a joke - so hopefully none took offense!

maalper wrote:

Many of you seem set on implementing your own individualized SBC based on the skeleton we all agree upon, but implemented and laid out with different components.

Yep, that's exactly what I had in mind.

I hear you, and understand your motivation here. I have some experience towards this - I enjoyed participating in the N8VEM Z80 CP/M project (really a wonderful community of people) which was definitely aimed at accessibility, open-ness, and the like. For people without an overflowing "junk box" the idea of a "kit" and common design, common PCB, etc. is great. I was personally a bit irked, however, when I found I had to buy a whole slew of weird TTL gates, or a specific and vintage Floppy Disk Controller chip. I found that, in my specific case, I spent MORE money on finding and buying very specific and, often, vintage components than had I simply made my OWN PCB and drawn from my own "parts on shelf". For example, you don't like the 6821 chip idea, so you've opted to make one yourself in a CPLD. That's cool. But, I happen to have a few 6821 sitting in on the shelf, and I may not want to use the came CPLD as you, etc...

maalper wrote:

So, please take this in the spirit it is intended--as a reframe of our conversation. I don't need to have this discussion, or the resulting design, go "my way" by any means, but I do suggest we think about those who might want to purchase a completed design rather than do the design work themselves.

Hmm...I think we might be in violent agreement here. If YOU have a design, and Lee has a design, and I have a design...then we have THREE designs. I've already stated that I intend to make freely available the PCB and schematic info for whatever I end up with. So if someone out there wants a "Tom" design and what I've come up with tickles their fancy - have at it. I'll probably use OSHPARK for PCB, where the lot size is three, so I'll have at least ONE extra PCB to sell at-cost.

So, I'm still thinking that there's advantages in following different paths to the hardware solution - so long as they're compatible. Of course, I'm still happy to think/consider anything related to the project, including the "student-proof" version. It's all good, IMHO. Hopefully you agree?

I really intended the "hiijack" comment as a joke - so hopefully none took offense!

I wasn't. I got that it was a joke. I also saw the irony that the word "hijacked" was used of the thread I started when, after two years, someone actually suggested something along the lines of what I was hoping when I started the thread.

Quote:

Hmm...I think we might be in violent agreement here. If YOU have a design, and Lee has a design, and I have a design...then we have THREE designs. I've already stated that I intend to make freely available the PCB and schematic info for whatever I end up with. So if someone out there wants a "Tom" design and what I've come up with tickles their fancy - have at it. I'll probably use OSHPARK for PCB, where the lot size is three, so I'll have at least ONE extra PCB to sell at-cost.

I do like the "free as in freedom" aspect of multiple designs. I'm trying to balance cost, however, because if I'm only building one then I can easily see even a decent subset of the features we're discussing on this thread costing $300 or $400 when all is said and done. My hobby budget's not big enough for that right now, so if I'm only building one I'll have to start cutting features. But I've already designed and built a rather spartan 68008 SBC, so if I'm just building a slightly different, stripped down SBC, I've got to ask myself "why bother?"

In light of that, I think I'm going to refocus on looking into designing the "student" version. I'll dump the CPLD implementation of a PIA in favor of a 65C21 that can more easily be put in a socket. I'll look at 68SEC000 for a processor because I know it is still available form common sources. I'll use Lattice ispMACH for the address decoder / system integration. I'll sift through what you all have written for other ideas.

A couple other points related to our common "skeleton." First, I'd like input, as I said eariler, regarding a common header scheme, connector scheme, or something that would allow a common interface to the system bus. It would be nice if add ons could be used across our different designs. Second, I'd like to throw out the idea of a motherboard + CPU card design approach? If the CPU and address decoder logic were on a daughtercard then it might be possible to have a common motherboard design for flash, SRAM, and optional onboard peripherals. That might make it possible to use 68008 or 68SEC000 by designing different CPU cards. Maybe it could even be designed so CPU cards with newer chips such as 68EC020 or 68340 would work.

There are already several standards that exist that could be used for your card~based approach. S100 and VME come to mind immediately. If you adopted either of them you could choose from many add~on cards.

I'm not advocating either approach ~just bringing them to your attention. VME in particular is rarely synonomous with "affordable" in hobbyist terms. The physically imposing S100 is alive and well. Google for it and you will find several current and recent projects. The ECB bus (my intro to this was the N8VEM project) is mechanically nice but somewhat Z80~centric.

I personally won't likely go the card/cage route. I have found that I would rather "start fresh" and make a whole new design for each CPU variant. Also I've found that mechanically robust card supports and bus interconnects are pricey ~ "you get what you pay for" seems to apply here. I'm certainly willing to be wrong here, so please keep us posted as to what solutions you identify.

There are already several standards that exist that could be used for your card~based approach. S100 and VME come to mind immediately. If you adopted either of them you could choose from many add~on cards.

As a colleague of mine likes to say "the nice thing about standards is that there's so many to choose from." For interfacing to off-board peripherals I'm looking for something more Arduino-like--just a definition of header or connector dimensions and defined pin assignments covering the 68000-series busses and bus control signals, and probably a handful of useful signals from the address decoder.

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.

I agreed. So I "bit" today and looked up 74LS164. It's a serial in, parallel out shift register. I must confess I'm at a bit of a loss for how and why to use a shift register for remapping. I'm planning on taking care of remapping ROM for exception vectors in the CPLD doing address decoding, so maybe it doesn't matter, but if there's extreme cleverness going on I'd certainly like to learn it.

My plan is just to have a 1-bit register that is set asynchronously when the RESET signal is asserted, and cleared when the CPU performs an access to an I/O address. The output of the register determines whether the chip select for ROM (flash, when set) or RAM (when cleared) is asserted when addresses 0x0000000 through 0x000003FF are accessed. Again, if there's a better way I'm all ears.

Who is online

Users browsing this forum: No registered users and 7 guests

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot post attachments in this forum