Jump to content

rje

Members
  • Content Count

    471
  • Joined

  • Last visited

  • Days Won

    12

Everything posted by rje

  1. I would not buy it at that price. I had to really work myself up to get it at its base price, which I am still too timid to type onto the screen. It's a very nice keyboard, but... really. And the base keyboard which will ship with the X16 is looking ... not bad. Good enough, even. Maybe you have creative options now when it comes to keyboards. Can you buy something nice and get custom PETSCII keycaps (at an affordable price)? How about something nice now, and custom PETSCII keycaps later, thereby splitting the cost in two installments? Sounds like a good way to go.
  2. OK, so you're using an assembly program to build out a BASIC program. No transpiler, this is all on-board. Looks like you're (correctly) using the ? token for PRINT. Otherwise I think it would be appx half as many lines. Interesting, amusing, and interesting.
  3. This. QFT. But I'll think about it if I ever get back to my 8SH code... a history function. I'd probably use one RAM buffer for it... that's EIGHT THOUSAND BYTES of history!! WOW!
  4. I've tried this with Dusan's PET uppercase font, and it's an improvement. I might port in the lowercase letters as well...
  5. rje

    Lemonade Stand

    Version 1.0.0

    19 downloads

    I played this game with my friends in grade school on the PET. Though unable to find the original, I found a stripped-down VIC-20 version -- which showed me the program's essential structure -- and the later 1986 version by Commodore, mainly designed for the Commodore 64. I used both to create this version, which retains the original algorithms, and tries to emulate the older PET version. It uses very little X16-specific code -- exactly, SCREEN and COLOR. It relies on the 40 x 25 screen, and it uses just about all 25 of those rows. The rest is all PETSCII and BASIC 2.
  6. Lemonade Stand View File I played this game with my friends in grade school on the PET. Though unable to find the original, I found a stripped-down VIC-20 version -- which showed me the program's essential structure -- and the later 1986 version by Commodore, mainly designed for the Commodore 64. I used both to create this version, which retains the original algorithms, and tries to emulate the older PET version. It uses very little X16-specific code -- exactly, SCREEN and COLOR. It relies on the 40 x 25 screen, and it uses just about all 25 of those rows. The rest is all PETSCII and BASIC 2. Submitter rje Submitted 02/23/21 Category Games  
  7. I (accidentally) blew up an LED and a 2N2222 last week, during the arctic whoosh in Texas when we lost power. It was refreshing (the blowing up of electronics bits, not the arctic front).
  8. From the Facebook chat, @TomXP411 was (idly?) thinking: He gave it a tentative name of "CX", that is, something C-like for the X16. His subsequent thought would be to alter Prog8, mainly to use PETSCII and get away from { } \. Péteri András then suggested TRSE, which is a Pascal environment for small machines. TRSE uses BEGIN and END to define its blocks, which are statements in their own right. So, for example, the IF THEN ELSE takes statements which are either single-line expressions or blocks. I glanced at the source on github, and it looks like a large language... but the original intended target is the Commodore 64, so. *** I note that languages like TRSE, COMAL, and S-BASIC all tend to resemble each other in capability, varying typically in syntactic sugar. That's probably because of the reality of programming on the Commodore: compact architecture, light memory footprint, and PETSCII dominance.
  9. Updated with settlements... sort of. Buggy settlements. I'm still working out how I want to do the sprite offsets there. I figure if I can do half-height offsets, I can get twice the number of unique settlements.
  10. Traveller UWP generator View File A quick UWP generator. Submitter rje Submitted 02/17/21 Category Demos  
  11. Version 1.0.0

    2 downloads

    A quick UWP generator.
  12. Off by one I suspect. Thanks for finding it! Ah, that's a "bug" with my map, not the code. The first two bytes used to store the map dimensions, causing your error. I'll upload a new map.
  13. The map drawing routine is my target. If I put it in assembly then ... well it'll be superfast. rem dx,dy is the top left corner of the map view bb=0 :rem this prevents us from POKEing the bank every loop for r = 0 to \rows-1 y = dy + r y3 = int(y/32) :rem each RAM bank has 32 rows ba = 10 + y3 :rem there's our bank number if bb <> ba then bb=ba :poke $9f61,ba yy = 32 * (y/32-y3) :rem y mod 32 for c = 0 to \cols-1 x = dx + c la = peek($a000+yy*256+x) :rem tile value bk=l1(la) :rem MSB for sprite block ls=l2(la) :rem LSB for sprite block s0=s0(r,c) :rem cached sprite address offset vpoke $f, s0+0, %00000000 + ls vpoke $f, s0+1, %10000000 + bk next c next r return First, the code is a mess. It's very busy, and seems to be inefficient for simply updating a map. The data required to update any one tile is: 1. The correct bank and offset of the data. 2. The MSB value to poke. 3. The LSB value to poke. 4. The sprite's register offset.
  14. Pirate Kingdoms View File A demonstration of the use of BASIC, sprites, and banks to create a tiled map. Everything is quite primitive right now. The response time is slow. The map is 256 x 256 and stored in banks 10-17 (it's 64k). My plan is of course to make it larger. Use the cursor keys to move about the map. Submitter rje Submitted 02/16/21 Category Demos  
  15. rje

    Pirate Kingdoms

    Version 1.0.0

    44 downloads

    A demonstration of the use of BASIC, sprites, and banks to create a tiled map. Everything is quite primitive right now. The response time is slow. The map is 256 x 256 and stored in banks 10-17 (it's 64k). My plan is of course to make it larger. Use the cursor keys to move about the map.
  16. Yes, I figured I can't just connect these two critters pin-to-pin. Even on the Pi it's not recommended (read: dangerous). Thanks for the level shifter link, Tom!
  17. I think as long as I/O isn't too difficult to figure out then I can write my own transfer programs. For me, the tricky part is with the electronics. I would need to connect GPIO pins on the X16 to the GPIO pins on a Raspberry Pi Zero. Assuming I didn't fry either board in doing that, then I think I'd be ok. Maybe.
  18. It is a massive improvement in self-documenting code. When I see gosub {:display.update} I know that not only is the display going to update, but that the subroutine can be found in the file module-display.list.
  19. I confess a bias for C-like things.
  20. It's nice -- (16 x 16) pixel tiles, in a (256 x 256) matrix, is pretty good, and nice that it's handled in hardware.
  21. Ah, ok, tiles, got it. I understand. Thank you. And, I think that's how my Rogue Forest game works -- one layer holds the characters of the map (I guess those are tiles), and the other is the "fog of war". Are tiles 8x8 pixels then? Sounds like I'd want to create a custom character set. I'm not creating a repeating background: it's a viewport (call it 40 characters by 40 characters or so, in the center of the screen) into a gigantic map. It sounds like *changing* the tiles requires 1,000 VPOKES... suppose your ship "moves" 320 pixels to the West; that's a whole new map, different from moving 320 pixels North.
  22. In BASIC, $80-$FF are tokens. And below that, they are themselves. Including the graphics characters. Right? Can we make these lower printables DO things? Type a batch of them on the command line and press <return>. The interpreter gamely returns "READY." No syntax error, because they simply exist. They don't DO anything. PI, on the other hand, represents something, so it will error out. As will letters. Sounds like something useful looking for a purpose. LIKE WHAT? Well how about variable characters? What if you could use the heart character as a VARIABLE? What if your valid variable set were larger than A-Z0-9? "Who needs 16,000 two-letter variables?" you say. "They collide with the way shortcut BASIC commands work." Fine. But these critters seem to me to be available for functionality of some kind.
  23. Let me use a REAL routine I'd like to make a subroutine. Here's (essentially) the BASIC 2 version, sans line numbers: REM REM distance(C1,R1,C2,R2) -> D% REM A1 = R1 + INT(C1/2) A2 = R2 + INT(C2/2) D1% = ABS(A1-A2) D2% = ABS(C1-C2) D% = ABS( A1 - A2 - C1 + C2 ) IF (D1% >= D2%) AND (D1% >= D%) THEN D% = D1% IF (D2% >= D1%) AND (D2% >= D%) THEN D% = D2% RETURN Converting to a structured, PROC format: SUB DISTANCE( \COL1, \ROW1, \COL2, \ROW2, \*DISTANCE ) LOCAL \A1 LOCAL \A2 LOCAL \D1 LOCAL \D2 \A1 = \ROW1 + INT(\COL1/2) \A2 = \ROW2 + INT(\COL2/2) \D1% = ABS(\A1-\A2) \D2% = ABS(\COL1-\COL2) \DISTANCE = ABS(\A1-\A2-\COL1+\COL2) IF (\D1% >= \D2%) AND (\D1% >= \DISTANCE) THEN \DISTANCE = \D1% IF (\D2% >= \D1%) AND (\D2% >= \DISTANCE) THEN \DISTANCE = \D2% RETURN The asterisk in \*DISTANCE means not to create a temporary variable, but to use the actual one named here. Hmmm, have to think about that. That would transpile to: REM SUB DISTANCE(ZA,ZB,ZC,ZD,Distance) REM LOCAL ZE,ZF,ZG,ZH ZE=ZB+INT(ZA/2) ZF=ZD+INT(ZC/2) ZG%=ABS(ZE-ZF) ZH%=ABS(ZA-ZC) Distance=ABS(ZE-ZF-ZA+ZC) IF (ZG% >= ZH%) AND (ZG% >= Distance) THEN Distance = ZG% IF (ZH% >= ZG%) AND (ZH% >= Distance) THEN Distance = ZH% RETURN Where "Distance" is whatever variable I'm using to store distance globally... Why is this good? This is good because it establishes a set of temporary variables that I can re-use in a way that's readable in the source.
  24. So say a procedure looks something like this: SUB PROCEDURE_NAME( \ARG1, \ARG2$, \ARG3% ) LOCAL \MYVAR$ ; A LOCAL IS A TEMPORARY VAR. ; IT WOULD NOT BLOW AWAY AN EXISTING VAR. ; DO STUFF WITH ARGS ; YOU CAN ALSO WORK WITH OTHER GLOBAL VARS \MYVAR$ = ARG2$ + " OUCH!" \ARG1=\ARG1+1 CALL ANOTHER_PROCEDURE( \ARG2$, \MYVAR$ ) RETURN The REAL challenge here is handling variables. So here's my house rules: You may use CALL inside of a PROC, but it will trample your parameters and local vars. Therefore, the only safe place to call another proc is at the end (tail call). I designate some number of variables for locals and parametrics. Say, 36. Go over that and the transpiler dies in agony. So the above code transpiles down to REM SUB PROCEDURE_NAME(ZA, ZB$, ZC%) REM LOCAL ZD$ ZD$=ZB$+" OUCH!" ZA=ZA+1 REM CALL ANOTHER_PROCEDURE(ZA$,ZB$) ZA$=ZB$ :ZB$=ZD$ :GOSUB 9000 RETURN Okay, that might work. The problem NOW is how to modify global variables. I think the best way is to add a notation that says "This is the ACTUAL variable name. Don't use a temporary name!" Like a splat (*).
  25. It's because I don't know what "tiles" are. ?
×
×
  • Create New...

Important Information

Please review our Terms of Use