Jump to content
IGNORED

Atari 2600 FPGA project


Leewrigley

Recommended Posts

Just now, Leewrigley said:

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)

 

1933636794_Outofphaseclock.thumb.PNG.250ab2fa3148f70557ee8ca92323939b.PNG

In my designs I prefer to use clock enables, as you see in my code. You will have to use a clock divider, a separate PLL, or generate a clock enable like I do. In the situation of a 2600, the TIA should be producing the phi0 signal with a clock divider.

Link to comment
Share on other sites

So, within my TIA module, have a straight divide by 3 clock output which goes into the CPU, do i need to change the phase at all?

 

i saw from the schematics that it worked this way but i just though i could generate clocks in the top level module and use them where needed.

 

btw my clocks arnt 100% accurate but should do for the sake of this project, i divide the 100Mhz clock by 27 to get 3.57142... and divide that by 3, i though that the input clock for cpu riot and tia would all be the same 1Mhz clock input but i just reveresed the phase for all these because i thought thats what i was meant to do

 

Link to comment
Share on other sites

6 minutes ago, Leewrigley said:

So, within my TIA module, have a straight divide by 3 clock output which goes into the CPU, do i need to change the phase at all?

 

i saw from the schematics that it worked this way but i just though i could generate clocks in the top level module and use them where needed.

 

btw my clocks arnt 100% accurate but should do for the sake of this project, i divide the 100Mhz clock by 27 to get 3.57142... and divide that by 3, i though that the input clock for cpu riot and tia would all be the same 1Mhz clock input but i just reveresed the phase for all these because i thought thats what i was meant to do

 

 

Under the circumstances, I wouldn't worry about shifting phases. As long as you know to have a separate delayed clock for your peripherals you're okay. The alignment of the cpu clock and the internal TIA clocks also matters, but I also wouldn't stress too much on that right now, until after you have it end to end. I should also add that the TIA in my project is not complete and shouldn't be trusted as a reference for some parts. The audio, and parts of it used by 7800 are tested and working well, but I punted the HMOVE and other graphics drawing to after release, so I could work on it separately (right now).

Link to comment
Share on other sites

Just now, Leewrigley said:

hey @Kitrinx, sorry to ask a million questions but in your t65 instanciation you showed me before..

what is RD for data input and also what is pclk1 and cpu_halt_n for the enable signal, i never had those before?

thanks

HALT is a signal that is specific to the 6502C aka "Sally" used for 7800, and you don't have to worry about it. RD is simply the RW signal, Read is high, write is low. Pclk1 is phi1 and used the drive the clock of the cpu. If you are generating a clock directly, you would want to make "enable" 1 and feed your clock as the clock signal. In my case I give it the system clock (14mhz) and use a 1-cycle-long clock enable to gate the timing of the CPU. To keep it simple for you, I think you should just skip the enable and use your cpu clock directly as the clock.

Link to comment
Share on other sites

2 minutes ago, Leewrigley said:

Thanks for that, unfortunatly my verilog compiler doesnt know how to deal with the vhdl because it has complex port types apparently... always something!

That's not unusual. Simulation can be quite a pain in mixed language projects.

Link to comment
Share on other sites

managed to get it simulating now, not sure if it will synthesise or anything though not tried yet, looks to be running which is good, i notice that not much gets written to the TIA registers at all, only position registers really so il need to look into that, maybe have polarity of read write or something flipped somewhere. BTW not sure if you would know or not but for the tia in the data book it says that write operations are done on the negedge of the clock, do you think this would make much difference?

Link to comment
Share on other sites

1 hour ago, Kitrinx said:

 

Under the circumstances, I wouldn't worry about shifting phases. As long as you know to have a separate delayed clock for your peripherals you're okay. The alignment of the cpu clock and the internal TIA clocks also matters, but I also wouldn't stress too much on that right now, until after you have it end to end. I should also add that the TIA in my project is not complete and shouldn't be trusted as a reference for some parts. The audio, and parts of it used by 7800 are tested and working well, but I punted the HMOVE and other graphics drawing to after release, so I could work on it separately (right now).

@Kitrinix Why wouldn't you use the Atari 2600 HDL I spent 10 hours on reviving, testing, packaging, and giving to Alan and yourself two weeks ago?  With the exception of two or three minor bugs, it works well.  I believe the code was well documented.  I'm open to hear any criticism of it ? .  I am NOT being confrontational at all! ? .  I was hoping to submit more to MiSTer eventually (the Cinematronic vector games are next on my list of things to get up and running on MiSTer ... that was another fun design ? ).

I did the 2600 back in 2005.  There was a cool article written up about it in Xilinx's now defunct XCELL journal.  I was asked about it constantly for two weeks by various people in the MiSTer group on Facebook when I mentioned it.  I finally got to it, delivered it, then heard virtually nothing about it. The late, great Curt Vendel and I became friends over that implementation too (he and I started to chat when I first posted about it ... damn shame what happened to him ? ).

Yes, I understand that the version that was first tested by Alan didn't work when I fired that giant zipfile Alan's way.  I had to find the right revision.  I made various demos using various versions and the like and kept everything in a mess of directories ... including some hacked up ones and partially cleaned up code ... it was a giant mess.  That was long before I grew up and used revision control at home ? .  I made it clear that I was delivering the zipfile just to show that it wasn't vaporware.  The following week, I found the proper revision, cleaned it up, tested it on my devkit, forwarded it on, then was promptly discarded/ignored/not contacted like I was garbage or something! ?

I think I have two bugs in my implementation of TIA (one of those is related to the clock alignment ... that's why I replied to that message you posted) ... despite those issues, it ran almost the entire gamut of Atari games and demos accurately.  I am using a revision of the T65 core that supposedly still has a couple of bugs and no undocumented opcodes.  The other known bug is proper implementation of the Cosmic Ark starfield "feature" (though that can be debated if it is actually a bug :-)).  One thing I did that was bad (by today's standards) was the use of asynchronous resets that are pretty much frowned upon when using modern FPGA devices, but those constructs are relatively easy to clean up. 

Anyway, OUTSTANDING (and that's an understatement) work on the 7800 ... those Atari ASICs are not easy to implement in an FPGA at all!  The 2600 was quite challenging to say the least ... I would have done a slightly higher level implementation, but I also wanted to capture the original TIA as best as I could for FPGA implementation (hence my decision to create that NMOS style of charge-and-forward (or precharge/evaluate), two phase clocked flip flop for FPGAs that is sprinkled throughout the design ? ... I know I didn't *have* to do it that way, but I blame it on my retro-OCD ? ).   

People looked at me funny when I'd say that making a perfect Atari 2600 is much more difficult than a seemingly more complex (in terms of FPGA porting) system like Colecovision or the base components of an NES ? (not saying either of those are "easy" to implement at at all ... they're just a little bit more like modern designs than stuff from the 1970s).  If you're off by so much as a single cycle almost anywhere in the 2600, it fails ... miserably ? .

Link to comment
Share on other sites

1 minute ago, ehenciak said:

@Kitrinix Why wouldn't you use the Atari 2600 HDL I spent 10 hours on reviving, testing, packaging, and giving to Alan and yourself two weeks ago?  With the exception of two or three minor bugs, it works well.  I believe the code was well documented.  I'm open to hear any criticism of it ? .  I am NOT being confrontational at all! ? .  I was hoping to submit more to MiSTer eventually (the Cinematronic vector games are next on my list of things to get up and running on MiSTer ... that was another fun design ? ).

I did the 2600 back in 2005.  There was a cool article written up about it in Xilinx's now defunct XCELL journal.  I was asked about it constantly for two weeks by various people in the MiSTer group on Facebook when I mentioned it.  I finally got to it, delivered it, then heard virtually nothing about it. The late, great Curt Vendel and I became friends over that implementation too (he and I started to chat when I first posted about it ... damn shame what happened to him ? ).

Yes, I understand that the version that was first tested by Alan didn't work when I fired that giant zipfile Alan's way.  I had to find the right revision.  I made various demos using various versions and the like and kept everything in a mess of directories ... including some hacked up ones and partially cleaned up code ... it was a giant mess.  That was long before I grew up and used revision control at home ? .  I made it clear that I was delivering the zipfile just to show that it wasn't vaporware.  The following week, I found the proper revision, cleaned it up, tested it on my devkit, forwarded it on, then was promptly discarded/ignored/not contacted like I was garbage or something! ?

I think I have two bugs in my implementation of TIA (one of those is related to the clock alignment ... that's why I replied to that message you posted) ... despite those issues, it ran almost the entire gamut of Atari games and demos accurately.  I am using a revision of the T65 core that supposedly still has a couple of bugs and no undocumented opcodes.  The other known bug is proper implementation of the Cosmic Ark starfield "feature" (though that can be debated if it is actually a bug :-)).  One thing I did that was bad (by today's standards) was the use of asynchronous resets that are pretty much frowned upon when using modern FPGA devices, but those constructs are relatively easy to clean up. 


 

????

 

I meant you no disrespect at all, your implementation was very thorough and the parallels to the schematic were clear and well observed, but I had my own TIA partially written since 2019 and it had clock enables already, and I find it fun. Sometimes the best way to really understand a system it to write it yourself. I did try to use yours for a bit, but I had issues with the clocking and I have a special hatred for working with VHDL :)

 

 

Link to comment
Share on other sites

14 minutes ago, ehenciak said:

People looked at me funny when I'd say that making a perfect Atari 2600 is much more difficult than a seemingly more complex (in terms of FPGA porting) system like Colecovision or the base components of an NES ? (not saying either of those are "easy" to implement at at all ... they're just a little bit more like modern designs than stuff from the 1970s).  If you're off by so much as a single cycle almost anywhere in the 2600, it fails ... miserably ? .

 

Having worked on both, of these, and many other system, I can say 2600 is one of the most absolutely unforgiving systems in terms of being cycle and sub-cycle accurate. It's not just that the system itself had a tremendous number of quirks, but the programmers who wrote for it were (and are) aggressively hacky, using every scrap of every cycle and every idiosyncrasy they can find to their advantage.

 

NES is difficult because of its 1001 mappers and the complexity and bugs in the PPU and APU, but ultimately it's a lot more forgiving.

Link to comment
Share on other sites

Wow what a deep and encouraging discussion about FPGA implementation for the Atari 2600!  Do any of you know if someone is working on producing an FPGA version of the TIA?  I mean with the intent to actually create a physical chip that could plug in as a TIA replacement.  Those are getting hard to find and it would be nice to have something that would work if an old chip cannot be sourced.

Link to comment
Share on other sites

2 minutes ago, wongojack said:

Wow what a deep and encouraging discussion about FPGA implementation for the Atari 2600!  Do any of you know if someone is working on producing an FPGA version of the TIA?  I mean with the intent to actually create a physical chip that could plug in as a TIA replacement.  Those are getting hard to find and it would be nice to have something that would work if an old chip cannot be sourced.

 

There's at least a few existing implementations that could be used for this purpose I would think, if someone cared to design it with a little max10 or something.

  • Like 1
Link to comment
Share on other sites

@Kitrinx Im using vivado i dont know about you, but how were you able to get over the T65 implementation in your verilog proect, i can simulate just fine but i cannot synthesise because of compex port types, i saw on xilinx website it could have something to do with negative structures ie (-1 downto 0) i didnt see anything like that in the code though. What would the complex port type even be, i wonder if it could be adapted?

Link to comment
Share on other sites

3 hours ago, Leewrigley said:

@Kitrinx Im using vivado i dont know about you, but how were you able to get over the T65 implementation in your verilog proect, i can simulate just fine but i cannot synthesise because of compex port types, i saw on xilinx website it could have something to do with negative structures ie (-1 downto 0) i didnt see anything like that in the code though. What would the complex port type even be, i wonder if it could be adapted?

 

My experience is with intel FPGAs. Quartus doesn't complain at all about using VHDL functions like that, as long as the source is properly assigned as VHDL in the qip file.

Link to comment
Share on other sites

9 hours ago, Leewrigley said:

@Kitrinx Im using vivado i dont know about you, but how were you able to get over the T65 implementation in your verilog proect, i can simulate just fine but i cannot synthesise because of compex port types, i saw on xilinx website it could have something to do with negative structures ie (-1 downto 0) i didnt see anything like that in the code though. What would the complex port type even be, i wonder if it could be adapted?

Which version of the T65 are you using?  I had no problems using it with Vivado, but I am also using an older version :-).

Link to comment
Share on other sites

20 hours ago, Kitrinx said:

 

I meant you no disrespect at all, your implementation was very thorough and the parallels to the schematic were clear and well observed, but I had my own TIA partially written since 2019 and it had clock enables already, and I find it fun. Sometimes the best way to really understand a system it to write it yourself. I did try to use yours for a bit, but I had issues with the clocking and I have a special hatred for working with VHDL :)

 

 

Sorry if I came off abrasive ... I joke all of the time ... It's been a while since I posted here on Atari Age and forgot nobody knows who in the hell I am here ... sorry about that :-).

First, it is a shame that all of you Verilog snobs don't appreciate the fact that some languages make you write 492367209346 characters to infer an AND gate.  More is better, and that's what makes VHDL the superior language :-). Some of us like to type a lot!  You saw my code and its comments ? ... if you'd eliminate the comments and VHDL overhead, I think the 2600 could be represented in 300 lines of code ? :-).

 

Kidding aside, I use both, but prefer VHDL since I know it a better.  It's also easier to create more complex testbenches though SystemVerilog addresses a lot of Verilog's shortcomings in that department.  Outside of that, they're both fine languages each with their own plusses and minuses.  I usually crack up over online debates about which is better ... but often find myself a bit more pro-VHDL when it comes to beginners learning this stuff.  

Next, I consciously kept the HDL of my TIA more of a structural style ... I do use some abstraction where it is warranted (like the LFSR counters ... it's better to use a regular counter and decode off those values ... they only used LFSRs since they're less area and a bit faster than traditional adders used in counters).  However, I like to keep these redesign kinds of projects as close to the source material as possible and abstract more when I think some clarity for a reader is warranted.  That's merely my preference and nothing more.  Some like designing that way, some don't ... however, either way is fine so long as the 1s and 0s the new design spews match the old 1s and 0s :-).  

When I first set out porting TIA, I knew *how* TIA worked from a high level, but didn't know the details.  I also made equivalent, "not intended for synthesis" components so that I could compare "real" against "new" as it was designed.  As I got it closer to the functional state, I was going to go back and change things up to make it a bit more abstracted from the finer details, but I also figured why not leave it alone since someone could learn from it someday.  There aren't many good "NMOS logic in an FPGA" reference designs out there.  While I never released it, I plan on doing so just for another example to be out there. 


One other note ... I do use clock enables in my design ... it doesn't seem like it at the top level of TIA though ... the clock drives a component in TIA that generates enables for the rising and falling edges of both the TIA clock and the CPU clock.  Other "clocks" I may drive in the logic are what I call "reference" clocks ... I am either looking at those signals in simulation to make sure I am doing things right, or I am using that "reference" clock (again, not a clock used to drive flops ... that's a big no-no) in a combinational logic function.  In other systems I have ported, I make a record with the rising edge, falling edge, and "reference" signals all packed up in a nice structure ... it makes things a bit easier to use the proper enable if I made a mistake somewhere (i.e. no need to route something from one component to the next).  Now that SystemVerilog introduced "structs", I think I can do the exact same thing in Verilog.

I do agree that not using clock enables can lead to disaster ... You are foolish to not use them in an FPGA :-).  I'd run from anything that didn't use them :-).

Anyway, how far along are you with Intellivision? I looked into it at one point, but never coded anything.  That CPU it used is pretty slick for late 70s technology.  

I do have the old Cinematronics vector stuff ported (no sound boards ... yet .... looking forward to that since I have little experience modeling analog stuff ? ). I need to get that up and running with a rasterizer though.

I'd really like to take a stab at the third generation Williams stuff (MKI & II, Smash TV, etc.) since that would require a CPU design, but I don't know if someone else is already on that. Have you heard anything (PM me if you don't want to spread rumors ? )?

I'm in the process of getting the second generation Williams stuff up and running for a personal project (Inferno, Turkey Shoot, Mystic Marathon (yuck ... total waste of the potential of that hardware) & Joust II), but I think someone is already working on that for MiSTer.

Ed

 

Link to comment
Share on other sites

4 minutes ago, ehenciak said:

Sorry if I came off abrasive ... I joke all of the time ... It's been a while since I posted here on Atari Age and forgot nobody knows who in the hell I am here ... sorry about that :-).

First, it is a shame that all of you Verilog snobs don't appreciate the fact that some languages make you write 492367209346 characters to infer an AND gate.  More is better, and that's what makes VHDL the superior language :-). Some of us like to type a lot!  You saw my code and its comments ? ... if you'd eliminate the comments and VHDL overhead, I think the 2600 could be represented in 300 lines of code ? :-).

 

Kidding aside, I use both, but prefer VHDL since I know it a better.  It's also easier to create more complex testbenches though SystemVerilog addresses a lot of Verilog's shortcomings in that department.  Outside of that, they're both fine languages each with their own plusses and minuses.  I usually crack up over online debates about which is better ... but often find myself a bit more pro-VHDL when it comes to beginners learning this stuff.  

Next, I consciously kept the HDL of my TIA more of a structural style ... I do use some abstraction where it is warranted (like the LFSR counters ... it's better to use a regular counter and decode off those values ... they only used LFSRs since they're less area and a bit faster than traditional adders used in counters).  However, I like to keep these redesign kinds of projects as close to the source material as possible and abstract more when I think some clarity for a reader is warranted.  That's merely my preference and nothing more.  Some like designing that way, some don't ... however, either way is fine so long as the 1s and 0s the new design spews match the old 1s and 0s :-).  

When I first set out porting TIA, I knew *how* TIA worked from a high level, but didn't know the details.  I also made equivalent, "not intended for synthesis" components so that I could compare "real" against "new" as it was designed.  As I got it closer to the functional state, I was going to go back and change things up to make it a bit more abstracted from the finer details, but I also figured why not leave it alone since someone could learn from it someday.  There aren't many good "NMOS logic in an FPGA" reference designs out there.  While I never released it, I plan on doing so just for another example to be out there. 


One other note ... I do use clock enables in my design ... it doesn't seem like it at the top level of TIA though ... the clock drives a component in TIA that generates enables for the rising and falling edges of both the TIA clock and the CPU clock.  Other "clocks" I may drive in the logic are what I call "reference" clocks ... I am either looking at those signals in simulation to make sure I am doing things right, or I am using that "reference" clock (again, not a clock used to drive flops ... that's a big no-no) in a combinational logic function.  In other systems I have ported, I make a record with the rising edge, falling edge, and "reference" signals all packed up in a nice structure ... it makes things a bit easier to use the proper enable if I made a mistake somewhere (i.e. no need to route something from one component to the next).  Now that SystemVerilog introduced "structs", I think I can do the exact same thing in Verilog.

I do agree that not using clock enables can lead to disaster ... You are foolish to not use them in an FPGA :-).  I'd run from anything that didn't use them :-).

Anyway, how far along are you with Intellivision? I looked into it at one point, but never coded anything.  That CPU it used is pretty slick for late 70s technology.  

I do have the old Cinematronics vector stuff ported (no sound boards ... yet .... looking forward to that since I have little experience modeling analog stuff ? ). I need to get that up and running with a rasterizer though.

I'd really like to take a stab at the third generation Williams stuff (MKI & II, Smash TV, etc.) since that would require a CPU design, but I don't know if someone else is already on that. Have you heard anything (PM me if you don't want to spread rumors ? )?

I'm in the process of getting the second generation Williams stuff up and running for a personal project (Inferno, Turkey Shoot, Mystic Marathon (yuck ... total waste of the potential of that hardware) & Joust II), but I think someone is already working on that for MiSTer.

Ed

 

 

Intellivision? I don't even think I'd be willing to open that console in my text editor :) Maybe you're thinking of Grabulosaure, he wrote an intellivision core that is pretty mature. I am generally not involved in any arcade related things, Alan is who you want to talk to there. I mostly deal with 3rd+ gen consoles. 2600 is kind of an exception for me, which I got tangled up in because it's such an integral part of 7800. It's best to make sure people are actually working on things, and not just saying they're working on them. A lot more people start things than finish them, so there's plenty of orphaned things with old comments where people say they're working on it.

 

 

Link to comment
Share on other sites

15 hours ago, hizzy said:

I'm curious to ask - as someone who plays on OG software, is now a good time to pick up a Mister for Atari gaming? Will these cores be released? Thanks!

7800 is already released, and pretty feature complete. If you are a CRT gamer, it might be amongst the best ways to play the system right now. There is also an existing 2600 core which is pretty capable, but not as feature complete as it could be, which is why I'm working on it. There's cores for 5200, ST, and Amiga as well which are well regarded. The Jaguar core is in sort of a pre-alpha state and development isn't active on it.

 

Several Atari arcade machines are also represented, but I couldn't say how well regarded they are.

  • Like 3
Link to comment
Share on other sites

  • 2 years later...

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...