Jump to content

svenvandevelde

Members
  • Posts

    378
  • Joined

  • Last visited

  • Days Won

    15

Everything posted by svenvandevelde

  1. Is it? That might also be a root cause. Don't know. I'll wil try this tomorrow and let you know. But if somebody using another platform could try to resimulate it? This might help to confirm the issue? This would eliminate the possibility that there is something wrong with the c code libraries which I'm using.
  2. I think I found the root cause and it seems that file handling APIs are conflicting ... It seems that file IO is making the mouse freeze ... I could resimulate the problem in a simple program ... I've added the asm sources as you will check in assembler finally, but my main source is C, which i will explain. The assembler outputs are fully c code annotated. Let me first explain what is done ... This program sets the mouse pointer, and opens the FILE for reading at channel 1 from the disk (secondary address is 0 for load). File is on the disk, embedded in the sdcard attached. The file contains the text SVEN, which is displayed as the file will read 4 characters and display them. Then normally, the file should be closed, right? Well, that seems to be causing the mouse freezing issue. In the below working version i am not closing the file, and the mouse works (with the loop displaying the addresses 22 till 25). CX16-working.zipPLS TRY by unzipping cx16-mouse-working.zip, running cx16-mouse.prg from the sdcard image cx16.vhd sdcard. Now the not working version, I've uncommented line 34, which closes the file ... CX16-problem.zipPLS TRY by unzipping cx16-mouse-problem.zip, running cx16-mouse.prg from the sdcard image cx16.vhd sdcard. Now, you will see the file will be loaded, closed and all looks ok, but the mouse is NOT working! Can somebody please check the ROM for any bugs or at least confirm this error using my program or trying this at home yourself? I cannot use R39 like this until the root cause has been found. I've added the sources in assembly language, and included a symbol file: cx16-mouse - working.asm cx16-mouse - working.vs cx16-mouse - working.c cx16-mouse - problem.asm cx16-mouse - problem.vs cx16-mouse - problem.c Note that the ASM output is not using optimizing compilation settings to improve assembler readability. Sven
  3. that being said, i think there is an issue with the mouse handler ... This routine worked flawlessly on the R38. I'm in the middle of an interrupt service routine where i execute the following code: The registers $22 till $25 should contain the mouse x and y coordinates after the cx16_mouse_get call. But they stay 0. Some additional notes: I've been debugging and found that the memory locations A026 and beyond are not updated when walking the $FF6B API code flow, using the emulator debugger. So in the API code, these memory locations are read, and then there is an sta ($00),x which is storing these contents in the zeropage $00 indexed by x, which has value $22 at the time of this execution. Bank RAM register $00 is zero, so it is reading from $00:A026, $00:A027, $00:$A028, $00:$A029 and writing into $22, $23, $24, $25. All values read and written are zero. I guess this is because it seems that the mouse pointer cannot be moved. The graphics mode that is active at time of execution on the VERA is on layer 0 a tile mode, 16x16, 64x64 tile map. On layer 1 a tile (character) mode, 8x8 tiles, 64x64 tile map. Could it be that the revised mouse configuration and coordinate limit system has a bug? I've attached my SDCARD where the game prototype is installed. CX16.zip Can you please try to find what is the problem? - Run x16emu attaching this CX16.vhd. - Load in the emulator equinoxe-flightengine.prg. - run the program You'll first the diagnostics when loading the sprites and tiles. Put a couple of key presses and the scrolling should start, but the mouse is not moving. The player plane is 'for the moment' attached to the mouse position.
  4. done Documentation additions/recommendations. Please review and adopt where it is correct/useful. by FlightControl-User · Pull Request #73 · commanderx16/x16-docs (github.com)
  5. Typo, you are correct, i meant to write $FF6B So this code seems to be correct. This is the API call fragment: However, the zero pages $22, $23, $24, $25 stay 0, regardless if I move the mouse or not. I"m sequently calling this CX16_MOUSE_GET continuously. I've attached a demo prg with source code in asm. cx16-mouse.prgcx16-mouse.ccx16-mouse.asm
  6. Any known issues with the mouse pointer? It seems the mouse pointer "get" api at $FFB6 is not working as expected. Maybe I'm wrong, i baseline the mouse vectors to be returned at $22, which should be available to the user, right? But it's not working. No mouse movement ...
  7. Bingo! Got it working now! So new interrupt vector at $0314 has value $E040.
  8. And the interrupt return vector has changed also . Where was that again ... address vector in $0314 .... let me check ... E040? I know, i need to make that more dynamic ...
  9. So in my program i moved the characters like this when in R38 the program started: In the code the VERA_PETSCII_TILE would have value $F800. So now with the R39, it seems that the character set has been optimized and i don't need to move anything :-). It seems that the character map is already at $01:$B000 and the petscii tiles at $01:$F000 !
  10. I just recompiled my program and ran on the R39 and i get these strange behaviour. It seems the R39 has more changes internally. Will try to find the root cause, but does somebody know if the vera character map tiles have been moved from 0:F800 to somewhere else?
  11. To be honest I checked immediately the md file of the documentation when I read the feedback and it is documented but it's a bit hidden in the details. To make things concrete, allow me indeed to contribute doing a little update to the MD file and I'll send a pull request. The memory layout is well documented already but it's a bit unclear for novice like me. It might be an idea to add a picture and a short text of the overall memory design at the start, and at the explanation of the ram banks, to clearly indicate that bank 0 is reserved for the cx16 designers and shall not be used. (And explain why).
  12. I read exactly my thoughts in your answer. I'm still not there and much to learn further and try things out but your answer confirms I'm on the right path.
  13. The F12 debugger is not showing any labels. I find it extremely hard to use. Not sure if you have the same experience. And also, it is very hard to debug on a running scenario in the middle of raster scan interrupt handling. I use the technique also but find debug lines and then recompile, re-run the most efficient; the other thing i do is to display info on the layer 1 while the background tiles are on layer 0. But this i won't be able to do anymore once i have the parallax layer active.
  14. Don't worry guys. Again, as you can see in this thread, I'm re-experiencing my 16 year old wizz kid feeling again at the age of 52, although now using C and more modern equipment. You see, the reason why i'm coming up with all these strange questions is because i'm digging now deeply into the machine making this game engine. I got now into the phase of "segmentation"; where to put code, where to put data, how to manage the "memory". So this brought me to how to construct the prg file and it appears that prg files for the CX16 will never be larger than 48KB, which is ok. No issue, i just wondered by there was not a continuous RAM space beyond the 48KB border into banked ram 0. Where I could load into bank 0 pre-initialized data like math (sine) tables, control blocks, "stuff" as part of the prg file. I'm in a discovery trying to define the strategy to extend this almost working prototype to a working engine with - levels, - state machine control - more graphics - more tiles - more event types - adding enemy fire- - more bullet types - defences - AI control And sharing my experiences along the way, I have questions, ideas, things I may have understood wrong etc. This forum is the platform to ask these questions and to share the ideas, right? The CX16 platform will become great through its users. I don't know how else it would grow, right? So to come back to the topic, it seems that the design of the game will need to apply dynamic loading of memory in the banks, applying the banks during runtime. It will need to be done by creating several bin files that are loaded dynamically into the banks as the game execution progresses (loading stages). I'm using banks already extensively, and the demo shows, all the sprites, tiles and control data is loaded in the banked memory and then gradually copied into the VERA when needed. Sven
  15. Hello Michael, nice to see you around. Thanks for your feedback. So it is clear now. I wanted to post a bit more on this answer because i feel that there is a huge confusion and that people are reacting rather emotionally on it. My question was humble.
  16. Equinoxe Flightmodel 5 ... Now the ground scrolling using the random tile engine is back alive and added to the mix... Still need to optimize the tile engine as it still is working with zeropage level pointers causing indirect addressing mode to be applied in the generate assembly, causing relatively slow performance. There is still a remaining glitch of those black areas that i need to sort out, and i feel that there is memory overwritten as a specific place that i also need to check further. (not in banked memory by the way, but in the main ram). The below video shows the preliminary result, and it shows also how the tile engine adds to the drawing overhead per scan line. It is already doable, but not good enough. I need to smoothen the large copy action of tiles (drawing each tile row plus at row 31, copying row 32 to row 0 to allow a seamless vertical scroll effect) to be smoothened frame per frame instead of doing all in one frame :)) Anyway, the scrolling now works again and the engine is in progress. Note the debug echo in the terminal emulator with informational text when loading ...
  17. That is not an option if you want the program to "echo" your outputs to the terminal console in the emulator for debugging purposes. I'm using vera registers all the time as I've written earlier. I'm developing a game engine with multiple in memory objects like a memory manager, sprite movement and event engine, tile scrolling engine, collision detection using a spacial grid hashing table, ... I need some kind of debug log in the terminal during execution, as a lot is going on. Yesterday I spent the whole day identifying the root causes of memory being overwritten during execution. So it would be good I can log data using a kernal call CHROUT so it gets echoed in the terminal emulator. ( -echo option ). The issue is that CHROUT writes to the screen on the vera in bank $0 starting from offset $0000. The default screen is 80x60 characters. When the vera base registers have been remapped for other purposes, writing text on the screen using kernal call CHROUT might overwrite the new vera data (like new tiles) at the default $00:$0000 vera base map. And I've identified a workaround which is not perfect but works... The debug output to be generated at lowest level is character per character, so I first do a PLOT kernal call to coordinate 0,0 and then I do a CHROUT kernal call to print one character at the top left corner of the screen. This pollutes my (remapped) vera data with one byte but that is a small sacrifice for the debug benefits I get. And this is done for all the debug text. I don't know how else I can generate debug output at this moment. Don't want to use files because it is slow and consumes a lot of memory and it's not really accessible. What would be nice is some sort of "debug" api feature that can trace outputs.
  18. I'll see if the R38 ROM can be adapted on github and I'll do a pull request.
  19. @BruceMcF Thank you for your extensive answer. It was very clarifying and a very interesting read. You are right, moving IO into banked ram is not a good idea, and indeed, the alternative would have been to move I/O totally to the front. It makes a lot of sense to move I/O to address $0400. But would that not have had side effects to the CX16 compatibility of the C64 programs written in BASIC? I am going to read the detailed explanation in a very detailed manner, as this information is extremely interesting to learn. It is amazing how I am now also starting to understand how actually the C64 hardware worked, address lines etc, and how the addresses were "calculated". And what you've written is very interesting to analyze and trying to understand. I never learned electronics, you see. Sven
  20. Never mind ... Michael has been hardcoding this stuff in the ROM ... x16-rom/screen.s at master · commanderx16/x16-rom · GitHub He did not use the "mapbas" variable to offset the cursor position calculation using ptr... If you would give the ROM to me I would make this more flexible! 1. Add an API in the kernal to offset the mapbase in the vera for basic screen functions (bank+offset). 2. Add an API in the kernal to set the active layer. 3. Add an API to switch cursor blinking on and off. I mean, the CX16 has a FIXED ROM that cannot be switched off. What use is a fixed rom if for more advanced and fancy programming it cannot be either: - used: - switched off to get more RAM and be replaced by customer ROMs (in RAM) ...
  21. Thank you. The documentation of the CX16 actually writes it and I oversaw this. It is clear for me now. Strange that the IO space is at such low area in memory. Was this done by design? And also, I had been noticed that A800 till BFFF was available for use in bank 0 in an earlier post ...
  22. The default text layer used by the kernal is vera layer 1. How is it possible to redirect the CHROUT/BSOUT kernal routines (FFD2) to write to vera layer 0 (yes, i've copied the PETSCII charset to another place). Does anyone know how to do that, or is such not possible? Since the ROM has all the required kernal routines for character output to the screen, i thought such a feature would also be included, but I cannot find it :-(. Is the vera layer hardcoded in the ROM??? note: I understand very well how to write using the vera registers directly. Is using vera directly an option? (does the kernal "understand" which layer is configured on the vera for text mode?) Sven
  23. I agree. Such a function should be part of the kernal.
  24. So is this space between A000 and A7FF not available due to hardware defined addressing? (address line logic on the board).
×
×
  • Create New...

Important Information

Please review our Terms of Use