6502.org http://forum.6502.org/ |
|
Pet2001 in FPGA http://forum.6502.org/viewtopic.php?f=10&t=4330 |
Page 1 of 1 |
Author: | Gehstock [ Mon Dec 05, 2016 3:08 pm ] |
Post subject: | Pet2001 in FPGA |
Hi i try to rebuild the Pet 2001 in FPGA using this Project http://www.skibo.net/projects/pet2001fpga/ but have to change some Things(using other FPGA) but i never show a Screen like this Have someone an Idea what can be fault (Rom/Ram?). And why is my Screen so dark (in White Mode also, nothing is changed on orginal Sourcecode exept the Green Screen Mode)I am a Newbe in FPGA programming. Edit: A simple tryout brings a Picture but still to dark and still no Keyboard ( Char Before the cursor?) and the Ram (normal 7167 Bytes Free) |
Author: | jac_goudsmit [ Tue Dec 06, 2016 1:01 am ] |
Post subject: | Re: Pet2001 in FPGA |
I had a look at that project a week ago or so; in my case I looked into the version for the Arty FPGA board. I couldn't get the latest code from the Github repo to work but that's because he didn't update all the files. I'll probably fix it in my fork and then send a pull request. When I have time. Anyway, that's not your problem I'm sure, because you're working with an Altera board. If your video is too dark, you probably did something wrong with the video bits. There are two bits (one for video, one for sync. Maybe the version for your board generates 3 bits: 1 for video, 1 for HSYNC and 1 for VSYNC; that's what you want for VGA anyway, right?). You should write your top level module such that the VGA D/A converters get the highest level of green (the D/A converters are probably 8 bits per color so green should probably be set to 8'xFF, but I'm not familiar with your board so Your Mileage May Vary) when the video bit is high, and zero when the video bit is low. Maybe you just connected the video bit to the top bit of the D/A converter instead of all the bits? That would only turn the video signal on to half brightness instead of maximum brightness. As for the keyboard: It looks like you're using a USB keyboard with a PS/2 adapter? If so, are you sure your keyboard supports this? Many keyboards that were recently manufactured (in the last 10 years or so), don't support the PS/2 protocol anymore. Try connecting the keyboard with the PS/2 adapter to the PS/2 keyboard input of a PC (before you turn it on) and turn it on to see if it works. If not, use a different keyboard (or do some FPGA magic ). Also it looks like you're using a (green) Mouse converter plug, not a (purple) keyboard converter plug. I can't explain why it's not showing all the memory and why you're getting the weird character as cursor instead of space/inverse space. Maybe you're trying to run it too fast and some signals don't make it to their destinations in time? Try lowering the top level clock frequency by inserting a PLL or a clock divider. The clock only has to be 1MHz to make it work like a real PET. Anything faster is a bonus. And of course, see if you can reach Thomas Skibo; he may not be able to help you with Altera-specific issues (it appears he works with Xilinx FPGA's only) but he has more knowledge about the project than anyone ===Jac |
Author: | Gehstock [ Tue Dec 06, 2016 6:54 am ] |
Post subject: | Re: Pet2001 in FPGA |
USB/Ps2 Combo will work with other Cores this is not a Problem. Have contacted Autor but no Answer, need help with the Rom Memory Must seperate the CharRom, Screen shows only Garbage with 2-Port-Ram Original Code Code: module pet2001roms( output [7:0] data, // cpu interface input [13:0] addr, output [7:0] chardata, // video interface input [10:0] charaddr, input clk ); // Arrange as 8 16x1 two-port RAMs genvar x; generate for (x=0; x<8; x=x+1) begin:bits RAMB16_S1_S1 rom(.DIA(1'b0), .DOA(data[x]), .ADDRA(addr), .WEA(1'b0), .ENA(1'b1), .SSRA(1'b0), .CLKA(~clk), // see description .DIB(1'b0), .DOB(chardata[x]), .ADDRB({3'b101,charaddr}), .WEB(1'b0), .ENB(1'b1), .SSRB(1'b0), .CLKB(~clk) // see description ); end endgenerate endmodule // pet2001roms have try this Code: pet2001roms1 rom( .address_a(addr[13:0]), .address_b(charaddr), .q_a(rom_data), .q_b(chardata), .enable_a(1'b1), .enable_b(1'b1), .clock_a(~clk), .clock_b(~clk) ); think problem is in Megafunctions must have address_a and address_b the same Size My "working Solution" Code: pet2001romfull rom(
.q_a(rom_data), .address_a(addr[13:0]), .address_b(), .q_b(), .enable_a(1'b1), .enable_b(), .clock_a(~clk), .clock_b()); //Need to seperate it no Chars without Charrom rom2( .address(charaddr), .q(chardata), .clock(~clk) ); |
Author: | jac_goudsmit [ Tue Dec 06, 2016 6:15 pm ] |
Post subject: | Re: Pet2001 in FPGA |
My Verilog "fu" is not good enough yet to evaluate that, sorry... But have you tried emulating the ROM without the megafunctions? The construct that's used in the (SystemVerilog) HDL for the Virtual Propeller that I maintain (sort of) is similar to the following. It just sets up a big array of regs and uses the address to index the array. The Altera or Xilinx software figures out how to implement this as on-board RAM or some other way. It's not my code but this is portable between Xilinx and Altera and much more readable. See here for how ROM is implemented in the P1V project. You would have something like: Code: /* NOTE: I'm writing this from my head, this was not compiled or tested in any way */ module pet2001roms( output [7:0] data, // cpu interface input [13:0] addr, output [7:0] chardata, // video interface input [10:0] charaddr, input clk ); /* System ROM (BASIC, Editor, Kernal) */ reg [7:0] sys_rom_low [16383:0]; initial begin $readmemh("sys_rom.hex", sys_rom); end always @(posedge clk) begin data <= sys_rom[addr]; end /* Character ROM */ initial begin $readmemh("char_rom.hex", char_rom); end always @(posedge clk) begin chardata <= char_rom[charaddr]; end endmodule ===Jac |
Author: | tsky [ Sun Dec 11, 2016 9:52 pm ] |
Post subject: | Re: Pet2001 in FPGA |
Gehstock wrote: USB/ Have contacted Autor but no Answer, need help with the Rom Memory Sorry I haven't been responsive. It turns out the e-mail addresses on ALL my websites have not been forwarding properly. They just go into a black hole. I'm trying to get that fixed. Grrrr. jac_goudsmit wrote: I had a look at that project a week ago or so; in my case I looked into the version for the Arty FPGA board. I couldn't get the latest code from the Github repo to work but that's because he didn't update all the files. I'll probably fix it in my fork and then send a pull request. I updated the Pet2001_Arty repository to include the .v and .mem files that are missing. I run Vivado on Linux and use Makefiles to generate those files automatically. I added these files to the repository for those not running Linux. --Thomas |
Author: | jac_goudsmit [ Sun Dec 11, 2016 11:14 pm ] |
Post subject: | Re: Pet2001 in FPGA |
tsky wrote: jac_goudsmit wrote: I had a look at that project a week ago or so; in my case I looked into the version for the Arty FPGA board. I couldn't get the latest code from the Github repo to work but that's because he didn't update all the files. I'll probably fix it in my fork and then send a pull request. I updated the Pet2001_Arty repository to include the .v and .mem files that are missing. I run Vivado on Linux and use Makefiles to generate those files automatically. I added these files to the repository for those not running Linux. Hi Thomas, Thanks for the update! I'll check it out later this week. If you don't mind me asking (and this may be a stupid question because I'm a noob with Vivado)... Why did you organize the project that way? As far as I can tell (but I just had a cursory look), the Makefile and Tcl scripts just copy everything to a different directory and then create a project file from scratch. I don't understand why that's necessary. In my P1V repository (which was an Altera project at first, but can now also be built with Vivado), I simply created a Vivado project P1V_arty.xpr, and added the source files, making sure that the "copy source files to project directory" option (or whatever it's called) was unchecked, so it keeps referencing the source files where they are. Then I added the project file to Github and updated my .gitignore to ignore the directories that Vivado creates automatically. Just wondering if that's the wrong way to go about it. ===Jac |
Author: | tsky [ Mon Dec 12, 2016 6:50 pm ] |
Post subject: | Re: Pet2001 in FPGA |
jac_goudsmit wrote: If you don't mind me asking (and this may be a stupid question because I'm a noob with Vivado)... Why did you organize the project that way? As far as I can tell (but I just had a cursory look), the Makefile and Tcl scripts just copy everything to a different directory and then create a project file from scratch. I don't understand why that's necessary. In my P1V repository (which was an Altera project at first, but can now also be built with Vivado), I simply created a Vivado project P1V_arty.xpr, and added the source files, making sure that the "copy source files to project directory" option (or whatever it's called) was unchecked, so it keeps referencing the source files where they are. Then I added the project file to Github and updated my .gitignore to ignore the directories that Vivado creates automatically. Just wondering if that's the wrong way to go about it. ===Jac It's a quirk of Vivado that if you use a "project.tcl" file (generated by Vivado), when it recreates the project, it creates the project and its subdirectories off to the side like that. I honestly can't remember why I went with a project.tcl file instead of just adding the project.xpr file to the repository. It might be because the .xpr file is specific to the version of Vivado you are running whereas the project.tcl file might work across different versions. |
Author: | Gehstock [ Sun Jan 15, 2017 11:38 pm ] |
Post subject: | Re: Pet2001 in FPGA |
Problem solved thanks for all Help |
Page 1 of 1 | All times are UTC |
Powered by phpBB® Forum Software © phpBB Group http://www.phpbb.com/ |