Jump to content

dmsc

Members
  • Content Count

    912
  • Joined

  • Last visited

  • Days Won

    1

Everything posted by dmsc

  1. Hi! Had a little time today - I suspect the error is that you ran it under python-2, but the script is for python-3, just try (for Debian or Ubuntu): sudo apt install python3-simplejson python3-six msitools gcab python3 vsdownload.py --cache $(pwd)/cache/ --dest /opt/vs2019/ I added the "cache" option so the script does not try to download all again if it fails... To install a somewhat smaller set of packages, I tried this: python3 vsdownload.py --dest /opt/vs2019 --skip-recommended --cache $(pwd)/cache/ \ Microsoft.VisualStudio.Workload.VCTools \ Microsoft.VisualStudio.Component.VC.Tools.x86.x64 \ Microsoft.VisualStudio.Component.Windows10SDK.19041 sed -i -e '35,36 s/ arm arm64//' install.sh bash install.sh /opt/vs2019 The above installs over 3GB of data, including multiple compilers (CL and CLANG), on 32 bit and 64 bit x86 hosts, for multiple targets (32 and 64 bits, x86 and ARM), debuggers, .NET, etc. A lot of those could be removed. $ vs2019/bin/x64/cl Microsoft (R) C/C++ Optimizing Compiler Version 19.29.30136 for x64 Copyright (C) Microsoft Corporation. All rights reserved. usage: cl [ option... ] filename... [ /link linkoption... ] Have Fun!
  2. Hi! If you use the XEX output format in the linker, it will automatically write correct headers, but he is using the RAW output format, in which the linker does not know the output format. We already told him to use the XEX output format a while ago, also we told him to read the documentation, and we also told him that he does not need to use a non-standard linker config for using low memory, but he does not listen. In CC65 it is the same if you use the correct linker config, you need to use raw output format to produce an invalid file. Have Fun!
  3. Hi! In fact, Visual Studio command line tools *do* run on Wine, it is the installer and the graphics tools that don't run. You can: - Download a Windows 10 plus Visual Studio VM from Microsoft: https://developer.microsoft.com/en-us/windows/downloads/virtual-machines/ - Mount the image under Linux, and copy the visual studio command line tools - look under "Program Files/Microsoft Visual Studio/2019/BuildTools/" for the binaries and "Program Files/Windows Kits" for the headers and libraries. - Look for the "vcvars.bat" command, it sets the environment variables depending on the target architecture and windows version. Alternatively, just open a command visual-studio command prompt on windows and copy all the variables. A while ago, I managed to compile a chunk of Altirra using VS2017 on Linux, I made the following bash script to run the compiler setting the correct variables: #!/bin/bash # Set to Linux path for the compiler root: LNX_VSPATH='/opt/ms/vs2017' # The same path as seen by wine: VSPATH='Z:\opt\ms\vs2017' VCPATH="$VSPATH\\VC\\14.12.25827" KITPATH="$VSPATH\\Kit\\winv6.3" UCRTPATH="$VSPATH\\Kit\\10.0.10240.0\\ucrt" INCLUDE="$VCPATH\\include;$KITPATH\\include;$UCRTPATH\\include" LIB="$VCPATH\\lib;$KITPATH\\lib;$UCRTPATH\\lib" # Suppresses "0009:err:msvcrt:demangle_datatype Unknown type s" # not needed on all wine versions WINEDLLOVERRIDES=api-ms-win-crt-conio-l1-1-0,ucrtbase=n export INCLUDE export LIB export WINEDLLOVERRIDES exec wine "$LNX_VSPATH/VC/14.12.25827/bin/cl.exe" "[email protected]" Now, you can execute the compiler from the command line: $ vs2017-cl Microsoft (R) C/C++ Optimizing Compiler Version 19.12.25834 for x86 Copyright (C) Microsoft Corporation. All rights reserved. usage: cl [ option... ] filename... [ /link linkoption... ] I copied just what was necessary, about 300MB in total from the 20GB image. Have Fun! EDIT: Also, I just googled this, looks easy to use: https://github.com/mstorsjo/msvc-wine
  4. 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!
  5. Hi! Yes, I'm ok... just very busy with my main job 🙂 Have Fun!
  6. 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!
  7. 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!
  8. 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!
  9. 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!
  10. 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!
  11. 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!
  12. 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!
  13. Hi! Great, so, I now have to add an XORMOVE statement to FastBasic
  14. 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!
  15. 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!
  16. 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!
  17. 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!
  18. 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!
  19. Hi! Be careful! - The array is defined from 0...31, but used from 0 to 63. - The memory area is not cleared, so the program will only work of no other program was loaded first in that memory. Have Fun!
  20. Hi! I have a syntax file for FastBasic and one for Turbo Basic XL. I'm not really happy with the FastBasic one, I tried to make it aware of the lack of spaces but it does not always work, look at line 3: Have Fun! fastbasic.vim tbxl.vim
  21. Hi! Congratulations to @vitoco!! Played 10 lines hero to the end, very good game in ten lines: Also payed Rockfall, very good!!, but level 3 is already too difficult for me! Again, congratulations to all participants, it is great to see so many entries Have Fun!
  22. Hi! Yes, but the routine at $0919 starts a simple "bytecode" interpreter from the PC position, it has a three commands depending on the bits 5 & 6 of each byte: - 00 : JSR to any address from $0000 to $1FFF, - 01 : Moves N bytes inside the buffer at $0D8A, N can be up to $1F bytes. - 10 & 11 : moves N bytes from two arbitrary 16 bit addresses. If bit 7 of the bytecode is 0, another bytecode is executed after this, otherwise it returns to the address following the last bytecode. For example, at $07F2 the code does: L07F2: jsr L0919 ' MOVE $0D17, $02E7, 2 .byte $4D,$17,$42,$E7, ' MOVE $07F0, $000A, 2 .byte $47,$F0,$40,$0A ' MOVE $0DF2, $0CF1, 2 : END .byte $CD,$F2,$4C,$F1 txa L0802: sta L0E4C,x cpx #$97 So, it writes the value at $D17 to MEMLO, the value at $7F0 to DOSVEC and the value at $DF2 to $CF1. Have Fun!
  23. Hi! Well, there are (expensive) alternatives: https://www.sindenlightgun.com/videos/ Have Fun!
  24. Hi! Watching the video, it was not the only weird problem in the setup - other games also did not work. Also, while loading TBXL, the screen got corrupted at the end of the loading - that does not happen in a real Atari. Have Fun!
  25. Hi! I thought that you had source for BW-DOS (or contact with the author), but I see that you are starting from a disassembly. I have a slightly better disassembly done about four years ago, with some of the routines identified: main.asm Changing parts of BW-DOS without original sources is difficult because a lot of the disk access code is written in a bytecode with special move and call instructions. I also have format.asm , verify.asm and xfsio.asm disassembled. Have Fun!
×
×
  • Create New...