Jump to content

SerErris

Members
  • Posts

    172
  • Joined

  • Last visited

  • Days Won

    1

Everything posted by SerErris

  1. I do not understand. Is this an issue? Here is the screenshot of the Raytracer.BAS
  2. Thanks for confirmation ... So I need to write my graphics mode fractral in 320x240 with 8bpp ... lets see how fast this will be ... I do in basic first and then try a assembler version.
  3. VERA 0.9 has defined that it can run in 640x480 in bitmap mode with 8bpp ... but that would to my calculation require 300kb and we only have 128kb video ram (even a little less if you remove the register space). Am I overlooking something or does it no longer support 640x480 at full 8bpp bitmap mode? 320x240 should fit with 256 colors ... So is it intended that we can use 8bpp only with scaling factor of 2? Cheers Ser
  4. Okay the raytracer has been updated and now works as expected. It is in the pull request. 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.
  5. 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?
  6. Ahh okay, great. understood. So in this example ZPKERNAL has 8 bytes reserved in ZP from 80 to 87. what is stored in this area? Is there a more details listing of what is exactly mapped in each ZP/Address?
  7. Sounds like a bug to me. Did you create a bug report for cc65 project?
  8. There is a benefit at having them at the end and in the beginning. Starting at 0x80 and then continue to 0xFF - wrap and continue on... you can then address all of the block in one indexing approach with the ZP wrap around mechanism. 6502 wraps around on ZP with indexing. So if you do LDA $80,X and X is 85, you will end up loading from $05. So you can with LDA $80,X address all of the data in a single block. However I agree, have it a single block and not scattered with free addresses in between is also very important.
  9. Anyone done this for the current ROM version? I have compiled the current rom, but did not try the memory map thing
  10. Should work the way you have done it from the specs (definition of ca65 .align statement). Not sure what goes wrong. Can you try .align 255,$cc and see what is happening?
  11. 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).
  12. BTW the BRA example only works on the 65c02 not on the 6502 or 6510 as this is a new Opcode.
  13. Another Idea would be a LSR ... and then check on carry bit.
  14. 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?
  15. 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.
  16. I agree, but the more the ZP is occupied by Kernal functions the more the programmer needs to carefully consider what to overwrite at what time. So you spend more time juggling around, than actually programming the stuff you want.
  17. I compiled the master tree of x16emu and of the rom files and together I get the expected result (including the banner). For the Bank switching @StephenHorn is right. It is currently not in the master branch. Still pointing to the old ) $9F60/61 vectors. I tried the x16_board_r2 branch. It compiles great, but the screen is black in the emu. The current ROM most likely is not adapted to the ROM vectors and this needs a commit (and most likely some more changes I do not understand/know yet).
  18. Hi, I was hyped about the fact that much of the ZP is actually empty and not used by the system. I found this allways a huge limitation of C64 that actually most of it is occupied by the System and Basic and you could barely find 10 bytes unused. Now in the progress of the project I can see first signs of getting it filled by the system again (now bytes $00-$21 are in use). Of the 126 bytes, that were available before, are now only 93 left. This is not to bad still, but shows a tendancy. Can you please consider to make it a design goal to have as much as free space in the precious ZP? ZP is becoming in the enhanced instruction set of 65c02 even more precious, so I would love to be able to use it. One way to achieve it would be a way to easily save and reload the parts that users might not need (e.g. Basic). Yes I know you can work in a "don't care" mode and simply assume that the user need to reset after using your program. However that is in no way a modern approach and I like to leave a clean environment. So if you run my program from basic, I like to return to basic and find it intact (no hidden time bombs left, because something overwritten). Also calling the basic initialize routing might not be the best, as it also clears the basic memory (overwrites what was in there in terms of sys calls or whatever). What I am asking for is: Either reserve some of the really precious ZP space for us programmers, or create a basic/kernal routine to restore the space without deleting any other part of the ram. Last point of consideration: Of cause If I write into areas used by basic, those data will be gone after calling basic initialize, but the basic ram should not be overwritten. I can then put temporary data into the memory section in questions and that keeps my program intact to get rerun.
  19. I found out about this awesome new project and Platform via 8-bit guys videos. I would love to see a new "modern" 8-bit computer coming to live and to have one in my Men/Kids Room .. I am a child of the 80s area where I owned (or should I better say my parrents got me) a Schneider CPC (Amstrad) with a nice Z80 CPU and a pretty good computer around it. Many of my friends had a C64 and I also nowadays own a C64 breadbin and worked a lot on it (hardware wise). I am now into learning 6502 machine language (better said assembler) currently on the 6510 of the C64. However most of it will be reusable - the system calls and all of the C64 will be somehow as well. I am in real hope to get away from the poor graphics mode of the C64. It had sprites, yes, but the screen mode is so awkward setup for me. As I said I learned on the CPC and the screen was just a 16k memory area where you could do whatever you want. So memory was just a very simple representation of the lines on the screens. The calculation of lines was very easy and not organized in characters or anything alike. So anyhow does not matter. Now I will dive into all available details on the X16 and cannot really await when it is getting released as a real hardware platform.
×
×
  • Create New...

Important Information

Please review our Terms of Use