Jump to content

SteveB

New Members
  • Content Count

    21
  • Joined

  • Last visited

Community Reputation

44 Excellent

About SteveB

  • Rank
    Space Invader

Profile Information

  • Gender
    Male
  • Location
    Germany

Recent Profile Visitors

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

  1. This sounds great! My upcoming version of TiCodEd will include a check for illegal user SUB routines and issues a warning. You have not updated page 12 in the manual so I assume those changes do not introduce new illegal names? I updated my installation to Isabella7 and everything worked immediately. Now waiting for version 8 ... Steve
  2. I am preparing version 1.1 of TiCodEd based on your input. One new feature will be a "Standard Library" with useful functions (CALL/SUB, not GOSUB). Are there any routines you use in multiple programs which are generic enough to be included in that library? For example, I always prepare the screen and char color, but now with one CALL ScrInit(16,2), which will append SUB ScrInit(fg,bg) CALL SCREEN(bg) CALL DELSPRITE(ALL) CALL CLEAR FOR I=0 to 14 :: CALL COLOR(I,fg,1) :: NEXT I SUBEND to my program if and only if used, and only in the generated output, not cluttering my source. There will also be a User Library for your private code extensions working the same way. Do you have any suggestions or XB code-donations?
  3. I built my own compilable random number generator based on the IEEE article "RANDOM NUMBER GENERATOR FOR 16-BIT MACHINES" by John J. Komo and William J. Reid (1989): // Returns an integer 0 <= RES < UL and advances the seed. Useful when you want a repeatable sequence, but be aware that // neighbor seeds will compute similar results, while the seed is updated with distinct values. SUB RAND(SEED,UL,RES) XDQ=INT(SEED/144) XMQ=SEED-(XDQ*144) SEED2=(227*XMQ)-(61*XDQ) IF SEED2>0 THEN SEED=SEED2 ELSE SEED=SEED2+32749 RES=INT(SEED/(32749/UL)) SUBEND Works well when compiled, but interpreted not as fast as the RXB random numbers. You may start with different seeds to create different, but repeatable Woodlands. This question has been my very first post here on AtariAge... Steve
  4. Hi, after some time of neglect I started my Atari 800 XL again after Christmas. My 1050 drive did not make the familiar sound when turned on. First I thought it was the sensor, but then I found out that the stepper motor driving the head does not move anymore. When trying to turn it nothing happens, it is just stuck. Did anybody recover from this? I see two options. I could try to get some penetrating oil inside of the stepper motor or use some brute force. Or a combination of both. I have plenty of time to wait for the oil to declamp whatever is in there. It can't get more broken. Does anybody know of a replacement motor? I just found a replacement for the main motor on the net so far. Or I could buy a broken 1050 where the mechanics are okay and the electronic died. Any helpful advise would be appreciated as I am a total hardware noob. Thank you Steve
  5. Thank you, I am experienced with ISABELLA, but never cared about the files, was only interested in the resuling -X file. It took me a moment to understand that the -E, -F and -G files are these EA5 files everybody talks about. I converted them to v9t9 with Ti99dir and did what the Module Creater 2.0 page told me to do ... the resulting BIN file loads in Classic99 and plays perfectly. I don't have the hardware here to test with FlashROM99. So in short: Install Module Creator 2.0 as described on @F.G. Kaal site as @arcadeshopper mentioned. Important is to have no blanks in the path. Compile your XB program with ISABELLA. I had the 24k setting active and used Asm994a for fast assembly. Clean XB, 14kB of size. Use Ti99dir to check if the -E, -F and -G files are in or convert them to v9t9 format (select all of them, then Ctrl-F7). I think the "no blanks in path" applies here as well. Start Module Creator, enter Name and Title, select the -E file as Program and press Create Module. If everything works you will find a new subdirectory in Module Creater 2.0 with the module BIN file and some working documents and logs. In Classic99 just open it under Cartridge/User and there you go ... If you didn't know ... now you do! 😎 That should save me from making a video? Thanks everyone! Steve
  6. Hi, there are plenty of compiled programs here available ... but I did not find a beginners tutorial on how to make your own cartridge from your freshly compiled XB program. I found hints on a V7 breakpoint .. but when it came to "Save memory as Program" in Classic99 I do not know what to select. I am not even sure if a breakpoint at "run" in the XB module is the rigtht thing to do or if I need to use the E/A. Please give an old XB programmer some hints. I would love to see my program on FlashROM99 on the real thing. Steve
  7. With your ISABELLA compiler I can avoid any manual memory access. Back in the days I did only have XB and a CS1, never learned the fancy E/A and memory stuff. RLE compressions sounds good, where can I learn which areas to use and how to reserve them? Everybody but me seems to know by now. There are some other areas where I could benefit from an "array of bytes", where I now use strings, complicated and slow to update. Additionally I will try to do a short demo of my interpreter to see where this leads ... how big, how fast (or slow), now that I know there is no common standard yet. My next release of TiCodEd Structured Extended Basic will include XB256 support in the way you can use CALL CWRITE(A$) and it will become CALL LINK("CWRITE",A$) in the generated XB code for all routines. Just a little convinience. I just started testing with XB256 last week and still have shiny eyes when I see what is possible now, even without compiling.
  8. Great! I didn't know this one... I'll check if one of the outputs qualifies to be compressed in the proposed way.
  9. Yes Rich, I see the improvement here. call vchar(5,10,88,3) -> 27 byte 9D[CALL] C8[Unquotedstring] 05 56 43 48 41 52 B7[(] C8[Unquotedstring] 01 35 B3[,] C8[Unquotedstring] 02 31 30 B3[,] C8[Unquotedstring] 02 38 38 B3[,] C8[Unquotedstring] 01 33 B6[)] call vchar(5,10,88,3,8,10,88,5) -> 45 byte instead of 54 byte 9D[CALL] C8[Unquotedstring] 05 56 43 48 41 52 B7[(] C8[Unquotedstring] 01 35 B3[,] C8[Unquotedstring] 02 31 30 B3[,] C8[Unquotedstring] 02 38 38 B3[,] C8[Unquotedstring] 01 33 B3[,] C8[Unquotedstring] 01 38 B3[,] C8[Unquotedstring] 02 31 30 B3[,] C8[Unquotedstring] 02 38 38 B3[,] C8[Unquotedstring] 01 35 B6[)] Still a lot more than the 6 bytes in my suggestion, but it depends on how large (and fast) the interpreter is whether this really pays off. I read so much about compressed sound I wondered if there were compressed graphics as well. My second thought about the >127 character is a "pen" solution. First set the character in Hex : $A5 and the do the drawing H5A3. Or always use two bytes for the character in hex: H5AA53. This would still save 22 byte with every HCHAR. Think of 5 levels with 10 xCHAR lines you'll have 1kb saved. Steve
  10. Hi there, when I wrote XB games with multiple rooms/levels I usually defined a description string, wrote a little interpreter and stored the levels in DATA statements (or a file). Usually a level had 30 to 60 bytes and the format was depending on the game, universal would be more. I wonder whether there is a generic format to shorten the CALL HCHAR, VCHAR, SPRITE etc already established? One char per command or parameter, no need for seperators etc., i.e. five bytes for a HCHAR with character, row, column and repeat. Using 0-9, A-Z,a-z would give us 0 to 61, whereas I often used ASC(x)-48 which is faster but harder to read ... colon equals 10, D equals 20. With a level editor readability would not really be an issue, would it? Sprites would be positioned according to character coordinates (row*8)-7. CALL HCHAR(5,10,88,3) could be H5AX3 or H5:X3. Does this makes sense? Or is there already something I wasn't able to find because this is hard to google? How to handle char codes beyond 127? Any clever ideas? Thank you Steve
  11. You made my day ... works perfect again! Consider to be my hero of the day, I saw myself already working my way through the documentation how to flash this thing ... Thank you, Steve
  12. Hi. I bought an assembled SDrive-MAX and screwed up the screen-calibration when playing around. I can't reach the CFG-Button anymore to correct this. Is there a way to reset to "factory defaults" or something? sdrive.atr loads and everything works from the Atari, but the screen is currently not usable... Any help would be appreciated. Steve
  13. I was curious ... here is SPEEDY.SXB in the RXB version ... works as expected out of the box. // SPEEDY // A demo of "Structured Extended Basic" by Stefan Bauch REPEAT GOSUB initialize REPEAT CALL KEY(0,K,S) :: B=B+(K=65)/4-(K=76)/4 :: B1=B-INT(B) :: Q=Q-(B1=.75)+(B1=.25) :: W=W-(B1=.5)+(B1=0) CALL GCHAR(Q,W,E) :: SC=SC+1 :: CALL VCHAR(Q,W,130) UNTIL e<>32 CALL SAY("GAMES OVER") DISPLAY AT(24,2):"GAME OVER SCORE :";SC CALL KEY("YN",3,K,S) UNTIL K=78 END initialize: CALL CHAR(130,"") Q=23 :: W=16 :: B=100.25 :: SC=0 CALL CLEAR :: CALL VCHAR(1,1,130,23,1,32,130,23) :: CALL HCHAR(1,1,130,32,23,1,130,32) FOR I=6 TO 18 STEP 6 :: CALL VCHAR(I,10,130,1,I,17,130,1,I,24,130,1) :: NEXT I CALL CHAR(130,"FFFFFFFFFFFFFFFF") RETURN
  14. Hi all, thank you for your positive responses. Until yesterday I was just programming for my own needs, so I adjusted the font for my needs and skipped the help menu. Now I know that there are more people interested I will add this in version 1.1. @sometimes99er I have no security infrastructure, so neither my website has an SSL certificate nor can I sign my programs digitally. @dhe Syntax highlighting, -help and code completion is available in the used SynEdit component, but I do not want to spent time there at the moment. If someone builds a Lazarus component I would be happy to include it. I may include some basic statistics in the project page if this is helpful. My code does not build any syntax graph or something, it does only context-insesitive text manipulations. Therefore I do not have any parsing in place for the used variables, sorry. But I am not quite happy with the Char editor. I think I will re-write it as a Charset editor one day. @RXB As long as RXB uses the same tokens it might work without any changes. The subroutine name is an unquoted string and all parameters are just translated to tokens, not interpreted in any way. Steve
  15. I agree ... I started the whole project because I wanted to finish some games I started in 1984 and abandoned them as XB was too slow to be fun to play. ISABELLA changed this, but my XB code is gibberish now. I changed all jump-destinations to labels and removed the line-numbers. The GOTO-mess remained. So yes, TiCodEd is a good way to conclude old developments, with large a screen and syntax-highlighting, but nice code requires a full re-write. My speedy.sbx example is also a port of 1983 TI Basic program, but it is small enough to be easily refactored. The WHILE would normaly also been a REPEAT loop, but I wanted to have both shown in the demo. From another game that was far less completed I will do a full SXB-rewrite, re-use only graphics and some few transformed functions. This might become a complex demo to be included someday.
×
×
  • Create New...