Jump to content

rje

Members
  • Posts

    1028
  • Joined

  • Last visited

  • Days Won

    31

Everything posted by rje

  1. Does that USB connection mean multiple X8s can be connected together in a strange informal kind of network? imagine writing a multi-unit game...
  2. Feeping Creaturitis is nothing new, eh?
  3. There are a few spare bits in VERA’s sprite registers. VERA itself might be “full”; however, I was thinking about the C64 and its chunky sprites, and its double-size mode. You know, it could be twice high, or twice wide. Those extra large sprites were 80’s jaggy, remember? Ok so maybe VERA is not designed to be so retro. It’s about clean graphics. I get that. But a chunky mode would work for games that aren’t as picky about graphics, but do want to use all available space. It would for example allow the programmer to design 32 x 32 sprites but display them as 64 x 64. You get the wall of graphics at a quarter the memory cost. Obviously it's not important, or else VERA would have this mode. And of course I can just switch to 40 column mode, so perhaps I am barking up the wrong tree. * * * Those 3 unused bits do call to me, though. I wonder why.
  4. 8BG’s videos get me thinking about Commodore hardware specifically and 6502 hardware generally. I think the form factor of the PET is one of the most visually appealing of the single-piece computers (along with the TRS-80 model 3). There’s something about them that screams “I must be taken seriously!”, whereas my Commodore 64 — which I loved — put on no airs, saying simply “I’m a superior game computer!” So yesterday I one again read Steve Gray’s webpage on the Colour PET — a PET which repurposed its second set of video RAM as color RAM. As a refresher: the PET had space for a parallel 1K bank of video RAM. When enabled, the PET was in 80-column mode. ( In my mind, this was a landmark separating business machines from home computers. ) A little effort by Steve lets it serve color when in 40 col mode. *Now*, however, I think the PET looks timeless, and so I “want” it to be *more* capable than it was. I’m an 80 column “snob”. And I’m also a color snob, although the basic Color RAM seems enough for me. And... I’m also a hardware sprite snob, because the C64 showed me how fun they are. It’s taking time to warm up to VERA’s more complex sprites, but I now see exactly why multicolor mode is so nice. And so I am thinking that VERA could turn any PET into a Color PET. If so, then I think VERA is a very good thing.
  5. Wow, ok. While I’m here asking questions, what else isn’t in the debugger’s current documentation, so I can update the README and do a pull request? * PR created with Vera, bank notation added.
  6. 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.
  7. 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.
  8. 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.
  9. 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.
  10. 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.
  11. 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); }
  12. 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?
  13. Welcome to yet another Scott! My mom was from Chandler, off the ol' Turner turnpike.
  14. 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?
  15. Thanks Ed. You helped me out, and I think it's starting to work. My Xebec sailing ship is now visible!
  16. 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;
  17. 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
  18. 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.
  19. 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.
  20. Here's from the video... I see the Lattice FPGA, and the nine-pin connector, plus headers for 1x8 and 1x14 connectors.
  21. An interesting question, followed up by many more interesting questions. Let's see what we can find out.
  22. (OK so here we go again) Let Peddle develop the CBM line in the manner of his Victor-9000. Thus they have inroads to education and a solid 16 bit business line as the VIC-20 softens and C64 saturates the home and lower-end market. Commodore then creates a sound and graphics card for the PET/CBM line. Then the 128D with a sixteen bit CPU becomes a natural evolution of that high-end line. * * * So that time machine has to send a cadre of us back to 1980 regardless.
  23. Well I can have a 1K orchestration program in main RAM that knows how to toggle between banked routines, when it comes to that. The tokenizer is 5.5 k. Plenty of room. Tokens are 5 byte structures: typedef struct { uint8_t type; uint8_t length; char *start_position; uint8_t line; } Token; Scripts are limited to 256 lines. The parsed source is diced up into strings and used in situ. 8-Shell, my current 25K attempt at the tokenizer + compiler + interpreter, is a mess, but the intro screen is pretty: and it can evaluate SOME expressions: and the logout screen reads a random entry from a FORTUNE file (8K, stored in yet another bank):
  24. rje

    My X16 Case

    Does it? Well you may be right. Oh yes, you're right. 1U is 1.75"? Yeah, you're right. Shows you how much I know.
  25. rje

    My X16 Case

    Here it is: I searched online and it's a lot like similar boxes for 386SX machines... this one for instance:
×
×
  • Create New...

Important Information

Please review our Terms of Use