This list is for discussion of the design and implementation of field-programmable gate array based processors and integrated systems. It is also for discussion and community support of the XSOC Project (see http://www.fpgacpu.org/xsoc).
|
Does anyone have information on where I might get a free (or very low cost) CRT core? I am looking for text only, 25 lines of 80 chars. On the surface the design seems simple enough but if it has already been done there is not much point in doing it again. I have some space left in my Spartan IIE with the T80 core running CP/M. I might as well fill it up and drive a VGA monitor instead of a physical terminal or something like Hyperterminal. I would also add a keyboard interface. Thanks! |
|
|
|
At 07:14 PM 8/30/2004, you wrote: >Does anyone have information on where I might get a free (or very >low cost) CRT core? I am looking for text only, 25 lines of 80 >chars. On the surface the design seems simple enough but if it has >already been done there is not much point in doing it again. > >I have some space left in my Spartan IIE with the T80 core running >CP/M. I might as well fill it up and drive a VGA monitor instead of >a physical terminal or something like Hyperterminal. I would also >add a keyboard interface. > >Thanks! Try opencores.org, they have a number of cores and one is a video controller. http://www.opencores.org/projects.cgi/web/vga_lcd If you only need text, you might be better off designing your own and saving the logic. An 80x25 text display is very, very simple and should not take much time to design. If you want, I might do it as an exercise. :) Be aware that VGA uses ADC converters to drive the three colors. You can kludge the interface from a digital output like this... http://www.fpga4fun.com/PongGame.html This sort of thing can give you up to 8 colors which is plenty for a text display. You can also add a few more resistors (and outputs) and have three or four levels on each output which can give you up to 64 colors. Much beyond that and you will likely see problems with quality. Rick Collins Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAX |
|
|
|
Hi All, It might be worth looking at the www.ExpressIP.co.uk web site as they give away a free VGA graphics controller that can also work on a TV as well. It works with our PS2 mouse (or other device) controller. It has a font rendering engine included. You also get an SDRAM controller (high performance) DMA engine, risc cpu (16 bit with i / d cache, c- compiler etc), RS232 + other cores WEB : www.ExpressIP.co.uk Thanks Lee ----- Original Message ----- From: "rtstofer" <> To: <> Sent: Tuesday, August 31, 2004 12:14 AM Subject: [fpga-cpu] Simple Character CRT Core Needed > > Does anyone have information on where I might get a free (or very > low cost) CRT core? I am looking for text only, 25 lines of 80 > chars. On the surface the design seems simple enough but if it has > already been done there is not much point in doing it again. > > I have some space left in my Spartan IIE with the T80 core running > CP/M. I might as well fill it up and drive a VGA monitor instead of > a physical terminal or something like Hyperterminal. I would also > add a keyboard interface. > > Thanks! > To post a message, send it to: > To unsubscribe, send a blank message to: > Yahoo! Groups Links |
|
Hi, There is a simple 64 x 32 text character display in my System09 SOC. It should be portable to the T80. Getting 25 x 80 characters would need a bit more work mapping the row and column address. http://members.optushome.com.au/jekent/system09/index.html (Look at the bottom of the page) It uses a 25MHz Pixel Clock and makes use of the Block RAM (if I remember correctly) for the Text buffer, Colour Attribute buffer and character generator. It supports 4 bits of forground colour and 4 bits of background colour. It has 4 registers: Cursor Row Address, Cursor Colum Address, Text Character Colour Attribute. To Move the cursor you increment the column address to write a character, you set up the colour Atribute and write an ASCII character to the Text Character Register. It's very basic and does not do anything like clearing the bottom line on line feeds ... you have to do that in software. It was designed for Tony Burch's FPGA board. I've also written the open cores P/S 2 keyboard in VHDL. (It was in Verilog). That's availaible in System09 too. John. rtstofer wrote: >Does anyone have information on where I might get a free (or very >low cost) CRT core? I am looking for text only, 25 lines of 80 >chars. On the surface the design seems simple enough but if it has >already been done there is not much point in doing it again. > >I have some space left in my Spartan IIE with the T80 core running >CP/M. I might as well fill it up and drive a VGA monitor instead of >a physical terminal or something like Hyperterminal. I would also >add a keyboard interface. > >Thanks! > -- http://members.optushome.com.au/jekent |
|
|
|
I stand corrected, 5 registers. It also has a Row offset register for scrolling the screen J. John Kent wrote: >Cursor Row Address, >Cursor Colum Address, >Text Character >Colour Attribute. -- http://members.optushome.com.au/jekent |
|
Thanks! I'll give it a look. I am using Tony Burch's board as well. The ExpressIP site is pretty useful as well. They have a lot of IP stuff to go with their board. --- In , John Kent <jekent@o...> wrote: > Hi, > > There is a simple 64 x 32 text character display in my System09 SOC. > It should be portable to the T80. > Getting 25 x 80 characters would need a bit more work mapping > the row and column address. > > http://members.optushome.com.au/jekent/system09/index.html > (Look at the bottom of the page) > > It uses a 25MHz Pixel Clock and makes use of the Block RAM > (if I remember correctly) for the Text buffer, Colour Attribute buffer > and character generator. It supports 4 bits of forground colour and > 4 bits of background colour. > > It has 4 registers: > > Cursor Row Address, > Cursor Colum Address, > Text Character > Colour Attribute. > > To Move the cursor you increment the column address > to write a character, you set up the colour Atribute and write an > ASCII character to the Text Character Register. > It's very basic and does not do anything like clearing the bottom > line on line feeds ... you have to do that in software. > > It was designed for Tony Burch's FPGA board. > > I've also written the open cores P/S 2 keyboard in VHDL. > (It was in Verilog). That's availaible in System09 too. > > John. > rtstofer wrote: > > >Does anyone have information on where I might get a free (or very > >low cost) CRT core? I am looking for text only, 25 lines of 80 > >chars. On the surface the design seems simple enough but if it has > >already been done there is not much point in doing it again. > > > >I have some space left in my Spartan IIE with the T80 core running > >CP/M. I might as well fill it up and drive a VGA monitor instead of > >a physical terminal or something like Hyperterminal. I would also > >add a keyboard interface. > > > >Thanks! > > > > > > > -- > http://members.optushome.com.au/jekent |
|
I had seen the listing at opencores and it seemed far too complex. At the moment I think I just want 80x25 but it also needs to do the control codes for a TV950 or ADM3a (switchable?) as some of the old software is configured and I can't seem to get it to change - Turbo Pascal and its TINST for example. I don't know why I can't get it to work but I think it has something to do with an error in the download. I had a large Fortran program that wouldn't run until I downloaded the compiler/linker and recompiled on the target. Curious... Well, I haven't used these programs in 20 years so it's possible I have forgotten some of the details. I bought the Xilinx Spartan-3 Starter Kit the other day (what a bargain for $100) and started to play with it last night. What do you know? There's a reason for the VGA connector on the board - there is a text mode VGA component included and it is ready to rock and roll. There's a ton of stuff that comes with this kit and, although a little small at 200k gates, $100 is not much tuition these days. --- In , Arius - Rick Collins <dsprelated@a...> wrote: > At 07:14 PM 8/30/2004, you wrote: > > >Does anyone have information on where I might get a free (or very > >low cost) CRT core? I am looking for text only, 25 lines of 80 > >chars. On the surface the design seems simple enough but if it has > >already been done there is not much point in doing it again. > > > >I have some space left in my Spartan IIE with the T80 core running > >CP/M. I might as well fill it up and drive a VGA monitor instead of > >a physical terminal or something like Hyperterminal. I would also > >add a keyboard interface. > > > >Thanks! > Try opencores.org, they have a number of cores and one is a video controller. > > http://www.opencores.org/projects.cgi/web/vga_lcd > > If you only need text, you might be better off designing your own and > saving the logic. An 80x25 text display is very, very simple and should > not take much time to design. If you want, I might do it as an exercise. :) > > Be aware that VGA uses ADC converters to drive the three colors. You can > kludge the interface from a digital output like this... > > http://www.fpga4fun.com/PongGame.html > > This sort of thing can give you up to 8 colors which is plenty for a text > display. You can also add a few more resistors (and outputs) and have > three or four levels on each output which can give you up to 64 > colors. Much beyond that and you will likely see problems with quality. > > Rick Collins > > rick.collins@a... > > Arius - A Signal Processing Solutions Company > Specializing in DSP and FPGA design http://www.arius.com > 4 King Ave 301-682-7772 Voice > Frederick, MD 21701-3110 301-682-7666 FAX |
|
|
|
At 02:32 PM 8/31/2004, you wrote:
>I had seen the listing at opencores and it seemed far too complex. >At the moment I think I just want 80x25 but it also needs to do the >control codes for a TV950 or ADM3a (switchable?) as some of the old >software is configured and I can't seem to get it to change - Turbo >Pascal and its TINST for example. I don't know why I can't get it >to work but I think it has something to do with an error in the >download. I had a large Fortran program that wouldn't run until I >downloaded the compiler/linker and recompiled on the target. >Curious... Well, I haven't used these programs in 20 years so it's >possible I have forgotten some of the details. > >I bought the Xilinx Spartan-3 Starter Kit the other day (what a >bargain for $100) and started to play with it last night. What do >you know? There's a reason for the VGA connector on the board - >there is a text mode VGA component included and it is ready to rock >and roll. There's a ton of stuff that comes with this kit and, >although a little small at 200k gates, $100 is not much tuition >these days. I guess you could do the full terminal emulation in hardware, but that is normally done in software with the basic memory to raster conversion done in hardware. The software writes the appropriate characters to the display memory according to the commands that are received. Perhaps I am misunderstanding what your CRT is doing. I was assuming that you wanted a computer console CRT controller like the VGA card in a PC. Is this instead intended to be a terminal emulation as if it had a serial connection to the CPU? In that case, you can implement the terminal commands in hardware, but that is very different from a CRT controller, which is what I was pointing you to. I have a VHDL UART emulation for a board that plugs into a PC/104 bus (same as the PC ISA). The CPU thinks it is talking to a UART connected via a serial port to another device (my board). But this requires much of the work to be done in a CPU (which is also in the FPGA). If you are designing a terminal emulation, this is similar to what you would need. Rick Collins Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAX |
|
|
|
heres a verilog uart you can strip it down and simplify it by finding the Tx and Rx state machines and making use of them descretely.... Peace http://ca.geocities.com/artiedc/files/UartZip.zip Ed Corter Resume Page http://www.geocities.com/artiedc/ --------------------------------- |
|
Hi, If you want to squeeze the VDU on with the T80, but want to have intelligence in the video display, you might consider cobbling the VDU in with a small micro like my Micro8/8a and write the video driver in the Micro8. If you have the Xilinx Spartan3 starter board as well as Tony's board, it sounds like you could just about have an intelligent T80 based VDU on the starter board. The Starter board looks great by the way... I was inspired to make inquiries at my local Xilinx agent today. Anyway ... Have a look around my web site: http://members.optushome.com.au/jekent/FPGA.htm The ADM3a was pretty basic ... I think it just honoured the basic control characters and had an addressable cursor command. it should not be too hard to write an intellegent VDU driver for it if you know what the command set it. I have some video drivers for a Thomas VDU written for the 6800. You can fit my 6800 with UART in a XSA100 (100Kgate FPGA) so you should be able to fit it comfortably on a 200Kgate Spartan 3 with a VDU. John. rtstofer wrote: >I had seen the listing at opencores and it seemed far too complex. >At the moment I think I just want 80x25 but it also needs to do the >control codes for a TV950 or ADM3a (switchable?) as some of the old >software is configured and I can't seem to get it to change - Turbo >Pascal and its TINST for example. I don't know why I can't get it >to work but I think it has something to do with an error in the >download. I had a large Fortran program that wouldn't run until I >downloaded the compiler/linker and recompiled on the target. >Curious... Well, I haven't used these programs in 20 years so it's >possible I have forgotten some of the details. > >I bought the Xilinx Spartan-3 Starter Kit the other day (what a >bargain for $100) and started to play with it last night. What do >you know? There's a reason for the VGA connector on the board - >there is a text mode VGA component included and it is ready to rock >and roll. There's a ton of stuff that comes with this kit and, >although a little small at 200k gates, $100 is not much tuition >these days. > -- http://members.optushome.com.au/jekent |
|
|
|
I was looking at the Map Report for the FPGA after the T80 core, dual serial ports and the IDE interface are all mapped and the complete system including monitor/boot ROM use well under 50% of the resources. The system is about 92,000 equivalent gates out of about 300,000. More important is Block RAM - here the 2k byte NoICE monitor uses 25% of available Block RAM. This leaves 48k bits available for screen memory and a character generator and, if necessary, the monitor could be eliminated and replaced with the 128 byte boot code. Screen memory of 2000 characters with 10 bits/char plus a character generator of 128 chars at 64 bits/char would require a total 28192 bits - this should fit easily. I figured that if a complete Z80, 2 serial ports and all the other components would fit in less than half the space, it should be possible to fit an ADM3A in the remainder. Maybe there would be room for a PS/2 port for the keyboard or I could use one of the serial ports. A one chip solution (not counting external SRAM) is very appealing! --- In , John Kent <jekent@o...> wrote: > > Hi, > > If you want to squeeze the VDU on with the T80, but want to have > intelligence > in the video display, you might consider cobbling the VDU in with a > small micro > like my Micro8/8a and write the video driver in the Micro8. > > If you have the Xilinx Spartan3 starter board as well as Tony's board, > it sounds > like you could just about have an intelligent T80 based VDU on the > starter board. > > The Starter board looks great by the way... I was inspired to make inquiries > at my local Xilinx agent today. Anyway ... Have a look around my web site: > > http://members.optushome.com.au/jekent/FPGA.htm > > The ADM3a was pretty basic ... I think it just honoured the basic control > characters and had an addressable cursor command. it should not be too hard > to write an intellegent VDU driver for it if you know what the command > set it. > > I have some video drivers for a Thomas VDU written for the 6800. > You can fit my 6800 with UART in a XSA100 (100Kgate FPGA) > so you should be able to fit it comfortably on a 200Kgate Spartan 3 > with a VDU. > > John. > > rtstofer wrote: > > >I had seen the listing at opencores and it seemed far too complex. > >At the moment I think I just want 80x25 but it also needs to do the > >control codes for a TV950 or ADM3a (switchable?) as some of the old > >software is configured and I can't seem to get it to change - Turbo > >Pascal and its TINST for example. I don't know why I can't get it > >to work but I think it has something to do with an error in the > >download. I had a large Fortran program that wouldn't run until I > >downloaded the compiler/linker and recompiled on the target. > >Curious... Well, I haven't used these programs in 20 years so it's > >possible I have forgotten some of the details. > > > >I bought the Xilinx Spartan-3 Starter Kit the other day (what a > >bargain for $100) and started to play with it last night. What do > >you know? There's a reason for the VGA connector on the board - > >there is a text mode VGA component included and it is ready to rock > >and roll. There's a ton of stuff that comes with this kit and, > >although a little small at 200k gates, $100 is not much tuition > >these days. > > > > > > > > -- > http://members.optushome.com.au/jekent |
|
|
|
That sounds cool. A small micro, a UART, PS/2 interface and a VDU should fit no problem. My VDU uses 6KBytes or 48Kbits of Block RAM. 2KB for the Text buffer, 2KB for the colour attributes and 2KB ??? (possibly 1K) for the character generator. You connect one of the UARTs back to back with the VDU UART and have a separate SOC to control the Display. An ADM3a terminal driver won't take much coding. You are going to have to do a little work though. The VDU micro is going to require a small amount of RAM and ROM too ... If your T80 is only using 33% of a 300K FPGA you could probably instantiate a second copy of the T80 and UART, add the VDU and use that to drive the display. I have an old Z80 board that has a built in ADM3a terminal emulator ... I may be able to dig up the code for that if you like ... The PS/2 keyboard interface is available on my web site as well as open cores. My System68 sounds like it is not as efficiently coded as the T80, but you could certainly use that as well. Do you need some assistance putting it together ? John. rtstofer wrote: >I was looking at the Map Report for the FPGA after the T80 core, >dual serial ports and the IDE interface are all mapped and the >complete system including monitor/boot ROM use well under 50% of the >resources. The system is about 92,000 equivalent gates out of about >300,000. > >More important is Block RAM - here the 2k byte NoICE monitor uses >25% of available Block RAM. This leaves 48k bits available for >screen memory and a character generator and, if necessary, the >monitor could be eliminated and replaced with the 128 byte boot >code. Screen memory of 2000 characters with 10 bits/char plus a >character generator of 128 chars at 64 bits/char would require a >total 28192 bits - this should fit easily. > >I figured that if a complete Z80, 2 serial ports and all the other >components would fit in less than half the space, it should be >possible to fit an ADM3A in the remainder. Maybe there would be room >for a PS/2 port for the keyboard or I could use one of the serial >ports. > >A one chip solution (not counting external SRAM) is very appealing! > -- http://members.optushome.com.au/jekent |
|
|
|
I probably won't start work on this until next week. I need to port the BIOS from the PC using the PseudoSam assembler to the FPGA using the MAC assembler. Unfortunately the source code syntax is considerably different - a complete rewrite is required. Today's effort was to implement a way to have the cold start loader pick one of two BIOSs depending on a config switch. This will allow me to write a developmental BIOS on the actual machine and not lunch the whole thing. I'm going to look further at what you have done. I had thought that the internal ADM3A would just communicate over the internal 8 bit bus and take data as a port. From the outside the code would just stick a byte in a port just as though it was headed toward one of the UARTs but with no need to check status (?). One of my first problems is going to be quite difficult. Although the Timing Report says this thing should run very fast, I haven't been able to get it much over 14 MHz. I would like to get to 29.491200 MHz to match the standard VGA pixel rate for 640x480 (actually a little more than the 25 MHz normally used) and also have a convenient baud rate divider. I'm not sure which part of the system is having difficulties and I don't have any documentation that says "Hey, this thing will run xxx MHz!". I could always cheat and use a 29 MHz clock for the display and divide it in half for the T80 but I would really rather have 29 MHz throughout. If you have ideas about how I should proceed on the speed issue please let me know. I am an absolute beginner with FPGAs and really don't have a clue about how to tackle this - other than test signals and a scope. I'll keep in touch... --- In , John Kent <jekent@o...> wrote: > That sounds cool. > > A small micro, a UART, PS/2 interface and a VDU should fit no problem. > My VDU uses 6KBytes or 48Kbits of Block RAM. 2KB for the Text buffer, > 2KB for the colour attributes and 2KB ??? (possibly 1K) for the character > generator. > > You connect one of the UARTs back to back with the VDU UART and have > a separate SOC to control the Display. An ADM3a terminal driver won't take > much coding. You are going to have to do a little work though. The VDU micro > is going to require a small amount of RAM and ROM too ... > > If your T80 is only using 33% of a 300K FPGA you could probably instantiate > a second copy of the T80 and UART, add the VDU and use that to drive the > display. I have an old Z80 board that has a built in ADM3a terminal > emulator ... > I may be able to dig up the code for that if you like ... > The PS/2 keyboard interface is available on my web site as well as open > cores. > > My System68 sounds like it is not as efficiently coded as the T80, but > you could > certainly use that as well. Do you need some assistance putting it > together ? > > John. |
|
|
|
Hi rstofer, (what is your first name ?) My System09 will only run at 12.5MHz, but that is the basic E clock. I'm nesting the decodes of the opcode register, in the state sequencer which is not very efficient. I also use the ALU for everything including indexing address calculations. It would probably work a bit faster if I reduced the size of the mux on the ALU inputs and had a seperate address adder for the addressing modes. Floor planning the design would probably help too, but I don't have that much time to play with it these days. I don't think there is a lot you can do with the industry standard 8 bit CPUs as they do not really allow you to pipeline the instructions. I think my design had an address setup time of around 30nSec and a data setup time on reads of about 20nsec This left about 30nsec to access SRAM which is probably what you need if you are runing ribbon cables to the SRAM. (Tony uses 15nsec RAM) 640 x 480 you should work quite happily at 25MHz. Multisynch monitors don't seem to be *that* fussy about the line and frame rate and you can normally compensate by adjusting the monitor settings. I run my system09 at half the pixel clock rate. It would be nice to run it faster ... but what the hey ... if I want a faster computer I would use my PC. Looking at the code on the web, I noticed that I was using 19.8MHz for the pixel clock rate (hence 64 characters across). At least that is what it says in the documentation at the header of the code. I'm not sure the documentation has kept pace with the actual design though ;-). 19.8MHz is a nice binary multiple of the baud clock. In later designs I pushed it up to 25MHz and it still worked OK. I used a divide by 27 to get the correct baud rate clock. To clear the bottom line of the screen when doing a line feed, you need some smarts in the logic to clear the bottom line. Normally this is done with some sort of state machine as part of the line scan function.You also need to do some character decoding to handle the addressable cursor. It's doable in hardware, but it's a lot easier and flexible to do it in software. You also have the advantage of being able to buffer incoming characters. I'm waffling on here ... sorry ... You need to set up the constraints file to check the propagation delays in each section of code or use the simulator. I used to know how to do it with web pack ISE 4.2 but the scheme has changed a little with later releases of web pack. (I'm no expert either :-) If you have not used the modeltech simulator, Its probably a good idea to try it. You should be able to simulate a post placed and routed design although so far I have only used it as a functional simulator to verify that the CPU is executing the correct cycles which did not include the propagation delays in the design ... I'm sure others on the list can help you out with that. John. rtstofer wrote: >I probably won't start work on this until next week. I need to port >the BIOS from the PC using the PseudoSam assembler to the FPGA using >the MAC assembler. Unfortunately the source code syntax is >considerably different - a complete rewrite is required. > >Today's effort was to implement a way to have the cold start loader >pick one of two BIOSs depending on a config switch. This will allow >me to write a developmental BIOS on the actual machine and not lunch >the whole thing. > >I'm going to look further at what you have done. I had thought that >the internal ADM3A would just communicate over the internal 8 bit >bus and take data as a port. From the outside the code would just >stick a byte in a port just as though it was headed toward one of >the UARTs but with no need to check status (?). > >One of my first problems is going to be quite difficult. Although >the Timing Report says this thing should run very fast, I haven't >been able to get it much over 14 MHz. I would like to get to >29.491200 MHz to match the standard VGA pixel rate for 640x480 >(actually a little more than the 25 MHz normally used) and also have >a convenient baud rate divider. I'm not sure which part of the >system is having difficulties and I don't have any documentation >that says "Hey, this thing will run xxx MHz!". I could always cheat >and use a 29 MHz clock for the display and divide it in half for the >T80 but I would really rather have 29 MHz throughout. > >If you have ideas about how I should proceed on the speed issue >please let me know. I am an absolute beginner with FPGAs and really >don't have a clue about how to tackle this - other than test signals >and a scope. > >I'll keep in touch... -- http://members.optushome.com.au/jekent |
|
|
|
John, I am starting to look at clock dividers - like you say, if I need a lot of speed I can use my PC. The next project is a Pascal P4 implementation and I expect a lot more from the chip but I'll have the advantage (?) of a clean piece of paper and the ability to throw hardware at the interpreter until it is highly parallel. We'll see... If I can get a clock divider to work then that's the way it will stay. The timing report shows a minimum period of just under 30 nS and if I add something for the SRAM (say 15 nS) and another 15 nS for slop I come up with 60 nS or about 16 MHz and I am running 14.7 so I may have maxed out without doing a lot more work. Richard --- In , John Kent <jekent@o...> wrote: > Hi rstofer, > > (what is your first name ?) > > My System09 will only run at 12.5MHz, but that is the basic E clock. > I'm nesting the decodes of the opcode register, in the state sequencer > which is not very efficient. I also use the ALU for everything including > indexing address calculations. It would probably work a bit faster if I > reduced the size of the mux on the ALU inputs and had a seperate > address adder for the addressing modes. > > Floor planning the design would probably help too, but I don't have that > much time to play with it these days. I don't think there is a lot you > can do > with the industry standard 8 bit CPUs as they do not really allow you to > pipeline the instructions. I think my design had an address setup time > of around 30nSec and a data setup time on reads of about 20nsec > This left about 30nsec to access SRAM which is probably what > you need if you are runing ribbon cables to the SRAM. > (Tony uses 15nsec RAM) > > 640 x 480 you should work quite happily at 25MHz. Multisynch monitors > don't seem to be *that* fussy about the line and frame rate and you can > normally compensate by adjusting the monitor settings. > I run my system09 at half the pixel clock rate. It would be nice to run > it faster ... but what the hey ... if I want a faster computer I would > use my PC. > > Looking at the code on the web, I noticed that I was using 19.8MHz > for the pixel clock rate (hence 64 characters across). At least that is what > it says in the documentation at the header of the code. I'm not sure the > documentation has kept pace with the actual design though ;-). > 19.8MHz is a nice binary multiple of the baud clock. In later designs I > pushed it up to 25MHz and it still worked OK. I used a divide by 27 > to get the correct baud rate clock. > > To clear the bottom line of the screen when doing a line feed, you need > some smarts in the logic to clear the bottom line. Normally this is done > with > some sort of state machine as part of the line scan function.You also > need to do > some character decoding to handle the addressable cursor. It's doable > in hardware, but it's a lot easier and flexible to do it in software. > You also have > the advantage of being able to buffer incoming characters. > > I'm waffling on here ... sorry ... > > You need to set up the constraints file to check the propagation delays > in each section of code or use the simulator. I used to know how to do > it with web pack ISE 4.2 but the scheme has changed a little with later > releases of web pack. (I'm no expert either :-) > > If you have not used the modeltech simulator, Its probably a good idea > to try it. You should be able to simulate a post placed and routed design > although so far I have only used it as a functional simulator to verify that > the CPU is executing the correct cycles which did not include the > propagation > delays in the design ... I'm sure others on the list can help you out > with that. > > John. |
|
|
|
John, I stole the design of your clock divider with the following: library IEEE; use IEEE.STD_LOGIC_1164.ALL; use IEEE.STD_LOGIC_ARITH.ALL; use IEEE.STD_LOGIC_UNSIGNED.ALL; --***************************** -- Added the following library --***************************** library UNISIM; use UNISIM.vcomponents.all; entity VDU is Port ( Reset_n : in std_logic; Clk_in : in std_logic; CPU_Clk_out : out std_logic); end VDU; architecture Behavioral of VDU is signal Divider : std_logic_vector(1 downto 0); component BUFG port ( i: in std_logic; o: out std_logic ); end component; begin process (Reset_n, Clk_in) begin if Reset_n = '0' then Divider <= (others => '0'); elsif Clk_in'event and Clk_in = '1' then Divider <= Divider + 1; end if; end process; clk_buffer: BUFG port map ( i => Clk_in, o => CPU_Clk_out ); end Behavioral; and at the top level instantiated it with: u5 : entity work.VDU port map ( Reset_n => Reset_s, Clk_in => SysClk, CPU_Clk_out => Clk); SysClk is the signal coming in to the chip from the oscillator and this is the only place it is connected. Clk is used everywhere. Now the question: throughout your system you have used falling clock edges while the T80 core uses rising edges. Is this a difference worth noting? The reason I ask is that the divider doesn't work if I use ANY signal other that Clk_in as the input to the BUFG. If I use 'not Clk_in' or 'Divider(0)' the system does not function and by that I mean that even the divider driving the LED (which uses Clk) is not functioning. I can only assume that there is no clock coming out of VDU. I haven't brought it to a pin to prove it because I figured that if the LED doesn't blink there isn't much in the way other than a missing clock. It's obvious I have messed up - do you have any idea how? Richard |
|
|
|
Hi Richard, rtstofer wrote: Snip... snip >SysClk is the signal coming in to the chip from the oscillator and >this is the only place it is connected. Clk is used everywhere. > >Now the question: throughout your system you have used falling clock >edges while the T80 core uses rising edges. Is this a difference >worth noting? > Yes ... System09 clocks on the falling edge. I think it's simply a matter of changing all the occurrences of if clk'event and clk=0 then to if clk'event and clk=1 then That's assuming data is valid on the rising edge of the clock. The SystemXX family also use R/W and the clock, where as I think the T80 uses separate RD and WR signals .... I use a mux on all the data inputs so the RD does not matter ... data is valid if you select a device. >The reason I ask is that the divider doesn't work if I use ANY >signal other that Clk_in as the input to the BUFG. If I use 'not >Clk_in' or 'Divider(0)' the system does not function and by that I >mean that even the divider driving the LED (which uses Clk) is not >functioning. I can only assume that there is no clock coming out of >VDU. I haven't brought it to a pin to prove it because I figured >that if the LED doesn't blink there isn't much in the way other than >a missing clock. > >It's obvious I have messed up - do you have any idea how? > The only thought I had was if you have a synchronous reset somewhere that held the divider reset, hence no clock to release it .... But looking at your code, that does not appear to be the problem. From my observation of the FPGA lists there is bit of a holy war, whether to use synchronous or asynchronous resets. I tended to swap arount a bit, which probably makes things worse. BTW. I received my Xilinx starter kit today .... the FPGA looks very small It does not look like it has enough pins on it to do everything :-) You mentioned that there was a heap of IP that came with the board ... I had a quick look on the starter disk but only saw applications notes in PDF format. I have not looked on the ISE 6.2 disks. John. -- http://members.optushome.com.au/jekent |
|
|
|
> I had a quick look on the starter disk but only saw applications notes > in PDF > format. I have not looked on the ISE 6.2 disks. There are a number of ZIP files in D:\FILES\APPNOTES. I wasn't paying attention when I followed the link from the CD to Xilinx: The IP goodies are in the MicroBlaze Master System ZIP file at http://www.xilinx.com/products/spartan3/s3boards.htm#RF There are quite a few uncommited pins available on both the A2 and B1 edge connector. As I compare it to the B5 board and my T80 implementation, the SRAM takes 2-20 pin connectors on the B5 and it is built in to the starter kit, the dip switches and LEDs take another 2-20 pin connectors and they are built in (not an equal number but sufficient), the IDE interface takes 2-20 pin connectors and, with effort, should run off the A2 connector, the dual UARTS take 1-20 pin connector and that could run off the B1 connector (although 1 serial already exists on the starter board) and that leaves 1-20 pin connector open on the B5 that doesn't exist on the starter kit. However, the starter kit includes the PS/2 and VGA ports. I don't think it is an even match but it's close. I really haven't had time to play with the board - I plugged it in, watched the lights flash and checked the VGA output and put it back in the box. I am workiing pretty much full time on the B5. I think you may be on to something with the reset idea - I'll check it out. The idea obviously works, it is my implementation that is wrong. > > John. > > -- > http://members.optushome.com.au/jekent |
|
|
|
Hi Richard, rtstofer wrote: >I wasn't paying attention when I followed the link from the CD to >Xilinx: The IP goodies are in the MicroBlaze Master System ZIP file >at http://www.xilinx.com/products/spartan3/s3boards.htm#RF > Yes ... I followed that link too, but I thought all the code there was comercial. There was a 6845 CRTC listed, but there is still a bit of work to get it going as a complete Intelligent terminal. >There are quite a few uncommited pins available on both the A2 and >B1 edge connector. As I compare it to the B5 board and my T80 >implementation, the SRAM takes 2-20 pin connectors on the B5 and it >is built in to the starter kit, the dip switches and LEDs take >another 2-20 pin connectors and they are built in (not an equal >number but sufficient), the IDE interface takes 2-20 pin connectors >and, with effort, should run off the A2 connector, the dual UARTS >take 1-20 pin connector and that could run off the B1 connector >(although 1 serial already exists on the starter board) and that >leaves 1-20 pin connector open on the B5 that doesn't exist on the >starter kit. However, the starter kit includes the PS/2 and VGA >ports. > You have to be carefull with the starter kit in that many of the A and B connector pin-outs are shared with the SRAM and might not be usable for expansion. The SRAM on the B5 board is 16 bit and because of the limitted number of pins on the 20 pin headers you can only really fit 256 K bytes or 128KWords. The B5-CPU-IO-Board only takes one 20 pin port but provides more I/O: ie. RS232, PS2 Keyboard, PS2 Mouse, 6bit / 64 Colour VGA, and buzzer. I don't make much use of LEDs switches and Displays so I'm quite happy having the option of leaving them off the B5 board. Maybe a suggestion for future improvements to the B5-CPU-IO would be to use the RTS and CTS signals as a jumperable secondary RS232 TXD/RXD connection on the second DB9 connector. The starter board has 1Mbyte of SRAM with a 32 bit data bus (2 x 16 bits) with upper and lower byte controls on each 16 bit data path. This makes it ideal for 32 bit applications but means you are using up an number of connector and FPGA pins if you are only implementing 8 bit designs. The Starter board manual talks a bit about using configuration Flash for applications code. Presumably you have to code some serial loader to read the Config Flash into SRAM. >I don't think it is an even match but it's close. I really haven't >had time to play with the board - I plugged it in, watched the >lights flash and checked the VGA output and put it back in the box. >I am workiing pretty much full time on the B5. > The B5 board is better set up for expansion. >I think you may be on to something with the reset idea - I'll check >it out. The idea obviously works, it is my implementation that is >wrong. Ok ... I'm not sure what else to check without you sending me the code. I've been working on putting my system09 with VDU into the Xilinx starter board and I've come across a few problems. The 200K gate spartan 3 only has 12 block RAMs where as the 300K gate Spartan 2e (B5 board) has 16 and the 200K Gate Spartan 2+ (B3 board) has 14 Block RAMs (I think). My System09 monitor ROM uses 2Kbytes or 4block RAMs The VDU uses another 4 for the character RAM, 4 for the Attribute RAM and 2 for the Character Generator. = 14 block RAM ... rats ! I tried coding the character generator so that it used Slices rather than Block RAM, but then that over ran the slice allocation by 4% ie 104% of slices used. I tried pulling everything out but the PS2 keyboard, UART, VDU and CPU, but it just won't fit. The only thing I can do now is to reduce the Attribute RAM to 2K x 4bits and only allow a foreground colour attribute. I could perhaps use the 7th data bit of the character RAM as reverse video. I could re-write the VDU to share the SRAM and use the Block RAM as a line scan buffer. That way the CPU could write directly into video memory. The problem with that is that if you want to use the T80 with it you need to be able to insert idle bus cycles. I'm a bit conscious of monopolising this list. It might be worth taking this discussion off line unless others are interested. John. -- http://members.optushome.com.au/jekent |
|
|
|
I wouldn't worry about filling up the list - this is the only project going on at the moment. When I looked at the tables for the edge connectors on the starter board, I counted the uncommitted pins and it looked reasonable for a direct replacement of the B5 as far as my T80 is concerned - but it is certainly not equivalent. The B5 is far more general and a much larger device. I have no idea what I will do with the starter board but the Pascal P4 project would be more interesting as a 32 bit design. In fact, 32 bits might be nice because it gives a useful integer range, eliminates multi-byte operations and implies that every register can address the entire memory space. This weeks project is to get the second drive on the IDE channel up and running. It was supposed to work by magic - it doesn't. MicroBlaze is usually a commercial IP. I thought it strange that it was included in the starter kit but my first interest was in the VDU IP although yours is more applicable. Anyway, the code is available so I grabbed it. |
|
|
|
Hi Richard rtstofer wrote: >I wouldn't worry about filling up the list - this is the only >project going on at the moment. > >When I looked at the tables for the edge connectors on the starter >board, I counted the uncommitted pins and it looked reasonable for a >direct replacement of the B5 as far as my T80 is concerned - but it >is certainly not equivalent. The B5 is far more general and a much >larger device. > The starter board appears to be a 256 pin BGA where as the B5 is a 208 pin QFP so the starter kit in theory should have more pins. >I have no idea what I will do with the starter board but the Pascal >P4 project would be more interesting as a 32 bit design. In fact, >32 bits might be nice because it gives a useful integer range, >eliminates multi-byte operations and implies that every register can >address the entire memory space. > Is the Pascal P4 project a Pcode machine ? >This weeks project is to get the second drive on the IDE channel up >and running. It was supposed to work by magic - it doesn't. > >MicroBlaze is usually a commercial IP. I thought it strange that it >was included in the starter kit but my first interest was in the VDU >IP although yours is more applicable. Anyway, the code is available >so I grabbed it. I was up until 3:30 am last night working on the VDU with a stripped back System09. It is a very tight fit in the XC3S200. I've got the 80 x 25 display working of sorts although I can't get a cracker out of the CPU UART, so I'm not sure what is going on there. I'll have to take a closer look at the SRAM. The Buttons are actually active high rather than the usual active low. I pulled the attribute RAM out of the design, but then realised from the literature that the Spartan 3 Block RAM is actually 2K * 9 bits, rather than 512 * 8 bits so I'll have to re-instate it. Hopefully it will save a few slices on data bus multiplexers. I did not see the Microblaze code, but I guess it must be on the CD somewhere. John. -- http://members.optushome.com.au/jekent |
|
|
|
In looking through the MicroBlaze Master Kit file, I see a lot of C code for execution on the MicroBlaze but none of the design files. I think that bit is for sale in the Embedded Design Kit for a mere $495. I'll have to think about that - it's pretty expensive. Yes the P4 system is a P code machine. Many years ago I used the UCSD Pascal system which was Niklaus Wirth's Pascal on steroids. As I recall, I didn't think much of the file system in concept but it did function. What I did like about the system was the total integration of the compiler, assembler, editor and run time. I added a couple of graphic devices to the interpreter and had a fine time with a Tektronix 4013(?) Graphics Terminal and a CalComp drum plotter. Unfortunately, I discarded the source listings several years ago - stupid! Not to worry, I just got another copy of the original Wirth code for the compiler and interpreter. Not the UCSD system but a start - the same start they had at UCSD. Western Digital made a chip to run the UCSD system but it never went anywhere. Seems the university cancelled all the user licenses and sold the system to a company that still markets it in a small-time way. Too bad, at the time it was the best thing going. From a hardware point of view the original P4 system ran on a CDC 6400 with a 60 bit word. But what I see is an opportunity to design hardware specifically for a stack oriented machine with an unlimited number of levels of indirection for variable references. What a trip! I hope you post your new VDU - I am still looking in to doing that if I ever get the compact flash running on the IDE channel. I'm missing something; a hard disk plugged in to the cable works perfectly but the CF balks. I'm reasonably certain I have an issue with the command sequencing but it'll take time to work it out. That and a long read of the 125 page interface manual! |
|
|
|
Hi Richard ... Well I got System09 running on the starter board with 80 x 25 character display with colour and chunky graphics to boot :-) It uses 1842 slices out of 1920, so as I said before it's a tight fit. I just have to write some display driver software. I have a Monitor ROM for a memory mapped 64 x 16 display. It will just be a matter of modifying it a little to access memory through the registers rather than writing directly into memory. I'll put the code up on the web site when I get the monitor working properly. I'm currently just using the RS232 port to talk to the system. Unfortunately the only PS/2 keyboard I have is attached to this computer :-( rtstofer wrote: >In looking through the MicroBlaze Master Kit file, I see a lot of C >code for execution on the MicroBlaze but none of the design files. >I think that bit is for sale in the Embedded Design Kit for a mere >$495. I'll have to think about that - it's pretty expensive. > I thought that might have been the case. >Yes the P4 system is a P code machine. Many years ago I used the >UCSD Pascal system which was Niklaus Wirth's Pascal on steroids. As >I recall, I didn't think much of the file system in concept but it >did function. What I did like about the system was the total >integration of the compiler, assembler, editor and run time. I >added a couple of graphic devices to the interpreter and had a fine >time with a Tektronix 4013(?) Graphics Terminal and a CalComp drum >plotter. Unfortunately, I discarded the source listings several >years ago - stupid! Not to worry, I just got another copy of the >original Wirth code for the compiler and interpreter. Not the UCSD >system but a start - the same start they had at UCSD. > I had a small integer only pascal for the 6800. I disassembled it, and found it was largely Pcode. The Pcode interpreter was only 1 K or so, so should be quite ammenable to coding in VHDL. The software dates back to the early 80's or possibly before. I think there might have been a series of articles in Byte magazine around that time on Pascal Pcode compilers. I think it might have inspired a number of budding compiler writers to write their own version. >Western Digital made a chip to run the UCSD system but it never went >anywhere. Seems the university cancelled all the user licenses and >sold the system to a company that still markets it in a small-time >way. Too bad, at the time it was the best thing going. > I remember seeing that advertised but never had much to do with it. >>From a hardware point of view the original P4 system ran on a CDC >6400 with a 60 bit word. But what I see is an opportunity to design >hardware specifically for a stack oriented machine with an unlimited >number of levels of indirection for variable references. What a >trip! > The Signetics 2650 used to have indirect addressing in it instruction set. I think it used the MSB of the 16 bit address as an indirect bit, which meant it could only address 32K bytes of memory. >I hope you post your new VDU - I am still looking in to doing that >if I ever get the compact flash running on the IDE channel. I'm >missing something; a hard disk plugged in to the cable works >perfectly but the CF balks. I'm reasonably certain I have an issue >with the command sequencing but it'll take time to work it out. >That and a long read of the 125 page interface manual! I've written the VDU for the Spartan 3 and RAMB16_S9 which is not available on the Spartan 2 (I don't think). I will be a matter of back tracking and re-instating the RAMB4 version of the Character ROM and RAM buffers. I wrote some drivers for System68 to read and write single sectors. I had to modify the attribute registers for 8 bit operation. The code is on my web site .... http://members.optushome.com.au/jekent/system68/index.htm look half way down the page for "cf.zip" ... it might give you a few clues. Also be careful with the access time for flash. It needs a minimum access time of 100nSec. Also I found it needed some "breathing time" between accesses. If you try pushing it too hard it won't work. I write a very simple 16 bit micro with one or two clock cycles per instruction. I ran it at 10 MHz but for some reason it would not access the CF. The CF kept reverting to the reset mode. My System 68 which took a few more bus cycles to access it, worked fine. Tony Burch had a state sequencer for reading and writing CF, but I could never get it to work. I think Tony was only running it at 1MHz where as I was trying to run it much faster which might have been the problem. I had a Dickens of a time trying to get it going for some one on one of these lists, who was trying to use it for a university project. The idea of the Micro16 was to provide a bare bones CPU that would replace the state machine. John. -- http://members.optushome.com.au/jekent |
|
|
|
John, As implemented today, the T80 takes: Design Summary -------------- Number of errors: 0 Number of warnings: 4 Logic Utilization: Number of Slice Flip Flops: 596 out of 6,144 9% Number of 4 input LUTs: 2,417 out of 6,144 39% Logic Distribution: Number of occupied Slices: 1,455 out of 3,072 47% Number of Slices containing only related logic: 1,455 out of 1,455 100% Number of Slices containing unrelated logic: 0 out of 1,455 0% *See NOTES below for an explanation of the effects of unrelated logic Total Number 4 input LUTs: 2,609 out of 6,144 42% Number used as logic: 2,417 Number used as a route-thru: 128 Number used for Dual Port RAMs: 64 (Two LUTs used per Dual Port RAM) Number of bonded IOBs: 104 out of 142 73% IOB Flip Flops: 9 Number of Block RAMs: 4 out of 16 25% Number of GCLKs: 1 out of 4 25% Number of GCLKIOBs: 1 out of 4 25% Total equivalent gate count for design: 91,058 Additional JTAG gate count for IOBs: 5,040 Peak Memory Usage: 82 MB As I said earlier, there seems to be quite a bit of space left for the VDU. You are correct, Tony Burch used a 1 MHz clock with the CF. I had thought that since the cycle times were acceptable to an older IDE drive that the CF would surely work. You bring up an interesting point, maybe I should slow down the clock, increase the access times and see what happens. I am using 16 bit data transfers with the high order 8 bits always 0 - the drives are so large that giving up space was no problem compared to the issue of converting back and forth from a 16 bit register to an 8 bit bus. I can do it, of course, but for a first attempt, it didn't seem worth the complication. For whatever reason, the IDE drive returned an error when I tried to set the feature for 8 bit transfers. I just wanted CP/M to run - ugly would be acceptable. Richard |
|
|
|
Hi Richard, It's past 3:00 am and I need to get to bed. I've put up my work so far up on my web site. http://members.optushome.com.au/jekent/Spartan3/index.html It runs my KBug9 monitor and displays stuff on both the serial port and the VDU. It should handle inputs from either the serial port or the keyboard. I have not tested the keyboard although I have not changed it from the B5 board, so it should still work. The serial port runs at 57.6 Kbaud 8 data 1 stop bit. There is a problem with the way I scroll the screen up. because 80 x 25 = 2000 and not 2048 some funny things happen to the alignment of the columns ... (its hard to explain the effect without demonstating it) I have a Column address offset register but I think there are problems when the offset gets too large. I've implemented a colour attribute register as well as chunky graphics and flashing characters, but the Video driver does not have any escape sequences to set it. I have some bresenham line drawing routines for the 6800 and 6809 somewhere. I was using an old SubLogic 3D wire frame graphics routine for playing 3D games on my old 6809 system. Would be rather neat to hard code it in VHDL. I have not implemented the full ADM-3A command set. There are still a few control characters missing. I also need a terminal mode so that the monitor does not try to execute keyboard commands. rtstofer wrote: >As I said earlier, there seems to be quite a bit of space left for >the VDU. > >You are correct, Tony Burch used a 1 MHz clock with the CF. I had >thought that since the cycle times were acceptable to an older IDE >drive that the CF would surely work. You bring up an interesting >point, maybe I should slow down the clock, increase the access times >and see what happens. > Yep, give it a try ... >I am using 16 bit data transfers with the high order 8 bits always >0 - the drives are so large that giving up space was no problem >compared to the issue of converting back and forth from a 16 bit >register to an 8 bit bus. I can do it, of course, but for a first >attempt, it didn't seem worth the complication. For whatever >reason, the IDE drive returned an error when I tried to set the >feature for 8 bit transfers. I just wanted CP/M to run - ugly would >be acceptable. > The Compact Flash data sheet describes an attribute register, that you can program for 8 bit transfers. I'm not sure that IDE drives have that. John. -- http://members.optushome.com.au/jekent |
|
|
|
I downloaded your project and put it in the starter board. I see what you mean about the display - kind of strange. Nevertheless, a lot of things work very well. Stranger is the fact I can not get it to synthesize. I changed the unisym library statements slightly to eliminate the red '?' marks in the files list: library UNISIM; use UNISIM.VComponents.all; but it still doesn't synthesize. It runs through the process, writes a reasonable Synthesis Report, no errors, etc. but the step continues to have a '?'. Any attempt to create the programming file results in nothing happening. --- In , John Kent <jekent@o...> wrote: > Hi Richard, > > It's past 3:00 am and I need to get to bed. > I've put up my work so far up on my web site. > > http://members.optushome.com.au/jekent/Spartan3/index.html > > It runs my KBug9 monitor and displays stuff > on both the serial port and the VDU. > It should handle inputs from either the serial port > or the keyboard. I have not tested the keyboard although > I have not changed it from the B5 board, so it should still > work. The serial port runs at 57.6 Kbaud 8 data 1 stop bit. > > There is a problem with the way I scroll the screen up. > because 80 x 25 = 2000 and not 2048 some funny things > happen to the alignment of the columns ... > (its hard to explain the effect without demonstating it) > I have a Column address offset register but I think there > are problems when the offset gets too large. > > I've implemented a colour attribute register as well as > chunky graphics and flashing characters, but the Video > driver does not have any escape sequences to set it. > I have some bresenham line drawing routines for the 6800 > and 6809 somewhere. I was using an old SubLogic > 3D wire frame graphics routine for playing 3D games on > my old 6809 system. Would be rather neat to hard code > it in VHDL. > > I have not implemented the full ADM-3A command set. > There are still a few control characters missing. > > I also need a terminal mode so that the monitor does not > try to execute keyboard commands. > > rtstofer wrote: > > >As I said earlier, there seems to be quite a bit of space left for > >the VDU. > > > >You are correct, Tony Burch used a 1 MHz clock with the CF. I had > >thought that since the cycle times were acceptable to an older IDE > >drive that the CF would surely work. You bring up an interesting > >point, maybe I should slow down the clock, increase the access times > >and see what happens. > > > > > > > Yep, give it a try ... > > >I am using 16 bit data transfers with the high order 8 bits always > >0 - the drives are so large that giving up space was no problem > >compared to the issue of converting back and forth from a 16 bit > >register to an 8 bit bus. I can do it, of course, but for a first > >attempt, it didn't seem worth the complication. For whatever > >reason, the IDE drive returned an error when I tried to set the > >feature for 8 bit transfers. I just wanted CP/M to run - ugly would > >be acceptable. > > > > > > > The Compact Flash data sheet describes an attribute register, > that you can program for 8 bit transfers. I'm not sure that IDE drives > have that. > > John. > > -- > http://members.optushome.com.au/jekent |
|
|
|
I take it you downloaded the .mcs file to the board. I'm using Web pack ISE 6.2.03i. The project file probably won't work for anything else .... I think the UNISIM library is only for simulating the Xilinx library components. The red question marks for RAMB16_S9 don't seem to matter Web pack appears to resolve that when you synthesize the code. oh ..... you have to be careful of the auto make in Web pack. Note that I'm probably about 10 hours ahead of you ... If it preseves the time date stamp on the zip files, it might mess up the auto make feature in Web Pack. I remember someone else complaining about the make feature doing some strange things because they were a few hours behind me. The Binary files were older that the source files so Web pack thought the binaries were out of date :-) Try loading and saving all the files again so that they have your date-time on them. I included some of the old files using the RAMB4 modules for the Spartan 2. I might have changed a few of the architecture signals, so I need to clean them up abit eg. make ram2k.vhd into ram2k_b4.vhd and so on. The funny scroll affect may have something to do with the way I did the maths for the Vertical offset register ... I multiply the row address by 5 then shift it up 4 bits (mult by 80) then add it to the horizontal column address to calculate the address in memory. In the software driver I simply increment the vertical offset register. My brain is not working at the moment, but there might be something wrong with doing that. Once I get the bugs out of the display with system09 I'll try porting it back to the Spartan 2 board, so you can integrate it with your T80. rtstofer wrote: >I downloaded your project and put it in the starter board. I see >what you mean about the display - kind of strange. Nevertheless, a >lot of things work very well. > >Stranger is the fact I can not get it to synthesize. I changed the >unisym library statements slightly to eliminate the red '?' marks in >the files list: > >library UNISIM; >use UNISIM.VComponents.all; > >but it still doesn't synthesize. It runs through the process, >writes a reasonable Synthesis Report, no errors, etc. but the step >continues to have a '?'. Any attempt to create the programming file >results in nothing happening. > -- http://members.optushome.com.au/jekent |
|
|
|
Well, i fried my brain earlier on Margaritas but now that I am up to semicomatose I see what you mean. It syntesizes just fine now that the time/date stamps are past. Time zones, another in a long list of lessons learned... I'm using the same Web Pack so no issues there but I had downloaded the .mcs file for the test. I never knew whether the little red boxes meant anything, I just worked in a direction to make them go away! If there was more memory, I wonder if a look-up table would be a faster way to get the memory address for the start of each row. And maybe a way to barrel-shift the lookup table as the screen scrolls. Or just a pointer to the point to the table entry that contains the address of the first line. Then just add modulo 25 like a circular buffer. But, I fear this design is getting a little tight! Giving up 100k gates is a difficult thing. I also wish they had positioned the power inlet centered between the serial and VGA connectors - mine collides badly with the VGA plug. On the 25 line thing: I don't know for sure about the ADM3A but I think it has 24 lines. The Televideo 950 had a 25th line for status information but it didn't scroll along with the others. This was useful for function key prompts. Of course, it also has 4 pages of screen memory and a full blown microprocessor to process the command sequences which are quite extensive. I am really looking forward to seeing this work on the Spartan II although I must admit it is pretty clean on the Spartan III. I should be able to port it in with very little difficulty. Of course, the CF was supposed to be a drop-in thing as well... |
|
|
|
I'm taking a bit of a break. After a few 3:00 am nights I think I owe it to myself. I remember using a BeeHive terminal back in the early 80s. That also had 24 lines with an optional 25th status line that you could enable or disable. I think it was used to report things like the baud rate, auxillary port status and so on. I think it might have had a number of screen pages too. I'm not sure if 24 lines makes the circular buffer wrap around any easier. I don't think you need a barrel shifter to offset the character rows, just an offset on the row counter. Thats what I have done but when the offset register gets to large or wraps around to zero, the offset calculation goes wrong and you get some modulo counter offset. I've just got to look a little closer at how I've done offset. Also, I need a better character generator. Characters are 8 pixels x 8pixels and I have two scan lines per character row which does not leave much space between characters on different rows. It would be nice to have an 8 x 12 pixel character generator, but then the ROM would double in size, which may be a problem for the Spartan 2 board. John. rtstofer wrote: >If there was more memory, I wonder if a look-up table would be a >faster way to get the memory address for the start of each row. And >maybe a way to barrel-shift the lookup table as the screen scrolls. >Or just a pointer to the point to the table entry that contains the >address of the first line. Then just add modulo 25 like a circular >buffer. But, I fear this design is getting a little tight! Giving >up 100k gates is a difficult thing. I also wish they had positioned >the power inlet centered between the serial and VGA connectors - >mine collides badly with the VGA plug. > >On the 25 line thing: I don't know for sure about the ADM3A but I >think it has 24 lines. The Televideo 950 had a 25th line for status >information but it didn't scroll along with the others. This was >useful for function key prompts. Of course, it also has 4 pages of >screen memory and a full blown microprocessor to process the command >sequences which are quite extensive. > >I am really looking forward to seeing this work on the Spartan II >although I must admit it is pretty clean on the Spartan III. I >should be able to port it in with very little difficulty. > >Of course, the CF was supposed to be a drop-in thing as well... -- http://members.optushome.com.au/jekent |
|
|
|
By default, the Televideo 950 also uses the 25th line for status but it can be overwritten with ESC f <message up the 80 chars> <CR>. I don't see this as important although I did use it with one of the screen oriented editors. I'm getting a little burned out at the moment as well. I just finished populating a PCB with dual 5 in, 3 out RS232 drivers for the 2 COM ports and those little SSOP pkgs are a chore to solder. In retrospect, I should have included the VGA R/2R, connector and PS/2 Port at the same time. I'm also tryng to come up with a nice way to package the system. I think it is going to look like a cube of PCBs attached to Plexiglass sheets about 6" square with standoff posts between the sheets. I have been looking at the idea of just folding things together. I have also toyed with the idea of stuffing the whole thing in a PC Tower case. Just yank the motherboard, mount all the PCBs and call it good. --- In , John Kent <jekent@o...> wrote: > I'm taking a bit of a break. After a few 3:00 am nights I think I owe it > to myself. > > I remember using a BeeHive terminal back in the early 80s. That also had > 24 lines > with an optional 25th status line that you could enable or disable. I > think it was used > to report things like the baud rate, auxillary port status and so on. I > think it might have > had a number of screen pages too. > > I'm not sure if 24 lines makes the circular buffer wrap around any easier. > I don't think you need a barrel shifter to offset the character rows, > just an offset on the row counter. Thats what I have done but when > the offset register gets to large or wraps around to zero, the offset > calculation > goes wrong and you get some modulo counter offset. I've just got to look > a little closer at how I've done offset. > > Also, I need a better character generator. Characters are 8 pixels x 8pixels > and I have two scan lines per character row which does not leave much space > between characters on different rows. It would be nice to have an 8 x 12 > pixel > character generator, but then the ROM would double in size, which may be > a problem for the Spartan 2 board. > > John. |
|
|
|
Hi Richard .... I think I've got the bugs out of the VDU ... It's up on my web page. http://members.optushome.com.au/jekent/Spartan3/index.html Don't forget to refresh your browser. The Character generator ROM still needs a bit of work. John. -- http://members.optushome.com.au/jekent |
|
|
|
I grabbed it this morning - I'll be playing with it over the weekend. The shower always worked for me as well. Maybe someone should study that - give up cubes and install showers. Lighten up the office. Well, except I'm retired - no office. --- In , John Kent <jekent@o...> wrote: > Hi Richard .... > > I think I've got the bugs out of the VDU ... > > It's up on my web page. > > http://members.optushome.com.au/jekent/Spartan3/index.html > > Don't forget to refresh your browser. > > The Character generator ROM still needs a bit of work. > > John. > > -- > http://members.optushome.com.au/jekent |
|
|
|
I should have been in my cubical but I was up until the early hours of the morning fixing my HP5L laser printer trying to work out how to install a new pick up roller. I work fairly flexible hours (part time). Bad arthritis has left me with bionic joints and a rather lazy work ethic. I've been looking around for a 7 x 9 or 7 x 13 character generator that looks a bit better than what I have at the moment but I could not find much on the web. I think the one I'm using is pinched from a Comodore 64, but I must have been out by a row when I spliced it together because I had to fiddle it a bit to get number and characters to line up on the bottom line. John. rtstofer wrote: >I grabbed it this morning - I'll be playing with it over the >weekend. The shower always worked for me as well. Maybe someone >should study that - give up cubes and install showers. Lighten up >the office. Well, except I'm retired - no office. -- http://members.optushome.com.au/jekent |
|
|
|
Sydney is about 151 degrees East and San Francisco is about 122 degrees West so we're about 273 degrees apart - figure 3/4 of a day or 18 hours ignoring local offsets for daylight savings time. Too much time studying celestial navigation... I still have a couple of issues: First, my generic 82 key keyboard doesn't work at all with the PS/2 port although it works on my Dell computer. Don't know what that's about. My Dell 101 key keyboard works at +5V but I get double strokes (press/release) which is what the keyboard sends. I also think I still see times when the counter problem reappears. If I enter an invalid (WHAT?) command and then press Enter repeatedly, as the screen scrolls it displays that odd line position as before but higher on the screen. I usually see it in the upper 4 lines, give or take. I was going to rebuild the project but, as you are up anyway, I thought I would send this along. --- In , John Kent <jekent@o...> wrote: > I should have been in my cubical but I was up until the early hours of > the morning fixing my HP5L laser printer trying to work out how to > install a new pick up roller. I work fairly flexible hours (part time). > Bad arthritis has left me with bionic joints and a rather lazy work ethic. > > I've been looking around for a 7 x 9 or 7 x 13 character generator that > looks a > bit better than what I have at the moment but I could not find much on > the web. > I think the one I'm using is pinched from a Comodore 64, but I must have > been > out by a row when I spliced it together because I had to fiddle it a bit > to get > number and characters to line up on the bottom line. > > John. > > rtstofer wrote: > > >I grabbed it this morning - I'll be playing with it over the > >weekend. The shower always worked for me as well. Maybe someone > >should study that - give up cubes and install showers. Lighten up > >the office. Well, except I'm retired - no office. > > > > > -- > http://members.optushome.com.au/jekent |
|
|
|
I can't reproduce your problem with the display ... but I borrowed a PS/2 keyboard and as you say ... it has problems. I've updated the monitor ROM to filter out key releases and undefined keys are mapped at $FF rather then $2e ("."). I notice the keyboard handles Shifts but not Control. I'll try post my updates soon. John. rtstofer wrote: >Sydney is about 151 degrees East and San Francisco is about 122 >degrees West so we're about 273 degrees apart - figure 3/4 of a day >or 18 hours ignoring local offsets for daylight savings time. Too >much time studying celestial navigation... > >I still have a couple of issues: First, my generic 82 key keyboard >doesn't work at all with the PS/2 port although it works on my Dell >computer. Don't know what that's about. My Dell 101 key keyboard >works at +5V but I get double strokes (press/release) which is what >the keyboard sends. > >I also think I still see times when the counter problem reappears. >If I enter an invalid (WHAT?) command and then press Enter >repeatedly, as the screen scrolls it displays that odd line position >as before but higher on the screen. I usually see it in the upper 4 >lines, give or take. > >I was going to rebuild the project but, as you are up anyway, I >thought I would send this along. > -- http://members.optushome.com.au/jekent |