Jump to content


  • Posts

  • Joined

  • Last visited

Recent Profile Visitors

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

Guybrush's Achievements

  1. Unfortunately, the X16 is not an Amiga and doesn't have a 3-bit color mode.
  2. The framebuffer address range probably overlaps with the address range of the PSG (programmable sound generator) in VERA's address space.
  3. You do realize that each tile instance (in tile mode, not character mode) and each sprite has a 4-bit palette offset field which allows you to use practically the entire 256-color palette? I don't think that would be any different on an X8.
  4. External RAM requires 8 data lines and at least 16 address lines (essentially FPGA pins) and VERA's FPGA doesn't have enough of those (it currently uses 8 data lines and only 5 address lines). A bigger FPGA with more pins would also be more expensive.
  5. But there is no need for dual-port RAM if the processors run on opposite phases of the system clock since memory accesses never occur at the same time, they are interleaved. There's also no need for dedicated RAM (apart from zero and stack pages), it would only complicate loading the data and code for the second processor. Let the programmers use RAM as they please.
  6. Well, we can always build an emulator for our non-existent dream computer. It wouldn't be much different from where we are right now with the X16 .
  7. A second 6502 could be used for playing complex music scores, generate PCM effects, bit-bang the I/O, anything that a simple DMA couldn't do. And it wouldn't take much extra logic on the board or an expensive FPGA (if the timings aren't too big of a hurdle). And both could be running code from ROM or RAM, you'd just start the secondary CPU after the first one initializes some RAM locations to signalize the second one that it is, in fact, a secondary CPU. Of course, paging would be a real pain in the a$$ because each CPU will most likely need access to different pages, but I guess that it could be solved with another set of page registers and a few extra logic gates that would switch active page registers depending on the clock phase. Now, stack would be a whole different problem .
  8. Two 6502's could also run on opposite phases of the clock, like 6510 and VIC-II run in the C64 and access memory without DMA or dual-port RAM. If they need to signal each other, they could use a VIA to signal interrupts. I'm not sure if both could access the same hardware (except memory, of course) because the timings might be a problem, but if you dedicate one of them to handle I/O, sound or video, then they don't have to both access all of the hardware.
  9. Or you could simply build a lookup table
  10. No they don't. If you really need scrolling, you can fake the bitmap mode with tile mode. Since you're only using 160x120, there should be no problems having enough different tiles.
  11. 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.
  12. 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.
  13. 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.
  14. @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
  15. 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.
  • Create New...

Important Information

Please review our Terms of Use