RevEng
-
Posts
7,607 -
Joined
-
Last visited
-
Days Won
12
Content Type
Profiles
Forums
Blogs
Gallery
Events
Store
Posts posted by RevEng
-
-
20 minutes ago, darryl1970 said:
Did "set 7800header 'set hsc' change with an update?
Seems to be working for me, with a test program.
-
6 hours ago, TailChao said:
R34 and R35 are both series resistors on the trigger inputs (J3-6 and J4-6 on the NTSC schematic, which go to the TIA's I4 and I5). So no, this wouldn't help with the paddle inputs drifting.
Derp, you're right. I glanced casually at the schematic and mistook r34/35 as belonging to the pin 5/9 paddle inputs. So really I should have said R38/39. (and given those are 1.4k series resistors that will divide the voltage with the pull-down, I guess 20k+ would be more prudent than my original suggestion of 10k+)
-
53 minutes ago, Stechmann said:
Will these hack work with the CX78 controller?
No, genesis controllers operate completely differently than CX78. Similar hacks can't be made for CX78, because the 2600 lacks the circuitry required to read CX78 buttons independently. (and a 7800 in 2600 mode has this circuitry inactive)
-
On 11/21/2023 at 9:52 AM, TailChao said:
These are just current limiting resistors, so while you're seeing the behavior go away it's likely more of a happy accident. Same as when swapping the TIA out for another one seems to fix it. Not that I'm doubting it's worked for you - but electrically you're not doing much other than changing the behavior of an antenna without attaching a ProLine or grounding both paddle inputs.
Am I wrong in thinking that adding some high value pull-downs, say 10k+, at R34 and R35, would likely stop the wandering and allow for regular 2-button and paddle operation?
-
There's a new v0.32 7800basic release at github. Changes include:
- fix: rare unpack bug in lzsa optimisation.
- fix: spaces in basic filename hangs compile, under Windows.
(RT, there are no manual updates in this one.)
-
5
-
2
-
2 hours ago, TwentySixHundred said:
Yes it does terminate the process but that's as far as i can get. First attempt just hangs at starting build until i terminate
Starting build of StoneAge.78b...If you want to send me your project directory in PM, I can check out the 7800basic side of things. I pretty extensively tested out the 2-pass stuff, but the fact that you're running into this problem right after 2-pass probably isn't coincidental.
-
1
-
-
On 10/27/2023 at 2:00 PM, Shugyo said:
Thanks again! I'll order a couple Mega7800 when they are in stock.
Heads-up that they're back in stock at AA.
-
Chris is the authority, but I think I can get most of the list right...
- dma cycle penalty updates, which fixes visual glitches (retail and homebrew titles)
- palette accuracy updates (retail and homebrew)
- opcode updates (homebrew)
- maria render fixes (homebrew)
- pokey accuracy additions (homebrew)
- additional mapper support added (homebrew)
- ym2151 support added (homebrew)
[edit] threadpeat
[edit x2] also relevant
-
4
-
1 minute ago, raz0red said:
Sadly, the automated process was me going through line by line. 🙂 Something that would be much faster today with Emscripten (ah, well...).
You sir, are a beast 👏
-
3
-
1
-
-
I've worked with the JS7800 source a few times. My understanding is the translation of the core prosystem emulation to javascript was done by some automated process, and then fixed up and tied in to the UI after the fact. Most of the original prosystem code is there in the comments, so back-porting isn't impossible. The trick is knowing where the fixes are, which would need to be done by someone with detailed knowledge. Maybe @raz0red would be open to a gig consulting or back-porting the fixes?
6 minutes ago, zzip said:But I never understood why a7800 was not used? It's already in C/C++, runs in Linux, is available standalone from Mame
Performance. This device can't won't run the a7800 core at full speed.
-
2
-
-
(Must... not... post... about.. Dremel)
-
1
-
5
-
-
7 hours ago, darryl1970 said:
This is very cool. Is there a software used to write music for the TIA tracker? Does the TIA music tracker allow for TIA sound effects to override on of the music channels?
I have a lot to learn, especially the compression stuff. If I can only carve out the time!!! 😪
The built-in tracker uses MML for composition. MML is kind of a programmer's music composition language. There are examples in the samples directory, and the manual covers the MML syntax.
The tracker shares same TIA priority code as sound effects, so the music can play together with sounds - up to you which instruments or sound effects have priority over others. In the Salvo theme, I intentionally used a busy drum track (loosely based on the Funky Drummer riff) The notes have priority, and the beats just fit in wherever they can.
-
2
-
-
You're totally welcome! Various aspects of the 6502 aren't supposed to be reliable on power-up, so Stella is probably emulating that. Best practise is to initialise the cpu, console ram, cart-based ram (if present), and allow for power-up with any bank active. (if using bankswitching) Sometimes people will skip one or more of those, observing that it works fine on their hardware, but if you do that and your game endures, it will eventually become a headache for someone.
-
You've left decimal mode switched on somewhere. A starts off as $50, and after subtracting one, A becomes $49. That's normal decimal mode behaviour.
-
2
-
-
There's a new v0.31 7800basic release at github. Changes include:
- feature: compression and decompression commands have been added.
- feature: two-pass compile phase. Banners and tallsprites no longer need to follow their corresponding inc* statement in your source code, to work as-expected.
- feature: "set pausesilence on" directive added, to pause and silence tracker music when pause is active.
- fix: the native tia music tracker generates spurious reads to $0000.
- fix: max shakescreen with screenheight=224 and zoneheight=8 would sometimes cause interrupts to be missed.
- fix: plotsprite4 wouldn't error-out when you plot a sprite 32 bytes wide. An error message has been added.
For anybody using the lz4 compression assembly routine that's been kicking around, I'm pretty sure you'll find the new in-built lzsa has better compression (typical 10% smaller) and faster decompression. (typical 20% faster) and a slightly smaller footprint. All credit goes to the Emmanuel Marty of the LZSA project. (though I did use 7800heat to improve the 6502 decompressor speed by about 10%)
-
9
-
2
-
11 hours ago, Shugyo said:
I am wondering if a Seagull 78 with a Genesis controller would work with the 7800 controller option? I have many genuine Genesis controllers and I am looking for something that will work with the 7800 for any two button game. I didn't understand that the adapter and SNES controller can only work for Attack of the Petscii Robots and not other games.
Yeah, Seagull 78 will work with any 7800 game, including Petscii Robots.
It's not presently in stock, but my understanding is the Mega7800 adapter will be in stock soon - it will allow your Genesiis pad to work with 7800 games too, but has the added virtue of allowing upcoming homebrew games that are aware of it to use the extra buttons. (Millie+Molly, A.R.T.I., Bernie and the Tower of Doom, ...) and it will also allow Sega "Light Phaser" Lightguns to work without modification with 7800 Lightgun games. (CRT display required, of course)
Unfortunately Mega7800 came out after Petscii Robots, otherwise we would have added it as a multi-button option for the game. (but it works just fine in it's default two-button Proline mode)
-
1 minute ago, Sprybug said:
Looks like I'm going to have to do some more playing around. How many banks do you get in a 128kRAM configuration? What would be the last bank in this scheme?
There are 8 banks in 128k. Like bB, 7800basic starts counting from bank 1, so bank 8 would be the last one. There's no real developer headaches if you want to start with 128k, but later decide you need to migrate to 256k, or 512k - literally you can just change the format and renumber your last bank.
1 minute ago, Sprybug said:This would mean I would have to do the incgraphics to load them in, in that last bank. By doing so, would this mean that these graphics would be accessible by all the other banks? Kind of like how Batari BASIC for the 2600 does it?
Correct, and that's a good way to start. But you may find that last bank is just too small to hold everything you want to stick in it. If that happens, you may need to start splitting out map-specific graphics into ephemeral banks - maybe you'll have Base Area specific sprites in bank 2, and Ice Area specific sprites in bank 3, and make copies of the main loop in each.
I'm avoiding giving a solid design layout, because there isn't a one-size-fits-all layout. Start with your plan, but adjust the plan if you need to.
-
2
-
-
I should really write something up on this in the wiki
Atari's 7800 supergame bankswitching gives you 16k of rom that changes whenever you bankswitch (ephemeral banks), and another 16k of perma-rom. (the permanent, last bank in rom)
First rule - you need to keep anything that 7800basic needs for the current frame in either: the last bank, the active ephemeral bank. or ram. That goes for goes for graphics, level data, text strings, music data, etc. If you start using the interrupts (topscreenroutine, bottomscreenroutine, userinterrupt) they *need* to go in this last bank, or else bad things will happen when you bankswitch.
So you want to stick anything that's very shared in that last bank, be it data, code, or graphics. If there's something shared that can't fit in the last bank (data, code, graphics) you can stick copies of the same stuff into the ephemeral banks that that you plan to be switching between - even though that seems wasteful, this sort of duplication is normal.
For things that don't need to be shared, I like to break my banks down by game function. e.g. my title screen code and graphics go in one bank. I guess one way to judge this is if the code uses a different main loop than your game engine, it might be a good candidate for another bank. I also dedicate banks to large data structures that will be copied to ram (e.g. RMT music, level data) along with the routines that do the copying.
-
3
-
-
On 10/24/2023 at 12:49 PM, zzip said:
So if I summarize those statements as 320 mode is easy and advanced programming is not required, it doesn't seem like I'm that far off base, because every time I say otherwise I get challenged
Only that wasn't the entirely of your claim...
On 10/23/2023 at 4:31 PM, zzip said:Scroll back in this very thread. I was told that even 320 mode is easy on 7800 despite all threads created by people struggling with it and a relatively small number of games making good use of it. No advanced programming required unlike other systems. It's just lack of spending that caused inferior 7800 ports.
I made the statement that 320 mode on the 7800 isn't difficult on the 7800. You just need to take the time and learn the rules, and that's no different than any other system of the era. That doesn't merit a summarising of "320 mode is easy on the 7800" without my qualifications. It's a stupid statement without qualifications, because it's not easy for children or animals. Using 320 modes would not be difficult for a professional game programmer in the 80s, because they're already need to work within rules for systems they know, and it's the same situation here.
Then you add the "unlike other systems" claim, which is the complete opposite of what I've been saying all along. I'm moving on from this meta discussion, because now you're not only dropping salient points from my posts, you're now dropping assertions that you yourself made as you try to defend statements. Life is too short for these kinds of games.
-
3
-
-
On 10/24/2023 at 1:38 AM, Bakasama said:
I’m still trying get how 7800 graphics work, I get how 2600 draws per scan line with very little RAM and how CPS2 and Neo Geo draws their sprites, more or less. The 7800 seems be a real beast with sprite handling.
If it helps, you can conceptualize Maria's operations in a couple of ways. Both are accurate, but depending on your understanding of other systems, one may resonate with you better than the other...
First, you can think of Maria as a soft-sprite accelerator on steroids. You hand it a list of sprite (and character) parameters (graphic data location, x, width, palette, mode) and it runs through the list and composites all of the sprite and character bitmaps for you. There's another level of detail to this explanation, due to the fact that Maria only has two on-chip scanline buffers. (one buffer is used for displaying the current scanline to the TV, the other used for generating the next scanline coming) Maria's bitmap compositing happens on a scanline by scanline basis, so you need to give it multiple parameter lists (aka Display Lists) covering different horizontal strips of the screen.
Second, you can think of Maria as a blitter chip, only unlike other blitter chips it doesn't run in parallel with the cpu. Instead it halts the 6502 when it needs the bus, and copies over graphics data at 4x the normal 6502 clock. (with no time wasted fetching opcodes or processing loop logic, like the 6502 would need) The extra level of detail I mentioned earlier, about Maria having a scanline-buffer, applies here too - the blitter operation is repeatedly triggered for each scanline prior to it being displayed by the TV, rather than the singe blit to a full-screen ram destination you might see in other blitter implementations.
It's worth pointing out here that one of the explicit GCC design goals was for the console to run Robotron well, and the Robotron arcade game has a blitter chip for compositing graphics. (as does Joust and Sinistar)
-
4
-
-
15 hours ago, zzip said:
Scroll back in this very thread. I was told that even 320 mode is easy on 7800 despite all threads created by people struggling with it and a relatively small number of games making good use of it. No advanced programming required unlike other systems. It's just lack of spending that caused inferior 7800 ports.
Defender_2600 commenting about cycles being something that had to be checked for Xevious in 160B mode literally didn't have anything to do with 320 mode at all. And before you infer some grand weakness, 320 mode doesn't use more cycles than 160 mode - 320 trades color for resolution, not cycles.
The fact that you're paraphrased what I've said as "even 320 mode is easy on 7800" and "no advanced programming required unlike other systems" is either delusional or a bad faith strawman. Since you decided to mischaracterise what I said, rather than cite, I guess I'll need to do it myself...
On 10/19/2023 at 5:06 PM, RevEng said:Here's the thing. There are certain, very clear, rules about using color in 320 modes. 160 mode is simpler, but not in some "oh my god, 320 mode is impossible!!1!" kind of way. It just takes a little bit of understanding and planning.
On 10/19/2023 at 6:52 PM, RevEng said:It's not difficult, you just have to follow the rules of the mode. It doesn't take some exceptional elite coder guru to follow those rules. As I already pointed out, we have a non-programmer non-hardware guru regularly demonstrating a perfect understanding of them. Every console has rules and constraints you need to adhere to, and this one is no different.
I'm likely gonna blow your mind here, but NES coders also have to understand their hardware and follow the rules.
On 10/20/2023 at 12:04 PM, RevEng said:This is true for any given system constraint or rule, on any console. There is no console from the 80s where any game design choice can be made without regard to the console hardware - even your imagined super 5200 successor would have had them. Ask an NES dev how simple raster interrupts are on their platform (without resorting to advanced mapper hardware) or how they add together BCD numbers for score display.
Show us on the doll where the 7800 console touched you.
-
2
-
3
-
-
On 10/21/2023 at 11:52 PM, Shugyo said:
Thanks for the information. I would not expect the adapter/controllers to work properly on a 2600 but I figured that it might tell me something if any of the buttons worked. I understand that the cx-24 was supposed to be designed to be compatible with the 2600 so I figured it might at least tell me if the problem is with the controllers or the adapter. With the information six and you supplied, I think my next step will be to test the adapter with my multimeter. If everything looks good, perhaps the issue is with the SNES Controllers. I forgot to mention that I don't have an SNES to test them with so I might just need to return them and try another set from a different manufacturer.
To rule out a problem with whichever console port you have them plugged into, try the snes2atari in the other port. (with 7800 Petscii Robots, of course) The game will autodetect the control and use either port.
A multimeter test isn't going to be very instructive. The SNES controllers talk to the console through a serial protocol, unlike controllers from Atari.
Are these SNES gampads from Nintendo, or some third party manufacurer? We tested the game with a pretty wide variety of SNES controllers, both first and third party, but obviously not every third-party controller that ever existed.
-
31 minutes ago, zzip said:
I know this, but I keep getting told it doesn't apply to 7800
As for bumping the system limits: Xevious was a 1982 arcade game, it should not require bumping the limits of a true late-80s console.
Who told you that the 7800 doesn't have resource limits you need to not be careful of exceeding?!? Citation, please.
NES didn't manage an arcade-perfect Xevious port either - it looks worse than the 7800 port from my perspective - despite your pet theory about it being easier to get amazing results from the NES without difficulty. It's almost as if dedicated arcade hardware from 1982 could push console tech from 1984 to the limit. So strange.
-
3
-
-
15 minutes ago, zzip said:
Yet you keep insisting that graphics on the 7800 is easy and straightforward. This is exactly the kind of thing I'm talking about when I say "advanced" techniques. To me "easy" graphics doesn't require counting CPU cycles or needing well-optimized code to get desired results.
You only need to "check cycles" (or test a design on real hardware or emulator, which is what most devs do instead) when you're pushing the game display so hard that you're in danger of bumping up against the system limits - it's not a factor in most games. When you're pushing the limits of other consoles, you also need to be sure you're not exhausting the resources involved. Even the NES! 😱
But by all means, confirm your bias again!
-
3
-
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
How about an Atari 2600+ portable?
in Atari 2600+
Posted
🤷 It seems to be stated in the official MiSTer FPGA FAQ...
MiSTer will never use physical cartridges.
The project aims to replace the need for having original hardware for the same experience. It is also physically impractical/impossible given the number of GPIO pins available from the FPGA.