Jump to content

Recommended Posts

I've got some room in SAMs and rt underneath my HELPS source code, as that loads into SAMS bank >FE00 and uses about 1200 bytes..

So what I did was to go ahead and load 1500 bytes of additional code there as it will become my MODI SCREEN routine, I just tested it to see if it could find my B @ SCRD routine and yippee... just like a champ! Branched rt to the routine after mapping..I'm starting to get low on ram and I had this in my head for awhile...

 

 

  • Like 2

Things are going well tonight, but I'm having to stop for the evening.

Was able to fix a couple small bugs,(is there such a thing),  and actually have my MODI SCREEN started and was actually able to move the first field around with the arrow keys for placement. 

Edited by GDMike
  • Like 2

architectural what are your plans for fast database file handling?

 

You know I love my TI  (TM) - but it a real stinker at having two files open at once on the same drive.

 

How do I know? Ask me about the number of times I forgot and had my assembly and output file going to the same floppy drive.

 

Even when working with 990's - the best performance, and it was pretty good, was ISAMation.

 

  • Like 2

Pretty much TIpi support. It's definitely not for the floppy at heart, probably works ok on ram disk, but I don't have access to test that, but, well as far as speed, an old CEO once told me, " I handle slow computers by putting a slow person on it", this ain't made for speed, just a thing I thought I'd like to have access to. 

The filing system hasn't been created, yet. We're still thinking that through as things start coming together..

  • Like 1

Added an escape route in the middle of modi screen. That's going to restore the screen AND command window. I was receiving an error while returning back to command window, and now that's resolved as well. I was returning with an invalid flag...duh... that's right. Fixed..

Working on the SAVE key (enter) in MODI SCREEN which sets the location of the label field in this case and places that screen location in our variable then picks up the next available field, which in this case will be the INPUT field for field 1. 

 

  • Like 2

I'm not sure what's going on.. I've rebooted the laptop...I only picked up where I ended last weekend.. and everything was cool. Now all is ok until I get ready to move field 1 on the screen, and this is after setting up the fields within the program...wthi haven't even touched anything yet, as I'm just starting the day...so I went ahead and recompiled anyway.. still receiving the same thing.

 

Edited by GDMike

Anyway...I Know its getting to the modi screen routine... and it hits a kscan. Normal...I'm going to play around with that routine and see what's up.... this routine workerd for..hmm... like two to three hours with no issues last week..lol...

It's good it broke now so I can figure it out..

Edited by GDMike

Post#191 has the current FOX executable. Don't use this one.

can anyone else run this?

DF 80 use E\A cart. option 3 FOX  and program name is FOXIT

step 1 Press F9 after SAMS init.

step 2 command window ENTER SELE DSK#.FILE

step 3 Command window enter MODI STRU

step 4 ADD 2 or 3 fields.. then SELE E to exit

step 5 command window ENTER MODI SCREEN

press arrow key

 

 

 

FOX

FILEDB

Edited by GDMike
14 minutes ago, GDMike said:

I'm checking my available ram.. maybe I'm out??

Yes despite the efficiency on small routines it can still be hard to keep ASM programs small.

We all have a tendency to write inline code because sub-routines can be a source of errors.

8 bytes to call something here and 20 bytes there, pretty soon it starts to add up on a significant project.

 

I don't know if this would just make one go crazy but the system that the BASIC compiler uses called direct threading can be more efficient for space than native sub-routine calls.

But you have to build up a little system to do it with a return stack and "enter" and "exit" routines. 

With such a system your hi-level code starts to look like DATA statements with lists of sub-routine labels in them. :) 

 

  • Like 1
1 minute ago, TheBF said:

Yes despite the efficiency on small routines it can still be hard to keep ASM programs small.

We all have a tendency to write inline code because sub-routines can be a source of errors.

8 bytes to call something here and 20 bytes there, pretty soon it starts to add up on a significant project.

 

I don't know if this would just make one go crazy but the system that the BASIC compiler uses called direct threading can be more efficient for space than native sub-routine calls.

But you have to build up a little system to do it with a return stack and "enter" and "exit" routines. 

With such a system your hi-level code starts to look like DATA statements with lists of sub-routine labels in them. :) 

 

I still have RAM avail at >Fxxx AFTER playing and deleting...but ill step back a DAY in my history file and see how that version runs.

 

1 minute ago, GDMike said:

it just sets everything to >2020..but i disabled it and it didnt make a difference..I was thinking maybe it might be hitting high ram and causing an issue but its not.

I was just thinking it could be a bit faster if you didn't write numbers on the screen. Maybe just "." 

 

 

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