Jump to content

svenvandevelde

Members
  • Posts

    327
  • Joined

  • Last visited

  • Days Won

    12

svenvandevelde last won the day on May 10

svenvandevelde had the most liked content!

About svenvandevelde

  • Birthday 01/31/1970

Recent Profile Visitors

1161 profile views

svenvandevelde's Achievements

Collaborator

Collaborator (7/14)

Very Popular Rare One Year In Dedicated Rare First Post Collaborator Rare

Recent Badges

168

Reputation

3

Community Answers

  1. @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.
  2. 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.
  3. 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
  4. 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
  5. 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.
  6. 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?
  7. 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.
  8. 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!
  9. 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.
  10. 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.
  11. There are obscure dialects in domestic Wallon regions which probably would increase the likelihood of fluent communication between Belgians and Quebecians
  12. Please consider this additional info ... http://www.kbdlayout.info/KBDBE/
  13. 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...
×
×
  • Create New...

Important Information

Please review our Terms of Use