Saving Memory for ML?

[BBQedIguana]

Hi everyone,

I've been hammering away on my VIC trying to rebuild my BBS, but I've run into a couple of snags. The first one is about securing memory for my ML program. I *thought* all I had to do was change the pointers for END OF BASIC and START OF VARIABLES to save memory (locations 56 and 52). So, if my RAM (16K expansion) has a value of 96 in locations 56 and 52, meaning my memory ends at decimal 24576, I should be able to:

POKE 56,80
POKE 52,80
CLR

And that should move the top of basic down to decimal 20480, giving me 4096 bytes to build my IO routines with. Is that correct? Or is there something else I need to do?

I ask, because when I use VICMON to assemble some very simple code starting at memory location 20482 (give myself a few bytes clearance?), it works fine. But if I either SYS 20482 or G 5002 from inside VICMON, my code works, but when I return to basic, my pointers are all messed up - end of BASIC moves back up but not all the way to 96 - seems random. Like sometimes it's 66. Sometimes it's 72! And if I have anything in BASIC at the time, I can't do a LIST anymore - I get a SYNTAX ERROR. Sometimes the character color changes to red - it's all messed up!

Am I missing something? Or is my VIC on the way out? Let me know what you think. THANKS!

Rick Towns
Barrie, Ontario, CANADA

[Mike]

Hi, Rick,

first of all, POKEing address 52 is redundant, as the pointer 51/52 (bottom of string space) is set to the value of the pointer 55/56 (end of BASIC space), when you do a CLR. I'd rather make sure that the low byte of 55/56 also is set correctly, thus:

Code: Select all

POKE55,0:POKE56,80:CLR

sets the end of BASIC space to 20480, as you wanted.

(give myself a few bytes clearance?)

Here, 20479 is the last byte touched by BASIC, and 20480 is guaranteed not to be used by BASIC. If you also care to define 55, that is.

I ask, because when I use VICMON to assemble some very simple code starting at memory location 20482 [...], it works fine. But if I either SYS 20482 or G 5002 from inside VICMON, my code works, but when I return to basic, my pointers are all messed up [...]

Well, then something inside your code messes up the zeropage. If you post a listing of your code it's more likely to spot the culprit.

Greetings,

Michael

[BBQedIguana]

Hi Mike,

Thanks for the reply! Location 55 already had a 0 in it, so I didn't think I needed to POKE it again. But I did your suggestion:

POKE 55,0:POKE 56,80:CLR

Then I ran my VICMON monitor (cartridge, SYS 45056), and entered in the following code:

5000 LDA #$05 ; think the 5 in OPEN 5,2,0,CHR$( 8 )+CHR$(0)
5002 LDX #$02 ; the 2
5004 LDY #$00 ; the 0
5006 JSR $FFBA ; JSR to SETLFA logical file
5009 JMP $500E ; JUMP to 500E, as the next 2 bytes are data
500C PHP ; Hex 08
500D BRK ; Hex 00
500E LDA #$02 ; length of the file name - 2 bytes
5010 LDX #$0C ; lower-order byte of file name ($500C)
5012 LDY #$50 ; high-order byte of the file name ($500C)
5014 JSR $FFBD ; JSR to SETNAM
5017 JSR $FFC0 ; JSR to OPEN
501A JRS $FF37 ; JSR to CLOSEALL - closes file 5
501D BRK ; End
501E BRK ; Extra End

I then saved it thusly:

S "MLTERM",08,5000,501E

If I G 5000, things seem to work fine. But when I 'X' out of VICMON, BASIC is all screwed up. I notice that location 44 (start of BASIC high value) is now 0!!! OUCH!

Any hints as to what I'm doing wrong?

Thanks!

Rick

[DELETED]

DELETED

[Mike]

Presuming it is:

Code: Select all

501A JSR $FFE7 ; JSR to CLOSEALL - closes file 5 

... I started up VICE, with RAM enabled in BLK1, BLK2, and BLK5 - and then auto-ran VICMON. This needs to be followed with NEW to reset the end of BASIC pointer. You use VICMON together with that 16K RAM expander in a module box, right?

Then I lowered the roof with POKE55,0:POKE56,80:CLR, and typed in your program. It runs fine, and doesn't clobber the zeropage at all. Also with the VICE monitor I couldn't spot anything suspicious at any time. $F7/$F8, and $F9/$FA get initialised with the RS232 transfer buffer addresses at $5E00, and $5F00.

There remains the possibility, that your 16K RAM expander is probably not quite in order. Could you check with a disassembly command, that the program you typed in is still the program present in memory, before you start it?

Michael

[BBQedIguana]

is isn't your desired behavior. Maybe that $FF37 call should actually be to $FFE7?

You are correct! The CLOSEALL kernal pointer is in fact $FFE7, and I had it wrong in my code. I corrected it to $FFE7, saved it to disk again:

S "@0:MLTERM",08,5000,501E

and then hard reset the VIC. Again, I typed:

POKE 55,0: POKE 56,80: CLR

I then entered a simple program:

10 PRINT "HELLO!"
20 END

I checked that PRINT FRE(I) works - it returned 15849. I then ran VICMON and loaded in my MLTERM program. I didn't run it, but instead exited back out to BASIC and checked things: location 44 had the value of 18, which is correct. 55 had a 0. 56 had an 80. It all looked good. I was able to RUN my program and it worked fine. I went back into VICMON and did a:

D 5000 501E

and my program showed with no issues or problems. I did a:

G 5000

and it ran, indicating the last executed address was 501D, which is correct. All this program does is open the RS232 channel and then close it again. But when I 'X' out to BASIC, everything was pooched again.

I'm wondering if it's VICMON - but I don't think so. It's LOAD and SAVE don't seem to be causing the issue - just when I run my ML code.

Maybe I'll redo it without my 16K RAM expander or try it on another VIC and see what happens.

[Commodore Explorer]

According to the book Mastering the VIC-20 by A.J. Jones, E.A. Coley, and D.G.J. Cole, VICMON's memory usage can cause problems when you exit to BASIC. (This refers to memory used by VICMON, itself, not your program.)

Apparently, VICMON uses a large number of zero-page locations for its own purposes, so when you exit to BASIC, you may find that some pointers have been overwritten. As a remedy, the authors suggest using VICMON's .E command to establish a "virtual zero page" elsewhere in memory and give the example .E 1000 which reserves 256 bytes starting at $1000.

I don't have a VICMON cartridge, so I don't know exactly how a "virtual zero page" works. Perhaps VICMON saves the original zero-page values there and restores them when you exit? I don't know. Consult the VICMON documentation for more information.

Also, there is another issue worth keeping in mind if you ever use the RS-232 channel. While this may not have any impact on your program because of the way it is written, you need to know it, especially if you ever use device #2 from BASIC.

When you open device #2, the VIC allocates 512 bytes for communication buffers at the top of BASIC memory. As such, OPEN x,2,y lowers the top of BASIC memory by 512 bytes and performs a CLR. If your program is too large for this (because the BASIC text occupies some of that memory), you will not get an error message; the end of your program will simply be overwritten.

[wimoos]

And thus you can make it position independ:

5000 lda #5
5002 ldx #2
5004 ldy #0
5006 jsr $ffba
5009 lda #0
500b pha
500c tsx
500d lda #8
500f pha
5010 lda #2
5012 ldy #1
5014 jsr $ffbd
5017 pla
5018 pla
5019 jsr $ffc0
501c jmp $ff37
501f

With it being position independ you can safely add the ML code at the end of the BASIC program, where it also be included during SAVE.