SteveB

Guarantied to help against headache: but Asperin might have less side effects. Sometimes the cure is worse than the problem.

I have to admit, when setting up my Linux NAS on a mini-pc last month, I had quite some bash scripts written by ChatGPT. It understood very well what I wanted and created code with error-checking and comments, which ran immediately. In some cases I started simple and added features in the dialog ... ignore .zfs directories, write a logfile, ... It was fun. And spared me from learning the bash syntax, in which I have no real interest in.

Really?

You BASICally found a parsing bug for the SUB statement. It ignores a single token in the variable list before any variable. Therefore the following also works: SUB TEST(SIZE X) SUB TEST(FIXED X) SUB TEST(DELETE X) If you CALL TEST(5), X will be ZERO ... I assume the 5 gets assigned to the strange token-named variable, which you can't access later on with print or anything else. When you set a comma after the token, you get an "incorrect argument list" at runtime. If you adjust your CALL for two arguments, it gets through and the second value gets assigned to X. Yet you can't access the Token-Variable with the first value, without provoking a syntax error. I tried to use it in PRINT, CALL and LET. This also works for more than one variable: SUB TEST(DELETE X, FIXED Y) Perhaps @RXB can share some insights of the SUB GPL code for this unexpected behaviour. Steve

I'm testing my changes and I am amazed how some songs sound much better now .. This one is in G minor (though Google lists half a dozen of keys for this song) ... Enjoy 100 DATA 500,220,0,0,500,349,174,0,375,415,349,0,125,349,311,0,125,220,0,0,125,349,311,0 110 DATA 250,466,261,0,250,349,311,0,250,311,349,0,500,349,174,0,375,523,349,0,125,349,349,0 120 DATA 125,220,0,0,125,349,233,0,250,554,261,0,250,523,311,0,250,415,349,0,250,349,138,0 130 DATA 250,523,138,0,250,698,277,0,125,349,277,0,125,311,311,0,125,220,0,0,125,311,311,0 140 DATA 250,261,261,0,250,391,311,0,750,349,349,0,625,220,0,0,125,311,0,0,250,261,0,0 150 DATA 250,233,0,0,250,207,0,0,500,349,174,0,375,415,349,0,125,349,311,0,125,220,0,0 160 DATA 125,349,311,0,250,466,261,0,250,349,311,0,250,311,349,0,500,349,174,0,375,523,349,0 170 DATA 125,349,349,0,125,220,0,0,125,349,233,0,250,554,261,0,250,523,311,0,250,415,349,0 180 DATA 250,349,138,0,250,523,138,0,250,698,277,0,125,349,277,0,125,311,311,0,125,220,0,0 190 DATA 125,311,311,0,250,261,261,0,250,391,311,0,750,349,349,0,625,220,0,0,125,311,0,0 200 DATA 250,261,0,0,250,233,0,0,250,207,0,0,250,174,0,0,125,523,174,0,125,523,174,523 210 DATA 125,523,349,0,250,523,349,523,125,622,311,523,125,622,0,0,125,622,311,622 220 DATA 250,622,261,622,125,587,311,0,125,587,311,587,250,587,349,587,250,174,0,0 230 DATA 125,523,174,0,125,523,174,523,125,523,349,0,250,523,349,523,125,622,349,523 240 DATA 125,622,0,0,125,622,233,622,125,587,261,622,125,587,261,587,125,523,311,0 250 DATA 125,523,311,523,250,523,349,523,250,138,0,0,125,415,138,0,125,415,138,415 260 DATA 125,415,277,0,250,415,277,415,125,415,311,415,125,415,0,0,125,466,311,0 270 DATA 250,466,261,466,125,311,466,0,125,466,311,466,250,466,349,466,250,349,0,0 280 DATA 125,523,349,0,125,523,349,523,125,523,0,0,375,523,523,0,125,466,0,0,125,523,311,0 290 DATA 250,523,261,523,250,233,523,0,250,207,523,0,250,174,0,0,125,523,174,0,125,523,174,523 300 DATA 125,523,349,0,250,523,349,523,125,622,311,523,125,622,0,0,125,622,311,622 310 DATA 250,622,261,622,125,587,311,0,125,587,311,587,250,587,349,587,250,174,0,0 320 DATA 125,523,174,0,125,523,174,523,125,523,349,0,250,523,349,523,125,622,349,523 330 DATA 125,622,0,0,125,622,233,622,125,587,261,622,125,587,261,587,125,523,311,0 340 DATA 125,523,311,523,250,523,349,523,250,138,0,0,125,415,138,0,125,415,138,415 350 DATA 125,415,277,0,250,415,277,415,125,415,311,415,125,415,0,0,125,466,311,0 360 DATA 250,466,261,466,125,311,466,0,125,466,311,466,250,466,349,466,250,349,0,0 370 DATA 125,523,349,0,125,523,349,523,125,523,0,0,375,523,523,0,125,466,0,0,125,523,311,0 380 DATA 250,523,261,523,250,233,523,0,250,207,523,0,1500,523,0,0 390 ! Player code 400 FOR I=1 to 158 410 READ DUR,F1,F2,F3 420 IF F2=0 THEN CALL SOUND(DUR,F1,0 ) ELSE IF F3=0 THEN CALL SOUND(DUR,F1,0 ,F2,0 ) ELSE CALL SOUND(DUR,F1,0 ,F2,0 ,F3,0 ) 430 NEXT I This restores the (sound-) honor of the TI-99/4a and the faith in the TMS9919, doesn't it?

The quick patch seems to cure the problem. I will rework the code a little and prepare a new release in the next days.

You are right again ... my music knowlegde wasn't suffient when I started this program. I works only correct when in C major. This is why the first note on the second, fourth, sixth and eights measure have a explicit "natual" accidental. The <alter> seems to reflect this already. @syd michel Does this sounds right?

Very interesting .. I currently ignore <alter> and only look for <accidental>flat</accidental> or <accidental>sharp</accidental>. I will see what I can do in the code... this does not really fit in my translation logic.

Yes, I'm afraid it is as good as the hardware permits. The calculation of frequencies to the notes seem to be correct, sometimes off by 1 Hz due to rounding and also different frequency tables. E: 329 vs. 330 Hz G: 391 vs. 392 Hz MuseScore/4a calculates by division from the 8th octave: freq[8,'C',natural] := 4186; freq[8,'C',sharp] := 4434; freq[8,'D',flat] := 4434; freq[8,'D',natural] := 4698; freq[8,'D',sharp] := 4978; freq[8,'E',flat] := 4978; freq[8,'E',natural] := 5274; freq[8,'F',natural] := 5587; freq[8,'F',sharp] := 5919; freq[8,'G',flat] := 5919; freq[8,'G',natural] := 6271; freq[8,'G',sharp] := 6644; freq[8,'A',flat] := 6644; freq[8,'A',natural] := 7040; freq[8,'A',sharp] := 7458; freq[8,'B',flat] := 7458; freq[8,'B',natural] := 7902; You may check out the E/A Manual chapter 20.3 to see the actual hardware divider resolution: Some things work better than others...

Could you send me an example? I'm sure this is fixable ...

I have one for some years now ... I wish I had it BITD ...

Sometimes you don't even need 16 Bit ...

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.

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.

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

Thank you. As CRU hasn't been in my projects yet, I would need some specific suggestion for such a section to be useful.

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.

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

Tomorrow has been postponed due to a total lack of interest ...

Thank you! I will play around with this and see, what I can do .. I will post a summary when done.

It's coming up .. we hope to be ready by Eastern ... another eighties classic not yet on the TI ... now with some extensions.

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

Great game! Thank you for this one!

if "moving" then "sliding friction" else "static friction" ?

Some are ... other just search for very favorable positions and view-point...