Jump to content


  • Posts

  • Joined

  • Last visited

  • Days Won


Everything posted by svenvandevelde

  1. This is quite an important sequence for the CX16 to handle interrupts . At the start: asm { lda $9f21 pha lda $9f20 pha lda $9f24 pha lda $9f23 pha lda $9f22 pha lda $9f25 pha } At the end: pla sta $9f25 pla sta $9f22 pla sta $9f23 pla sta $9f24 pla sta $9f20 pla sta $9f21 Learning by doing ...
  2. @Michael Steil The BE Dutch AZERTY keyboard has the "." mapped to a "." on the numpad, while the BE French AZERTY keyboard maps the "." to a comma "," on the numpad !!! Don't know who invented this, but it is really annoying if the numpad shows a "." but generates a "," when typed. I use the BE Dutch AZERTY keyboard all the time. We have 3 official languages in our country. Please include the BE Dutch AZERTY keyboard in the ROM. These keyboards are not the same, unfortunately.
  3. You see... more ram brings more complexity to manage that ram, as it allows for more complex software or games. More video ram requires a capability to manage that ram and to use that ram effectively. Because it's very limited although 128k seems like a lot. It all depends what is the game you're trying to create. Some people may put this statement at question, as written in other forum posts. Those people should do what we do, and then they will see . Once I get the vram heap manager in the most optimised state, I'll share the METHOD of how it was done and how it works, so you can potentially reimplement in an other language like prog8. Just a few more days patience please. Once the VRAM is working I'll make the BRAM manager again but now with a different method than how the VRAM manager is implemented. The two have distinct properties that really require a different approach.
  4. Here a few test programs that I've written to test the mechanisms and performance of the vera heap manager. It is coming together: - best fit algorithm for finding the optimal free block. - coalescing free blocks - statistics for debug - byte-level indexing, so no word size and very fast - no vram pollution, so everything is managed in RAM or BRAM - no direct pointers of offsets returned after an alloc, it returns a handle, which is an indirect reference! Feel free to run the following attached prgs in an cx16 emulator and observe the workings. I'll post a more detailed description of it later! (It"s a very long story). My last challenge is how to optimize memory location placement, to avoid fragmentation. But this is a common problem that is not easy to fix. I think I will further design a compactor that can be triggered from within a game logic to compact memory when needed (for example between levels). cx16-veraheap_test_stress.prgcx16-veraheap_test_graphical.prg
  5. Ed, This is very kind of you sharing these libraries. I'm sure that there are more people who have build such libraries over the past (30?) years. I went through your list and what really makes it interesting is to jointly discuss some of these algorithms to understand the logic applied. Like SQRT B200 square root of absolute value of index
  6. I would like to be the owner of Belgian 80C. But a small suggestion, pls add belgian point keyboard as I have written, it is used by +/- 5 mio people. You can blame Napoleon for this fact.
  7. There is only one master keyboard layout for the cx16, would you agree? (just teasing a little). That being said, on this keyboard is a 40/80 button which does not seem to work properly. Not sure if this button was meant to switch between 40 and 80 columns automatically?
  8. Yes. Building memory managers is a fascinating subject. How to make it fast, achieve requirements, small code base, use memory efficient, avoid long loops, easy to use etc ... There are tons of "examples" on the internet and github using C on 32/64 bit machines and using the operating system brk on unix or memory allocation using win 32 api. However, on a naked cx16 in 8 bits architecture this topic gets a whole other dimension. You need to manage the addressing in memory yourself without operating system support! Then add to that the VRAM and BRAM banking and segmentation, and you have a problem domain that is extremely interesting to solve.
  9. Exactly. Note that for a VRAM memory manager, the complexity is that the memory manager cannot be implemented using header and/or footer blocks as this would pollute the video objects!
  10. In C using kickc. Note however that the kickc produces an asm file that can be compiled with kickass assembler. Once I've properly documented I'll post it. I also have a bram memory manager using a heap approach and a bram fixed block memory manager. The latter however results in internal memory fragmentation but is blazing fast.
  11. After a long time, decided to improve this heap manager. I need such a memory manager to dynamically allocate and free from the VRAM on the vera tiles and sprites of various compositions like 32x32, 16x32, 16x64 etc. And this during raster interrupt logic. The code that I had written for BRAM and VRAM had ended to to be bulky, slow and hard to understand. So I decided yesterday to try again, with the focus on managing VRAM only. So I took my code and have been reworking it. The major requirements for the design have stayed the same, but additionally, it should avoid internal fragmentation. Also, it should allow the heap to be compacted (not garbage collected), so I decided to keep the handle based approach. This memory manager won't give you pointers but references or handles to indirectly access the memory. The heap manager still uses an index in BRAM, which contains the dictionary of where VRAM is used, where it is free. I just finished today a new logic, with a code footprint of about 2000 bytes ... Tested the main allocation scenarios including coalescing. More on it later. Dinner is served.
  12. There are obscure dialects in domestic Wallon regions which probably would increase the likelihood of fluent communication between Belgians and Quebecians
  13. Please consider this additional info ... http://www.kbdlayout.info/KBDBE/
  14. Since you have 40C French included, instead of 80C Belgian French, as both are very similar, suggest you add 813 Belgian point, the "Flemish" azerty version. You would do 5 million people a favour. What about Russian (Not kidding), Chinese, Romanian, ... Another 1.5 billion...
  15. Enjoy your time here. There is a lot to learn and try out on the CX16. Groetjes uit Koksijde
  16. 00000813 Belgian (Period) please or 0000080C Belgian French
  17. haven't counted the cycles yet but it will be less ... also i store 64 bytes as lookup tables, that's it.
  18. However, to go back to the topic, i really think this atan2() function is genius :-). Not 100% accurate but accurate enough :-). The way how this got calculated.
  19. Indeed. Programs could focus on the actual logic rather than having to deal with these calculations. A separate ROM bank containing such functions would be really useful.
  20. I see. I need to install discord then. Ok.
  21. Done, @Michael Steil R40 x16emu: error when using -prg option, first file on disk read instead of given filename · Issue #398 · commanderx16/x16-emulator (github.com) I''ve attached a video link that shows the phenomenon. Because all my other binary files are registered as "PRG" also on the disk. So what happens is, it tries actually to load a file that contains sprites using the command LOAD ":*",8,1. Not sure if it is part of the options that if a quick fix is possible, that you remake the emulator binaries? Maybe an idea is that before release, let a couple of people test it first who have developed already more "complicated" CX16 programs? So that you can ensure that your release is stable enough before submission. (just an idea). Sven
  22. Try out R40. It has a lot of improvements.
  • Create New...

Important Information

Please review our Terms of Use