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.
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 !
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.