CMPM works now. I am not sure why, but I managed to eliminate a state used by CMPM. There are only seven instructions left which do not work correctly.

Found that ADDQ / SUBQ to an address register should update the entire address register even if a byte or word form is specified. Effectively only the long form is used. This issue was not caught by the test suite.

I found a webpage that indicated ABCD / SBCD / ADDX and SUBX all had source and destination operands swapped. Fixing this reveals that the instructions still did not work, in fact results were further off. On a hunch I found another webpage with instruction encodings, and it turns out I had them right to begin with. The latest “fix” was due to bad info on a webpage.

I am beginning to wonder if the test suite is suspect The core is at that stage where its 95% working and it is the last 5% that is consuming time. I am keen to start working on the rf65000.

Core #7 looks like it may be working too. I can see the screen fly by when alt-tabbing but do not seem to be able to stop on that screen.

Latest Ideas
The core uses priority encoders to save clock cycles when processing the movem instructions. The priority encoder network skips over registers that are not being moved. However, a smaller core may result if a simpler shift register were used. The drawback is each register position would require a clock cycle as the shift is being performed. I am thinking about adding it as a size versus performance trade-off option.

I am wondering if the timer interrupt should be a global interrupt that requires servicing on all cores.

Looking at finding an OS to try and implement. But it has to be very small so I was thinking of FreeRTOS. There is only about 64kB per core to implement an OS on. But the OS code can be shared for pairs of cores.

Latest Fixes:
Found out that rotate instructions ROL, ROR were not supposed to set the X flag. The test suite did not check directly for this. Fixing the ROL, and ROR instructions caused ADDX, SUBX to pass the test suite. Apparently they were working all along. I spend about two days trying to identify what was wrong with the wrong instructions. Five instructions left to work the bugs out of.

Silly me. For overflow detection in the ASL instruction, the only shift with an overflow possibility, I had overflow detected as a difference in the sign bit of the result from the sign bit of the original value. The 68000 tests for overflow each time a bit is shifted, so if an overflow occurs during any bit shift then the overflow flag is set. This behaviour is probably more difficult to replicate using a funnel shifter.

The divide instructions DIVS, DIVU were updating the register when overflow occurred, this was different than the 68000 behaves, it leaves the destination register unchanged if an overflow occurs. I managed to get DIVU working by correcting the overflow behavior. As far as I can tell DIVS should also work but does not match the results for the test suite. DIVS is returning the same results as DIVU. I eyeballed the test suite and note that it looks like this should be correct. The first test is an overflow state. After that the operands are shifted to the right which would make them positive. IF the operands are always positive then DIVU and DIVS should return the same results.

The following looks to me like it should be working with positives after the first set of overflows. Am I missing something?



Being able to dump register values in the monitor has helped immensely.

Latest Fixes
ASL was not setting the overflow correctly for word and long-word operations.

Trying to get serial port connectivity. I know the physical link works because I ran Digilent’s GPIO demo which sends data when a button is pressed. However, when I try using the serial port using my own uart through the monitor program it does not work. There is not even garbage coming through.

I finally got transmit from the FPGA board to work. The receive and transmit signals were swapped. There were also a couple of issues with the ACIA. One was an unconnected signal was treated as a high, causing a constant reset of the transmitter. The second issue was the use of positional parameters in the code. I added another parameter for clock frequency and that threw the positional parameters off. So, the baud rate ended up being off by a factor of about 2.5 times. Fixing these two issues got transmit to work but receive still seems to elude me. This is using an ACIA known to work in the past. I have used it in other projects. I want to get the serial S19 loader going to be able to load an OS.

Work on rf65000 is going nicely. I have got a lot of the ISA spec’d out.

I wrote a small routine about six lines long to receive from the serial port and dump it to the screen. It worked! So, the physical connection is working, and so is the uart. The S19 loader did not work, however. I found a bug in the loader. It was expecting the character from the serial port to be found in d0 and it is in d1 instead. So, a quick fix was made. I should note that the transmit and receive char code segments are being run through the 68000’s trap mechanism. So, that is working.

Serial receive is now interrupt driven. A 4kB buffer was set aside to receive serial port data. The S19 loader is almost working. It was not recognizing CTRL-C to stop the load due to a typo in the assembler code. I had typed ‘cmp.b #CTRLC,d1’ which did not assemble as expected. I corrected this to ‘cmpi.b #CTRLC,d1’. Still does not recognize CTRL-C the keyboard seems to be hung while performing the S19 load. The on-screen interrupt flag keeps going though.

Found a Noob bug. The variables for serial port access were defined to reside within the keyboard buffer. I forgot to allow space for the keyboard buffer. Explains why the keyboard was acting up.

Still no luck with the S19 load even after a few fixes, it hangs.

Moved on to improving the monitor program’s command dispatch. Previously it was like a giant case statement. It has now been switched to be table driven. Ultimately it should use less room in the RAM as new commands are added. With a little luck the little monitor program can evolve into an OS shell.

Rewrote interrupt handlers. Made use of the 68000’s interrupt acknowledge cycles to place vector numbers on the data bus allowing multiple vectors per interrupt level. Currently the keyboard and timer interrupts are at the same level. Previously there was code in the interrupt routine to detect which source caused the interrupt. Now it is controlled by the vector number placed on the data bus. Using the INTA cycles allows the interrupt routines to be generic without needing to detect in the ISR which device caused the interrupt.

Trying to get semaphores to work today. They are necessary in a multicore system where turning off interrupts in a core is not sufficient. There is a special semaphore memory in the global address space which when written to at different addresses may lock, unlock, or read/write the semaphore. Why not use instructions dedicated to implementing semaphores like TAS or CAS? Those instructions work only if the memory system can guarantee atomic access to the memory. Most memory systems do not work that way. Meaning most of the time those instructions are not that useful. Because global memory is accessed through a network it cannot be stalled waiting for a semaphore.

There are 1024 32-bit binary semaphores available (1 block RAM worth) mapped into a 16kB memory space. I have only ever used two or three myself so 1024 should be plenty. To lock the semaphore a 32-bit key value is written to the memory. The memory will only accept an update if the memory cell is currently zero. Whether or not the semaphore got locked can be determined by reading back the key value. If it is the same as the one used to set the semaphore, then the semaphore must have locked. To unlock the semaphore the memory at address $1000 greater is written with the key value. The memory checks the value written against its contents, and if they are the same zeroes out the memory cell freeing the semaphore. At addresses $2000 and $3000 above base the semaphore memory responds as an ordinary RAM. This allows forcing the semaphore values if necessary. Useful to reset the semaphore memory. The key used is a hash of the core number shifted left 16 bits and the thread number.

Keyboard and serial ports are now protected by semaphores. And it does not hang! The issue with my first semaphore implementation things locked up all the time.

Serial receive works well enough that a test dumping received data to the screen can be done. But dumping received data to memory hangs the machine. Maddening. Why one works but the other does not. So, I have made some changes to the S19 loader. If it takes too long to get a character then the loader jumps back to the monitor, which will hopefully prevent things from freezing.

Milestone: two cores working! Core #5 is working now with a few minor glitches, after putting semaphore locks around high-frequency screen updates. It is possible to switch to core 5 using the monitor’s CORE command, CORE 5. And better yet switching back to the primary core, CORE 2, works. Keyboard input is working for both cores
Milestone: Tiny Basic working!

Added a RESET <n> command to the monitor which causes the reset signal for the specified core to become active, resetting the core. Using the RESET command another core was running.

Three cores running at the same time, I am on a roll.

Latest Fixes:
A fix in the text controller core. The RAM size was increased to allow each core its own screen, but an address bit was missed on the video RAM. This caused two cores to be accessing the same RAM area resulting in display issues. It also resulted in blank displays for some cores.

Latest Trials
The system was setup to run the 68000s at 80 MHz. It seems to run okay at 80 MHz but long trials are to be done yet. They were running at 40 or 50 MHz for development purposes. At 80 MHz there were timing issues with the video frame buffer. The color depth register, which is used in many locations had timing issues. So, I double buffered the color depth signal. It was possible to do this because it is not a dynamically changing signal so the extra register should not interfere with operation of the buffer. And, double buffering the signal did not help timing. I am going to leave it, as it does not matter if the color depth value is off by a clock cycle or two due to timing delays.

Latest Mods
All cores now receive timer interrupts. This is to allow the core to scan for messages from other cores which is done during the timer interrupt. The network packet ager had to be modified to remove global broadcast interrupt packets that are too old.
Switched the system back to running at 40 MHz. It was taking too long to build systems.
I have partially implemented remote procedure call buffers. The timer ISR for each core scans the buffers looking for RPC requests. If there is one it calls a dispatcher, but the dispatcher is stubbed out ATM.

I can get most if not all of the cores working by issuing the RESET command. There must be something in the timing of a hard reset that fouls things up. Still have not been able to get serial port loads into the FPGA board to work. I did manage to get TinyBasic LOAD to work. So, I can create TinyBasic programs and load and store them.

Latest Fixes
Found out the character colors in the text display were off by one character. The character colors needed another pipeline reg.
Forgot to include a case in the nic controller’s addressing to allow access to the global DRAM. This caused cores to hang trying to access the DRAM. Fixed this, but the cores still hang trying to access DRAM.

Latest Mods
Added redirect commands to TinyBasic to redirect I/O to either the serial port or the console. This is handy to be able to load and store information.

Latest Issue
Whenever something is received from the serial port, the keyboard stops working correctly. This turned out to be the serial port which was not zeroing out the output when not selected, and I had wire-or’d all the I/O outputs of different devices together.

Where did you find a decent test for the opcodes?

Glad you asked, I thought I had mentioned it before.

The test suite is derived from https://github.com/cdifan/cputest. which itself is derived from MicroCoreLabs https://github.com/MicroCoreLabs/Projec ... _Test_Code.

I adapted it to run on the test system and commented out a couple of instructions. (BCD, DIVS).

Ah, so you have a version which "compiles" in VASM?

Yes. It compiles using vasm with vasm generated for Motorola syntax. I added a couple of control registers and the 68010's movec instruction to it. (movec is already in the assembler for the >=68010). The great thing is it uses the vlink linker too, so it should be possible to compile programs with vbcc, the C compiler; but, I have not tried this yet.

Any chance you would share it?

I'm working on my own 68k, and should start to check the opcodes ...

Any other pointers to some 68k tests?

Yes. It is in my Github account under the rf68000 repository which is publicly accessible.

https://github.com/robfinch/rf68000

Vasm changes are under the software/vasm folder. Only the changed files are there. It is necessary to get vasm source from the vasm site to build and compile vasm.
There is a copy of the executable under the software/examples directory. The cputest.asm source is there as well.


I would be tempted to try running a program like Tutor for the 68000. I discovered a lot bugs getting a monitor program to work. I do not know of any other publicly available test suites. Getting a wide variety of 68k software running correctly is one way to test. TinyBasic is another program that could be used as a test.

I believe the guy who maintains WinUAE (Toni Wilen - mangled spelling probably) has some of the most extensive tests for 680x0 compatibility. The 68000 implementation is supposedly clock cycle perfect even for esoteric happenings.