Jump to content


  • Posts

  • Joined

  • Last visited

  • Days Won


Everything posted by SerErris

  1. So the result is similar to a compiled basic or a compiled c code? Do you use the 65c02 opcodes already? They could speed up certain things (e.g. bittests or bitsets etc).
  2. An external math co processor could be done on an IO extension maybe. But that is most likely even not doing any floatingpoint math... a good mul/div would be already great for integers that are longer than 16bit (e.g. 32x32=64bit mul). But to be honest, that is not really required for any games... 16bit math would be good enough. A math chip would "only" speed up the calculation. Esp. if you are talking about wireframe graphics like ELITE, the limited CPU is really slowing it down. However ... all the 8bit computers had to live with no multiply available. The 6502 series even need to live to that for any addition it needs to go to the memory. This is now deviating from the original topic a lot. I have no clue how the math co processors (8087 for instance) actually worked, but for 6502 there is no such thing available. A math coprocessor would be something that has IO address space mapping for example two data registers and a command register. The two data registers can then be multiplied, divided, squared etc. pp. The biggest issue would be the handover or wait for the coprocessor to execute the result and then continue. The 6502 does not know any of those integrations. Maybe a brk could work, but any interrupt (not just the coprocessor) would reset it. Maybe a quick loop looking at a flag register would do. However the whole thing would be asynchronous and therefore difficult to implement. Interesting read: https://retrocomputing.stackexchange.com/questions/9173/how-did-the-8086-interface-with-the-8087-fpu-coprocessor
  3. Yep, somthing like an Ultima IV thing. The graphics was tile based anyhow, but it was a very small part of the screen actually showing the graphics. That makes perfectly sense. You could have a 16 color text layer and a 256 color 8bpp bitmap mode on the other layer as a window or such. Very good.
  4. The future will tell how much of a constrain is to have no direct access to the memory with the CPU one one hand and the demand to do everything with the CPU in VRAM on the other hand. Copying larger areas of VRAM will be painful (anyhow as it is a CPU task) but esp. with the VERA implementation as only some structured copy will work efficient with the auto increment. If you need to copy blocks of memory in an X/Y fashion it will require frequent write to the VERA ADDR registers and that will slow down the process. So I assume TILE Mode is the mode to go for anything that needs frequent movement/copying as it can be done in a different way with very low amount of data movement from CPU to VRAM.
  5. Hi fractal256.bas works. Tried it from the repository. It looks like a garbled screen, that is even getting more garbled .. however after 10 seconds or so you seen in the first line some ping/violett movement ... that is the fractal creeping over the screen - not not fast :-). fastfractal256.bas was unfortunately an upload missing a lot of thing, not sure how that happened. I attached the correct version here ... Hope that helps in the meantime. Ah and of cause - these files need to get copy and past into the emulator. They are not BAS files in the meaning of a X16 save command (not coded, but pure text). BTW: The garbled screen exists because both programmers (fract256 and me) were to lazy to wipe the screen before activating it. The wipe process is pretty slow. Also in the two programs, you see different VRAM layouts. fract256 starts at $0000 with the bitmap and therefore overwriting the CHARRAM of Layer0. Also the CHARROM is kopied to $0F800 and is sitting in the middle of the screen, where you can see it. That is overwritten by fract256 as well. After the program finishes, you need to reset the C64 cause you cannot read anything anymore. My approach is preserving the CHARRAM of Layer0 by starting at $4000 and copying the CHARROM to $1F000 and changing the Tilebase to preserve it. Works great. I also believe that the CHARROM should be copied by default to $1F000 to keep it out of the way. It sits really in a spot were it hurts for 320x240 modes. fastfract256.bas
  6. For 320x240 graphics mode (x8) you need to move some stuff around, or work only with one layer. The Map for the textmode allways takes $4000 bytes. The Charrom (tile map) takes another $800 byte (if I did not remember wrong). 320x240 takes 76800 bytes ($12C00). So the easiest way is to leave the Textmode where it is ($0000-$3FFF) then start your layer 0 at $4000 and move the char rom to $1F000 (the tilemap). That leaves some empty space above the tile map and the beginning of the other VRAM parts (PSG, Sprite and Pallette). And you still have some space between $16c0 and $1F000 for your sprite data. Does anyone know, maybe from an older thread, why the charrom is not loaded to the end of screenram? Sitting at $0F800 is cutting the VRAM in half and sits in the way.
  7. Yes ... Screen $80 is doing this. But still you need to handle the layers or you see both ... (text in front of the graphics) Sorry, that was crap .. that was 320x200 mode ...
  8. I had an discussion on the github repository with some other guys. They pointed out that this is a bad idea to just store a 0 in the CTRL register, as it also holds another value (bit1). So you should leave the rest of the byte intact. Therefore this should be a better way of doing so (only works on 65c02 - not on 6502). The TRB instruction (test reset bit) clears a bit in the memory (and actually tests its status before clearing) indicated by the value in A. So with this (and the TSB instrcution (set) ) you can influence just the bits you want. Same is btw true for the VRAM highbyte - even if that can be set completely as no other registers are depending on that and it just defines the highest bit and the increment amount and inc/dec flag. C64 style would be:
  9. Seen it on FB already. Looks fantastic. I also love your sprite
  10. Agreed .. I would be one of those guys. When will you have the chance to build a whole computer on your own? Love it. But I can understand all the concerns. They are valid and it is a huge soldering project.
  11. I believe that you save the parsing and some other stuff. So maybe it is faster.
  12. I think as more we get tracktion in this forum (and we are getting more and more people on it every day) the more we will get people to help. You could also restrict help request to a specific section of the forum, where you state right at the beginning that there is no support from the main development team in the soldering and that any question and help will come from the community to set expectation right. And yes a disclaimer on the project site as well as on the kit itself "IN BIG RED LETTERS" will help to understand that it is not for the faint hearted.
  13. The Characters are stored in VRAM and can only be accessed via the VPOKE command (or via VERA registers directly). The standard location of Screen starts at 0,$0000. Each character has two bytes. Mode 0 1. Byte is the Screencode (not PETSCII - same as C64) 2. Byte is the color entry from the Palette 16 colors 4bit for foreground and 4bit for background color. The Screenram is organized in rows of 256 bytes, where 160 are used for each line. (80x2). First line starts a $0000, second line at $0100 and so on. Easy, right? You have 60 lines of Characters. (16kb). So the screen goes from $0000-$3FFF in VRAM. Screenlayout (S=Screencode,C=Color) $0000 SCSCSCSCSCSC ... (256 bytes) $0100 SCSCSCSCSCSC ... In other words, if you want to out an A in 20,40 you do the following 10 X=20:Y=40:C=5 20 AD=(Y-1)*256+(X-1) *2 30 VPOKE 0,AD,$01:REM PUT CODE A 40 VPOKE 0,AD+1,C:REM PUT PALLETTE COLOR 5 Hope that helps. /edited: some errors in there as Mode0 is 16 color mode and the color byte has a different setup.
  14. That was not the point ... and even there you already have an emulator. It is there is no need to run it on an FPGA. Simply cannot see any reason to do this. Either you want hardware - go with X16 - you do not want hardware - take the emu or any other available option.
  15. Yep, that is the easiest to use and understand, however Steves version is shorter. It is using the trick that the letters follow the numbers .. great idea.
  16. Maybe it is good to start very basic and work your way up. The same is true for if then else. It is either else or goto, does not matter. Most languages do not have a goto instruction. The problem is that else is very slow the goto variant is also much faster which is most likely not a concern. Easier to read for someone not that familiar with a simple basic or even assembler dialect, so maybe it is good to implement and have options, however even the C128 implementation is very limited (one line if instruction)
  17. And much slower . I write the color directly to VRam using the autoincrememt feature of Vera. But this is also a very good example more BASIC stile and good to understand. The issue with C64 Basic and also this version is that good to read is heavily inefficient (read slow). and to speed up on the initial diagram you should reduce maxdwell to 30. You will not be able to see any difference in that resolution ... I am not sure if anyone have done a c implementation. I next aim for a assembler version. The required math make my head spin already. We need long int mul/div ... phew
  18. It is not the vpoke that shifts it. It is that the screenram has another coding (not Petscii) . You either use CHROUT or convert Petscii to screencode yourself. I never understood why the did not simply ordered the chars in charrom as in Petscii directly. Anyhow that is what it is now. Petscii<>Screencodes
  19. Iovectors will not wipe the palette as this is VERA internal. On reset VERA resets the pallet, and that would be okay. I could the. Run the CINT to load the Chatroom again but I cannot get it to work.
  20. Look at the demo directories there are some Mandelbrot already. Two 320x240@256 versions ... it is running some 20-30 minutes for a full run.
  21. There is another potential. You just do. It provide ready to use ROMs but just Diffs to the cloanto ROMs . That way every one need to purchase a copy of the cloanto ROMs and then patch them. That should be possible. and yes you can put the complete X16 on a DE10 Nano. Also the DE10 Nano comes with quite a few GPIO pins. You do not need any of the expansions and can use them as expansion port. Still I do not see any point in doing so. If you want hardware you go for certain reasons the X16 way. If you do. It need the hardware ... why then bother with an FPGA? Run vice with a C128 or Frodo for a CPC or even Amiga or ST in an Emulator. You get everything you need there. X16 does not give you anything better or more.
  22. 6502 is also very bare bones ... you cannot even add x to a. I grew up on a Z80 and never understood why people loved the 6502. It is most likely a nostalgia thing, as the C64 were everywhere and people had access to a 6502 . Z80 was much more in UK and in Germany present and still compared to Commodore a fraction of the Market. However looking from today’s perspective the Z80 was much easier to program for real things. For learning assembler in general the 6502 is pretty good as it has only very few commands to learn. The addressing modes then makes it difficult to understand. Esp Indexing has some serious limitations that you need to work around and that no one would put in any CPU anymore those days.
  23. I agree, I do not see any reason for else. You do not need to do anything it works out of the box like that: So we even have a ELSE with multiple lines already in it. Yes it is a little bit different to write but it is not an issue and easy to understand after you worked with it.
  24. So if I to restore ... the cint will never get called, cause my memory is gone (afaik). I just think the pallette stuff should be part of CINT. But it currently not. Not sure if that is considered a bug. Also the Pallette is created by the VERA chip. IOINIT does not restore the palette.
  • Create New...

Important Information

Please review our Terms of Use