Jump to content


  • Posts

  • Joined

  • Last visited

  • Days Won


Everything posted by SerErris

  1. Use some POKEs in the vscale and hscale registers of Vera. Both set to 64 gives you 320x240 . The depth is not dependent ... can be anything that fits into screenram.
  2. I bet it is Star Citizen you are working on...
  3. uhh ... and messes up my emu directory Okay, thanks, that explains a lot. I thought it would be actually an sdcard loader.
  4. Hi, does not work for me on Windows r38 emulator. I created a SDcard.img from the files and attached it to x16emu. I can see all the files in the emu and it looks like this: But when I load it the screen is getting scrambled and it stops there: The web emulator does it correctly. but I am not able to start it on my windows machine ... any idea, what happened?
  5. Is this in general true for MOD? So does this apply for any DIVISOR or if not, in which boundaries of the DIVISOR it is true? and #(DIV-1) ; .A % DIV ... for all DIV=2^n where n>=1;n<=7 I tried with my good old Windows calculator ... 21 AND 4 should equal 21 % 5. but it does not. The output is 4 and not 1. Not sure how that works or does it just work by chance with 4? /Edit ... not for any Divisor, but for any Divisor with the power of 2. So 2,4,8,16,32,64,128 ...
  6. That is great stuff. Esp if you write about the things you stumbled across during your learning experience. The X16 project really requires (right now) a bit of understanding how the C64 worked and does not touch on anything that is connected to it. On the other hand, some things work differently and things are difficult to find for a newbie. E.g. even if you know the C64 quite a bit and are used to PEEK and POKE, you will have a hard time to find the memory locations you have been used to in the past. Esp. the Memory Map is on of the things that require documentation. However as things still can massively change, it is not a good investment in time to document the memory map now, as that also might change completely. So your writeup together with other resources will get a better and better picture to enter the platform. BTW: here is another book of great value for the commodore platform ... and a lot of things still hold true on a X16 (also a lot of things are different). https://archive.org/details/Complete_Commodore_Inner_Space_Anthology_The_1985-03_Transactor_Publishing
  7. No. Assembly language is something you need to learn from other sources - like Jim Butterfields book for the C64 still one of the best books to read. Here are some links (depending on the language you speak/read) German: https://www.retro-programming.de/programming/assembler/ English: https://skilldrick.github.io/easy6502/ Here is Jim Butterfields book... http://www.1000bit.it/support/manuali/commodore/c64/ML_for_the_C64_and_Other_Commodore_Computers.pdf Also a good thing to understand the C64 book. It is actually everything that is referenced from the X16 dokumentation (e.g. BASIC, KERNAL calls etc.) http://www.zimmers.net/anonftp/pub/cbm/c64/manuals/C64_Programmers_Reference_Guide.pdf And this documentation to understand all the different inner workings of the Commodores ... very extensive and also quick reference. https://archive.org/details/Complete_Commodore_Inner_Space_Anthology_The_1985-03_Transactor_Publishing The Monitor is covered in this document: https://github.com/commanderx16/x16-docs/blob/master/Commander X16 Programmer's Reference Guide.md#machine-language-monitor
  8. Which one did you get? The X16 one or a full features 104 keys version?
  9. Actually the workflow is already working as you can put nearly any tool into C64 Studio. So from code to run is already there. Debug obviously is not working that way (with the debug keys in C64Studio for step etc. pp.) You need to configure in the Tools section of the preferences a new entry for an emulator and define it as in this screenshot. Works great And if you put -debug in the line as well you can use the debugger inside. However the debugger with step integration and such stuff does not work right now. Also the assembler does not create 65c02 code, but 6502 code. That means the new instructions available in 65c02 cannot get used.
  10. Does Atom/VS Code allow debugging with breakpoints and stuff? Or is that also not working currently? Btw: You can completely integrate the emulator into C64 studio to get your workflow to the point of beeing able to automatically compile and run it.
  11. yes, you can ... there are even DOS commands for that on the C64. I am not sure if all that has been implemented within the X16 yet, but surely will come. look here for the C64 version of that. https://codebase64.org/doku.php?id=base:reading_a_sector_from_disk Also I am not sure if that can be easily ported to the SD card (of the VERA) at all .. But again the C64 could do that, I cannot see any reason why the X16 eventually not get there.
  12. Yes, thanks for pointing that out. I should really check for updates between releases That has been introduced in R38. C64 Studio normally interfaces directly with VICE. VICE has a remote interface to the build in monitor. So it is not a monitor running in the virtual machine (so esp. not like a monitor on a cartridge or ROM) but it runs within the emulator itself. Therefore you can set breakpoints and stuff without the need to change the code in any way. If you hit a certain address the emulator stops execution and shows all values (like a monitor would do). Obviously that is much better in an emulator to do than within a machine. I believe even the -debug option is pretty close already. ... I have not tested it myself. The main issue would be remote control and output of the debugger to inject breakpoints and see the flow inside the IDE together with the source code, the registers and memory segments. Here is the VICE docu on the debugger ... very powerful but not needed for the integration. https://vice-emu.sourceforge.io/vice_12.html#SEC269
  13. I thought about getting a better workflow for programming X16 in assembler. There are several ways of writing code for X16 and to compile it. That is no issue. /EDIT: Already there in R38 2. Debugging within the emulator from outside with any IDE is currently not possible (not that I understand how it would be). Can we integrate a standard interface (like VICE does) that enables IDEs to control the build in monitors with breakpoints and stuff? That would be very possible with a monitor running within the emulator instead of running inside the virtual machine with a rom. The monitor we have is build into the x16 roms. But as Vice does it, the monitor is actually part of the emulator and can be controlled by the IDE from outside. What I am looking for is something CBMStudio or C64Studio does. If that interface is available, I will work together with the guy who wrote the C64Studio to integrate the X16emu ... then we have a full development IDE with Sprite Editor, Tilemap Editor, Color Editor and stuff including full assembler and debugger support .. I have a dream
  14. Yes 2x8bpp does not work. But 2x4bpp works. I would say in any animated form 8bpp is not usable if you use graphics mode and not tile mode. It is simply to much data to draw CPU constrained and also double buffering is not possible. I do not like the cc65 approach ... I will never do and actually do not want to compile and then link my assembler .. I want to have it in my own hand how everything works. I am using C64studio that has ACME assembler included. It creates .prg files, that can be loaded directly into the emulator from the normal operating system. It also enters the typical SYS2062 to run your program at 080E .. ...
  15. AND .. you can set both layers to Bitmap mode However that is most likely not what you want. What you want is: Lets assume you want a 320x200x4bpp bitmap with double buffer You start to use Layer0 for that. You set tile base to $04000 (if you do not need your text buffer, you can start at $00000) then build whatever you want in that screen ... Then you start building your next frame in area starting @$10000 .. after you are finished rendering it, you set the tilebase to $10000 Then you start to build in $04000 again ... flip back tilebase and so on. That is how you can do double buffering with VERA.
  16. It does ... it sets this value in a BASIC variable that is used for all output. Not sure where it is - you can use the monitor and search $100-$3FF for any change after the color command Without now really knowing it I expect that the color command exactly creates this color byte and stores it in this variable to be used by any print char command later on to fill it into the screen ram. The VERA does not know anything about colors in that sense. It has the tilemap information (actually the Screen Ram is a tileset, where each tile contains a monochrome letter and the color byte points to palette entries). So the print char routines are not using any VERA technology. They just write the char to a certain position int screen ram and set the color information for the color byte. Really recommend you read the very good stuff on 8bitcoding.com ( no it is not from me )
  17. If you use 16 color mode (what you are in by default) the VRAM byte $0 0000 to $0 3FFF contain the SCREENRAM for the characters. This is divided into 60 rows of 128 columns each, of which you can see the 80 first columns. (the rest is not displayed). Each Screen position consists of two bytes - 1. The character Byte 2. The color information byte. Each Color information byte consists of two Nibbles - $00 each nibble is one of the hexadecimal digits. So each nibble can take values from 0-15 or better from 0-F ... The first nibble contains the foreground color and the second nibble contains the background color. So if you want to have white on black you can put $10 in the color byte. If you want black on white it would be $01 ... Everything in Video and Sound differs completely from how the C64 worked and how stuff could be accessed. So the documentation does not work and any examples need adaption to get it to work. You can find a lot of good information about the X16 here: https://www.8bitcoding.com/p/commander-x16.html Esp the tile mode of the VERA and how it works (in BASIC) is explained in this article https://www.8bitcoding.com/p/tiles.html ... I like it cause it is not just text but also visually. And obviously you would not get very far without looking at the VERA 0.9 documentation.
  18. quick answer : You cannot read the VRAM with a monitor, nor with PEEK. The reason is, that the CPU cannot acces the VRAM at all. Instead you need to use the VERA registers to read from or write to the VRAM (VPOKE or VPEEK are implementing that).
  19. Kickstarter will bring in greater audience .. thats it. This website will only get people on them that know the product anyhow. Others may never have heard about it (like me - I heard about it in August this Year).
  20. I never said custom printed ... I say custom printed caps is not worth 150$.
  21. Find the answer in this thread above:
  22. I did not say custom printed ... I said Cherry MX switches Keyboard. https://www.amazon.de/REDRAGON-Mechanische-Tastatur-Beleuchtete-Kompaktes/dp/B07CMGWKMT/ref=sr_1_21_sspa?__mk_de_DE=ÅMÅŽÕÑ&dchild=1&keywords=cherry%2Bmx%2Bred%2B87&qid=1599638825&sr=8-21-spons&spLa=ZW5jcnlwdGVkUXVhbGlmaWVyPUEyM0hGWFJNWDEzVTNLJmVuY3J5cHRlZElkPUEwMzE1MzU5MVNMRzRJWUI0NzNYQiZlbmNyeXB0ZWRBZElkPUEwMTI2ODQ1MVkxVzlCRkhWUFZFNCZ3aWRnZXROYW1lPXNwX2J0ZiZhY3Rpb249Y2xpY2tSZWRpcmVjdCZkb05vdExvZ0NsaWNrPXRydWU&th=1 This one for instance ... Or this for 82$ with now real MX blues ... https://www.newegg.com/p/32N-00A4-000P8?Item=9SIAHB09997843&Description=mechanical keyboard blue switches&cm_re=mechanical_keyboard blue switches-_-9SIAHB09997843-_-Product
  23. According to C64 Kernel documentation Secondary address 0 should load relative ... Unfortunately I only have a german commented KERNAL at hand so trying to translate This is in the middle of the load routine and in X we stored the original value of the secondary load address (in your case 0). So transfer X to A and automatically set flags accordingly. The next command is where the key is: Branch if Z=Flag is not set (bne) which mean : Branch if A is NOT 0. And the branch jumps then to absolute loading (e.g. the values that has been got from the file and stored in ($AE) are beeing used, otherwise the paramterers you have given are being written to ($AE) first. Unfortunately I have no idea what the X16 rom will do, as I could not figure out to read it. The whole thing with includes and all the separated files in tiny bits makes it absolutely unreadable to me. I could not figure out at all what the adress of bcc_16 load_iec would be ... So I could not find the corresponding section in the X16 ROM to identify what may be different. The f4a5.load.s does only contain the very beginning and the rest of it is missing. Not sure where it is located in which file and how to find it.
  24. I do not agree ... there are a lot of Cherry keyboards available that cost either a lot less (starting with 49€) or are feature loaded under the roof (e.g. RGB lighting based on game situation and such). Not that I am looking for the later, but as I said - simply having Cherry mx on it does not justify the price, esp as the num block is not needed and it is only a 87 key keyboard. It will never get as cheap as 10$, that is okay and I would potentially even consider a 100$ ... but 200? nope not at all. I then would prefer to remove the caps from the cheap keyboard and put on any Cherry MX 87 keys keyboard.
  25. I would prefer that, as it is easier for me. But to be honest, that might be easier for the team to put the sourceing to the people utilizing their numbers (more hands) and therefore enable more speed for the delivery. Another Idea could be (not sure if that is possible) to create a kit with Mouser (for example) and have a specific SKU on Mouser for that set, so that you can simply order it and Mouser can deliver it - and in the end you have the right stuff in your hands. Maybe a doable compromise to get the burden off of your shoulders.
  • Create New...

Important Information

Please review our Terms of Use