Jump to content
IGNORED

dBase III for Atari A8


Ripdubski

Recommended Posts

Atari 8 Bit dBase III Utilities

 

Project Background:

 

This is a project I wanted to do for quite a while. While refreshing my Action! programming skills I wrote the first program in a suite that I plan on writing. The idea is to have a dBase III work-alike for the Atari 8 bit computers. Yes, it won't be as robust as PC version, and there will be limits, but that's not the point. I already know, and don't care, that there are better databases for the Atari. The intent of this project is to support dBase III structures directly and have the files fully compatible with the PC-DOS counterparts - all done in Action!.

 

In this thread I will post updates as I progress through the utilities.

 

 

Planned Utilities:

 

DBF Info - Display information about a DBF file. dBase flavor, structure, number of records, header and record size, and optionally print.

 

DBF Make - Create a DBF file, and optionally a DBT file if there is a memo field. This includes are the pertinent header information and field structure.

 

DBF Query - Browse and query a DBF file. I want to support at least one index as well.

 

DBF Edit - Browse and edit a DBF file. Field data editor.

 

 

Wish List:

 

  • Stand alone executables.
  • Optional printing where applicable.
  • Support at least one index per file.
  • Support at least one relationship to another DBF file.
  • dot Prompt utility (unlikely)

 

 

Updates:

 

I will and have been documenting the progress on my blog http://unfinishedbitness.info/action, and will be posting shorter updates here announcing components, how to use them, and availability. The first two components are complete. The first has a blog entry already, and the second blog entry is being worked on. I realized after the fact that there may be an audience here on AtariAge that is interested.

 

 

In case you read this far and feel the need to question why, then you've missed the point. Any negative comments will simply be ignored.

 

 

  • Like 6
Link to comment
Share on other sites

Utility 1 - DBFInfo

 

Completed.

 

This utility displays the structure of a DBF file It will report which flavor of dBase created it (i.e.: dBase II, FoxPro, dBase IV, etc). The utility will only display information for dBase II, dBase III, and FoxBASE files.

 

You can read the details about it on this blogpost.

 

In addition to downloading the ATR from the blog site, you can download it from here. Complete source is included. Licensing is a bit restrictive, but I will relax it once I complete all the utilities.

 

Usage is simple:

  1. Run the program. If you are in SpartaDOS it will correctly exit back to the command prompt at completion.
  2. Enter the filename (i.e.: D1:FILENAME.DBF)
  3. Answer Y/N to printer output.

 

Results are always displayed to the screen. If you selected Y to printer output, then the same output will be sent to P:.

 

DBFINFO.ATR

Edited by Ripdubski
Link to comment
Share on other sites

Hi Ripdubski. Neat project. Just want to point out though that [$6C $0A $00] is not a JSR $000A, but rather a JMP ($000A). It is correct as a an indirect jump though so no worries.

Oops, you are correct. $6C is a jump. I am not sure why I documented it everywhere as JSR. I'll update the source and blog post.

Link to comment
Share on other sites

Great project! I was a Clipper programmer as well - amazing what could be done with that language!

 

Dot prompt support would be awesome, but I think memory requirements would make it impossible! Many years ago I wrote a dBase III clone (including an interpreter for the language), but that was on the PC.

Link to comment
Share on other sites

Thanks for the comments thus far. I too formerly programmed in Clipper. As much as I would like to implement a dot prompt, I just don't see it happening, or at least not being very useful. Too limited on memory. That will be the last pieces I look at it implementing.

 

I have DBF Make completed but have found a problem with it in regards to memo files. Once I correct it I will post it. On top of the memo error this one is giving me symbol space error when compiling standalone. So two things to fix.

Link to comment
Share on other sites

Can it use Extended RAM?

 

The two parts done so far don't need it. Managing extended memory will be new territory for me, so we'll see. Can Action! do that in a standalone program?

 

At any rate I found another issue with DBF Make when the Action! cart not present, and in resolving it the program now crashes at completion. Debugging now.

Link to comment
Share on other sites

Rip, I'm sure Action can do it. It involves writing to PORTB to flip the 16k at $4000-$8000 around between the banks. A couple of issues arise; the main one is that obviously the code that does the flipping cannot be in that memory range. Usually people will set aside a page flipper function, a buffer, and a memory copier function, and then make sure they are not in the $4000-$8000 range. When the program needs data from the extended, it will call the flipper with an address, it will flip the bank in, copy the memory into the local buffer, and then flip the bank back out and return to the caller. You should probably write your own memory copy and not use any Action! system library calls because they might be in the memory region. It's also possible to copy memory directly around without having a intermediate buffer. The pseudo-code looks like this :

 

bank_copy frombank, tobank, fromaddress, toaddress, length

for length times

flip bank frombank in

a=peek(fromaddress)

flip bank tobank in

poke(toaddress,a)

increment toaddress

increment fromaddress

end for

 

Again, you have to make sure this code is not in the $4000-$8000 range and doesn't call any code that is.

Edited by danwinslow
Link to comment
Share on other sites

I don't think there is much difference between writing your own memory copy routine or using something provided by OSS/ACS as far as what memory location it will be at. The reason I say this is because when you use the runtime or toolkit routines, they get compiled just like the rest of your program or indeed, like your own mem copy routine would. The only two main times I can think of when OSS/ACS routines deal with fixed addresses is when you are relying on the routines in the cartridge (instead of using the runtime), or pseudo routines that are really pointing to routines in the ROM OS (like CIO).

 

In addition, Action! allows you to specify where you wish to begin compilation at, and it allows you to specify for individual routines where they should compile at. Given all that, it should be quite doable. Don't forget also, that it is not too hard to have Action! use machine code that was made with an assembler, but you really shouldn't have to go there.

Link to comment
Share on other sites

This is one of the true joys of the Atari community. Thank you for working to bring more useful applications and utilities to the Atari!

Thank you for making it right!

-The Doct

 

I'm not sure if it will be useful with the technical constraints, memory, number of file handles, disk space, etc. I guess some of it could be. At the very least its a fun learning project. Thnx for the support!

Link to comment
Share on other sites

one thing I have noticed... It may take many years but each time someone picks up the torch and eventually all the things do indeed get fixed enhanced and tinkered with till all the constraints get licked. This group likes to take the impossible and make it reality, or use skill and guile to work around it till it behaves like it should!

  • Like 2
Link to comment
Share on other sites

one thing I have noticed... It may take many years but each time someone picks up the torch and eventually all the things do indeed get fixed enhanced and tinkered with till all the constraints get licked. This group likes to take the impossible and make it reality, or use skill and guile to work around it till it behaves like it should!

 

I would like to see it useful and complete. One thing that will need to be improved is the user interface. Right now they are rudimentary as the utilities are basically just proofs of concept. I'm not even using ATASCII so the code can easily be displayed in a browser.

 

And in other news, I have nearly completed the blog post detailing DBF Make. I should complete it tomorrow night.

Link to comment
Share on other sites

For screen forms, I remember one thing I did a very long time ago. I had gr.0 screens represented by text files. Anything in the file would just be dumped to the screen, up to a delimiter. After the delimiter in the file were some configuration settings for colors and some other stuff...I think the name of the dbf file and the submit routine or something, it's been a long time. In the screen text part, when it was copying it to the screen it looked for special delimiters around text like so :

Hi. Whats your name? [name]

The brackets would tell the system that this was a database field. When it was copied to the screen it would look like

Hi. Whats your name? ______

and the system would drive the input behavior and tabbing around the screen and so forth. It was really handy because I didn't need to write a big program to put up an input screen, it just ran off those little text files.

Link to comment
Share on other sites

Utility 2 - DBFMake

Completed. Documentation took a little longer in the blogpost than I anticipated. In the future I am not going to break down the source in the blog posts. I will instead add those blog comments as additional comments in the source code. This will make posting easier / more efficient for me.

This utility creates the structure for a DBF file, and optionally a DBT file if needed. It will create the files with the dBase III "flavor" signature as opposed to any other xBase offering. I chose to mimic dBase III rather than create a new signature for files created on the A8 since programs elsewhere would likely not recognize a new signature.

It adheres to the dBase III file specifications and limits. The only piece I have not confirmed is the minimal size of the number field thus the constraint is validated to be at least 1. This allows for the incorrect creation of a number field. You can create number field with size of 1 and decimal precision of 4 - bzzt. Thats invalid because the decimal precision is stored as part of the number field itself. If you have size of 1 there is no room for any decimals. At the very least I will make the program adjust the field length to either adjust the size of the number field to be at least as long as the decimal precision; or prevent the decimal precision from exceeding the the size of the number field itself. I left it in limbo until I have the minimum number field size, at which point I will expand the validation.

You can read the details about it on this blogpost.

In addition to downloading the ATR from the blog site, you can download it from this post. Complete source is included. Licensing is a bit restrictive, but I will relax it once I complete all the utilities. DBFMake was simply added to the DBFInfo ATR, but the ATR was named as DBFMake. DOS is not present on the disk image.

Usage is simple:

  1. Run the program. If you are in SpartaDOS it will correctly exit back to the command prompt at completion.
  2. Enter the current date in YYMMDD format. WARNING! Sanitization of input is not present yet. Garbage In = Garbage Out
  3. Enter the desired filename (without extension) (i.e.: D1:FILENAME). WARNING! It does not check if the file exists prior to creating so it can clobber a file if it already exists. It will check in future versions.
  4. Repeat this step for as many fields as you need (up to the dBase III maximum of 128).
    • Enter the field name. Just press RETURN to complete all field entry.
    • Enter the field type by pressing the appropriate letter (C for Char, D for Date, L for Logical, M for Memo, N for Number).
    • Where applicable you then enter the field length and in the case of number you also enter the decimal precision.

As the files are created, a summary is displayed to the screen very similar to that of DBFINFO, along with some key information about the header structure. The DBT file will only be created if there is at least one memo field in the record structure. At this point the file(s) can be transferred to a PC/Mac and manipulated with standard dBase programs.

Note: The interface is crude, but works for what it needs to do. The interface in each utility will be updated later. Right now I'm just concentrating on making things work.

DBFMAKE.ATR

  • Like 2
Link to comment
Share on other sites

  • 7 months later...

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...