Jump to content

dmsc

Members
  • Content Count

    646
  • Joined

  • Last visited

  • Days Won

    1

dmsc last won the day on July 14 2017

dmsc had the most liked content!

Community Reputation

1,112 Excellent

3 Followers

About dmsc

  • Rank
    Dragonstomper

Profile Information

  • Gender
    Male
  • Location
    Viña del Mar, Chile

Recent Profile Visitors

8,047 profile views
  1. Hi all! Well, @rensoup discovered a bug in the compressor, so here is a new version. Have Fun! lzss-sap-20191202.zip
  2. Hi! Yes, it could be ported, but you will loose the ability to compile to disk - as the ROM version won't be at the same address than the current version. Have Fun!
  3. Hi again Here are two small P/M demonstration programs that i ported fro BASIC A+ to FastBasic, "toothbrush" and a simple game "eggs". Have Fun! BRUSH.FB EGGS.FB
  4. Hi! Don't know if it is explanatory, bit at least is simpler than the "gameloop.bas" posted before: https://github.com/dmsc/fastbasic/blob/master/samples/int/pmtest.bas Also, you can look at the manual, see at https://github.com/dmsc/fastbasic/blob/master/manual.md , search for PMGRAPHICS and PMHPOS. Have Fun!
  5. Hi! Don't know, but I hope soon Have Fun!
  6. Hi! So, you want an assembler as part of the FastBasic IDE. This would be possible, but with some limitations: - Access to FastBasic variables would be difficult - as they are not at a fixed memory address. - You would need some way to call your code, so you also need access the assembler variables from FastBasic. - It would mean about 1KB extra memory usage in the IDE. This is why I added the possibility to link external ASM files in the cross-compiler, so you can have all your assembly code in a separate file and simply pass the ASM file to the FastBasic compiler - without modifying the FastBasic language. I could add a special syntax only to the cross compiler that would pass you assembly to CA65 under the hood, but I don't want to make the two languages different, one of the big advantages of FastBasic over other languages is that you can do all your development in the Atari itself. Have Fun!
  7. Hi! I did a little research long time ago, and all the versions >1.5 are really only hacks over the original one, with new bugs. If you want to add functionality to TurboBasic XL you can start with my disassembled and commented sources, at https://github.com/dmsc/turbo-dis , that source has some optional enhancements: - Allows setting the load-address to any page instead of the default $2080, to produce versions for smaller or bigger DOS, and to gain 128 bytes more free ram. - Fixes two small bugs in the interpreter: parsing of long lines after IF and handling of run-time FOR stack when deleting lines. - Moves some code around to give a few bytes more RAM. Adding new syntax is not difficult, but you have to grow the low-ram section, reducing the memory available to programs. I don't plan to add more to that source because I think it is better to contribute to the excellent Altirra Extended Basic: fully open-source and not based on Atari BASIC; and I started writing FastBasic that is faster and smaller than TurboBasicXL Have Fun!
  8. Hi! Sorry, I don't understand what you are proposing. Perhaps if you post some source code with what do you mean? Have Fun!
  9. Hi! Well, that is actually a bug plus a misfeature. The parser is designed to allow for the "tenliner" code style, so omitting spaces is supported in all possible places. But, your example shows an actual bug due to the cleverness of the parser. When it encounters the line "DONE=1" it starts by parsing the "D" and "O", so a "DO" statement is recognized, and a DO-LOOP is created in the loop stack. But then the parser expects an end of line, so it pull back and try to parse the line again. This time, it creates the variable "DONE" and parses an assignment statement. But (and here is the bug), the DO-LOOP is not pulled from the loop stack, producing the error you saw (and with no line number information, as the parser state was erased). The above bug also happens with "REPEAT", "WEND", "LOOP" and "PROC", but those cases are not as common as the "DO". I added an explicit check for "DO" and "REPEAT", so this is fixed in current unreleased version, you can now have variables like "DONE" and "REPEATED", see the two byte fix at https://github.com/dmsc/fastbasic/commit/f2aa27435da4af77beab4bcbfbe2ec2938a4383c Have Fun!
  10. Hi! This is a limitation in the way the TurboBasic XL parser works - as it is a modification of the original Atari BASIC parser. The FastBasic parser do not have keywords as such, so you can use variable names that are the same as operator names; you can write very confusing code that way: The output of that program is: Have Fun!
  11. Hi! Good table, I think but it needs adding more entries: AdvanBASIC, Altirra Basic, BASIC++, FastBasic. Also, for TurboBasic XL, size on RAM is 5.5k, size on disk is 18k and number of variables is 256. Have Fun!
  12. Hi! Why you say that FastBasic does not have proper strings? The only limitation is that strings are maximum 255 bytes of length, but it supports all string operations: extracting characters, extracting sub-strings (slicing), concatenation, LEN, VAL, ADR, and also supports string arrays. Next version (I know, I should make a new release) will also support DATA string arrays, those allow storing big arrays of immutable strings efficiently (as DATA's use the least memory in the program). About procedures, I'm planning to add named parameters to procedures, but it will increase the size of the IDE beyond 8kb.... so that would be for a new major version. Even then, I won't plan to support recursive calling with automatic stack parameters - our little 6502 is not built for that , as the stack is really small. Have Fun!
  13. Hi Last released version is 4.0, from GitHub link you posted above. I should release a new version soon, but have had no time to finalize a few things, like the new DLI support. Have fun!
  14. Hi! FastBasic VM is fast and small, and binaries compiled by the IDE are completely self contained, so they don't need any runtime. The reason to use a VM is that it allows larger programs, as the code is smaller than 6502 assembly and the compilation is much simpler. And if you really need the speed, I have a compiler to 6502 machine code available, but currently only as a cross compiler from a PC. And about the language, IMHO, FastBasic language is much more advance than older BASICs, with control statements and procedures, and without GOTO and line numbers. The example posted by @funkheld is old, newer FastBasic versions have P/M support making the code simpler, see attached. Also, the attached version can be compiled and run from the IDE. For another game written in FastBasic, look at Joyas: Have Fun! PD: Here is the "gameloop.bas" code: ' Simple demonstration game loop in FastBasic '''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' Proc Init ' Sets ANTIC mode 4 gr. 28 screen = Dpeek(88) ' SAVMSC ' Set P/M graphics pmg. 1 ' Our player data: ' 5 frames, one static, two going left, two going right data P0_Data() byte = $00,$00,$00,$00,$3c,$3c,$3c,$18,$00,$00,$00,$81,$00,$00,$00,$00,$00,$66,$66, data byte = $00,$00,$00,$00,$3c,$3c,$3c,$18,$80,$00,$00,$01,$00,$00,$00,$00,$00,$36,$36, data byte = $00,$00,$00,$00,$3c,$3c,$3c,$18,$01,$00,$00,$80,$00,$00,$00,$00,$00,$c3,$c3, data byte = $00,$00,$00,$00,$3c,$3c,$3c,$18,$01,$00,$00,$80,$00,$00,$00,$00,$00,$6c,$6c, data byte = $00,$00,$00,$00,$3c,$3c,$3c,$18,$80,$00,$00,$01,$00,$00,$00,$00,$00,$c3,$c3, data byte = $00 data P1_Data() byte = $00,$18,$3c,$7e,$00,$00,$00,$00,$18,$3c,$7e,$3c,$3c,$3c,$3c,$24,$66,$66,$66, data byte = $00,$18,$3c,$3e,$00,$00,$00,$00,$18,$7c,$3e,$3c,$3c,$3c,$3c,$24,$24,$36,$36, data byte = $00,$18,$3c,$3e,$00,$00,$00,$00,$18,$3e,$7c,$3c,$3c,$3c,$3c,$64,$46,$c7,$c3, data byte = $00,$18,$3c,$7c,$00,$00,$00,$00,$18,$3e,$7c,$3c,$3c,$3c,$3c,$24,$24,$6c,$6c, data byte = $00,$18,$3c,$7c,$00,$00,$00,$00,$18,$7c,$3e,$3c,$3c,$3c,$3c,$26,$62,$e3,$c3, data byte = $00 ' Our frame addresses dim P0_Frames(4), P1_Frames(4) for Frame = 0 to 4 P0_Frames(Frame) = Adr(P0_Data) + Frame * 19 P1_Frames(Frame) = Adr(P1_Data) + Frame * 19 next P0_Size = 20 ' Char data data Ch_Data() byte = $00,$00,$00,$00,$00,$00,$00,$00, data byte = $AA,$AA,$AA,$AA,$AA,$AA,$AA,$AA, data byte = $88,$22,$88,$22,$88,$22,$88,$22, data byte = $00,$14,$7D,$7D,$7D,$14,$00,$00, data byte = $00,$A8,$A8,$A8,$A8,$A8,$00,$00, data byte = $44,$11,$44,$11,$44,$11,$44,$11 ' Setup characters just before the P/M graphics move Adr(Ch_Data), PMAdr(-4), 8 * 6 poke $2F4, PMAdr(-4)/256 ' CHBAS Player_x = 56 Player_y = 48 P0Mem = PMAdr(0) ' Get P/M addresses for faster main loop P1Mem = PMAdr(1) poke $26f, 33 ' Set GPRIOR for mixed color P/M HITCLR = $D01E ' P/M Hit clearing HITP0 = $D004 ' Collision Player 0 / Play-field HITP1 = $D005 ' Collision Player 1 / Play-field endproc '''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' Proc StartGame mset P0Mem, 512, 0 ' Clears P/M cls #6 ' Cleat screen Poke HITCLR, 0 ' Clear collisions Sound ' Clear sounds Setcolor -4, 3, 10 ' Player 0 color Setcolor -3, 8, 4 ' Player 1 color Player_x = 56 Player_y = 48 Frame = 0 got = 0 snd = 0 ' Draws play-field color 34 plot 0,0 : dr. 39,0 : dr. 39,23 : dr. 0,23 : dr. 0,0 color 33 plot 1,1 : dr. 38,1 : dr. 38,22 : dr. 1,22 : dr. 1,1 color 35+128 for i=0 to 20 plot rand(15)*2 + 6, rand(15) + 5 next i color 35 for i=0 to 10 plot rand(15)*2 + 6, rand(15) + 5 next i color 36 for i=0 to 10 plot rand(15)*2 + 7, rand(15) + 5 next i endproc '''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' proc GameLoop ' Keeps iteration counter for the colors iter = 0 do pause 0 ' Waits for VB ' Reads HIT hit = peek(HITP0) ! peek(HITP1) ' Now, you should put here the code to copy variables to hardware registers, ' as we are synchronized to the screen. pmhpos 0, Player_x ' Player 0 and 1 are the player pmhpos 1, Player_x Move P0_Frames(Frame), P0Mem + Player_y, P0_Size Move P1_Frames(Frame), P1Mem + Player_y, P0_Size Setcolor 3, 0, iter inc iter Poke HITCLR, 0 ' Clear collisions ' Sound generation if got dec got sound 0,snd,10,got dec snd endif ' Now, the game logic, this does not need to be synchronized ' Store old player position: Old_x = Player_x : Old_y = Player_y ' Moves Player Frame = 0 if (Stick(0) & 8) = 0 inc Player_x Frame = (not (Player_x & 2)) + 1 endif if (Stick(0) & 4) = 0 dec Player_x Frame = (not (Player_x & 2)) + 3 endif if (Stick(0) & 2) = 0 inc Player_y endif if (Stick(0) & 1) = 0 dec Player_y endif ' Check if we are over a wall Screen1 = Screen + (Player_x - 48) / 4 + ( (Player_y - 32) / 8 ) * 40 Screen2 = Screen + (Player_x - 48 + 7) / 4 + ( (Player_y - 32 + 18) / 8 ) * 40 if Peek(Screen1)=1 or Peek(Screen2)=1 Player_x = Old_x Player_y = Old_y endif ' Check if we are dead! if hit & 8 exit elif hit & 6 ' Got something, setup sound got = 16 snd = hit * 40 ' Brute force clear all behind our character Screen3 = Screen + (Player_x - 48 + 7) / 4 + ( (Player_y - 32) / 8 ) * 40 Screen4 = Screen + (Player_x - 48) / 4 + ( (Player_y - 32 + 18) / 8 ) * 40 Poke Screen1, 0 : Poke Screen1 + 1, 0 : Poke Screen3, 0 : Poke Screen3 - 1, 0 Poke Screen1+40, 0 : Poke Screen1 + 41, 0 : Poke Screen3 + 40, 0 : Poke Screen3 + 39, 0 Poke Screen4, 0 : Poke Screen4 + 1, 0 : Poke Screen2, 0 : Poke Screen2 - 1, 0 Poke Screen4-40, 0 : Poke Screen4-39, 0 : Poke Screen2-40, 0 : Poke Screen2 - 41, 0 endif loop ' Dead loop for iter = 10 to 0 step -1 sound 0, iter, 2, iter Setcolor -4, 3, iter Setcolor -3, 8, iter * 4 / 10 pause 1 next endproc '''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' ' Main Game Exec Init ' Calls an initialization function, this sets graphics, loads P/M, etc. do Exec StartGame Exec GameLoop loop end gameloop.bas gameloop.xex
  15. Hi! In my mini-simulator I had to add special tracking of flags after BIT because this usage was interfering with the detection of uninitialized memory usage. Now it allows BIT to read from uninitialized memory but sets the Z, N and V flags as "uninitialized" and reports any instruction that uses those flags. Yes, that is a good use case, as the error path does not need to be fast. You need to remember to not use ERR values from $D0 to $D7, specially the $D5 page that can cause page flips on some cartridges at read Have Fun!
×
×
  • Create New...