Jump to content

SerErris

Members
  • Posts

    172
  • Joined

  • Last visited

  • Days Won

    1

Everything posted by SerErris

  1. I would consider buying it, IF there was substantial funding for the X16 project. But as I understood from @Perifractic there is very limited money flowing into the project from a sold keyboard. So I would prefer a kickstarter or whatever to help supporting the project - maybe even a patreon page and get the money directly to the developers instead of funding someone else.
  2. OMG $200 ?? that is insane. What is in there? Gold ? What is the specific Design that has gone into it? The PETSCII caps? If they would be alike the C64 (graphics on the front, not on the top) I might consider it .. but to be honest ... that is by far too much for a standard keyboard without Num block.
  3. Isnt Vera a FPGA logic anyhow? So cycle exact is just releasing the rtl code of it and compile it?
  4. Yes Shift+backspace it is and it was for C64 as well ... Maybe both work, but officially it is SHIFT+backspace
  5. The way it was implemented on Amstrad was, that you could use any command you like and connect it to one of the 20 unused opcodes. You could for instance create a CIRCLE command that draws a circle around any given position and connect it to $20 opcode. The user Opcodes actually are not standardized and are for users individually. But we could define a user command repository, where you can draw from to use the ones that benefits your program the most. So if you are drawing a lot of circles - that basic command would help, as it speeds up the process massively by implementing a assembler routine for it, but keeps is accessible for BASIC. Thanks @desertfish , I will look it up.
  6. After reading C64 manual, read the X16 docs. Start with BASIC and the examples to understand how the computer works. Then get into Assembler ... read Jim Butterfields book: http://www.1000bit.it/support/manuali/commodore/c64/ML_for_the_C64_and_Other_Commodore_Computers.pdf Then read the X16 docs again (esp. regarding firmware and VERA). Work both through the Assembler examples. 65c02 Assembler is not hard to learn (actually very few instructions) and Jim Butterworth book is legend. I would use VICE for the first steps to understand the Assembler examples and to ensure they work. After that you can start working with the X16emu and use it natively.
  7. Is there any possibility to extend the BASIC Opcode in RAM (so user defined basic commands if you want to name it that way)? I am just asking because I learned today, that the Schneider CPC hat this possibility to define the 20 unused Basic Opcodes however you want with normal RAM.
  8. edit ... fixed my inital problem - thanks for you response
  9. Just want to cover some thoughts on the threading. Threading has come up with CPUs with a lot of cycles and the main routine sitting around most of the time and idling. Also having multiple cores requires threads as otherwise you would not be able to use it in a single program. Threads come with at least two disadvantages: 1. you need to make your code thread save. As threads will run asynchronous, you cannot forecast when a thread will finish its task and if this is inline with the main loop. So you need to write message queues and handlers and such things to ensure that you have everything in the right order. That will put a lot of overhead on both CPU and RAM. Even if RAM is not a big issue any longer with the X16, CPU cycles are precious. 2. You need a MMU or you need to program one yourself to ensure that threads are always accessing their memory. Regarding the first point: X16 has a very small CPU that is not powerful at all. Yes it is 8times faster than the C64, but the compute power on your hands is less than an Arduino (ESP-12f for instance with WIFI and USB and other components runs at 80Mhz and with much better CPU. 4USD price range ) . So if you are starting to use thing like threads you need to use Interrupts, each of the interrupt handlers need to decide what to do (actually multitasking/multithreading) and then save everything somewhere (stack), load the current thread environment and start executing, until the next interrupt happens. Depending on the complexity you are wasting 50% of the available cycles just for the thread handler. Remember the CPU and the whole System has no support of that ready. No multi tasking, No multi threading. No MMU. So given all that, it is definitely possible to implement multithreading in any CPU as long as you have enough memory to handle it (and you have on X16), however there is most likely nothing that justifies the overhead. Instead you write a main loop (game loop) and branch into all the individual "tasks" and ensure that it is as efficient as possible and that whatever task you have to complete within a frame fits into the available cycles of a frame (e.g. 8.000.000 cycles/60 = 133k cycles per frame. If you consider that you need at least 2 cycles per instruction, that is not a lot of things you can do within that time frame. (C64 had only 16k cycles per Frame).
  10. I agree that OOP is not the start you need to go and esp not if you want to understand hardware based programming. There are a lot of languages out there that are still not haveing OOP in them (hello Python). Yes you can do OOP programming, but in reality it does not separate the variables inside of an object form the outside world and you do not need any method to access or change them. However I believe the basic construct of programming has nothing to do with Object Oriented and OO can be learned easily after you understood programming directly. It is very easy to write a text based output on any computer. Writing a Windows based output is getting you into nightmares of different layers and libraries to understand what you are dooing and that is confusing new learners a lot. So I understand why OP want to have a simple language on a simple computer. It is just much easier to create your first programs on it than on a modern PC/Mac/Linux Desktop or any other device you can get your hands on.
  11. Hijacking this thread. Is there a way for a reset that does preserve the BASIC memory? I try to reset the screen to defaults including CHARROM and Pallette and was not successful as of now (other than saving and copying the stuff)
  12. Ah ... good to know and understand ... thanks for the explanation.
  13. Maybe you want to have a look at this: https://github.com/commanderx16/x16-docs/blob/master/Commander X16 Programmer's Reference Guide.md X16 has already a much broader BASIC dialect than C64. Some borrowed from new Commodores .. For you .. PSET and LINE are interesting in the context above, but there are others like COLOR or SCREEN ...
  14. The KERAL is actually the all the functions sitting in the ROM required for the bare IO functions for the Commodore Computers to work. BASIC is another part which is interfacing with the KERNAL for more low level access.. It is not the jump table, but it has a jump table. The jump table is in ROM.. but obviously you could copy the jump table to anywhere, (a bank for instance) and change some parameters. However the Jump Table assumes, that you are and stay within the current selected banks. You cannot jump across banks with the KERNAL, as the KERNAL is not aware of banked RAM like the X16 has. It can only bank-in ROMs into the addressable space (e.g. CHARROM, KERNAL ROM, BASIC ROM) and as I said if you are inside the KERNAL, you can only jmp within the KERNAL - not into another ROM bank for instance... That brings me to one question: KERNAL and BASIC live in different ROM banks. So how is it possible that BASIC calls a KERNAL function? What is happening to switch the BANK before the JSR ? The more I think of it, the more my head is spinning. So you would need to do a bank switch, and then the next instruction from the ROM you worked in is not available anymore. Lets assume you have the BASIC ROM paged in (#4). You work in a routine and want to call CHROUT (for instance) from KERNAL. So you prepare the page for KERNAL ROM (#0) and then the next instruction executed is the on sitting in KERNEL ROM ad the address in PC instead of the instrcution in BASIC ROM. Any idea how that works in X16?
  15. Yep, that might be a thing and the approach is different. However the Z80 had so much other thing (other than the memory access issue) like 16bit index registers and other stuff. The concept of pages in memory was also completely new to me, as the Z80, did not know any pages. But anyhow .. the beauty of the 6502 is that it is very easy to learn. On the other hand it is at the same time very difficult to master. You need to be either very bright, or read a lot of stuff that is not officially documented, but hidden everywhere (like in this thread now ). Thanks @BruceMcF for the knowledge sharing .. appreciate it.
  16. Agreed ... as long as you do not write to it at the same time ... you might use it to read some debugging from PC side from it.
  17. Ah ... got it. That might potentially work, but will be quite expensive. You need a card, and all of that and then the SD card itself (which will be minor cost obviously compared to the rest). But yes - might work.
  18. You can open with lock or without ... systemcalls for both exist and there is nothing wrong with it. But maybe the emulator should use a locked opening.
  19. Thanks for the flowers, but non of the examples was from me Credits go to rje (I assume you mean his approach).
  20. Sure, but even if you take the smallest of the tables above, it is 64kb ... so several banks (actually 8 ). And each lookup need to lookup first the bank, than switch the bank and then lookup the value. Yes it is possible, but also slower than expected. Larger banks will even increase. Using the SD card ... not sure how long you have to wait for a single load and also not sure how that even shall work. The SD card will most likely still emulate a IOdevice. But maybe I am wrong. Even if you can access the SD card on block level you need to setup the VERA registers, calculate what block you need, load the full block somewhere and then select the Value inside of the block. So most likely that is also not a good in the meaning of fast lookup procedure. It might be even slower than calculating it. Maybe someone has a good idea how that could be implemented, but I cannot see a fast way. Of cause we do not know how access through VERA to SD card will work.
  21. Yep, I would not consider that a bug, other than that the emulator should exclusively mount it to avoid such tries.
  22. That is by far too much memory .. we only have max 2MB. Yes that would be very fast - no this is not working cause you cannot do anything anymore besides doing calculations. There are other efficient solutions, that still rely partially on lookup tables, but that is tooo much. Regardless of the size of the tables and how fast they are to do the 3d calculations, I cannot see that you get something like Wolfenstein 3D or any filled graphics working in X16. The fill of the areas need to be done by the CPU. And filling in VRAM an oddshaped part of the screen is not fast. It is even slower than filling any memory area, because you need to load the VERA ADDR registers frequently. Each change is a 3 byte write to VERA register for a single byte of data - IF the data is not in any way automatic incrementable. And that is most likely the case with any vector graphics. Eventually you would end up to copy the whole screen from a memory buffer to Vera every time, and that alone will be relatively slow. estimated 10 cycles per pixel in 256 color mode. in 16 color mode you can do 2 pixel in 10 cycles. That will be still 384.000 cycles per frame (320x240). That is roughly 1/20 second if the 65c02 is running @80mhz. In that resolution you could bring out 20fps copy process. However you need to do all the heavy lifting (e.g. calculating the next image and stuff) and write all that to the normal RAM. That will be another 10fps at best (just the loop and the write) .. and will already half your FPS to 10 fps. and depending on the difficulty of calculation ... it is really not much air. So you would need to reduce the viewport massively. Full Screen DOOM or Wolfenstein is not realistic. (I know you did not mention Full Screen).
  23. That solution was btw already in Jim Butterfields excellent Book on Programming 6502 (10 and all the derivates). Cannot recommend it enough if you want to dive into Machine Language on 6502.
  24. Talking about a BASIC Compiler ... here is one that is supposed to work. However I am not sure what happens to X16 special commands ... https://www.c64-wiki.com/wiki/MOSpeed
×
×
  • Create New...

Important Information

Please review our Terms of Use