Start Address from KERNAL's LOAD

[chysn]

After a LOAD operation, I want to show the user the starting address of the program they just loaded.

The KERNAL LOAD routine puts the starting address at $ae, but increments that pointer with every byte that comes in. On completion, LOAD reports the last address loaded (and also, it's still in $ae), but I didn't see LOAD stashing the start address anywhere.

My solution to this is that instead of calling LOAD, I'm reproducing much* of the first maybe quarter of LOAD in my code, up until the point where the $ae pointer is set, and I also save the address to my own start address pointer. Then, I turn control back over to LOAD with jsr $f58a to finish the job.

This works, of course. Once the load is done, I can show the file's entire range. But, damn, it takes 59 bytes.

TLDR: Is there a better way to get the starting address?

* I leave out the parts that check for illegal devices, since I already know the device

[Mike]

The KERNAL LOAD routine inits $AE/$AF either from the first two bytes in the file (in case of an absolute load with ",<device>,1") or from X/Y (in case of a "relative" or relocating load with ",<device>" or ",<device>,0"). The routine doesn't keep that address, because it doesn't need to, $AE/$AF is then used as running address to store the incoming bytes and it ends up with $AE/$AF pointing behind the last loaded byte.

So, implementing a wedge storing away $AE/$AF before the bulk of the LOAD operation takes place is a feasible way. Of course that needs some 'extra' code. An alternative would be to OPEN the file, read the first two bytes containing the load address and display their value (in hex). Most probably, that alternate method needs about the same amount of extra code. Either method only works with IEC, tape needs to be handled by a different way - there, the load address ends up in the tape buffer and BTW is enforced with header type = 3.

SJLOAD also outputs start and end address of loaded files as part of the LOADING prompt. Here, the 'extra' code naturally wedges in, as SJLOAD needs to re-implement huge parts of the LOAD routine anyhow for the alternate transfer protocol, and it's no hassle to display $AE/$AF directly before proceeding further.

Note such wedges are supposed to output these messages only in direct mode. The convention being, that KERNAL messages (with the exception of "PRESS (RECORD &) PLAY ON TAPE" and "OK") are suppressed in program mode so to not disturb the screen display of the running program.

[beamrider]

Just an idea the load routine scans the stop key via a jmp vector at 0328, could you intercept that with your own very simple code that watches for the initial changes to $ae and then removes itself?

[chysn]

An alternative would be to OPEN the file, read the first two bytes containing the load address and display their value (in hex).

I've already called SETLFS and SETNAM, so this is worth looking into. It certainly promises to be clearer. Setting up CHKIN and OPEN calls, 8 bytes, a couple CHRIN calls and storage, 12 bytes, some error-checking, maybe 5-8... This could definitely be the way.

Just an idea the load routine scans the stop key via a jmp vector at 0328, could you intercept that with your own very simple code that watches for the initial changes to $ae and then removes itself?

That's so crazy it just... might... work! Actually, after looking at the KERNAL LOAD routine again, it absolutely would work. Implementation might be on the clunky side, but I'll definitely evaluate it for its memory footprint. Setting the vector at both ends, 20 bytes, maybe another 20-something for the handler. It could be slightly smaller than what I'm doing now.

Thanks, all!

[chysn]

Note such wedges are supposed to output these messages only in direct mode. The convention being, that KERNAL messages (with the exception of "PRESS (RECORD &) PLAY ON TAPE" and "OK") are suppressed in program mode so to not disturb the screen display of the running program.

Thanks for the reminder. I've been suppressing certain output within a BASIC program (breakpoint-setter feedback, some cursor movements, the assembly prompt). I've suppressed the range display as well. The range is formatted to behave like a disassemble command if you cursor up to it.

I tried the OPEN method but I must have done something wrong because text just scrolls off the screen. I'll play around with it later.

[Mike]

I've already called SETLFS and SETNAM, so this is worth looking into.

[...]

I tried the OPEN method but I must have done something wrong because text just scrolls off the screen. I'll play around with it later.

You probably used 1 as secondary address in preparation for an absolute load. With OPEN, secondary addresses 0 and 1 are special cased on tape and disk and have another interpretation: 0 opens for read, 1 opens for write.

So somewhere in between you got the KERNAL I/O error #6 (NOT INPUT FILE) with a CHKIN call but decided to ignore it.

[Mike]

Come to think of it, this application warrants the use as an own transient tool. Because, if the user only gets too know the load address when he has already loaded the file, it's probably too late: the file may have been written to an unexpected address in RAM and has overwritten something else.

I quickly hacked the following listing into MINIMON. The BRK at $0390 can be replaced by an RTS for use from BASIC:

Code: Select all

.033C LDX #$07
.033E LDA $03A6,X
.0341 JSR $FFD2
.0344 DEX
.0345 BNE $033E
.0347 JSR $FFCF
.034A CMP #$0D
.034C BEQ $0354
.034E STA $0140,X
.0351 INX
.0352 BNE $0347
.0354 TXA
.0355 LDX #$40
.0357 LDY #$01
.0359 JSR $FFBD
.035C LDA #$01
.035E LDX $BA
.0360 LDY #$00
.0362 JSR $FFBA
.0365 JSR $FFC0
.0368 LDX #$01
.036A JSR $FFC6
.036D BCS $0388
.036F LDX #$10
.0371 LDA $03AD,X
.0374 JSR $FFD2
.0377 DEX
.0378 BNE $0371
.037A JSR $FFCF
.037D PHA
.037E JSR $FFCF
.0381 JSR $0391
.0384 PLA
.0385 JSR $0391
.0388 JSR $FFCC
.038B LDA #$01
.038D JSR $FFC3
.0390 BRK
.0391 PHA
.0392 LSR
.0393 LSR
.0394 LSR
.0395 LSR
.0396 JSR $039C
.0399 PLA
.039A AND #$0F
.039C CMP #$0A
.039E BCC $03A2
.03A0 ADC #$06
.03A2 ADC #$30
.03A4 JMP $FFD2

>03A7 20 3F 45 4C 49
>03AC 46 0D 24 20 3A
>03B1 53 53 45 52 44
>03B6 44 41 20 44 41
>03BB 4F 4C 0D

Greetings,

Michael

[chysn]

Come to think of it, this application warrants the use as an own transient tool. Because, if the user only gets too know the load address when he has already loaded the file, it's probably too late: the file may have been written to an unexpected address in RAM and has overwritten something else.

It's considerate, albeit unconventional. I don't want to add another command for it, but the LOAD routine could always ask for confirmation if it's in direct mode.

What's with the backwards text?

[tlr]

What's with the backwards text?

That's a common loop size optimization. You could also use a "negative" index value and count up to $00, but then the base address needs to be adjusted to point to the right location (also usually generates a page crossing = +1 cycle).

[chysn]

Incidentally, I wrote a shell script to convert MINIMon output to wAx BASIC programs:

Code: Select all

#!/bin/bash

cp $1.asm $1.asm.tmp
sed -i.tmp '/^$/d' $1.asm.tmp
cat -n $1.asm.tmp | tr "A-Z" "a-z" > $1.bas
sed -i.tmp 's/;.//g' $1.bas
sed -i.tmp 's/>\([a-f0-9]\{4\}\) /@\1:/g' $1.bas
sed -i.tmp 's/\./@/g' $1.bas
petcat -w2 -o $1.prg -- $1.bas
c1541 ../vic/my.d64 -write $1.prg
cp $1.prg > /Volumes/VIC20
rm $1.*.tmp

I'll refine this as needed when I see things that aren't yet handled.

[Mike]

I don't want to add another command [to wAx] for it, [...]

That's why I consider the inquiry/display of the load address a transient utility: nice to have it available in case it's needed, but not important enough to be included as resident command, or part thereof. Besides, as I already noted, other tools like SJLOAD already include the display in their code.

What's with the backwards text?

Most of the code is boilerplate, inherited from the cat utility I released in another thread ... ... and there, the "FILE?" prompt already used that technique, and so I replicated it with the "LOAD ADDRESS: $" caption.

You could also use a "negative" index value and count up to $00, but then the base address needs to be adjusted to point to the right location [...]

That is easily done with another label, "text_end", right behind the text. More problematic is the init value for the index register, which is the difference "text_start - text_end", and which necessarily comes out negative with that technique. Either small negative immediate operands are accepted by the assembler in charge, as 2s-complement, or the calculated init value needs to be vetted by adding 256.

Incidentally, I wrote a shell script to convert MINIMon output to wAx BASIC programs: [...]

[chysn]

In VICE, there's a noticeable time difference between the OPEN method and the KERNAL-replacement method. It takes a couple seconds for "SEARCHING" to appear. Maybe it's because OPEN does the searching without announcing it, loads two bytes, and then LOAD needs to search again.

On real hardware (with an SD2IEC), SEARCHING appears instantaneously. My guess is that the OPEN method would be slower with a 1541, and that's what VICE is emulating.

Still, however, I prefer the OPEN method over the KERNAL-replacement, on a mostly-philosophical basis. The code size difference is 18 bytes, though, so there's also a tangible benefit.

Useful thing I learned: If you want to use the same name again, you don't need to call SETNAM again.

Later, I'll try the Stop key vector method and see if there are any gains over the OPEN method.

Edit: The Stop key vector method works fine, but takes 20 bytes more than the OPEN method, and two bytes more than the KERNAL-replacement.

[Noizer]

Hi chysn, I guess the action is for a nice load function for wAx?
BTW, some questions:
- it's possible to compile wAx to running at $B000?
- what's about coding under active running IRQ? You know, as Mike demonstrated in a parallel topic about stable raster irq?

New question will come for sure. Bye for now

[chysn]

Hi chysn, I guess the action is for a nice load function for wAx?
BTW, some questions:
- it's possible to compile wAx to running at $B000?
- what's about coding under active running IRQ? You know, as Mike demonstrated in a parallel topic about stable raster irq?

New question will come for sure. Bye for now

Yeah, future questions might belong in that topic; but, yes, you can assemble it wherever you want. The 2K version is nice and stable, I think. The additional features of the 4K version are well worth it, in my opinion (it's a Somewhat Symbolic Assembler). I know you're interested in illegal opcodes, and the 4K version has built-in support by way of an alternate disassemble command.

wAx does not use the IRQ or NMI vectors for anything, so it won't get in your way. It sets the vector for IGONE, of course, to capture commands. It also changes the one for BRK trapping; but you can easily control that one with Stop/Restore (to disable) and ! (to re-enable).

[chysn]

For completeness, if anybody is looking for answers to this question in the future, it's much easier to find the starting address for a tape load, because it's kept in memory. After the conclusion of the LOAD, you can check $033d/$033e as the pointer to the start of the loaded data. The end+1 is still in $ae/$af, just like a disk load.

I'm glad it’s so easy for tape. I really decided to grit my teeth and make my tape support robust, on the reasonable assumption that my C2N is going to long outlast my SD2IEC.