jltursan Posted January 25, 2021 Share Posted January 25, 2021 Hi! Yes, 0.227. Basically I miss the PAL version, seems that only NTSC model is emulated. Also, when "racing the beam" you can clearly see the differences, the vblank period seems to be correctly processed; but when the new frame retrace starts, looks like the frame is instantly generated. Probably I'm not explaining correctly... Oh, I also miss the border color and I haven't found a switch to enable it. Does it works or hasn't been implemented yet?. Screeen shot from Aqualite Aqualite!, thanks! As you're emulating a PAL machine (at least seems so), Aqualite renders the screen mostly fine, the row is partially visible; with a PAL Aquarius and a 43 value you won't see at all the yellow row, with a value of 42 you'll see about one quarter of the last scanline. Probably I would need to develop more accurate tests to fine tune this. We still need the real numbers from a NTSC machine, I don't expect a big difference but the hblank must be taken into account. Quote Link to comment Share on other sites More sharing options...
Pernod Posted January 25, 2021 Author Share Posted January 25, 2021 2 minutes ago, jltursan said: Yes, 0.227. Basically I miss the PAL version, seems that only NTSC model is emulated. Also, when "racing the beam" you can clearly see the differences, the vblank period seems to be correctly processed; but when the new frame retrace starts, looks like the frame is instantly generated. Probably I'm not explaining correctly... Oh, I also miss the border color and I haven't found a switch to enable it. Does it works or hasn't been implemented yet?. The PAL version is aquariusp, whereas aquarius is NTSC. The refresh period should be correct but it's still using an old rendering method where the whole screen is drawn at once, it needs to be converted to be drawn by scanline. I'll take a look at updating this. You'll have to give me a reference on the border colour, it's not implemented. Quote Link to comment Share on other sites More sharing options...
jltursan Posted January 25, 2021 Share Posted January 25, 2021 Doh!, you're right, I just need to invoke aquariusp to get the PAL version. That was fast, thanks! The refresh period should be correct but it's still using an old rendering method where the whole screen is drawn at once, it needs to be converted to be drawn by scanline It matches what I'm seeing. I've used the MAME debugger to trace the display update and looks fine indeed, it was only the screen refresh what made me think that something was wrong there. It would be really cool if you can fix it. Border colour is, AFAIK, extremely simple, the border is filled with the character and attribute color present at $3000. If you check the Aqualite snapshot you'll notice that upperleft green char, it's a space char with green background color, the border is generated using it. I've not tested yet how the border interacts with the raster but I guess you can change $3000 at any time and the border will be updated but only will be visible from the beam position to the end of frame. Quote Link to comment Share on other sites More sharing options...
MackJsy Posted January 25, 2021 Share Posted January 25, 2021 (edited) 2 hours ago, jltursan said: Border colour is, AFAIK, extremely simple, the border is filled with the character and attribute color present at $3000. If you check the Aqualite snapshot you'll notice that upperleft green char, it's a space char with green background color, the border is generated using it. I've not tested yet how the border interacts with the raster but I guess you can change $3000 at any time and the border will be updated but only will be visible from the beam position to the end of frame. Check my recorded video from a real machine with some border effects in play. Border colour is changed end of Vblank and again at start of vblank Edited January 25, 2021 by MackJsy 1 Quote Link to comment Share on other sites More sharing options...
jltursan Posted January 27, 2021 Share Posted January 27, 2021 Thanks, cool demo!. I'm testing a new tech demo using border colour and indeed it works as expected, I'll try to upload it ASAP. 1 Quote Link to comment Share on other sites More sharing options...
Pernod Posted January 27, 2021 Author Share Posted January 27, 2021 3 hours ago, jltursan said: I'm testing a new tech demo using border colour and indeed it works as expected, I'll try to upload it ASAP. Sounds like a good test case for me, looking forward to it. Quote Link to comment Share on other sites More sharing options...
MackJsy Posted January 27, 2021 Share Posted January 27, 2021 17 minutes ago, Pernod said: Sounds like a good test case for me, looking forward to it. More than welcome to try this one - The video linked above is it playing on a real machine captured via HDMI CLoad XMAS_B.caq and then Xmas.Caq (needs a 16k expansion and mini-expander - AY enabled) Xmas_B.CAQ Xmas.CAQ 1 Quote Link to comment Share on other sites More sharing options...
Pernod Posted January 28, 2021 Author Share Posted January 28, 2021 Implemented the border, but looks like I'm a little out on the timing? The Xmas Demo is blanking the borders, but also looks like it's maybe out by a couple of scanlines blanking the bottom border. I need to double check everything and do some calculations, may have some questions to clarify things. 1 Quote Link to comment Share on other sites More sharing options...
jltursan Posted January 28, 2021 Share Posted January 28, 2021 (edited) Amazing progress! Yes, if the row is invisible in line 49 you're off by 6. I want to finish the border demo as it could be a better way to test all things together but the timing is giving me some headaches. Right now the number shows how many scanlines are being skipped before an action takes place; but the calculation is absolutely rough and with incremental error count, higher numbers means higher accumulated error. The scroll demo shows a little better, there're not too much extra lines/pixels in the bottom. Edited January 28, 2021 by jltursan Quote Link to comment Share on other sites More sharing options...
jltursan Posted January 29, 2021 Share Posted January 29, 2021 This is the border demo I've been working on. It mostly works but it has some flaws as the yellow bar first scanline is off by about 30tstates (you can clearly see this in the first line of 191 pic) and I've just noticed that the line counter is wrong, showing the value minus 1 ? . As in this demo I'm always leaving free the first scanline, you can't never reach a 0 counter, 1 must be the lowest valid value. I hope that even with these bugs it could be of some help, I'll try to generate a new version with more exact routines. Btw, use "Q" & "A" as before. Suposedly, in all pics I've tried to align the first visible yellow scanline with the start of a 4x4 box but in fact, due the 30 cycles offset, it's the second scanline of the yellow bar. bordertest.bin Quote Link to comment Share on other sites More sharing options...
Pernod Posted January 29, 2021 Author Share Posted January 29, 2021 (edited) 10 hours ago, jltursan said: This is the border demo I've been working on. It mostly works but it has some flaws as the yellow bar first scanline is off by about 30tstates (you can clearly see this in the first line of 191 pic) and I've just noticed that the line counter is wrong, showing the value minus 1 ? . As in this demo I'm always leaving free the first scanline, you can't never reach a 0 counter, 1 must be the lowest valid value. The demo works well, but the counter and bar get further out of sync as I move down the screen. What are your timings actually based on? I'm still not convinced on the detail in the Video Timing thread, and find it hard to totally disregard the timings giving in the technical manual as not being relevant. We know the pixel clock is 7.15909MHz, so the question is how many dots per line at this rate? The Video Timing thread suggests 456 but I think this is slightly off. As far as I know the only timing info you have access to is the VSYNC bit on port $FD, correct? Is VSYNC low for the borders too, your demo suggests yes but the Video Timing thread says not. Assuming a 312 PAL screen, which lines are you expecting VSYNC to be low on? Edited January 29, 2021 by Pernod Quote Link to comment Share on other sites More sharing options...
MackJsy Posted January 29, 2021 Share Posted January 29, 2021 (edited) 43 minutes ago, Pernod said: The demo works well, but the counter and bar get further out of sync as I move down the screen. What are your timings actually based on? I'm still not convinced on the detail in the Video Timing thread, and find it hard to totally disregard the timings giving in the technical manual as not being relevant. We know the pixel clock is 7.15909MHz, so the question is how many dots per line at this rate? The Video Timing thread suggests 456 but I think this is slightly off. As far as I know the only timing info you have access to is the VSYNC bit on port $FD, correct? Is VSYNC low for the borders too, your demo suggests yes but the Video Timing thread says not. Assuming a 312 PAL screen, which lines are you expecting VSYNC to be low on? I'm going to get the logic analyser on the RA0->RA2 and Vblank lines on the PAL (all I have) version - just to see if RA0->RA2 are reset to zero on VBLANK end (which I suspect is the case) but logic says the following 625 lines in 1/25s (2 interlaced frames) - Dot clock would produce 458. ((1/25)/(1/CLK))/625 = 458 so 456 is off by 2 a line, or 50 a full frame note - VBLANK is only low from bottom of the displayed area round to top of the displayed area - it is not low during the side borders, only the top (above active screen area) and below (under active screen area) Edited January 29, 2021 by MackJsy 1 Quote Link to comment Share on other sites More sharing options...
Pernod Posted January 29, 2021 Author Share Posted January 29, 2021 (edited) 3 hours ago, MackJsy said: I'm going to get the logic analyser on the RA0->RA2 and Vblank lines on the PAL (all I have) version - just to see if RA0->RA2 are reset to zero on VBLANK end (which I suspect is the case) Sounds good, the actual VSYNC time should give us more to work with. Whilst I'm very close to actual behaviour on all three test cases I feel there may be something more that we're missing. Could there be any RAM contention coming into play during the active display? Edited January 29, 2021 by Pernod Quote Link to comment Share on other sites More sharing options...
jltursan Posted January 29, 2021 Share Posted January 29, 2021 I'm trying to generate a delay of 228T for every scanline based on the timings here. Looking at the real thing, it's close but I need to tighten a bit the code, I'm losing cycles here and there... Quote Link to comment Share on other sites More sharing options...
MackJsy Posted January 30, 2021 Share Posted January 30, 2021 40 minutes ago, Pernod said: Sounds good, the actual VSYNC time should give us more to work with. Whilst I'm very close to actual behaviour on all three test cases I feel there may be something more that we're missing. Could there be any RAM contention coming into play during the active display? Well - Ram contention is interesting , as the Z80's Wait line is fed the CLK/4, so some instructions will wait, some won't - depend on the point of the M1 /access cycle of the CPU at that point However, it's a CPU wide thing - not ram location. - so it's consistent Quote Link to comment Share on other sites More sharing options...
jltursan Posted January 30, 2021 Share Posted January 30, 2021 I'm not a hardware guy but this remembers me how the Amstrad CPC, sharing its RAM with the CRTC, does inserts extra wait cycles every four CPU cycles to give time to the CRTC to read pixels for video generation. I think that it also works consistently along all the RAM. Quote Link to comment Share on other sites More sharing options...
MackJsy Posted January 30, 2021 Share Posted January 30, 2021 11 hours ago, jltursan said: I'm trying to generate a delay of 228T for every scanline based on the timings here. Looking at the real thing, it's close but I need to tighten a bit the code, I'm losing cycles here and there... There is Ram contention sadly, - the Z80 Wait line is on a 1/4 CPU clock, so randomly (pretty much) some instructions will be one T state longer, I believe you lose on average 8 Tstates per scan line Quote Link to comment Share on other sites More sharing options...
Pernod Posted January 30, 2021 Author Share Posted January 30, 2021 4 hours ago, jltursan said: I'm not a hardware guy but this remembers me how the Amstrad CPC, sharing its RAM with the CRTC, does inserts extra wait cycles every four CPU cycles to give time to the CRTC to read pixels for video generation. I think that it also works consistently along all the RAM. I'm not a hardware guy either, I just emulate machines based on available schematics and technical manuals. I'm only familiar with RAM contention as it's also an issue with the Acorn Electron. Quote Link to comment Share on other sites More sharing options...
jltursan Posted January 30, 2021 Share Posted January 30, 2021 Yep, there're a lot of possible contention types, the more complex variant I know is the one in the CPC. It must be hard to emulate!. Let's see what can be done with the Aquarius... the Z80 Wait line is on a 1/4 CPU clock, so randomly (pretty much) some instructions will be one T state longer, I believe you lose on average 8 Tstates per scan line Thanks!; so, maybe we're talking of 228T+8T=236T per scanline?. I can make it work this way and compare the results. I'm afraid that this will turn into a trial and error affair; but right now it's the best I can think of. Quote Link to comment Share on other sites More sharing options...
Pernod Posted May 27, 2021 Author Share Posted May 27, 2021 I relented on waiting for some better video timings, so the border effects and scanline rendering are now in today's MAME 0.232 release. 2 Quote Link to comment Share on other sites More sharing options...
MackJsy Posted May 28, 2021 Share Posted May 28, 2021 21 hours ago, Pernod said: I relented on waiting for some better video timings, so the border effects and scanline rendering are now in today's MAME 0.232 release. Not been able to get the aquarius to run since you started making changes tbh - so gave up Quote Link to comment Share on other sites More sharing options...
Pernod Posted May 28, 2021 Author Share Posted May 28, 2021 5 minutes ago, MackJsy said: Not been able to get the aquarius to run since you started making changes tbh - so gave up Rather than just giving up with no explanation it would help if you actually mentioned this when you had problems, and provide some details as to what happens when you try to run it. Chances are that you need to update your aquarius.zip romset, by adding the aquarius_s1 ROM that was posted earlier in this thread. 2 Quote Link to comment Share on other sites More sharing options...
MackJsy Posted May 28, 2021 Share Posted May 28, 2021 1 hour ago, Pernod said: Rather than just giving up with no explanation it would help if you actually mentioned this when you had problems, and provide some details as to what happens when you try to run it. Chances are that you need to update your aquarius.zip romset, by adding the aquarius_s1 ROM that was posted earlier in this thread. Sorry -- been busy on lots of other things - think I tried it one "How many Scotch can I drink this evening" evening, and well forgot! Is there a link to the romset, as what I have fro S1/S2 doesn't work !! 1 Quote Link to comment Share on other sites More sharing options...
jaybird3rd Posted May 28, 2021 Share Posted May 28, 2021 5 hours ago, MackJsy said: Sorry -- been busy on lots of other things - think I tried it one "How many Scotch can I drink this evening" evening, and well forgot! Is there a link to the romset, as what I have fro S1/S2 doesn't work !! Glad to see you back, Mack! (I've been busier with other things than I would like, too, so I know what you mean.) aquarius.zip I've attached an Aquarius ROM set which you might find helpful. It includes the "S2" OS ROM set for both the Aquarius and Aquarius II, along with my dumps of the "S1" OS ROM and the character generator ROM. I just tested this set with the latest MAME 0.232 release, so all you should need to do is drop this into the "roms\" subdirectory. You can switch from "S2" (the default) to "S1" using the "BIOS Selection" option in the MAME UI. (Thanks again to Pernod for your work on the Aquarius/Aquarius II emulation! I'm still stoked to finally see bankswitched cartridges working in MAME! I hope to make use of it soon for some new projects.) 1 Quote Link to comment Share on other sites More sharing options...
jltursan Posted June 1, 2021 Share Posted June 1, 2021 On 5/27/2021 at 8:34 PM, Pernod said: I relented on waiting for some better video timings, so the border effects and scanline rendering are now in today's MAME 0.232 release. That's really cool, thanks!. I'm working in a "big" Aquarius project and this would prove to be handy for sure, I need to update my MAME (I'm using it as my main development tool thanks to its debugger) right now! 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.