Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


rje last won the day on September 4

rje had the most liked content!

Community Reputation

369 Excellent

Recent Profile Visitors

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

  1. OK, so I have the debugger up. I can see memory locations by using the m xxxx command -- for example, to see RAM bank 4 I can do this: b ram 4 m a000 (actually, this command appears to ignore the bank set and always displays bank 0) Now VERA's memory is.... in VERA. What's the debugger convention for displaying VERA? The docs don't say (https://github.com/commanderx16/x16-emulator), and trying something like "m 14000" defaults to 0x4000.
  2. What a great idea. You know, I've never actually done that before, and I think that is an excellent idea. Thank you. @Ed - yes, as far as I can tell, it's the default palette.
  3. OK. Yes, these are 4BPP sprites -- they're based on a 2K PNG file instead of the 4K version. And they're 64 x 64.
  4. Aha! I found SOMETHING. I just don't know what it is, yet. I translated the load addresses for the land down to $4000 thru $9000. And I can see land, although its color scheme is messed up. So one or more loads are messing up VRAM somehow. But, there's no data at $8000 and $9000, even though I attempt to load to VRAM at those addresses. The palette is really screwy. I wonder what I'm missing. The palelette offset is 0. Maybe these land sprites are 4 BPP. AH! I think they are! That would explain a lot.
  5. Thank you -- I'll check again, it's likely that that's done wrong. Those files ARE 4K in size, so yeah, 16 pages are needed. Even so, though, SOMETHING should be stored at those addresses. But yeah, I'm overlooking something in the sprite definition or the data load. My BASIC code loads them two at a time from banked RAM like so: rem --------------------------------------- rem rem load ocean and land into VERA at $8000 rem rem --------------------------------------- vpoke %10000,$8000,0 :rem reset autoincrement for bb=7 to 9 :rem banks 7 to 9 poke $9f61,bb :rem point to the right bank for i=$a000 to $bfff poke $9f23,peek(i) next next So that's attempting to load VRAM at $8000, $9000, $a000, $b000, $c000, and $d000. And it looks like it's still 8 BPP. Actually I know it is.... huh do I though? Yeah, yeah I do: VPOKE $F, S0+0, %00000000+ls :REM LSB VPOKE $F, S0+1, %10000000+bk :REM R...BBBB VPOKE $F, S0+2, X AND 255 :REM X VPOKE $F, S0+3, X / 256 :REM X MSB VPOKE $F, S0+4, Y AND 255 :REM Y VPOKE $F, S0+5, Y / 256 :REM Y MSB VPOKE $F, S0+6, %00000000+Z+FL :REM coll,ZZ,FLIP VPOKE $F, S0+7, %11110000+PO :REM HHWW..PO The above code is in a land load loop. S0 is the sprite register in question, so S0+1 includes the color depth, which is hard-coded to 8 BPP (%10000000). I know for sure that land sprites are 64 x 64 because the last line has the height and width in the first nybble (%11110000). So I'm missing something in the C code.
  6. Now I'm doing something wrong. I've loaded 64 x 64 sprite data into VERA at $8000 and up, like this // terrain at 0x8000 loadVera("terrain/ocean.bin", 0x8000); loadVera("terrain/island-desert-x.bin", 0x8800); loadVera("terrain/island-grass-x.bin", 0x9000); loadVera("terrain/island-savannah-x.bin", 0x9800); loadVera("terrain/island-forest-x.bin", 0xa000); loadVera("terrain/island-hills-x.bin", 0xa800); loadVera("terrain/island-mountain-x.bin", 0xb000); But when I define a 64 x 64 sprite and point it at 0x8000, it displays as noise. A 64 x 64 bit sprite of noise. When I move its block pointer down into the 32 x 32 sprite data, it shows the presence of that data -- it ain't pretty, but it proves that I know how to point sprites to their data. It's like the load failed. Why did the load fail, when the other 32 x 32 sprites loaded fine into $4000 through $7000? They're all 8 BPP mode, so I can rule that out. void initLand() { sprdef.mode = SPRITE_MODE_8BPP; sprdef.block = 0x8800; sprdef.layer = SPRITE_LAYER_1; sprdef.dimensions = SPRITE_64_BY_64; sprdef.x = 4000; // this is ok; it's high on purpose. sprdef.y = 4000; landpos.x = sprdef.x; landpos.y = sprdef.y; sprite_define(2, &sprdef); }
  7. Okay, you've ignited my interest in doing hi-res graphics plotting. Can you point me to a dumb guy's intro, while I scratch my head over the extremely dense information content in the VERA user's guide?
  8. Welcome to yet another Scott! My mom was from Chandler, off the ol' Turner turnpike.
  9. A ridiculous brainstorm: lead your videos with the headlines / bottom lines. The 15 minute "here's what happens". Then the 60 minute deep dive. One video, formatted for two levels of interest?
  10. Thanks Ed. You helped me out, and I think it's starting to work. My Xebec sailing ship is now visible!
  11. I'm trying to define and show a sprite, in C, using CC65. It's a mess and I'm not sure what I'm doing wrong, so I'm going to write it afresh here and see if anyone can see what I'm doing wrong. I am thinking that the following code should be sufficient to define and display a sprite, assuming of course that VRAM has been initialized with the sprite data at location $4000. First, I have to set the port address in VERA. I'll use port 0. (Version 2) #define SPRITE_REGISTERS(spritenum) ((spritenum << 3) + 0xfc00) // // set port 0 address and increment // VERA.control = 0; // port 0 VERA.address = SPRITE_REGISTERS(1); VERA.address_hi = VERA_INC_1 + 1; // the "+1" is the VRAM high address bit. // So $1FC08 begins the registers for sprite 1. Right? Now I should be able to define sprites. // 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_DISABLED 0 #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_32_BY_32; int palette_offset = 0; vera_sprites_enable(1); // 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;
  12. If I understand the VERA documentation correctly, I could write to VERA two bytes at a time, if I am careful. Here's how I think I can do it. But egads, it's so much work, it ain't worth it, is it? // // set the initial address for port 0, and set its auto increment to 2. // VERA.control = 0; // select port 0 VERA.address = my_even_vram_address; VERA.address_hi = 33; // incr = 2 and address = 1. I think. // // set the initial address for port 1, and set its auto increment to 2. // VERA.control = 1; // now select port 1 VERA.address = my_odd_vram_address; VERA.address_hi = 33; // i.e. same as before, I think. // // now I can set data, two bytes at a time. // #define VERA_BY_2 (*(uint16_t*)0x9f23) VERA_BY_2 = *((uint16_t*) myTwoByteStruct); VERA_BY_2 = *((uint16_t*) myNextTwoByteStruct); VERA_BY_2 = *((uint16_t*) myThirdTwoByteStruct); // and so on
  13. I think that, specifically, tokenizing from an editor, line by line, is plenty fast on the X16. Tokenizing an entire file all at once would probably be a bit laggy. The Python model. But, it might be OK? You'd have to try it and see. Banks ... just spitballing here ... banks could serially hold tokenized programs. The "heap" would (probably?) have to be in main RAM, i.e. common to all the banks. But the banks are a serial run of "memory hunks", so when you hit a bank boundary, you just skip lightly into the next bank and keep going. That seems OK to me. * * And for BASIC it's probably OK... although... I suspect programs need more data space than program space (I mean, a 40K BASIC program is a monster. I've been there.). So banks really are ideal for data. Now if that data just happens to be program fragments, that's okay too. But ... banks are best for data. Not that you can't make it work -- and it might work really well -- but I'm just thinking this.
  14. Re X8, X16, and VERA. The X8 is more like Commodore's memory-mapped I/O. Because college was soooo long ago, I had forgotten about using ports. But because I first learned programming on Commodore machines, I thought memory mapped I/O was not only natural, but just right. The X16's interface to VERA is a pair of ports, isn't it? I can handle it, but I prefer memory mapped.
  15. Here's from the video... I see the Lattice FPGA, and the nine-pin connector, plus headers for 1x8 and 1x14 connectors.
  • Create New...

Important Information

Please review our Terms of Use