Jump to content
  • 0

X16-demo basic scripts update for r37


SerErris
 Share

Question

Hi I started to work on the basic scripts on x16-demos. A lot of the demos actually do not run anymore as VERA 0.9 has been implemented and the registers are now much easier to use than before. As expected it breaks the basic programs.

Now I am stuck at one specific script, where I cannot figure out, what it actually does.

Can someone help me with Raytracer.bas ? what does it actually do? I could not even get it to run in r36 .. I change the vpokes and corrected them to the 0.9 but there is still not much of a result, that I could have expected. 

Any idea how to get it to run, to actually see what it is doing?

There are some Pokes which looks like BASIC Variable space .. not sure what they are doing .. 
The docs state:

The following features must not be relied upon:

  • the zero page and $0200+ memory layout
  • The layout of the zero page ($0000-$00FF) and the KERNAL/BASIC variable space ($0200+) are generally not compatible with the C64.

So what is actually in those addreses used by the program:
     
20070 POKE 713,3:PRINT CHR$(147);        "($02c9)"

Do we have a documentation on the variables of BASIC somewhere? And if not, how did this guy actually identified, what he was looking for. 

One last rant .. A little bit of comments would be great for those demos/examples ... ouch.

Edited by SerErris
Link to comment
Share on other sites

13 answers to this question

Recommended Posts

  • 0
12 hours ago, SerErris said:

The other vpokes ...

So you mean I would need to install a Version 34, and see what the normal result is supposed to be?

I refered to the POKE at the end of line 20010.  But then, I looked at the "rom.sym" file in earlier releases.  I saw that
:POKE 218,40
told Kernal to pretend that the text screen has only forty rows.  I can't think of any reason to do that -- you should remove that statement.

In early releases, text was put on layer 0, and graphics tended to be put on layer 1.  But, those roles have been swapped in the current release.  Therefore, you should plot the graphics on layer 0.

Yes, the current raytracer.bas can't work on R35 and later releases.  You must go back to R34, in order to see it draw the picture (three mirror balls on a checkerboard).  But, be prepared to wait a very, very long time -- it's as slow as frozen molasses.

Edited by Greg King
  • Like 2
Link to comment
Share on other sites

  • 0
On 8/9/2020 at 1:21 PM, SerErris said:

So, what is actually in those addreses used by the program:

     20070 POKE 713,3:PRINT CHR$(147);        "($02c9)"

 

Do we have a documentation on the variables of BASIC somewhere? And if not, how did this guy actually identify what he was looking for.

The program works in prerelease 34.

The original author used documents that describe the Commodore 64's memory map.  That line poked to 646.  Then, it was moved to 713.  It set the character color to cyan-on-black.  The modern method to do that is:

     20070 PRINT CHR$($90);CHR$(1);CHR$($9F);CHR$($93);

I don't know what the other POKE was supposed to do.

  • Thanks 1
Link to comment
Share on other sites

  • 0

The other vpokes was setting up the VERA registers, for the old version of it. So that part obviously needs adoption. I did that but, still it does not get me any output. The code is written to 0x04000 of the video memory, and the vpokes in the last section setting the screen to that start adress for Layer 1. Then layer 1 is enabled and also a scaling is defined. But all that is not that difficult. Anyhow no output at all. 

So you mean I would need to install a Version 34 and see what the normal result is supposed to be?

Link to comment
Share on other sites

  • 0
32 minutes ago, Greg King said:

In early releases, text was put on layer 0, and graphics tended to be put on layer 1.  But, those roles have been swapped in the current release.

Yep.  This tripped me up a lot when I started trying to learn layers, especially since I was starting after r34 where the change was made.  I've had a PR sitting out there to update the basic layer demo since February, but it hasn't moved and likely needs to be updated as of VERA 0.9.

Does anyone know who maintains the demo project?  The pulse has pretty much been dead all year, but I'm sure I'm not the only one who references this project for learning purposes.

 

image.png.da3dab37f43ab6244648beb450e0908e.png

Edited by Jestin
Link to comment
Share on other sites

  • 0
10 hours ago, Greg King said:

I refered to the POKE at the end of line 20010.  But then, I looked at the "rom.sym" file in earlier releases.  I saw that
:POKE 218,40
told Kernal to pretend that the text screen has only forty rows.  I can't think of any reason to do that -- you should remove that statement.

In early releases, text was put on layer 0, and graphics tended to be put on layer 1.  But, those roles have been swapped in the current release.  Therefore, you should plot the graphics on layer 0.

Yes, the current raytracer.bas can't work on R35 and later releases.  You must go back to R34, in order to see it draw the picture (three mirror balls on a checkerboard).  But, be prepared to wait a very, very long time -- it's as slow as frozen molasses.

Ahh ... I see, yes will do and move everything to layer 0 then. Interested to see if it changes and actually works (which it did not so far).

Link to comment
Share on other sites

  • 0
2 hours ago, StephenHorn said:

Michael Steil is probably the guy who needs to accept those PRs. Busy fellow, though.

Yeah, no joke.  I've been following and even submitting PRs for the docs and emulator projects as well, and it seems like he's running all of them.  I'd love to help out however I can, but I'm not audacious enough to ask for maintainer permissions.  I'd also hate to steal his attention away from the ROM and the emulator.  I may see about merging the outstanding PRs into my own fork of the project, just so there exists a working fork of the demos out on github.

  • Like 1
Link to comment
Share on other sites

  • 0

Okay, there is one more thing I like to understand. Got the RAYTRACER code running and it has now a funny feature. At every start it creats random colors for the Raytracer (maybe not what you would want).

The reason (might be) is the change in VERA I suppose:

The old VERA had a pallet in registers that you can read out. The new implementation states, that you actually do not read the registers, but the ram behind. If you write the register it will be put in register and in RAM. So this is confusing as the real register value does not correspond to the memory value after reset.

This section of the code most likely was supposed to pick 4 colors from the color tables and move them to the first four colors in the table. However it now randomizes the colors as the screen memory is not beeing initalized. Only the registers are.

20030 A=66:B=0:GOSUB 20200
20040 A=24:B=1:GOSUB 20200
20050 A=20:B=2:GOSUB 20200
20060 A=17:B=3:GOSUB 20200
...
20200 PV = VPEEK(1, $FA00+A*2)
20210 VPOKE 1,$FA00+B*2,PV
20220 PV = VPEEK(1, $FA00+A*2+1)
20230 VPOKE 1,$FA00+B*2+1,PV

So this section of the code in the old version was supposed to read a value from a specific pallette register (lets say 66 as in line 20030) and write that value to register 00. Of cause it handles high and low byte.

This does not work the same way. I consider now to write them directly in there (4 data values) instead of copying them. Otherwise I would need to initalize the vRAM by writing all values into the registers, that are there by default. 

I am not sure, but I believe the vRAM should be set to the same values as the registers are OR a read from a register shall return the register value (why is it write only anyhow?).

Can anyone confirm my analysis? 

Link to comment
Share on other sites

  • 0

Okay the raytracer has been updated and now works as expected. It is in the pull request.

On 8/11/2020 at 3:20 PM, Greg King said:

The program works in prerelease 34.

The original author used documents that describe the Commodore 64's memory map.  That line poked to 646.  Then, it was moved to 713.  It set the character color to cyan-on-black.  The modern method to do that is:

     20070 PRINT CHR$($90);CHR$(1);CHR$($9F);CHR$($93);

I don't know what the other POKE was supposed to do.

I actually changed the line to this: 
20070 COLOR 3,0:PRINT CHR$(93)  ;cyan on black and clear. 

The BASIC extension allows now to change the color much easier and more direct than in the C64. I love it.

Link to comment
Share on other sites

  • 0
13 hours ago, SerErris said:

I actually changed the line to this: 
20070 COLOR 3,0:PRINT CHR$(93)  ;cyan on black and clear. 

The BASIC extension allows now to change the color much easier and more direct than in the C64. I love it.

BASIC's COLOR statement prints four color control characters to the screen.  You can see them by putting the screen into "quote mode":

PRINT CHR$(14);CHR$(34);:COLOR3,0

Link to comment
Share on other sites

  • 0

Thanks for the answer. I expected it not to be very direct as it is basic commands. As the whole purpose of the demos is educational or understanding the principles ... This is what I included now into the source. It also will make it more independent on any future changes.

Link to comment
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
Answer this question...

×   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.

 Share

×
×
  • Create New...

Important Information

Please review our Terms of Use