Jump to content

Guybrush

Members
  • Content Count

    38
  • Joined

  • Last visited

Everything posted by Guybrush

  1. VERA's layers wrap around, and you can scroll for up to 4096 pixels in both directions. So, if you have a 128×64 tile map (such as for the default 80×60 text layer), after scrolling horizontally beyond (128 - 80) * 8 = 384 pixels, your first column would start appearing on the right side of the screen, and when you reach hscroll of 128 * 8 = 1024, the first column would be back a the left edge of the screen. The same would happen at hscroll values of 2048 and 3072 and by the time you reach 4096, you run out of bits for scroll registers so you're back at the scroll value of 0 .
  2. I'll try to answer your questions to the best of my ability, everyone is free to correct me on any point . 1. There are 128 sprite definitions, and there is a hard 128 sprites per raster line limit, but there's no 128 sprites per screen limit. Sprite definitions can be changed during the frame, so you can reuse sprites in the same frame, further down the screen. a) Yes, but as stated above, that data can change during the frame b) No, the number of sprite animation frames is limited only by the available video memory (128K total). Each sprite definition points to a location in video memory containing the sprite pixel data, so you can just change that pointer in each frame (or even more often) c) Yes, absolutely 2. a) Yes b) There is no performance penalty besides the sprite limit per scanline (which also depends on the sprite size and the sprite no#) c) 256 colors is possible in 320×240 max for bitmap layers without resorting to raster interrupt tricks; for tiled layers it depends on the amount of memory needed for the tile data (e.g. 1024 16px×16px tile definitions takes 256K of memory, so that's out of the question, but if you don't need many different tiles you can use really big maps) 3. a) Yes, but it requires using raster line interrupts b) Sure, but it would start repeating the layer after 256 lines. But you can also use 64 tiles vertically and just use an empty tile (tile with all pixels using palette index 0) for all the tiles in the bottom half 4. I'm not very familiar with Genesis or SNES so... maybe. But i believe Mode 7 would be pretty hard to emulate.
  3. Well, one big difference between VERA PSG and YM2151 is that YM supports only sine waveforms, while VERA PSG supports pulse, sawtooth and triangle waveforms. That's something you immediately notice and what gives these solutions different "feels". So, if you want FM music, you can use YM, and if you want something more reminiscent of the old 8-bit sound, you can use VERA PSG. Of course, PSG lacks filters and modulation capabilities of the SID chip, but that was the case for pretty much every sound chip of that era.
  4. If you use both data ports on VERA and set one of them to the start address of the source and the other to the start address of the destination, then you can read from one port and write to the other without setting up addresses for every byte you want to move. And if you're interested in the memory map of VERA's internal RAM on startup, you can simply read the VERA registers, that should immediately tell you what mode each layer is in and where it gets its tile data and/or tile map data.
  5. Hmmm... are you a member of the Commander X16 group on facebook?
  6. For the demo of the technique, see this post (not mine): https://www.facebook.com/groups/CommanderX16/?post_id=617425515675213
  7. You definitely don't want to draw the road in bitmap mode. Just create a fixed tile map for the road, a central perspective of the road and make it pretty wide. In the default position (road in the center, a long straight ahead) there will be some amount of horizontal scroll. Then it's just (hehe, just! ) a matter of calculating the right scroll offset for each screen line, depending on the position on the track. For instance, if the road ahead is turning to the left, the top line of the road will have the smallest x scroll offset, with the scroll offset increasing each line until it reaches the default position at the bottom of the screen. If you're feeling particularly bold, you can also simulate terrain elevation. It's all just a matter of choosing the right line of the tile map with the right scroll. Also, you can simulate texturing either by modifying the palette on each line or (a simpler method) create multiple tile maps with different colored tiles and change the tile map per raster line. You can do all the calculations in vsync interrupt handler. Of course, this all requires a raster interrupt for each line where the road is drawn, but since you've already calculated the scroll, it's only a couple of LDA's and STA's per line. As for the background (mountains, sky, etc.), you can use another layer, or you can reuse the same layer as for the road, you just need to switch tile maps on the right raster line. Everything else (cars, signs, trees and bushes) should be done with sprites.
  8. That's most certainly not true. The tile map wraps around when scrolled. So, when you're nearing the left edge of the tile map, you simply load your data into the next column to the left. Since you're already at the left edge, you load your data into the rightmost column. Same goes for any direction. You just need to keep record of what portion of your big map you're currently showing. For instance, if you have a big map, say 256*64 and a tile map of 32*16, then col 0 of you map would be copied into col 0 of the tile map, 1 into 1, etc. Col 32 of your map would be copied into col (32 bitwise-and 31) = col 0 of the tile map. Same goes for rows.
  9. I don't think that updating the entire screen worth of tiles is the right thing to do. Letting the tile map wrap around is. I don't see why it would be so complex, it's all very simple arithmetic, every multiplication and division is with some power of 2. When you scroll past one row, you simply copy new data into the next available row. The same goes for columns. In fact, those two things you can just do one right after the other. If both conditions are true, only one tile (2 bytes) would be written twice. And the best thing is, you can do the copying any time since you're updating tiles that aren't visible on the screen.
  10. @Johan Kårlin May I just ask why are you updating the entire visible part of the tilemap? Simply for scrolling?
  11. One thing that comes to mind is huge lookup tables for fast floating-point (or fixed-point) calculations, e.g. for demos or games using some kind of 3D graphics.
  12. Implementing it is a problem because address decoding and banking (the stuff that's handled by the PLA in C64) is currently done by discrete logic on the motherboard (a handful of off-the-shelf electronic components). Remapping the stack and/or zeropage would require even more logic and a major overhaul of the motherboard layout. Eventually it would be easier to use the same sort of hacks that are used for PLA replacements: EPROM or another FPGA. Not sure it's realistic at this point in the development of the machine.
×
×
  • Create New...

Important Information

Please review our Terms of Use