 Notice. New forum software under development. It's going to miss a few functions and look a bit ugly for a while, but I'm working on it full time now as the old forum was too unstable. Couple days, all good. If you notice any issues, please contact me. |
Forum Index : Microcontroller and PC projects : Any chance to get the MSDOS version of MMBasic updated?
| Author | Message | ||||
| Friet Newbie  Joined: 16/12/2020 Location: BelgiumPosts: 13 |
Hi, I'm trying to do some prototyping using the DOS/WINDOWS veriosn of MMBasic, but i stumble on a lot of limitations/differences versus the current version on the CMM2. (i've started on a library to read/write DBF files..as someone was suggesting that in one of the topics) They are not related to graphics nor special devices ; just 'standard' functions and commands that are not (yet) implemented in the DOS version. ( a lot of the MM.INFO stuff , OPTION stuff, functions like BIN2STR, STR2BIN, etc) Current DOS version is still 5.05.03 and in the meantime MMBasic on the CCM2 has evolved to fast that the differences are becoming too big. (on myCCM2 i now have 5.06.00 ; with 5.07.00 close on the horizon if i'm not mistaken) Any chance we could see an update on the DOS version coming some time? Thanks in advance, Regards, Frank |
||||
Geoffg Guru  Joined: 06/06/2011 Location: AustraliaPosts: 3308 |
The Windows version of MMBasic is based on the Micromite version and is fully up to date (both are at V5.05.03). The CMM2 version was developed by Peter Mather who took MMBasic V5.05.03 for the Micromite and added a HUGE amount of extra commands, functions, etc. The result is that the CMM2 has developed its own trajectory which, in some ways, is quite different from the original Micromite version. There is not much difference in the core BASIC language between the Windows and CMM2 versions but what you are essentially asking for is the extra features of the CMM2 version. I'm not sure about this. The Windows version was not intended to be a an alternate Micromite development platform and the same argument applies to the CMM2 - there are too many physical differences (I/O pins, graphics, etc) for that to work. I guess that the features that you listed (MM.INFO, BIN2STR, STR2BIN, etc) could be implemented but I am wary of cluttering a clean implementation of BASIC. However, regardless, some features could be migrated from the CMM2 and I will have a good look at that possibility for the next Micromite/Windows version. But, sorry, it will still not provide a good emulation of the CMM2. Geoff Geoff Graham - http://geoffg.net |
||||
| Paul_L Guru Joined: 03/03/2016 Location: United StatesPosts: 769 |
Hi Frank. That was me. I always liked dBase. I worked on the Summer 87 re-incarnation of the Clipper executable. It was a shame that Computer Associates killed Clipper and then Microsoft killed FoxPro. Vulcan and its progeny dBase were incredibly popular because they filled a specific requirement -- a standalone programmable relational database program. Lizby and I thought that it would be a valuable addition to the CMM2. We started working on a Vulcan replacement but there didn't appear to be much interest, so we stopped beating a dead horse. Lance and I would be glad to work on an implementation with you if you feel so inclined, but it would be a big project. I believe that it could be implemented in the DOS version of MMbasic using functions to emulate the copying of disk records back and forth to arrays in RAM memory. The actual programmatic processing of the individual records should be accomplished in RAM. It would require a conceptual change to think of volatile variables in RAM mirroring persistent variables on disk. I disagree with the way Wayne Ratliff defined the header of his Vulcan data file. It is too fragile and susceptible to damage. Storing the definition of a record in separate redundant files would be much more reliable but the program would not be able to read a dbf file. (Dbf files can be easily read using Excel or Libre Office Calc and then written back to csv files so older data would not be trapped in dbf files.) Please let me know how far you have gotten with your file handling library. Paul in NY Edited 2021-06-05 15:59 by Paul_L |
||||
| lizby Guru Joined: 17/05/2016 Location: United StatesPosts: 3478 |
This is still on my to-do list, but keeps being bumped down by more enticing developments on the CMM2, F4, and now PicoMite. None of this is approved (or disapproved) by Paul, but I have working a database format file, indexing, multi-megabyte text data files, and limited SQL searching and reporting. I'm using DOS MMBasic, but with the intention that it would work with any SD-enabled MMBasic. I reached the point in SQL development where a debugger would have been useful, and that is now functional (in C, with very minimal additions to the DOS MMBasic source)--but that also got bumped short of completion by new developments elsewhere in the 'mite world. If you wish to share efforts, I would be happy to join in. Lance PicoMite, Armmite F4, SensorKits, MMBasic Hardware, Games, etc. on fruitoftheshed |
||||
| Friet Newbie Joined: 16/12/2020 Location: BelgiumPosts: 13 |
So far still working out what and how i need to store/represent each field in the header. Have the file type, date, number of records, start of the dataset worked out. Next is the record length, and then the actual record definitions. Two fields i'm currently not (yet) touching are the Table flag (CDX, Memo, CDC) and the code page mark. Need to figure out how to deal with memo fields.. i know it is a separat file, but it is my understanding that different versions (dBase vs FoxPro vs Clipper) handle this differently. It goes quite slow as it's been almost 30years since i've done any real programming and at the same time i use this to actually learn the ins and outs of MMBasic. Once i get far enough i'll switch to the native CMM2 as it does have a lot more power (language wise) than the DOS version. @Geoff as well : no worries if the DOS version is not high on the list.. makes it more challenging and that is also not such a bad thing.  Regards, Frank |
||||
| Paul_L Guru Joined: 03/03/2016 Location: United StatesPosts: 769 |
Hi Frank, To reiterate, I never liked Wayne Ratliff's implementation of the DBF header. It is fragile! Only a single record of the data structure of a record, its fields and indexes exists at the head of this possibly enormous data file. This structure header would necessarily be of variable length, depending on the structure of the individual record and the indexes. This variability in length of the header makes it difficult to determine the file offset to the beginning of the actual data. It probably would be more reliable to depend on the well tested routines which establish the FAT to find the data structure definition in one file and the actual data in another file. It would also be a good idea to be able to compare the record structure in multiple structure files for verification of the data structure. When you open a database you would load the structure definition into a newly declared structure array for rapid access. The structure definition might as well be in its own structure file which would be closed after declaring and filling the structure array. Then a second copy of the structure file would be opened, compared to the contents of the structure definition array and closed. Then the structure definition array data would be used to declare the buffer arrays which would receive and parse one record of the actual data. Then, finally, the data table file itself would be opened and the first record would be read into the data buffer and a pointer would be set to the file offset of the start of record one. The array that holds the structure definition would be used as a pointer to the array locations of the data buffer array variables which would be manipulated programmatically. You would commit / write a changed record back to the file when the file pointer changes, when a commit command is issued or when the table is closed. (SQL does all of this behind the scenes. The current crop of database programmers don't even give it a thought. It's only us geezers who remember writing the procedural code used to build a database and manipulate it's data.) ((Are you aware that the old timers at IBM used to pronounce SQL as SQUEAL"?? I'm older than dirt.)) The CMM2 would be usable as a database server only if an external physical disk could be depended upon to maintain the data when the power is off. The DOS version of MMbasic would be ideal for working the bugs out of the disk data manipulation back end. The DOS character based display would be ideal for displaying data records. The CMM2 display would be a little more awkward for this type of character display. Paul in NY |
||||
 Print this page |
 |
The Back Shed's forum code is written, and hosted, in Australia. | © JAQ Software 2025 |
