dmsc

Hi! Also, from your photo, yo have a Winbond flash device, that seems strange, I tough that all of this boards had ZBIT flash media, it is a lot cheaper than winbond. Perhaps your board does not have the full 16MB? Have Fun!

Hi! And an obvious question, which firmware did you flash in the PICO board? Do you see the PICO virtual disk when plugging into a PC without the boot button pressed? Have Fun!

Hi! To test the A8PicoCart firmware in real hardware, I decided to build one "on the cheap", and ordered two pico boards from Aliexpress at USD 1.80 each. My plan was using one of-the shelf 4x6 prototype PCB that I have, like this: But, I discovered that the rows don't align with the Atari cartridge connector : So I used a very old PCB for an 16KB cart that I had. Sadly, not all pins were present, so I cut and glued some copper pieces to add the missing pins (phi0, R/W, CCTL), and cut the traces connecting RD4 and RD5 to VCC: After this, it was time to solder all the pins to the PICO board, and using some tape to keep all together: It is ugly, but it works! So, IMHO, this is the cheapest multi-cart you can possibly build for the Atari 8-bit. Have Fun!

Hi! The DOS is always loaded, and stays resident - when you hold down OPTION you go straight to the DUP menu, same as typing the DOS command in BASIC. IMHO, you should start trying more and asking less 🙂 Yes, that ATR image, as the name says, has DOS 2.5 in it, and will auto-load the Altirra BASIC at boot. Most software distributed in ATR images will have a DOS to load the software at boot. Have Fun!

Hi! Yes, the editor uses raw text. Redraw is slow because for each line, the editor does: - Calculate the line length (by searching for the next EOL), - Setup DSPFLG and CRSINH to print control characters and hide the cursor - Move cursor to the line position - Print the portion of the line that fits in the screen width - If the line length is more than the screen width, print the portion of the line that fits and a right arrow. - Else, print spaces until the right margin (to erase old characters in the screen) - Restore DSPFLG and CRSINH. Some of the functionality is not needed when you are redrawing the full screen, but the editor uses the same procedure to draw one line, so it must do the full drawing. And yes, in ML and writing directly to the screen it would be faster. Not really 🙂 Copying a byte in 6502 assembly is basically about 16 cycles (using indirect addressing and one byte per iteration). Suppose that you are at the start of a 10K buffer. Then, to insert one byte, you need at least 160000 cycles. As the CPU in graphics 0 runs at about 1.16M cycles per second, this means you can only insert characters at 7 char/second in the best case. This will feel slow. And with a 30k buffer, you are at 2.5 chars/second, very slow. So, by only modifying the current line, the editor feels a lot faster. Thank you! But it is not that difficult, the only tricky part is making it small and memory efficient. As I explained above, the editor processes the keys on input and redraws the whole line on each change. Basically, when you press a key, the editor reads the key, inserts it into the line buffer, and then redraws the line - this ensures that the line is always drawn correctly. The E: device is only used for screen output, not for input. Have Fun!

Hi! Yes, but FastBasic is not fast enough - so a full redraw is slower than the scrolling, you can see in the video a redraw when i do a go-to-line 100. Old versions did redraw on page-up and page-down, but I simplified the code by doing the multiple cursor-up and cursor-down instead. No, I don't store a pointer to each line, only to the lines that are visible in the screen, exactly to avoid the space overhead. When you do a go-to-line, the code searchs the line from the start of the complete buffer. And I'm thinking of also eliminating the array of lines on screen, and simply search backwards and forwards for the next EOL on each cursor-up and cursor-down, to make the code smaller - I have to see if the editor feels slower that way. The slowest part of the editor is adding or removing lines at the start of a big buffer - as you have to move the full buffer memory. This is mitigated in the FastBasic editor as each line is edited in a temporary 256 byte buffer, and it is only inserted in the text when you change the line. This also allows implementing the "UNDO" as simply dropping the modified line buffer - so you can only undo the editing on the last line. Have Fun!

Hi! In the FastBasic editor, the scroll-up and scroll-down are very easy, as they use the E: operations (insert/delete line, printing an $9C or $9D character at top of the screen), the only "slow" part is searching for the start of the previous line, but as most of the lines are short, this is fast enough, see https://github.com/dmsc/fastbasic/blob/master/src/editor.bas#L421 for the code. Also, FastBasic maintains an array with the pointer to the beginning of each line in the screen - this makes the up/down movement inside the the screen a little faster and avoids searching the end of the screen when you delete a line at the middle. FastBasic implementes page-up and page-down as pressing 20 times cursor-up or cursor-down respectively, an depends on those operations being fast enough. Using the EFAST accelerator, I think is confortable for an editing session, here is a little demo of the speed using original hardware (it is faster with Altirra OS replacement ROM): fb-editor.mp4 Have Fun!

Hi! You don't need to "use the E: editor" to read from keyboard and write to the screen. But using the E: device to write to the screen has the advantage of supporting existing 80 column devices; and using the K: device to read from keyboard has the advantage of automatically processing all the keys. The full-screen editor in FastBasic - that also does not use line numbers and support up to 255 characters per line (scrolling the line if necessary) works that way, it reads from K: on input and writes the E: on output, handling all the screen details. A full screen editor - with char/line insert/delete, copy-paste, loading, saving, page-up/down, at less than 1000 basic lines: https://github.com/dmsc/fastbasic/blob/master/src/editor.bas But, as you say, the main limitation of the built-in E: device is the speed, it is very slow. This can be alleviated with a "screen accelerator", but doing all the output directly to the screen from assembly would be faster. In the case of the FastBasic editor, it was written to be as small as posible, and IMHO it is fast enough for typing small to medium size BASIC programs, and as you can compile and run from the editor it is nice that uses very little RAM. Have Fun!

Hi! Yes, currently in FastBasic, sub-strings are not assignable (they are "r-values"), so the second expression is not valid. And the string concatenation is a unary operator, so the second also does not work. One possibility is using string concatenation, but you need a temporary: Q$=T$[14] T$=T$[1,11] T$=+"10" T$=+Q$ The other possibility is to use POKE, but it is ugly: POKE &T$ + 13, ASC("1") POKE &T$ + 14, ASC("0") Or, if you want the fastest version: DPOKE &T$ + 13, $3031 The reason I have not implemented more string functions is that most of the users of FastBasic don't need them - the development has been focused on adding graphics, P/M and DLI capabilities. If you think that implementing more string functions is important, you can create an issue on github, so I can track features for future releases. Have Fun!

Hi! I normally use a chain of IF/ELIF/ELSE/ENDIF: INPUT "Type a number:", A IF A=1 @Proc1 ELIF A=2 @Proc2 ELIF A=10 @OtherProc ELSE ? "none!" ENDIF PROC Proc1 ? "In Proc 1" ENDPROC PROC Proc2 ? "In Proc 2..." ENDPROC PROC OtherProc ? "In Other Proc" ENDPROC A good example is in the FastBasic editor, there is a long IF to process the keys: https://github.com/dmsc/fastbasic/blob/a0ae8ad70e9f9c125a2632e83d9df4d025819fb9/src/editor.bas#L893 Not directly, but you can "cheat" by using a DATA of strings. The problem with this, is that you will use a lot of memory, as each string will use 256 bytes, independent of the length: DATA strData() byte = "HELLO","WORLD","TEST","DATA", DATA byte = "MORE","STRINGS TO TEST" DIM String$(6) A=0 FOR I=0 TO 5 String$(I) = $(ADR(strData) + A) ' Here, we are copying the strings from the DATA to the ARRAY A = A + LEN(String$(I)) + 1 NEXT ? String$(2),String$(0) If you don't need to modify the strings, it is smaller and faster to use an array of pointers to the DATA directly, note the similarity with the above: DATA strData() byte = "HELLO","WORLD","TEST","DATA", DATA byte = "MORE","STRINGS TO TEST" DIM Ptr(6) P=ADR(strData) FOR I=0 TO 5 Ptr(I) = P P = P + LEN($(P)) + 1 NEXT ? $(Ptr(2)), $(Ptr(0)) Have Fun!

Hi! Great. Basically, there are two alternatives: - Copy all your files to a BW-DOS (or Sparta-DOS, as they use the same format) disk, and use BW-DOS for development. I prefer this option, as BW-DOS is smaller and more powerful than MyDOS, I think that it makes a better development environment. - Copy FB.COM (and FBI.COM, FBC.COM and README) to a MyDOS disk, and use MyDOS for development. FastBasic will run without issues in MyDOS. To copy from the SpartaDOS disk format to the MyDOS format, you can use the BW-DOS "MENU" utility. Have Fun!

Hi! I don't normally use immediate mode for debug, I mostly add some PRINT in strategic places 🙂 (or, if in graphics mode, simply setting colors to show a value). I have a proof of concept "integrated debugger" into the IDE (you press "BREAK" and the screen shows the current line number and the value of all variables, allowing to single-step into the code), but I have not worked in it for a while, so I don't promise to release it anytime soon. Have Fun!

Hi! You can use FastBasic, https://github.com/dmsc/fastbasic/releases/ FastBasic has a full IDE in the Atari, runs in any Atari 8-bit computer. No line numbers, supports all the structured basic statements from TBXL, has statements for P/M graphics, DLI, etc. Have Fun!

Hi! It is my github: https://github.com/dmsc/bwdos-mads/blob/main/utils/chkdos.inc I could not test the A8PICO in real hardware because I realized that my raspberry pico was not compatible - so I ordered a couple of "purple" rp20240 boards... After further testing, I will need to add 256 bytes sector support to A8PICO, and better error detection to the driver. And about the Atari800 emulator, I added more A8PicoCart commands in the attached patch, now it also emulates reading directories, searching, ATR and XEX loading. You need to pass a folder to the "-a8pico" command line parameter. Have Fun! atari800-a8pico-2.patch.gz

Hi! Atari BASIC uses a binary file, with the tokenized source. You can use my basic parser at https://github.com/dmsc/tbxl-parser to convert your source file to a BAS file. Remember to use the "-A" option to limit it to Atari BASIC syntax (instead of Turbo Basic XL). Have Fun!

Hi! The code in CheckDOSINI and ResetHandler code has a few problems: - The code resides in $160-$171, limiting the usable stack to $8F bytes, about half of the 256 bytes. Many programs need more stack and will crash the OS. - The code will be called from the ROM OS after setting up the interrupt vectors - so after the OS is swapped with the RAM one, the machine will crash at the first NMI or IRQ. - Any program that sets up DOSINI and then tries to read using indirect addressing from it will not work. I think that with this code, the machine will always crash after pressing RESET. So, IMHO, the code should be completely removed - it only makes the OS less compatible. Have Fun!

Hi! Oh, bummer. I tried it in atari800 emulator using your Altirra OS "softkick" sources, and it worked. So, I added minimal support of A8PicoCart to Atari800 emulator, and found the problem - the included OS replacement rewrites DOSINI during the VBI, this means that you can't install loadable drivers into any DOS, as those depend on chaining the DOSINI on reboot. I think that disabling this DOSINI rewriting is the best course of action, as it is not really needed for most of the use case of the softkick OS. Attached is my patch to current atari800 git. I used the ROM from the headers from your A8PicoCart sources. Have Fun! atari800-a8pico.patch.gz

Hi! The Atari Kernel, inside your computer, only knows howto load/save files to tapes, using the "C:" driver. Any other medium (hard disks, floppy disks, etc.) needs a resident program that organizes the data inside to build files and directories. So, you need a "DOS" to actually use your SDrive or any other "drive emulator" from BASIC, the DOS will create a "D:" device that access files on your disk (real or emulated). As BW-DOS size is a little less than 6kB, this is the amount of memory you will loose by using it, so your 16K Atari will be a 10K Atari..... and this will not be enough even for a GR.8 screen, so you will be very limited to which programs you can run. I will see this as a temporary situation while you wait to perform the memory expansion that you *really* need. I recommend you practice a little with any emulator to familiarize yourself with the setup. You can configure Altirra to emulate your 600XL and boot the ATR that I posted before, and go from there. No, BCALC will not run, as it will not have enough memory. You will need the memory if you really want to run the majority of software available for your computer. No. As mentioned above, the Atari OS does not know about "files", so it does not have any means to save to any device except tape. Have Fun!

Hi! That is great, thank you for testing!! It means that the A8PICO driver actually works (at least for read operations), but when swapping the Altirra OS with the original ROM, it hangs. This is because the interrupt handlers have different initialization values, so at the first IRQ or NMI the kernel hangs. To solve this, we need to perform a warm-start after swapping the kernel. Attached is a new image, with a new program "ROM.COM" that performs the swap, you need to boot the image and answer "Y" to both, load the A8PICO driver and swap the ROM kernel in. After this, the computer resets and you can type "TB" to load tb-xl. Please, if @ascrnet or you can test this, I hope this time will work 🙂 , and I can include the A8PICO driver in my BW-DOS branch. Have Fun! bwdos-a8pico-v2.zip

Hi! So, I will need to build an A8PICO to test myself 🙂 .... debugging on emulators is so much easier. Yes, I understand. So, the ATR that I posted should work, the procedure is: - Boot with the ATR using A8PICO, it will use the replacement RAM OS and load the driver as "D8". - You can test A8PICO driver by accessing D8:, for example "DIR D8:" should give the directory. - Now type " A8PICO 1 " to replace the standard SIO D1 with the D1 through the A8PICO driver. - Type " TB " to load TurboBasic, after initial loading, it will swap the ROM OS back on, and continue from there. This will work given that the Altirra based OS replacement is "mostly compatible" at the RAM level with the original ROM, I think this is ok. You can now LOAD and SAVE to "D1:" using the driver, so it will behave in the correct way. As explained, it can be swapped on A8PICO driver load (you can edit the STARTUP.BAT file and change from 8 to 1) Have Fun!

Hi! I strongly recommend using BW-DOS, as it is small and does not need the resident menu (DUP), so it will work better with little memory. Attached is my current devel version, at load it gives you 7554 bytes of free memory, or 7.2k from basic. Have Fun! bwdos.atr

Hi! As TB-XL really needs a DOS, won't be easier to simply load a DOS supporting the UNO/A8Pico SIO emulation? The attached proof of concept image is an 1MB ATR with BW-DOS (my current devel version) that loads an untested driver for the A8PICO, allowing to read/write from the mounted ATR image. The ATR also includes TurboBasic XL. The MADS sources of the driver (that should work in BW-DOS and SpartaDOS 2 and 3) is attached here: a8pico.src How can I test this in an emulator? Have Fun! bwdos-a8pico.zip print1.inc print.inc

Hi! The code posted by phaeron does go up to 255, and jumps to "overflow" if the result is 256 or bigger. You need to call it multiple times until there are no more digits. Have Fun!

Hi! What I don't understand is... why do you want the data as part of the program??? Normally, it is more efficient to store your data in a different file, that you can load and append, specially if you have a disk drive: 10 DIM N$(100) : R=1 15 REM OPEN FILE FOR APPEND 20 TRAP 70 : OPEN #1,9,0,"D:LIST.DAT" 30 ? "Input NUMBER , NAME, press RETURN to end:" 40 TRAP 80 : ? "Record "; R;: INPUT NUM,N$ 50 TRAP 70 : PRINT #1, NUM; "," ; N$ 60 R=R+1 : GOTO 40 65 REM ERROR ON WRITE 70 ? "ERROR WRITING FILE:"; PEEK(195) : CLOSE #1 : END 75 REM END OF INPUT, CLOSE FILE 80 TRAP 70: CLOSE #1 85 REM READ DATA BACK 90 TRAP 130: R=1 : OPEN #1,4,0,"D:LIST.DAT" 100 TRAP 140: INPUT #1,NUM,N$ 110 ? "Record "; R; ": "; N$ , NUM 120 R=R+1 : GOTO 100 125 REM ERROR ON READ 130 ? "ERROR READING FILE:"; PEEK(195) : CLOSE #1 : END 135 REM ALL OK 140 ? "ALL OK" : CLOSE #1 : END The above program will allow you to enter numbers and names, stores them to disk, and then lists all the names again. Using "C:" for the cassette is more difficult, as you can't append to a file, but you can save and load a list in the same way. Have Fun!

Hi! Yes, of course, but I was thinking on using SIO2PC to load games or load/save little BASIC programs. Also, with LiteDOS you will have 10800 bytes free in BASIC, enough to test a lot of (simpler) programs. Have Fun!