Jump to content

rje

Members
  • Posts

    1281
  • Joined

  • Last visited

  • Days Won

    44

Everything posted by rje

  1. When I try to mock up my Traveller Trader, I get a little bogged with the vast number of choices. Which makes me realize I need to pare it back -- that there's a lot here that's not important. Also, in some cases, I just need to manage the data better.
  2. MacOS. I'm seeing the top pixels cut off a bit in 41_rc3, e.g.
  3. Can I use PLOT to position the cursor and then use a PRINT to print the text at that position? What I'm seeing is that I can set the Row, but the column is reset before I do the PRINT: 10 POKE $30C, 30 :REM ROW = 30 20 POKE $30D, 40 :REM COL = 40 30 POKE $30E, 0 :REM CLEAR FLAGS 40 SYS $FFF0 :REM PLOT 50 PRINT "HELLO THERE" :REM PRINTS AT ROW 30 COL 0
  4. But then, there's also this. I2C $FEC6: i2c_read_byte - read a byte from an I2C device $FEC9: i2c_write_byte - write a byte to an I2C device Function Name: i2c_read_byte Purpose: Read a byte at a given offset from a given I2C device Call address: $FEC6 Communication registers: .A, .X, .Y Preparatory routines: None Error returns: .C = 1 in case of error Stack requirements: [?] Registers affected: .A Description: The routine i2c_read_byte reads a single byte at offset .Y from I2C device .X and returns the result in .A. .C is 0 if the read was successful, and 1 if no such device exists. EXAMPLE: LDX #$6F ; RTC device LDY #$20 ; start of NVRAM inside RTC JSR i2c_read_byte ; read first byte of NVRAM Function Name: i2c_write_byte Purpose: Write a byte at a given offset to a given I2C device Call address: $FEC9 Communication registers: .A, .X, .Y Preparatory routines: None Error returns: .C = 1 in case of error Stack requirements: [?] Registers affected: .A Description: The routine i2c_write_byte writes the byte in .A at offset .Y of I2C device .X. .C is 0 if the write was successful, and 1 if no such device exists. EXAMPLES: LDX #$6F ; RTC device LDY #$20 ; start of NVRAM inside RTC LDA #'X' JSR i2c_write_byte ; write first byte of NVRAM LDX #$42 ; System Management Controller LDY #$01 ; magic location for system poweroff LDA #$00 ; magic value for system poweroff JSR i2c_write_byte ; power off the system
  5. I just read about this X16 KERNAL function, and thought it would be useful for an efficient file transfer mode: Commodore Peripheral Bus The X16 adds one new function for dealing with the Commodore Peripheral Bus ("IEEE"): $FF44: MACPTR - read multiple bytes from peripheral bus Function Name: MACPTR Purpose: Read multiple bytes from the peripheral bus Call address: $FF44 Communication registers: .A, .X, .Y Preparatory routines: FILNAM, FILPAR, OPEN, CHKIN Error returns: None Stack requirements: ... Registers affected: .A, .X, .Y Description: The routine MACPTR is the multi-byte variant of the ACPTR KERNAL routine. Instead of returning a single byte in .A, it can read multiple bytes in one call and write them directly to memory. The number of bytes to be read is passed in the .A register; a value of 0 indicates that it is up to the KERNAL to decide how many bytes to read. A pointer to where the data is supposed to be written is passed in the .X (lo) and .Y (hi) registers. Upon return, a set .C flag indicates that the device does not support MACPTR, and the program needs to read the data byte-by-byte using the ACPTR call instead. If MACPTR is supported, .C is clear and .X (lo) and .Y (hi) contain the number of bytes read. Like with ACPTR, the status of the operation can be retrieved using the READST KERNAL call.
  6. THINGS I DO LIKE Lest you think I hate my work, there's a lot I am proud of. (A) Data management. I have so much binary data stored in RAM banks -- especially the map, and the starship list. Both of those are large: the map is a couple hundred K, and the starship data is squeezed into one 8K bank. The map just won't fit in system RAM. Other banks are used for other "nice to have" things that run from 1K to 8K, and each of which would potentially limit the main program. (B) Navigation. The ability to jump correctly through a hexmap of "space" from system to system is a major accomplishment for me, and I'm very happy with it. A sprite reticle is pretty cool, too, although it might be incongruous to the retro feel. (C) Data representation. Going back to data, it took a long time to figure out what data was important for the game -- I couldn't just store every known piece of data, and I do rely on some bitfields. The result is a satisfactory tradeoff of terseness versus completeness. (D) Ship crew management. The menu may need improvement, but the crew naming, hiring, firing, and "automatic" skill use is good enough. (E) Ship icons. They seem a little incongruous to the retro nature of the game, but having good-looking ship sprites was a big accomplishment for me. (F) The alarm bar. Having an alarm bar carry ship overall status is something I've had since the BASIC version. It's terse and retro and concise and useful... it even lends some drama to the game, especially if you see a lot of critical alarms lighting up your screen.... in theory. Assuming I ever get combat written.
  7. THINGS I DON'T LIKE I let this project rest for a couple months while r39, r40, and r41 came out. I looked at it again, and compared its look-and-feel with two other attempts: (1) Tom's "Space Trader" mockup menus are better. Tom's mockup has a very clean and functional look. Its menu sample is superior to my scrolling-selection menu system, which is slick but less usable. More subtly, my menu code encourages poor design choices, such as longer menus to choose from. I suspect the ideal menu size is 5 to 7 items. If it's got more choices than that, I need to rethink my design at that point. (2) My earlier BASIC version of my trader game looked PETSCII retro nice. My earlier version had clean-but-retro, rounded PETSCII borders. It split the screen into clear zones, and data was compartmentalized and summarized in an engaging way. At least, that's what it seems to me. It still relied on the scrolling-menu theme, which I don't like, but otherwise the overall look was ... well I have to repeat myself and say it looked engaging. (3) The Trade Engine. I am working on a third trade engine. This one follows Traveller's Book 2 to the letter. I don't know if it's going to work out. (4) Combat. I am not sure how to do text combat well. What I *DO* know is that it can't be long and drawn out, and it must have very limited but important options.
  8. It's all in C, using the cc65 compiler.
  9. So Tom showed us his "wireframe" menu for his Space Trader game. If you didn't see it, it uses the new 80 x 30 display mode reminiscent of the C128 -- and it looks clean and classy. But I wanted to comment on his menu system. If you just look at it, you know exactly how to work it -- it's the classic "one key, one option" thing. Thus every visible menu option is one keystroke away. The color scheme is pleasing as well, but not a show-stopper if you're colorblind. I think that's an optimal, usable way to do menus on the X16. ---- On the other end is my Traveller Trader game. I opted to go with a scrolling-menu system. This means the user has to "cursor" to the desired option. It's not as usable. It's helpful for when there are many options, and I only use one function to render and manage all menus -- that's how I argued the decision to myself. But... there probably ought not be dozens of options in any given menu. And scrolling is not a fantastic experience. So, +1 for the one-key-menu.
  10. I'm running up against main memory limits with my "Traveller Space Trader" program. That's a good thing, because artists must work within constraints. Otherwise I'll never finish. It uses 30K of main RAM, and it's "not done yet"... but for practical purposes it is indeed darn close to "done", whether it's complete or not. But, I shove a lot of constant data into banked RAM, and this lets main RAM focus on game logic. That's a good thing too. So naturally, I was thinking about that neat heap manager of yours, and how it might be useful for storing tokens in a symbol table. For my purposes, a "token" is probably just a string, but it's just a pile of bytes, so a pointer to it could be cast to any struct. The neat part is the symbol table angle -- it's a generic solution that I could use for all sorts of runtime data.
  11. Yep, that did it. Thank you. NOW I have to decide what to CUT from my code. I'm down to 1100 free bytes of main RAM. Currently "externalizing" more constants into a RAM bank, which should get me at least another 1K. But of course I can always simplify my code too.
  12. Three, eh? OK then, sounds reasonable, I'll try that out tonite after work.
  13. Okay, so the PETSCII tiles have moved to $1:F000. I think this means that my code which loads files to banked RAM changes from: to: $F800 to $F000, easy. But I'm wrong.
  14. ^ and I like the look of your Space Trader game.
  15. Problem solved. Now I have to read up on what address to load a font file.
  16. To wit: my brain is wrong. This change was made since my last build of cc65. I just have to update. Duh.
  17. The source for cputc says: https://github.com/cc65/cc65/blob/master/libsrc/cx16/cputc.s That LOOKS right, but clearly something's wrong.
  18. It just seems too useful, and there seems to be room for it. I could use it instead of using my own half-baked routines; it could shrink my codebase, which sometimes is a good thing.
  19. Do you suppose this might be a candidate for one of the spare ROM banks?
  20. A heap manager for banked RAM is nice and helpful if, for example, you want to implement a hashtable using banked RAM. And that's useful if, for example, you're writing a parser/interpreter and need a symbol table. Etc.
  21. rje

    codex

    It's an excellent name for the product, regardless.
  22. I was thinking Khmer, or Baybayin, or Hangul, or Linear A.
  23. Oh, that is nice too. I'm not a fan of QWERTY. Of course I doubt I'll ever use Colemak .
  24. Anglo-Saxon is nice. How about Tengwar
×
×
  • Create New...

Important Information

Please review our Terms of Use