Jump to content

rje

Members
  • Posts

    1028
  • Joined

  • Last visited

  • Days Won

    31

Everything posted by rje

  1. That speeds things up quite a bit. Thanks!
  2. Whoa! That's something I never knew about sprites! You learn something new every day...!
  3. So I started to make my Scary Forest program more Roguelike... and the first thing I did was implement a "fog of war" on the map. It's a great idea: don't draw the map! Saves time! Only draw new bits when you get within, say, 4 moves. And then you can "see" monsters... and they can see you... and start lumbering towards you. I mean this is a win-win, right? So I'll tell you: it DOES improve the feel of the game... a LOT. It adds some suspense. It adds an exploration element to the game. So there's emergent gameplay that I didn't realize was there. Once I add treasure, it'll be a whole new ball game. ...BUT... ...What I've found is that even drawing a 9 x 9 map from a 2D array, then handling player and monster movement, is too slow. Yeah, even with the Commander X16, it's too slow. I optimized. I went memory-lazy and use an array of floats instead of ints. I got rid of newline printing and went all cursor controls. Up, down, left, right. It helps. But... it's still slow. It turns out that adding a line of logic here and there really add up fast... and this is just PETSCII! So I'm fishing for suggestions. I've started asking myself what assembly language I can write to get the most speedup for the least amount of pain. Maybe the map drawing routine: fairly straightforward, no funny checking of data and switching around, so not a big chunk of code. I guess I'd POKE the map into a bank, and the ML would use ZP indirect indexing to find the right data, do a PLOT, and render the PETSCII. Next square. Do it from x-4 to x+4, y-4 to y+4. Maybe? Or maybe I should use sprites for the player and monsters? They would sit "on top" of the map, so I wouldn't be drawing over it; surely that might help? Anyone got better ideas?
  4. Yes, I've gotten highly geeky over storage. I settled on the "subsector", which is a fundamental unit of Traveller interstellar space. It's basically a game map of 8x10 parsec-sized hexes, each of which could hold a star system. It's enough room to support interstellar travel plus local fun. The star system itself is encoded in about 48 bytes -- enough space for useful information for travel, trade, exploration, combat. Thus, a subsector is 3840 bytes of star system data, plus a 256 byte header for metadata. 4K exactly. There are 2,000 mapped subsectors in the default supported timeline for "Charted Space". You can view them here: http://travellermap.com So that's 8 megabytes. But you're right -- I *could* group data in sectors, which is a 4x4 matrix of subsectors. I reckon that would take up 64K, not 128K, but same difference, and would (as you note) reduce the file count drastically, to a manageable 125. I note that loading files into the X16 is quite fast. Maybe loading a sector at a time isn't so bad. There's also a procedural process for generating system data, so that's an easier way to plug in data. But OF COURSE I want to do things properly and support existing data... and y'know, there's multiple periods in time, each with different data... etc. It's a fun task.
  5. Ah Forth! So please, can someone explain to me why I have such a resistance to the Forth language? It seems to tick a lot of the boxes for a great 8-bit language.
  6. Because we have MEMTOP and MEMBOT, I can write a little assembly routine that generates a partial memory map "in situ": Since the X16's I/O and bank locations are fixed, I can hard-code those, and query for the current active banks. Ideally, register loads will also get dumped to low RAM, but currently, well... Is there anything else I can do to determine the current memory map of a running X16?
  7. I've started assembly that draws a beveled box in PETSCII on the screen. The user POKEs in left,top,right,bottom, and the code does the work. I just remembered that there are KERNAL routines to position the cursor on the screen. I should use those, shouldn't I? The routine starts by pre-computing the height and width, and then it positions the cursor: Then, it prints the top line: That's what I have so far. Next steps are to print the vertical bars and the bottom of the panel frame. Now for the print_x_spaces I have: And for the horizontal bar, I have: I guess I want to verify I'm doing things correctly, if there's a better way, and perhaps if this has already been done.
  8. Totally. I hope you find this new exploration enjoyable!
  9. It's currently a very boring game, so I will add some elements to bring in some meaningful player choices. Also, some bits of the "user interface" need tweaking. And I will remove the dependency on my banner code, so it can be launched "run it now"-style in the browser.
  10. Scary Forest View File You are lost in the Scary Forest. Work your way to the edge to escape, and defeat monsters to gain points. You can defeat them by your sword, your wits, or your feet (by running). But beware... some monsters are smart, some are strong, and some are fast. Good luck! Submitter rje Submitted 08/12/20 Category Games  
  11. This is the contrapositive version of the "Big" data file question. One of the BASIC programs I submitted to x16-demo is a Traveller game, where the player jumps around a subsector of space, trading goods. Because I stored all data in DATA statements, the program reached about 38k in size -- a major accomplishment if I do say so! But that's okay, it was a proof of concept. Next step is to put data into a binary format that I could load into banked RAM. Now, I'm thinking that I can dynamically load data as I need it from a set of files on SD. For example, say I have 2,000 star charts, and each is 8K in size. I don't need to shove them all into RAM; I only need the "current" chart, and perhaps its neighbors. Does that sound reasonable to everyone?
  12. You're right - I wasn't thinking enough about the situation. LDA <label> is an absolute address, for example. OK.
  13. Banner View File An assembly language routine which prints "banner" text using PETSCII. # How to Use This code is currently compiled to banked RAM at address $A000. Load the PRG file into memory at $A000. Poke the desired PETSCII character code into $A000. Call the routine at $A001. e.g. ``` LOAD"BANNER-FONT.PRG",8,1,$A000 POKE $A000, 65 :REM "A" SYS $A001 ``` # Supported Characters Version 1 only supports A-Z and space. The characters are 3 x 3 characters in size, with a special "space" character that is 2 characters wide. # How to Compile This is the command I use to compile the source: ```cl65 -o BANNER-FONT.PRG -t cx16 -C cx16-asm.cfg banner.s``` Submitter rje Submitted 08/07/20 Category Graphics Apps  
  14. rje

    Banner

    Version 1.0.0

    78 downloads

    An assembly language routine which prints "banner" text using PETSCII. # How to Use This code is currently compiled to banked RAM at address $A000. Load the PRG file into memory at $A000. Poke the desired PETSCII character code into $A000. Call the routine at $A001. e.g. ``` LOAD"BANNER-FONT.PRG",8,1,$A000 POKE $A000, 65 :REM "A" SYS $A001 ``` # Supported Characters Version 1 only supports A-Z and space. The characters are 3 x 3 characters in size, with a special "space" character that is 2 characters wide. # How to Compile This is the command I use to compile the source: ```cl65 -o BANNER-FONT.PRG -t cx16 -C cx16-asm.cfg banner.s```
  15. Nope, that's not it at all. I guess the linker forces the code to an address. Hmmmm. Well changing those two JMPs to BVCs reduced my code size by two bytes. Consolation prize.
  16. EXAMPLE: In my assembly, I have So I think this forces me to do this in BASIC: Because when I try this: It doesn't work. This seems to mean that the linker is linking to absolute addresses, even though I try to load it to a different address. So. How do I write my code so that it's all relative addresses? Ah, is it because I have a JMP in my code, and JMPs are **ABSOLUTE** so the linker **HAS** to assign an address..... hah that's probably it. So since I'm not doing any math, I can try to replace that with a BVC or something. But, is there something else I don't know? Thanks all.
  17. That sounds kind of fun. I suppose a driver program would need (1) A buffer to store the name of the T64 file it's accessing from the SD. (2) A destination pointer. (3) An EOF flag. (4) A block-offset into said T64 file. If that's an unsigned int, then you could access up to 4mb. (5) Routines to "mount and open" the volume (maybe), scan the next filename, read a block into the destination address, skip the file. (6) Similarly, write operations. (7) An "Experience API" that prints the tape "directory" to the screen. Actually that would also be nice for debugging and development... #4 and #5 could be gathered into a nice little jump table as well.
  18. Ed Minchau apparently is working on a set of 16 bit "kernal" ops... I directed him to you on the Facebook page.
  19. Sweeeeeet. This is just awesome. I've put sequential files on hold until OPEN was supported. Of course, now I'm just enjoying loading binary data straight into RAM banks! But being able to save small pieces of data will certainly be welcome! Thank you!
  20. When I first read that the X16 will have 512K installed, and be expandable up to 2MB, I thought of the law of the curse of expansion, which says that programmers will develop to the minimum requirements in order to reach the largest audience. But then I went online and saw that 512K SRAM chips are selling for appx $5 each. OK.
  21. It's not the color that gets me. It's not the features like the expansion slots, VGA out, IEC interface, or the SNES adapters. Apologies to Frank, but it's not VERA either (although it is supercool). It's not even the sockets. It's that there's a 65C02 there, and a straightforward but clever banked memory map, on no-fuss static RAM, and it's going to run an ancient (albeit upgraded) Commodore KERNAL. That's what gets me. That, and maybe the SD slot. But I like all the other stuff too of course.
  22. Thank you for your effort! I'm thrilled to see all of your KERNAL extensions, and looking forward to using them.
  23. I've started (and stopped) writing a bytecode-interpreted small language for a few years now. I call the language "Cargo Cult" mainly because it's a cool-sounding name. But... its specs are kind of hazy. The bytecode interpreter is bog-standard, but the language it compiles to is fluid: it changes based largely on my whims. So, what better way to start again than to target an 8 bit architecture, says I. Forces me into constraints. Here's kind of what I'm aiming for in CargoCult 1.0. I *think* the key difference between it and a structured BASIC is the array notation and use, which is more or less borrowed from Perl. That, and the importance of the newline character in block declarations and endings. fn int buildZones totalSectors, startTrack, @zones for |index| 0..@zones.length my track = 1 + GLOBAL.totalTracks + startTrack; my sectorCount = @zones[index][1]; my endTrack = 1 + GLOBAL.totalTracks + @zones[index][0]; GLOBAL.totalTracks += @zones[index][0]; for |jdex| track..endTrack GLOBAL.@trackOffset[ jdex ] = totalSectors * 0x100; GLOBAL.@sectorOffset[ jdex ] = totalSectors; GLOBAL.@sectorsInTrack[ jdex ] = sectorCount; totalSectors += sectorCount; endfor endfor return totalSectors; endfn
  24. However, I like the idea of loading the asm at $8000... the monitor can introspect those locations, and doesn't know how to deal with the banks.
  25. You're right, and you're right. By the way, that was my problem -- load "blah",8,1,$a200 did the trick. Then I caught my code error (have to inx or else the thing never increments). Duh.
×
×
  • Create New...

Important Information

Please review our Terms of Use