Jump to content

rje

Members
  • Posts

    1028
  • Joined

  • Last visited

  • Days Won

    31

Everything posted by rje

  1. I'm slowly building a kind of C toolchain so I can program interesting things on the CX16. Now it's time to start thinking about a PSG interface. With sprites, I've had success by defining a sprite record, then writing functions that do basic sprite things. I think that is how I will approach the PSG as well. I've muttered about a general PSG API in other discussions on this forum, so I'll probably dig through them to figure out where to start. Obviously, a voice definition struct would have the voice number, waveform, volume. Would it have EVERYTHING, including frequency? Then the functions just take what they need from the struct pointer? My thought is I don't want to multiply typedefs. 1. Does it make sense to have most or all data in one typedef? 2. Does it make sense to have ADSR data in there as well? 3. Does it make sense to try to implement envelope control (in C)? I suppose there will have to be an external "clock" that calls a C envelope manager, which means there will have to be one sound structure allocated per voice. And yes, that sound "structure" is probably just going to be a hunk of contiguous memory that an interrupt-driven assembly routine could also handily work in instead. 4. What else am I missing?
  2. Very true. That's a good option. But I'll have to stew on it for awhile. However, I think before I get to that point, I want to write a simple PSG interface in C.
  3. I've started thinking about how I'm going to interact with the map. The ship should "stop" when it hits land, and a landing party should take over movement. The ship's movement needs to be finer grained. (easy) The landing party should interact with settlements. If I have enough VERA RAM left, I want sprites to define a few key buildings (maybe 16 x 16?). In this way, the landing party can interact with the town without requiring a separate town map, and it keeps essential things without adding stuff I don't want to do. Replacing the "settlement" sprites gives me 8K VERA RAM to define buildings and groups of people. I can re-use the settlement graphics and chop them up into some of these smaller, 16 x 16 sprites.
  4. So. Yeah. I'll have to revert to the old school method of using shoreline sprites. I figure one 8 x 64 "vertical shoreline", one 64 x 8 "horizontal shoreline" (I can flip them based on what I need), and a 16 x 16 "inner corner adapter" (which I can flip on either axis as needed). I'll sacrifice one of the terrain sprites (4K) for this. 512b: Horiz Shoreline 512b: Vert Shoreline 256b: Corner Also, I can stop overlapping the sprites. Current overlap is 8 pixels on every side, which means my 8 x 8 grid covers 384 x 384 pixels. I can now move down to a much more reasonable 6 x 6 sprites, stay at 384 x 384 pixels, but have more interesting terrain. AND this gives me room for a couple of badly-needed tactical sprites.
  5. Good idea, thank you. I'm also thinking about using characters for the ocean background instead of sprites. I guess that means I'd have to scroll a character layer too. Going to characters for the background "ocean" also has the benefit of not overlapping the terrain sprites (I overlap because each terrain sprite is, by itself, essentially an "island" with a jaggy "coastline"). *** UPDATE. VSYNC! Can C code do that? Ohhhh, I'd write an assembly interrupt. OK.
  6. I should be able to get away with simple, blocky sprites, similar to Pirates:
  7. Yep... I was thinking 8 x 64 and 64 x 8 too, but yep. The sprite block swapping is causing a bit of flashing effects. I'll think about that too... I might have to swap out sprite definitions off-screen. Don't want to go as far as double buffering, but...
  8. Okay with that minor crisis averted, now I can do some real work. My map is 8 x 8 terrain sprites, and I'm going to scroll them. I THINK what I'll have to do is: * put the map-sprites behind the default text layer * draw a thick "frame" slightly overlapping the map using reverse-spaces Now the tricky part. * When the player moves, the SCROLL X/Y OFFSET is changed, NOT the actual "position" * When the X OFFSET < -24, Then the x position is decremented and the x offset is changed to +24. * When the X OFFSET > 24, Then the x position is incremented and the x offset is changed to -24. * Similarly for the Y OFFSET. "Position" tells us what terrain to draw in each tile. "Offset" tells us what screen position to draw that tile. ...something like that anyway.
  9. If I ever go off the deep end and actually become a true tinkerer I'd bid on something like this and, perhaps, gut it -- assuming it has multiple problems (mainboard, power supply, keyboard, monitor, who knows). The case is in good shape. https://www.ebay.com/itm/115005318802?hash=item1ac6d9e692:g:K7MAAOSwTPNhS9Td Or, more perversely, a TRS-80 Model 4 case... $75... https://www.ebay.com/itm/194385725279?hash=item2d424ac75f:g:AnYAAOSwqp5hTJDi
  10. So in other words, I'm better off figuring out how to get an X16 and its monitor to fit into a PET frame. XD
  11. OMG I CAN'T DO BINARY MATH. ...Told you I was doing something stupid...
  12. Found it. Shifting the palette by -4 fixes these images. WHY.... why why why why.... I'm going back to the BASIC code to see if there's a palette shift there...
  13. Well this is interesting. None of the 32 x 32 sprites show any palette shift; ALL of the 64 x 64 sprites show it... in C, but not in BASIC.
  14. It gets even funner. I just did a fresh copy of all these images back into the /basic folder, and re-ran the BASIC program... just to confirm it's loading the same files... and the mountain is CORRECT there. Hilarious. So now I look at what BASIC is doing, versus what C is doing. BASIC is loading those images into RAM banks, and then the data in those banks is being copied into VRAM. There's a VLOAD command in BASIC, isn't there? Can I vload straight to VERA $4000 in BASIC? ==> YES, yes I can, and it works great (when loading from the host file system).
  15. LOL. Here's the correct image, from the BASIC program, next to the image loaded from the C code: Obviously a palette shift of some kind. The transparency layer looks like it's dark blue. The "grass" is cyan-ish. The mountain shadow is a darker cyan-like thing. The mountain proper is brown, with a lot of chaos where there are shades of white-gray in the correct image.
  16. Plainly I'm doing something wrong with my 64 x 64 sprites -- which are 8BPP after all. So I'm going to approach this the same way I approached the 32 x 32 sprites: slow and steady. #define TO_RAM 0 #define TO_VERA 2 #define SPRITE_REGISTERS(spritenum) ((spritenum << 3) + 0xfc00) // sprite blocks are in 32 byte chunks. #define SPRITE_BLOCK(addr) (addr >> 5) #define SPRITE_MODE_8BPP 128 #define SPRITE_32_BY_32 (128 + 32) #define SPRITE_64_BY_64 (196 + 48) #define SPRITE_LAYER_BACKGROUND (1 << 2) #define SPRITE_LAYER_0 (2 << 2) #define SPRITE_LAYER_1 (3 << 2) int block = SPRITE_BLOCK(0x4000); int mode = SPRITE_MODE_8BPP; int x = 100; int y = 100; int z = SPRITE_LAYER_1; int dimensions = SPRITE_64_BY_64; int palette_offset = 0; // //. load the sprite into VRAM // cbm_k_setnam("terrain/island-mountain-x.bin"); // cbm_k_setlfs(0,8,0); // cbm_k_load(TO_VERA, 0x4000); // this all works // // set port 0 address and increment // VERA.control = 0; // port 0 VERA.address = SPRITE_REGISTERS(1); // sprite 1 VERA.address_hi = VERA_INC_1 + 1; // the "+1" is the VRAM high address bit. vera_sprites_enable(1); // in cx16.h VERA.data0 = block & 0xff; // lower VRAM address bits VERA.data0 = mode + ((block >> 8 ) & 0x1f); VERA.data0 = x & 0xff; VERA.data0 = x >> 8; VERA.data0 = y & 0xff; VERA.data0 = y >> 8; VERA.data0 = z; // leave collision mask and flips alone for now. VERA.data0 = dimensions + palette_offset;
  17. That's absolutely correct. I think he decided when he laid out his original plans. The design only changed when it gets blocked. In other words, he's not dithering.
  18. Understood. I'm currently using the native file system, so I'm ok. I'll probably get bit if I try to move to an SD card before migrating to R39 tho.
  19. Yeah, I'm using 38, but I always specify the address so the contents of those two bytes don't matter to me. I always write two zero bytes when I create these images.
  20. Hmmmm how about this: BASIC's "LOAD" command works differently than cbm_k_load()? I wonder... load "island-mountain-x.bin", 8, 9,$b000 :rem 9b The above fragment loads a file into one of the RAM banks, which I later transfer into VERA. This method requires those initial two null bytes in the file. Meanwhile, my C code uses this: void loadVera(char *fname, unsigned int address) { cbm_k_setnam(fname); cbm_k_setlfs(0,8,0); cbm_k_load(TO_VERA, address); <--- THIS } Now, does THIS method throw out the first two bytes of a file? I assume it does. But if it doesn't... "This function LOADs data bytes from any input device directly into the memory."
  21. Well anyway. I don't know why I was thinking of a strange X8 ad hoc connection, except for a niche of games. Those racing games always work better when each person has his own monitor. And things akin to FPS. I'm sure an Ultima-style game COULD have multiple players on multiple consoles -- remember Diablo II? The limitations of the hardware is a GOOD thing, but I like to test those limits.
  22. Ha! Hey I like your impudent waste of resources for the sake of a retro look! But yeah, low-res mode is a good solution here. Thank you.
  23. I'm sure universal can mean lots of things, but for us users living in the 1990s, USB was a breath of fresh air. Previously, we had a different connector for every peripheral. Its serial nature was similarly a relief. 25-pin printer connectors were ridiculous, and shrinking computer sizes aligned with USB's rise more or less together. The ability to daisy-chain made me think that the industry finally caught up with Commodore.
×
×
  • Create New...

Important Information

Please review our Terms of Use