A 32 Bit Variable Length Instruction Set Core and Transputer Like Comms Network
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 !
I had a look at reducing the amount of area for Trinity. I came up with a significant saving by reducing the number of levels 'pages' dedicated to the Exception Level. Bringing this down to four pages means that at the fourth nested level you need to push stuff into an Exception Stack. I could make this more automatic but I'm going to leave it for now.
This means that everything is back in play.
Back to getting the RS232 to work. A bit of pipecleaning. I have an old Amstrad NC100 (Noddy) which happens to have an RS232 port. Resurrecting old kit is fun but it appears to be working.
I bought what is advertised as a USB to RS232 conversion cable that can cope with a full +/- 12 V swing. This along with a Null Modem cable I connected up to Noddy and the Mac. Using Zterm I managed to get comms up and running in both directions at 9600 Baud. The following steps will now be made
1. Send a series of characters to Noddy from the FPGA board at 9600 Baud using the Null Modem cable.
2. Write a routine that runs on an interrupt to take the incoming character and then display it on the LCD display.
3. Send characters to the FPGA board from Noddy at 9600 Baud again using the Null Modem cable.
4. Connect the Mac to the FPGA board using the USB RS232 cable and the Null Modem.
5. Expand the amount of Memory available to the Trinity Dual Complex.
6. Write some kind of Monitor to allow downloading of programs and uploading of results.I'll see what I can do when I get some time.
There have been a few things happening since my last entry.
1. Movement of Call Return Address Register to R0.
2. An improvement of the Stack Push instruction by one clock cycle.
3. Finally hard overflowing of the area on my FPGA so that to keep two cores I had to lose the DMA block.
4. Getting 6.0 + 7.0 = 13.0 .
I've now been able to write some routines in Assembler to do Floating Point operations. Now I am sure a Professional Software Engineer might raise their eyebrows and I need to go through the routines possibly to clean up, or at least comment them, but I now have a small group of routines to do floating point support operations.
Here is a screen shot. Single Precision IEEE 754 in software adding 6.0 to 7.0 getting 13.0.
I've now implemented the two instruction Insert and Extract.
The reason for this is that I am starting to look at some Floating Point code with the intention of making it easier to work on IEEE 754 Standard.
Infact I have plans to extend those instructions but let's leave that for now.
The intention is to get some form of Single Precision Math up and running. If I can get that up and running then I will be on the path where I can start to do some cunchy compute on the Array.
Slow, incredibly SLOW but got to aim high :).
The smaller 2 D Trinity Net by the looks of it is up and running. A couple of squeaks but wasn't too bad.
Did notice a couple of possible improvements along the way so will target those next.
Getting this up and running means that I will be able to get an array into the larger FPGA board.
I would prefer to get this all tested out and secure before concentrating on the RS232 again. With that good to go I can start to write some code and get it to deploy to the array.
I've also bought a four line LCD display which will be used by the master to display information. This implies four machines but might be able to use two to a line.
Slow but sure.