Sounds like you placed an order, but another thing you could do, is put an auxiliary connector somewhere on the board, and run those blue wire connections back through it. Effectively, add a MEMDIS and while you're at it, anything else you need from the expansion hardware. Except, you're targeting the wasted I/O space, not memory.
I spent a while yesterday looking up how many SMD glue parts I could jam onto a small satellite board and it's pretty encouraging. Maybe even an L-shaped board to pick up the 7400 as well as the expansion connector.
Yes, I will have boards by this time next week. I like you suggestion about the blue wires and will take a look at a place to add that.
Good point, the NAND gate socket is a bit of a back door.
While 6809 supplies trickle in, I began work on the HD63C03Y prototype. This Hitachi IC has an MC6803 compatible processor, on board parallel and serial I/O, timers and a tiny RAM (128 bytes). So the idea is, give it 32k RAM NVRAM with a 16k write protected boot space. The MCU uses smaller than 2.54mm pin spacing, so it will sit on its back when I place it. I prepared the RAM board first, and it has a trick. There are 28 pins on the back of the board, such that the RAM can be seen from either the MCU, or a device it's plugged into. In this case, that is the NMIS-021 HC11 board.
Here the processor isn't on board yet, I'm testing the NVRAM circuit by itself before going on. It's working fine. The empty 14 pin socket is the protection logic, which looks like this:
"Socket" refers to the RAM backdoor access pins. When JP1 1,2 are connected, the upper 16kb is write protected, it is write enabled when 2,3 are connected. The other jumpers are just for isolating the on board logic from the socket when it's in use. The CPU will be held in reset during those times, to tri-state the bus.
It wouldn't be that hard to add a second 32kb RAM to utilize the entire memory space except for the tiny internal register map. But I wanted to keep this first one simple. It's actually possible to build a completely glue logic free system with this processor, because it produces RD* and WR* signals by itself and those will drive memory chips directly. So, you can have one memory chip with no glue at all. If it's EEPROM, you can have a very typical controller system but with the limitation of almost no RAM. As soon as you add additional memory chips, you need some glue logic. But because of the versatile memory control signals, it's easier than usual.
So you can program the NVRAM from the HC11 board? Does it handle S-records?
That’s a nice all in one chip.
The Forth documentation I have doesn't seem to detail exactly what memory it uses, however does comment. It is the de facto monitor program when you boot. Because Forth seems to use the first 512 bytes and no memory above that until the 32kb limit, you can easily program almost the entire NVRAM. But to load S records directly from the HC11 would involve either a binary loader written for HC11, or a Forth program residing on the NMIS-021.
Hardware wise, the NMIS has only RAM in the first 32kb half of memory. So there is no technical obstacle to cleanly writing the entire 32kb NVRAM. I guess, to eliminate doubts about Forth memory usage, it would be better to load a binary copy of an S record loader. I assume that is between easy and medium difficulty in assembly?
In operation there are several single chip memory options, which could be made select-able. With RAM, fully unprotected or upper half protected. With EEPROM, unprotected and using the MCU small internal RAM.
I was looking at C compilers, for the 6803 the prospects are fairly dismal. So I got the idea (from Forth, really), what about a virtual machine? Then a C compiler for it. I found it, maybe too simple but it's called LC-3.
https://highered.mheducation.com/sites/0072467509/student_view0/lc-3_simulator.html
There isn't at present an MC6801/03 implementation AFAIK but how hard could it be?
You could copy the code from the Buffalo monitor and assemble it. I guess the Forth monitor has a memory examine and change so it wouldn’t take too long to type in the hex code by hand.
Thanks, I'll give it a try. I thought, my first test would be to echo characters from the UART. It would really be nice to have Buffalo back.
Ordering boards from JLCPCB was so easy and inexpensive I think I’ll see what a 4-layer board looks like cost-wise. I would prefer to use KiCad rather than EasyEDA so I need to see how that works out.
My first PCB layouts were done on a light table with a precision Mylar grid and Brady tape and pads. Then years later I thought 3 boards for $99 from ExpressPCB was a great deal and ordered a few of those. Now the idea of 5 boards for $7 plus variable shipping costs is just too tempting to ignore. I really wish I’d looked into it sooner.
I’ve followed the threads here discussing PCB design but my only experience was with Eagle which I thought was more trouble than it was worth but KiCad has made me a fan.
I learned and used Eagle for my last PCB project. This time around, I decided to go with KiCad, I'm very satisfied with it although I haven't yet reached the point of Gerber outputs and so on.
I downloaded MIKBUG source and documentation, this is what I will use as a monitor on all the boards.
I modified MIKBUG to assemble for the 6809. Very little to change. I mostly wanted to adjust the relative entry points of subroutines other software might access. It’s a perfectly good monitor.
Not specifically asking for help, but I had a major mystery yesterday... I have AT24C64 EEPROMs and decided to try them in the NMIS memory slots. In spite of an hour of confirming jumpers and everything, I can't seem to read or write them. I have 4 and they are "pulls", so they may be bad, but then again suspicious that they would all fail. Not likely.
The only thing that seemed really critical about that, I thought I covered... pin 1 is a BSY/RDY output, so shouldn't be connected, so I removed the jumper to it. The only other difference is that one address pin is an NC, shouldn't make any difference...
I have AT24C256's in PLCC32 that I could similarly try, but no adapter socket yet.
Probably a typo and this should be AT28C64?
I'm having a similar problem with the HC11 EVB I have with brand new parts. Consequently, I'm returning to my off board programmer. I've gotten a little distracted from that because I'm laying out a circuit board to replace my breadboard.
I tried to find a schematic for the NMI board but didn't so I really can't comment on what might be the problem.Maybe they are bad parts. I'd expect to be able to read back whatever their previous programming was unless they were erased at some point before resold. Presumably your EVB waits the appropriate 10ms after programming before trying to read back.
Interesting. That would be a Forth question, but I do a store to EEPROM like:
HEX
AA 4000 C!
and I'm pretty sure there is no read back on that. Not until I dump it several seconds later...
I tried using both the upper and lower 32kb memory slot, same deal.
Edit - meanwhile an STM Nucleo kit arrived in the mail, and my neighbor's car was rear ended by a snow plow while we put it on the road to clear the shared driveway. No end of excitement today.
Yes, AT28C64. IIRC those were used in older PC motherboards, to hold BIOS. I suspect that is where these came from. The AT28C256 chips look newer, I suspect I will have better luck with them.
I’m not familiar with this. Is it from the EEPROM or somewhere else?
Added: Is it the state of pins I/O6 & I/O7? Does your board monitor them for write completion?
Yes, the EEPROM. The 8kb part has it, the 32k part doesn't. The 8k part has an open drain output on pin 1, so you have a choice of polling it in hardware, or polling I/O7 in software. The 32kb part is only polled in software, has no such pin.
Today, I am trying to "jailbreak" the NMIS-0021 HC11 board by putting it in bootstrap loader mode and connecting to it with JBug11. At the moment, it's giving me a hard time, I can do everything except upload a "talker" which is the target client on the HC11. It will connect and reset, but doesn't auto upload the talker as it should. Still struggling. I want to cut Forth out of the picture, there are just too many unknowns to trust it.
It's suprising how much work I have to do, that has little to do with the actual project. 
By the way, I discovered HD63C50 exists in SOP package, it's MC6850 compatible so there is an opportunity to shrink size and power consumption for the UART. I'm still checking but it looks like there is also a Hitachi analog to the MC6840 also CMOS in SOP.
Another small issue that has come up, I started to worry about the state of the bus during start up - if there exists an interval during which the processor is in reset, but the NVRAM becomes active, it could be unintentionally written. The NMIS board (I don't know how many others...) conditions the write signal with RESET so that can't happen. Still pondering this, as my designs don't factor that in. Normally nobody worries because RAM is volatile, and contents are considered undefined at boot time.
Ah, okay, my Atmel AT28C64 is a NC on pin 1. I didn't realize there were different varieties.
Those SOP parts would definitely be nice.
According to my 6809 data sheet, the address bus is at $FFFE during RESET low so long as Vcc is valid and Q and E are running. I use E as a condition for asserting WRITE. I don't know if that helps keeping NVRAM uncorrupted or not. I'm going to have to think more about that. I never had to worry about that in the past. The DS1210 has some features that might help, e.g. if you can delay it sensing a valid Vcc for a bit, it keeps /CE high.
According to my data sheet, the AT28C64X has NC, not RDY/BSY on pin 1. I guess that's what you have. If you don't connect anything to it, either chip is the same.
AT28C64B-15PU is what I purchased from Mouser. The Microchip/Atmel data sheet show it as a NC. Interesting that there are variations. They may may have changed it because they thought it made it easier to design for either it or the 256k part.
1 Like