Jump to content

Search the Community

Showing results for tags 'basic'.



More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • Atari Systems
    • Atari 2600
    • Atari 5200
    • Atari 7800
    • Atari Lynx
    • Atari Jaguar
    • Dedicated Systems
    • Atari 8-Bit Computers
    • Atari ST/TT/Falcon Computers
  • Gaming General
    • Classic Gaming General
    • Classic Computing
    • Modern Gaming
    • Prototypes
    • Arcade and Pinball
    • Emulation
    • Hardware
    • Gaming Publications and Websites
    • International
  • Marketplace
  • Community
  • Game Programming
  • Site
  • Classic Gaming News
  • The Club of Clubs's Discussion
  • I Hate Sauron's Topics
  • 1088 XEL/XLD Owners and Builders's Topics
  • Atari BBS Gurus's Community Chat
  • Atari BBS Gurus's BBS Callers
  • Atari BBS Gurus's BBS SysOps
  • Atari BBS Gurus's Resources
  • Atari Lynx Programmer Club's CC65
  • Atari Lynx Programmer Club's ASM
  • Atari Lynx Programmer Club's Lynx Programming
  • Atari Lynx Programmer Club's Music/Sound
  • Atari Lynx Programmer Club's Graphics
  • The Official AtariAge Shitpost Club's Shitty meme repository
  • The Official AtariAge Shitpost Club's Read this before you enter too deep
  • Arcade Gaming's Discussion
  • Tesla's Vehicles
  • Tesla's Solar
  • Tesla's PowerWall
  • Tesla's General
  • Harmony/Melody's CDFJ
  • Harmony/Melody's DPC+
  • Harmony/Melody's BUS
  • Harmony/Melody's General
  • ZeroPage Homebrew's Discussion
  • Furry Club's Chat/RP
  • PSPMinis.com's General PSP Minis Discussion and Questions
  • PSPMinis.com's Reviews
  • Atari Lynx 30th Birthday's 30th Birthday Programming Competition Games
  • 3D Printing Club's Chat
  • Drivers' Club's Members' Vehicles
  • Drivers' Club's Drives & Events
  • Drivers' Club's Wrenching
  • Drivers' Club's Found in the Wild
  • Drivers' Club's General Discussion
  • Dirtarians's General Discussion
  • Dirtarians's Members' Rigs
  • Dirtarians's Trail Runs & Reports
  • Dirtarians's Wrenching
  • The Green Herb's Discussions

Blogs

There are no results to display.

There are no results to display.

Calendars

  • AtariAge Calendar
  • The Club of Clubs's Events
  • Atari BBS Gurus's Calendar
  • ZeroPage Homebrew's Schedule

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


Website


Facebook


Twitter


Instagram


YouTube


eBay


GitHub


Custom Status


Location


Interests


Currently Playing


Playing Next

Found 57 results

  1. Hi all! To start the new year, and to provide a better Basic for all the new ten-liners, I'm releasing version 4.0 of FastBasic. The major changes in this version are under the hood: The interpreter has been changed from a stack-base virtual machine to a register plus stack, this makes the interpreter from 10% to 20% faster depending in the program. In the SIEVE.BAS benchmark, the Atari version is 13% faster and in the cross-compiler is 19% faster, but programs depending on fast PEEK and POKE should be much faster. There is now a full test-suite to automatically catch regressions in the parser and interpreter, ensuring that bugs don't re-appear. Also, there are some user visible changes: There is now a command-line compiler "FBC.COM", this allows compiling large programs that don't fit in the full editor. Currently, "FBC" accepts the full floating-point syntax. Added minimal support for Player/Missile graphics: PMGRAPHICS (abbreviated PM.) statements setups P/M, PMHMOVE (abbreviated PMH.) horizontal moving a a player/missile, PMADR() returns the address of the given player/missile data. Many small bugs fixed. In this version the integer IDE is 8188 bytes in size (we still have 4 bytes less than 8K), and the floating-point IDE is 9405 bytes. As always, full sources and binaries for Atari, Linux, Windows and MacOS are available over Github: https://github.com/dmsc/fastbasic/releases
  2. Hi everyone, For various fun reasons, I am trying on an 800xl (in Altirra first) to create a GRAPHICS 8+16 kind of display list with a few extra rows - 208 total would be perfect. I'm not worried about either screen position, or VBI running out of time. Ideally, I would like to be able to then PLOT 319,207, (but poking into screen memory would be ok too) - but I've got something wrong before I get to that stage... My dodgy BASIC effort is attached - I'm moving RAMTOP to 112 first, calling GRAPHICS, and putting this DL into the top of page 6: 112,112,79,0,112 [two 8*blank lines instead of 3, then LMS to 112*256, with a graphics 8 (+15) line] 15 [* 99] - [99 graphics 8 lines. Hence, my total, 100 * 40 bytes, is less than 4k. 79, 0, 128 [Another graphics 8 with LMS, for the next chunk] 15 [* 99] - [another 99 graphics 8 lines - again, less than 4k.] 79, 0, 144 [And another graphics 8 LMS...] 15 [* 7] - 7 more graphics 8 lines makes 208 in total,. 65, 0, 6 [JUMP back to the start] I'm not quite sure what I'm getting in the end - probably about half a screen worth of GRAPHICS 8 that seems much higher than it should be, so I think I must be missing something fairly simple. Can anyone point me in the right direction? Learning display lists properly is probably about 30 years overdue... Thanks, Wes EDIT: Oh, there's a hideous and embarrassing typo - I've poked 561 twice, instead of 560 and 561... (groan) Let me fix that and see where things are! gr8big.lst
  3. Hey all, I'm sorry if this has been answered elsewhere but I'm a bit stumped: I'm using a simple inkey$ to jump out of DO LOOP which has the user press the <spacebar> when they are ready to move on and it works nicely, except for the fact I can't find a way to clear the keyboard buffer? If the user has stabbed away the keys earlier on then it whizzes through the stops quick-fast O_0. Back in BBC BASIC it was a *FX command to clear various buffers, including the keyboard, but I can't find a way in GFA? I've tried the CLEAR command, which didn't seem to do what I needed. Any ideas?
  4. Another Extended BASIC game for the Ti-99/4 line; Star Merchant. Back in the 80's there were several variations of this game where you traded merchandise between star systems. The game dates back to at least August 1981 when Creative Computing published the game but probably goes back even further to the mainframe era. I seem to remember playing something like this on the TI mini-frame in school. Simple game, you buy merchandise in one star port the 'Warp' to another star port and try sell it at a profit. The version I am posting is a modification of a Atari 8-bit version that Creative Computing sold through a 3rd party. I again use Harry Wilhelm wonderful 40 column routine as I used with the Civil War program. Only difference is I'm using the inverse utility in T40 to livin' up the text. Translating from the Atari 8-bit was fairly straight forward for this program (not like the Mille Borne which took and almost total rewrite). The two things that were the big difference was, of course, string usage and the fact that with the Atari you can have a variable line number in a ON GOTO and ON GOSUB statement (can't with the TI ExBASIC). Included is a copy of the manual for T40, the auto LOAD .dsk of the game and a copy of the original text from Creative Computing Aug, 1981 where the game was printed. Enjoy, HLO star-mech.zip
  5. Mille Borne is a French card game of auto racing currently being sold by Parker Bros. The actual card game can be played with 2-6 players but the computer game is 2 player only; you vs. computer. The object of the game is accumulate enough mile cards to make it to the finish line. But there are hazards along the way that will keep you from that goal. If you haven't ever played the game refer to the manuals I have included with the game .zip file. in this computer version there are a few differences. a.) to start the game you can choose a long game (standard 1000 miles/5000 total) or short game (700 miles/3000 total). b.) when playing a safety or Coupe Fourre you don't get an extra turn. (it was too much trouble to implement). I think everything else is the same. some history on the program. This game is a translation of a game I have had on the Atari 8-bit forever. I have no idea where it came from on the Atari. I would love to credit the programmer but have no idea who he or she is. On programming the game. As I said, this is a translation from Atari 8-bit BASIC. At first I thought that it would be a direct translation but the differences in how the strings work on the Atari BASIC to convert to TI-XB turned out to be too time consuming. So, basically, I just rewrote the TI-XB with guidance from the original program. Some of the code looks a little, out of place. this is usually the code I pulled directly from the Atari BASIC. This probably makes the code a little slower than if I had programmed it in TI-XB from scratch but I didn't want to spend an additional week to just fine tune for a few seconds of speed. Anyway, enjoy the game. UPDATE: forgot to mention, I have a small simple routine that redefines the character set to true lower case. only takes about 3 seconds to load in XB. should even work in console BASIC. just cut a paste into your program. millborn.zip
  6. About 6 years ago, for a Jaguar, a created a VRBasic Translator (in .NET) that translates VRBasic code into C and then feeds it into the C compiler to get the target platform (Jaguar) binary. Since, allegedly, there's no BASIC for Lynx (I really wouldn't know, as I'm ignorant on the platform's history and only got familiar with coding it in C/Asm few months ago) - it looks like it might be worthwhile to port the VRBasic to Lynx as that might entice more users to the platform. I took the liberty to implement the Microsoft's syntax of BASIC, so this would be unfortunately quite far from the Atari 800 XL's Basic syntax (with line numbers), but: - it's still much more accessible than C - no Line numbers - no curly braces - no semicolons - you can use hardcoded paths to your art assets (sprites) right in your code (without using any external tools), and the backend will do all the heavy lifting (loading, conversion, alpha keying) at the compile-time, so on Jaguar it just works Here's one sample to show the syntax: ' VRBasic Sample 05 - Sprite Drawing ' Sep-2013 ' Declare the sprite variable as a global variable to avoid passing it to every function using it Module Globals Dim ImgWall As Sprite End Module ' Draw all colors in the palette Sub DrawPaletteAt (xp As Integer, yp As Integer) For idxColor As Integer = 0 To 255 DrawPixel (xp + idxColor, yp, idxColor) Next idxColor ' Draw some helper points every 32 pixels to assist with picking the color index For idxHelper As Integer = 0 To 8 DrawPixel (xp + idxHelper*32, yp+1, 127) Next idxHelper End Sub Sub Main () SetGraphicsMode () DrawPaletteAt (32,0) ' LoadImage takes a full path, so you will have to update it based on where you installed the VRBasic LoadImage (ImgWall,"c:\jaguar\_Projects\_VRBasic\src\Samples\ArtAssets\TileA2_16_Colors_Palette.gif",8) ' Now let's place the palette of the loaded image at the desired destination in our palette - for example at index 100 CopyPalette (100,ImgWall) ' Of course, since we changed the palette indices of the image after loading, we need to update the image data for the same offset ' Under Virtual Jaguar, upon every restart of the *.j64 (e.g. when it reaches End Sub for Main () ), this will have the effect of further offseting the colors, since VJ does not seem to reload the *.j64 (merely jump to Sub Main), thus the Image Data are not physically reloaded OffsetImage (100,ImgWall) ' Let's display the sprite roughly in the middle of the screen ShowImage (ImgWall, 160,100) Wait (5000) End Sub Obviously, the platform's specific functionality (sprites, palettes, etc.) would have to be recoded for Lynx (or use TGI), but the basic language should, in theory, compile fine (assuming no major differences between jaguar's C and cc65) right out of the box. I should also have a full PDF documentation, somewhere on my hard drive...
  7. I would like to serve this topic as a discussion on the BASIC Ten-Liners Contest, especially the two areas: 1. Removal of the FREI category this year, which I believe is unreasonable and doesn't help the contest in any way. - Because the FREI category was established the previous year, this year I have been experimenting a lot with what kind of functionality I can fit into 10 lines of hexa code (about 2.2 KB of assembler code) - I just checked my source code, and I wrote over 5,000 lines (yes, five thousand) of assembler code, figuring out the best compromise between performance&size of the code for each component of the game - It was very exciting finding out what kind of functionality (some quite surprising and unexpected) can be fit within that limit - Hence, it was quite frustrating to see the category removed - For as long as there have been magazines with BASIC listings, inlined ASM code was always integral part of the charm of BASIC - since it doesn't in any way affect the other categories, I really see no reason why it should be removed - the only thing the removal achieved was two less entries for 2019 from me (and who knows how many other people were in same situation) TLDR: It can open up a new uncharted territory of games possible in 10 lines. 2. Inclusion of Compilers (as a separate category) - if my understanding of rules is correct, the only BASICs allowed are the ones that have an editor on the target platform (e.g. you must be able to type the program on an actual Atari (or other computer)) - this would rule out the compilers that exist on PC only - because of my recent work on Lynx, 2 weeks ago I have created a PC-based 6502 compiler (by modifying my Jaguar's 68000 & GPU RISC compiler) of a high-level language that resembles C, and feeds into the cc65 linker toolchain - it would be relatively easy to change the syntax of the language to be BASIC-like - there would be no Atari-based editor or compiler, as I really see no point in creating yet-another editor. - this can however bring the increased productivity of PC-based workflow (Notepad++, Photoshop, etc.) and increase the quality of the target application that is otherwise utterly impossible to achieve by purely typing program on a physical HW TLDR: It can further push the boundary of 10-liners due to much higher execution speeds of compiled code and increased work productivity on PC. It's important we know about this by the end of November, ideally. Posting a contest announcement thread on January 31 will be definitely too late for me (as I will be busy with Jaguar in Q1, especially around March) and I'm sure others would love to know too, as for us there are only 2 options: - resume/start the ASM coding for the 10-Liners Contest - ignore the Contest altogether
  8. Hi all! A new release of FastBasic is available, this is Release 3. This release has with many enhancements, mayor ones: - Added string comparison operators, - Interpreter is about 3% faster in FOR loops and other simple operations. SIEVE benchmark now takes 17 seconds. - The integer-only IDE is now less than 8KB, the floating point IDE is 9.2kB, and there are 200 bytes more available for the programs. - Cross compiler produces smaller executables by only including used parts of the runtime, a simple '? "Hello"' compiles to 453 bytes, including the interpreter and runtime. Minor improvements to the IDE and language: - The IDE now can edit files with lines of up to 255 bytes. - The IDE is a little faster to parse large files. - More abbreviations to the statements, The list of abbreviations is in the manual. Mayor improvements to the cross-compiler and optimizer: - New scripts for the cross-compilers allows passing options to the compiler and linker, also writes label files for debugging. - Cross compiler gives better errors in many cases. - Optimizer for NEG/MUL/DIV/MOD and all bitwise operations. - Optimizer ignores comments and can span multiple lines. - Adds tail-call optimizations (replaces CALL/RET with JUMP and JUMP to RET with RET) And many fixes: - Optimizer no longer ignores negative numbers, - Correct corner cases with MOVE / -MOVE, updates docs. - Cleanup all variables and arrays on run, fixes on memory-clearing function. - Fixes some cases of integer to floating point comparisons. - Fixes parsing of NOT with parenthesis and NOT/NOT. - Fixes errors on line numbers > 255 in the IDE. - Fixes some corner cases in the IDE editor with lines at top/bottom of screen. - Parsing of statements after a ':' ignored errors. As always, full sources and binaries for Atari, Linux, Windows and MacOS are available over Github: https://github.com/dmsc/fastbasic/releases Have fun! Edit: current version is v4, announcement at https://atariage.com/forums/topic/288617-fastbasic-40-tenliners19-release/
  9. Hi All!, After a long time, I updated my BASIC parsing tool, this is a major release that includes an Atari BASIC parsing mode, this limits the parser and optimizations, disabling all Turbo-Basic XL extended commands. To use this mode, use command line option "-A". As always, full source and binaries are at github: https://github.com/dmsc/tbxl-parser/releases/tag/v10 basicParser-v10-0-gc06210e-linux64.zip basicParser-v10-0-gc06210e-manual.pdf basicParser-v10-0-gc06210e-maxosx.zip basicParser-v10-0-gc06210e-win32.zip
  10. So... being a fan of human readable over tokenized source code files, I got the idea in my head that I should convert my tokenized Atari BASIC and BASIC-XL files into text based ones. I did so on about a dozen files by loading in the tokenized version, and then LISTing them out to a text version. I popped them open in The Last Word and they looked real good. So I went ahead and deleted the binary tokenized versions. Oopsy; rather than just verify the listed files came out good, I should have also verified that the would ENTER back in okay. Yes indeed. I am having trouble being able to successfully ENTER them back in. I suspect it has something to do with control code characters. I'm guessing that the ENTER command behaves just as if the user were typing from the keyboard. The problem with that of course is that the user would need to prepend control codes with the escape key to avoid them being interpreted literally, which I doubt the ENTER facility bothers to do. Anyway, does anyone know what the issue might be? Am I onto something or might it be something else? Solutions?
  11. I'd like to introduce my latest project: Altirra Extended BASIC, a Turbo-Basic XL compatible interpreter implemented in a banked MaxFlash 1Mbit cartridge. Often when I need to do testing on the physical hardware I just end up using BASIC when the speed and control of assembly isn't needed, as I can just type in the program instead of hooking up the tether to upload one. Problem is, Atari BASIC is missing useful features like hex values, and the Altirra BASIC cartridge is packed like a can of sardines, so I couldn't add anything substantial there. Thus, the idea came to take Altirra BASIC and split it across cartridge banks so that it could be expanded. At the same time, experience had shown that much of the BASIC XL subset wasn't that useful due to the small pool of people who had used it and could run it, but with the extra space I could implement a far more expansive and available language: Turbo-Basic XL. Therefore, once I had gotten the interpreter reorganized into a banked cart, it was then possible to begin reversing TBXL's token format and reimplementing the extended language. Details: Uses a MaxFlash 1Mbit (128KB) cartridge. I chose this cartridge type because of its address-based banking mechanism, which turned out to be faster than data-based banking. Figuring out a usable long jump mechanism was a big obstable to getting this off the ground. Also, I have one of these carts and it's fairly widely emulated in the mega-carts. Currently 7 8K banks are used, 6 of which are split with a 4K shared bank and a 4K variable bank, and the last one being a special full bank for the help system. Half the cartridge is thus currently unused. Unlike Turbo-Basic XL, Altirra Extended BASIC does not occupy memory at MEMLO or memory under the OS ROM. This means that its memory layout is closer to Atari BASIC and it will run on a 400/800, even with 16K. Some TBXL programs are incompatible because they hardcode addresses in the $A000-BFFF range which Altirra Extended BASIC occupies. ATXBasic is binary compatible with Turbo-Basic XL 1.5 save files. However, this means that it is not binary compatible with Altirra BASIC's BASIC XL subset. Conflicting token values, couldn't do both. Some statements like LOMEM have been relocated to new token values above TBXL's. The AltirraOS math routines have been hoisted into the cartridge and reworked for speed. They are not necessarily as fast as TBXL's yet -- haven't touched division or transcendentals yet -- but it should be in competitive range overall. The OS math pack is not used so results are consistent between OSes. I implemented as much of the Turbo-Basic XL language as I could find documented or tokens for, and tried to match TBXL's behavior when it diverged from Atari BASIC, such as the ON statement. One deliberate incompatibility: TIME$ uses the accurate frame rates for NTSC and PAL, no way I was going to use hardcoded 50.0Hz. There is also a built-in help system, which I plan to fill out QBasic-style -- mainly because I am tired of turning away from the Atari to look up OS and hardware addresses. Writing the help directly is a pain, though, so it only has two pages right now. Need to write a help compiler. Preliminary docs are attached, though I still need to edit some old stuff from Altirra BASIC that needs to be changed. All that being said, I could use help testing the TBXL subset. I have a large collection of Atari BASIC programs and have already gotten my classic test suite working (Nazz, SpyPlane, Quadrato, Escape from Epsilon, Valiant, Jenny of the Prairie, etc.) but I have very few TBXL programs. I'd like to get the TBXL subset more solid before jumping into more optimizations or adding more commands, and with Altirra BASIC the community was very good at pointing stuff I didn't know about Atari BASIC. One lengthy TBXL program I've gotten running is Rocket Rescue -- that was fun to fix (PAINT leaks, ugh). atxbasic.bin atxbasic.pdf
  12. Over on the Atari 8 bit forums, they are having a contest where they challenge programmers to "write a game in ten lines of basic"! http://atariage.com/forums/topic/234337-basic-ten-liners-contest-2015/?hl=+basic%20+contest I wondered if I it was possible to write an IntyBasic Game in 10 lines.... Only one way to find out! So I gave it a try.... The result is snake! (Click to animate) Here is the whole program: start: cls : for i = 0 to 19 : poke $200+i,(56*+1 : poke $200 + (20 * 11) + i,(56 * +1 : if i < 11 then poke $200+(20 * i),(56 * +1 : poke $213 + (20 * i) , (56 * + 1 ' line 1 next i : food = 0 : score = 0 ' line 2 dim snake(180) ' line 3 for i = 0 to 179 : snake(i) = 0 : next i : snake(0) = 130 : snake(1) = 131 : slen = 1 : #sdir = 1 : poke $200 + 130,(56 * + 2 : poke $200 + 131, (56 * + 2 ' line 4 loop: wait ' line 5 if food = 0 then food = RAND : if (food > 240) OR (peek($200 + food) <> 0) then food = 0 else poke $200+food,(38 * + 5 ' line 6 if cont1.left then #sdir = -1 else if cont1.right then #sdir = 1 else if cont1.up then #sdir = -20 else if cont1.down then #sdir = 20 ' line 7 if (frame AND $0f) = 0 then #adrs = snake(slen) + #sdir + $200 : if (peek(#adrs) AND $07f8) = (56 * then goto game_over else poke #adrs,(56 * + 2 : if #adrs = (food + $200) then slen = slen + 1 : snake(slen) = #adrs : food = 0 : score = score + 1 else poke $200 + snake(0),0 : for I = 0 to slen : snake(i) = snake(i+1) : next i : snake(slen) = #adrs ' line 8 goto loop ' line 9 game_over: print at 25, "game over" : print at 44, "score = " : print <3> score : wait : if cont2.key = 12 then goto game_over else goto start' line 10 Here is a longer, more readable version (essentially the same program spread over more lines with some comments...) rem snake program rem copyright 2015 rem Catsfolly CONST bluex = (56 * + 1 CONST redx = (56 * + 2 CONST greenf = (38 * + 5 CONST backtab = $200 dim snake(180) ' snake data (offset from start of backtab for each snake piece start: cls ' clear the screen for i = 0 to 19 poke backtab+i,bluex ' draw the top border poke backtab + (20 * 11) + i,bluex ' draw the bottom border if i < 11 then poke backtab+(20 * i),bluex : poke backtab + 19 + (20 * i) , bluex ' top and bottom borders next i food = 0 ' food position. 0 means no food on screen score = 0 ' score rem init snake for i = 0 to 179 : snake(i) = 0 : next i ' clear offsets (probably not necessary…) snake(0) = 130 : snake(1) = 131 ' put first 2 segments in the center of the screen slen = 1 ' there are two segments, number 0 and 1 #sdir = 1 ' direction is "1" (add one to the current address to get to the next square) poke backtab + 130,redx ' draw the first two segments poke backtab + 131, redx loop: wait rem if there is no food then try a random number. If the random number < 240 and the location at backtab rem + the number is blank, then draw the food there and set food to the random number if food = 0 then food = RAND : if (food > 240) OR (peek(backtab + food) <> 0) then food = 0 else poke backtab+food,greenF rem set the direction variable based on the controls (uses exact directions, so probably unplayable with a rem real intelliision controller if cont1.left then #sdir = -1 else if cont1.right then #sdir = 1 else if cont1.up then #sdir = -20 else if cont1.down then #sdir = 20 if (frame AND $0f) <> 0 then goto loop ' slow down the action #adrs = snake(slen) + #sdir + backtab ' get the address of the next square for the snake if (peek(#adrs) AND $07f8) = (56 * then goto game_over ' if its an x, goto game over poke #adrs, redx ' put an x at the new square rem if the new square is where the food was, make the snake longer, set food to zero, and inc the score rem otherwise clear the first square of the snake, and shift the addresses down in the array if #adrs = (food + backtab) then slen = slen + 1 : snake(slen) = #adrs : food = 0 : score = score + 1 else poke backtab + snake(0),0 : for I = 0 to slen : snake(i) = snake(i+1) : next i : snake(slen) = #adrs goto loop game_over: print at 25, "game over" print at 44, "score = " print <3> score : wait if cont2.key = 12 then goto game_over else goto start The game checks for exact up, down, left, and right values on the controls, so it might be difficult to play on real hardware. Here are the files: snake.bas snake_readable.bas snake.rom How about you? Why not take a break from your mega-epic-kroztastic-supergame project, and write a game 10 lines of basic? Catsfolly
  13. Anyone know anything about this program. seems to be a lot like 'the missing link'. I got a copy (from where??) but it only has a little bit of info on it. attached is the .dsk in cf7 format readable by TIdir. XBASIC2.zip
  14. What do you guys think are some of the best games made in the last few years that were done in 100% (or nearly 100%) BASIC? Any version of BASIC for the TI. Compiled BASIC OK. By "best games" I mean the ones you enjoy playing the most and/or show off impressive features.
  15. here is my first attempt on creating Aquarius .rom files from Boriel's ZX-Basic Compiler - i think i'm struggling on the "scramble code" ( http://www.vdsteenov...s/romcheck.html ) or something else? the resulting .rom, the ZX-Basic sources i used, the .asm temporary file (for helping the debug process) and the .sh (bash script on Linux) for the compiling process are all there! the idea was, for now, to do a "cls" with the character 0x41 ("A") and the colour attribute 0x35 (i can't remember now which colours are), and the resulting behaviour looks weird... :S aquarius_borielszxbasiccompiler_experimentalsnippets_201306291704.zip
  16. We would love it if you could check out our Applesoft / Integer BASIC interpreter, DiscoRunner. Unlike most interpreters, we've closely simulated the graphical and sound capabilities of the Apple II, allowing most BASIC listings to run faithfully (it comes with almost a thousand of them!) It has some rudimentary 3D camera support; later versions will add more complex 3D and digital sound capabilities. You can download it for Windows, Mac and Linux at http://discorunner.com Please let us know what you think of it so far! Thanks, April and Melody Ayres-Griffiths
  17. Note: a new version is available over this post. Hi all As a new-year present, I released a new version of FastBasic. It's only a minor bugfix release from last one: - Fixes a bug with floating-point comparisons - Adds more usage information to the cross-compiler. - Fixes display corruption in the editor. - Allows comments after any statement. As always, the full source is over github, and you can download the release at https://github.com/dmsc/fastbasic/releases/full manual at https://github.com/dmsc/fastbasic/blob/master/manual.md and sample programs are included in the ATR or in the source at https://github.com/dmsc/fastbasic/tree/master/samples/int and https://github.com/dmsc/fastbasic/tree/master/samples/fp Over github I included the cross-compiler for Linux, Windows and macOS, but I only tested the Linux and Windows ones. For usage instructions of the cross-compiler, see at https://github.com/dmsc/fastbasic/blob/master/compiler/USAGE.md fastbasic-r2.atr
  18. Hi, I'm new here and am happy to release my "3d" tennis. If you find any glitches let me know. Atari_tenis.bin
  19. Hi all, I'm using Altirra 2.10 to emulate an Atari 800 (or 800XL, or 1200XL, issue is the same). I am booting Atari DOS 2.5 with the BASIC Rev. C cartridge attached, and a host device (H:) to save files. This works fine except for two things: 1. Cannot enter lowercase text at all 2. Cannot enter inverted (high-ATASCII) text at all Yes, I'm kind of a n00b to Atari 8-bit emulation, and would like to try out some BASIC programs which use lowercase and invented chars in PRINT statements. Altirra's helpfile claims that Caps-Lock and End should enable lowercase and inverted text respectively, but it simply does not work. So I'm starting to believe there's something obvious that I'm missing due to my lack of Atari knowledge. Any ideas?
  20. since almost a year, i got really excited with a cross-compiler coded in Python that allows to make z80 binaries (z80 asm were used temporarily there in cross-compiling process) from an ansi-basic syntax very closed to zx-spectrum basic - http://www.boriel.com/software/the-zx-basic-compiler/?lang=en - http://www.boriel.com/forum - http://www.boriel.com/files/zxb/ - http://www.boriel.com/wiki/en/index.php/ZXBasic at the Boriel's wiki page, i started to add some information about Mattel Aquarius (if people know more links with very useful information, please add there too) : http://www.boriel.com/wiki/en/index.php/ZX_BASIC:Aquarius for having a version of it cross-compiling to Mattel Aquarius, we may need help from people skilled enough about how to adapt this Python code for the same purpose, and is comfortable enough to use Aquarius technical information there. what do you all think about this?
  21. I just finished programming a music program into my Commodore 64 in BASIC. I ran it before saving, and it worked fine. I saved it and turned the computer off, then back on and loaded it, then typed 'list' to make sure all the lines of the program were there. They were. So I ran it. All that I could hear was (the best way I can describe it) a clicking sound rather than the musical melody that was there before saving and loading. The program ran for it's regular cycle and exited like it was supposed to, but the sound was messed up. I tried this a few times with the same results. Thinking that perhaps my sound chip was burned out, I loaded games on both cartridge and floppy disk. They worked fine. So my next step was to type the program again, save it under a different name and on a different disk, and run it. Same results.The last thing I did was turn the computer off and back on, then type the program into it again. I ran it without saving and it worked fine. Bad drive maybe? It's just weird that I can load it and the program shows all the lines, but it won't work right. And only after loading it from a 5.25 floppy. Any ideas or thoughts? Just so you know, I am doing this on original hardware. I am using an actual breadbox C64 with a 1541 disk drive and disks that were brand new in the packages(DD Fujifilm). They formatted just fine too. Any advice you can give would be appreciated. Thanks guys!
  22. Hello all, I am a new to this forum. I would like to program the 2600 as a hobby. I have been reading posts this morning on how to begin. I am hoping that some of you nice folks can save me some time. I have read about DASM, batari Basic and others. Can someone answer a few questions for me and save me a great deal of time. Maybe this will help others also. What editor assembler software is used most these days? What do you recommend? Please leave a link. I have downloaded Barair Basic and and IDE and will install it today. Any useful links? Any other software that you folks use? I downloaded Stella and I have ordered a Harmony cartridge. I know these questions have been asked before but I ask for your patience and help. I hope to start writing some code today if I can get the software I need in place. Thanks to all of you in advance. Ed Cheek
  23. set kernel_options playercolors player1colors dim zombiewalk=a dim zombiewalk2=b dim zombiewalkdelay=c dim zombiewalk2delay=d dim zombiespeed=e dim ballwasshot=f CTRLPF=$21 playfield: ................................ ................................ ................................ ................................ ................................ ................................ ................................ ................................ ................................ ................................ XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX end player0: %1101100 %0100100 %0100100 %0100100 %0100100 %0010100 %0001000 %0001011 %1111111 %1111111 %0101010 %0011100 %0001000 %0011100 %0100010 %1000001 %1000001 %1000001 %0100010 %0011100 end player1color: $F0 $F0 $F0 $F0 $F0 $F0 $F4 $F4 $F4 $F4 $F4 $F4 $F4 $F4 $C4 $C4 $C4 $C4 $C4 $C4 end player1: %00011001 %00010010 %00010010 %00010010 %00011110 %00010000 %00011110 %10011100 %10011000 %10111101 %10111101 %10111001 %01111110 %00011100 %00011110 %00110001 %00111111 %00110101 %00111111 %00011110 end COLUBK=6 COLUPF=244 player0x=138 player0y=79 player1x=17 player1y=79 zombiespeed=20 ballheight=1 ballx=139 bally=71 ballwasshot=0 loop drawscreen player1: %00011001 %00010010 %00010010 %00010010 %00011110 %00010000 %00011110 %10011100 %10011000 %10111101 %10111101 %10111001 %01111110 %00011100 %00011110 %00110001 %00111111 %00110101 %00111111 %00011110 end if zombiewalk=1 then player1: %01100110 %01000100 %00100100 %00100100 %00011000 %00010000 %00011110 %10011100 %10111000 %10111010 %10111010 %10111010 %01111110 %00011100 %00011110 %00110001 %00111111 %00110101 %00111111 %00011110 end if switchreset then reboot if joy0left then player0x=player0x-1 if joy0right then player0x=player0x+1 if !joy0fire && !ballwasshot then ballx=player0x+1 if joy0fire then ballwasshot=1 if ballwasshot then ballx=ballx-2 if player0x>138 then player0x=138 if player0x<16 then player0x=16 if player1x>138 then player1x=138 if collision(ball,player1) then player1x=16:ballx=player0x+1:ballwasshot=0:score=score+1 zombiewalkdelay=zombiewalkdelay+1 if zombiewalkdelay=zombiespeed then zombiewalk=zombiewalk+1:zombiewalkdelay=0:player1x=player1x+1 if zombiewalk=2 then zombiewalk=0 goto loop The code was compiling and executing fine a while ago, but now, wherever I place my cursor, there is a syntax error there. Any tips?
  24. I'm extremely new to actually using the CoCo 2 and basic code in general. So I found some sample basic code in an old december issue of The Rainbow that does a little Xmas demo and i'm wondering if there is a way to type it in on my modern computer(this one is a Macbook Pro, but I can also run windows so i'm fairly platform agnostic) in a text editor and convert that file to a cassette image or a disk image I can load on the CoCo? Does this even make sense?
  25. Hi! There is a new version of my FastBasic interpreter available, now with optional *floating point* support. Also, I have written a full language manual, you can browse it at: https://github.com/dmsc/fastbasic/blob/fastbasic-fp/manual.md Note that the manual is also included in the disk image. The two files contain the two versions: - Integer only, currently 8633 bytes, a "?FRE()" minimal program reports 30458 bytes. - Integer and floating point, currently 9431 bytes, a "?FRE()" minimal program reports 29642 bytes. Note that FP variables end with a "%" sign, and use the OS mathpack, so FP calculations are slow. Also, you can't have two variables of different type and same name (so "var%" and "var$" are not allowed). As always, full sources are at github, see https://github.com/dmsc/fastbasic/tree/fastbasic-fpfor the floating point version and https://github.com/dmsc/fastbasic/tree/master for the integer only version. And you can compile the sources to get the cross-compiler, build from the same sources as the atari compiler. Enjoy, and report any problem! fastbasic-int-20170719.atr fastbasic-fp-20170719.atr
×
×
  • Create New...