Test Scripts in VICE?

[chysn]

I have a program that requires an intricate set of tests. Every time I make a change, I need (well, want) to redo the tests, to avoid regression issues.

I found the "Start recording events" feature in VICE, and thought this might help me. However, when I load the new version of my program and select "Play back events," it seems like it reverts to the version of the program that was in memory at the time the events were recorded? So that's no good as a testing aid when the program changes.

Does anybody have some tips for this kind of thing? Basically, I want to run a script against the newest version of the program, the version in memory when I start the script.

It occurs to me that maybe I can do this with AppleScript....

[Mike]

I suppose you want to script:

1. mounting a disk image or alternatively, a PC hosted directory in VDrive,
2. start a given program,
3. supply (keyboard) input,
4. record (screen) output, and finally,
5. check output against reference.

Points 1. and 2. are directly provided with the command line of VICE. Point 5. could be handled by a program that gets called in the command line script, when VICE has exited.

With points 3. and 4., I would probably go for redirection of KERNAL I/O and instrument the own program to accept files for input and output (much akin to changing input/output streams in the PC command line) instead of keyboard and screen. The CMD <output> command would do this for file #<output> opened for write access, and POKE781,<input>:SYS65478 would do so for file #<input> opened for read access. Unfortunately, KERNAL I/O redirection is half-duplex only.

The video "heron.avi" (~12 MB) shows the incantation "POKE781,X:SYS65478" in action, with a batch assembly from file into MINIMON.

[chysn]

OK, this has been a promising avenue. Since my program uses CHRIN for input, it's easy enough to set up input from a file as you suggested, and it works. I don't care that much that it's not full duplex, since I mostly care about output. And I can always work in a fix for that later by printing the buffer conditioned on the file number.

However, at the end of the file, blank lines just scroll forever. I imagine that the VIC-20 doesn't detect end-of-file, so it just keeps going back to CHRIN and getting nothing. I put x00 at the end of the file, no joy. I also tried BIT $90 to test for end-of-file, also no good. I also created a script file directly with the VIC-20 using PRINT#. Same thing, and no evident file ending seen using cat xxd. How do you specify a file end for the KERNAL in the script?

(Incidentally, when editing scripts in vim for VIC-20, use :setlocal ff=mac so that line endings are x0d only.)

[Mike]

You'd need to detect EOF from input like we did here.

Edit:

I also tried BIT $90 to test for end-of-file, also no good. How do you specify a file end for the KERNAL in the script?

Something like this should actually work. As I noted in the other thread, EOF gets signalled with the last byte sent already, not after it.

[chysn]

You'd need to detect EOF from input like we did here.

Edit:

I also tried BIT $90 to test for end-of-file, also no good. How do you specify a file end for the KERNAL in the script?

Something like this should actually work. As I noted in the other thread, EOF gets signalled with the last byte sent already, not after it.

Ah, yes. And it does work! The end-of-file is being detected. But then I close the file, "READY" appears, and then infinite scrolling!

Here's the ML program:

Here's the BASIC part:

When this is run...

https://youtu.be/yfr1TZQGjBw

I'm holding down CTRL so you can see it in slow motion. The point at which the border color changes is when EOF is detected by the BIT $90 method. Then I close the file and return. But after READY, it scrolls forever. It does the same in my actual program.

[chysn]

If I to JMP CLALL ($FFE7) after the INC $900F, then it stops like it should. I did this in my directory system (which discussion you referenced). There was some controversy as to whether it should work, but it does....

[Mike]

You'd normally use JSR $FFCC (CLRCHN) to revert to keyboard input and screen output at some point.

CLALL "tail calls" CLRCHN, but before that, it sets the number of open files to zero. Which means, files may still be open on a floppy drive, but the computer doesn't remember anymore ...

[chysn]

I changed the CLALL call to CLRCHN, and it still works fine.

All right, Mike, I'm all set here. Thanks a ton again for your help!

I built scripting support to my engine. It's about three dozen bytes, but it'll save me lots of time. It echos commands, and it'll wait for SHIFT to be pressed between commands so I can single step. With SHIFT/LOCK engaged, it'll just run through the whole script. It seems to work fine, but the next step is to write a complete script for the game.

I'm checking $49 (open file#) to determine whether it's in "normal" or "scripted" mode. It doesn't seem like any KERNAL routines (CLOSE, CLALL, CLRCHN) reset $49 to 0, so I do this myself after EOF. Is $49 the best way to check for an open file?

[Mike]

I'm checking $49 (open file#) to determine whether it's in "normal" or "scripted" mode. It doesn't seem like any KERNAL routines (CLOSE, CLALL, CLRCHN) reset $49 to 0, so I do this myself after EOF. Is $49 the best way to check for an open file?

You should be using $98 for this.

$49 is in "BASIC space" ($00..$8F of zeropage) and does not belong to the KERNAL. $49 actually keeps the low byte of a pointer to the variable of FOR/NEXT, and not at all the number of open files.

Also in addition to my previous post, here is the relevant code of CLALL and CLRCHN in the KERNAL:

Code: Select all

; entry point for JSR $FFE7 (CLALL) -> JMP ($032C)

.F3EF  A9 00     LDA #$00   ; set number of open files to 0
.F3F1  85 98     STA $98    ; (i.e. clear table of open files)

; entry point for JSR $FFCC (CLRCHN) -> JMP ($0322)

.F3F3  A2 03     LDX #$03
.F3F5  E4 9A     CPX $9A
.F3F7  B0 03     BCS $F3FC  ; check current output device
.F3F9  20 04 EF  JSR $EF04  ; send UNLISTEN to IEC if necessary
.F3FC  E4 99     CPX $99
.F3FE  B0 03     BCS $F403  ; check current input device
.F400  20 F6 EE  JSR $EEF6  ; send UNTALK to IEC, if necessary
.F403  86 9A     STX $9A    ; $9A = 3 (output to screen)
.F405  A9 00     LDA #$00
.F407  85 99     STA $99    ; $99 = 0 (input from keyboard)
.F409  60        RTS

... and there you see that $98 (number of open files) is just rudely set to zero by CLALL before continuing in CLRCHN.

[chysn]

$49 is in "BASIC space" ($00..$8F of zeropage) and does not belong to the KERNAL. $49 actually keeps the low byte of a pointer to the variable of FOR/NEXT, and not at all the number of open files.

Not number of open files, but the last opened file:

But, I got this from the disassembly, so I'll switch to $98, and if I go back to CLALL I won't have to decrement it myself. The rudeness of CLALL is welcome here.

When I wrote an assembler, I realized that the best thing you can do is to write diagnostic code first. I learned the same thing again. Scripting support at the beginning would have saved so much time. Fortunately, I'll use this again.

[Mike]

Not number of open files, but the last opened file: [...]

The number appears there as side effect how OPEN processes its parameters (see the code at $E216). As I wrote, $49 may also contain other info, so $98 definitely is what you want to use.

I'll switch to $98, and if I go back to CLALL I won't have to decrement it myself.

My caveat regarding CLALL still applies. Especially with files (still) open for write access, it easily leads to splat files.

[chysn]

My caveat regarding CLALL still applies. Especially with files (still) open for write access, it easily leads to splat files.

Understood, but this isn't user-facing code, it's just there to make my life easier. If there are other files open, checking $98 for 0 to ascertain "user mode" is going to fail anyway.

[D-Type]

Have you considered running Forth on the emulated VIC? Then you can put in as many test scripts as you like and call the assembly programs with them. This is how I develop on the 6809 Vectrex, except I'm using physical hardware and a Windows-based terminal emulator connected via a USB serial port, instead of regular screen and keyboard. It works great!

I guess you could do the same with BASIC, but it doesn't offer the same low-level capabilities as Forth.

[chysn]

Have you considered running Forth on the emulated VIC? Then you can put in as many test scripts as you like and call the assembly programs with them. This is how I develop on the 6809 Vectrex, except I'm using physical hardware and a Windows-based terminal emulator connected via a USB serial port, instead of regular screen and keyboard. It works great!

I guess you could do the same with BASIC, but it doesn't offer the same low-level capabilities as Forth.

I have not considered Forth. I don't know it.

My primary concern would be memory utilization. The software I'm testing uses an EEPROM that covers blocks 1, 2, 3, and 5. So where would Forth even go?

I've been pretty happy with the BASIC redirect explained above.

[D-Type]

Well, my Vectrex Forth runs from a cartridge and uses a few hundred bytes of RAM, but you're already using block 5, so I guess you'd have to shoe-horn it into block 0, replace the BASIC ROM or do some other shuffling around. You could make a basic usable Forth in perhaps 2 or 3K.

If you've already filled 4 blocks, chances are you're at the end of your build anyway, but maybe worth a look at Forth for the next one. There are a few to choose from for the VIC, I did notice this thread a while back http://sleepingelephant.com/~sleeping/i ... f=2&t=7557