dmsc

Hi! No, the BAS file that we got has the variable-name-table cleared to all EOL ($9B), so it is not possible to recall the original names, only that there are 118 variables. This was a common "protection" trick BITD, as this makes the program harder to understand. Also, the program has an invalid last statement, this means that after a LOAD, Atari BASIC hangs - you can only RUN it directly. Have Fun!

Hi @newTIboyRob! About the long lines, those are because the program that you typed is not the "original" one, it is recovered from a version that was protected, with all the variable names erased. So, to un-protect it, the variables were replaced by V1 to V99, making some of the names bigger. IMHO, that Basic spreadsheet program is not a good program to type in, it is big and slow, and not a very good learning experience 🙂 Here is a better option: I ported B-CALC to work in 16K memory and load from a cassette, attached is the .CAS file and a binary image. You can test the .CAS file in an emulator and see it works - it would give you about 3k of free memory for your spreadsheet, see: What I did was to assemble the code from the magazine to address $700 instead of $2000, and skipped the test for "D" device on SAVE and LOAD, so it works with "C:". Then, I compressed it to make loading shorter and converted to a bootable CAS file. The magazine article with the instructions is here: https://archive.org/details/analog-computing-magazine-63/page/n50/mode/2up Sadly, the program is too large to convert to a BASIC tipe-in in 16K, as you would need the BASIC source plus the decoded binary in memory at the same time, and this is more than 16K for a 6k program like this. It would need to be typed in different sections and then appended together, a very difficult task without some disk drive. And a simple recommendation - if you need some very inexpensive device to connect to your Atari, you can build a SIO2PC-USB using an usb to serial adapter, like this: https://www.aliexpress.com/item/32273550144.html ... you will start to enjoy your Atari 🙂, like this: Have Fun! bcalc-cassete.cas bcalc-cassete.bin

Hi! This is easy to do with CA65/LD65 and a custom linker script: you need to define memory areas for each 1k block, and then add (at least) two segments to each memory area, one with the font and another one with the code. MEMORY { ZP: file = "", define = yes, start = $0082, size = $007E; FONT1: file = %O, define = yes, start = $2000, size = $400; FONT2: file = %O, define = yes, start = $2400, size = $400; FONT3: file = %O, define = yes, start = $2800, size = $400; FONT4: file = %O, define = yes, start = $2C00, size = $400; FONT5: file = %O, define = yes, start = $3000, size = $400; FONT6: file = %O, define = yes, start = $3400, size = $400; FONT7: file = %O, define = yes, start = $3800, size = $400; FONT8: file = %O, define = yes, start = $3C00, size = $400; MAIN: file = %O, define = yes, start = $4000, size = $4000; } FILES { %O: format = atari; } FORMATS { atari: runad = start; } SEGMENTS { ZEROPAGE: load = ZP, type = zp; FONT1: load = FONT1, type = ro, define = yes; FONT2: load = FONT2, type = ro, define = yes; FONT3: load = FONT3, type = ro, define = yes; FONT4: load = FONT4, type = ro, define = yes; FONT5: load = FONT5, type = ro, define = yes; FONT6: load = FONT6, type = ro, define = yes; FONT7: load = FONT7, type = ro, define = yes; FONT8: load = FONT8, type = ro, define = yes; CODE: load = MAIN, type = ro; CODE1: load = FONT1, type = ro; CODE2: load = FONT2, type = ro; CODE3: load = FONT3, type = ro; CODE4: load = FONT4, type = ro; CODE5: load = FONT5, type = ro; CODE6: load = FONT6, type = ro; CODE7: load = FONT7, type = ro; CODE8: load = FONT8, type = ro; DATA: load = MAIN, type = rw; } You then need to assign different procedures / tables to different segments CODE, CODE1, CODE2, etc., like this: .segment "FONT1" .byte 1,2,3,4,..... .segment "FONT2" .byte 1,2,3,4,..... .segment "FONT3" .byte 1,2,3,4,..... .segment "CODE1" .proc my_proc ; .... .endproc .segment "CODE2" .proc my_table .byte 1,2,3,4,.... .endproc .segment "CODE1" .proc other_proc ; .... .endproc ;... and so on... Note that the order does not matter, as the linker script specify that the "FONT" segments are at the start of each memory section. What LD65 does not (yet) support is writing a segment to more than one memory area, you need to specify on which area each segment is written and then assign a segment manually to each procedure, but IMHO, this would not be difficult to implement. I would like a syntax similar to the GNU LD linker, where you can specify segments with a pattern (like, "code.*"), and then each procedure can be written to a different segment and sorted accordingly. Have Fun!

HI! Yes, I discovered it while modifying the resident programs - I solved it by simply limiting the search for the installed program to an address higher than the disk buffers, but this is not a great solution, as different DOS could have the disk buffers in other places. Problem with the XOR is that assembling the programs is more difficult, needing an extra step. I keept this copying exactly for this reason - it is very useful to be able to load the DOS from another DOS. In my fork, I optimized the commands a little, and I also think that having BASIC and CAR as resident commands is important. In my fork, MEMLO is already 3 bytes less than in the 1.3 version, this with the added "MAN" command that Janz implemented. I don't find the labels that hard to understand - in fact they are a lot better than the tipical "L***" labels in disassembled sources 😛 Thank you again for releasing it back in the day, and releasing the source now. I have only one request - can you clarify the license of the released sources? Have Fun!

Hi @Jiří Bernášek, nice to hear from you!! It is great to learn about your reasoning on the update of the file/dir allocation pointers, it certainly makes a lot of sense for the standard disks back in the day. I think that today, most people uses flash based storage - with no seek times - so a simpler strategy (like the one Janz implemented) is better, as it is faster and a little smaller code-wise. I also have a fork of BW-DOS in my github, over at https://github.com/dmsc/bwdos-mads , I'm optimizing all the resident programs and utilities to minimize the RAM usage: - All the "low memory" utilities fit bellow $600 now, so you can use them to load and examine the page-6. - Many simpler utilities are at least one sector smaller, so they load faster. I see BW-DOS as the DOS of choice when generating new ATR images, as it is free and extremely capable, thank you very much for releasing it! Have Fun!

Hi! I think you still don't get what what Pirx is saying: Atari BASIC is your spreadsheet. BASIC is older than spreadsheets, and is more powerful - if somewhat more difficult to use. Suppose you want to add two list of numbers. Simply, write those as DATA: 100 DATA 123, 456, 789, 100, 200, 300 200 DATA 654, 321, 987, 10, 20, 30 Now, you write your "formula": 10 NUM = 6 : DIM A(NUM) 20 RESTORE 100 30 FOR I=1 TO NUM: READ X: A(I) = X : NEXT I 40 RESTORE 200 50 FOR I=1 TO NUM: READ X: A(I) = A(I) + X : NEXT I 60 FOR I=1 TO NUM: PRINT A(I), : NEXT I 70 STOP Now, you save tour program with "CSAVE", and load with "CLOAD". And to change which numbers to add, simply edit the "DATA" lines. BASIC is really meant to be used this way in this early computers. Have Fun!

Hi! Great tool! I have a similar utility, "mkatr" and "lsatr", that implement creating, listing and extracting ATR images in Sparta DOS format: https://github.com/dmsc/mkatr The tools also supports directories, time stamps and attributes on creating/extracting. Have Fun!

Hi! Thanks for your FastBasic examples! The problem is in your assembly, at line 18: https://github.com/markjfisher/fb-args/blob/master/example/getargs-sdx.asm#L18 .zeropage ptr1: .res 1 Here, you reserved 1 byte of zeropage to store your "ptr1" variable.... but then, at line 46: sparta: lda DOSVEC clc adc #<LBUF sta ptr1 lda DOSVEC+1 adc #>LBUF sta ptr1+1 You are writing to "ptr1+1", so you used two bytes. This overwrites one FastBasic pointer, messing up the code later. The fix is simply to reserve 2 bytes for ptr1. Have Fun!

Hi! This is not about FastBasic, more about 6502 assembly 🙂 ... yes, accessing results from depth in the stack is not that easy. But, there is an alternative to pop and push, use TSX to transfer the stack pointer to the X register and access from there: .export GEN2 .proc GEN2 start: ; Get stack pointer int X: tsx ; Read original parameter 2: lda $103,x sta _p2+1 lda $104,x sta _p2 ; Increment inc _p2 bne no1 inc _p2+1 no1: ; Store parameter 2: lda _p2+1 sta $103,x lda _p2 sta $104,x ; Or do the same in place for parameter 1 inc $105,x bne no2 inc $106,x no2: ; Return rts ; temporary data _p2: .res 2 .endproc About the ".export" and ".proc", those are specific to CA65 assembler. In your first example, you were trying to access "GEN2::start" from outside, but that does not work because ".export" only exports the given symbol, all other local symbols are hidden from the file. Have Fun!

Hi! Yes, but I doubt the caller will change Have Fun!

Hi! Note really. He is using my patched version of TBXL, that relocates itself based on MEMLO, but only on page boundaries. And after loading the ramdisk driver, TBXL had 256 bytes less of memory available. TBXL does not use extended memory, so FRE(8) is the same as FRE(0). Have Fun!

Hi! IMHO, as different people will have different tastes for the optimal LMARGIN value, two versions could be provided. Or perhaps a little "config" utility to configure some default settings. Yes, it is not really useful, but it also does not waste any memory (as it is in the initialization section), only a little disk space. I will probably remove it also from my version. This is also an option that will differ between users.... IMHO, a configuration utility could ask: - Default LMARGIN: (left unchanged, set to 0, 1 or 2) - Default boot action: (run cartridge / run CP) - Default back color: (unchanged, black, other) Perhaps also key repeat / key delay ? Have Fun!

Hi! I finished merging your changes to the original sources, each in one commit: - Make banner text unprotected. - Move COMTAB to absolute address $726. - Rename commands to modern names. - Improve performance of sector allocation for overwrite cases. - Adds MAN command, same as TYPE. - Optimization to GETSTK procedure by flashjazzcat. - Simplify BASIC ON/OFF logic and sync with VBLANK. I'm undecided to merge the next changes: - Set left margin to 0 when loading the CP. - Don´t clean memory at start - original clears from MEMLO to MEMTOP. Why this change? - Don´t run cartridge if startup.bat is not found. Also, the code is 4 bytes smaller because I left the original optimization with "EOR" instead of BIT + LDA skip. Perhaps you could re-introduce those? OTOH, I also optimized the MENU a little, I remove the jump tables between the three parts of the menu so it is 162 bytes smaller. The sources are at: https://github.com/dmsc/bwdos-mads , assemble and build the image with "make", attached is the resulting ATR image. Have Fun! bwdos.atr

Hi! Ha ha, no problem 🙂 Have Fun!

Hi! I meant tags, but forgot to push them 😛 . Now the tags are there: https://github.com/dmsc/bwdos-original/tags I'm planning to upload the binary releases on github for each tag. Have Fun!

Hi! Mmmm.... what sources? Have Fun!

Hi! So, I completed the conversion, and included a Makefile to easily recreate all the files in the original disk of BW-DOS 1.3: https://github.com/dmsc/bwdos-mads I included a little C program that recreates the "protection" in some of the original programs, this is simply EOR of the code with the constant $55 that was performed after assembly in the original sources. From the README over github: Description of the files DOS Sources, those are assembled using the ASM file that includes all the parts: dos/bwdos.asm dos/bwdosa.src dos/bwdosb.src dos/bwdosc.src dos/bwmac.src dos/comtab.src Standard tools, those are assembled directly: utils/bload.src utils/boot.src utils/chkdsk.src utils/chvol.src utils/copy.src utils/cut.src utils/date.src utils/dirmast.src utils/disass.src utils/dump.src utils/else.src utils/endif.src utils/format.src utils/hexedit.src utils/if.src utils/mdump.src utils/mem.src utils/memedit.src utils/move.src utils/msdos.src utils/msini.src utils/newed.src utils/offload.src utils/pause.src utils/save.src utils/time.src utils/unerase.src utils/verify.src utils/xbat.src The following utilities are multi-part sources, and must be assembled with the stub that includes all parts: utils/backup.asm utils/bk_a.src utils/bk_b.src utils/menu.asm utils/menu_a.src utils/menu_b.src utils/menu_c.src And the following utilities were "protected" in the original distribution by exclusive-or-ing the program in the file with the constant $55. After assembling those, there is a little C program that generates the protected binary from the unprotected one: utils/argsprn.src utils/argsrtc.src utils/autocwd.src utils/clock.src utils/dosdrive.src utils/keybuff.src utils/rambox.src utils/ramdisk.src utils/rtime8.src utils/xfsio.src utils/xlrdisk.src From here, I would like to include all the changes that @janzh made in his 1.4 version to have an "universal" source, and then remove the "protection" to produce smaller binaries. Have Fun!

Hi! I created two repos on github: - https://github.com/dmsc/bwdos-original : This is the repo with the original sources, one tag for each version. The only modification to the sources is the conversion of the line endings from orignal "CR" line endings to modern "LF" ones. This allows the github interface to show the diffs from each version. For example, you can see that the changes from 1.0 to 1.1 are minimal: https://github.com/dmsc/bwdos-original/commit/8fa47d61c1c04797ee2b79d0afbcacb434d5f46e - https://github.com/dmsc/bwdos-mads : This repo is my work in progress to convert the sources to MADS syntax. I already converted the DOS (split in four files) and half of the utilities. See the README for details. Have Fun!

Hi! I have those tools in my path always 🙂 But for Sparta DOS filesystems, you can use mkatr (for creating ATR images) and lsatr (for listing and extracting from ATR) from here: https://github.com/dmsc/mkatr Have Fun!

Hi! Attached is the "extracted" sources, I used my mkatr tool and zip, this preserves the file and folder dates: mkdir bwdos-original-sources lsatr 'BW-DOS 1.30 Sources.atr' -l -X bwdos-original-sources/ zip -9r bwdos-original-sources.zip bwdos-original-sources/ I'm preparing a repo with the source history - just give about a week to finish it. The original source includes code to patch the assembled binaries to fix limitations of the ATMAS assembler, as it does not have an "EXOR" operator for it´s expressions. So, if you assemble with xatmas2, you have to manually patch the resulting binary. IMHO, it would be easier to simply convert the sources to be able to assemble with MADS. So, my plan is to have a repo with a commit for each new version, and then a commit with the adaptation to MADS. The other advantage of loading at $3000 is that you can load a DOS from another, to replace the running one. This allows you to load different versions of BW-DOS as needed. Have Fun! bwdos-original-sources.zip

Hi! I was able to assemble the original sources using XATMAS2, from https://github.com/ivop/xatmas2 , after some fixes to the cross-assembler (available in a pull-request). The sources were split (to allow editing on the Atari) using fixes labels, it was probably a lot of work to edit one file, assemble, lookup the labels and update the rest of the sources by hand... probably it would be better now to simply concatenate the sources in one big file. @janzh, do you plan on updating your disassembled sources with the labels from the original sources? Have Fun!

Hi! I see, now you set the last alloc sector number to the first sector deleted, before it was set to 1/16 of the total number of sectors. Don´t see how the previous logic made sense, the new logic is a lot better. But, I think that it would be worth testing a different logic: simply keep the last-alloc sector unchanged on file deletion. That would mean that new files will always be appended on disk, up until the disk is full, where the allocation would start at the beginning again. This would make sense when the disk is big and the usage is low. Have Fun!

Hi! The problem is that you are showing a pattern: - You ask the forum for help - so, you are making us work for you. - You ignore some of the advice, saying you don´t need the advice anymore. (i.e., "I moved on to other" BASIC/DOS/etc.) - You ask for help again. - Etc. This kind of behavior makes other people fell abused - because you make it feel that helping you was a waste of other people time. Have Fun!

Hi! You can also test a modified version by @janzh, named "BW-DOS 1.4", available on github https://github.com/HolgerJanz/BW-DOS: He modified the commands to be more "modern", this is the new command list: Original (BW-DOS 1.3) New (BW-DOS 1.4) RENAME REN ERASE DEL PROTECT PROT UNPROTECT UNPROT CREDIR MD DELDIR RD CWD CD LOAD LOAD CAR CAR RUN RUN PRINT PRINT TYPE TYPE DIR DIR DIRS DIRS BASIC BASIC Also, added a "MAN" command that shows help for any internal/external command. Have Fun!

Hi! Those artifacts are normal, and caused by the program not clearing the P/M registers, and the OS ROM does not clears them either on graphics change. This is how Atari BASIC, Turbo Basic XL and other interpreters at the time worked. Just press RESET, it is what anybody did in the old days 🙂 The FastBasic IDE also clears the P/M registers on GR.0 or when returning to the IDE, but does not clear on program termination - I did this because some programs actually want to keep the P/M graphics after end. Have Fun!