Jump to content

SteveB

Members
  • Posts

    638
  • Joined

  • Last visited

Everything posted by SteveB

  1. Could you send me an example? I'm sure this is fixable ...
  2. I have one for some years now ... I wish I had it BITD ...
  3. While moving some old stuff to my new NAS System I found a Bookmark-File from May 2002 ... @Tursi's page at http://tursi.yiffco.com/games/classic99/ isn't online anymore... but still in the archive.
  4. I haven't seen a game manual ... as I know the original game well, I didn't look for one either. You may have a look at our XB Ghostbusters One-Page Manual, there are only minor differences ... Map: If you catch a "Roamer" ghost on the map it will show up during your drive. If you bought the vacuum, you may catch it there. Building: You need to drive to a fashing building to catch a ghost. If no ghost is present, you will end up on the map.
  5. There was an interesting article on a BBC website from the UK: https://www.bbc.com/worklife/article/20240111-it-hasnt-delivered-the-spectacular-failure-of-self-checkout-technology
  6. Thank you. As CRU hasn't been in my projects yet, I would need some specific suggestion for such a section to be useful.
  7. So here are my findings ... I wanted to have a static address, which I can rely on in my program and reserve 4 kB for my levels: BSS >1000 reserve 4kB space for level AORG >FF9E->1000 point to the beginning of the reserved space COPY "S:\classic99\DSK4\LEVELS.TXT" and include the levels This way I could have an XB line adr=-4194 ! >EF9E base memory adress for levels An encoded levels look like this in the LEVELS.TXT TEXT '0020d58Jk2P5cF5Ci8Ea79,' TEXT '1000jF5Ch4N5iWe9CbBPe9M,' BYTE 44 Then I have a "READ" replacement, to read a string from this area: sub memread(adr,s$) s$="" call peek(adr,a) :: adr=adr+1 while a<>44 s$=s$&chr$(a) call peek(adr,a) :: adr=adr+1 wend subend or if you are old-school XB: 31010 sub memread(adr,s$) 31020 s$="" 31030 call peek(adr,a) :: adr=adr+1 31040 GOTO 31070 31050 s$=s$&chr$(a) 31060 call peek(adr,a) :: adr=adr+1 31070 IF a<>44 THEN 31050 31080 subend This whole approach has multiple advantages I can add new levels without rearranging memory until I filled the reserved 4kB I can use memory otherwise inaccessable when compiling XB The disadvantage is, you can't really test this in interpreted mode. So the approach to do READ/DATA first and when everything works, replace the READ with the CALL MEMREAD above, seems to be a good mitigation.
  8. Download: https://github.com/endlos99/xdt99/releases/tag/3.6.4 This includes a markdown-format documentation, also available onnline: https://endlos99.github.io/xdt99/#xbas99
  9. Tomorrow has been postponed due to a total lack of interest ...
  10. Thank you! I will play around with this and see, what I can do .. I will post a summary when done.
  11. It's coming up .. we hope to be ready by Eastern ... another eighties classic not yet on the TI ... now with some extensions.
  12. Hi 99ers, we ran out of memory on our latest compiled XB game. We switched to "put runtime into low memory" and were fine. We filled the memory to almost the last byte. When we compile, we get a "4962 bytes remaining", as the compiled code is more compact than the tokenized, interpreted one. How can we use these bytes? I could load additional level data with CALL PEEK from this memory, but I am not quite sure, which AORG I need to use on the assebler to put it there. Where do these almost 5kB reside exactly? I know that RXB has an enhanced SIZE command: I would think, that >A040 to >B3A1 is unused? The difference is exactly the value given by the compiler. It doesn't look unused in the debugger ... or the values are relicts from previous usage. Did I miss something or could we just AORG >A040, define the levels with 4962 BYTEs until we reach >B3A1, assemble and CALL LOAD? Any thoughts, hints and warnings welcome ... Thank you Steve
  13. Great game! Thank you for this one!
  14. if "moving" then "sliding friction" else "static friction" ?
  15. Some are ... other just search for very favorable positions and view-point...
  16. It is a marketing initiative for Windows 11 ... as we all know, the next version won't have any bugs .... 🤪
  17. This had me wasting half an evening some months ago ... I cut&paste XB code and left a :: :: standing ... bad idea. TiCodEd now looks for it and issues a warning ... I might include ":: REM" as well.
  18. MakecartG creates a GROM based module compatible with the v2.2 console, makecart8 creates a more versatile ROM based module. Both basically disables the 32k memory extension and works out of VRAM to make a dump of the 32k extension. Details can be found in the XB GEM Manual.
  19. The second one seems to be more important .... 😁
  20. Too late, already taken .... Ommmmmm ....
  21. This is great! I always missed the RANDOMIZE X function in the compiler and had to build my own randam number generator in the past. It is a great trick to save lots of space to make things repeatable by storing just a seed and create the values for a level background or attack-pattern in a game.
  22. Thank you ... I got it running in less than ten minutes!
  23. It looks quite ready-ish ... Great game, I can't wait to play it...
×
×
  • Create New...