Search the Community
Showing results for tags 'turbobasic xl'.
Found 4 results
-
Similar to @phoney's question here, but in TBXL not FB. I have a menu disk I wrote in TurboBasic XL, and I'd like to cleanly launch executables (tiny, self-contained bootable .xex-es) from it. I'm using `BRUN`, and running into crashing and obvious memory loading issues. I've looked through De Re Atari, but the Atari memory map is still a bit of an eldritch art to me, so forgive me. Is there a more solid way of doing this, that doesn't crash? (specifically, these seem to crash when a key is pressed after they execute. I tried it in both A8MXa and Altirra, cofigs attached; don't have real hw to try it on). I think the underlying issue is that these expect a clean system to boot into, not to be loaded from TBXL; so is there a way to make this work better, like load it into a different part of memory, or reset memory to default before loading it? I've set up a Gr.8 screen and PMG in my menu, both of which use a bunch of RAM, so... I attached my current menu disk effort as an ATR for testing along with the basic file. Any ideas? Note I also tried a different way or executing the entries, which worked even less well: REM the old fragile basic executable loader way (even more fragile): xex$(len(xex$)+1)=chr$(155) poke 5534,0 poke 5535,192 x=adr(xex$) y=int(x/256) poke 853,y poke 852,x-256*y x=USR(ADR(["hL~)~{bbar}"])) atascii23 compo menu - ntsc version.atr atascii23 compo menu - ntsc version.bas
-
Similar to @phoney's question here, but in TBXL not FB. I have a menu disk I wrote in TurboBasic XL, and I'd like to cleanly launch executables (tiny, self-contained bootable .xex-es) from it. I'm using `BRUN`, and running into crashing and obvious memory loading issues. I've looked through De Re Atari, but the Atari memory map is still a bit of an eldritch art to me, so forgive me. Is there a more solid way of doing this, that doesn't crash? (specifically, these seem to crash when a key is pressed after they execute. I tried it in both A8MXa and Altirra, cofigs attached; don't have real hw to try it on). I think the underlying issue is that these expect a clean system to boot into, not to be loaded from TBXL; so is there a way to make this work better, like load it into a different part of memory, or reset memory to default before loading it? I've set up a Gr.8 screen and PMG in my menu, both of which use a bunch of RAM, so... I attached my current menu disk effort as an ATR for testing along with the basic file. Any ideas? Note I also tried a different way or executing the entries, which worked even less well: REM the old fragile basic executable loader way (even more fragile): xex$(len(xex$)+1)=chr$(155) poke 5534,0 poke 5535,192 x=adr(xex$) y=int(x/256) poke 853,y poke 852,x-256*y x=USR(ADR(["hL~)~{bbar}"])) atascii23 compo menu - ntsc version.atr atascii23 compo menu - ntsc version.bas
-
new game "Invenies Verba" (latin: "find the words")
billkendrick posted a topic in Atari 8-Bit Computers
A few months ago I became aware of a game (by a small company that a friend & past co-worker of mine works for now) for iPhone and Android called "LEX". It's a fast-action word puzzle that's a lot of fun to play. So... I've cloned it for the Atari 8-bit, of course! You can learn more about it, and download it from http://newbreedsoftware.com/iverba/ (or see attachment). The objective is to get as high a score as you can, by entering words. You get a stack of random letters, and create words by using some of those letters (they'll get replaced by more random letters). Similar to games like Scrabble, each letter is given a point value -- common letters have low scores, uncommon letters have high scores. The catch is, you need to use letters before they run out of time -- in LEX, the letter's color changes (as though it's filling up) from bottom to top; in Invenis Verba, I draw a little vertical line next to each letter -- if any letter "fills up", the game ends! Different letters' meters fill up at different rates -- common letters fill up fast, uncommon letters fill up more slowly. The current release of the game (1.0, my first beta release) contains two dictionaries: English (4800 3- to 8-letter words), and German (2000 3- to 8-letter words). Others can be made, which I'll get into a little below. (It's late, so in the end, I'll probably wait for people to ask for help before I try to explain everything in too much detail.) Due to how I've constructed the dictionaries, only 15 ASCII characters (A-Z) from each language's alphabet are used. (I pick the most frequently-used letters, then grab all of the 3- to N-letter words that contain just those letters. In English, based on the /usr/share/dict/american-english file on my Ubuntu laptop, it uses A, C, D, E, G, I, L, M, N, O, P, R, S, T, and U.) I've also had success generating French, Italian and Spanish dictionaries. I've been developing this game on my Linux laptop, entering TurboBASIC XL code as plain ASCII into a text editor, and then using a tool I made during the NOMAM 2014 contest to convert that to ATASCII, and fire up Atari800 emulator to actually load and run the code. I made another simple tool (in PHP of all things; it's because I use it all day at my day job!) to come up with, and store/pack the dictionary files. I use a binary search to find words in the dictionary -- you can't just enter random junk and get points, it has to be a word -- and it's playable but kind of slow in straight TubroBASIC XL. Therefore, the ATR disk image I released (at the site above, or also attached to this post) contains the compiled TBXL, which runs much faster. (Note: I'll be tweaking the meter speed, since now that goes a little too fast.) I've also posted the source code & tools & instructions I use to build the game, so if you have a Linux box handy, you should be able to play with the code. (Maybe I need to post it to github? ) Anyway, tell me what you think! And be sure to check out LEX, which is a lot of fun to play. (Oh, and they recently open-sourced their code!) iverba-1.0.atr- 23 replies
-
- 6
-
-
- puzzle
- turbobasic xl
- (and 1 more)
-
Hi All, Seriously, I have no idea what is happening here. I am working on a TURBO BASIC program that will let the user exercise their (relative) ear. It is planned to test intervals melodic and harmonic and probably a few other things. To come as close as possible to the wanted frequency (I have really a sensitive and precise ear) I use 16-bit pokey registers in stead of 8bit. Downside is that I only can play 2 tones together, but ok... Perhaps I might decide later to go to the 8bit 4# voice capabilities of pokey. Earlier today I found that DSOUND 0,4020,10,10 would produce a perfect 220Hz A and and DSOUND 0,2008,10,10 would produce a perfect 440Hz A. I was very happy with the results, I saved my program to disk and that was that. Now I fired up the Atari with Turbo Basic and I was playing again with the DSOUND command and I was not as satisfied as I was earlier today. I was like: hmm it is not right. So I started playing again with it and I found different values. After checking: DSOUND 0,4028,10,10 gives the perfect 220Hz A DSOUND 0,2017,10,10 gives the perfect 440Hz A DSOUND 0,1001,10,10 gives the perfect 880Hz A Ok it is not really a big difference, but still, I was not as close as I would have thought. So my 2 questions are: How stable is this anyway? Can I assume that pokey in 16bit modus produces a steady frequency or does it fluctuate (when colder/warmer) or is it a different part on the PCB that might have influence on the frequency? (Like the audio-out circuit)? I am using the speaker of my television set, so it is not directly what comes out of pokey. In the Turbo Basic Manual by Wil Braakman I read a formula: "de berekende frequentie in HERZ nu 1789790 / (2*freq+14) bedraagt. De frequentie bedraagt dan 16 bit (0 . . . . 65535)" (Braakman, 1988, p. 3-36). This means that the 16bit pokey value for 440Hz would be: 1789790 / (2*440+14) is approx. 2002 which is closer to my earlier find of 2008, and than my newer find of 2017. It seems that either this formula is wrong, or my ears/tuner-app. My personal findings using ear and tuner-app come way more close to 220Hz, 440Hz and 880hz than this formula. Is there a better formula somewhere? Or is there something else wrong? Or do I ask too much of a formula anyway? I am really interested in this stuff, I hope someone can help. Marius -- Braakman, W. (1988). TURBO BASIC XL 1.5 MANUAL. 's-Hertogenbosch, Netherlands: Stichting Atari Gebruikers.
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord