A 32 Bit Variable Length Instruction Set Core and Transputer Like Comms Network
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 !
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.