Jump to content

Guybrush

Members
  • Content Count

    37
  • Joined

  • Last visited

Community Reputation

22 Excellent

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Well, for one, you could not change the palette at all . Of course, you could change the background color registers (1,3 or 4, depending on the display mode), the sprite multi-color registers (2) and sprite color registers (8), but you'd have to time your code very precisely. And then there are badlines . On a normal line with no sprites, you get 63 cycles for PAL, and 64 or 65 for NTSC. That's 23-25 cycles off-screen, even a bit more since you only have to perform your writes in the invisible part of the scanline. If you're changing global color registers that's just about enough time to update 3-4 of them if you use self-modifying code (to directly update color values in LDA #val instructions). On a line with sprites, you lose up to 16 cycles in the invisible part, but if you're changing sprite colors you are more flexible in your timing because you know when the sprite is being displayed and since the sprite color affects only one one sprite... you get the point. Long story short, on the C64 you also need to design the screens carefully to make big changes to colors.
  2. It's simply impossible to update the entire palette during one scanline, even if you use every available hardware trick. There's only 254 (266) CPU cycles per scanline, the exact number depends on whether the CPU runs on dedicated 8 MHz clock, or a VGA clock divided by 3 (25.175 / 3 = 8.3196666 MHz) . Since a simple LDA/STA combination to read and write from/to VERA data registers takes 8 cycles, even if you completely unroll the loop, you can copy 254 / 8 / 2 (2 bytes per palette entry) ~= 15 palette entries. And I'm not even taking the KERNAL IRQ handler overhead into account. Even if there was a DMA chip somewhere in the system, it couldn't update the palette in one scanline beacuse it would need 256*2*2 = 1024 cycles, which also means that even a DMA internal to VERA couldn't do it because a VGA 640x480 scanline is only 800 cycles long. The only way to update the entire palette in one scanline would be to have a relocatable palette. So, you can only change a few colors each scanline and must design your graphics accordingly.
  3. Be aware that VERA hardware will probably have very different timings. The emulator renders the current line into the buffer in one cycle (from the CPU's perspective), while real hardware will be rendering most of the time during the scanline. If I'm understanding things correctly, real VERA will actually be rendering the next scanline into 3 separate line buffers (sprites, layer 0, layer 1) while it composes and outputs the current scanline from its line buffers. Which means that VERA is actually using a sort of scanline double buffering internally. See this comment from VERA's designer, Frank van den Hoef. I suppose VERA hardware could latch the contents of its registers (layer settings, sprite settings etc.), but it's not going to be latching the VRAM. Therefore, writes to VRAM might affect the rendering of the scanline on real hardware. And if VERA doesn't perform any latching of its registers, any changes of those registers may also affect the rendering of the current (actually, next) scanline. So, it really remains to be seen how the real hardware handles the rendering and what are the exact timings, e.g. when does the rendering of the scanline start/end and which, if any, registers are being latched. At this time it is only safe to assume that any changes that might affect the rendering of the scanline can only be made during a small window, but since we don't know where and how long this window is, we're back to square one TL;DR the emulator is not at all accurate when it comes to line interrupts. Any effects you create and test with the emulator may or may not work on real hardware. YMMV.
  4. @rje Please be aware that 256x256 tile map is really not usable since it uses 128k of VRAM (256 * 256 * 2bytes). I suggest you use the tile map size only slightly larger than your visible game area, and load in new columns or rows as needed. And just try to wrap (pun intended) your mind around the fact that tile layers wrap around
  5. Character modes are simply two kinds of tile mode where there's 256 different tiles (characters) available. The other tile modes make 1024 different tiles available, in sizes of 8x8, 8x16, 16x8 or 16x16 pixels. Also in 1, 2, 4, or 8 bits per pixel, and in map sizes of 32, 64, 128 or 256 tiles vertically or horizontally, in any combination. So, there's really 4 tile sizes * 4 bit depths * 4 map sizes horizontally * 4 map sizes vertically = 256 different combinations per tile layer. Oh, and tiles in these "real" tile modes can be horizontally and vertically mirrored. I suggest you read the VERA Programmer's Reference thoroughly and try to understand the tile modes, because they're VERA's main strength.
  6. Why can't you use tiles for the shoreline?
  7. VERA's native resolution is 640x480. That's 640 pixels horizontally by 480 pixels vertically. So, there are no 640 lines, only 480. Of course, there's also the part where there's no image output, but according to http://www.tinyvga.com/vga-timing/640x480@60Hz, even then there's only 525 scanlines. Anyway, I believe we can ignore those extra 13 scanlines we are not able to set the IRQ for.
  8. It would only require changing the CTRL register's ADDRSEL bit to set the active port while reloading the address registers but that's just one register instead of three. If you don't use any of the KERNAL's graphics functions then you have complete control of the VERA and you can be sure that nothing else is touching the address registers and the CTRL register. Then you can simply do LDA #$01, ORA $9f29 when you enter the interrupt handler and LDA #$FE, AND $9f29 before exiting. That's just 12 cycles instead of 15 when using the stack. I know that's not that important on Commander X16 compared to C64, but I just can't help myself .
  9. You could possibly set your code up in such a way that VRAM access uses port 1 and sound register access uses port 2.
  10. Because that area stores variables that are probably often used, and if they were in bank 0, then most if not all KERNAL and BASIC functions would need to switch banks all the time. Imagine calling a KERNAL function with a parameter that references a memory area in bank 2 for instance... now if KERNAL needs to access its variable(s) stored in bank 0 for each byte it need to process, that would require at least two bank switches per byte processed. Not a very efficient use of processor time, is it?
  11. As per the Commander X16 documentation on Github: This is the allocation of banked RAM in the KERNAL/BASIC environment. Bank Description 0 Used for KERNAL/CBDOS variables and buffers 1-255 Available to the user
  12. It's most probably made by changing a bitmap layer's tile data address for each scanline.
  13. I don't know what you expected... there's (almost) nothing more vintage than 6502
  14. @svenvandevelde I would just like to say that even the Amiga and Atari ST games were 320*200 or something similar. So were most the PC games well into the 90's. Commander X16 is an 8-bit computer, and those were 16 or even 32-bit. Use the 320*240 mode for games (or software in general) with loads of colors and sprites. Use the 640*480 mode for GUI applications or with 2 or 4-bit color. If you want more memory, fork the emulator, it should only be a couple of changes.
  15. I believe the idea is to use a beefier FPGA to run all (most?) of the chips... CPU, VERA, VIAs, YM, address decoding logic, the whole shebang. That would leave only RAM, ROM and perhaps some glue logic as separate physical chips.
×
×
  • Create New...

Important Information

Please review our Terms of Use