8bit basic coding library

[Ray Gillman]

I now recall having stored a set of 8 bit files in LIST format so they could be added by simply doing an ENTER"D:READSECT.LST"

and it would load a block of basic code with the USR calls for reading and writing sectors from a disk.  This library was quite impressive and allowed me to create lots of cool tools with a nice starting point to know I could "include" (to borrow a C language term) those code snippets to kick off the new application.

 

Anyone have a current set of files or one big file even of this sort of treasure in their collection?  

 

Thank you in advance for keeping the librarian spirit of Atari kicking.

[vitoco]

I had my own collection of such USR routines stored as a lot of LST files, each of them starting from line 10. As my utilities started at line 100, after every ENTER I had to LIST 0,99 and then renumber the line with X$="{atascii}" to the required one, add (or rename) the variable name to a DIM statement and finally delete the "temp" lines.

 

Some years ago, when I copied most of my 5.25" diskettes into ATR files, I found that this diskette had lots of bad sectors. I got frustrated and never tried it again, so I never knew which routines were lost and which ones survived. ?

 

[+Larry]

Back when I coded a lot more than now, I tried that several times, but line numbers conflicts always caused problems. (The line numbers that I had saved didn't fit in with what I was programming at the current time.)  Or, the variable names didn't fit. I wonder if it would be easier to do now with FAST BASIC (with no line numbers)? 

[_The Doctor__]

I take you post to mean when running up against the end of line in old basics- the line numbers pushed the code past the edit line limit. I should think that isn't a concern with fast basic..

[+Larry]

No, not what I meant.  The line number that I would need in a new program didn't match the line numbers (or variables) that I had saved.  Yes, they could be changed, but then the extra editing required to make things usable, would impede the purpose of having the library. I found that by the time I modified the saved routines, then I would save little time.  I would usually just take out a previously written program and see how I did things, then write (almost) from scratch. And perhaps that's just me, but I just didn't find that it was very efficient.  USR routines are a different matter -- USR libraries are quite usable in a library (like BASIC Turbocharger, etc.) 

[E474]

Hi,

 

   Not sure if this is along the lines of what you meant, but I have posted BASIC/Assembler code to access SIO functions on GitHub, see 

for more info.

 

Hope this helps!

[_The Doctor__]

I remember a few people selling sets of library disks with snippets of stuff and examples for this or that in newsletters...  it's surprising none of that is archived...

 

Never had a problem using a renumber utility or changing where a line points to...

as for variable... if you always use a predefined variable set based on your canned code, you could make a quick cheat sheet and keep that in mind when creating. Then you end up with something another person could not easily follow in that RobotFlip might F or even FLP(your canned flip rigamarole) etc. Over time you would be used to all your canned stuff is and know what it does, is named, what it's output variables are like the back of your hand...

the solution for others to read it was you could always have a variable that is named how you like pull from your canned stuff after it processes the data. RbtFlip=flp, after you fed the flp the robot data... or NMEflp=flp, after you fed your flip code your enemy data(slow and adds bytes if your doing this for everything so someone can follow your program). or even just push the result directly if its not required to hold it after it's done what you wanted or the routine performs something visual or audible where whatever it's fed is put out from within whatever you had canned.

seems a little tough if you did it from floppies(possibly slower than just doing it from scratch)... but from any hard disk or todays' divisor zero devices it becomes feasible... some people did slightly similar off of large ramdisks.

 

Would be interesting to see vitico disks and if kryo/scp and a trained eye could recover all that for you.

Edited October 7, 2019 by _The Doctor__

[Ray Gillman]

On 10/5/2019 at 9:56 PM, vitoco said:

I had my own collection of such USR routines stored as a lot of LST files, each of them starting from line 10. As my utilities started at line 100, after every ENTER I had to LIST 0,99 and then renumber the line with X$="{atascii}" to the required one, add (or rename) the variable name to a DIM statement and finally delete the "temp" lines.

 

Some years ago, when I copied most of my 5.25" diskettes into ATR files, I found that this diskette had lots of bad sectors. I got frustrated and never tried it again, so I never knew which routines were lost and which ones survived. ?

 

That is kind of where I am at.  Wanting to rebuild the old 8 bit collection now that there are so many good emulators for it and Xbox360 controllers make pretty nice joystick replacements was looking forward to building some utility and then some kids stuff for the grandkids to play around with but the first few bricks are the toughest to pull together in a rebuilding scenario 

[Ray Gillman]

On 10/7/2019 at 8:36 AM, E474 said:

Hi,

 

   Not sure if this is along the lines of what you meant, but I have posted BASIC/Assembler code to access SIO functions on GitHub, see 

for more info.

 

Hope this helps!

That does help - I can't believe how they store the asm code in an XEX file like that example.  Seems overworked right?  I got used to seeing them embedded with those glyph codes in strings - I remember you had minor issues embedding chr$(34) quote marks and stuff inside the interpreter.

Thanks for that

[E474]

Hi,

 

   I think it's quite simple to convert the XEX to embedded glyph codes (e.g. character strings containing the assembler code), but I found it was simpler to make the XEX in an IDE (WUDSN), then build an ATR that included it, and have BASIC load it from a file. I'm sure there are utilities that will take an XEX and convert it to a BASIC string, but when I was hacking together the code I just wanted to have a quick edit/assemble/test cycle, so I went with this approach as I could spend most of my time in WUDSN hacking the code. It was also example code to show how to do this, so I'm not sure if that counts as overworked or not. To be honest, having to work with line numbers (BASIC) again was a bit like hard work, being able to do almost everything in WUDSN is pretty nice (thanks again @JAC!)

 

  

[Ray Gillman]

I stumbled across this which is a very nice menu I would love to locate the source code to - it has a wonderful intuitive disk exploring ability and could use to be expanded to be more useful in my opinion.  Anyone know where this ACommander 1.4 code might be found?

[Ray Gillman]

I stumbled across this which is a very nice menu I would love to locate the source code to - it has a wonderful intuitive disk exploring ability and could use to be expanded to be more useful in my opinion.  Anyone know where this ACommander 1.4 code might be found?  Found another pretty good menu system which might work called Tom's Navigator which is similarly simple and elegant for an 8 bit disk navigator app