Jump to content

SerErris

Members
  • Posts

    172
  • Joined

  • Last visited

  • Days Won

    1

Everything posted by SerErris

  1. Hi, I have created a screen setup which uses Layer0 320x240 8bpp bitmap mode. The screen is so big, that it overwrites the screenareas of ScreenRam (characters) and the CharRom. I also change the Palette. After running the program I like to return to the READY. prompt with a working screen. However I am not able to reset it. I can run CINT ($FF81) and that recreates the CHARROM. However it does not copy back the Palette or sets the color scheme (color 1,0). So this works partially, but it does not reset the color pallet. I also tried to set the VERA Reset bit.. but that crashes the emulator completely. The screen goes all blue and nothing ever returns. (I am using a -echo setting currently). You never get any ready prompt or an listing or anything at all back. I also tried to run the vera restore first, and then the sys call to CINT - but does not work at all... looks like the sys call is never getting executed. Any idea? I do not want to load the pallette on my own. Should the CINT not actually do a VERA Reset first and then sets all the registers as required and copy the CHARROM?
  2. Yes .. X16 is much better, cause BASIC is much better on X16 than on C64. As I wrote .. it is really painful and ugly on C64. Not enough space in ROM for C64 BASIC 2.0. The C128 hat much better and the C+4 even better, however the C+4 is a completely different machine and the C128 requires to run in 128 mode to see the new BASIC. In 64 mode you are back to square one as it is 100% compatible with a C64 in that mode.
  3. I would use actually anything then C64 for BASIC. The reason is, that they run out of ROM space and did not imlement a lot of basic things. So you have to use Peek and Poke with weird numbers and you will never get to it - actually very painful. You cannot even plot a point or draw a line on the screen. To be honest everyone had a 6502 based computer (C64 for the most part) in the 80s, but C64 Basic was never good. Also the C64 architecture esp. the video modes are so weird, if you come from any other computer you will think that the developers were insane. Yes it had hardware sprite support, but the pure basic (not the language) design of the video memory was a nightmare. Drawing a line on the C64 is absolutely painful, as the memory is organized in a very weird structure. It does not simply count up the lines one by one etc. So X16 IS a big improvement in BASIC dialect as the developers have implemented a lot of those missing functionality. That will help to avoid all Peeks and Pokes (hopefully). Look at Amstrad CPC Basic. The computer is very simple as well and even simpler in certain aspects. It has a great and full featured BASIC implementation that let you program anything you like without the need for Peeks and Pokes. The only time you need Peek and Poke is if you want to embed Machine routines in your BASIC code and want to poke that to memory and then run the routine. Also I would go with emulation. No reason to buy real hardware for learning to Programm BASIC. Hardware makes a lot of sense if you want to teach how computers work and BASIC is just your vehicle for easy access. Then the X16 is my clear recommendation. It has a much simpler architecture compared to the C64 (the bank switching alone on the C64 is a nightmare and much easier to understand on the X16). Just my personal thoughts.
  4. To be honest, I did not know what this ZP is or why you would need it. I just patched a BASIC program to run under r37+ of the emulator and there was one poke in it. As I had no clue what it actually does, I looked up the old memory address (as of r34 and translated it to the new location). I am no friend of such pokes as it makes the reading of the code painful and currently unstable (things change currently). I simply removed it now. Still do not understand what the AIM of the orignial programmer was, cannot see any reason to use it.
  5. Yes understood and did so - however the demos are not merged at the moment. @Michael SteilNo reason to hurry .. let me do the work ... I just wanted to understand if something is missing. But that explains why I am not able to do it. Good enough for now.
  6. Have you added me to the official maintainers already, or is something missing? Do not see any pull request rights to merge into master. ...
  7. Great, happy to help. This projects gives me so much ... I am happy to give back to the project where I can.
  8. Hmm ... according to this picture the US keyboard has the + and = at the same key ... just shifted. On a German keyboard this is the "´" key and the "`" key. The later one is with SHIFT. The documentation should better read CTRL-= and CTRL-SHIFT-= It works ... however the same key is in X16 the "UP ARROW" key.
  9. Can someone tell me what Chars are that on a DE Keyboard layout? Ctrl + = and Ctrl + + will toggle warp mode. I have no clue how to enable warp mode or how to identify I am in warp mode. Any idea?
  10. Hi all, I created a ZP Map from the .sym files in excel and also for all the individual .sym files (e.g. BASIC and others). So you can now search for symbols, sort the list (to be an ordered list by address etc.) and do other stuff with it. The Map enables you to convert from older releases of the ROMs (and EMU) to the current versions. Esp for the BASIC programs where people are poking in some ZP addresses and you have no clue what it was for and where it is now. Inside the excel you will also find the full rom.sym map of R34, so you can search here for addresses and look the symbol up in the other table .. Memory Map R38.xlsx
  11. HI Michael, do you know who is maintaining the demo repository? I am working on updateing the Basic examples (first) to get them to compatability with R37 (now R38) release. But pull requests for demos just sitting there. I would even volunteer to maintain the demo section. Please let me know what you think
  12. It is also much better to maintain .. most likely you will be able to replace a standard PSU even in years down the road. If it is a brick (like the C64 one) at best with multiple voltages, you will get into trouble purchasing off the shelf items.
  13. If you put data to the screen directly, you need to use the screen rom character codes and not the Petscii /ASCII codes. You can find a mapping here: https://www.aivosto.com/articles/petscii.pdf ... screen ram requires screen codes. If you want to put ASCII codes, you need to use the CHROUT kernel function
  14. The code you referenced is for an older Version of VERA (looks 0.8). The whole register setup as well as were you find Pallette and Sprite information has changed. Where VERA had 16 64k banks it now has only bank 1 and 0. So that code will never work with r37. But with the docu from VERA 0.7 or 0.8 you can find out what it does and adapt it pretty quick.
  15. Are you doing it in Basic? Maybe the drawing routines should be Assembler at least? Or you might want to translate into C and compile with CC65...
  16. That is interesting ... It is definately BASIC but still looks very machine near
  17. Found the solution ... Modulo is the answer (one of the commands I allways missed in C64 Basic). For any given 16bit address the following works: 10 ADDR = ADDR-320 20 HI%=INT(ADDR/256) 30 LO%=ADDR-INT(ADDR/256)*256 The last line can get optimized of cause by substituting (ADDR/256) with HI% and avoiding one division. 30 LO%=ADDR-HI%*256 BASIC is not only painful slow, but also painful complex for such things. Where in Assembler you could do a simply subtraction and then have everything you need ... Even with the 3 byte ... everything is just there. That is where Assembler is beautiful. However have the floatingpoint calculations in pure assembler is painful ...
  18. I will write it next in pure assembler ... But I wanted to have a demo in BASIC for easier entree for new guys coming to the platform. I now also found a way to get the calculation right now. The only thing open is the question how to move the char rom data and the screen ram ... But this is not that difficult. I know where to start. Thanks a lot for all your input.. helped to get it done. Attached is the current version. It does the Mandelbrot (and pretty fast for Basic and if you compare to a C64) and in up to 256 colors. To be honest - I am not sure if I can reach my goal. Actually the code is pretty much unreadeable with all the Variable Names 2 char long. I will expand them keeping them Unique for better readability.
  19. Ohh ... CBM BASIC does only recognize 2 letters of the variables ... Those need to be unique accross all variables and obviously TAXY is not unique - so for the interpreter it is allways the same variable I am talking about. After correcting this it works ... until a certain point - this is the error I get. This happens in this line: 30060 AL%=INT(AB AND $FF) So actually everything works fine until I reach the first address that is smaller than $FFFF. Then I try to continue to convert the numbers. However that fails with a number higher then 32767 I try to select the lower byte of the address ... but that fails .. I assume for now that AND works on an Integer, try to convert the float into an integer internally and that is not possible as the number is to large (>32767). In assembler all that would be very easy to do, but I am unfortunately in BASIC for this demo/education ... So any ideas how I can get the lower 8 bits from a BASIC floatingpoint number?
  20. So I would need to set the screen start to something at the end of the buffer (with KERNAL I assume) and also need to copy the charrom to something at the end and point the VERA to it with a KERNAL function? How do you do this in Basic? Pokeing addresses is not an issue, but actually calling a Kernal Routine with specific parameters in registers ... that might not work.
  21. Hi I need your help. I do not understand at all the behaviour of this code and why it does not work. The following is just a code fragment for me to undstand BASIC calculations on Commodore. The original AIM is to compute a VRAM address in three bytes. The original code did not work and allways put out -320 for all paramenters and I am puzzled ... I do not understand why this does not work (not at all). The code is a part of a code that shall copy one line of bitmap data to another line. Actually it copies line 0 to line 239 and line 1 to line 238 and so on. For that I need to calculate the start address of the target line. I store the target base address in TAD and then need to calculate the 3 Bytes for the VERA address + Increment. For that I first define some Variables: TAD = Target Address TADP = Target Address Page TADB = Target Address Base (the lower 4 nibbles of the address) TADH = The high byte of the TADB TADL = The low byte of the TADB Together the address is then TADP,TADH,TADL ... However ... the result is actually -320 for every parameter ... The stuff @40000 and up is just an HEX output routine, I cannot really work with DEC numbers on addresses ... Attached find the output. So any explanation why that does not work at all?
  22. So char is actually tile and map data for VERA? The ROM just uploads the fonts as Tiles and the Map is the screen and color information for each char?
  23. Hi, I have written this Mandelbrot program, that outputs a Mandelbrot in 256 colors (potentially .. as I do not use depth 256 it actually uses only 20 colors). I attached the BASIC file in full detail. I struggle with some issue around the Video RAM that I hope to get some insight from you guys: I have no clear idea of what sits where in the Video RAM as per default. The pagination of VPOKE ($FFFF+1 bytes per page) is painful to use in a scenario where you need to access VRAM of multiple pages. (explanation below) Is there any efficient way of copying areas of Video RAM to other Areas? This process in BASIC is so painful slow ... (more details below) Okay now to the individual parts: 1. I could not find any documentation of what is where in the VRAM. I am talking of the Area $00000-$1F9BF. That is 129,472 bytes of VRAM. I need for my screen 320x240 bytes of VRAM = 76800 ($12C00). I started with 0x4000 first and realised. That I am overwriting something (char ram, or color ram or anything alike). Then I put my bitmap start to $0000 ... which was no better. I did not find any area in VRAM that has consecutive space available for the whole screen. So a documentation what sits where and how to tell the VERA chip, where those addresses are is welcome. Could not find any documentation on that. At least not in the VERA docs - also the X16 docs does not have this information. So I could not find any way to define where VERA finds char and color information in VRAM. This is how the VRAM looks like if I use $0000 for bitmap start address (see VERA_VRAM.jpg). To get myself educated: What is the best way to identify such information? Looking at source code for the ROM? How would you deal with the situation? That the whole char memory (char ram and color ram) is getting destroyed if you are using 320x240x8 screen mode? 2. Pagination of VPoke command. It looks like that this is something from before Vera 0.9 implementation. The Video Memory is from the point of view of the VERA no longer paginated. It is a 17 bit addressable space. As such the bank thing in the VPOKE does not make to much sense anymore. Instead we could simply use a 5 digit hex format - so the basic command accepts 17bit addresses. It could be either hex ($0-$1FFFF) or decimal (0-131071). This can then be directly written to the three address registers of the VERA. Why I am talking about this? My Mandelbrot is trying to optimize the calculation time by rendering only 50% of the image and then mirroring it at the y axis. The problem is, that I have in between a jump in the page as the screenram obviously does not fit a single page now. So I have to calculate the right address and then check every time if the put address is above FFFF and then if so, subtract $FFFF+1 and add X and then VPOKE to the page 1. That is a very painful and time consuming process. It is so time consuming, that rendering is not much slower than copying the screen. Parts. This is how I tried it (still bugged, not giving me the expected result and erroring out with an error message I cannot read, because of the destroyed char mem). The code is supposed to read the lower half of the screen (lines 0-120) and copy to the upper half but mirroring the lines (line 0 goes to line 240 and so on). 3. Now one of the issues with not direct addressable video memory is: As long as you do not write consequtive bytes to it, it is dead slow. Maybe I am doing a stupid thing here and copying should be done different, but I did not find anything better for basic. For rendering the image I am simply using the increment Feature of the Vera and then just putting out one byte after the other. But for copying that is not possible as I would need to read a byte and then write a byte to completely different addresses. Any idea to improve the VRAM copy process? I cannot believe that this is the only possible way to copy VRAM. Is read from the data byte also incrementing the address? Can I use the two addresses to increment two screen regions at a time? (e.g. I set register 0 to start of copy source and register 1 to start of copy dest, then read from data 0 and write to data 1 ? That should speedup the process and in my example would be much faster as I could copy a whole line in one shot. Mandelbrot.bas
  24. Thanks for the answer. I expected it not to be very direct as it is basic commands. As the whole purpose of the demos is educational or understanding the principles ... This is what I included now into the source. It also will make it more independent on any future changes.
×
×
  • Create New...

Important Information

Please review our Terms of Use