|
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 |
|
|
Simple Character CRT Core Needed
Started by ●August 30, 2004
Reply by ●September 4, 20042004-09-04
Reply by ●September 5, 20042004-09-05
|
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! |
|
|
Reply by ●September 5, 20042004-09-05
|
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 |
|
|
Reply by ●September 5, 20042004-09-05
|
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 |
|
|
Reply by ●September 5, 20042004-09-05
|
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 |
|
|
Reply by ●September 5, 20042004-09-05
|
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 |
|
|
Reply by ●September 6, 20042004-09-06
|
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 |
|
|
Reply by ●September 6, 20042004-09-06
|
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... |
|
|
Reply by ●September 6, 20042004-09-06
|
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 |
|
|
Reply by ●September 6, 20042004-09-06
|
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. > |
|
|
