Jump to content
IGNORED

SuperCart Construction


Opry99er

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
Link to comment
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
Link to comment
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..

 

Link to comment
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..

Link to comment
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
Link to comment
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
Link to comment
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
Link to comment
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
Link to comment
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
Link to comment
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
Link to comment
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
Link to comment
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.
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...