Atari 2600 FPGA project

[Leewrigley]

Hi guys,

 

dont know if this is necessarily the right place to post this if not let me know or move for me

 

Basically im working on my final year project for university and i am doing the project on creating an atari 2600 clone on a FPGA using verilog programming. I have everything written im just having a waaaayy harder time debugging it than i antisipated ( i really should have expected this tbh). Im really looking for anyone with really good 2600 knowledge and/or verilog programming skills that can help me try get it (at least a little bit) up and running. as long as i havee something to show for my efforts than some red lines and a horrendous beep noise i will be happy.

 

Heres the real kicker.... its due tomorrow night   i was getting help from someone on fiverr but he has just ended up not replying anymore (must have been too difficult for him ). i know i maybe wouldnt have too but id happily pay for somebody to take the time to help me out if they can.

 

If anyone knows a better place to ask also then let me know, thanks so much

[+Andrew Davie]

If you have not seen the "Andrew Towers" notes on the '2600 hardware, have a look there. It gives a fairly accurate and comprehensive review of how it all should work. Also reach out to the emulator programmers -- and experts. @Thomas Jentzsch will know the answer to much hardware stuff, as will @alex_79 and @JetSetIlly who have all been heavily involved in close-to-the-metal stuff. There are many others, but those are the first three who came to mind.

 

[Kitrinx]

Can you be more specific? Do you need to know how to use debugging tools like signaltap, or do you have issues with your implementation that you need help with solving? If you need references the mister fpga repo has a functional 2600 core in VHDL, and I have a lot of verilog and atari experience if you need help with something specific.

[Leewrigley]

@Kitrinx@Andrew Davie thanks both of you for getting back to me, i have the verilog code written to the best of my ability and i am just running a basic testbench to analyse how things are working. needless to say not everything is working well, could be a simple fix that causes the whole thing to break, if i was to be more specific about the current state of things, on initial start up the CPU and the ROM talk to each other briefly but then after a very short period all the addresses that the CPU sends to the ROM returns all zeros and then it just loops.

 

If you have experience is there any chance you could have a look over it with me, maybe iv got a few polarities reversed (althoguh i thought i fixed them all) or something like that. Its fine if not im just down to the wire now.

 

also i am not familiar with signaltrap, tbh im very new to verilog and everything really this project has been a large majority of my experience.

 

thanks

[+Andrew Davie]

So you're recreating the 6507 as well. I guess my first step would be to confirm that's working properly. How far advanced are you on that aspect?  Are you able to step through 6507 "code" and watch registers and flags change as expected?

 

[Kitrinx]

Signaltap is altera's debugging tool for FPGA softcore. Xilinx has their own tool, the name escapes me at the moment. It looks like this:

 

You're in a tight spot with your project due tomorrow, particularly with a system as picky as 2600. The HMOVE stuff in particular is extremely demanding of being cycle accurate, and I would not expect you to go from non-booting to a reasonable functional system in a day. What I would suggest you do is the following:

Get some working code from somewhere to start with, such as the working t65 from the mister project, or the working TIA and RIOTs from the same project. Hook these known-to-work chips up in parallel with your own implementations, and then compare the outputs in your debugging tool, looking for where your own code deviates from the known working copies. You can mix and match the working code and your own code to try to coax your project into functionality and then replace it with your own code as you get it in working shape.

 

HDL programming, debugging, and the atari2600 are significant studies on their own and there's not really an quick and dirty guide to go from zero to hero with any of those things, much less all of them at once.
 

[Leewrigley]

sorry i should have mentioned the CPU is imported to that SHOULD work fine, i wrote the TIA and 6532 and most of everything else

 

[Leewrigley]

@Kitrinx thanks for the advice i suppose i shall give that a go, i do get what you mean. TBH i dont think im particularly worried about everything working fine, il settle for displaying an image i think! that should be good enough as a proof of concept for the project, i try have a look into the mister cores for some testing then

[+Andrew Davie]

If the 6507 core is written and should be working fine, then how on earth can you get all zeroes on the address lines when talking to the ROM?

These are nothing to do with the TIA or 6532.  The 6507 core/ROM should be independent in terms of working correctly -- so there's the first place to handle things. Firstly, make sure your'e testing with a non-bankswitching ROM (i.e., a 4K ROM would be suitable).  What game/binary are you using to test?  If you can step through your implementation with a debugger, you could test with an emulator stepping through the same code to test.... and compare side by side, instruction by instruction.

 

[Leewrigley]

so far i have tested pitfall, defender and combat (hex mirrored to fit the 4k area), pitfall originally was "working" a bit better than others as it was the only one that was getting data written intot the tia registers including vblank, whereas others wernt getting anything like that

 

Edited April 21, 2021 by Leewrigley

[Leewrigley]

its actually a 6502 core btw, here is the wrapper i wrote to convert it, maybe i mucked this up but seemed simple..

 

module MOS6507 ( A, Din, Dout, RE, CLK_s, RDY_s, RES_s);

 

output [12:0] A;   //Smaller address bus
input [7:0] Din;   //Data bus input
output [7:0] Dout; //Data bus output
output RE;      //Read write output (s to distinguish the shell)
input CLK_s;       //Shell Clock
input RDY_s;       //Ready line  
input RES_s;       //Reset line

 

wire [15:0] cpuAB;
wire R_W_s;

 

cpu6502 cpu (.clk(CLK_s), .reset(RES_s), .addr(cpuAB), .data_in(Din), .data_out(Dout), .we(R_W_s), .irq(1'b1), .nmi(1'b1), .rdy(RDY_s));
 
assign A = cpuAB [12:0];  //Convert 16 lane address bus into 13 lanes
assign RE = ~R_W_s;

 

endmodule

Edited April 21, 2021 by Leewrigley

[Leewrigley]

if anyone happens to be bored and wants to have a look at my horrible programming skills then here is my latest zip

project_2.rar

[+Andrew Davie]

First thing to look at is the reset process, I guess.

You want to (in all the carts) see the contents of the reset vector (from the binary) transferred to the PC address of the 6507.

Can you confirm that's all OK?/

 

[+wongojack]

 

I can't help, but here's another reference for you:

 

The CollectorVision Phoenix has an Atari 2600 FPGA implementation available on their github account:

https://github.com/CollectorVision/Phoenix2600

[Kitrinx]

22 minutes ago, Leewrigley said:

its actually a 6502 core btw, here is the wrapper i wrote to convert it, maybe i mucked this up but seemed simple..

 

module MOS6507 ( A, Din, Dout, RE, CLK_s, RDY_s, RES_s);

output [12:0] A;   //Smaller address bus
input [7:0] Din;   //Data bus input
output [7:0] Dout; //Data bus output
output RE;      //Read write output (s to distinguish the shell)
input CLK_s;       //Shell Clock
input RDY_s;       //Ready line  
input RES_s;       //Reset line

wire [15:0] cpuAB;
wire R_W_s;

cpu6502 cpu (.clk(CLK_s), .reset(RES_s), .addr(cpuAB), .data_in(Din), .data_out(Dout), .we(R_W_s), .irq(1'b1), .nmi(1'b1), .rdy(RDY_s));
 
assign A = cpuAB [12:0];  //Convert 16 lane address bus into 13 lanes
assign RE = ~R_W_s;

endmodule

 

Make sure that IRQ and NMI are actually active low. Normally they would be labeled NMI_n and IRQ_n if they are. Under normal circumstances this is the case but i've seen 6502 implementations where they are not.

[Leewrigley]

@Kitrinx  wow, i had changed these before but to no avail, but alas i have done it now and its a lot better, not perfect, but better...

 

edit: it probbaly worked this time because i had fixed some other problem in the mean time

 

iv attatched a ss of the simulation, at one point the data from the ROM does become 0 and stay that way, is that mayb efter everthing is written and the game is waiting for the reset button?

 

Edited April 21, 2021 by Leewrigley

[Kitrinx]

Just now, Leewrigley said:

@Kitrinx  wow, i had changed these before but to no avail, but alas i have done it now and its a lot better, not perfect, but better...

 

iv attatched a ss of the simulation, at one point the data from the ROM does become 0 and stay that way, is that mayb efter everthing is written and the game is waiting for the reset button?

 

I assume you're just baking a ROM in as a block of ROM right now, if this is the case I would hold the system in reset for a little bit to make sure everything initializes correctly. It's hard to see what's going on there without being able to see the values of the address bus, how far is it getting past the boot vector, and are you correctly mirroring the address bus for the rom size? ie, if the boot vector is 16'hFFFC you have to make sure if the rom is 2kb that FFFC is referring to the rom's end, and not blank space in your ROM/RAM implementation. usually you'd do this like AB[10:0] and it will mirror it naturally, but if it's a 2kb rom and you're giving it the full address it will just find empty space at the end.

[Leewrigley]

right now pitfall is the game i am running, i should probably move over to a simple game like combat so would copy and pasting the hex twice in a row make that work properly or no?

 

il attatch a few images, one is how im loading the game, how long do you think i should give for reset?

 

the other image is the moment that it craps out, for some reason the cpu spits out an adress of xxx's and then shortly after does it a second time, this second time is when all data stops flowing

 

also just want to say thank you to everyone for their help so far

 

edit: i now notice my naming is horrible, A is the address bus, D above is data intot the 'ROM' Din below is just data going into cpu

 

Edited April 21, 2021 by Leewrigley

[Leewrigley]

18 minutes ago, Kitrinx said:

usually you'd do this like AB[10:0] and it will mirror it naturally

wait, really, would that work? if so i will do that and try to run combat as surely that is easier than pitfall haha

[Kitrinx]

2 minutes ago, Leewrigley said:

wait, really, would that work? if so i will do that and try to run combat as surely that is easier than pitfall haha

That's how it works on real hardware. It just doesn't hook up the higher address lines to the rom chip.

 

This CPU implementation is kind of suspect. I know your simulation is probably verilog only, but I'd really suggest switching to t65 if you are able to handle VHDL in your sim as well.

 

Is there a reason you are looking at your address bus in binary instead of hex?

 

 

 

[Leewrigley]

okay im going to try combat then and shorten the address bus, no reason its just how iv looked at it from the start, il convert it from now especially for screenshots so you can more easily tell what is being excecuted.

 

i have no experience with VHDL, but if it will work exactly the same dropped in i can replace the CPU core no problem, would my call from before work the same? how do you call a VHDL file within a verilog one?

 

[Kitrinx]

3 minutes ago, Leewrigley said:

okay im going to try combat then and shorten the address bus, no reason its just how iv looked at it from the start, il convert it from now especially for screenshots so you can more easily tell what is being excecuted.

 

i have no experience with VHDL, but if it will work exactly the same dropped in i can replace the CPU core no problem, would my call from before work the same? how do you call a VHDL file within a verilog one?

 

 

Here is an example of an instantiation of a VHDL module in verilog (it's just as you'd expect):
https://github.com/Kitrinx/Atari7800_MiSTer/blob/master/rtl/top.sv#L467

[Leewrigley]

Is that the exact CPU you were telling me to use also? so i could take the CPU from that project and use the same line just change the names on the wrapper side?

 

btw you are a massive help thank you

[Kitrinx]

2 minutes ago, Leewrigley said:

Is that the exact CPU you were telling me to use also? so i could take the CPU from that project and use the same line just change the names on the wrapper side?

 

btw you are a massive help thank you

 

Yes and yes. I can vouch for that CPU being accurate. Be mindful of how the phases of 6502 work.
Phi0 = cpu oscillator input and is roughly equivalent to phi2
Phi1 = when the cpu changes it's address and data bus
Phi2 = signal the cpu outputs indicating it's time for peripherals like roms, chips, etc, to use what's on the address and data bus.

T65's input is *phi1* not phi0 like a real chip, so just be mindful of that. Unlike a real 6502, the bus values will update immediately when phi1 ticks, so as long as phi2 is just after phi1, you're okay.

 

This is a 7800 implementation, but since 7800 is just a 2600 with an extra couple of chips, feel free to use it as a reference, as it's mostly in systemverilog.

[Leewrigley]

How do set up this clock then sorry, i just use basic clock dividers for everything. right now my cpu clock which is used for riot and tia also and the 3.58Mhz tia clock can be seen in the ss attatched, which clocks do i need to change? just to one going into cpu or 1Mhz clock going into all 3? CLK2 is cpu and CLK is tia (obviously)