Project Logs

Collapse logs

• New PCB, new bugs (but very minor)

  Phil.macphail • 10 hours ago • 0 comments

  The new PCB arrived before the Chinese New Year holiday, and I even found time to assemble one. All the modifications listed in the previous logs worked without problem, and I was able to get the monitor prompt straight after reset. The real-time clock circuit is new, and I very quickly noticed a missing connection - one of the CS pins is floating and should be connected to the reset line. With this fixed with a small wire the chip could be read and written to, but to use it properly needs a little more complex code, so that can wait. The code for the CF card isn’t finished yet but is moving forward. I can read the card details into a buffer and list them calling the memory dump routines in the monitor. I can also fill the buffer with a constant and read a block from the card. The reads aren’t consistent, however, so I want to fix this before writing to the card. I did notice that the configuration data seems to be a little scrambled, configured for Intel-style 16-bit reads. Reading 8 bits at a time, the LSB of the address needs to be inverted. Without this, the manufacturer for the card I have is reported as OTHSBI A, rather than TOSHIBA.

  A kind reader correctly pointed-out that the TSC pin is floating in my design, and it should be grounded. Another wire again fixed this, but I had been lucky that the chips I used (all Thomson) seemed to ‘float-low’ on this pin and work. I had noticed that at power-on the CPU required a press of the reset button to work, and assumed this was due to how the PSU ramped. That is one of the reasons I added the reset chip to the new design. 
  My priority now is to finish the CF Card code, then write the routines for I/O for Flex. Actually getting Flex onto the CF cards is something I haven’t yet resolved, but that isn’t a concern right now.

• Compact Flash Card Interface Works

  Phil.macphail • 01/31/2021 at 17:28 • 0 comments

  The Compact Flash interface was quite easy to check, however plugging a CF card into the socket before power-up prevented the whole computer from starting. Something as major as that should be easy to diagnose, and so it was. The CF Card is configured at reset by checking the status of the two select pins in the interface, and the first problem was that the reset wasn't connected to the interface.... fixing that didn't help much, however, as the two select pins were swapped. With that fixed the computer started and I could start to write a program to read and write to the memory card.

  Assist09 provides several functions that are handy when writing a program, such as read a character from the console, print to the console and print memory locations. Software interrupts control this and I soon had the bare bones of a disk editor working. I will continue to improve this over the next week or two, but I could see enough to know the hardware was working correctly. With the Chinese New Year getting close I added all the changes to the PCB and added a few features, and sent the board off to be made.

  The new PCB has a few new features an addition to bug fixes. I have opted for a better reset circuit as the simple resistor, capacitor and push-button switch isn't so good for any chips that don't have Schmitt-trigger inputs (and I can't be sure the signal met the CF Card specification). A small expansion connector will let me add features in the future without making a whole new card. I would like to add a video and keyboard interface in the future (and a second CF Card socket), and this expansion port will let me do this. I was also able to squeeze a real-time clock chip onto the board too, with the thought that, should I get Flex running, I can use this to set the date.

  Quite a successful couple of weeks, and I hope I have time to complete the CF Card editor before the PCB's arrive, so that I can put it in the EEPROM along with the monitor. With the design becoming pretty stable now I have added a parts list for the new design, and added the schematic too.

• MC68681 - Just one more thing...

  Phil.macphail • 01/13/2021 at 17:58 • 0 comments

  Configuring the 68681 serial ports was the next task, so that I can replace the 6850 I am currently using. The datasheets from NXP and Motorola rather complicate things with the register explanations requiring constant referencing to different pages to do quite simple things. I decided that I would write a simple program to send a character from port A repeatedly as the first test, so that I could confirm the correct configuration. This proved problematic but I found a configuration that almost worked, so I enhanced the code to read a received character and resend it. I could then check the function in a controlled way. With this some characters were sent correctly, some were modified to different characters, and some were translated to multiple characters. This was completely repeatable; pressing the same key on the keyboard always resulted in the same outcome, even if it was incorrect. Checking with an oscilloscope I could see that the data format being sent wasn’t what I was setting in the configuration registers, and I suspected a hardware fault. When I designed the PCB I didn’t gate the chip select pin with the E signal from the CPU as I didn’t have a spare gate. I half expected that to cause a problem but I had seen other schematics that did the same thing, so thought I would try it. I was fairly sure that might be the problem here. Piggy-backing a chip onto another and lifting a couple of pins let me add the required gate, and everything started working as expected. Fortunately the gate I need will be available when I stop using the 6850, so the changes to the layout are quite simple (but the changes for the revision of the PCB are growing). I also realised I had the pinout of the serial connector wrong to plug an FTDI serial board straight into the CPU board, so more changes needed there too.With a reliable serial port working with my terminal I had all the routines needed to modify the monitor code. I was able to transfer all communication to the 68681, set the memory page register, copy the EEPROM to RAM and disable the EEPROM (using the output pin of the 68681) in a single update to the monitor. It all worked in the same way as the individual steps had, but this was the first time they were all tried at once. Very satisfying. Having the 6850 and Assist09 working from the (almost) beginning was a huge help in getting this far. Without that I don't think I could have got the new serial interface working at all as I would have had little insight into the behaviour of the PCB otherwise.
  The next step is to apply all the modifications to a second PCB that has a Compact Flash socket in place of the 6850 and test the CF interface. If this works then it will be time to get a new PCB made with all the changes and add a few more features.
  I will put the asm file for the modified Assist09 on the GitHub page in the next couple of days, and probably add it here too.

• Further functional checks

  Phil.macphail • 01/10/2021 at 19:17 • 0 comments

  With the computer running code correctly I could start to verify the other features of the design. The upper 32k of the memory map has both RAM and ROM in parallel. Writes to this space go to the RAM, but reads come from the ROM after reset, however the ROM can be disabled so that reads come from the RAM. This is important if I want to run Flex, as I need RAM at the top of memory. Reset set a 74HC74 used as a SR flip-flop, and the output of this is used to gate the chip-select signals, diverting reads to ROM. Writing to a memory location resets this flip-flop, so this is easy to test. Using the monitor to write to $F2C0 crashed to computer, and I could see with a logic probe that the ROM wasn’t selected at all. Now how to continue correct program execution? This turns out to be quite easy. Re-assembling the Assist09 code to produce a S-record output gave me a file that I could download to the SBC using the Assist09. True bootstrapping! This gives identical memory contents in both RAM and ROM, so switching between them should be invisible to the CPU. Writing to $F2C0 once more didn’t crash the processor, and I could read, modify and verify memory contents that were previously located in the ROM space.The second memory feature is that the space $D000-DFFF is mapped to any 4k block through the 512k of the RAM chip. With the ROM disabled I could now ‘see’ this space, and see if it works. Again, the monitor let me do this very quickly. The sequence used was

  • Writing a page number to $F280 then writing something to $D800
  • Write a new page number to $F280, and write different data to $D800
  • Write the original page number to $F280, and examine the contents of $D800, to verify that it is the original data written in step one.
  • Write new data to $F800
  • Write the second page number to $F280
  • Verify the data at $D800 corresponds with the data written in step two.

  This all worked perfectly, so for now I can confirm that the memory paging is working correctly. All good so far, and no need to write any code so this all took less than an hour. The only thing left to verify was the 68681, and again I could do initial checks with the monitor.
  The PCB has two LED’s connected to the output port of the 68681, so writing to the correct register should be able to turn them on and off. Again, the monitor made this simple and I could control the LED’s as expected. At this point I realised that the state of these outputs is defined at reset; I could use one output to control the ROM select, so that I can switch it in and out as required rather than just at reset. Removing the 74HC74 and soldering a wire on the underside of the board took a few moments, and worked perfectly.
  This was all going too well, and it was at this point that I realised I couldn’t check the DES chip - it requires a clock input at twice the bus frequency, and I had connected this to the crystal oscillator running at four time frequency. This will require a bit of surgery, so perhaps I will leave this for now.

• First signs of life

  Phil.macphail • 01/03/2021 at 14:22 • 0 comments

  After assembling the board I programmed the EEPROM with a version of Assist09 with the ACIA address modified to reflect the new memory map. On power-up nothing happened. This isn’t entirely surprising but was worth a shot, it would have been great to see the prompt on my terminal. Assist09 uses a vector map placed in RAM, so to function correctly both memories need to be working correctly; I needed to see where the problem was. I considered jamming NOP instructions on the bus to check the processor was functioning, but the 6809 sets the address bus to $FFFF when executing instructions so it isn’t easy to see anything useful with this. Instead, I wrote a small piece of code that simply jumped to itself. This would exercise the EEPROM only, and it worked fine. The problem was therefore with the RAM.

  I wrote another short piece of code that wrote to a fixed memory location in an endless loop, and I could see the correct data on the data bus synchronized with the control signals for RAM. This indicated that the problem was with reading, so another piece of code read from the same location in a loop. I could see straight away that when the read cycle started the RAM was disabled. I had just re-invented the write-only memory! Fortunately I was able to modify the circuit using the gates on the board (as seen in the photo) and both reading and writing worked correctly. That should be enough to get Assist09 running.

  Reprogramming the EEPROM with the monitor still didn’t give me a prompt on the terminal. What could be wrong? I could see the ACIA being polled regularly so the code was running correctly, so what had changed? When I reset the board I could see that the ACIA transmitted something, but the terminal didn’t recognize it. I had switched from a 7.3728MHz crystal to a 3.6864MHz so expected the Baud rate to halve. What I realized later was that on the previous board the ACIA was clocked by the crystal frequency divided by 4, so my new design was actually running at twice the speed of the previous design. Changing the settings on the terminal program finally gave me the Assist09 start-up text and command prompt. With Assist09 running I can download code rather than reprogram the EEPROM so progress should be much easier.

• Single-board computer initial design & PCB

  Phil.macphail • 12/31/2020 at 11:35 • 0 comments

  With a working cross-assembler and basic design, I am ready to design the board the preparation was intended for. The outline specifications are –

  • 68B09E clocked at 8MHz, as that is the chip I got from Jameco.
  • I had 32k EEPROM chips from another project, so that was a simple choice.
  • I also had some 512k SRAM chips, so one of those could provide a ram-disk or some other paged memory.
  • The 6850 used on the original board doesn’t have any Baud-rate generating circuitry so I decided to replace that with a 68681, which also adds a second serial interface.
  • If I want to run Flex or other DOS then I need some kind of storage, and Compact Flash seems easy to interface.
  • Most importantly, and the reason for the project title, I added a 6859 DES encryption chip. I found some NOS parts for a couple of Euros each and thought it would be interesting to experiment with them. They only do 56-bit DES but there is still some kind of export control on them.

  The detail implementation turned-out to be quite straightforward, with a couple of extra constraints to fit the ‘small steps’ approach. I knew there was a good chance of making errors in the design so I wanted to be able to implement the original one within the new one, which meant including a 6850 for early testing. Only the address of the chip changes, so if the monitor runs then I know I have both RAM and EEPROM working. From there I can use the monitor to check each feature in turn.

  Memory Map

  The peripherals are all mapped to a 2k address space between $F000 and $F7FF. After reset the rest of the upper 32k is mapped to the EEPROM when reading, and RAM when writing, but the EEPROM can be disabled to give 62k of RAM. The intention is that code in the EEPROM can be copied to RAM at the same address then the processor switches to RAM-only without any other functional change.

  An extra twist is that a 4k segment between $E000 and $EFFF can be mapped to any 4k segment of RAM by writing to a single register.

  There are enough complexities here to be a challenge to debug so I was reliant on the monitor and serial interface to get me started.

  Schematic

  This is the design created, that I was hoping was mostly functional

  Initial schematic

  PCB

  This is the PCB I received, before I assembled it

• A09 on OSX

  Phil.macphail • 12/24/2020 at 14:35 • 0 comments

  I looked around for 6809 assemblers for OSX, and there were three main options; A09, AS9 and lwtools. lwtools was a bit more 'serious' than I was looking for and AS9 was quite complicated to get into a form Xcode could compile, so A09 was what I chose. It compiled without problem but generated lots of errors when used, so clearly something wasn't quite right. The comments at the start of the code are quite explicit in the expectations of int and long bit-widths, which the compiler on my Mac didn't satisfy. Converting ints to int_16t and similar for longs the code worked and I could assemble Assist09, program an EEPROM and run it on my simple PCB.

  There is an error in the check-sum generation for the s-records, but that can wait for another day. The updated code is here

  https://github.com/valgamaa/A09-cross-assembler
  

  and I can now progress to my full design safe in the knowledge that I have a working version of Assist09 that I can modify for the new board to bring it to life.

• Little Steps

  Phil.macphail • 12/17/2020 at 13:35 • 0 comments

  The problem with getting a computer board working is that both the hardware and software need to be working correctly. If both are new then chances are neither works, so how to fix them?

  In my case I decided to solve the problem in little steps. I found a blog by Jeff Tranter (http://jefftranter.blogspot.com/2019/01/a-6809-single-board-computer.html) where he had a simple design and functional software. Perfect! I could take the design, make my own PCB and the software on his git page to verify my version, then use the working hardware to verify my cross-assembler. With both of these tested I can make a 'real' design, safe in the knowledge I could debug it with known-working software.

  As you can see, my cautious strategy paid-off. When there was no output from the serial port I knew that the fault was on my board, and a few minutes with a 'scope showed there was no clock signal. The 74HC74 CLR inputs were tied low rather than high.

  Still no activity. A couple more minutes and I could see that E and Q had been swapped. Remove pin 6 and put a link between Pin 5 and 6 on the PCB and there was activity on the serial port. Success, I had the Assist09 prompt on my terminal emulator.

  I now have a functioning platform to verify my development tools with, and verified footprints for a more complex design, so while it's disappointing I made a couple of simple errors they justify the 'small steps' approach.

  I will link a GitHub page later to contain all the files as I proceed.

View all 8 project logs