Jump to content
PeteE

Copper (raster tech demo)

Recommended Posts

12 hours ago, Tursi said:

But MAME is the most accurate emulator, therefore it is Classic99 and real hardware which is wrong. ;)

If reality were to comply with MAME, I'll just start off now with patching out that damn pandemic virus. 🙂

 

(As for the issue above: The paged378 mode was my interpretation how this cartridge type works, but I never had one in my hands. I'm still struggling to get the omniscience perk. ;-) )

  • Like 3

Share this post


Link to post
Share on other sites
14 hours ago, OLD CS1 said:

My sides.

I know, right! I literally spat out my coffee at his comment.  My missus turned to me and asked what was funny.  I now have to explain a lot, and she still won't find it funny. But I sure as heck do.

  • Like 1
  • Haha 3

Share this post


Link to post
Share on other sites

OK, paged378 fixed and committed in MAME. With the next release you'll see the full copper demo.

 

Edit: If you don't want to wait, you can find the Windows build at https://ftp.whtech.com/emulators/MAME/ti99/windows/mame20201218b_ti99_win64bit.zip. Download it and unpack it over your MAME installation.

 

I'm going to prepare more builds in short term.

 

Linux: https://ftp.whtech.com/emulators/MAME/ti99/linux/mame20201218b_ti99_linux64bit.tar.gz

(Ubuntu ≥ 20)

 

Edited by mizapf
  • Like 5

Share this post


Link to post
Share on other sites
On 12/17/2020 at 12:49 AM, Tursi said:

It should run on the F18A, the raster effects tend to work fine there. I can't test it myself atm...

 

From what I understand about the F18A, it doubles the scanlines to produce the 480p60 VGA output, and therefore must run horizontally twice as fast to scale up by 2.  In my raster test on F18A, the white band appears only only every other scanline and twice as wide, which would seem to support that idea.  I suspect it also latches the screen image table register and the color table register at the start of each scanline, @matthew180 can you confirm? 

 

But I'm also thinking a better solution would be to detect F18A and run the GPU to change the registers using the F18A-specific horizontal interrupt.

  • Like 1

Share this post


Link to post
Share on other sites
57 minutes ago, PeteE said:

But I'm also thinking a better solution would be to detect F18A and run the GPU to change the registers using the F18A-specific horizontal interrupt.

I think it's more up to Matthew than you to fix this. Using the F18A capabilities for a demo is fine, but not nearly as cool as making it run on the 9918A. If we went in and really pushed the F18A to the limit, a whole new dimension would be opening.

  • Like 2

Share this post


Link to post
Share on other sites
49 minutes ago, Asmusr said:

I think it's more up to Matthew than you to fix this. Using the F18A capabilities for a demo is fine, but not nearly as cool as making it run on the 9918A. If we went in and really pushed the F18A to the limit, a whole new dimension would be opening.

I didn't mean that I wanted to push the F18A to the limit, I just wanted people who only have F18A to be able to view it, instead of the demo looking like a garbled mess.

  • Like 1

Share this post


Link to post
Share on other sites
27 minutes ago, PeteE said:

I didn't mean that I wanted to push the F18A to the limit, I just wanted people who only have F18A to be able to view it, instead of the demo looking like a garbled mess.

But if you fix it the next person who make a cool demo for the 9918A will run into the same problems with the F18A. So I still think it's up to Matthew to fix.

  • Like 2

Share this post


Link to post
Share on other sites

I replaced the brand new 12MHz crystal installed on the TIny-99/4Av2 with an old 12MHz one taken on one of my 99/4A computers and the problem has almost disappeared (it is now just visible on a top left zone and not on all a left vertical column as before). I used a .47pf capacitor and a .33mH inductor for the TIM 9904A.

  • Like 4

Share this post


Link to post
Share on other sites
On 12/17/2020 at 7:16 PM, Asmusr said:

Yes but it won't work even if I remove that line, because my F18A emulation is hacky and calculates one sprite collision flag for the entire screen.

I discovered that I did actually fix this in the past, so the F18A emulation is also supporting line by line sprite collision detection. 🙂 This means that the demo is now running in js99er in the F18A emulation, but it doesn't work on real hardware. That makes it even more interesting for me to find out why. @matthew180

  • Like 3

Share this post


Link to post
Share on other sites

Oh!!

This day, I tried to remove the thing I thought was a bug on my TIny-99/4Av2:

As I said in my previous message, the replacement of the 12MHz crystal by an other one taken on a stock 99/4A computer removed the full vertical artifacts line that I had at the left on the screen. Just remained some artifacts (sprites) on the top left of the display on some animations (not all) and on less than 1/3 of the height of the screen. I studied again and again my schematics, the timing specification of the 99/4A computers, I found nothing that could results a compatibility problem. I was really out of ideas... Then, to relax me a time before searching again, I ran the Copper demo on a real 99/4A (with a TMS9929A inside). It's a thing that I haven't done since the beginning because I had got into my mind that it worked perfectly.... And it doesn't!  On the real 99/4A, the result is the same as on the TIny-99/4A: It also displays these artifacts, at the same place, with the same length.
Finally, it is a very good news for me 🙂

  • Like 4

Share this post


Link to post
Share on other sites
22 hours ago, Asmusr said:

But if you fix it the next person who make a cool demo for the 9918A will run into the same problems with the F18A. So I still think it's up to Matthew to fix.

After some thought, I agree with you on this.  The F18A should try to match the horizontal sync timings of the 9918A.  I'm not going to make a F18A version of the demo.

 

46 minutes ago, fabrice montupet said:

Oh!!

This day, I tried to remove the thing I thought was a bug on my TIny-99/4Av2:

As I said in my previous message, the replacement of the 12MHz crystal by an other one taken on a stock 99/4A computer removed the full vertical artifacts line that I had at the left on the screen. Just remained some artifacts (sprites) on the top left of the display on some animations (not all) and on less than 1/3 of the height of the screen. I studied again and again my schematics, the timing specification of the 99/4A computers, I found nothing that could results a compatibility problem. I was really out of ideas... Then, to relax me a time before searching again, I ran the Copper demo on a real 99/4A (with a TMS9929A inside). It's a thing that I haven't done since the beginning because I had got into my mind that it worked perfectly.... And it doesn't!  On the real 99/4A, the result is the same as on the TIny-99/4A: It also displays these artifacts, at the same place, with the same length.
Finally, it is a very good news for me 🙂

I'm sorry you had a struggle with this.  There are sometimes artifacts on the 9918A in the upper left and right corners also, and I'm still astonished that it works on the 9929A using the same code as well.  The reason for this is the locking on the hsync (through the sprite collision flag) is really imprecise at the top of the screen and can take quite a few scanlines before it can settle in to right spot.  I've tried many different tweaks to try to get it to converge faster, but so far I've not found anything that works as well as the original method.  And this is after I've noticed that my original method forgot to reset the collision flag after one of the register writes, so it would leak the collision flag to the next line.

 

 

  • Like 2

Share this post


Link to post
Share on other sites

Don't be sorry!  It was for me a very good brainstorming and I am happy with it.  in addition, this equal results confirm one more time the good compatibility of my computer with the 99/4A 🙂
You made a great work with this demo, I thank you again.
I just have a little request: If you have some free time (or the desire), could you change the code of your program to make an infinite loop of the demo, instead of stop it when all the animations have been played? It could be cool for a public demonstration in old computers meetings.

Edited by fabrice montupet
  • Like 6

Share this post


Link to post
Share on other sites
1 hour ago, PeteE said:

After some thought, I agree with you on this.  The F18A should try to match the horizontal sync timings of the 9918A.  I'm not going to make a F18A version of the demo.

Well, after some thought I also agree with you 🙂. Because there is more to this demo than just the scanline detection, and everybody should have a chance to see it. But maybe there is a simple fix once we know what the issue with the F18A is. I could image that it's setting the collision flag on every VGA scanline instead of only setting it on even scanlines. Would that break the demo? I set up my F18A machine today for the first time since corona to be able to test it. 

  • Like 2

Share this post


Link to post
Share on other sites
On 12/17/2020 at 4:38 AM, PeteE said:

I was inspired by the C64 demo in this post and decided to port it to the 99/4a.  The lack of colors was indeed a struggle, but I think it turned out pretty okay given the limitations.  There are three major effects that are combined to produce the various animations.  The first is color cycling, which changes the contents of the color table to create motion.  The second is 8 rotating color bars on screen at 64 different angles, done by changing the pattern table address.  The final effect is the interleaved screen+color tables - using raster horizontal sync, which changes the screen image table address and color table address on every line.  This is using VDP graphics 1 color mode!

 

I've only tested it working in Classic99 and on a NTSC 99/4a console.  It wasn't working in JS99er or MAME, maybe because it relies on the VDP status collision flag being set by transparent (color 0) sprites?

copper8.bin 128 kB · 51 downloads

Hi Pete

 

no way to share the code of the demoscene?

For me this demo is rocket-science stuff I would be very interested on how it works ... where/what is the starting point to create such demo ...   

The best for me is a sort of tutoria thread that explain step by step how to create this demo ... but I know I'm asking the impossible ... anyway that would be very helpfull to have a look to the coding ... 

 

Thanks once again for your commintent with this wonderfull AMachineMakeEverything system

All my best for a great year end... for 2021 better to say nothing

Francesco

  

Share this post


Link to post
Share on other sites

I finally set up an NTSC machine again and was able to view the demo in its full glory, and it looks amazing - much better than on emulation. I wonder if there would be time enough during vertical blank to play some music?

  • Like 2

Share this post


Link to post
Share on other sites

Yes, I think there is enough spare cycles during vblank to fit in a sound list music player, if not at 60Hz, then at 30Hz. There's about 2k available in 13 of the 16 total banks for additional data.  I might try taking some other game music and fit it in.

 

I do intend to write a more detailed explanation of how it works. Thanks for your patience.

  • Like 6

Share this post


Link to post
Share on other sites

So I wonder if the issue on v9938/58 VDPs is the collision between transparent (color 0) sprites not working.  @fabrice montupet or someone with such VDP, would you please try the attached raster test and let me know if the wide band appears?  If this works, then I can fix the Copper demo by making the sprites black (color 1) instead of transparent, and place them at the left edge of the screen and adjust the timing. Thanks!

rasterc.bin

  • Like 1

Share this post


Link to post
Share on other sites

Thank you for the time you spend to find a solution.  Here is the result on my V9958 based computer:

IMG_1569.thumb.JPG.ef420fbfe3bbf365928df2b4c35108cb.JPG

... 🙂

 

Edited by fabrice montupet
  • Like 1

Share this post


Link to post
Share on other sites

Thank you for confirming the raster test.  So this exposes a difference between the two VDP families:

TMS9918A/28A/29A: collisions between transparent (color 0) sprites are tested and reported in status register.

v9938/58: collisions between any transparent (color 0) sprite are NOT tested.

 

 

Share this post


Link to post
Share on other sites
5 minutes ago, mizapf said:

Here is a copy of the V9938 spec.

Screenshot_20210109_225221.png

Screenshot_20210109_225328.png

Thanks, my PDF copy doesn't have the handwritten note there: "when either sprite has color 0, the "... I can't quite make out the rest, what does it say?

Share this post


Link to post
Share on other sites
3 minutes ago, PeteE said:

"when either sprite has color 0, the "

Looks like "when either sprite has color 0, the bit will not".

Share this post


Link to post
Share on other sites
2 minutes ago, Asmusr said:

Looks like "when either sprite has color 0, the bit will not".

Okay, thanks, that makes sense. When either sprite has color 0 (transparent), the (collision) bit will not (be set.)

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...