Jump to content
Opry99er

SuperCart Construction

Recommended Posts

Found the bug...it wasn't my code, but was my BL @ 

As I was branching to cpywd instead of

BL @ cpywrd...oh my my.. but yet it was somehow making it to my subprogram cpywrd? I call that a leak.

and as lee predicted, as I can read minds, user error again. ..lol

 

Edited by GDMike

Share this post


Link to post
Share on other sites
16 minutes ago, GDMike said:

I call that a leak.

 

I've always thought of it as an "excursion", facilitated by the 9900 CPU's, DUNNO... ignore and keep going policy.

 

    P.S. Glad to see you're keeping at it!:cool:

  • Like 1
  • Thanks 1

Share this post


Link to post
Share on other sites

Yup, when I said, this doesn't make sense, start over and that's when I found typo...in my BL.   Maybe I should distance my label spelling...hmm

But that's like branching to 101 instead of 110. I'd still mess it up.. how about maybe getting more rest at night..

  • Like 2

Share this post


Link to post
Share on other sites

Ha!Ha! Earlier on, I was going to say... maybe more sleep,:sleep: but didn't want to risk, ticking a tired person off!:o

 

Work-a-holic types, like us, have all been there...:roll:

 

Next up: Branching 101

:D

 

  Alex.

  • Like 1
  • Thanks 1

Share this post


Link to post
Share on other sites

Update: now there's an option, use SuperNotes cartridge (32K SRAM) or

Use 32K memory expansion.

I'll try to make an option that utilizes both at once.

The SRAM cart allows 9 pages for the user as storage while maintaining the SNE program inside the cart too along with menu and the utils.

The memory expansion, PRO version I call it, allows for 17 pages of storage for the user. But unlike the cartridge, the memory expansion data goes away when you turn off the computer.

I will make an option to allow both to work giving the user 26 pages of data storage (860 bytes per page).

Then I gotta make it read/write to DSK, print and a SAMS version...

Someday...

Edited by GDMike
  • Like 3

Share this post


Link to post
Share on other sites

Big shoutout to GDMike who helped get SUPERNOTES running on my TI.  It looks like I needed a bit of help with the Editor/Assembler steps.

 

Great progress so far -- looking forward to more.

 

Thank you!

 

  • Like 3

Share this post


Link to post
Share on other sites

Here's the latest SNP ... with some bug fixes.

This has a working option for utilizing the expanded 32K memory. 

The program asks the user if the intent is for 1.) super notes express cartridge

or 2.) Using to 32K memory expansion

If it's for 32K,(I call 32K pro), then 17 pages are init in lower/Upper, and in-between - anywhere I can squeeze a page... Then the program is released to the user.

SAMS version on the horizon.. still WIP

Well for some Reason my paperclip says loading and I haven't touched it..so the program will be on the next submitted page..

 

Share this post


Link to post
Share on other sites

Options 1-2 work

Just remember, option 1 if you have a formatted SNE cart.

 

DSKA0052.dsk

EA option 3, load  SNP, run SNP as program name.

Edited by GDMike

Share this post


Link to post
Share on other sites

New key made:

Import SuperNotes pages 1-9 from cart and places it at pages 1-9 in 32K expansion memory. This way you can pull that SuperNotes Express data while in the PRO version.

Ctrl I is the new key.

Edited by GDMike

Share this post


Link to post
Share on other sites

I'm looking for a better idea than what I have for a long delay routine...

I'm just incrementing a few Registers until I get my desired outcome, but it takes quite a few of those to do that..so I started throwing in a VSBR routine to help my delay time...it helps but again takes a few of these. My delay should be a 2 second delay.

I'm throwing in everything, NOPs, inct R3 then a dec R3... just to try to stall for time..

Share this post


Link to post
Share on other sites
1 hour ago, GDMike said:

I'm looking for a better idea than what I have for a long delay routine...

I'm just incrementing a few Registers until I get my desired outcome, but it takes quite a few of those to do that..so I started throwing in a VSBR routine to help my delay time...it helps but again takes a few of these. My delay should be a 2 second delay.

I'm throwing in everything, NOPs, inct R3 then a dec R3... just to try to stall for time..

You could wait for 120 VDP interrupts. 

  • Like 1

Share this post


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

You could wait for 120 VDP interrupts. 

Yeah, opa suggested using vdp int...thx

Edited by GDMike

Share this post


Link to post
Share on other sites

This is what I use...

 

DLY1   LI   R8,2
DLYR   LI   R9,>CCCC
DLY    DEC  R9
       JNE  DLY
       DEC  R8
       JNE  DLYR
       RT

 

Here's a working example...

 

       DEF  PRTSLW
       REF  VMBW
HAL    TEXT 'HI I AM A HAL9000 COMPUTER'
PRTSLW LI   R0,0
       LI   R1,HAL
       LI   R2,1
NEXT   BLWP @VMBW
       BL   @DLY1
       INC  R0
       INC  R1
       JMP  NEXT
DLY1   LI   R8,2
DLYR   LI   R9,>CCCC
DLY    DEC  R9
       JNE  DLY
       DEC  R8
       JNE  DLYR
       RT
       END

:)

 

R9=1/2 sec. approx.

R8=number of half secs.

 

 

        HA

  • Like 1

Share this post


Link to post
Share on other sites

Good, I like this. short and simple..

I think my loop is getting lost somehow in the BL @dly  that I created.. as I have a stack of ci >FFFE

inc R3 jump to another delay like this over and over about 10 times and my program zips rt through all of em. I can tell they work a little but I'm not even delayed 1 full second..so something is so wrong..but I'll try yours.

 Thank you.

 

Edited by GDMike

Share this post


Link to post
Share on other sites

This is a little trickier to implement, but uses no registers!

 

       DEF  PRTSLW
       REF  VMBW
       AORG >A000
       DATA 2
       DATA >7777
       DATA 0
       DATA 0
DLY1   MOV  @>A000,@>A004
DLYR   MOV  @>A002,@>A006
DLY    DEC  @>A006
       JNE  DLY
       DEC  @>A004
       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

:grin:

  • Like 1
  • Thanks 1

Share this post


Link to post
Share on other sites

I thought you always had to have a C, or CI prior to a jump Condition. Hmm

But I see how the status changed..

Edited by GDMike
  • Like 1

Share this post


Link to post
Share on other sites

Come to think of it... I suppose I could have used labels on all the DATA directives, as well as in the MOVs and DECs, instead of AORG and absolute addresses.:ponder:

Edited by HOME AUTOMATION

Share this post


Link to post
Share on other sites
36 minutes ago, GDMike said:

In not sure, but maybe the labels would take a byte or two of memory if used.

Not sure if this helps, but I think of Assembly labels with DATA directives or BYTE directives, as "variables". 

So you are correct.  A label with a DATA directive allocates(reserves) 2 bytes of memory for storing data. 

Since you know some Forth this is what the word VARIABLE does in Forth as well when  you compile your programs.

  • Thanks 1

Share this post


Link to post
Share on other sites

Labels do take up space, but in the source code only. All labels are resolved by the assembler, which replaces them with the required addresses, and should produce exactly the same object code, as would using absolute addresses in your source code. Since you can chain the source files together, up to 8K each, memory use isn't really an issue.  Although personally, I've only come close to producing an 8k source file, instead loading separate smaller object files manually. I'll try and produce the labeled version, a little later, if time permits ...sometimes I wonder.

 

I started learning assy. around 1998. I only had MINIMEMORY and LINE by LINE ASSEMBLER the first year. I managed to learn a lot, without ever using or understanding the use of labels. Hence, I still often think of using absolute addresses first. It would seem to be more difficult to understand using these addresses from EDITOR/ASSEMBLER, because you can't see the addresses used, until and unless you produce a LIST file during assembly. Even after receiving the EDITOR/ASSEMBLER package, it was another leap(for me) to learn how labels worked at all. I imagine the reverse is true for most assembly programmers!:ponder:

Edited by HOME AUTOMATION
  • Thanks 1

Share this post


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

In not sure, but maybe the labels would take a byte or two of memory if used.

 

As indicated by @HOME AUTOMATION, labels, in and of themselves, take no memory whatsoever in the object code. A label is a convenience for the ALC programmer, whereby the Assembler assigns the current value of the location counter (absolute or relocatable) to the label, which can be used by the programmer as a symbolic address elsewhere in the program. Similarly, using EQUate directives to define symbolic addresses also does not take any object code memory.

 

...lee

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