RevEng
-
Content Count
6,681 -
Joined
-
Last visited
-
Days Won
10
Posts posted by RevEng
-
-
1 hour ago, Bradsco said:I think it might be. The case I've found is when the dividend is less than the divisor, the result is always zero.
Ah, looking at how the routine runs, I think that's an overlooked case. I'll add a comparison check to the beginning of the routine to cover it.
Until the next release, I'd recommend you just add an if...then test for this case to your code.
-
The new routine should definitely be in there, though it's entirely possible you've run into some other issue. When I get a chance, I'll write up an exhaustive test.
-
1 hour ago, kisrael said:Roughly that's what the 5200 was, landing in 1982 right? Pity about the joysticks.
And then the XEGS again, in 1987. Candy in 1979 would have been much better timing for such a console release, market strategywise.
I won't comment on the sticks, because people living in Proline houses shouldn't throw rocks.
1 hour ago, kisrael said:(Atari 8-bits are so impressive. (and the whole culture, like with the Atari Program Exchange). But I think they were pricey when they came out? Like Atari and Apple had these amazing systems, and C=64 came out a bit later, cheaper but more tuned for playing games, and then they were all competitors.. Sometimes I feel bad hopping to the C64 for the games when Atari had been a much better development machine)
They 8-bits were pricey, but a good chunk of that was ram. A console doesn't need as much ram as a computer does, since the program resides mostly in cart rom, and the Candy console would have no doubt been more streamlined in other ways.
-
21 minutes ago, kisrael said:Heh, yeah, I've been thinking about Random Terrain's saving of the "hula hoop" ad.
I don't think it means quite as much as RT takes from it ... I mean, if that were true in that way, why release the 5200?
More that that. Atari internally expected the VCS to age out of the market around 1980. The "Candy" project, which later became the Atari 400, was originally planned to be a keyboardless console that was the remedy to that problem. [source]
-
3
-
-
2 hours ago, Cafeman said:1. Thank you for sharing the interesting Zelda dev-team statistics chart!
2. A lone 7800 programmer could not do a Zelda-style game/clone, true. Even with Adventure II, a 32K game on 5200 hardware, we had 3 people contributing. I was the main programmer, but also I needed Raccoon Lad as the artist or else the game would not have been done. He used Calamari's Antic4 utility to make the character sets and then most of the actual screens. He also designed the sprites and moving BG images and their animation. It would have taken me forever to attempt that, I'm not an artist. Then I had to do the coding work of compressing the BG Antic 4 screens, converting all the sprites and animation into ASM/hex bytes and tables, in addition to coding the actual game engine and routines. And it took years of part-time work.
[...]
EDIT - actually, John Swiderski had a Zelda-ish 5200 game demo he shared (Irata Quest?) years back. It functioned and looked all right. I wonder if he did that all himself, how long it took him, and why he bailed on it eventually.
With AdvII being on the Adventure->Zelda spectrum, that's a nice data point for complexity.
It's deceptively easy to put together a quick Zelda-ish demo, but the full game is another beast. I imagine this is where Irata Quest went off the rails. AtariusMaximus quickly put together a 7800 Zelda map traversal demo in pretty short order. (he never planned to take it past a demo). But full-game stuff requires dialog trees, npc behaviours, etc., and all of these needing to be malleable with progress through the game. It's only tenable if you take a well-thought-out data driven approach, with tools being written to support the data generation and encoding.
Aside from dev time, I think there are other reasons to consider a design on the Adventure->Zelda spectrum. The shorter play-time commitment and better replayability of Adventure would be worthy design goals. (while trying to maintain some of that richness of the Zelda world.)
-
2
-
-
21 hours ago, Cafeman said:I imagine a 7800 Adventure 3 (not including PMP's idea) as basically a clone of NES Legend of Zelda. Inventory, health, enemies to battle, multiple weapons to use.
While I don't disagree that the 7800 invites all of this complexity, in the past I've advocated for something between Adventure and Zelda. (for both complexity and story). Reason being that Zelda had a dev team of 6. When people say they want a Zelda clone, IMO they really mean something more like the sequels, which had even bigger dev teams.
A lone 7800 dev taking on a true-to-form Zelda clone will be metaphorically eating an elephant one bite at a time.
-
8
-
-
It's worth mentioning @Nathan Strum's AtariVox audio mixer, for those that are DIY inclined. (as discussed in his About the AtariVox page)
-
2
-
1
-
-
Make sure your .a7800/a7800.ini file has a "hashpath" entry that's pointing at the provided hash directory from the a7800 package.
-
12 hours ago, -^CrossBow^- said:But a hardware issue where? The 7800? The DF cart? That is what we are trying to figure out. The fact that @john_q_atari has this happening to some degree on 3 different 7800s that he has in his possession would indicate it isn't the 7800 as it is unlikely that he would own three of them with the same hardware error right?
Yes, that's the question, and there isn't a simple answer here. The 7800 has some signal quirks. e.g. A14+A15 being pulled up, A12+A14+A15 being run through AND gates before hitting the cart port. (introducing differences in timing between these lines and the others) Bus access happens at 1.19Mhz, 1.79Mhz, and 7.16Mhz, depending on what device is involved. Probably more that I'm not considering. Timing with these quirks, even with eprom based carts, has always been a bit hit and miss.
I only wanted to add some clarity to the fact this likely isn't a software issue, since Versa is immune. I don't own a DF cart, and nor do I have the tools to do a signal timing analysis.
-
1
-
-
Just to underline a point here... While getting rid of "BEQ $00" may have provided relief for Popeye from the 7800basic break protection, it's just masking the real problem. The argument byte of an opcode shouldn't be executed as it's own instruction ever, unless the program flow has gone completely off the rails. The fact that 7800basic calls a dead-stop when BRK is executed is meant to alert the programmer to the fact that something very dangerous has happened, and changing the code to remove the "0" opcode argument isn't really a fix, any more than disabling break protection would be.
This sort of problem with flow control could either be a bad jump, bankswitch, or whatnot, or it could be a hardware issue. The fact that the problem with Popeye didn't manifest when Versa was used, demonstrates it's a hardware issue in that case. Perhaps it's the same here too, since many people can't reproduce it.
-
1
-
1
-
-
Alternate history.
1977: An enhanced version of the VCS is released.
1979: a jealous George Plimpton convinces the Kremlin it should send a bomb to take out the Sunnyvale HQ. Ferris Bueller tries to stop the Kremlin computer from sending the bomb by playing 3D Tic-Tac-Toe with it, but he loses, and the bomb launches anyway. Luckily Nolan and the employees are all out back in the hot tub when the bomb hits, and are unscathed, except for some soot-covered faces and smouldering hair. With the building destroyed, George Plimpton convinces the bank manager to foreclose on Atari's mortgage, but at the last minute Nolan manages to sell the rights to the name "Atari" to some french company. Cut to Nolan, the employees, and Ferris Bueller all triumphantly dancing outside the rubble, and George Plimpton sulking away.
If anybody reading is wanting to option the rights, I currently have several bidders, so come in with your best and final.
-
1
-
5
-
-
2 hours ago, mimo said:[...] let's take a 7800 + video mod + flash cart + SD card+ pokey chip [...]
+ YM2151 + High Score Cart + Covox + xegs keyboard
Plus the ability to play the Rescue on Fractalus demo without every other line messed up.
-
1
-
-
44 minutes ago, John Stamos Mullet said:Isn't this largely dependent on your display method, and the lag of your input devices/controllers?
Sure. But using the same display (hdmi TV) and the same controller that I was using on retroarch for RPi and Android, to me the latency difference is night and day.
On those systems I wasn't able to play Caverns of Mars (A8) with any level of skill approaching what I used to have. I had written it off as just getting old, until I fired it up in MiSTer and played like my old self. Then the same experience repeated itself over and over with a number of games.
But honestly, if you're happy with software emulation, for sure stick with it - to each his own, and I'm the last person to be slagging software based emulation.
-
2
-
-
From the perspective of latency, it's night and day.
-
1
-
-
As far as "ok", the de10 nano is warrantied up to 100 degrees celsius, and shouldn't exceed that during normal operation, so you're unlikely to break things any time soon running this way. However silicon longevity is always inversely related to the temp you're running at over the lifetime of the device, and I don't think we have the data for a specific answer here. i.e. I don't think we know the mean time before failure rate with any mode of cooling, let alone MTBF rates for different cooling scenarios.
There are certain cores that are known to be less stable on some systems, and active cooling seems to improve the situation. This mainly seems to be the SNES and ao486 cores, from what I read.
Being much simpler, the 7800 core shouldn't have the same problems. I could be entirely wrong here, but I also get a feeling these cores with thermal instability issues may be due to race conditions being won differently, after a temperature differential shows up between different parts of the fpga. I wouldn't expect problems with the 7800 core on this count either.
-
1
-
1
-
-
1 hour ago, PacManPlus said:I'm still curious to know why that first unit worked fine after giving it time to warm up.
I think the question can be equally framed as "why didn't the CC2 respond to $800-$FFF after warm-up?" on your first unit.
Best guess is it's along the lines of @tep392's versa problem, with timing of some signal on the device being near some edge case. The warm-up seems to push the unit into not-working side of the edge case.
-
1
-
-
You're welcome. I found an old doc (attached) that clears up the mystery a bit too.
Quote2K used for storing user settings:
Located from $800-$FFF if NVRAM_EN & fpga_req & csiop_csWe likely gave it some impossible settings, which messed up the menu. Odd the messed-up menu didn't persist, as this is battery backed ram, but maybe it detects bad settings and re-inits for the next run. Or maybe Bob's battery isn't doing the job.
-
3
-
-
It's only tested in emulation so far, but give this a shot and let me know.
It's a (fairly involved) hex-edit hack that fixes the display to run on PAL, so no speed tweaks. (I don't know if speed tweaks are even possible.)
Technical details ahead... The display and NMI for this game is a bit unconventional. There are mulitple NMI, and the NMI that's supposed to run at the bottom of the screen looks to see if a vblank transition happens soon, to ensure it actually is running at the bottom of the screen. If that transition doesn't come, it assumes the NMI order is off, and shifts the order. But if the vblank transition is never seen in any of the NMI positions, the shifting never ends.
Due to this NMI scheme, this PAL hack hangs on NTSC consoles, for the same reason the NTSC retail release hangs on PAL. (no vblank transition near the NMIs)
-
4
-
1
-
-
Pretty sure that from the cart's perspective, A12 being forced low (via U4) made access to $1800-$1FFF look like access to $800-$FFF. The CC2 likely has an undocumented mapping or hotspot in that range. Avoiding $1800-$1FFF seems to have done the trick.
-
3
-
-
On 5/2/2012 at 9:31 PM, HammR25 said:I get weird collision detection errors on my CC2 as well. I assume I'm not suppose to hit invisible walls in the middle of the play field unless I'm just using the wrong bankswitch file.
Hopefully this necropost can be forgiven, for providing new information.
It was recently pointed out to me by @Kitrinx that the 7800 has phi0 being generated by Maria instead of TIA *and* this would impact correct RSYNC behaviour. So I gave this ROM a try via Harmony Concerto. I have the same result as you, which matches the rsync-not-properly-emulated result described earlier in the thread. (the alien is displayed quite a bit to the right of the dots eaten, walls are similarly offset from the actual player display) So I believe this result is a general 7800 thing.
Homebrewers experimenting with or otherwise relying on RSYNC should be aware of this potential issue on 7800s.
-
1
-
1
-
-
Heads up that some time ago I started a disassembly of Ken's 7800 Blocdrop game, with the intention of some day finishing it for him. While I made a good start of it (there's a fair bit of semantic info added, and it builds identically to Ken's last demo) there always seems to be more pressing hobby-business, so it hasn't moved much lately.
I decided to throw this open to anybody that's interested. If you can move the disassembly forward, feel free to do so, and add your name to the contributors at the top. Contributions can be made via pull-request, or if you don't do git, just pass on your changed file.
https://github.com/msaarna/7800blocdrop
I can't promise any recompense for any work. If carts are some day produced, it's my intention to have dev proceeds go to an appropriate charity. If there are a lot of hands in this, it won't be possible to get carts to the contributors either. But adding your effort to the project would be a nice way of honouring someone who once added light to our hobby.
-
9
-
2
-
-
It would be informative to know if it was gamepad directions (handled by RIOT) or gamepad buttons (handled by TIA) that trigger the issue. A lot of people have been using genesis controllers on the 2600, so I don't think it's a matter of of genesis controllers being problematic in general.
The only joystick pins that could cause problems by being directly connected would be pin 7 (+v) and pin 8 (gnd) - the rest could be joined together in all kinds of combinations without any sort of issue like you're describing. Pin 7 on a genesis port is the "select" line, which controls which set of buttons the controller is reporting - this is an input to the controller, so I wouldn't expect the controller to ever be connecting it to ground. So I don't believe there's anything damaging for the 2600 going on.
My best guess is that the multiplexer chip in this controller draws a bit too much current from your 2600. When you cut off the connection to pin 7, you've leaving the multiplexer chip unpowered. (a genesis controller plugged into a 2600 also gets it's power from the select line, but this is a back-fed power source, not the intended one.)
-
1
-
-
Presently only Bupsystem emulator works with it (which is the emulator bundled with the Steam release) but you need to actually choose the FoxBox.cdf file. It's sort of like a bin/cue deal, where cdf is a text file that specifies the FoxBox.bin file and also tells the emulator some extra info, like what order the music tracks are in.
If you're trying to play R&V with the beta MiSTer FPGA 7800 core, you can skip the cdf, but you need to add an a78 header to FoxBox.bin, specifying the Souper format. This can be done with the latest version of 7800header, which is in the 7800AsmDevKit.
-
3
-
-
14 hours ago, Prizrak said:Would that file be foxbox.bin?
Yes
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
7800basic beta, the release thread
in Atari 7800 Programming
Posted
The quick answer to arbitrary bitmap drawing is to use RAM-backed sprites. Basically you have a series of sprites that cover the screen and point at different segments of RAM, and you have line drawing routines that update that RAM. There isn't an easy way to do this in 7800basic right now. @SmittyB's Plink game uses pretty much this technique for dynamic backgrounds, though it's not doing full-screen bitmaps. (they repeat vertically)
That said, I don't think Missile Command actually needs bitmap display, if you just limit the number of angles the missiles can come in at. (The 2600 version doesn't pull off arbitrary angles either, and the missile aspect of the game compares very well to the arcade). Given that approach, you can just draw the missile segments with sprites. (pulling this off quick enough would likely require the Under The Hood technique)