Trinity Core and Net

Now updated the Assembler which should avoid the issue with too long a concatenated string.

A lot cleaner as well.

Putting a program together I appear to have discovered a limitation.
The Assembler would build up a long string of '1's and '0's using concatenation. This would then be chopped into 32 bits and put into a .mif file.

I had a test program which when ran came up with a non decodable instruction Exception.
This was a PushF instruction that I've used before many times.

Debugging eventually came to a print of the line before and after the concatenation. Low and behold the leading bit of the instruction appeared to disappear.

This means that something somewhere is going wrong in the way that the concatenation operator is working within Perl.

I don't think GAS has the ability to select an instruction depending upon it's possible registers, a smaller instruction could be used if r0 -> r15 is used in comparison to r0 -> r31.

Might need to be a different approach to creating the .mif file.

As mentioned in previous logs I've been able to get data out as a 'Serial Screen'.

I've now turned towards getting data into the Trinity Complex from the Serial Port.

This I have now successfully done by a small program which detects and interrupt from the UART and places the character into the next position within the display memory.

I noticed an oddity along the way which I need to investigate but the main aim of getting data in and out of Trinity via the UART is successfully completed.

I've now updated the assembler to allow a Labelled Memory block to be reserved.

Useful for defining a display memory or a DMA region.

The Serial Display Engine is now up and running. A few 'DOH' moments but got there :)

I've connected up the Serial Display block and written some test code to just run it up in simulation.
it looks like it can get a screen update in approx 163 ms. As mentioned previously the Doherty Threshold is at 400 ms so if there is any lag in the response it's not down to the display mechanism.
The next step is to get the design resynthersized and tested using a terminal on the laptop.

Once this is looking good I'll start looking at the input side of things and see if it works as well.

Note that I improved the UART block again as the original interrupt logic was just pants for the TX side. I have a suspicion that the RX side will not be any different !

The initial RTL prior to debug has been written for the Serial Display peripheral. The display address will start at any byte address which will make things flexible.

It compiles and elaborates on it's own successfully. Next to link it in to the Dual Complex.

I've written a program that just sends out 32 lines with 80 characters at 115200 Baud.

The aim of this program was to show I can control the screen appropriately. The timing turned out to be below the Doherty limit with timing loops to do the delay between characters to be sent out.

This means that I have all the information needed for the creation of the block to send a memory area to a serial port. This will assume a dedicated Serial TX port for the display.

The next step will get to see data coming down the line to Trinity and then displaying it.

From the previous success of getting the RS232 to work at 9600 Baud the next incremental step is to get it to work at 115200 Baud.

This has now been done successfully.

The reason for getting this to work is to see if I can create a real time 'large' display of 80 characters by at least 30 lines.
To do this we need to send the contents of what is needed to be displayed plus the command codes to send the cursor around a monitor. Carriage Return and Line Feed will get the cursor down and to the left of the screen. The cursor needs to get back to the home position. I understand that the cursor can be sent up n lines using VT100 codes which takesfour characters.
This display needs to be refreshed within 400 ms. This is the Doherty Threshold as made famous in 'Halt and Catch Fire'. By ensuring that all the characters are sent in this time we can guarrantee that the Doherty Threshold is met.

The plan is to initially confirm the screen control via writing the appropriate characters.
Once this has been confirmed the Screen Engine will be written.
An area of memory will represent the screen, the Screen Engine will transfer the memory contents to a Tx Uart. It will then pass the control charcters.
For a 40 line by 80 character display then 3200 printing characters need to be sent. Along with these we have 40 Carriage Returns, 40 Line Feeds and then finally four characters to send the cursor back home. So we are looking at 3284 characters. 
If we are to keep within the Doherty Threshold at 115200 Baud then we can send 4602 characters, so 3284 characters is well within this limit.
As to response time of the machine that will be up to the software to be written, however by making the Screen Engine handle the display the Software can get on with the job working out what is needed to be displayed the problem is reduced.

A weekend of some success ! Barring a bug which I am still yet to fix in the Branch Predict I have managed to achieve the goal of this weekend.

Yet I have now sent text from Trinity to the Mac !