RIOT After Reset

[ehenciak]

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...

[supercat]

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.

 

The normal approach I've seen and used is simply to store the value read from INTIM into the random number seed. The assumption seems to be that the INTIM value on startup will be 'random'. If INTIM starts in anything other than 1x mode, it will revert to 1x mode after it counts to zero. My guess would be that INTIM just free runs, even during reset, in which case it will most likely be in 1x mode by the time the 6507 starts executing code (if it started in 1024x mode with a count of 255, it might not count all the way down to zero before /RESET is released, but if it's in any other mode it certainly would).

[ehenciak]

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

[+batari]

As I understand, Kool-aid man writes to the HMCLR or HMxx (can't remember which) when you're not supposed to, and thus it doesn't work on all consoles anyway. I could be wrong about that, though.

 

Other than that, it's good to see that you're still working on this!

[ehenciak]

As I understand, Kool-aid man writes to the HMCLR or HMxx (can't remember which) when you're not supposed to, and thus it doesn't work on all consoles anyway. I could be wrong about that, though.

 

Other than that, it's good to see that you're still working on this!

 

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

[Eckhard Stolberg]

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 !

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).

 

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.

 

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.

 

The display problem that batari mentioned is indeed related to the Cosmic Ark starfield effect. If you have your HMOVE handling work properly, then there shouldn't be a problem with Kool Aide Man. If not, then the digits in the score display might overlap. In that case the game constantly triggers the collision detection, so that the Kool Aide Man sprite bounces back and forth in the top left corner.

 

 

Ciao, Eckhard Stolberg

[ehenciak]

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

[supercat]

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.

 

The version of Z26 I'm familiar with simply looks for a few cases of when horizontal-related writes occur and acts appropriately. "Confusion" mode is only handled for M0, and it's a very rough approximation of the real thing. There are some useful HMOVE tricks that do not get handled properly at all, including doing an HMOVE followed by a RESPxx (if some HMOVE ticks are still pending, they'll take effect after the RESPxx, but the emulator ignores that) and doing two HMOVEs with consecutive STA instructions (if done on the proper cycles, this approach will allow some sprites to be moved +/- 8 pixels on alternate scan lines while other sprites remain motionless, all without having to update HMxx).

[Eckhard Stolberg]

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.

There should be working versions of these ROMs available. The first time the ROMs were available was in the form of these bad dumps, so they got spead pretty widely. Therefore it might be a bit difficult to find good copies.

 

You need to start these games in the higher bank, because the lower bank has the system vectors from the higher bank too, which doesn't work.

 

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 !

IIRC, CommaVid extra RAM has the read ports at $1000-$13ff, the write ports at $1400-17ff and the ROM at $1800-$1fff.

 

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.

Supercat is right. The current versions of the emulators aren't that acurate when it comes to HMOVE handling. For the special cases, like Cosmic Arc or Kool Aide Man, we basically cheat well enough to get the available games working. It would be quite easy to break the emulation with a new game.

 

 

Ciao, Eckhard Stolberg