RevEng
-
Posts
7,612 -
Joined
-
Last visited
-
Days Won
12
Content Type
Profiles
Forums
Blogs
Gallery
Events
Store
Posts posted by RevEng
-
-
I'm going to take a shot in the dark and guess it's a ground loop issue. If you have a sacrificial cable, you can remove ground connectivity from the end that plugs into the retrotink. I guess you could even avoid sacrificing a cable by using some thin paper or plastic shimmed between the rca male and female to isolate ground. If symptoms improve it will tell you that ground loop is the problem.
The usb charger is probably putting out switching noise in the mhz range, as they all do to some degree, but I wouldn't expect that to only affect chroma, so it's a less likely candidate.
-
1
-
-
49 minutes ago, Karl G said:
1) I wouldn't post any more about what you may or may not do for a Knight Rider project until you have at least some small amount of working code
The lack of working code I can live with. It's the lack of quotes from Moby Dick that's the real problem.
-
3
-
-
1 hour ago, Crazy Climber said:
Nah dude, at this point is HAS to be everything @HardWork promised us or nothing at all. Some generic driver in batari basic with the knight rider name slapped on it will simply not do 😆
How about a knight rider pac-man clone? You know that's what the suits would have asked for, back in the day.
Here's my earlier comment, which matches your sentiment. I'm quoting it for easy access to the HardWork design docs...
On 3/2/2023 at 12:03 PM, RevEng said:-
1
-
2
-
-
One more thing... for anybody using "underthehood" techniques, the underthehood sample now has a "updateobjects4.asm" assembly file suitable for 4-byte sprites.
-
3
-
1
-
-
50 minutes ago, Muddyfunster said:
That's what I was hoping
will be testing this on Bernie this weekend. Thanks for the update Mike.
A couple sharp edges I forgot to mention...
- 4 byte sprites can "only" plot objects up to 31 bytes wide. I'll update the manual and get the compiler to throw an error if someone attempts this.
- The PLOTSPRITE/PLOTSPRITE4 commands are limited to sprites that are 16 bytes wide - I can extend those if necessary, but it already seems excessive, given the purpose is to loop and plot a ton of sprites efficiently.
-
5
-
1
-
Excellent - thanks for the testing and typo report!
I tried out the four byte sprites in Salvo, with similar results. The reduced DMA isn't the biggest boost if you're not already pushing the limits, but if it's free, so you may as well. I think where it can be really useful is for designs that use sprites as tiles. That's pretty much what I did for the Petscii Robots tile display, though I built the four byte sprite objects via manually crafted data tables.
-
3
-
-
There's a new v0.30 7800basic release at github. Changes include:
- feature: integrated project backup.
- feature: plotsprite4 command added, for generating 4 byte DL objects.
- feature: PLOTSPRITE and PLOTSPRITE4 commands added, for more efficient looped sprite generation.
- fix: throw error when plotchars doublewide exceeds 32 characters. (which exceeds the screen width)
If you're not regularly backing up your game projects, I urge you to do so now. We've had two developers lose mature projects due to hardware failures in recent history. A thumb drive attached to an unused usb port is a cheap and easy insurance policy.
The new backup feature will create a backup of your basic file, included images, mapfiles, and rmt files, every time you compile your game project. The backup goes to a location you specify in your source code. You have a choice of replacing the previous backup with the new one (single mode) or keeping a running history (running mode)
The sprite related updates are useful for better efficiency, provided your game design can work with their quirks. (see the "Advanced Spritework" part of the manual). Using 4-byte sprites allowed me to upgrade the 69 Sprite Demo to 86 sprites, thanks to the reduced DMA 4 byte sprites have compared to 5 byte sprites.
-
10
-
1
-
40 minutes ago, john_q_atari said:
That picture is soo fake!
<puts on nerd hat>
By my rough calculations the coffee alone in that cup would weigh over 800 pounds.
</still a nerd>
Totally not fake. There's no banana for scale, but i'm quite certain he's just really really small.
Since he has an arm span of about five keyboard keys, it does really explain the game development delays.
-
2
-
-
14 hours ago, Albert said:
Not sure if that's TIA or POKEY audio off the top of my head.
The text click is TIA audio.
-
2
-
-
4 hours ago, rhuneke said:
What will AtariAge do with the leftover unsold physical cartridges (boxed or just manual and cartridge) that were never sold and had to be removed from the AtariAge store because of the acquisition of AtariAge by Atari.
Lets just say a certain New Mexico landfill has a few new mounds.
-
9
-
-
My pleasure! I didn't know that about the Jaguar... the Maria design started out as a co-processor for gcc's aborted "spring" ibm pc compatible. I always wondered what that would have looked like, so it's cool to hear that some of the ideas did make it to a more powerful platform.
-
6
-
-
57 minutes ago, Stephen said:
Excellent demo. Would it be possible to use this colour palette (from the 8-bit, I believe this was done in Graph2Font).
That's very cool, and it's possible to get something close to that, but it would cost a few sprites - maybe 4 or 5.
The main point of the demo is made, and I'm ready to move on from this one for now, but I may revisit it with your suggestion at some point.
-
2
-
1
-
-
Last time I do this, but I've updated the demo in the first post. I had left some DMA on the table in the original "sixty-nine" demo, and after fixing that up, I have 86 animated sprites instead. Not so "nice", but I figured having the extra sprites was worth spoiling the joke.
-
8
-
1
-
-
Thanks for all the nice words on this one, guys! I wasn't expecting a whole lot of feedback for a tech demo, so it was a pleasant surprise.
I've included the source for the demo in the 7800basic samples directory, in case anybody is curious.
-
9
-
2
-
-
Apparently some fans of other consoles see my 7800 "101 sprites demo", and conclude that a large number of sprites is only possible when the background is black/solid. It's the same old shared-bus cycle-stealing rhetoric from people that haven't coded anything for the 7800. They look at a single 7800 wiki page, stay at a Holiday Inn Express, and all of a sudden they're 7800 gurus who "know" it's impossible that the console has any useful strengths.
As a response I put together this
Sixty-NineEighty-Six Sprite tech demo, which has 86 animated sprites, a detailed background, rmt music playing, and a scroller. Enjoy!Play it live in your browser thanks to JS7800! (if it doesn't play music, hit the reset button - some browsers mute sound until you interact)
Or download it to play in your favourite emulator or flashcart...
[rom update 1 - changed one of the sprite palettes]
[rom update 2 - fixed the spelling of Gollum. Whoops!]
[rom update 3 - updated from 69 to 86 sprites]
[rom update 4 - minor typo]
-
24
-
2
-
2
-
-
The other thing about composite artifacting, is it happens in the 160 resolution too, just less strongly. From the 7800 color documentation wiki entry, here's an example of artifacting colors from two different composite displays...
...from left to right, the first two colors are produced by alternating light and dark pixels. The second (striped) set of colors are produced by alternating pairs of light and dark pixels. (i.e. 160 resolution). This is part of the reason why graphics seem a bit more sterile when displayed on an emulator with lcd vs console with composite device.
-
3
-
-
3 hours ago, Karl G said:
Okay, thank you, that clears up a misconception I had nicely. I had thought that pixel pairs were only defined based on 160 pixel coordinates.
For 320 and composite artifacting, no.
There are color restrictions on 320 color modes that do get impacted by the 160 mode grid. (easier to think of it as 320 mode pixel pairs) 320A does have a pixel pair quirk, but it manifests with transparent pixels paired with lit pixels showing up as background color instead of transparent. It's usually a very subtle effect, though you can amplify it if you try hard. (e.g. use a bright background register color, and paint background tiles dark)
-
3
-
-
1 hour ago, Defender_2600 said:
Yes I know, one of those people is me (
) and, in a superficial way, I am generally only referring to what will be seen on the screen without explaining how it is happening (and I would do it wrong).
[...]
Anyway I apologize if I'm not considering artifacts when I show my graphic examples.
No apologies needed. I don't expect everybody to hobby the same way I do, and ignoring composite artifacting is a perfectly valid thing to do.
On your topic of a post-composite world, my own view is a display that's incapable of composite artifacting is deficient for retro consoles. Tower Toppler and Rikki+Vikki use composite artifacting for color. I used composite artifacting in the Petscii Instruction screens for a splash of color. Even when composite artifacting is accidental and ugly, I still want it displayed that way on my screen, because that's how it truly would have been seen back in the day. For me, bypassing artifacting feels like an artificial enhancement, along the same lines as using a pixel art scaling algorithm in an emulator.
-
2
-
-
It's worth spelling out that the shared bus impacts the 7800 resources in two ways... The first impact is lost cycles for the 6502, and the second impact is the shared address space, which limits the amount of graphics you can arbitrarily display in any one zone.
As Trebor pointed out, Souper and Banksets remove the second impact entirely, since Maria gets a separate address space of graphics rom, independent from the 6502.
The first impact is less of a big deal once you get to working with the 7800. You pre-bake stuff into the DLs to allow minimal updates. You use frame buffering so you don't have to partition cpu time into visible and non-visible buckets. You schedule events when needed rather than running them every frame. You optimise, pre-compute, and get a little clever about how you do things.
The 7800 port of Petscii Robots has nearly the whole screen's worth of 6502 cycles lost to dma, but it runs about as fast as other Petscii Robot ports on systems without DMA penalties. Those other systems aren't holding things back - they're running flat out. We just had to optimise things a bit.
I'm sure I'm coming across as cranky, but I get tired about reading about how terrible the shared bus is - the nes pundits like to bring it up a lot whenever one of these stupid vs threads comes up. Its kind of like complaining about how hard it is to keep a motorcycle upright at slow speeds, and concluding that cars are therefore better. If you personally have trouble keeping the bike upright, then I guess its true for you. A whole lot of us are managing to stay upright just fine, and doing it in style. 🤷
-
4
-
1
-
-
4 hours ago, Karl G said:
What I don't understand about using 320A and 320C modes is that it seems that the only way to avoid artifacting is by treating the 320 modes like 160 modes. It seems like if I understand correctly, having a pixel pair where one pixel is a foreground color and the other is background, then there will be artifacting.
Yes and no. Here's a diagonal line that avoids artifacting, while still using 320 resolution...
-##----- --##---- ---##--- ----##-- -----##-
...it's also an option to just ignore it and tell people that your game may artifact with composite video. (s-video won't, nor will component from 7800gd, MiSTer FPGA hdmi, etc.) That one doesn't sit right with me personally, but tbh i think I'm the odd man out, and most homebrew authors don't really think too much about composite artifacting.
-
3
-
-
2 hours ago, zzip said:
a7800 is used by Atari on the VCS, I don't see why they'd switch to something else for 2600+, unless forced for technical reasons.
Ah, I did not know.
If they do the same here, the only nut to crack is cart format detection, since there's no a78 header in a real cart. It should be possible to actively probe for ram in-cart, probe pokey at the common addresses (assuming it's not a write-only pokey) and try some common bankswitch schemes.
-
On 8/25/2023 at 1:11 PM, DanBoris said:
And if it is using Stella, I wonder what it is using for the 7800 emulation. Would like to know if any of my code is in there.
2 hours ago, hizzy said:Does anyone know how it's doing the 7800? Stella doesn't do that.
The choice of 7800 emulator is certainly make or break for the 7800 aspect of this device. If they go with a Prosystem emulator, homebrew compatibility will be poor and glitchy.
I'd rather see a7800 emulator used. It was forked from Dan's original Mame a7800 driver, and is nearly cycle accurate at this point, allows for mid-scanline graphical changes, has faithful pokey emulation in it's most exotic modes, ym2151 emulation, etc. But 2600+ doesn't seem to be concerned with homebrew, so I won't hold my breath.
-
5
-
-
5 hours ago, DanBoris said:
... and I thought 16 bits would be plenty.
Yep. I guess it's a good problem to have. Lots of hardware development going on, on our little platform.
-
1
-
-
Also advise if you're using pal or ntsc consoles.
-
3
-
will be testing this on Bernie this weekend. Thanks for the update Mike.
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
2600+ w/7800 support
in Atari 7800
Posted
How about the for-profit company do it for their product, instead? This isn't rocket science - the source code is all there, and thoroughly commented. One could back-port the a7800 driver improvements to an earlier mess code-base (the mame4all approach) or port them to prosystem. (basically what I did with the a7800 pokey driver, for js7800)