Hi,
I've been building the N8VEM 68K board and have had a really good time doing it. It's been logged on a private site so far but we have reached a point where all seems to be working properly so I've decide to make the build log public now. Someone may fins it interesting and/or find pointers and tips in it for their own projects. You're naturally welcome to give comments and/or suggestions to it.
This is just a text copy from the private site but I will be adding pictures to it when I get the time to do so.
At this point, we're ready to start porting CP/M-68 to it. I will be waiting to receive the N8VEM ZDFC cards to do so but anyone with pointers or tips are welcome to post here.
Happy hacking all
Thanks
/Pontus
2011-03-21: Back on track again.
I managed to spend a few hours this last weekend sorting out the last S-100 bus issues.
First of all, in order to make the SRAM board work in our 68K system, three TTL devices on the SRAM card need to be exchanged to faster versions in order to meet the required setup time of the write signal at the SRAM's. Devices U12, U13 and U15 need to be exchanged for faster versions. I replaced them on by board with F versions and it seem to work. A quick propagation delay analysis also indicates that it should work. Note that this setup time does not have anything to do with the clock speed of the 68000. Downgrading the clock will not give you the desired result.
So.. the system now works as mr. Wilcox intended it to work at 6MHz processor clock speed.
But I wanted to be able to run the board at full speed that is at 8MHz. I have previously run the board at 8MHz without any problems. It was not until the S-100 sequencer was incorporated that the problems started. After some calculations I figured out that I was a bit off on the BCYCLE signal, which did not meet the setup time for the register (U37), controlling the state machine. I quickly tested to replace U36 with a F version of the device and low and behold it ran as beautifully as before at 8MHz. I did some calculating on the delay times and it looks as we are okay with replacing that device. According to the red book there also a critical line at the DTACK* generation and adding wait states with the S-100 RDY input. I tested to add one wait state and it worked in my system but to be safe I also replaced U46 to a F version so it now also theoretically works.
Summary:
On the SRAM board, replace the following devices:
o U12 - SN74F11
o U13 - SN74F11
o U15 - SN74F02
And on the CPU board
o U36 - SN74F10
o U46 - SN74F02
Next up is the interrupt system and exception handling, which should be the last things to verify.....
2011-03-13: Noops, it aint working......
I received a new shipment of sockets and some other stuff that I needed, and got the SRAM board mounted pretty quick. I tested the board in a known working system and all looked good initially.
Next I plugged the SRAM board into my 68K system and started it up. Initially I just tested to read from the board and it works fine, it's all random data in there. Next I tried to write to the RAM but right there is where the fun stopped. I hooked my logic analyzer up to see what was going on. After some debugging I noticed that the S-100 state machine seemed to generate a pWR* signal that seemed delayed and extremely short. I placed the CPU card on a raiser card in order to be able to debug it simultaneously. After some digging I found that the state machine didn't work at 8MHz system clock. Setup times weren't met properly resulting in the pWR* signal getting out of sync. So I switched to a 4.9MHz crystal (the only one I had at hand) and the state machine started to work as expected. I think I need to go back to the book and read the chapter about the statemachine again and see if it can be optimized to work even at 8MHz.
Anyway, I felt relieved and quite confident that I had solved the problem, so I detached the logic analyzer, put it in the drawer and restarted the system again. Aaaaaaaand..... no go. Writing still did not work. Packed the logic analyzer up again and hooked it up to the memory board. This time all looked good at initial examinations and I could not understand what was going on. I worked my way through the signals verifying that they looked okay. After a while I recognized a pattern in the write failures and remembered a similar problem I had on another system. I zoomed in on the write negation and had the data signals in the display at the same time and noticed that the write signal was negated after data had started to garble (see picture below):
pWR* is the incoming write signal to the board, WE_EVEN* is the write signal on the memory chip. RAMD[7..0] is the data signals on hte ram chip. Notice that WE_EVEN* is rising during the time that data is destabilizing. The delay between A and B *pWR going high and WE_EVEN* going high is 30nS which is due to the decoding logic on the RAM board. The pWR* should probably have been in the last section of the decoding logic, or even better the CS signal should have been used to qualify what device (odd or even) to select and the WR term could have been really simple. Maybe even MWRT could have been used.
Data hold time from pWR* negating on the 68K board is around 20nS so this is what I need to aim for. Maybe it is possible by exchanging the devices affected to F type or ALS to reduce the propagation delay.
Anyway, here's a picture of my current test setup.
All for now.
2011-03-03: Out of DIP-14 sockets *grrr*
I had planned to spend the evening building and at least starting to test a N8VEM 4MEG SRAM board when I found that someone had been using all my DIP14 sockets. I distinctly remember that I bought 250 of them just six months ago, but when I reached for a tube they were nowhere to be found. I'm not exactly sure how I could have spent 250 sockets in just six months but the empty drawer speaks for itself. So I soldered what I could and I will have to take a trip to the local socket monger tomorrow so that the weekend doesn't get completely wasted. A picture of what I've done so far....
One thing with this board is that it's real hard to do good solder joints on grounded pads. They are all connected directly to a fill area (without thermal reliefs) so they do need a good heating before applying solder. Otherwise it is a beautiful board, very fun to build.
I also uploaded the source code for my revised Tutor monitor as well as the binaries so you can program your proms directly. If you have any questions don't hesitate to ask.
2011-03-02: Resuming 68K board effort again.
I've been really busy lately working on several projects at once, but finally have a little bit of time for the 68K board again. I received the 4MEG SRAM boards yesterday and will build one of these to finally test the S-100 memory interface. For the rest of you building this version of the board I'll make sure to upload the Tutor 1.3 sources and binaries to make it easy for you to get things going. This version depends on you having the N8VEM SIO board, if you don't you need to make your own changes to the Tutor source code to fit the UART board that you have. A simple diff between my source and the original one should get you in the right direction.
2011-01-29: CP/M 68K beginnings
After having worked quite intensely on the 68K board for some time and having started to build a SRAM board, at the same time as having a very intense period at work, I decided to hold the work on the hardware for a while.I now wanted to start taking a look at the CPM 68K sources and see what I could do with it. After having downloaded the source code and starting to play around with different tools I decided to go ahead and port the sources to compile with the GCC tool chain instead. The source files are a mixture of 68K assembly and C language and quite well documented.
So I spent a few hours playing with the cpm loader (cpmldr) and a it turns out it was very easy to port that package to build with the gcc tools. I created a simple makefile that builds all files and links them together into a binary. The gcc utility objcopy can then be used to create a S-records or whatever you need. I have uploaded the source package for the loader here (bootldr.tar) so anyone can test it. The compiler I used is the one I uploaded here some time ago, it should work on any Debian or Ubuntu box.
Note that no testing whatsoever has gone into the package, it has just been compiled and test linked. There is also no linker control file yet so it gets some weird high address to it. However, using objdump one can see that the resulting code should be loadable and startable.
2011-01-23: Touchdown !
Just a short update, Tutor 1.3 is now humming along on my system. It took a little longer than anticipated due to my own incapability of reading the Z8530 datasheet properly. Once I had that figured out it was pretty easy. I have gone through and modified all code related to serial transfers, although I don't expect anyone ever to test the tape reading functions.
Since I don't have a S-100 memory board (have them on order though) I can not yet verify that the ready signal arbitration works but looking at the schematics I don't expect any problems here either. Andrew has just done a fantastic job porting the Wilcox schematics to electronic format.
A short video as well as the source and binaries to Tutor will be available shortly. Now I'm going to spend some time with wifey.
2011-01-10: Moving to a proper motherboard
Just a short update. I verified that calling functions and accessing RAM worked properly as well as nothing happened when I inserted the S100 bus data bus drivers. All works as expected so far, even without any waitstates on the local bus.
So I decided to move ahead and start verifying the S100 bus interface. For this I needed a motherboard and decided to dedicate an early version of the N8VEM motherboard to this platform.
Here's how it looks now, the smoke test passed so I'll start verifying the S100 interface in my next session and hopefully be able to see some data comming through the serial ports.
2011-01-06: Executing code and accessing SRAM
Today I set out to, at least, be able to have the board execute a short scope-loop but it all wen better than expected. The first attempt was using a scope loop taken from Wilcox book (page 163). The board was configured to address EPROM (FLASH) at $00000000, and the first test was successful. The board was executing real code for the first time, although only one instruction in a loop, but still. Inspired by my success I went on to test the boot sequencer. The EPROM area was configured to $00008000 and the J15 jumper was installed to enable the boot sequencer. A short note for you other builders of the board, J14 is rotated 90 degrees so the settings in the book need to be adjusted accordingly. Before starting the board again I needed to patch the software to handle the new configuration. Below is the listing for the new software:
00008000 1 ORG $8000
00008000= 00000000 2 DC.L 0
00008004= 00008008 3 DC.L START
00008008 4 START
00008008 4EF9 00008008 5 JMP START
The board started up and behaved exactly as expected, so I was quite pleased. At this point I decided to abandon the 2 MHz system crystal and move up to a 16 MHz crystal, having an 8 MHz system frequency. I spent some time with the logic analyzer making sure that memory access parameters were met but I have yet to find any problems in that area.
To end my session I decided to move ahead and install the SRAMs and get them working. I wrote a short program that was going to be easy to follow on the logic analyzer to make debugging easy. The listing of that program below:
*
00000000 =00010000 7 STACK EQU $00010000
00000000 =00000000 8 MEMSTART equ $00000000
00000000 =00007FFF 9 MEMEND equ $00007fff
00000000 10
00008000 11 ORG $8000
00008000= 00010000 12 DC.L STACK
00008004= 00008008 13 DC.L START
00008008 14
00008008 15 ; We are goig to do a simple memory test here, just to see that
00008008 16 ; RAM is accessable and that it works properly.
00008008 17 ;
00008008 18 ; First we simply write a few values to the first memory location
00008008 19 ; to see that it works as expected.
00008008 41F8 0000 20 START lea MEMSTART,A0
0000800C 21
0000800C 303C 0000 22 move.w #0,D0
00008010 3080 23 move.w D0,(A0)
00008012 B050 24 cmp.w (A0),D0
00008014 66F2 25 bne START
00008016 26
00008016 303C FFFF 27 move.w #$ffff,D0
0000801A 3080 28 move.w D0,(A0)
0000801C B050 29 cmp.w (A0),D0
0000801E 66E8 30 bne START
00008020 31
00008020 303C AAAA 32 move.w #$aaaa,D0
00008024 3080 33 move.w D0,(A0)
00008026 B050 34 cmp.w (A0),D0
00008028 66DE 35 bne START
0000802A 36
0000802A 303C 5555 37 move.w #$5555,D0
0000802E 3080 38 move.w D0,(A0)
00008030 B050 39 cmp.w (A0),D0
00008032 66D4 40 bne START
00008034 41
00008034 4EF9 00008034 42 LOOP jmp LOOP
0000803A 46
0000803A 47 END START ; last line of source
(Easy68K was used to create these test programs)
So I flashed the program and started the board again aaaaand...... Dooh, No, didn't work. I hooked the logic analyzer up to trace all SRAM control signals and saw that the WE* signal was being pulled continuously low. I suspected the configuration headers and pulled the schematic up to dig a little deeper. After some browsing and thinking it struck me that I had pulled A14 low on the AT29C256 FLASH that I am using in the EPROM sockets. Since that pin is the same pin as the WE* pins on the SRAM's they were being pulled low, causing the write operation to fail. I removed the SRAM's and cut the line going from pin 27 of the PAIR2 block to the PAIR1 block, put the SRAM's back and flicked to power switch on and voila, it worked. Please note that if you are using 16KByte EPROM's (27C128) this is not a necessary operation, I'm using the FLASH memories since they are easier to work with than EPROM's. Although if the board should be respun we should probably keep this in mind and change the configuration headers.
In my next session I'll make sure that stack operations are working as expected, after which I can start debugging the S-100 interface. My objective is to be able to access a N8VEM Serial IO card in order to have the Motorola monitor Tutor up and running.
And as always, I'll en my report by adding a meaningless picture of the board being probed.
2011-01-03: Wait state generator
So, today I intended to verify the operation of the wait state generator. Seemed like an easy enough thing to do when you just have woken up
I started out by verifying that the number of wait states for I/O area could be changed. No problem there, I could go from 0 up to 8 wait states without any problems. Next I was going to verify the Local area. But no matter what setting I changed to I still had 0 wait states. I started probing the board with some simple tests but couldn't easy identify the problem. I then started to review the wait state section of the schematic and found the problem rather quickly. Looking at the original schematics (Page 495) by mr. Wilcox, he has identified the function of the LS151 mux input pins with logical names. These logical names can also be found on our (N8VEM 68k) schematics, but the problem here is that these identifiers now becomes nodes in the netlist. The names I/O, M1 and ALL do not appear on any other place in our schematic but LOCAL is already a net which means that the LS151 mux LOCAL net now connects to the global LOCAL net. To verify that I am correct in this, I have measured the net as well as lifted pins 14 and 15 from U33 and connected it directly to the shift register and it now works as expected.
M1 and ALL both as expected so if we can just get rid of the net names on U33, LOCAL will also work as expected.
Another thing I noted when reading the book again, on page 184 (figure 9.17) there is a small note on how the signals POC*, RESET* and SLAVE-CLEAR* is expected to be pulled up by the external bus. This is in line with the specification but I wonder if it's correct that the permanent master makes assumptions about the system that it is running in (discussion please). For instance, in my IMSAI I do not have any active termination, although it may be necessary when running a 68K board in it.
Anyhow, next thing will be to run a small program from EPROM/FLASH that is easy to follow on the logic analyzer.
(Still not to messy to debug)
2010-12-31: Freerun is verified
After having a really nasty flu which forced me in bed for the last week I finally had the strength to play some more with the 68k board. The board was configured to 0 wait states for all address regions, two zero data adapters were made and plugged in. I removed the SRAM and data bus buffer IC's to avoid any collisions. The first tests were no go's so I started to investigate the board. After a while I discovered that it did not reset properly. After glancing at the schematics I found out that the BUS_RESET* signal did not have any pull upp, so the 555 was never triggered. I soldered a 4.7K resistor to pull this signal up and the BUS_RESET* signal worked as expected. The board did however not start so I hooked my trusty logic analyzer up and saw that the reset still did not come through to the processor. A little more digging revealed that the POC* pulse was to short, so I installed a 100uF/16V cap instead and voila, the board freeruns.......
Worth to note is also that the oscillator in place is a 2MHz oscillator, thus running the 68000 on 1MHz. That's why the LED blinks so slowly.
This images shows how the BUS_RESET* pull up resistor was placed (Sorry about the crappy quality.)
So, the board certainly seem prepared to start testing executing a little code from PAIR1 EPROM's so that'll be the next thing I will concentrate on.
2010-12-25: Board Mounted
It took a while to get the time to finish the board, but now it is done. Next I need to configure the board for the memories I'm using as well as watchdog and the other functions. The Allan Wilcox book also got here (finally) just before Christmas so I should be all set to start debugging (if any) and get the board running.
2010-12-02: Reset block mounted and tested
We're currently snowed in and I have been busy shoveling snow the last couple of days, but I managed to find the time to mount and test the reset generator. And it.... well it works as expected. I also found that while purchasing all IC's that the 74LS352 devices are very hard to find. Luckily I had some devices in my TTL stock but if the board is re spun at some point they should probably be designed out to avoid further problems.
Recommended Changes:
Redesign the board to get rid of SN74LS352 devices.
2010-11-26: GCC compiler toolchain
I managed to get the entire toolchain built using newlib as the c-library. As this toolchain is intended for our S-100 68k-board I wanted to be able to customize sbrk and the generic I/O functionality, so this was completely disabled in newlib (no stubs either). I will write a basic library supplying these basic functions, but they will most likely need customization for different hardware configurations and systems.
2010-11-25: Power and oscillator mounted and tested.
Yesterday I mounted the voltage regulators and cap's associated with them as well as the oscillator (U29) and the following 74F74 (U30) frequency divider.
One thing that I have noticed is that thermal ground pads are difficult to heat properly. This is most likely due to that many ground pads are connected to both the top and bottom layer with pretty wide thermal spokes. Some pads also seem to have a routed wire connected to them which also adds to the ability to dissipate heat from the pad.
Anyway, the oscillator started up fine and two nice clock signals are shown on my scope. I only had a 8-pin configuration oscillator and had to patch the board to supply +5V to pin 11 as well.
Recommended Changes:
Thermal Reliefs: I suggest that the width of the spokes is reduced slightly and maybe that the the isolation clearance is increased slightly to make it easier to solder these pads.
U29
Connect +5V (VCC) to pin 11 as well so that 8-pin type oscillators can be used.
2010-11-23: S-100 68K Board Received !
So I received the 68K S-100 board PCB from Andrew yesterday. After a good looking over I started to mount a few items, just to get the feeling that I have gotten started. The board looks very good although I am slightly allergic to some things that autorouters keep insisting on getting wrong.
It's a pretty complex board so I will be spending quite some time on verifying that parameters are within specification. This page will hold all the results of this. That's all for now, stay tuned.
I've been building the N8VEM 68K board and have had a really good time doing it. It's been logged on a private site so far but we have reached a point where all seems to be working properly so I've decide to make the build log public now. Someone may fins it interesting and/or find pointers and tips in it for their own projects. You're naturally welcome to give comments and/or suggestions to it.
This is just a text copy from the private site but I will be adding pictures to it when I get the time to do so.
At this point, we're ready to start porting CP/M-68 to it. I will be waiting to receive the N8VEM ZDFC cards to do so but anyone with pointers or tips are welcome to post here.
Happy hacking all
Thanks
/Pontus
2011-03-21: Back on track again.
I managed to spend a few hours this last weekend sorting out the last S-100 bus issues.
First of all, in order to make the SRAM board work in our 68K system, three TTL devices on the SRAM card need to be exchanged to faster versions in order to meet the required setup time of the write signal at the SRAM's. Devices U12, U13 and U15 need to be exchanged for faster versions. I replaced them on by board with F versions and it seem to work. A quick propagation delay analysis also indicates that it should work. Note that this setup time does not have anything to do with the clock speed of the 68000. Downgrading the clock will not give you the desired result.
So.. the system now works as mr. Wilcox intended it to work at 6MHz processor clock speed.
But I wanted to be able to run the board at full speed that is at 8MHz. I have previously run the board at 8MHz without any problems. It was not until the S-100 sequencer was incorporated that the problems started. After some calculations I figured out that I was a bit off on the BCYCLE signal, which did not meet the setup time for the register (U37), controlling the state machine. I quickly tested to replace U36 with a F version of the device and low and behold it ran as beautifully as before at 8MHz. I did some calculating on the delay times and it looks as we are okay with replacing that device. According to the red book there also a critical line at the DTACK* generation and adding wait states with the S-100 RDY input. I tested to add one wait state and it worked in my system but to be safe I also replaced U46 to a F version so it now also theoretically works.
Summary:
On the SRAM board, replace the following devices:
o U12 - SN74F11
o U13 - SN74F11
o U15 - SN74F02
And on the CPU board
o U36 - SN74F10
o U46 - SN74F02
Next up is the interrupt system and exception handling, which should be the last things to verify.....
2011-03-13: Noops, it aint working......
I received a new shipment of sockets and some other stuff that I needed, and got the SRAM board mounted pretty quick. I tested the board in a known working system and all looked good initially.
Next I plugged the SRAM board into my 68K system and started it up. Initially I just tested to read from the board and it works fine, it's all random data in there. Next I tried to write to the RAM but right there is where the fun stopped. I hooked my logic analyzer up to see what was going on. After some debugging I noticed that the S-100 state machine seemed to generate a pWR* signal that seemed delayed and extremely short. I placed the CPU card on a raiser card in order to be able to debug it simultaneously. After some digging I found that the state machine didn't work at 8MHz system clock. Setup times weren't met properly resulting in the pWR* signal getting out of sync. So I switched to a 4.9MHz crystal (the only one I had at hand) and the state machine started to work as expected. I think I need to go back to the book and read the chapter about the statemachine again and see if it can be optimized to work even at 8MHz.
Anyway, I felt relieved and quite confident that I had solved the problem, so I detached the logic analyzer, put it in the drawer and restarted the system again. Aaaaaaaand..... no go. Writing still did not work. Packed the logic analyzer up again and hooked it up to the memory board. This time all looked good at initial examinations and I could not understand what was going on. I worked my way through the signals verifying that they looked okay. After a while I recognized a pattern in the write failures and remembered a similar problem I had on another system. I zoomed in on the write negation and had the data signals in the display at the same time and noticed that the write signal was negated after data had started to garble (see picture below):
pWR* is the incoming write signal to the board, WE_EVEN* is the write signal on the memory chip. RAMD[7..0] is the data signals on hte ram chip. Notice that WE_EVEN* is rising during the time that data is destabilizing. The delay between A and B *pWR going high and WE_EVEN* going high is 30nS which is due to the decoding logic on the RAM board. The pWR* should probably have been in the last section of the decoding logic, or even better the CS signal should have been used to qualify what device (odd or even) to select and the WR term could have been really simple. Maybe even MWRT could have been used.
Data hold time from pWR* negating on the 68K board is around 20nS so this is what I need to aim for. Maybe it is possible by exchanging the devices affected to F type or ALS to reduce the propagation delay.
Anyway, here's a picture of my current test setup.
All for now.
2011-03-03: Out of DIP-14 sockets *grrr*
I had planned to spend the evening building and at least starting to test a N8VEM 4MEG SRAM board when I found that someone had been using all my DIP14 sockets. I distinctly remember that I bought 250 of them just six months ago, but when I reached for a tube they were nowhere to be found. I'm not exactly sure how I could have spent 250 sockets in just six months but the empty drawer speaks for itself. So I soldered what I could and I will have to take a trip to the local socket monger tomorrow so that the weekend doesn't get completely wasted. A picture of what I've done so far....
One thing with this board is that it's real hard to do good solder joints on grounded pads. They are all connected directly to a fill area (without thermal reliefs) so they do need a good heating before applying solder. Otherwise it is a beautiful board, very fun to build.
I also uploaded the source code for my revised Tutor monitor as well as the binaries so you can program your proms directly. If you have any questions don't hesitate to ask.
2011-03-02: Resuming 68K board effort again.
I've been really busy lately working on several projects at once, but finally have a little bit of time for the 68K board again. I received the 4MEG SRAM boards yesterday and will build one of these to finally test the S-100 memory interface. For the rest of you building this version of the board I'll make sure to upload the Tutor 1.3 sources and binaries to make it easy for you to get things going. This version depends on you having the N8VEM SIO board, if you don't you need to make your own changes to the Tutor source code to fit the UART board that you have. A simple diff between my source and the original one should get you in the right direction.
2011-01-29: CP/M 68K beginnings
After having worked quite intensely on the 68K board for some time and having started to build a SRAM board, at the same time as having a very intense period at work, I decided to hold the work on the hardware for a while.I now wanted to start taking a look at the CPM 68K sources and see what I could do with it. After having downloaded the source code and starting to play around with different tools I decided to go ahead and port the sources to compile with the GCC tool chain instead. The source files are a mixture of 68K assembly and C language and quite well documented.
So I spent a few hours playing with the cpm loader (cpmldr) and a it turns out it was very easy to port that package to build with the gcc tools. I created a simple makefile that builds all files and links them together into a binary. The gcc utility objcopy can then be used to create a S-records or whatever you need. I have uploaded the source package for the loader here (bootldr.tar) so anyone can test it. The compiler I used is the one I uploaded here some time ago, it should work on any Debian or Ubuntu box.
Note that no testing whatsoever has gone into the package, it has just been compiled and test linked. There is also no linker control file yet so it gets some weird high address to it. However, using objdump one can see that the resulting code should be loadable and startable.
2011-01-23: Touchdown !
Just a short update, Tutor 1.3 is now humming along on my system. It took a little longer than anticipated due to my own incapability of reading the Z8530 datasheet properly. Once I had that figured out it was pretty easy. I have gone through and modified all code related to serial transfers, although I don't expect anyone ever to test the tape reading functions.
Since I don't have a S-100 memory board (have them on order though) I can not yet verify that the ready signal arbitration works but looking at the schematics I don't expect any problems here either. Andrew has just done a fantastic job porting the Wilcox schematics to electronic format.
A short video as well as the source and binaries to Tutor will be available shortly. Now I'm going to spend some time with wifey.
2011-01-10: Moving to a proper motherboard
Just a short update. I verified that calling functions and accessing RAM worked properly as well as nothing happened when I inserted the S100 bus data bus drivers. All works as expected so far, even without any waitstates on the local bus.
So I decided to move ahead and start verifying the S100 bus interface. For this I needed a motherboard and decided to dedicate an early version of the N8VEM motherboard to this platform.
Here's how it looks now, the smoke test passed so I'll start verifying the S100 interface in my next session and hopefully be able to see some data comming through the serial ports.
2011-01-06: Executing code and accessing SRAM
Today I set out to, at least, be able to have the board execute a short scope-loop but it all wen better than expected. The first attempt was using a scope loop taken from Wilcox book (page 163). The board was configured to address EPROM (FLASH) at $00000000, and the first test was successful. The board was executing real code for the first time, although only one instruction in a loop, but still. Inspired by my success I went on to test the boot sequencer. The EPROM area was configured to $00008000 and the J15 jumper was installed to enable the boot sequencer. A short note for you other builders of the board, J14 is rotated 90 degrees so the settings in the book need to be adjusted accordingly. Before starting the board again I needed to patch the software to handle the new configuration. Below is the listing for the new software:
00008000 1 ORG $8000
00008000= 00000000 2 DC.L 0
00008004= 00008008 3 DC.L START
00008008 4 START
00008008 4EF9 00008008 5 JMP START
The board started up and behaved exactly as expected, so I was quite pleased. At this point I decided to abandon the 2 MHz system crystal and move up to a 16 MHz crystal, having an 8 MHz system frequency. I spent some time with the logic analyzer making sure that memory access parameters were met but I have yet to find any problems in that area.
To end my session I decided to move ahead and install the SRAMs and get them working. I wrote a short program that was going to be easy to follow on the logic analyzer to make debugging easy. The listing of that program below:
*
00000000 =00010000 7 STACK EQU $00010000
00000000 =00000000 8 MEMSTART equ $00000000
00000000 =00007FFF 9 MEMEND equ $00007fff
00000000 10
00008000 11 ORG $8000
00008000= 00010000 12 DC.L STACK
00008004= 00008008 13 DC.L START
00008008 14
00008008 15 ; We are goig to do a simple memory test here, just to see that
00008008 16 ; RAM is accessable and that it works properly.
00008008 17 ;
00008008 18 ; First we simply write a few values to the first memory location
00008008 19 ; to see that it works as expected.
00008008 41F8 0000 20 START lea MEMSTART,A0
0000800C 21
0000800C 303C 0000 22 move.w #0,D0
00008010 3080 23 move.w D0,(A0)
00008012 B050 24 cmp.w (A0),D0
00008014 66F2 25 bne START
00008016 26
00008016 303C FFFF 27 move.w #$ffff,D0
0000801A 3080 28 move.w D0,(A0)
0000801C B050 29 cmp.w (A0),D0
0000801E 66E8 30 bne START
00008020 31
00008020 303C AAAA 32 move.w #$aaaa,D0
00008024 3080 33 move.w D0,(A0)
00008026 B050 34 cmp.w (A0),D0
00008028 66DE 35 bne START
0000802A 36
0000802A 303C 5555 37 move.w #$5555,D0
0000802E 3080 38 move.w D0,(A0)
00008030 B050 39 cmp.w (A0),D0
00008032 66D4 40 bne START
00008034 41
00008034 4EF9 00008034 42 LOOP jmp LOOP
0000803A 46
0000803A 47 END START ; last line of source
(Easy68K was used to create these test programs)
So I flashed the program and started the board again aaaaand...... Dooh, No, didn't work. I hooked the logic analyzer up to trace all SRAM control signals and saw that the WE* signal was being pulled continuously low. I suspected the configuration headers and pulled the schematic up to dig a little deeper. After some browsing and thinking it struck me that I had pulled A14 low on the AT29C256 FLASH that I am using in the EPROM sockets. Since that pin is the same pin as the WE* pins on the SRAM's they were being pulled low, causing the write operation to fail. I removed the SRAM's and cut the line going from pin 27 of the PAIR2 block to the PAIR1 block, put the SRAM's back and flicked to power switch on and voila, it worked. Please note that if you are using 16KByte EPROM's (27C128) this is not a necessary operation, I'm using the FLASH memories since they are easier to work with than EPROM's. Although if the board should be respun we should probably keep this in mind and change the configuration headers.
In my next session I'll make sure that stack operations are working as expected, after which I can start debugging the S-100 interface. My objective is to be able to access a N8VEM Serial IO card in order to have the Motorola monitor Tutor up and running.
And as always, I'll en my report by adding a meaningless picture of the board being probed.
2011-01-03: Wait state generator
So, today I intended to verify the operation of the wait state generator. Seemed like an easy enough thing to do when you just have woken up
I started out by verifying that the number of wait states for I/O area could be changed. No problem there, I could go from 0 up to 8 wait states without any problems. Next I was going to verify the Local area. But no matter what setting I changed to I still had 0 wait states. I started probing the board with some simple tests but couldn't easy identify the problem. I then started to review the wait state section of the schematic and found the problem rather quickly. Looking at the original schematics (Page 495) by mr. Wilcox, he has identified the function of the LS151 mux input pins with logical names. These logical names can also be found on our (N8VEM 68k) schematics, but the problem here is that these identifiers now becomes nodes in the netlist. The names I/O, M1 and ALL do not appear on any other place in our schematic but LOCAL is already a net which means that the LS151 mux LOCAL net now connects to the global LOCAL net. To verify that I am correct in this, I have measured the net as well as lifted pins 14 and 15 from U33 and connected it directly to the shift register and it now works as expected.M1 and ALL both as expected so if we can just get rid of the net names on U33, LOCAL will also work as expected.
Another thing I noted when reading the book again, on page 184 (figure 9.17) there is a small note on how the signals POC*, RESET* and SLAVE-CLEAR* is expected to be pulled up by the external bus. This is in line with the specification but I wonder if it's correct that the permanent master makes assumptions about the system that it is running in (discussion please). For instance, in my IMSAI I do not have any active termination, although it may be necessary when running a 68K board in it.
Anyhow, next thing will be to run a small program from EPROM/FLASH that is easy to follow on the logic analyzer.
(Still not to messy to debug)
2010-12-31: Freerun is verified
After having a really nasty flu which forced me in bed for the last week I finally had the strength to play some more with the 68k board. The board was configured to 0 wait states for all address regions, two zero data adapters were made and plugged in. I removed the SRAM and data bus buffer IC's to avoid any collisions. The first tests were no go's so I started to investigate the board. After a while I discovered that it did not reset properly. After glancing at the schematics I found out that the BUS_RESET* signal did not have any pull upp, so the 555 was never triggered. I soldered a 4.7K resistor to pull this signal up and the BUS_RESET* signal worked as expected. The board did however not start so I hooked my trusty logic analyzer up and saw that the reset still did not come through to the processor. A little more digging revealed that the POC* pulse was to short, so I installed a 100uF/16V cap instead and voila, the board freeruns.......
Worth to note is also that the oscillator in place is a 2MHz oscillator, thus running the 68000 on 1MHz. That's why the LED blinks so slowly.
This images shows how the BUS_RESET* pull up resistor was placed (Sorry about the crappy quality.)
So, the board certainly seem prepared to start testing executing a little code from PAIR1 EPROM's so that'll be the next thing I will concentrate on.
2010-12-25: Board Mounted
It took a while to get the time to finish the board, but now it is done. Next I need to configure the board for the memories I'm using as well as watchdog and the other functions. The Allan Wilcox book also got here (finally) just before Christmas so I should be all set to start debugging (if any) and get the board running.
2010-12-02: Reset block mounted and tested
We're currently snowed in and I have been busy shoveling snow the last couple of days, but I managed to find the time to mount and test the reset generator. And it.... well it works as expected. I also found that while purchasing all IC's that the 74LS352 devices are very hard to find. Luckily I had some devices in my TTL stock but if the board is re spun at some point they should probably be designed out to avoid further problems.
Recommended Changes:
Redesign the board to get rid of SN74LS352 devices.
2010-11-26: GCC compiler toolchain
I managed to get the entire toolchain built using newlib as the c-library. As this toolchain is intended for our S-100 68k-board I wanted to be able to customize sbrk and the generic I/O functionality, so this was completely disabled in newlib (no stubs either). I will write a basic library supplying these basic functions, but they will most likely need customization for different hardware configurations and systems.
2010-11-25: Power and oscillator mounted and tested.
Yesterday I mounted the voltage regulators and cap's associated with them as well as the oscillator (U29) and the following 74F74 (U30) frequency divider.
One thing that I have noticed is that thermal ground pads are difficult to heat properly. This is most likely due to that many ground pads are connected to both the top and bottom layer with pretty wide thermal spokes. Some pads also seem to have a routed wire connected to them which also adds to the ability to dissipate heat from the pad.
Anyway, the oscillator started up fine and two nice clock signals are shown on my scope. I only had a 8-pin configuration oscillator and had to patch the board to supply +5V to pin 11 as well.
Recommended Changes:
Thermal Reliefs: I suggest that the width of the spokes is reduced slightly and maybe that the the isolation clearance is increased slightly to make it easier to solder these pads.
U29
Connect +5V (VCC) to pin 11 as well so that 8-pin type oscillators can be used.
2010-11-23: S-100 68K Board Received !
So I received the 68K S-100 board PCB from Andrew yesterday. After a good looking over I started to mount a few items, just to get the feeling that I have gotten started. The board looks very good although I am slightly allergic to some things that autorouters keep insisting on getting wrong.
It's a pretty complex board so I will be spending quite some time on verifying that parameters are within specification. This page will hold all the results of this. That's all for now, stay tuned.
Last edited: