Omegamatrix Posted September 27, 2020 Share Posted September 27, 2020 I made a few 36 character demos a while back. One of them was an interlaced 36 character demo, which is good for CRT's. Orange808 found an issue though with it on his consoles. When looking at the glitch it was obvious that it was 1 pixel off due to unusual positioning sta.w HMOVE ;4 @73 early hmove, HMP0 = $40 (left 12) sta RESP0 ;3 @76 strobing after HMOVE! On his console it was one pixel to the right of where it should have been. To fix it I used HMP0 = $50 (left 13), and then added in an auto-detection routine for it to differentiate between consoles. I have since made a couple of demos for the display. One is a 1008 character demo (perhaps the first time for over 1,000 characters on the 2600?), and the second is 576 character demo which is taller digits. On my LED TV they don't look too good, but if you have a CRT they might be okay. Toggle the left difficulty switch to scroll the letters or keep them stationary. 1008Char.bin 576Char.bin 16 Quote Link to comment Share on other sites More sharing options...
Prizrak Posted September 27, 2020 Share Posted September 27, 2020 Amazing work, crazy how much the system can handle. Sent from my SM-T727V using Tapatalk Quote Link to comment Share on other sites More sharing options...
Omegamatrix Posted September 27, 2020 Author Share Posted September 27, 2020 Thanks! Thinking about the roms I posted though I realize the autodetection might not work for the top row as I don't do the funky positioning before checking the result. But these are just proof of concepts so no biggie. Quote Link to comment Share on other sites More sharing options...
+SpiceWare Posted September 27, 2020 Share Posted September 27, 2020 Impressive! 576 looks best, less apparent flicker than 1008 due to the doubled-up vertical pixels. During the development of the 32 character text display I found a 3x4 pixel font, which with I think you'd get 1188. Just for grins I filled part of the font table with $F0 to see if it was suitable for a 144 pixel display, guess not. Impressive nonetheless! Quote Link to comment Share on other sites More sharing options...
Omegamatrix Posted September 27, 2020 Author Share Posted September 27, 2020 26 minutes ago, SpiceWare said: 576 looks best, less apparent flicker than 1008 due to the doubled-up vertical pixels. During the development of the 32 character text display I found a 3x4 pixel font, which with I think you'd get 1188. Yeah, looking at your screen the height of the doubled up looks good. The flicker could definitely be reduced as I'm flickering $xE on $x0. Going down from $xE will make it less bright but also flicker less. The four pixel font is interesting, but I think it would be most effective as a mixture of upper and lower case as one aphabet set, i.e. never use upper case B because lower case b is much more readable. 26 minutes ago, SpiceWare said: Just for grins I filled part of the font table with $F0 to see if it was suitable for a 144 pixel display, guess not. Impressive nonetheless There are certainly gaps. With the interlaced display I use a black background as there are HMOVE bars every second line. To help mask them I use PF0, but I am also using the Ball to mask a pixel in the kernel so the background is black. Each row can be any color though. The non-interlaced 36 pixel display I made can be any background and row color. It shows a lot better on my LED TV than the interlaced version, but on a CRT it looks worse for flicker. On my LED TV the interlaced version shows horizontal gaps in all the letters making it hard to read, and I can't force my TV into another mode to compensate. Any interlaced kernel on my TV has that problem, Harmony menu included. There will always be a problem with flicker and different TV types. The only way around it is avoding flicker altogether, or writing two completely different kernels for a game and giving the user an option between them. If that is an in-game menu option it is not so practical as space is still a constraint in most games. Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted September 27, 2020 Share Posted September 27, 2020 Excellent stuff! Maybe it is time to update the PlusCart menu again. 2 1 Quote Link to comment Share on other sites More sharing options...
+Al_Nafuur Posted September 27, 2020 Share Posted September 27, 2020 18 minutes ago, Thomas Jentzsch said: Excellent stuff! Maybe it is time to update the PlusCart menu again. I hope @Andrew Davie don't finds this thread ? Quote Link to comment Share on other sites More sharing options...
alex_79 Posted September 27, 2020 Share Posted September 27, 2020 (edited) Cool! I tested on the Jr console I have hooked up to my CRT. I agree with @SpiceWare that the 576 chars one looks best. The 1008 one flickers too much for my taste. I recently tested various consoles by resetting an object position while an HMOVE is still performing its operations, and my conclusion is that the offset between different consoles is the result of a race condition. If the strobe to RESxx coincides with one of the extra CLK pulses that the position counter receives during an HMOVE, the resulting position depends on which of the two events happens first. Here is a table with the (hopefully correct) timing of the extra CLK pulses for HMOVE cycles form 73 to 3. HMOVE extra CLK pulses | HMOVE cycle HCOUNT CPU | 73 74 75 0 1 2 3 ---------------------------------------------------------------------- 0 0 | 1* 1 1 1.33 | 2 2 1 2 2.67 | 3 3 2 1 3 4 | 4* 4* 3* 2* 1* 1 4 5.33 | 5 5 4 3 2 2 1 5 6.67 | 6 6 5 4 3 3 2 6 8 | 7* 7* 6* 5* 4* 4* 3* 7 9.33 | 8 8 7 6 5 5 4 8 10.67 | 9 9 8 7 6 6 5 9 12 | 10* 10* 9* 8* 7* 7* 6* 10 13.33 | 11 11 10 9 8 8 7 11 14.67 | 12 12 11 10 9 9 8 12 16 | 13* 13* 12* 11* 10* 10* 9* 13 17.33 | 14 14 13 12 11 11 10 14 18.67 | 15 15 14 13 12 12 11 15 20 | 15* 14* 13* 13* 12* 16 21.33 | 15 14 14 13 17 22.67 | 15 15 14 -------NORMAL HBLANK END----- 18 24 | | 15* 19 25.33 | | --EXTENDED HBLANK END (hmove bar) --------- * = a RESXX on this cycle causes race condition with the extra CLK pulse. Edited September 27, 2020 by alex_79 3 Quote Link to comment Share on other sites More sharing options...
Omegamatrix Posted September 27, 2020 Author Share Posted September 27, 2020 I've made another demo. For this one I fixed the auto-detection to be at the top of the kernel. Please note I don't do exhaustive in-rom testing of multiple values to see which one will work for HMP0. I assume that if it is not one case then it is the other, which seems to work for now. In this demo you can scroll up and down to adjust the brightness (affects the flicker). Left and right will scroll the display. I have also included the code which is not optimized at all. I know it can be heavily optimized, but this is just a demo. 576Char_20200927_A.zip 11 Quote Link to comment Share on other sites More sharing options...
+Andrew Davie Posted September 27, 2020 Share Posted September 27, 2020 2 hours ago, Al_Nafuur said: I hope @Andrew Davie don't finds this thread ? What was that... did you say "proportional fonts...?" 3 Quote Link to comment Share on other sites More sharing options...
JetSetIlly Posted September 28, 2020 Share Posted September 28, 2020 This opens a lot of possibilities. My first thought was a port of Adventureland and the other early Scott Adams' adventures. Tricky I suspect but not impossible. https://en.wikipedia.org/wiki/Adventureland_(video_game) 2 Quote Link to comment Share on other sites More sharing options...
+Andrew Davie Posted September 28, 2020 Share Posted September 28, 2020 3 hours ago, JetSetIlly said: This opens a lot of possibilities. My first thought was a port of Adventureland and the other early Scott Adams' adventures. Tricky I suspect but not impossible. https://en.wikipedia.org/wiki/Adventureland_(video_game) I'm already have Scott interested. Sssh. 2 1 Quote Link to comment Share on other sites More sharing options...
+Andrew Davie Posted September 28, 2020 Share Posted September 28, 2020 20 hours ago, Omegamatrix said: I've made another demo. For this one I fixed the auto-detection to be at the top of the kernel. Please note I don't do exhaustive in-rom testing of multiple values to see which one will work for HMP0. I assume that if it is not one case then it is the other, which seems to work for now. It's lovely. In the PlusCart menu, we have found that 12-line-high characters look very good, and the double-line enforced on all characters. The above font, "Glacier Belle" is my favourite. We have 4 different fonts at the moment. I would be happy to share the characterset data with you. What I'd also be interested in doing is using your 36-char wide kernel in place of the current 32-char wide kernel on the PlusCart, if that's something you'd be open to. 2 Quote Link to comment Share on other sites More sharing options...
chewy Posted September 28, 2020 Share Posted September 28, 2020 (edited) On 9/27/2020 at 9:50 AM, SpiceWare said: Impressive! 576 looks best, less apparent flicker than 1008 due to the doubled-up vertical pixels. During the development of the 32 character text display I found a 3x4 pixel font, which with I think you'd get 1188. Just for grins I filled part of the font table with $F0 to see if it was suitable for a 144 pixel display, guess not. Impressive nonetheless! hey my guy: so your vcs is not going to a TV, but a colour CRT computer monitor? and you have probably the direct mod that a lot of atari big dogs have- so with the combo of those two things you must have a real HQ screen- is it similar to what you would play dos games on- Edited September 28, 2020 by chewy Quote Link to comment Share on other sites More sharing options...
+SpiceWare Posted September 28, 2020 Share Posted September 28, 2020 6 minutes ago, chewy said: hey my guy: so your vcs is not going to a TV, but a colour CRT computer monitor? and you have probably the direct mod that a lot of atari big dogs have- so with the combo of those two things you must have a real HQ screen- is it similar to what you would play dos games on- That's a Commodore 1084S monitor, came with my Amiga 2000HD back in 1991. I've never connected it to a PC; though am pretty sure it would support CGA and the 200-line graphic modes of EGA as they use a horizontal scan rate of 15.7 kHz, which is the same that NTSC and PAL use. However it wouldn't support EGA's 350-line modes, as those are at 21.8 kHz, and definitely not VGA. My 2600 has a CyberTech S-Video Card, think I installed in 2004. The 1084S supports split chroma-luma input via 2 RCA jacks, which was used with the C= 64 and 128. That's basically the same as S-Video, but the S-Video spec didn't come out until 1987 - 5 years after the C=64 was released. I use an S-Video to RCA cable to connect it, similar to this one from Console5. The CyberTech also features stereo audio, which is why I designed Medieval Mayhem with that in mind. The stereo you hear in this video is what I hear on my Atari and C=1084S. 1 Quote Link to comment Share on other sites More sharing options...
Omegamatrix Posted September 29, 2020 Author Share Posted September 29, 2020 8 hours ago, Andrew Davie said: It's lovely. In the PlusCart menu, we have found that 12-line-high characters look very good, and the double-line enforced on all characters. The above font, "Glacier Belle" is my favourite. We have 4 different fonts at the moment. I would be happy to share the characterset data with you. What I'd also be interested in doing is using your 36-char wide kernel in place of the current 32-char wide kernel on the PlusCart, if that's something you'd be open to. Of course you guys can use the 36 char kernel. Please feel free. I would recommend though testing it on a few more consoles before full commital. Orange808 did try a version of the rom which had the different HMP0 value. It worked on his 4 switch, but he had a 7800 which was intermittent. That's where I hope the auto-detection will help as I run it every frame. I will PM him to see if he can try the new rom, but if anyone else can run some tests that would also help. Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted September 29, 2020 Share Posted September 29, 2020 17 hours ago, Andrew Davie said: IMO the 'N' looks odd and is very hard to read. I suggest using a large lowercase 'n' there. Quote Link to comment Share on other sites More sharing options...
+Andrew Davie Posted September 29, 2020 Share Posted September 29, 2020 (edited) Replied in the PlusCart forum so as not to further hijack this thread, sorry! Edited September 29, 2020 by Andrew Davie Quote Link to comment Share on other sites More sharing options...
DirtyHairy Posted September 29, 2020 Share Posted September 29, 2020 On 9/27/2020 at 9:27 PM, Omegamatrix said: I've made another demo. For this one I fixed the auto-detection to be at the top of the kernel. Please note I don't do exhaustive in-rom testing of multiple values to see which one will work for HMP0. I assume that if it is not one case then it is the other, which seems to work for now. In this demo you can scroll up and down to adjust the brightness (affects the flicker). Left and right will scroll the display. I have also included the code which is not optimized at all. I know it can be heavily optimized, but this is just a demo. 576Char_20200927_A.zip 4.45 kB · 19 downloads Amazing, that looks excellent. 1 Quote Link to comment Share on other sites More sharing options...
alex_79 Posted October 4, 2020 Share Posted October 4, 2020 On 9/27/2020 at 9:27 PM, Omegamatrix said: For this one I fixed the auto-detection to be at the top of the kernel. Please note I don't do exhaustive in-rom testing of multiple values to see which one will work for HMP0. I assume that if it is not one case then it is the other, which seems to work for now. There should only be two possible results: 1 - the extra clock at cycle 0 happens slightly before the reset of the position counter -> the player is moved left one pixel, then it's repositioned (at pixel 3, as we are in HBLANK), then moved left one pixel for each of the remaining clock pulses. For a HMP0 value of $40 (12 pulses), it will then move left 11 pixels from position 3, ending at 152. 2 - the extra clock at cycle 0 happens slightly after the reset of the position counter -> the player is positioned at pixel 3 and then moved left one pixel for the current and following clock pulses (so 12 in total), ending at position 151. I did some tests with my consoles. Here are the results when running the roms posted in this thread: 1008 Char and 576 Char: The first 2 chars are garbled on the Light 6er on every other row. Works fine on all other consoles 576 Char multicolor: slight issue on the very first pixel row for the L6. Fine on the other consoles. I also tried the 36 char demo posted here, which doesn't display correctly on my L6. By looking at the included source, there is room to move the RESP0 strobe from the critical cycle 0 without affecting the timing of the rest of the kernel. So I compiled a few modified versions with that RESP0 happening at cycle 1,2 or 3 (and changing the HMP0 values accordingly, to keep the alignment). I would have expected all three versions to work reliably on all consoles, and while this is true for the "cycle 1" and "cycle 2" ones, the "cycle 3" shows another positioning issue on three of my consoles!! This seems to be a different kind of race condition, as there aren't HMOVE clock pulses at cycle 3, and the difference in positioning is 3 pixels, not just 1. Here the results with an altered rom that helps showing the positioning of the players: 36_Char_Interlaced_mod.zip 1 Quote Link to comment Share on other sites More sharing options...
Omegamatrix Posted October 4, 2020 Author Share Posted October 4, 2020 Thanks for all your tests Alex! Truthfully I knew the top line of the 576 Char multicolor was messed up because I forgot to apply the fix to the first line. I made a new rom since then and was awaiting some feedback, but since you have a console that has the same behavoir maybe you can try. This rom should work for all cases. 576Char__2020_09_30_A.bin 3 Quote Link to comment Share on other sites More sharing options...
alex_79 Posted October 4, 2020 Share Posted October 4, 2020 Tested the new rom with the L6 and the glitch is gone. 2 Quote Link to comment Share on other sites More sharing options...
JetSetIlly Posted February 8, 2021 Share Posted February 8, 2021 On 10/4/2020 at 6:16 PM, alex_79 said: I also tried the 36 char demo posted here, which doesn't display correctly on my L6. By looking at the included source, there is room to move the RESP0 strobe from the critical cycle 0 without affecting the timing of the rest of the kernel. So I compiled a few modified versions with that RESP0 happening at cycle 1,2 or 3 (and changing the HMP0 values accordingly, to keep the alignment). I would have expected all three versions to work reliably on all consoles, and while this is true for the "cycle 1" and "cycle 2" ones, the "cycle 3" shows another positioning issue on three of my consoles!! This seems to be a different kind of race condition, as there aren't HMOVE clock pulses at cycle 3, and the difference in positioning is 3 pixels, not just 1. I've been working on this problem in Gopher2600 today and I believe I've identified the condition when "RESP0 cycle 3" applies. To begin with I've implemented the condition for "RESP0 cycle 0" as described by @alex_79 in https://github.com/stella-emu/stella/issues/699 . That is, what we see is caused when RESPx is strobed during HBLANK and on the same video cycle as when the HMOVE ripple counter started. As @alex_79 postulates "RESP0 cycle 3" is caused by a completely different race condition. I believe this is correct. In my opinion, the image we see in the third screenshot is caused when: 1) RESPx has been strobed 2) scancounter START signal has been triggered (but before drawing starts) 3) HMOVE ripple counter has just ended 4) the player's phase-1 clock signal is rising/falling Normally, a scancounter that has had its START signal triggered will not start drawing until the player position has actually been reset. On this type of machine however, the START signal will resolve without being affected by the RESPx strobe. Reassuringly, these changes do not break any test in my regression database, so I believe this is partly accurate description of what is going on, if not entirely. I've pushed the changes to Github: https://github.com/JetSetIlly/Gopher2600 Some screenshots. The flicker makes it difficult to capture a still-image but you can just see enough of the phosphor. RESP0 cycle 0 RESP0 Cycle 1 and 2 RESP0 cycle 3 1 2 Quote Link to comment Share on other sites More sharing options...
alex_79 Posted February 8, 2021 Share Posted February 8, 2021 1 hour ago, JetSetIlly said: In my opinion, the image we see in the third screenshot is caused when: 1) RESPx has been strobed 2) scancounter START signal has been triggered (but before drawing starts) 3) HMOVE ripple counter has just ended 4) the player's phase-1 clock signal is rising/falling Normally, a scancounter that has had its START signal triggered will not start drawing until the player position has actually been reset. On this type of machine however, the START signal will resolve without being affected by the RESPx strobe. Many thanks for the explanation. Very interesting. I've just pulled from git and compiled Gopher2600 with those changes. It works great! 1 Quote Link to comment Share on other sites More sharing options...
Omegamatrix Posted February 9, 2021 Author Share Posted February 9, 2021 Should we consider both cycle 1 or 2 RESP0 safe, or is there a preference here? I am going to remake with my 36 char routine with changes @alex_79 proposed but want to keep it as compatible as possible. Quote Link to comment Share on other sites More sharing options...
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.