Yes, I was thinking along those lines. I am really hesitant to add anything though. But a write barrier or fence instruction is present in a lot of architectures. Another thing I have been contemplating is making use of the three interrupt lines to implement a priority encoding like the 68000. There are four extra bits to use in the ccr for the 12-bit version.

Trying to get the ddr3 ram working. The first issue was not recognizing the need to process the end of read data signal properly. This resulted in read data spanning the entire 128-bit packet instead of just the bytes for the specific read. With that fixed the next issue is that the controller appears to be able to write only the first byte pair of a packet. Attempts to write other bytes are ignored. This smells like an issue with write mask generation. I have tried a couple of different ways to set the mask with the same results. My thinking now is that like reads, it has to do with the end-of-data signal. Since it works for the first byte pair my thought is to extend the signal by a clock cycle and see if the second byte pair is processed correctly.

Modified the memory controller to perform read-modify-write cycles since it does not appear to be able to write individual bytes. Fortunately, most cycles are memory read cycles. <- This did not help. It still writes only the first 16 bits.

Ran into an issue that confused me for a little while. Looking in ILA there was a state transition in the dram controller that was impossible according to the code. Then it finally dawned on me that the ILA clock was likely too slow to pick up additional transitions that were happening.

Still cannot get the dram to work. It can be faked by using only the first byte of a strip and shifting the address left three bits when accessing the ram. This results in access to every eighth byte, which is the byte at the start of the strip, being accessed. A couple of issues with this. It wastes eight times the memory, limiting memory to 32MB instead of 256MB. It also makes it impossible to use the RAM for the video display, as that requires reading entire strips to get the necessary bandwidth.

*****************

Another potential addition to the core is using the extra bits in a memory word to indicate debug breakpoints. It would require a special read/write operation to manage the breakpoints.
Yet another desired feature may be support for memory address reservations.

Got the DDR RAM working. The biggest issue was not using block RAMS to cache the data. After adding block RAM caches things started working. I am guessing the issue was a clock domain crossing issue. The 6809 core now has access to megabytes of RAM. Better yet so does the graphics display.

I updated the boot rom with a SWI routine, which I am just about to test. In theory timer interrupts are enabled, but I do not see the status flag updating on-screen.

Latest fixes: The instruction size for indirect extended jumps was incorrect due to a misplaced bit in the decoder. This led to indirect subroutine calls failing to return to the correct address. Indirect jumps worked okay though.

The far return instruction RTF was messed up. It failed to increment the stack pointer. This would lead to following code failures due to an invalid stack state.

Hitting mostly software issues now. Been working on invoking routines including the OS using the SWI instruction. Re-wrote the monitor’s command processor to be table oriented. Working on getting code breakpoints working. That should help with debug.

I have been reviewing the ASSIST09 monitor program and Supermon816.

Pondering on making a system for the CmodA7. The core will certainly fit along with a uart.

Wrote a simple S19 file loader. It should now be possible to download files and execute without having to rebuild the system. The S19 format is hacked for 12-bit bytes. Should call it something else F19 for instance. First working download has bit errors in it. So now to try a lower baud rate.

Got the SoC for the CmodA7 built that I was thinking of. Got stuck for a while on the memory controller and ultimately ended up implementing a read cache using block RAM. It works well enough now to be able to use to store the stack and other data. Which is important given the small amount of block RAM in the 7a35t chip.
The system is kind of neat because it uses a virtual screen in memory which emulates the real text screen for input and output. The text screen is used as an input buffer and allows full-screen editing. With the CmodA7 you cannot see a screen but it still there.

The SoC which implements a ACIA and VIA along with 6809x12 core uses only about ½ the resources available in the chip. So, there is room to play.

Concocted a new file format which works identically to the S19 format but uses 12-bit bytes so there are three characters per byte value. So that the format is not confused with an S19 file I changed the start of record indicator character to a ‘C’ from ‘S’.

Interrupts appear to be working. At least there is a timer interrupt occurring as can be seen by the onscreen indicator updating.

Stuck on the compiler at the moment with a typecasting issue to resolve.

Trying to get Xmodem working. The S19 loader has a persistent error in the transfer, so a transfer mechanism that has some error recovery was desired. Found a bug in the S19 loader. Sometimes it did not wait for an input character. The blocking / non-blocking status was not being set properly. The loader was modified to be able to load from a file already present in memory. This should allow download via Xmodem, then load via S19.

Cannot get the Xmodem transfer to work.

The ACIA was updated to use vendor supplied fifo’s instead of the fifo I coded. I found an issue with my fifo so I decided it best just to use the supplied ones. I did more testing of the serial with fifo’s enabled to ensure things are working. The fifos are 64-bytes deep.

Started working on the mini-assembler in the meantime.

Got interrupts going again, including interrupt driven serial receive. There is a slight glitch though. Every about 2 to 3 seconds it seems a phantom carriage return is being received. I have not been able to track down the source yet.

Thinking about supporting some of the 6309 instructions which make a little more sense to me. These being operations on the D register.

oh no - an infrequent failure can be so difficult to track down...

Still have not found it. The boot rom accepts input from the serial port and echoes it back to the terminal emulator. I am wondering if somehow the terminal emulator is sending the CR. This started happening when I tried Xmodem transfers.

Started adding 6309 instructions.
With many 6309 instructions the core is much larger approx. 8000 LUTs.

Just finished a documentation marathon. Documenting the 6809 instruction set for 12-bit byte instructions. It is the same instruction set as the ’09 except that the instruction page bytes are compressed into the 12-bit opcode. Since there are a couple of extra bits in the opcode I have been thinking of how to best put them to use. One thought is multi-bit shifting, from zero to three bits in a single cycle.

Had fun with the divider. It is implemented as a reciprocal multiplier using a 2048 entry lookup table that is accurate to 26 fractional binary bits. The divider is quite fast, requiring only about 16 clocks or fewer to perform a divide. Granted it is only doing a 24 by 12 divide. The reason it is possible to get away with a lookup table is the divisor is only 12 bits signed, or 11 bits unsigned.

Also implemented the multiplier which produces a 48-bit product in the W,D registers.

Still have not tracked down the source of the phantom carriage returns.

Backed out the lookup table divider and decided to use standard radix-2 dividers. While fast, after some testing the lookup table divider was found to be not accurate for some basic divides where one would expect 100% accuracy. For instance 21/7 came back as 2 remainder 6. It may just be a matter of the accuracy of the table but its already a large table for 27 bits precision.

Added hardware breakpoints into the design. Hardware breakpoints can trap on a match of a load, store, or instruction address. They feature a zone within which a match may occur, some of the least significant bits may be masked off during the compare and made don’t cares. It is now possible to set breakpoints in ROM routines. Setting a breakpoint does not modify the code or data at the breakpoint address. The trick now is to get the breakpoint software working.

Ah, indeed, the table approach has its risks - Intel's FDIV bug cost them half a billion, and that was caused by a smattering of wrong values in the table... so bringing a table into play means you need a lot of care in verification.

Did DAA decimal adjust get fixed for 12 bit data ( 3 BCD DIGITs), you need a second half carry flag for the second BCD digit. A bcd shift for memory would be handy as well.
Ben.

I thought of it but decided to just leave it. It should still work for two digits. There is room for a second half carry flag in the 12-bit ccr. So it was tempting to do. I also thought of taking the 6502 approach and having a decimal mode for add and subtract. Multiply/divide should handle BCD as well.

I am finding I am wanting to do too much with the design, so I started working on Thor again. Thor is going to have decimal floating-point.