RevEng
-
Posts
7,607 -
Joined
-
Last visited
-
Days Won
12
Content Type
Profiles
Forums
Blogs
Gallery
Events
Store
Posts posted by RevEng
-
-
4 hours ago, batari said:
Regardless, I can change this to give the Activition bit priority over the Supergame bit. But, if this A78 header change is actually an error (bits 1 and 8 both set) and not a part of some specification change that I am not aware of, perhaps the Activision game(s) can be corrected as well.
I'm pretty sure the two bits being set in the latest propack Activision roms is a mistake or misunderstanding. We haven't had a community discussion on Activision header bits, and there isn't a logical reason to flag a rom as both supergame and activision. As you noted, they're mutually exclusive.
-
1
-
-
If you haven't done so already, check out the music tracker section of the manual. That goes over the moving parts in detail, and the tracker sample should hopefully help with implementation questions. (and you can always ask here too, of course)
-
1
-
1
-
-
1 hour ago, SmittyB said:
As somebody who has no experience writing music or using trackers the 7800basic tracker has enabled me to make some pretty cool sounding things that I'm proud of. I'll happily post the source for any of them if somebody's interested.
I'm very happy to stand corrected
-
6 hours ago, bsteux said:
Hi,
May I use your soundtest library to make a TIA sound example for cc7800 (keeping your copyright obviously) ? These sounds are very cool... Are they all generated with sound2tia ? The pitfall ones for instance went through your tool or from disassembly of the game ?
Help yourself! As to the copyright, consider the program and sounds to be public domain, or equivalent in jurisdictions that don't allow new works to be placed into the public domain. Anybody can do anything with them.
A few of the sounds were hand-crafted, the Adventure and Pitfall ones were lifted from the games by just watching the audio registers change in Stella (set a trap in the debugger and record what values are written each frame), but the bulk of the sounds come from sound2tia conversions. TBH getting good stuff from sound2tia is much more miss than hit, but often enough I'll get something unexpected and more interesting than the original. The sound2tia ones are generally more organic sounding, which has its ups and downs - I sometimes have to clean them up by hand, as there's often a glitch here and there.
It's not featured in any sounds in the library, but i have another technique for copying sounds from arcade games that I've found very effective. I get a WAV capture of the sound, and then using Audacity I time stretch the sample 10x or so while retaining the same pitch. Then I do a spectrum analysis on any unique segment to pick out the fundamental frequency. From there I just use a TIA frequency table to generate the sound, and my own ears as to which distortion would match the original.
-
7
-
-
4 hours ago, Defender_2600 said:
Just wanted to bring this to your attention, could TIA do something like this?
Something fairly like it, sure. The smooth glissando, especially with the higher voice, isn't going to happen. But with some voice priority code, you could slip in a beat track, like the original composition has.
-
1
-
-
3 hours ago, Gemintronic said:
There's trackertest.bas. So, is this what people use to create and play TIA music in their homebrew?
I downloaded 7800basic-0.24-ALL.zip and looked at the samples folder there.
So far just it's just me and @Revontuli using the built-in tracker, I think.
The rest of the folks have either used the same stuff they did in bB, or have opted for Pokey music.
-
1
-
1
-
1
-
-
On 6/8/2023 at 9:00 AM, SainT said:
@RevEng if you wouldn't mind doing the honors on the 7800header code to add the extra feature set bit when you get a chance, please!
The only limit is this feature doesn't cohabit with the Souper Mapper. It basically implements the same functionality but at a different address space to allow more modular use.
I've added the adpcm@420 flag to 7800header, and added a corresponding comment to the a78_asm_header file.
-
1
-
1
-
-
Without digging into the assembly (again) I'd say what you're seeing is expected. Each line of the kernel relies on precisely timed updates to change the player graphic values. If you put in 2 WSYNC hits at the top of the loop, you're instructing the 6502 to sleep for the rest of the remaining line (fine) and then go to sleep again for another whole line, skipping those precisely timed graphics changes. (not so fine)
-
2
-
-
On 6/5/2023 at 5:14 PM, Gordon Fecyk said:
I wonder if the existing ROBOTS ports could be adapted to use SNES2ATARI instead. Use a SNES controller on a Commodore 16 for instance, even with no user port.
With the disclaimer that I'm not a Commodore guy,...it seems the CIA can set the joystick lines hi or lo, so it seems possible.
-
3
-
-
Just now, Trebor said:
A SNAC adapter takes an original controller and allows it to be connected via USB under a USB SNAC board.
Not that Snac adapter, the other Snack adapter.
But the answer holds. Snes2Atari is an original design (by @Danjovic) that differs from Snack. Snes2Atari reads the snes buttons serially. Snack feeds the button info to the console via the paddles lines. Snack works great on a platform that has a dedicated AD converter for paddle lines, but not so great on consoles that use caps and charging times to measure paddle position, like the 7800 and 2600.
-
5
-
-
Sorry about that. It looks like the bB header file usage needs to be cleaned up a bit to keep recent versions of gcc happy. When I get a chance I'll take that on, and advise here.
[edit - this was fixed. bB should now compile fine with recent versions of gcc]
-
1
-
1
-
-
Short term, I don't have cycles to look at setting up a new cross-compiling and testing environment. Longer term, I'm open to it.
For now you can build the bB CLI tools from source on the pi. i.e...
- setup a basic development environment on the pi with "sudo apt-get install build-essential"
- download and unpack the source package from the github release page
- change directories to where the source package was unpacked and type "make".
- setup the expected PATH info by typing "./install_ux.sh"
You'll also need dasm installed. The raspbian version of dasm looks current, so you should be able to just "sudo apt-get install dasm" for that.
-
1
-
13 hours ago, KrunchyTC said:
Does having an external sound chip save on CPU cycles at all?
Nope, being external doesn't have an effect on CPU cycles. Depending on how the chip paradigm and/or number of voices, it may take more cycles to drive than TIA. (or in the case of a chip with tracker built in, fewer cycles than TIA. AFAIK this only applies to the microcontroller sound-chip in the Rikki+Vikki homebrew)
13 hours ago, KrunchyTC said:Also, how much does the TIA cripple the performance of the SALLY chip? Do you have to access the TIA chip very frequently?
The usual way of driving TIA audio is to update it's 6 registers once a frame. A simple tracker might use a few dozen cycles. A very complicated tracker might use a hundred or so. Even with DMA the average game will have ~10000 cycles, so this is a drop in the bucket.
Driving TIA more frequently to play PCM audio is different, since you're likely hitting TIA over hundreds of times per frame. But that's not a common requirement for games.
13 hours ago, KrunchyTC said:Also, is it a significant issue to not have the ability to have both the CPU and graphics chip to access memory at the same time? Does that mean that there is a performance penalty by default? Is that what DMA is? Why would GCC go with such a design?
Yes there's a penalty, and that's what DMA amounts to. (Direct Memory Access - when a non-cpu device takes over access to the memory bus) Having shared memory would complicate the design quite a bit ($$$) especially given that Maria runs considerably faster than Sally's top speed.
The reason for going with such a design, was to maximise what the 7800 is capable of at the intended production cost.
DMA as an approach in itself isn't unorthodox. The Atari 8-bit computers do the same - the Sally CPU with the necessary halt line was developed for those computers, and repurposed for the 7800. The DMA penalty is smaller in the computers because Antic is doing less Sally halting than Maria does.
CPU is the typically most constrained resource in this architecture, but it's less of a big deal than you may think. Not every game task needs to happen every frame, so you can claw back time by scheduling things only when needed, rather than when convenient, and then balancing that scheduling. Further, algorithmic improvements can get you far. (see my previous comments on Petscii Robots)
-
4
-
-
On 5/9/2023 at 10:00 AM, Karl G said:
Where can I find the updated .bas that corresponds with the version in the js7800 link? The source in the first post as well as in github has 116 sound effects, whereas the version in the js7800 link has 183 different effects.
I goofed. It's actually just 116 sounds. I've corrected the first post to include the correct tally.
I fooled myself that it was a hex tally in the gui, due to the high nibble incrementing past the decimal range. 🤷
-
2
-
-
54 minutes ago, ZeroPage Homebrew said:
No Video on Atari 7800: The Sequel!
Well, it happened again and this time it looks like for good! [...]
Good luck with the investigation!
-
1
-
-
Heads up that I've updated the assembly header and 7800header with the multi-region flag and mega7800 controls.
-
3
-
1
-
-
Sounds good to me. I should be able to take on the assembly header and 7800header updates this weekend.
-
4
-
-
Of the higher-requirement emulators, I've played around with Xemu, Yuzu (switch), Cemu (wii u), Dolphin (gc,wii), and Citra (3ds). I'm running a Ryzen 5 5500, which is a modern capable-but-budget cpu.
There's a mantra that modern emulation is cpu dependant, which is mostly true, but in my experience with Xemu and Yuzu I went from unplayable framerates (on my desired games) to full framerates by switching from a very potato gpu (gt 1030) to a somewhat less potato gpu (rx 550). So emulation is cpu dependant, so long as it's not gpu dependant.
My older gpu is more capable than the highest Intel integrated graphics, and pretty close to on-par with the current highest AMD integrated graphics. IMO it's better to budget for a discrete gpu if you're looking at higher end emulation, though there's nothing wrong with starting integrated to see what you can do with it, and then upgrade later if you need it.
The latest lifehack for budget gpu gaming is to pick up a second-hand RX 580 8G for less than $100. (almost certainly ex-miner gear, so buy on a platform where you feel safe to return) The 580 more than capable for emulation and has the required API support. It's likely that driver support for the 580 won't last a whole lot longer, so if you're also looking for modern AAA gaming, it might be better to stretch for something more modern and powerful. (a 580 will play almost all current AAA titles fine at 1080p and mid to low visual settings, though it's days are probably limited here too.)
I agree with TwentySixHundred that diy is a good way to go, especially if you're interested in keeping up with modern gaming. Ex-business PCs are fantastic value, but they have limits, and if your needs exceed those limits then expansion is either impractical, expensive, or impossible. e.g. the power-supplies and motherboards typically have proprietary connectors, physical space limits what gpu you can use, limited ram slots, etc. When you outgrow one of these systems, you can't salvage the case, power-supply, motherboard, cooler, etc., unlike a diy system.
Last point - some games are heavier than others on any given emulator. However much you spend, there will be some game that you try to run that will disappoint you. The emulators I mentioned, with the exception of Dolphin, aren't perfectly optimised and have games that won't run well, even on top-end PCs. (God of War III on RPCS3, I'm looking at you) Of course, there are also a bunch of games that don't run at all.
-
1
-
-
Yeah, we cut out the 32-bit build for windows after 4.0. I believe there was a build system replacement, and since all of the Windows 32-bit OSes have reached end of life, dropping 32-bit just made life easier.
-
1
-
-
Yay, more dev tools for the 7800!
Looking forward to seeing how this develops!
-
7
-
-
Looking at the circuits, it seems to me that the audio and video at the expansion ports could have been input or output, depending on how the device connected to it worked. e.g The audio is resistor-mixed from TIA+POKEY, where it branches off to both the expansion port and the RF mixer. Injecting an audio signal, with a corresponding resistor-mixer would have worked, but equally the expansion device might mix it's own audio with the console's audio and present that to it's own audio output.
Composite video is more complicated, since you can't just join together one composite video source with another. The console and the video source need to be genlocked together. i.e. one device needs to line up it's sync with the other. Maria has no way of adjusting her sync, so the device on the expansion port would need to adjust it's timings via the sync signals on the expansion port. The synced video device signal could technically be fed into the console via the composite pin, or like the audio, the external device could have taken the console's video as input. Since all of Maria's video signals are also on the expansion port, the device could have mixed those together itself instead.
Since the expansion port allows for a bit of everything, I think they were probably hedging their bets with the design.
-
2
-
-
The public version of ChatGPT uses GPT3.5. Bing chat uses GPT4, and does a bit of research before answering and has an improved model. It seems a bit more accurate, gives citations, and is a bit less prone to making stuff up.
I don't think Space Treat is one of Andrew's, but if I check the reference it gave, there's an acknowledgement credit. That's forgivable.
I thought the above was a bit matter-of-fact, so I asked for more output...
These things are only going to get more and more capable, from here on out.
-
1
-
-
On 3/25/2023 at 8:37 PM, John Stamos Mullet said:
The central argument here seems to be that David Crane and the Kitchen brothers turned up their noses at their work being referred to as, or equated with "homebrew".
If that's your summary, it looks like the central argument has gone completely over your head. I'm going to assume you're still arguing in good faith, and try to spell it out a little clearer...
If someone says they don't belong to category [X] because they have attribute [Y], it means they think that attribute [Y] excludes anyone from belonging to category [X]; that leaves category [X] with nobody possessing attribute [Y].
If I say that I'm not a Jaguar fan because, among other things, I bathe regularly and have manners, it speaks volumes about the negative beliefs I have about Jaguar fans. Saying that I was only talking about myself, and that I was just proud of my good hygiene and my disciplined brain - however true it might be - doesn't mean I didn't slight Jaguar fans.
If you want to give Audacity a pass because they're your childhood 2600 heros, then good for you. For the record, I give them a pass too. Not because there was no slight given, but because there was no slight intended - they just cluelessly revealed their insulting beliefs. Sorta like when you give your grandparent a pass after they reveal some horrible and outdated belief, and you just cringe a bit and hope they don't repeat it in public.
All of these arguments about rock bands and professional athletes have completely missed this point. Nobody took offence that Audacity didn't consider their game a homebrew. People may have disagreed about that, but it wasn't offensive. People took offense at the insulting inferences that Audacity made about homebrew in general.
-
13
-
-
7 hours ago, Tempest said:
Thanks for all the investigation on these. Is the code for 10/14/88 or 11/18/88 compilable or is something missing from those archives?
It looks to be complete, but the assembler syntax differs from dasm a fair bit, so assembling it would take a bunch of translation work.
There is an interesting bit of source in the 10-14-88 source directory, namely the AB1.S and AB2.S files. These aren't a buildable game or demo (there are other files they rely on that aren't present) but these two files appear to be part of an "Airball 7800" port. (perhaps this Airball)
Here's the header at the top of the files...
; **** (C)1988 Property of John Boeschen & Co. **** ; **** Source Code - Airball 7800 ****
Often enough programmers will copy over existing source into a new project directory, to have all of their handy routines ready to copy and paste or adapt. I expect the author did so here
-
1
-
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Concerto Enhancement Module #0: test results and ongoing impressions
in 7800 Concerto Multicart Support
Posted
This entirely the cause - a 7800header bug, where running "fix" with an "activision" cart causes the spurious supergame. So this one is on me.