I found a way to make my own NVRAM module
The alignment prongs were snipped off the battery holder, then it's glued with CA to the PCB, as is the upside down DS1210.
I had a nasty surprise at the end, the spacing is 0.1" wider than the DIP socket. But with some pliers and gung ho, I was able to bend the header pins into alignment (they are soldered to machine socket pins, those remain perfectly straight). After that trauma, I reflowed the solder on the pins to avoid stressed joins.
With this, I can load software on the HC11 board, then pull it and put it in any prototype.
Very nice! That’s probably what is inside those modules from Dallas Semi.
I have successfully written to the EEPROM I’m using and am about to start wiring up a 6809 prototype. This continues to be a fun project!
Indeed, although I believe I beat the price point on the 32kb version. The next one will be easier to build. I don't have all the parts I need yet to build a complete proto yet. The baud rate compatible crystals for example.
I see one can buy the Axium HC11 EVB on eBay and in fact brand new from Newark so I’m tempted to pick one up.
I'm not sure why I didn't find this sooner.
Compiles with no complications under Mac OS and is Motorola syntax compatible.
3 Likes
A curious "feature" of the aforementioned assembler that I discovered while assembling old 6809 source files:
-
No blank source lines allowed. At least a '*' for a blank comment line required. This is particularly annoying for me because I automatically insert a blank line after a branch statement.
- Every assembly language statement must be followed by one "whitespace" character.
label lda ,x(space or other whitespace character)
label2 lda ,s+ ; comment(okay because of spaces before comment)
If anyone decides to use this otherwise great command line assembler just beware of this idiosyncrasy. Easy enough to fix with search/replace in your editor.
Sorry, quick interjection here.
I just assembled the assist-09 source.
It is feature packed, and two kilobytes to the byte - a real work of art.
I'd forgotten how much fun 6809 was.
I really am going to have raid the attic - I'm sure there must be at least one of 'em up there.
The 6809 is extremely memory efficient because it is basically a CISC not a RISC processor, the addressing modes allow you to pack a lot more activity into each instruction cycle.
The 74HCT139's arrived today, so I'm a step closer... but no cigar until maybe next week...
Yes, since my copy of assist-09 assembled "out of the box" for me, that made figuring out why other source files I have didn't. It is a powerful monitor and easily extendable. For old times sake I'm going to fire up my system with the version of MIKBUG I converted to 6809 and ACIA I used on my first product. I may end up installing assist-09 later.
It is a very fun processor.
Wow. Somehow I missed this thread. In January, the big brown truck took away my four 25-drawer semi storage units of 68xx and 8088 parts. Could have made all of you very happy! Yikes! I'll give you the address of the dump, they can't be any more than a foot or two down from the surface.
!
2 Likes
Heh. I had an MC68000L8 in ceramic package, it's about 20 feet down now...
Our local Hall-Mark distributor had a contest where I won $1000 credit and a ceramic 68000 was one of the things I used it on. I have no idea where it is now. Plugged into an expensive Vero wire wrap board somewhere.
You're preaching to the choir.
In the early 80's I was working for a company whose main product (a whole-board functional tester, the Columbia Automation (later Zehntel) 2000) was based on a pair of 6809s; one to run the disk, and one to run the test script via an MSI/LSI tester.
The test script processor product had evolved from a simpler 6800-based system, and many system services were simple SWI + function code macros, handled by a large jump table.
For example, for 2D array accesses, you might want to multiply the contents of ACCA by the contents of ACCB.
The original code for the 6800 was an SWI, retrieve the function code, bounce jump via computed offset to a short subroutine that did the multiplication, and returned the result in X.
The 6809 optimisation was simply rewriting the macro with a MUL instruction...
Whoohoo! This just arrived!
An HC11 EVB from Axiom.
Not as elegant an instruction set as a 6809 but has a nice EEPROM programmer onboard that is somewhat better packaged than the one I just built.
Worked the first try!
3 Likes
I would honestly take Buffalo monitor over Forth. It was the monitor on the Moto EVM board. I'm still working on a design, uses some ideas from the ones I posted, but some things have come to having to make some philosophical decisions. As, is it a minimal system? How can the modern hardware help? To which - yes I am trying for example to limit the number of glue logic to maximum of 4. Because I am doing that without PGAs or other programmable logic, it has to be guided carefully. But along those lines, I've concluded:
- it's worth having a full 64k RAM at least as an option.
- a boot EEPROM like the AT28C256 is a good idea
- all RAM is NVRAM
- why not use the 256kb SRAM as it is cheap, and makes decoding easier
and the simplest hardware paging system for the SRAM implies
- a simple latch (e.g. 74HCT273) holds the upper SRAM address bits
- The upper half of memory should be selectable between boot EEPROM and a selected SRAM page
- The lower half should be any page in SRAM
- regardless of page size, it would be safer to guarantee that at any time, the page that the processor is executing code from won't change, while another page is changed
- at any given time then, at least two paged memory areas are required
The first paging attempt in reply #129 tries to maintain a permanent page in memory, but it is costly in glue logic.
Errata - the latest schematic I posted showed write protection for the EEPROM. I've since studied it and realized that it isn't necessary. It would be if you wanted the socket to accept either EEPROM or SRAM.
In the next post, I will show the schematic that follows the previous comments. I received crystals at least, in the mail, which solves the baud rate problem. Communicating with the NMIS-0021 is painful at 9600 baud.
I sympathize with the philosophical directions you are contemplating. In a perfect world, I would still have my Gimix 6809 box with its 8 inch floppies but alas those are gone. I would be happy with a PCB with processor, RAM, EEPROM, ACIA, and buffers terminating in an expansion connector that I could then connect to a breadboard for any hardware project that interested me. Access to all the software development tools from the 80s would be nice too but that will take some work.
It’s a pity that PLAs from the past are not readily available /usable because they really made address decoding a pleasure. It might be worth considering whipping up a small SMD PCB with lots of glue logic that would only take up the space of, say, a 28 pin skinny DIP.
I have past product experience with bank switching, at least EPROM, on a commercial product and as you’ve suggested the function for handling that was in fixed program memory. One just had to insure that the hardware and user stacks were static and that the bank switching was complete before the subroutine call to the new bank from fixed memory was executed. Then when exiting a bank you had to land back in fixed memory. But these are things you’ve no doubt already considered.
Keep having fun!
Jeff Tranter's SBC would actually go a long way toward quickly having hardware to play with. His EasyEDA files are available online as open source. I guess I can order a board from JLCPCB using those. Any thoughts?
The Tranter board would be a start, but forces certain design directions because of the memory map. The sensible way to expand it is via the expansion connector (who'd have thunk). Some others of those include a MEMDIS signal from devices on the expansion bus, so that you can "punch a hole" in on board selection, and locate external device wherever you like. But in this case, what you have is a 8kb non-selected area, and you are only free to assign addresses to any devices in that area, the 8kb below the 16k EPROM and ACIA. I checked compatibility with AT28C64, and it fits but you can't write to it in place because *WE and *BUSY are tied high.
So regards your wants list, for this board, the buffers and additional decode logic would have to be on any expansion board that you plug in. RAM comes to mind instantly, since it would contiguously extend the onboard memory. Also if that happened to be NVRAM, it would fit nicely into the idea of implementing a RAM disk.
Some nice thoughts went into it, like the FTDI pins for the serial interface. Perfect.
The ACIA can deliver 115200 or 28800 baud using only its internal dividers, again nice.
The one chip glue logic is smart, but not new, as the NAND gate memory circuit is published in application notes of the vintage era. The simplicity is sacrificed for a need for additional decoding to expand it, however. Also 8k is a lot of address space to allocate to a simple I/O chip, the ACIA.
I would have liked to see an attempt to make the RAM non-volatile, but they design is trying to keep things simple. I don't like the layout much - the design rules make tiny traces too close together IMHO. I guess in reality it would work. One good thing it has, is decent mounting holes (bad ones are a pet peeve of mine). So you might have a daughter board of the same size that sits on top like a shield. It might have parallel I/O and large NVRAM, for example.
If you have a RAM drive, you can potentially support a lot of different OS, and obviously just do more in software in general.
A separate post for a separate idea... that's a really interesting idea about the decoder board. It could be generic at least to 6800/6502 series at least, and make all kinds of prototypes very much easier to lay out. You could use one side of the board for logic, and the other for solder jumpers to choose a memory map and other options. I think with that, you could get a pretty decent granularity, and produce almost or entirely all the device control signals that you would need. With that, you could actually make something useful on plug boards alone. Or, plug into perf board via headers. Either way, it could make things a lot easier. So I will put more thought into it.
For example, if you cascade two 138's you get memory regions down to the 8kb page level and I/O down to the 1kb level (or better with additional decoding such as may be already on board some peripherals). Those can be jumper selectable as mentioned way back in the thread.
Yes, it has lots of warts but for 5 boards for under $25 including shipping I couldn't resist. The layout is cringeworthy as you say but probably no worse than a breadboard prototype. The offending connections are easy to cut before assembly and I have lots of blue wire. 
I have several different frequency oscillator modules and the board layout allows an easy way to plug a satellite board in. I have 7.3728 MHz, 8 MHz, and 4MHz to play with. Since I also have a 14411 baud generator I'll probably cut the trace to E and use that as well.
I intend to leave the 7400 unpopulated and do the address decode I want from the expansion connector.
I think the big chunk of peripheral space at $A000 is somehow reminiscent of the old days of MIKBUG. Again, easy to fix with blue wire.
All of your points are relevant but for my purpose of not having to hand wire up a prototype to start programming with I think this will work for me.
