Look at AN897 - MC68008 Minimum configuration system.

The 74LS164 is used to generate the /MAP signal for the address decoding.

Lee.

I see, the shift register serial input is tied high, the RESET signal clears the shift register, and the Address Strobe clocks the shift register. After 8 bus cycles (enough to read the initial SSP and PC from ROM) a logic high has been shifted out. Simple enough, and easy to mimic in a CPLD.

I must say, though, I'm not a big fan of the remap happening automatically, without software intervention. First, on power up the reset handler will start executing with an uninitialized exception vector table. Any code error or bus signal glitch and *boom.* Second, the RESET instruction will also clear the shift register in this design, so the programmer has to remember to wait 8 bus cycles after a RESET instruction executes before accessing RAM at low addresses, or avoid using the RESET instruction entirely. Having done initialization with exception vector remapping before for ARM7TDMI chips, two of the first things I'm going to want to do in a reset handler are to reset peripherals and set up the exception vectors. It seems to me for someone not intimately familiar with the hardware a potential "gotcha" waiting to happen.

I'll post here if I come up with a thought for turning remap off in software.

You shouldn't be getting code errors before the vector table has been copied to RAM, it only takes a few dozen cycles to copy the most used vectors. A bus glitch or even a hardware interrupt shouldn't be happening this soon after a reset, if they do something is probably broken and nothing I know can protect you from hardware that just doesn't work.

Someone who is writing code that uses the RESET opcode to assert the reset line should be at least a bit familiar with the hardware to be doing such a thing so it's not a huge ask to expect them to know this. However this can easily be avoided entirely by either gating the shift register reset with the halt signal or simply using the power on reset signal to reset the shift register.

I like this solution a lot because it is about as transparent a solution as you can get and unlike solutions that use a port bit it requires no code to work. It also works for all bus widths, just use a different output, so the same circuit can work for all processors.

Lee.

Since we're bringing the address bus, data bus, and presumably some IRQ lines out to expansion headers a user could very easily see problems creep in when something's plugged in that the system designer will never see. Such problems (too much capacitance, cross talk, etc.) can be notoriously intermittent and/or hard to replicate. It isn't that the hardware "just doesn't work," but that it mostly works, or that it always works right up to some point in executing the code, then crashes. Such problems aren't solved with properly initialized exception vectors, of course, but I pity anyone having to debug a system where the code executes correctly until just before the exception vector he/she is accidentally triggering is valid.

A lot of these types of issues could be helped by inserting bus buffers into the design between the onboard busses and the headers for the bus signals. I'll look at doing that, since I'm wanting to design the "student" version. That won't protect from premature IRQs, of course.



Regarding using power up reset to clear the shift register, I had the same thought.



I was thinking of doing remap completely in my address decoder CPLD, in which case the circuitry issue becomes irrelevant, and I can put off the decision 'till later. For what it's worth, my original idea was that a remap flip-flop would be set one way when a power on reset pin is asserted, then be set the other way by a CPU access to some specific address or address range the CPLD could decode--the first access to an I/O address, for example. For that to work, however, I'd have to mirror SRAM somewhere in the address space to allow writes to the exception vector table while remap is active. BIOS-es written for the two methods would be incompatible.

Maybe I'm being paranoid, but I've still got a rather sore "bug bite" from a boot code issue where I work. A project of mine from 2011 was delayed for more than six months while we tried to find the cause behind some percentage of the PCBs occasionally failing to boot. In the end we learned that on that particular microcontroller, resetting the watchdog timer right before writing the watchdog timer configuration was bad. Nowhere in the chip manufacturer's documentation did it *say* it was a bad idea or that it could be a bad idea--they told us this after they were finally able to reproduce it on their end and admitted we'd helped them discover an erratum in their silicon.

When the product exhibited the problem it showed up as a continuous reboot "loop" where the firmware would execute just fine until the watchdog was configured, then reset itself, then repeat. Whether or not the reboot happened was dependent on the phase between the CPU clock, which was crystal-controlled, and an internal RC oscillator. Because of this it was highly dependent on temperature and even physical force applied to the MCU. Anything that changed the frequency of the RC oscillator, and thus its phase at the critical moment, was a factor. Take a PCB that was in the reboot "loop" and twist it, and it would stop rebooting. Take one that wasn't rebooting and twist it, and you might trigger it. We also found by trial and error it didn't happen at all with certain watchdog configurations.

I like the suggestion of gating the MAP shiftreg reset with the halt signal - never considered that before.

Personally, I don't worry about the time-tested LS164 MAP approach, but to me, there's nothing wrong some other MAP mechanism, so long as it's understood/documented in the boot code how to negate MAP. I have to say that the "transparent" MAP approach is almost universal, as far as I can tell. I do hate to break from tradition on something like this.

(consumed by other things lately, but looking forward to more time to ponder the schematics and think about PCB layout during the holidays!)

-tom

Hi all,

It's been quite a while, and I wanted to post a quick update. First, I accepted the job of CTO in January, and I've been quite a bit busier as a result. I finally got some time this last weekend to dive back into this, though, and got a little done. I evaluated a UART from NXP, their SCC2691, by connecting it to my existing 68008 design. My goal is to pick a second UART chip to sit alongside a 68681 to have 3 or 4 UART channels in the final design. One UART can then be dedicated to interfacing with a PC and/or with GDB as I'd previously discussed. I'm probably going to use the newer SC28L91 on the design, but the very similar SCC2691 was available in a DIP package for easy breadboarding, whereas the SC28L91 is not.

As of this morning I had tested some code that configured the SCC2691's transmitter and sent "UU" at 9600 baud. This demonstrated writes to the UART's registers are working. The code checked the TXRDY bit in the UART's SR before sending the second 'U' character, providing some verification that reading one of the UART's registers worked.

My next exercise will be to run a similar test on the W65C22 to settle on the bench the question of whether it can be made to "work" asynchronously (i.e. it's "PHI2" pin only transitioning during 68000 bus accesses), or whether it really needs 6800-compatible synchronous bus accesses.

Mark

I got W65C22 talking to my 68008 board last night using the synchronous (E, VPA, VMA) signals. I first had to fix a bug in my GAL address decoder code where the USRIO strobe indicating an access to the expansion I/O address space was asserted when the 68008 let go of the busses (it wasn't conditioned on the processor's AS signal).

After synchronous access was working I tried a quick asynchronous access test by simply inverting the active low signal indicating an access to the W65C22 and supplying that for its PHI2 (E) signal. I reasoned that the W65C22 times its transfers with the falling edge of PHI2, and the 68008 clocks in data at the rising edge of DS, which rises at the same time as AS. This failed miserably, which didn't surprise me. What was interesting, though, is that an LED I had connected to one of the port I/O pins of the W65C22 started flickering on and off irregularly after an attempt to write to the output register for that port, and the chip select for the W65C22 was negated by that point (the LED was connected exactly as it was in the synchronous operation test, which worked as expected).

While the asynchronous access test was certainly naive in its methodology, the fact that I saw the LED behavior when none of the control lines for the W65C22 were changing state convinced me to abandon the asynchronous access path and stick with talking to it as its designers intended, synchronized to a steady PHI2 clock. That means in order to use a MC68SEC000 I'll have to design my own E clock generation and synchronization logic. The design is narrowing in on a well-defined list of tasks.

Long time, no post! As of late 2013 I'm at a new job with a wee bit more free time--still have small kids, though, so not that much.

A few weeks ago I finished working on changing the GAL code on my 68008 design to boot with flash remapped to address zero, then after boot set RAM to address zero so that exception vectors can be changed. That design has no convenient boot circuit as previously discussed, so I wired a jumper from a spare GAL pin now used to do the remap, to a GPIO pin on the MC68901.

I then wrote a boot loader to allow serial upload of the main BIOS code as an S-Record and program it to flash. It makes firmware updates quick compared to pulling and re-flashing the IC.

Tonight I've been digging into implementing as many of the Trap #15 tasks as is practical on a board with little else than a single UART. I wrapped up by loading and running Lee Davison's "mhz" example that measures estimated CPU speed. It's reporting an average of about 5.039 MHz. This makes sense since the 68008 on my board is running at 10 MHz, and the 68008 has an 8-bit data bus, making most instructions take twice as long in processor cycles to execute.

Mark

hi guys
any news for the board ? have you already designed and built it ?
let me know =)

I read this very informative thread with great interests. There are many well thought out ideas here. I like to add my 2 cents by suggesting the Motorola 68302. I don't have a long experience with the 68302, but I delved into it at some depth in the last couple months trying to use some of its many features on a batch of re-purposed single board computers. It turns out the 68302 has a 68000/68008 core (8-bit or 16-bit external bus), a system integration block (programmable chip selects, interrupt controller, timers, bus arbitration), and a powerful communication processor (3 serial ports + SPI). So with one 68K CPU we have just about all the peripheral features mentioned in this discussion thread. It seems to me a minimal 68302 system can be built with a RAM chip and a flash chip (plus an oscillator). That ought to keep the cost down. A quick check on eBay shows a 16MHz 68302 for $14, even a batch of 5x68302 +4x68030 for $66 (I'm not associated with these sellers), so the CPU is pretty cheap.

On a separate note, I was shocked and sadden to learn that lee is no longer with us. Over the past 24 hour of perusing this excellent forum, I became a great admirer of him and was looking forward to correspond with him only to learn late last night that he'd passed in 2013 at age 49. I can only see the foot prints he left behind but I wish I know the man!

Has there been any activity on the EASy68K compatible 68000 computer?
I have a 68K SBC with 2MB SRAM and 1MB Flash that I'd like to get linked up to some type of Development Environment to speed things up. Currently it has boot code for CP/M 68K in flash and a monitor program.
I'm also considering using Joseph Zatarski's Timesharing/Multiuser version of EhBASIC v3.5.2 in the flash on this board. I have been away from this forum for a while now so I need to get some reading done.
What I'd really like to get done is to get OS-9 68K running on this board. I've found code on the internet. I just don't know how to go about porting something that big.
All the little 68K boards are very interesting. I'm going to do some more reading.
If anyone is interested in this project or any related project ideas of any kind, shoot me an email to computerdoc at sc dot rr dot com. Take care my friends.

Glad to see the forum is back up and running.

computerdoc,
Could you point me to a source of CP/M68K? I'm ready to add Compact Flash IDE interface to my Tinyxxx, so I'm ready to implement a version of CP/M for the 68K. I also looking for a multi-task OS. I thought of uCOS, but OS-9 would be very interesting as well.

There are so much surplus parts available on eBay and cheap parts from China (including low-cost pc board), that I'm thinking seriously about designing a DIY 68K board for $10 part cost. I know I can keep it at $10 when calculating base on how much I paid for my existing stock of parts, but my stocks were accumulated over a course of 5-10 years, so the question is whether it is sustainable. Even if the $10 target is exceeded, I think the mindset of designing with a strong cost control goal (especially for the entry-level 68000 board) is important.