Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


dmsc last won the day on July 14 2017

dmsc had the most liked content!

Community Reputation

1,496 Excellent


About dmsc

Profile Information

  • Gender
  • Location
    Viña del Mar, Chile

Recent Profile Visitors

9,359 profile views
  1. Hi! It is meant to show the end-of-file; It was very useful during development of the editor, because you can easily see the state of the buffer and detect any error. But perhaps you are right, and it does not really help. Removing the code to draw the arrow makes the binary 8 bytes shorter 😛 I agree, but it is not easy - the line is simply drawn using PRINT, and there is no way to force inverse video output on PRINT. Adding this feature would be useful for BASIC games, specially using Graphics modes 1 and 2, where you would like to print a string (or your score) using a different color. I also want to add a "TAB()" function, then the status line could be printed with: PRINT COLOR(128);TAB(2);FileName$;TAB(32); 1+topLine+scrLine; TAB(39); Well, many features to add in next versions Have Fun!
  2. Hi! Yes, I'm ok... just very busy with my main job 🙂 Have Fun!
  3. Hi! Yes, you would need to write an "stub" to call PROC's with parameters: ON x EXEC A,B,C PROC A EXEC P 2, 3 ENDPROC Also, it could be abbreviated " O. x @ A, B, C ", with only one "@". Have Fun!
  4. Hi! It is a self-imposed constraint to limit the growth of the language: Mi intent is for FastBasic to be small, simple and fast. So, every time I add something to the language, it needs to be tough as how to minimally add the feature and justify it's usefulness. Yes, I know. What I was trying to say is that IMHO, the current "IF/ELIF/ENDIF" structure gives good code clarity, without complicating the language. Have Fun!
  5. Hi all, and thank you for all responses! Not currently, as Vitoco said, FastBasic currently does not support the "ON/EXEC" statement. Yes, it could even make the editor shorter - as currently uses a long string of "IF KEY=*" for processing all keyboard commands. To correctly implement it, I would need a way to count the number of parameters in the parser, basically, the parser needs to transform this: ON expression EXEC A,B,,,E,F Into this: DATA targets() = A,B,0,0,E,F temp = expression IF temp > 0 AND temp <= 6 THEN EXEC targets(temp) This is specially difficult as the parser can't create arbitrary variables (in this case, "targets" and "temp"), so it would be better to define a new token that mixes all the above. i'm currently rewriting the cross-compiler, so the code is in a state of flux, but after that I will see if adding "ON/EXEC" is actually feasible - in the constraints of 8KB for the IDE. That is not possible in FastBasic, as it does not have line numbers. Also, it is a very bad construct from the compiler point of view, as you can't easily predict the control-flow, making some optimizations imposible - in your example it even allows to jump to any line of the code!. I specifically removed "GOTO" from the language to simplify the parser and make the generated code faster. That would not be as difficult, but IMHO, it does not add anything to the language not possible already, it is fairly easy to just do: X = expression IF X = 2 ; Case 2 ELIF X = 5 ; Case 5 ELIF X = 1234 ; Case 1234 ENDIF Have Fun!
  6. Hi! Thank you, hope you do some great programs with FastBasic You can download the PDF manual at: https://github.com/dmsc/fastbasic/releases/ Have Fun!
  7. i! As others have said, if you don't access the video memory directly and only use standard I/O to the "E:" driver, your program just work in 80 column mode. The FastBasic editor is written in BASIC, and adapts to any number of columns: https://github.com/dmsc/fastbasic/blob/master/src/editor.bas Have Fun!
  8. Hi! It was determined the "source" posted was not really the original source, and not a new version, it was simply a disassembly with some minor modifications to support the TURBO-2000 cassette system. Sadly, the original source is not known, and probably lost. I have a full disassembly, with some optional fixes and minor optimizations over a github repo: https://github.com/dmsc/turbo-dis Have Fun!
  9. Hi! There are a lot of 6502 cores, in Verilog and in VHDL. Two of my recommendations: - The Atari 800 core by Foft uses the VHDL core from the FPGA-64 by Peter Wendrich, see http://www.64kib.com/atarixlfpga_svn/trunk/atari_800xl/common/a8core/cpu_65xx_a.vhd - If you want a really simple and small core, in Verilog, the one by Arlet Ottens is great: https://github.com/Arlet/verilog-6502 A great place to discuss about reimplementations of the 6502 is the 6502.org forum, at http://forum.6502.org/viewforum.php?f=11 There you can find TTL implementations that work replacing the original CPU, and fast TTL implementations at more than 20MHz, with full cycle accuracy. Have Fun!
  10. Hi! Great, so, I now have to add an XORMOVE statement to FastBasic
  11. Hi! Thank you for your comments!! To not miss this, I added a bug report on github: https://github.com/dmsc/fastbasic/issues/46 Have Fun!
  12. Hi! Try this fixed version: circ.lst Fixed two bugs: - an "STA" instead of an "SBC" in one assembly instruction - missing initialization for a table of powers of two. Also, this is the BASIC program, "circle 5", works for me: circ5.lst Have Fun!
  13. Hi! You seem to think that somehow CLANG is more advanced than GCC. This is false. CLANG is a newer project, and has a lot of commercial baking, so it is catching up to GCC fast, but IMHO, it is still behind: it support less targets, is is less mature and it optimizes about the same in common architectures (it produces code sometimes faster, sometimes slower than GCC). GCC support Link-Time-Optimization from version 4.5, released in 2009, just a few months prior to the release of the first version of CLANG (1.0) that still did not had complete C++ support. So, why LTO is not enabled by default? - It is slow, specially on big C++ projects. As the full source code is "visible" to the compiler, and C++ templates produce code explosion, the compiler has to analyze a lot of code, using a lot of memory. - It can fail in older codebases that cheat with symbol types - this was a common pattern, define one symbol (variable or function) with different types in different source files. Both Chrome and Firefox use LTO for their release builds, as it produces faster and smaller code, specially on those projects that include a lot of libraries internally to avoid shipping DLLs. Have Fun!
  14. Hi! Modern ELF linkers (like LD from binutils/GCC or LLD from CLANG) allows using wildcard in the section specifications, allowing to write one bit object file with one section per function or data object - this allows to filter out individual functions from one object file, reducing the number of source files needed. Currently LD65 does not support this, but it could be added so you could write a linker config like this (simple sample from FastBasic linker config): FEATURES { STARTADDRESS: default = $2000; } SYMBOLS { __STARTADDRESS__: type = export, value = %S; } MEMORY { ZP: file = "", define = yes, start = $0094, size = $0040; MAIN: file = %O, define = yes, start = %S, size = $BC20 - %S; } FILES { %O: format = atari; } FORMATS { atari: runad = start; } SEGMENTS { ZEROPAGE: load = ZP, type = zp, optional = yes; CODE.*: load = MAIN, type = rw, define = yes; DATA.*: load = MAIN, type = rw optional = yes, define = yes; BSS: load = MAIN, type = bss, optional = yes, define = yes; HEAP: load = MAIN, type = bss, optional = yes, define = yes, align = $100; } Now, you could write assembly like this: .secgment "CODE.00001" .proc print_eol .import print_char .export print_eol lda #155 jmp print_char ,endproc .secgment "CODE.00002" .proc print_char .export print_char tay lda ICAX1,X sta ICAX1Z lda ICPTH, x pha lda ICPTL, x pha tya rts ,endproc .secgment "CODE.00003" .proc print_str .import print_char .export print_str ; .......... some code that uses print_char rts ,endproc Now, you need to also implement the option for garbage-collect unused linker sections - this is the most difficult part as you need to only include sections that contains symbols that are referenced, and discard sections that aren't. Hacking LD65 is not that difficult, you could try!. Also, if you are writing a cross-compiler, current PCs are really fast, so this is not really a problem. When compling FastBasic, compiling the C++ parser is ten times slower than compiling the full library 😛 Many compilers (both GCC and CLANG, for example, with the "-flto" option) support link-time-optimizations, and the technology is always the same: instead of compiling to machine language, compile to some intermediate representation. On link time, the liner calls a plugin that is passed all the needed object code, the plugin calls the compiler again passing all the intermediate code as one big chunk. Have Fun!
  15. Hi all! I suspect most early computer algorithms were rediscovered multiple times in the home computers, because we did not had easy access to all the information! About math algorithms, those were known and used from the early history, and binary floating-point algorithms are published from the 1950's. In the 6502 you can find implementation of multiplication and division as old as the Woz 6502 FP math, that uses a lot of tricks to make the code small. About the graphics algorithms, the Atari OS has an implementation of the Bresenham algorithm for line drawing, and the equivalent circle-drawing algorithm was also known, as shown in the article from 1983, were it is called "potential", and a 6502 assembly version is given: https://www.atarimagazines.com/compute/issue38/066_1_CIRCLES.php Have Fun!
  • Create New...