Jump to content

ehenciak

Members
  • Posts

    78
  • Joined

  • Last visited

Profile Information

  • Location
    Pittsburgh, PA USA

Recent Profile Visitors

3,561 profile views

ehenciak's Achievements

Star Raider

Star Raider (3/9)

0

Reputation

  1. 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
  2. Which version of the T65 are you using? I had no problems using it with Vivado, but I am also using an older version :-).
  3. @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 ? .
  4. ehenciak

    5200 in FPGA?

    Do you have any updates on this project? Just curious :-). BTW, the 5200's controllers were actually analog in nature and sensed by POKEY. Your best bet might be to hack this behavior into your design and test with a simple joystick ... maybe fake out the 5200's keypad with a PS2 keyboard ... just some suggestions :-).
  5. Your points are all valid ... the 7800 deserves a bit of an exception though :-) ... 1> The original 7800 was supposed to ship with a Pokey instead of just using TIA for audio. That alone there was a travesty. If they could have managed to deliver POKEY, the system may have done a bit better. The audio on the 7800 was horrible even by mid 80s standards. 2> They keyboard and high score savers were prototype peripherals that never hit the market. 3> There is an expansion connector ... may as well do something with it :-). Again, I really see your points ... it just looks like this add-on (aside from the extra memory) may have very well been in the cards back in the day for the 7800. I kind of dig the new hardware personally ... especially if the case looks like it should be part of the system :-). Like others have eluded, I'll buy one for the aesthetics/basic features just to round things out with the 7800 :-). Ed
  6. "(This is one of the most interesting threads I've read in a long time.)" I'd say ... hell, I thought I knew a lot about Atari and 90% of this is news to me. I love a good dose of schooling in history from time to time :-)! Nolan does make some decent posts on Facebook :-)! That much I know :-)!
  7. I'm playing with FPGAs too, and I would be interested by what you've done so far with the 2600. I've emulated some old (obscure) computers myself (the latest one being the Oric-1). Have a look at my website, there is some information about my projects. Ah...you're the Intellivision guy :-)! I've been to your site many times! I basically have the whole 2600 up and running. I'd say compatibility is about 95% of all titles released prior to 1992. I don't have the ability to test some of the stranger bankswitching schemed games at this time since I haven't written the circuits yet. There are a few critical things I have to do though : 1> Damn Cosmic Ark starfield bug....I know how this happens (I think) in TIA, but you gotta have it perfect if you *really* want to play Kool Aid Man :-). I really don't care about this since I hate Kool Aid Man and Cosmic Ark is more than playable, but I am also a perfectionist :-)! 2> I need to fix two or three "asynchronous clear" paths in the FPGA....these cause a build-to-build issue that unveils a few problems. Basically, I hacked in a solution just to test games...this really has to be fixed though since good digital designers keep the whole thing synchronous ! Let's say I made an ASIC out of this or ported it to some other FPGA....chances are things would misbehave :-)! 3> Add undocumented opcodes to the 6502 from Opencores (MikeJ and I fixed several bugs in this core for cycle-to-cycle accuracy issues....it still could be a lot better though). Still, some of the demos that beat the crap out of TIA are behaving just fine and I managed to squeeze it all into a relatively tiny FPGA (2,000 LEs....I figure I can get this down to 1,500 with a better 6502). I also wrapped a Microblaze around the core + use external asynchronous SRAM to act as both a frame buffer for the LCD I am driving as well as a manager for uploading games to external SRAM. Of course, the Microblaze adds more logic, but that is not really needed (it's just a fast way to add communications ). There's mention of my rendition of the 2600 in an old Xilinx Xcell journal....just do a search for Xilinx Atari on Google. I'd love to make a small system out of this (I am 1/4 thru the 7800 and have a decent understanding of the 5200 based chips), but I flat out don't have much time. I work full time + manage to swamp myself with contracts on the side. Still, if I could get a few people together to handle some embedded software stuff, I'd like to make a small system based on this thing someday ! I'm booked until August though and I promised my wife that I would behave on side jobs this fall. I am more interested in making a console as opposed to a handheld since LCD prices still aren't exactly cheap (save the ones you can get from Electronics Goldmine.....but you need to discard a few scanlines to smash the 2600 display onto that). PM me your email address ! I wouldn't mind talking with you ! Ed
  8. OK, a handheld with ethernet, 2 banks of DDR DRAM, a 1.5M gate FPGA (have to assume a Spartan 3e or Cyclone here), 1gbps busses.....I guess it isn't a handheld unless Wanga also developed some kick ass fuel cell. It looks as if the feature creep has taken over. Just a suggestion in case the Wanga people are paying attention : stick to your original gameplan What baffles me is that I cannot see how this could be produced @ a reasonable price. Moreover, development kits already exist with most of these features....you're better off getting once of those cheaper $99 Xilinx kits and making a simple riser card for the video output. Someday I'll finish my 2600 VHDL project. In fact, I might just release the source code when Wanga comes out :-)! (Please, no "Ok Ed, that makes two cases of vaporware"....trust me, my version does exist and I have given the source to a few people in the event I die or FPGA design induces a heart attack :-)!) Ed
  9. In particular, VHDL Simili doesn't support user-defined resolution functions for composite types, so I had to use ModelSim for this project. Just curious, were you using these constructs for synthesis or verification purposes? I guess I am kind of old school when it comes to synthesis and I avoid stuff like this (call it company guidelines and less time to experiment...and getting too set in my ways at a relatively young age...bad ). However, if I am not mistaken, resolution functions are used when you have multiple drivers on a signal...like when you do something concurrently as in : sig_a <= '1'; sig_a <= '0'; Result on sig_a is usually 'U' or 'X' (I forget exactly which) That *should* be bad for synthesis...some compilers (actually all I've used) for synthesis will not let that happen. But I've been wrong before and could be wrong now ! I do see how it would be very useful during verification for detection bus collisions/errors. For the record (no pun intended), I assume you are trying to do something like this (and forgive me if my syntax is a little off): TYPE Zinz IS RECORD zinz1 : std_logic; zinz2: std_logic_vector; END RECORD; Then you'd define some function like function wired_zinzes is (blah) return zinz begin ... end function; and subsequently work out the resolutions in the function body.....is that right? If Simili doesn't support this, maybe email them....those guys are pretty good at replying and learning of weaknesses in their tools. I cannot see why they wouldn't directly support that right now. For the most part, I don't write my own resolution functions, but I could probably see a day where I need that kind of functionality after shooting my mouth off that it could be done with Simili ! If you were doing this for synthesis, I'm simply curious as to why ! Ed
  10. Modelsim is the best HDL simulator on the market in my humble opinion. I wouldn't classify it as a "linter/coverage" tool though...it is primarily an HDL simulator. Modelsim does provide some basic synthesis checks at compile time, but not sign off quality caliber. Linting tools are typically separate beasts that cost significant $$$. Code coverage is an additional component you can buy for modelsim, but with the kind of circuits I suspect your company is designing, I doubt it would be necessary. The least inexpensive, but totally useful version of Modelsim one can purchase is Modelsim DE. It is geared towards FPGA designs, but it can be used for FPGA/ASIC/entertainment purposes as it is a "complete" HDL simulator. It is not to be confused with the "Free" versions of Modelsim you might get from Altera or Xilinx as it is not bound to those particular technologies (plus, they are annoying once you "really" use Modelsim). A fantastic alternative is VHDL Simili available from www.symphonyeda.com. One year license cost is only $300 and is perfect for most semi-complex VHDL simulation purposes. The "full up" version costs about $1K if you need the additional features, but it suited the 2600 FPGA I did just fine as well as a few other design contracts I had/have. I know of two other chip engineers that use it religiously to free up more expensive Modelsim licenses for more large scale tasks. Ed
  11. For what it's worth, I did not have the timer implemented properly in my FPGA and these games worked fine. Basically, it was a case where the CPU could never, ever get out of the polling loop that checks to see if the timer reaches zero. The games this did impact (comming from memory here) were Boxing and Berzerk among others.
  12. Sky Patrol and Sir Lancelot are most likely bad ROM dumps that have wrong system vectors in one of the banks. You have to start them in the other bank to get them working (or fix the reset vector in the ROM image). Thanks for the warning ! I tried another dump and it still doesn't work...I'll probably have to fix the reset vector. Just curious, do you detect these ROMs in Stella and act accordingly? Or, better yet, should I be pointing to a particular bank at powerup? I find it strange that virtually of of these ROMs are good save two. Video Life uses 1K of extra RAM on the cartridge. If your test system doesn't support this, the game won't be able to change the display. This explains what I am seeing ! I don't get the nice cursive "Life" ... I get tones of death, a yellow pixel dropping into a bunch of red pixels, a flickering screen, then a static world displayed with no life what so ever...kind of like my hometown of Pittsburgh ! Just curious, how do they map memory? Is it like Atari or CBS? I haven't put RAM support in yet simply due to, well, laziness ! In fact, I only support one bankswitching for each of the ROM sizes, so I have no idea how my FPGA works with Parker Bros. or Tigervision stuff...yet. This makes it easier for me right now since I basically enable a bankswitch method based on the size of the ROM I send from the PC to the FPGA...when I add RAM support, I am simply going to have a checkbox to enable RAM for Atari games. If I see that the ROM is 12K, I know it is CBS RAM.... If I get a 2K ROM, I know that it's Video Life. In the end, I will have to get creative since I know that end users will not want to put up with that nonsense ! Kool Aide Man uses one of the difficulty switches for a pause feature. If the switch is in the 'pause' position, the game will lock up in the title screen as you describe. Simple flipping the switch will solve the problem. Cool! And with a flick of a switch, BAM! Works! In fact, it works exactly as you described seeing that I have HMOVE/CLR broken! I kind of expected this. My implementation of HMOVE "bug" was known not to be perfect. While Cosmic Ark looks good, it is not perfect. Just curious, when you do SW emulation, are you using something like a virtual tick of the pixel clock to update the state of the system? I know I can go and look at the source code, but I really want to avoid doing that until I am done with the hardware side of things...I'm just wondering how you guys pull off accuracy like that in software ! In other classic systems, I can see how you might be able to be a little "relaxed" (that is probably a poor choice of words) in what you are doing and at what time, but with the 2600, there is literally no margin for error on each tick of the clock. Thanks for the help. That just saved me hours simulating Kool Aid Man and slamming my head off a wall ! I am currently working on a port of the Colecovision hardware to my development kit (the one available on www.fpgaarcade.com)...again, if all goes well, I should be able to show off something this weekend. These things tend to get sidetracked, but I am hoping that there are no surprises. Ed
  13. Rotten Kool Aid Man... :-)!!!! I still want it to work. I want my rendition of TIA "Kool Aid Man" ready ! Besides, what good is a broken TIA if you intend to get the 7800 done next (despite not using most of TIA, the 7800 would be easier if I had a known working TIA). I've been chewing on Maria @ lunchtime, but most of my evenings are focused on the 2600. If HMOVE/CLR was the problem, then I would expect Kool Aid Man to execute, but show garbled graphics...that is not the case with my silly design. I get a stupid screen of something that resembles the intro screen, but frozen. If I *really* cared about this game I would simulate it and tear it to pieces (and I will), but for now, I am merely testing the 400+ ROM images I am capable of playing and knocking out problems one by one. In fact, what you are describing seems to be related to the Cosmic Ark "feature" ! Now that I have insulted Kool Aid Man (a.k.a Bira Bira II), I assure you that fixing this bug will clean up any other bug I have in the system once fixed (OH YEAH!!!!). Over the past 1.75 years, I was sidetracked with a lot of FPGA related contracts and I had no time for anything fun. Also, Flashback 2 was on the way out and there really didn't seem like there was a need for a chip like this at that time. However, once I finished my little contracting endeavor (one of those was a PCI Express design that I thought had the best of me), a friend and I drug this design out of mothballs (this was around October of '06). These homebrew projects tend to limp along when you have a rotten job screwing you out of time ! Anyway, to make a long story short, I started re-attacking the logic in December and I have been making progress, when time permits, since then. I hope to post something on AA this weekend...I *really* hope the response is good ! I've been working a lot on this thing the past two months (even more so that past 3 weeks), so I hope to have good news sooner rather than later this time ! Ed
  14. Thanks for the quick reply. I understand what you are doing. My reset in my FPGA is rather "determinstic" in that once a clock manager locks on to a reference clock, the 2600 power on reset deasserts exactly 256 ticks of my "2600" clock later. Therefore, when I boot a game with RIOT coming out of reset in a DIV1 mode @ a 0x00 initial vector, a game like Boxing boots looping forever since it will never read a zero from the timer. Changing that to DIV64T & 0xFF works fine for now. I want this right though, so I am going to have to do some research!!!! (RIOT was also used in Gottlieb pinball machines & I want to do something in that department as well). I think what I am going to do is wire up a RIOT to a logic analyzer and see what it does timer wise. I kind of suspect that if I address the timer by wiring down the address for timer reads, I should be able to see what comes out of RIOT after a reset (I suspect that values from the RIOT are simply multiplexed out of the device...we'll see. That should put this issue to rest once and for all :) !!!!! It will also let us know if the timer is reset by the external reset line. This is getting pretty interesting....of all the games tested so far (i.e. 2K, 4K, 8K F8, 16K F6) games, only Koolaid Man and some ROM called "challenge (PAL)" are locking up 4K ROMs-wise. In the 8K realm, I lock up on Sky Patrol and Sir Lancelot. 2K wise I have problems with Video Life. About 20 or so are displaying some strange, but subtle, artifacts here and there. Congo Bongo is the worst of these 20 since it either boots incorrectly or displays garbled objects. All the ROMs I mark as "bad" on my virtual system look good on Stella/Z26. I really need to order myself a Kroko-cart for test purposes ! I still have a lot of playing, er, um, testing to do, but a vast majority of the games in those categories mentioned work perfectly. I'm just glad I finally got HERO to work...that game is probably one of the best in history. I actually prefer the 2600 version over Colecovision :-)!!!! Thanks for the help! It's appreciated! Ed
  15. Hi all, What mode is the RIOT timer in after a system reset (or power up I should say). To be clear, what I mean is a power on reset and not depressing a "game start" reset. I notice that some games depend on the timer to be ticking down at a rate that is not equal to DIV 1. Overall, the game will execute a bunch of initialization code and then sit in a loop where it polls a timer. The results of the timer read are stored in the X register. Now, if the timer is ticking down at a "fast DIV1" rate, the CPU never sees the timer reach zero...it simply spins on and on forever and the CPU will always read the current timer value at a nonzero value. Since the CPU will read the timer at a deterministic interval, it never reads a zero in this case. According to the datasheets, it seems that all internal registers are set to zero....based on what I am seeing, this really doesn't appear to be the case. When I use a RIOT model that is in DIV1 mode after reset, nothing works...I probe some internal nets and I see the 6502 in a nice loop (opcodes AE, D0, AE, D0 ...etc.) hitting the RIOT at a fixed period (I am executing Boxing). Now, when I change the powerup values to DIV64 and initialize the timer to all ones vs. all zeroes, everything works! I can play Boxing, Blueprint, HERO, and a few others ! Finally, the timer should spin forever at a DIV1 rate after the timer expires, correct? That is what I gathered from the data as well. Now keep in mind that I am stupid...am I missing something here ? Is "00" the encoded timer value Let me log something from Z26 real quick too.... * wait * OK, cool...it seems that the timer tick occurs every 256 CPU cycles...the timer must be in some non DIV1 mode at powerup... Thanks! Ed PS Yes, after a 2 year hiatus, I brought my FPGA back to life. I spent about 4 months on this from Dec. to Apr. 04/05...it sat for a couple of years, but now it will be back one way or another ! I'll post details about the whole project shortly...hopefully a few of you will get excited. And I recall shooting my mouth off about how easy RIOT is to emulate faithfully...heh heh...
×
×
  • Create New...