Scratch pad RAM usage

[ralphb]

I'd like to maximize scratch pad usage >8300->83ff in my assembly programs.

What are safe addresses for my own use if I don't use interrupts, DSRLNK, or GPLLNK in my program, and I don't want to return to E/A? How does this change if I still want to use BL @SCAN (in addition to the obvious loss of >8374->8377, >837c, >83e0+)?

This has probably been discussed countless times before, but Google (and the forum search) is surprisingly bad at searching AtariAge. Or I'm surprisingly bad at coming up with search words.

Thierry has a nice list of the scratch pad words, but it is not entirely clear when those are used.

[+Lee Stewart]

How does this change if I still want to use BL @SCAN (in addition to the obvious loss of >8374->8377, >837c, >83e0+)?

 

Among others, KSCAN uses the interrupt workspace (>83C0 – >83DF), the default subroutine stack (>8380 – >839F, pointer at >8373) and most of >8372 – >837F. It does not look like the GPL workspace (>83E0 – >83FF) or the data stack (>83A0 – >83BF, pointer at >8372) are used.

 

...lee

[ralphb]

Ugh, what a greedy little program!

 

Are there more economical alternatives already written that handle debouncing, and preferably return the ASCII code of the key instead of some key code? fbForth, perchance?

 

Size doesn't matter, just scratch RAM usage.

[+mizapf]

Could that look plausible:

 

(a really quick, ugly hack into MESS )

 

This is what I get after a LIMI 0, a BL @>000E, and a JMP $

 

8300 ................
8310 ................
8320 ................
8330 ................
8340 ................
8350 ................
8360 ................
8370 ..WWWW......WW..
8380 ..............WW
8390 ................
83a0 ................
83b0 ................
83c0 ......WWWWWW....
83d0 ........WW......
83e0 WWWWWW..WWWWWWWW
83f0 ......WWWWRR....

Edited April 15, 2016 by mizapf

[+mizapf]

This is what I get after I do a LIMI 2 and lock up the CPU in a JMP $.

 

8300 ................
8310 ................
8320 ................
8330 ................
8340 ................
8350 ................
8360 ................
8370 ........WWWW....
8380 ................
8390 ................
83a0 ................
83b0 ................
83c0 ..RRRR........RR
83d0 ......WW..WWWWWW
83e0 ..WWWW....WW....
83f0 WW......WW..RRRR

[+InsaneMultitasker]

A stand-alone keyboard scanning routine would be a good approach. Examples can be found in source code for terminal emulators. If you like, I can post one that I use when I have time.

 

If you aren't accessing peripherals and don't need the console keyboard routine, most of scratchpad is available to you with exception of the interrupt workspace. If you don't need interrupts (or if you can program around them) you'll be in great shape.

 

If you still need "more" scratchpad space, you can set up memory in such a way that you can save/restore areas of scratchpad, lift your code into scratchpad, execute, and restore. If you don't need to save what is in that scratchpad area, you can simply copy your code there until the next routine needs to be copied.

[Asmusr]

If you only need SCAN for a few menu entries, for instance, you can easily replace it with direct CRU access. Then you can use all of scratch pad for your own purposes.

[+Lee Stewart]

Ugh, what a greedy little program!

 

Are there more economical alternatives already written that handle debouncing, and preferably return the ASCII code of the key instead of some key code? fbForth, perchance?

 

Size doesn't matter, just scratch RAM usage.

 

fbForth uses KSCAN. Mark Wills (@Willsy) and I messed around with various KSCAN alternatives in a PM exchange (not sure whether we hoisted it into a forum discussion thread). Also, there is some discussion in the fbForth thread at post #483ff. I rewrote KSCAN to run from my program space. If I remember correctly, it was a functional duplicate without the GROM table references. I even kept the delay loop, which can be called twice before KSCAN is done. Its counter starts at 1250! Mark managed debouncing without using the delay timer (I think). I would have pursued it further for fbForth, but I did not have enough ROM space for it.

 

Regarding the use of the subroutine stack (>8380 – >839F) and its pointer at >8372, that RAM is only used to save and restore the current GROM address and could either be co-opted or written out of a rewrite.

 

...lee

[Asmusr]

Here's a CRU key checking routine that I have used numerous times:

***************************************************************************
*
* Check key
*
* R0: Column in MSB: >0000 - >0700, Row in LSB: >0006 - >0014
*
*       Column   0      1    2    3    4    5     6       7
*     Row
*     >0006      =      .    ,    M    N    /    Fire    Fire
*     >0008    Space    L    K    J    H    ;    Left    Left
*     >000A    Enter    O    I    U    Y    P    Right   Right
*     >000C             9    8    7    6    0    Down    Down
*     >000E    Fctn     2    3    4    5    1    Up      Up
*     >0010    Shift    S    D    F    G    A
*     >0012    Ctrl     W    E    R    T    Q
*     >0014             X    C    V    B    Z
*
* On return NEQ means that the key is pressed
*
CHKKEY LI   R12,>0024                  ; CRU address of the column decoder
       LDCR R0,3                       ; Select column
       ANDI R0,>00FF
       MOV  R0,R12                     ; Select row
       TB   0                          ; Test key, EQ if not pressed
       B    *R11
*// CHKKEY

[ralphb]

Thank you all for the lightning fast replies.

 

 

Here's a CRU key checking routine that I have used numerous times:

 

Very handy, thanks! I'll add some mappings to that, because -- as you guessed -- I need to translate key presses A ... Z to indices 1 ... 26, for you-know-what.

 

(a really quick, ugly hack into MESS )

83f0 ......WWWWRR....

 

Hey, that's would be an awesome MESS feature! I was thinking of using the debugger to run on a pre-initialized scratch pad and to check which bytes have changed. But you're also detecting reads ... Any chance this might make it into MESS proper?

 

And in case you're wondering ... The more scratch pad I have, the more images I can sort on the FlashROM. Otherwise, I'd have to revert to VDP RAM, which is doable, but tedious.

[+mizapf]

Any chance this might make it into MESS proper?

 

Not really.

 

Honestly, the problem is manifold. For this feature I just glued some printf lines into the code of the databus multiplexer where it accesses the PAD RAM. Of course, I can see whether this is a read or a write access.

 

What I did was to add an "int padaccess[256]" to the databus multiplexer class.

 

You may wonder how I managed to keep the remaining bytes untouched until my program started. This was the next ugly thing. I added a check into the datamux which clears the byte array when an access to address FFF8 is done.

 

if (address==FFF8)

for (int i=0; i<256; i++) padaccess = 0;

 

When a read access to address 8300+i is done and padaccess==0, then padaccess=1. When a write access is done to 8300+i, padaccess = 2.

 

Finally, I loaded the following program into memory:

 

START LIMI 0

MOV R0,@>FFF8

BL @>000E

JMP $

 

This is handy, but there are so many specific things ... what if you want to monitor another memory area?

 

It would be easier to show you into the MESS code and how to compile it. Maybe ti99sim or another emulator can be similarly patched?

[ralphb]

Actually, I was thinking of a read/write counter for ALL memory, displayed in the memory window (if requested), resettable by debugger command. Like a heatmap. (AFAIK, Classic 99 has something like that, but yes, I understand the philosophical differences between those programs. )

 

No immediate need, though, just a nice feature.

[Tursi]

Classic99 does have the memory tracking (for uninitialized memory detection)... there's just no way to view the map. I will think about it.

[Willsy]

I'll post my key scan routine later when I'm home.

[ralphb]

Back to KSCAN:

 

I'm still having a hard time to get SCAN run reliably after a soft reset. I would assume that a soft reset would initialize the scratchpad RAM sufficiently so that I could call SCAN with this code:

.

keymode:
       equ  >8374
keycode:
       equ  >8375
gplst:
       equ  >837c


c_stackptrs:
       data >9e7e
c_newkey:
       data >2000

       limi 0
       lwpi >83e0
       ...
input:
       mov  @c_stackptrs, @>8372  ; restore stack pointers for SCAN
wait_key:
       clr  r0
       mov  r0, @gplst
       mov  r0, @keymode
       bl   @scan
       li   r0, ' '
       movb @gplst, r0
       coc  @c_newkey, r0     ; new key pressed?
       jne  wait_key

.

The problem seems that after a soft reset, SCAN returns that a key has been pressed even though there hasn't, or if it already picks up my "2" from the menu selection then it's returning a different key. I do mess around with the scratchpad up to >8360, but the code is working on hard reset, just not on soft reset.

Before I look somewhere else, is there anything else I need to initialize for KSCAN (that the startup didn't)?

[+Lee Stewart]

Before I look somewhere else, is there anything else I need to initialize for KSCAN (that the startup didn't)?

 

Try putting the actual keyboard mode in >8374 (5, for full keyboard):

 

wait_key:

li r0,>0500 <--This won't work for clearing GPL status byte! See my next post.

 

SCAN will set >8374 to 0 after storing your default keymode - 3 at >83C6 in the ISR workspace.

 

...lee

Edited May 1, 2016 by Lee Stewart

[+Lee Stewart]

Oops! That'll never do! Try the following:

 

wait_key:

clr r0

mov r0, @gplst

li r0, >05FF

mov r0, @keymode

 

My previous post won't clear the GPL status byte! Also, >FF is the code returned for “no key pressed” and might improve chances of your code getting it right for startup.

 

...lee