Jump to content

Photo

dBase III for Atari A8

Action! dBase

23 replies to this topic

#1 Ripdubski OFFLINE  

Ripdubski

    Stargunner

  • 1,306 posts

Posted Sat Aug 29, 2015 4:56 PM

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.

 

 



#2 Ripdubski OFFLINE  

Ripdubski

    Stargunner

  • Topic Starter
  • 1,306 posts

Posted Sat Aug 29, 2015 5:04 PM

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:.

 

Attached File  DBFINFO.ATR   90.02KB   77 downloads


Edited by Ripdubski, Sat Aug 29, 2015 5:06 PM.


#3 fujidude OFFLINE  

fujidude

    Quadrunner

  • 5,217 posts
  • Location:United States of America

Posted Sat Aug 29, 2015 7:18 PM

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.



#4 Ripdubski OFFLINE  

Ripdubski

    Stargunner

  • Topic Starter
  • 1,306 posts

Posted Sat Aug 29, 2015 8:06 PM

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.



#5 slx OFFLINE  

slx

    Stargunner

  • 1,751 posts
  • Location:Vienna, Austria

Posted Sun Aug 30, 2015 9:15 AM

Great idea! Good luck! (DBase was the only programming I ever did for money.)


Gesendet von meinem iPhone mit Tapatalk

#6 danwinslow OFFLINE  

danwinslow

    River Patroller

  • 2,574 posts

Posted Sun Aug 30, 2015 11:41 AM

Very cool, this has been in the back of my mind for a while as a project. I was a Clipper programmer way back in the day.



#7 jacobus OFFLINE  

jacobus

    Dragonstomper

  • 699 posts
  • Location:Canada

Posted Sun Aug 30, 2015 2:28 PM

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.



#8 Ripdubski OFFLINE  

Ripdubski

    Stargunner

  • Topic Starter
  • 1,306 posts

Posted Sun Aug 30, 2015 6:36 PM

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.



#9 Ripdubski OFFLINE  

Ripdubski

    Stargunner

  • Topic Starter
  • 1,306 posts

Posted Sun Aug 30, 2015 8:25 PM

Both issues with DBF Make now resolved.  I've moved DBF/DBT files created on the A8 to PC and successfully updated them.  I should have it documented in the next day or so.



#10 Kyle22 OFFLINE  

Kyle22

    River Patroller

  • 3,899 posts
  • Call my BBS! telnet://broadway1.lorexddns.net
  • Location:McKees Rocks (Pittsburgh), PA

Posted Mon Aug 31, 2015 11:31 AM

Can it use Extended RAM?



#11 Ripdubski OFFLINE  

Ripdubski

    Stargunner

  • Topic Starter
  • 1,306 posts

Posted Mon Aug 31, 2015 8:23 PM

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.



#12 danwinslow OFFLINE  

danwinslow

    River Patroller

  • 2,574 posts

Posted Tue Sep 1, 2015 7:29 AM

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, Tue Sep 1, 2015 7:30 AM.


#13 fujidude OFFLINE  

fujidude

    Quadrunner

  • 5,217 posts
  • Location:United States of America

Posted Tue Sep 1, 2015 10:48 AM

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.



#14 danwinslow OFFLINE  

danwinslow

    River Patroller

  • 2,574 posts

Posted Tue Sep 1, 2015 4:17 PM

Yes, the main point was that you need to make sure it is not in the window and nothing that it calls is in the window. If you can do that without writing custom stuff, all the better.



#15 Ripdubski OFFLINE  

Ripdubski

    Stargunner

  • Topic Starter
  • 1,306 posts

Posted Tue Sep 1, 2015 8:05 PM

Awesome, thanks for the tips!

 

I have corrected the crashing on completion issue with DBF Make.  I'm in the process of writing about it and should have it done by tomorrow or the next night.  Then I'll start work on one of the next utilities.



#16 _The Doctor__ OFFLINE  

_The Doctor__

    Flux Capacitor Master Craftsman

  • 6,553 posts
  • Location:10-0-11-00:02

Posted Tue Sep 1, 2015 9:56 PM

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



#17 bf2k+ OFFLINE  

bf2k+

    Stargunner

  • 1,773 posts
  • Location:Boot Factory BBS 2k+

Posted Wed Sep 2, 2015 4:08 AM

Ditto to Clipper programming... loved it!



#18 Ripdubski OFFLINE  

Ripdubski

    Stargunner

  • Topic Starter
  • 1,306 posts

Posted Wed Sep 2, 2015 5:19 PM

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!



#19 _The Doctor__ OFFLINE  

_The Doctor__

    Flux Capacitor Master Craftsman

  • 6,553 posts
  • Location:10-0-11-00:02

Posted Wed Sep 2, 2015 5:49 PM

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!



#20 Ripdubski OFFLINE  

Ripdubski

    Stargunner

  • Topic Starter
  • 1,306 posts

Posted Wed Sep 2, 2015 7:28 PM

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.



#21 danwinslow OFFLINE  

danwinslow

    River Patroller

  • 2,574 posts

Posted Thu Sep 3, 2015 7:12 AM

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.



#22 Ripdubski OFFLINE  

Ripdubski

    Stargunner

  • Topic Starter
  • 1,306 posts

Posted Thu Sep 3, 2015 7:16 AM

Interesting.  Food for thought...  Got a ways to go before I cross the prettification bridge.  Thnx!



#23 Ripdubski OFFLINE  

Ripdubski

    Stargunner

  • Topic Starter
  • 1,306 posts

Posted Fri Sep 4, 2015 8:21 AM

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.

 

Attached File  DBFMAKE.ATR   90.02KB   78 downloads

 

 

 


#24 Ripdubski OFFLINE  

Ripdubski

    Stargunner

  • Topic Starter
  • 1,306 posts

Posted Tue Apr 12, 2016 1:02 PM

Podcast has  been consuming my extra time.  Hoping to get more time this summer for this project.







Also tagged with one or more of these keywords: Action!, dBase

0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users