Jump to content
Opry99er

SuperCart Construction

Recommended Posts

Here is a labeled version of @HOME AUTOMATION’s ALC. I included a check for the end of the HAL string to prevent the program from printing ad infinitum the ASCII values of the RAM (machine code etc.) that follows the HAL string:

 

       DEF  PRTSLW
       REF  VMBW
       
INIT1  DATA 2
INIT2  DATA >7777
CNT1   DATA 0
CNT2   DATA 0

DLY1   MOV  @INIT1,@CNT1
DLYR   MOV  @INIT2,@CNT2
DLY    DEC  @CNT2
       JNE  DLY
       DEC  @CNT1
       JNE  DLYR
       RT
       
HAL    TEXT ' HI I AM A HAL-9000 COMPUTER'
* Using the following label in case HAL ends on an odd address
HALEND 

PRTSLW LI   R0,0
       LI   R1,HAL
       LI   R2,1
NEXT   BLWP @VMBW
       BL   @DLY1
       INC  R0
       INC  R1
       CI   R1,HALEND   end of HAL string?
       JNE  NEXT        display another char if not
       END

 

...lee

  • Like 2
  • Thanks 1

Share this post


Link to post
Share on other sites

Haha, you beat me to it a little, Lee, it looks like you added a way to stop the printing.:cool:

 

here's what I did...

 

easier to implement...

 

       DEF  PRTSLW
       REF  VMBW
D1     DATA 2
D2     DATA >7777
DD1    DATA 0
DD2    DATA 0
DLY1   MOV  @D1,@DD1
DLYR   MOV  @D2,@DD2
DLY    DEC  @DD2
       JNE  DLY
       DEC  @DD1
       JNE  DLYR
       RT
HAL    TEXT ' HI I AM A HAL-9000 COMPUTER'
PRTSLW LI   R0,0
       LI   R1,HAL
       LI   R2,1
NEXT   BLWP @VMBW
       BL   @DLY1
       INC  R0
       INC  R1
       JMP  NEXT
       END

 

You might want to note that, using registers as operands, always runs faster and results in a shorter program.

 

This is because when an instruction that uses registers as operands, is assembled, a single word of hexcode is produced.

 

Using absolute addresses as operands, produces an an additional word of hexcode for each absolute address operand specified.

 

Resulting in up to 3 words of hexcode produced for only 1 instruction!

 

In this case(a delay), slower is ok, but 2 word of memory would be saved by using registers instead!

  • Like 1
  • Thanks 1

Share this post


Link to post
Share on other sites

Ahhhh.... really..ok..yes and I thought I was crazy because my code was running so fast through my loop and I'm using all registers in my code with just a couple ci in their.. but I see, I see.... interesting..

I've always seen this jne command by so many but without understanding it I never used it.. but this cleared things up for that part, I know that's simple but, there were other ways to get my result without the jne so I never bothered, and I take the approach that if I encounter it in my own circumstances then I'll learn it that way, since I've tried it other ways with results then learning it this way makes things so clear.

Thanks you guys. I love this code maybe someone can put 4 of these processors on a board someday and gigs of RAM and a sweet video card and other periphs. What a screamer it would be. Especially in Forth, let alone assy. AND basic.

Share this post


Link to post
Share on other sites

I added an endless loop to the end of your(@Lee Stewart) code, to prevent the program from over-running ad infinitude,:lol: the ASCII values of the RAM (machine code etc.) that follow the JNE! It was ending up, looping somewhere down in console ROM!:o

 

       DEF  PRTSLW
       REF  VMBW
       
INIT1  DATA 2
INIT2  DATA >7777
CNT1   DATA 0
CNT2   DATA 0

DLY1   MOV  @INIT1,@CNT1
DLYR   MOV  @INIT2,@CNT2
DLY    DEC  @CNT2
       JNE  DLY
       DEC  @CNT1
       JNE  DLYR
       RT
       
HAL    TEXT ' HI I AM A HAL-9000 COMPUTER'
* Using the following label in case HAL ends on an odd address
HALEND 

PRTSLW LI   R0,0
       LI   R1,HAL
       LI   R2,1
NEXT   BLWP @VMBW
       BL   @DLY1
       INC  R0
       INC  R1
       CI   R1,HALEND   end of HAL string?
       JNE  NEXT        display another char if not
LOOP   JMP  LOOP
       END

 

     P.S.

I hate it when I do that.:)

 

     H.A.

  • Like 1
  • Haha 1

Share this post


Link to post
Share on other sites

Ok.. since a boundary issue arose yesterday, here is an update to SNE

This is the latest, V.1.1

You can check your version by reading the last line in the SNE file and it should read, V.1.1-ML

This corrects an issue where if a user pressed F2, insert, near or at the end of line, right side of page the program would lose where it was supposed to go and end up locking up the program.

 Thanks, Mike

 

 

DSKA0055.dsk

  • Like 2

Share this post


Link to post
Share on other sites

It just allowed me to see more things I need to correct...I've taken care of 1 but I'm having a time on the other.. it's related to my F2, insert key...

And now I'm just about ready to upload an update to SNE to ver1.2

After some tests first.

Edited by GDMike
  • Like 1

Share this post


Link to post
Share on other sites

Supernotes Express update here.

3/9/20 ver 1.2

Corrects F2, character Insert. Where

If a user was at end of line, right, and F2 was pressed. This was causing the computer to lock up.

Another update to F2, insert character. Sometimes pressing F2 and hitting the space bar would result in a "no key response" until an F3 or F8 key was pressed. This has been corrected in ver 1.2 also.

And users wanted another way to save pages other than pressing"Enter" at the end of each line, they wanted PAGE up/PAGE down to also provide a SAVE page to occur. This has been provided in ver 1.2

Thank you.

ML

DSKA0050.dsk

  • Like 2

Share this post


Link to post
Share on other sites

I think that somewhere the source code of the EDITOR, from E\A, is available... that might shed some light on how the INSERT, function works... But it's so much more fun using the TRIAL and ERR method!:grin:

 

Just yesterday, I stumbled upon the disk image containing your source code... I think I see some issues... Some code that probably does not function as intended... But little else. I'm not sure that there's a way for me to run it w/o your hardware. I'm uncertain that any of the emulators will offer 4 x 8k RAM blocks at >6000.:ponder:

  • Thanks 1

Share this post


Link to post
Share on other sites

Oh yes. I freed up some 420 bytes today

And a lot of code would work so I Left it so as to finish the product as I knew I'd be going back. But I did clean up today.

I did it without looking at another editor, it may have taken quite awhile, but I was taking EA classes as me the instructor lol and reaching out when I ran into trouble..hmm wonder if that ever happened?? Can't remember..

But, I know there is still some code that needs rewriting..at this moment in not sure which it is..but it ain't F2 haha..

Let me think..F8 could use help but I know what to do there...hmm

F1 is Done ok, F3 ok...F7 is simple..hmm

I used your beep and honk...so that's fine.

Hmmm...I'll have to review. 

Now I do know for a fact that the whole thing could be rewritten entirely and different from what I have. 

The way I've got this setup is, I load everything into Ext ram, including menu. Then after the program starts I push it into the cart.

And I segmented the>6000 space with I think 500 bytes reserve at the lower 6000

For menu..as it has to go there.

Then I create an area that I let the user create a cart name and that name sits in that segment after menu. The cart name serves 2 purposes. 1. User defined for personal reasons, 2, the program looks scans that segment and if it sees the cart name is other than the default, then the program knows that the user is sitting on bank 0 and we put up an error saying that you need to switch Banks.

Each bank is segmented with the name of the bank, as in BANK 2,3,4 and are not user defined.

I have a counter that countsdown before changing cursor shape. And in-between that I scan the keyboard and bank name.

Pressing Enter saves the screen page.

Pages are equates to 862 byte boundaries. I spare a byte to make me feel better. Actually it's on purpose, as I can always use it for a flag if needed. So it's reserved..

Page up and down also do a page save.

Oh and my Auto repeat is setup like this. Each function or special key gets a variable set from 2 to 20, and anything above >20 gets a variable and then I had to create one for the space character. All not in sequence just a pick as long as there different from each other and the same value is set for the same function. Using a 1 byte variable flag.

And I have another flag that is either a 0 or a 1 or a 2.

If the program sees that first flag before, then it's incremented. 

If the program sees it twice then that function basically pauses by returning to my cursor timer, then on the third flag of that function it tells the program not to change the flag unless the key was lifted or if some other instance caused a change.

It seems to work

 

 

 

 

 

 

Edited by GDMike
  • Like 1

Share this post


Link to post
Share on other sites

After testing the SNP program for the F2 bug that I fixed in the SNE program yesterday, I couldn't find any of the problems with it. It all works wonderful.

So I have the green flag for proceeding with the SNP program. As it stands now, we have a 32K version that has many editing options + F9 pulls up the help menu and 17 pages of PEB memory for user space.

SNP allows the user at boot to select SAMs if you have SAMs. The SAMs section is what I'm currently working on.

With something like 980 pages of user space + I'm hoping to make it TIPI compatible later.

 

 

  • Like 2

Share this post


Link to post
Share on other sites
23 hours ago, GDMike said:

Supernotes Express update here.

3/9/20 ver 1.2

Corrects F2, character Insert. Where

If a user was at end of line, right, and F2 was pressed. This was causing the computer to lock up.

Another update to F2, insert character. Sometimes pressing F2 and hitting the space bar would result in a "no key response" until an F3 or F8 key was pressed. This has been corrected in ver 1.2 also.

And users wanted another way to save pages other than pressing"Enter" at the end of each line, they wanted PAGE up/PAGE down to also provide a SAVE page to occur. This has been provided in ver 1.2

Thank you.

ML

DSKA0050.dsk 180 kB · 5 downloads

Here's a video to go with this

  • Like 1

Share this post


Link to post
Share on other sites

I ran into an issue where I lost the menu during bootup. I just wanted you all who use SuperNotes Express to see this video.

But I turned on the computer and the switches were already down, so I rebooted and put the switches up then back down again.

Edited by GDMike

Share this post


Link to post
Share on other sites

Supernotes pro is finally reached a stage where I need to save the 17 pages,840 bytes per page, to disk.

I've been reading, Thierry’s pages, and trying to get aquanted with PAB, DSR stuff ya know, that needs to happen. But I ain't got a clue so far or where to start.

Plus I can read and read but if I don't see it in action, I'm still going to have a tough time. But I sure wish someone.hmm

Would do a video and explain these things out visually.

That would be super! To see a demonstration on how the DSR works the way it does. I can probably find code to do my job, but I really would like to see it presented. 

Oops..I just found this.

"What would it take..."

I will study this on the forum

Edited by GDMike
  • Like 1

Share this post


Link to post
Share on other sites

Hmmm, my agent said nay to the video.:roll:

 

This shouldn't be to hard to do though.:twisted:

 

I built this in Classic99's EDITOR/ASSEMBLER.
I tested using MINIMEMORY and EASYBUG, also on Classic99.:)

 

Easy as cake!;)

 

By using a MOVB instruction to change @PAB to >06 or >05,
you can switch between SAVE/LOAD, before BL-ing into @DISKIO.:ponder:

 

       DEF  DISKIO
       REF  VMBW,DSRLNK
PAB    DATA >0600,>0000,0,840,>000B
       TEXT 'DSK1.PAGEXX'
PABADR EQU  >3000
DISKIO MOV  R11,R10
       LI   R0,PABADR
       LI   R1,PAB
       LI   R2,21
       BLWP @VMBW
       LI   R2,PABADR+9
       MOV  R2,@>8356
       CLR  @>837C
       BLWP @DSRLNK
       DATA 8
       MOV  R10,R11
       RT
       END

 


Adapted from, E/A Manual - 18.3 EXAMPLE OF FILE ACCESS(p.303).

 

      P.S. The PAB address of >3000, might need to be adjusted, to suit your application.8)

Edited by HOME AUTOMATION
  • Haha 1

Share this post


Link to post
Share on other sites

I'm laughing...

 you just couldn't help yourself..

I'm that way too. 

I love the scheme and I might just try it.. but I really need to Know why and how it works. I'll look at that page you provided. And try to grasp it. Thanks..

Awesome stuff...

 

  • Like 1

Share this post


Link to post
Share on other sites

Well, it helps to have a working example, really!

 

Why it works???

 

Thierry's pages on disk access, seem to be a bit more about direct access to the hardware level, rather than using TI's, disk DSR.

 

I'll try to tell you, some of what I think you'll need to know...

 

First, the data you wish to save/load, to/from disk, is located in CPU RAM. TI's disk DSR, moves data back and forth between disk and VDP RAM. Your program has to move that data back and forth, from VDP RAM to/from CPU RAM.

 

So to save a page(840 bytes) to disk, you'll need to move some or all of the page to VDP RAM, setup a PAB, register the PAB's name length at >8356. Call the disk DSR, and let it do the rest.

The PAB provides the disk DSR with, the file name, the data location and length to SAVE/LOAD.

 

Sec. 18, of the E/A manual goes into great detail about how to manipulate RECORDS, as in, VARIABLE/FIXED, RELATIVE/SEQUENTIAL, REC #'s, OPEN/CLOSE, READ/WRITE. None of these, come into play, when using the  SAVE/LOAD Op-codes.

 

Files of the FIXED/VARIABLE type, using the OPEN/CLOSE, READ/WRITE, RESTORE, DELETE, SCRATCH, STATUS Op-codes, use multiple small records(a few screen lines worth) that need to be manipulated individually by your program. The max file size is limited by the size and number of RECORDS you choose(max. REC #'s, 32767, I believe). Because the individual RECORDS are small, only a small amount of VDP RAM is needed for the data buffer.

 

Files using the SAVE/LOAD Op-codes, move larger blocks of data, referred to as a MEMORY IMAGE or PROGRAM. The amount of data to be moved, to/from a file must fit in VDP RAM all at once. Thus the max. file size is limited by this factor.

 

I have only used SAVE/LOAD Op-codes with ASSY, so I can't help much with the other methods.

Although SAVE/LOAD may require more VDP space at once, it is possible to save the "current" VDP RAM contents first, in order to make room for the data buffer, than restore the "current" VDP RAM after moving your data.

:)


 

Edited by HOME AUTOMATION
  • Like 2

Share this post


Link to post
Share on other sites


How it works???:lol:

 

       DEF  DISKIO
       REF  VMBW,DSRLNK
PAB    DATA >0600,>0000,0,840,>000B *Once copied to VDP RAM, this 
       TEXT 'DSK1.PAGEXX'           *data and text, comprise the PAB.

PABADR EQU  >3000     *where the PAB is to be created, in VDP RAM.

DISKIO MOV  R11,R10   *save return address(I think @DSRLNK trashes R11).

       LI   R0,PABADR *where the PAB is to be created, in VDP RAM.
       LI   R1,PAB    *buffer containing the structure of the PAB.
       LI   R2,21     *length of PAB.
       BLWP @VMBW     *create PAB!

       LI   R2,PABADR+9 *register PAB's location(so it can be found
       MOV  R2,@>8356   *by the disk DSR).

       CLR  @>837C      *clear the GPL STATUS byte(required).

       BLWP @DSRLNK     *do the magic! (create, read, write the file)
       DATA 8

       MOV  R10,R11     *restore return address
       RT
       END

 

...about the PAB data:

 

       >0600,>0000,0,840,>000B

 

The first byte(byte 0) should be 06, to save to disk, 05 to load from disk.
The second byte is unused.
The third and fourth bytes specify where the data is/goes in VDP RAM.
The lone zero, between commas, represents bytes 5 and 6, both unused.
The 840, in bytes 7 and 8, specify how many bytes to save/load.
The ninth byte is unused.
The tenth byte, you should use, to specify the filename's length(11)(device.filename).
The eleventh and successive bytes, are where you specify the device.filename.

 

In my sample program, I set the data buffer to >0000, the SCREEN TABLE, so as to allow the visual inspection of the save/load data, while still in the buffer! From there, the data can be moved back and forth to/from CPU RAM by using VMBR/VMBW.

 

It might be wise to use a SYMBOLIC MEMORY ADDRESS instead of R10, or perhaps load a new WORKSPACE altogether before the DSR call(for compatibility). Seems to work, this way, though.


     Good luck, though!:grin:

Share this post


Link to post
Share on other sites

WOW. You make it easily understood, and I'm assuming a lot of things I suppose as most of this fits my need.

Thank you for this!!

  • Thanks 1

Share this post


Link to post
Share on other sites
7 hours ago, HOME AUTOMATION said:

Files of the FIXED/VARIABLE type, using the OPEN/CLOSE, READ/WRITE, RESTORE, DELETE, SCRATCH, STATUS Op-codes,

 

Never use SCRATCH (scratch record) because it was never implemented. It always returns an error.

 

 

6 hours ago, HOME AUTOMATION said:

It might be wise to use a SYMBOLIC MEMORY ADDRESS instead of R10, or perhaps load a new WORKSPACE altogether before the DSR call(for compatibility). Seems to work, this way, though.

 

Presuming you are using the E/A DSRLNK routine, BLWP @DSRLNK already changes to a different “utility” workspace in low RAM (>209A).

 

Also—you can save an instruction at the end of your routine by returning via the register used to save the return address.

       B    *R10     *return to saved address
       END

 

...lee

Edited by Lee Stewart
Corrected ERROR in Assembly code.
  • Like 2

Share this post


Link to post
Share on other sites

You're welcome, but it's only rocket science!:ponder:

 

...Piece of Pi.;)

 

I try to take a simple approach, where possible. The main program usually tends to be enveloping enough!

 

I also chose the SCREEN TABLE, as the data buffer, so I could test the subprogram's functionality easily, using EASYBUG.

 

If you REINITIALIZE MINIMEMORY using option 3 and FCTN 6, then load the DISKIO object code using option 1, the subprogram should load-up at >A000, with an entry point of >A016. Go into EASYBUG and (E)xecute >A016. This will create a file named "PAGEXX" on DSK1, containing the current screen image. Use the (M)odify CPU RAM to change the PAB Op-code at >A000 from >06 to >05. (E)xecute >A016 again. This will read the file from DSK1 back to the buffer, thus restoring the earlier screen image.

 

This method, saves 1 page per file. You could save up to 16K(less the size of the PAB) per file, but that would require, a bit more juggling of the data.

 

The main trick to using this subprogram, is to manipulate the bytes in the PAB(including the filename), before each call of the subprogram.:cool:

Edited by HOME AUTOMATION

Share this post


Link to post
Share on other sites
3 hours ago, Lee Stewart said:

 

Never use SCRATCH (scratch record) because it was never implemented. It always returns an error.

 

 

 

Presuming you are using the E/A DSRLNK routine, BLWP @DSRLNK already changes to a different “utility” workspace in low RAM (>209A).

 

Also—you can save an instruction at the end of your routine by returning via the register used to save the return address.

       B    *R10     *return to saved address
       END

 

...lee

Yes, I'll be using that utility, DSRLNK. 

I understand a bunch of this in appearance, I haven't had time to sit down and examine thorughly. 

But maybe sometime in a few days. 

(Down with back problems)..

Hopefully I'll bounce back in a couple days and get this code flying..ty

 

Share this post


Link to post
Share on other sites
LI   R2,21     *length of PAB.

You lost me here and after here(above).

Is this supposed to be the number of bytes total in PAB +

DSK# period + name? If so, I got everything up to this.

 

But I'm not understanding the next part, "so it can be found"

LI   R2,PABADR+9 *register PAB's location(so it can be found.
Edited by GDMike

Share this post


Link to post
Share on other sites
2 hours ago, GDMike said:
LI   R2,21     *length of PAB.

You lost me here and after here(above).

Is this supposed to be the number of bytes total in PAB +

DSK# period + name? If so, I got everything up to this.

I think you have the first part right.

VMBW, copies the first 21 bytes of data in the subprogram, starting with >06(SAVE Op-code) and ending with >58(X). VMBW, copies these bytes into VDP RAM at >3000.

 

diskaccess1.thumb.JPG.76d6f704d41bfcc9cc0ae42872343e68.JPG

 

2 hours ago, GDMike said:

But I'm not understanding the next part, "so it can be found"

LI   R2,PABADR+9 *register PAB's location(so it can be found.

That should read... "(so it can be found by the disk DSR)"

 

PABADR+9 would point to the length byte(>0B) just before the device.filename(>3009). I'm just assuming, but placing that VDP address pointer(>3009), into CPU RAM at >8356, gives the DSR, a way to locate your PAB, so that the DSR can know what you want it to do next.

Edited by HOME AUTOMATION
  • Thanks 1

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

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