# svenvandevelde

Members

197

6

1. ## Average amount of 6502 instructions per scan line, does my calculation make sense?

Nope. Pure C code ... https://github.com/FlightControl-User/X16_Code/blob/main/cx16-equinoxe/equinoxe-flightengine.c
2. ## Change of Command

Remember FIDOnet?
3. ## Average amount of 6502 instructions per scan line, does my calculation make sense?

True. I might do a combination of things. A larger tile in the background, and then an animation of the gun on the top of it ... But it will take time for me to program it, and also draw the tiles and the sprites. But I guess this is part of the fun, isn't it?
4. ## Average amount of 6502 instructions per scan line, does my calculation make sense?

Well, it can be improved. The tile algorithm is generating for a whole tile row in a new random sequence (building further upon the previous drawn tile sequence), every 32 scan lines Walls need to fit with walls and open space can be closed with walls or can stay open, etc, etc ... Facinating stuff to learn and to code... The algorithm takes quite some CPU actually at the moment, because a "row" is actually a combination of "logical tiles", which are a combination of 4 * 4 * 4 vera tiles. The layer on which the background is drawn, is actually in 16x16 tile mode in 4bpp. So per tile, there is a tile segment, which is 4 * 4 tiles, which makes a 32x32 tile. A whole "tile" is actually then a combination of 4 tile segments. And it may not show, but the algorithm works with about 60 background tile "bitmaps", and the combinations of those create about 56 tile variations of 4x32x32 width and height. You notice that there is sometimes a white "flash" in the border, which is the drawing of the row. It draws a complete row of 2x32x32 tiles (so half of a complete tile), and on top it draws the row the full length, which is 64 vera characters. This will alllow me to design also a panning to the left and right, depending on the player steering. So the enemies can get out of screen focus for a while if the player flies left or right. I really need to do some code crunching now =-). If I can tweak out a couple of cycles, that gives room for more effects or other weapons etc. Also plan to have "towers" or ground installations in the background, that would fire also or would defend together with the player the incoming enemies. Those would be sprites that would be layered on top of the floor plan, but under the enemies and the sprites. And those would fire weapons, or have some sort of magnetic fields or something like that. The imagination only limits the ideas. It is a lot of fun to make this. Sven
5. ## Average amount of 6502 instructions per scan line, does my calculation make sense?

Indeed! Spot on! It is a real challenge for the CX16 to do that! I've seen a couple of demos where people float some sprites around but without a lot of change or processing behind. When you build a logic that changes the sprites per item individually with their own logic, that is a completely different story! I need to work on my scrolling engine. By the way, the tiles are placed with a randomization algorithm, no game has the same tile sequence :-).
6. ## svenvandevelde    Cyber

I would like to wish the new management team the best of luck with this forum. I hope that David is still committed to the project. I am honestly worried. David needs to be more careful with his marketing. I hope he will show a sign of life on the forum.

7. ## Change of Command

I see here a great community and demonstration of leadership with this management initiative. It was initially this site that attracted me to the CX16. Although facebook is a great tool for marketing purposes and analytics, it are forums like this that build the core competence and knowledge sharing. Running a forum is a separate skill and requires indeed a good management team. It are the people behind the acronyms that make retro computing on the CX16 a living thing. So good luck to all of you, and thank you. Sven
8. ## Average amount of 6502 instructions per scan line, does my calculation make sense?

Thank you all for the massive feedback. Some real experienced people here I will need to do some more code crunching to optimize my logic to get more objects processed. Thank you for your suggestion to count in cycles. Indeed, the instructions used to build a logic varies game per game. One big lesson that I learn out of all of this is that although the x16 has 8mhz it is still a machine with limitations. The prospect of managing 128 sprites in a fluid process really requires a thoughtful design and a coding approach that requires a lot of experience. On top of that the background scrolling logic, collision detection, AI behaviour, player control, scoring, event management adds complexity. Beside the logic to control the sprites, I'm the most afraid of the complexity of the collision detection. The more objects you need to control in the flow, the longer it will take to identify which objects are colliding. Even taking into account that the vera can help with the collision detection events for the specified sprites displayed on the screen. I really would like to design this game using c language. My biggest challenge is how I can use absolute indexed addressing in the 6502. I mean, in a complex game flow the objects and memory locations move around and invite for the usage of pointers. Which results in indirect indexed addressing. I could write a game engine using absolute indexed addressing, but then I would need to copy memory areas around and avoid pointers where I can, which also adds CPU time. Or I would need to follow the route of self modifying code, but this one I really would like to avoid. Not so sure what is the right way to go. I guess the solution will be in the middle. And that makes it fun, to design a software that is portable, fast and designed for speed where needed. Another boundary I'm about to hit is the code size...
9. ## Average amount of 6502 instructions per scan line, does my calculation make sense?

Of course it is. My intention is indeed to understand with some science behind, how many objects would be able to be updated per frame, or in my terms a complete horizontal vera display scan. I'm not intending to update the object per vera scan line operation :-).
10. ## Average amount of 6502 instructions per scan line, does my calculation make sense?

Hi all, I want to validate a calculation on how much instructions are processed by the 6502, every time the vera scans a display line. Let's assume that the average instruction processing time is 5 cycles. (It might be an overestimation, depending on the type of instructions used). But let us imagine 5, as there is a program that uses a lot of indirect indexed addressing, like LDA (\$ZP),Y ... I've understood that the CX16 works at 8Mhz, so translating this, that would be around 8.000.000 cycles per second, correct? The vera display is configured to operate at 640x480 resolution, and no scaling. Let's assume that the vera scans the display 60 times per second. So the average amount of instructions that would be processed by the 6502 would be 8.000.000 cycles per second / 5 cycles per instruction, which would be 1.600.000 instructions / second. The vera scans the complete display 60 times per second, so that would mean that 1.6000.000 instructions per second / 60 vera scans per second would result in 26.666 instructions per single vera display scanning operation. However, there are 480 vera scan lines, so 26.666 instructions per vera display scan / 480 vera scan line would result in around 55 instructions per scan line per 60 times a second. So if we need to control about 40 objects, that would mean that for each object, there would be about 1,375 instructions per scan line available. Is the above calculation correct or is it way off? And what other variants or parameters come into play? Please see the below, it is the reason of my asking ... The white border measures the processing from the start of scanning till the end of scanning. Each object on the display is processing movement logic, behaviour logic, draw logic ... I was surprised that the machine takes time to process all this logic. Which makes it excitiing, because it allows to build a relatively more complex game, but still there are boundaries as a result of the machine configuration. kind regards, Sven
11. ## New upload: Fragmentation demo of heap memory manager in banked ram

I have the latest updates moved to my cx16 coding area on github. Moving the heap manager out of the kickc compiler did the moment but as a side compile. https://github.com/FlightControl-User/X16_Code/blob/main/cx16_lib/cx16-heap.c An open work item is to be able to configure that allocated blocks are not crossing \$a000 - \$buff bank boundaries. This is important for data structures. The data elements in the structure must be stored in sequential memory space. For bitmap data such boundary crossing would not be a problem though. For example, if at address \$A008 a block would be allocated of 16 bytes, then this would require the remaining 8 to be registered as idle, and the 16 bytes to be allocated from \$C000 downwards, with base \$BFF0.
12. ## Framebuffer in C?

Which veralib are you referring to? Can you pls show url?
13. ## Debug C-code using CC65 in the CX16?

Amazing ... for testing I can indeed use the above methods, but for production i think it is better to have it really nicely implemented separately. Anyway, the future will be the version 39, right? So that means that in the future the \$00 and \$01 will switch the banks, which I really like by the way! Note that the heap manager switches banks all the time, as there are no pointers but handles. To refer to a memory block, the function heap_data_ptr is used, which receives the handle. So based on the bank information embedded in the handle, the index block is retrieved, and the data handle is unpacked to set the correct bank and return the 16 bit data pointer, pointing to the previously allocated memory block start position in BRAM (between 0xA000 and 0xBFFF). enemy_handle = heap_alloc(HEAP_SEGMENT_BRAM_ENTITIES, sizeof(Enemy)); Enemy* enemy = (Enemy*)heap_data_ptr(enemy_handle); memset(enemy, 0, sizeof(Enemy)); enemy->health = 1; enemy->x = x; enemy->y = y; enemy->sprite_type = &SpriteEnemy01; enemy->sprite_offset = NextOffset();
14. ## Debug C-code using CC65 in the CX16?

How can I identify the ROM version in C? Which adres to peek? I have a feeling I'm going to learn something new ...
15. ## Debug C-code using CC65 in the CX16?

Thank you. So i need to make 2 version of the heap memory manager.
16. ## Debug C-code using CC65 in the CX16?

Thank you. And does the rom 39 use zeropage 00 and 01 to address the ram and rom banks respectively? Or are these still done through the VIA addressing?
17. ## Debug C-code using CC65 in the CX16?

Thanks. Just to make sure, I tried the box16 version 39.2.3. with the Kyoto version 38 rom.bin. But maybe this is not the way as it is not working ... When I read that the rom.bin needs to be build, how can I build the rom of the version 39 of the rom is not released yet? I mean, where is the source code of version 39 of the rom? How to obtain this source code? Is this the master branch of the rom on github?

19. ## Debug C-code using CC65 in the CX16?

I've installed the box16 on my pc, and downloaded the rom.bin and installed it at the root dir of the box16. But when i start the emulator, i get a blank white screen. Does somebody know what may be the issue?
20. ## How to obtain the lobyte and hibyte of a word in cc65 (using macros?)

@Greg King Can you pls advise what is the best way?
21. ## How to obtain the lobyte and hibyte of a word in cc65 (using macros?)

Thanks. But wouldn't the compiler make this resulting code highly inefficient? (This is my biggest worry actually).
22. ## How to obtain the lobyte and hibyte of a word in cc65 (using macros?)

I've been using the kickc compiler of Jesper Gravgaard for a while now to model my heap manager. Now i'm looking into cc65 to see if i can port the cx16-heap.c towards a cc65 compatible format, so that it compiles both on the kickc and the cc65. But I'm facing a problem. The unary operators < and > allow to obtain the lower and higher byte or word from an unsigned int or unsigned long respectively. Example what compiles in kickc: unsigned int address = 0x1234; unsigned char lo = <address; // returns 0x34 unsigned char hi = >address; // returns 0x12; printf("lo = %x, hi = %x", lo, hi); The output would be: lo = 34, hi = 12. Jesper has been adaptiing the syntax of his KICKC compiler, introducing BYTEx() syntax: unsigned int address = 0x1234; unsigned char lo = BYTE1(address); // returns 0x34 unsigned char hi = BYTE2(address); // returns 0x12; printf("lo = %x, hi = %x", lo, hi); So the above is now also working, and allows a higher compatibility for other ansi compilers by defining macros. My question is, how can I get a similar result done using the cc65 compiler? I've been searching and searching the internet but cannot find such a solution. Are there other methods on how this can be achieved? I know there are pseudo functions using the ca65 assembler like .LOBYTE and .HIBYTE but there I should write assembly language. How can a macro be defined in C using cc65 that does the similar like in kickc BYTEx() macros? Sven
23. ## Happy holidays

Merry Christmas. Beautiful pictures in Sweden @martinot
24. ## Happy holidays

Christmas demo from 1982?
25. ## Happy holidays

Merry Christmas everyone from Belgium. And indeed, X16 is very much alive. Enjoy a peaceful end year.
×
×
• Create New...