+stephena Posted July 5, 2017 Author Share Posted July 5, 2017 I'd rather 5.0 bake for a long time. Then come out bursting with flavors and goodness It's already been baking since Sept. 2016. Any more and it will be a black spot on the bottom of the oven 1 Quote Link to comment Share on other sites More sharing options...
israelg Posted July 5, 2017 Share Posted July 5, 2017 It's already been baking since Sept. 2016. Any more and it will be a black spot on the bottom of the oven Quote Link to comment Share on other sites More sharing options...
+stephena Posted July 5, 2017 Author Share Posted July 5, 2017 Pre-release10 is now available at https://github.com/stella-emu/stella/releases. We're getting close to a new release, perhaps in a week or so. 6 Quote Link to comment Share on other sites More sharing options...
iesposta Posted July 6, 2017 Share Posted July 6, 2017 I posted a reaction because Thomas and I were swayed by thehobo's (too late) post of the source code explaining why the colors chosen originally were the colors they were. For me that was a 20+ year mystery solved. It really was hue / luminance, although it didn't appear that way because $30 is a dark red and $38 is an orange, $16 is yellow and $12 is a yellow-green, and the PF / Ball were a purple, lighter purple $D8 $DE. Next I posted that I am all for getting 5.0 out, the Stella Debug Color issue is closed, and changes would have to be made at a later date. Sorry if I continued to ramble on about colours. I tend to ramble. Getting the new TIA improvements is way more important than colors. Quote Link to comment Share on other sites More sharing options...
+stephena Posted July 6, 2017 Author Share Posted July 6, 2017 Actually, I don't think there was any real reasoning behind the original colours. It was a long time ago now, but I think they were just copied from nocash 2600, which was the emulator where I first saw debug colours. So the hue/luminance thing certainly wasn't a consideration on my part. Maybe we're looking for justification where none exists?? 1 Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted July 6, 2017 Share Posted July 6, 2017 (edited) Maybe. But giving the colors some logic is still a good idea. Personally I never liked the background being bright, so my own colors will change that. And besides debug colors a mixed mode would be good too, e.g. display main objects with their original color and objects inheriting their color with color XOR 8. That way the game still looks quite original and you can identify the objects. BTW: Any feedback about the new phosphor effect? How does it work for you? Which values look best on your monitor. And what type is it (especially the monitors response time is interesting)? Edited July 6, 2017 by Thomas Jentzsch Quote Link to comment Share on other sites More sharing options...
+stephena Posted July 6, 2017 Author Share Posted July 6, 2017 Maybe. But giving the colors some logic is still a good idea. Personally I never liked the background being bright, so my own colors will change that. And besides debug colors a mixed mode would be good too, e.g. display main objects with their original color and objects inheriting their color with color XOR 8. That way the game still looks quite original and you can identify the objects. I'm not arguing that logic isn't a good idea, just that attributing logic to its origins is probably a waste of time (since there may well have been no particular reason for the original choice). As for your other suggestions, they're not terribly difficult to do. But definitely a post-5.0 thing. Maybe add an issue for it on the tracker. BTW: Any feedback about the new phosphor effect? How does it work for you? Which values look best on your monitor. And what type is it (especially the monitors response time is interesting)? Yes, this was the main point of the pre-release, and it would be nice to get feedback on that. The default phosphor blend level will be 50%, but that may need to be adjusted for your monitor and equipment. My next step is to add the ability to set the default blend level overall, instead of needing to modify each ROM like we do now. Of course, you'll still be able to adjust each ROM individually. Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted July 6, 2017 Share Posted July 6, 2017 Maybe add an issue for it on the tracker. Since I am currently on mobile data (barely!) only, I have to be careful with my data usage (1GB/month). And just loading a GitHub issue requires more than 1.5 MB. So will probably add this (and other post 5.0 issues) later. Good idea to have a phosphor blend default setting. Quote Link to comment Share on other sites More sharing options...
Keatah Posted July 11, 2017 Share Posted July 11, 2017 So which is correct? 3.9.3 colors 5.0 pre-10 colors Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted July 11, 2017 Share Posted July 11, 2017 What hack is that? Quote Link to comment Share on other sites More sharing options...
+stephena Posted July 11, 2017 Author Share Posted July 11, 2017 I forget the hack, but I believe the difference comes from having tiadriven toggled. I'd need to test on a real system to know for sure which is correct. EDIT: Sorry, it's not tiadriven related; I was thinking of something else. The ROM seems to be the '[h1]' version of Space Invaders. Quote Link to comment Share on other sites More sharing options...
alex_79 Posted July 11, 2017 Share Posted July 11, 2017 (edited) These two roms seem to match the screenshots (they only differ for 1 byte): Better Space Invaders (Space Invaders Hack) (1999) (Rob Kudla).bin Better Space Invaders (Space Invaders Hack) (1999) (Rob Kudla) a.bin First of all, the roms are buggy, as there are a few ZP intstead of IMM loads (The display flickers like mad with the "tiadriven" option enabled in Stella), so, on rare occasions, they might behave differently depending on the particular hardware used to run the game. A "lda $4E" instruction at f1d2, fa97, fb94 loads the color value for the aliens and right score. $4E is a mirror of PF1 register and it's write only. With "tiadriven" option disbled, in stella 5.0 the resulting accumulator value is "$4E", while it's "$0E" in stella 4.x. I tested the rom on a 7800 and a 2600 jr (with an Harmony cart), and the results match stella 4.x (white aliens), while it was my understanding that in such case, the behaviour of stella 5.0 should be the most common one. Edited July 11, 2017 by alex_79 Quote Link to comment Share on other sites More sharing options...
+stephena Posted July 11, 2017 Author Share Posted July 11, 2017 I will test on my light sixer when I get home. I wish we had seen this sooner, since I was planning to release 5.0 this coming Sunday. I'll have to see what DirtyHairy has to say about it. Opened an issue for this at https://github.com/stella-emu/stella/issues/173. Quote Link to comment Share on other sites More sharing options...
Keatah Posted July 11, 2017 Share Posted July 11, 2017 What hack is that? This is the rom I used. Space Invaders (1978) (Atari) h1.bin Quote Link to comment Share on other sites More sharing options...
+stephena Posted July 11, 2017 Author Share Posted July 11, 2017 This issue is now fixed. White invaders are what's happening on all tests on real hardware, and also in other emulators. So we revert to Stella 4.x behaviour in this case. Quote Link to comment Share on other sites More sharing options...
RevEng Posted July 11, 2017 Share Posted July 11, 2017 I don't wish to sidetrack this great work, but since understanding the hardware does coincide with improved emulation... does anybody have any pet theories on why the actual bus float value is $0E instead of the last opcode $4E byte? Like Alex, I'm fairly surprised at the result. Could it be the TIA A0-A5 lines stabilize the floating data value lines somehow, leaving the higher bits less likely to show? Quote Link to comment Share on other sites More sharing options...
DirtyHairy Posted July 11, 2017 Share Posted July 11, 2017 (edited) I don't wish to sidetrack this great work, but since understanding the hardware does coincide with improved emulation... does anybody have any pet theories on why the actual bus float value is $0E instead of the last opcode $4E byte? Like Alex, I'm fairly surprised at the result. Could it be the TIA A0-A5 lines stabilize the floating data value lines somehow, leaving the higher bits less likely to show? I am just as surprised. I was my understanding that this type of undefined read would leave the whole bus undriven and thus reflect the last value on the bus. My hypothesis now is that reading will always cause the TIA to drive the highest two bits und pull them low unless one of them is specifically pulled high by the read. However, this is just a hypothesis. The only certain way to answer this would be reading the schematics but, unfortunately, I suck at electronics Edited July 11, 2017 by DirtyHairy 1 Quote Link to comment Share on other sites More sharing options...
Keatah Posted July 11, 2017 Share Posted July 11, 2017 (edited) ..or it may be a characteristic of the silicon. The schematic may say one thing, and the silicon behaves mostly as predicted, except in some corner cases. The only way to be certain is to put it on the test bench and watch the signals cycle-by-cycle. Or keep refining the models over time till the "right solution" pops up more often than not, so to speak. Edited July 11, 2017 by Keatah Quote Link to comment Share on other sites More sharing options...
Keatah Posted July 12, 2017 Share Posted July 12, 2017 (edited) Not TIA related, but.. 2 things.. Note on phosphor "mode": <alt>-O ramps it up to 100 and then maximum. And then it stops. <alt>-I ramps it down to 0, never shows "minimum", and then cycles back to 48, and then counts down again. And is Draconian title page supposed to look like this when phosphor is set to near maximum? It is the black lines I'm questioning. I'm using my own custom TV settings, but they're still there to slightly lesser degrees with the built-in RGB/Composite settings. TV effects on: TV effects off: Edited July 12, 2017 by Keatah Quote Link to comment Share on other sites More sharing options...
alex_79 Posted July 12, 2017 Share Posted July 12, 2017 The vertical black lines are definetely there on a real CRT; they're more or less visible depending on the specific console + TV combination, the brightness and color used by the program and the TV settings. You can see them on screenshots posted in the "bus stuffing demos" thread, as some of the demos use the same "interlaced flicker" technique:http://atariage.com/forums/topic/258191-bus-stuffing-demos/ Quote Link to comment Share on other sites More sharing options...
+SpiceWare Posted July 12, 2017 Share Posted July 12, 2017 And is Draconian title page supposed to look like this when phosphor is set to near maximum? It is the black lines I'm questioning. Impressive! I didn't know Stella was emulating those. As alex_79 say's, they're definitely there. I even cover that in the blog entry for the Draconian logo. There is a minor issue with the technique - due to the way TIA generates the video signal there are vertical lines in the image. Quote Link to comment Share on other sites More sharing options...
+stephena Posted July 12, 2017 Author Share Posted July 12, 2017 Not TIA related, but.. 2 things.. Note on phosphor "mode": <alt>-O ramps it up to 100 and then maximum. And then it stops. <alt>-I ramps it down to 0, never shows "minimum", and then cycles back to 48, and then counts down again. This is a bug I will look into. As for the black lines, as already mentioned, this is normal. Quote Link to comment Share on other sites More sharing options...
+stephena Posted July 12, 2017 Author Share Posted July 12, 2017 Bug mentioned by Keetah above is fixed in https://github.com/stella-emu/stella/commit/87c1d12d1d036a0adee0b1457d6755d141d9f3ed. Quote Link to comment Share on other sites More sharing options...
+stephena Posted July 16, 2017 Author Share Posted July 16, 2017 Stella 5.0 is now released at http://atariage.com/forums/topic/267810-stella-50-released. Please move all discussion to that thread. 2 Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted July 25, 2017 Share Posted July 25, 2017 Impressive! I didn't know Stella was emulating those. The lines are created by the Blargg TV Effects. BTW: There seems to be no parameter which allows disabling them. So it must be something hard coded internally. Quote Link to comment Share on other sites More sharing options...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.