|
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 |
|
|
Simple Character CRT Core Needed
Started by ●August 30, 2004
Reply by ●September 1, 20042004-09-01
Reply by ●September 1, 20042004-09-01
|
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 |
|
|
Reply by ●September 1, 20042004-09-01
|
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. |
|
|
Reply by ●September 2, 20042004-09-02
|
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 |
|
|
Reply by ●September 2, 20042004-09-02
|
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. |
|
|
Reply by ●September 2, 20042004-09-02
|
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 |
|
|
Reply by ●September 3, 20042004-09-03
|
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 |
|
|
Reply by ●September 3, 20042004-09-03
|
> 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 |
|
|
Reply by ●September 4, 20042004-09-04
|
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 |
|
|
Reply by ●September 4, 20042004-09-04
|
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. |
|
|
