Jump to content

rje

Members
  • Content Count

    43
  • Joined

  • Last visited

  • Days Won

    4

rje last won the day on July 31

rje had the most liked content!

Community Reputation

25 Excellent

Recent Profile Visitors

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

  1. rje

    Scary Forest

    Version 1.0.0

    0 downloads

    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!
  2. 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  
  3. 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?
  4. You're right - I wasn't thinking enough about the situation. LDA <label> is an absolute address, for example. OK.
  5. rje

    Banner

    Version 1.0.0

    7 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```
  6. 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  
  7. 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.
  8. 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.
  9. 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.
  10. Ed Minchau apparently is working on a set of 16 bit "kernal" ops... I directed him to you on the Facebook page.
  11. 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!
  12. 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.
  13. 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.
  14. Thank you for your effort! I'm thrilled to see all of your KERNAL extensions, and looking forward to using them.
  15. 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
×
×
  • Create New...

Important Information

Please review our Terms of Use