Port DirMenu to Vic20?

[HarryP2]

Hi! I have a program called DirMenu. It is a utility to allow the user to run any program on a disk. I have it at https://sourceforge.net/projects/cc65extra/files/ui/. Should I port it to the Vic20? I believe I can do it on even an unexpanded Vic. I'll probably will only be able to fit 18 programs on the screen.

[orion70]

Just another disk browser / prg launcher, but why not?

[HarryP2]

Okay. Thanks!

[HarryP2]

BTW, my DirMenu programs copy the LOAD/RUN sequence from ROM to the keyboard buffer. I can look for the keyboard buffer in my docs., but I don't know where in ROM the sequence is.

[HarryP2]

Never mind. Found it! I have a Windows utility called VBinDiff which can analyze a file or compare two files.

[joshuadenmark]

Yes

[Mike]

I could easily cite a two-digit number of prior art for directory-viewers/-loaders on the VIC-20, but all the people behind those did not feel the necessity to ask around whether it was a good idea to write one - they simply did it.

If you write a compact and fast implementation of that tool and post the result here, chances are that people might take a look at it and possibly use it. Implementing it in C somewhat goes against the goal of being compact - if it takes longer to load the tool than it takes to load the majority of programs with it, that much reduces the chances that people will find your tool useful.

[...] my DirMenu programs copy the LOAD/RUN sequence from ROM to the keyboard buffer. I can look for the keyboard buffer in my docs., but I don't know where in ROM the sequence is.

There's no need to know that address, as putting 131 decimal into the keyboard buffer has the same effect on the VIC-20 (and C64).

Besides, there are much better techniques than the keyboard buffer method to load and run other programs from machine code. They have been covered here in Denial in other threads already (like this one), no need to rephrase them here.

[HarryP2]

It is written in cc65 C but includes a lot of assembler. It is also small and fast. (Most binaries are <1k in size.) Mike, I thank you for your insight.

[Mike]

(Most binaries are <1k in size.)

1 KB is about the maximum size for such a tool with a minimal feature set to keep the pace:

• nbla000's fb20 weighs in at ~2 KB, but it has some extra features like on-the-fly alphabetical directory sort, auto-RAM-config, and being able to change directories on drives which understand the CMD additions to CBM DOS,
• Miklós uses a directory-viewer/-loader of unknown origin (to me at least) on his demo disks, which is only 666 bytes,
• even though it is not of the 'scrolling viewer' type, the VIC WEDGE comes around with 396 bytes with an implementation I included on some of my tool disks (download),
• and if all that matters is a way to view a directory without destroying the current program in memory, you can have that with 95 bytes.

These are some of the existing solutions which should give you an idea where your implementation fits in.

[beamrider]

As has been said, plenty such tools already exists, but I would never discourage anyone from writing any new software for the Vic

There maybe other things worth looking at though....

For instance - I've yet to find a tool that ignores the load address on the tape header and force loads it to BLK1 then saves it back out with the original header. I did start looking at doing this but got side-lined along with several other started projects on my PC.

[Mike]

I've yet to find a tool that ignores the load address on the tape header and force loads it to BLK1 then saves it back out with the original header. I did start looking at doing this but got side-lined along with several other started projects on my PC.

viewtopic.php?t=9770&start=52 ...

In that very case, replicating header and payload of the fast tape routine would only be doing half the job, as the turbo saved main game part also needs to be handled.

I made the backup copy to disk instead.

[HarryP2]

Hi! I was recently working on the Vic20 ports of DirMenu and ran into a problem: it loads a program properly, but, after the loading, it displays the "ready" prompt but no cursor and no RUN command. The code to copy to the keyboard buffer follows:

Code: Select all

	//If vic20, write LOAD command to screen.
	prints ("\f\n\nlO\""); WriteEntry();
	prints ("\",8,1\x13");
	//Write LOAD/RUN tape sequence from kernal starting with Return after LOAD
	//to the keyboard buffer.
        __asm__ (
                "\tldx\t#5\n"		//# bytes to copy.
                "\tstx\t$C6\n"		//# bytes in keyboard buffer.
		"\tdex\n"
                "@z00:\n"		//Copy in reverse order.
                "\tlda\t$EDF8,x\n"	//Address of sequence to write in kernal.
                "\tsta\t$0277,x\n"	//Address of keyboard buffer.
                "\tdex\n"
                "\tbpl\t@z00\n"
        	);

[Mike]

[...] it loads a program properly, but, after the loading, it displays the "ready" prompt but no cursor and no RUN command. [...]

How can you assess that the program has been 'properly loaded' if you get no cursor to type in a LIST command?

[HarryP2]

It displays the "SEARCHING FOR" and "LOADING" messages.

[Mike]

These two prompts are not entirely sufficient to back your assessment. The target program could for example have been loaded into wrong memory locations, which in turn locks up the computer.

From your description, the code snippet writes an abbreviated LOAD command to screen, in the third line so the cursor ends up there when it has been "homed" (which is what the \x13 does at the end of the prints() construction). Then, you put <CR>RUN<CR> into the keyboard buffer. The first CR executes the LOAD command, the second CR executes the RUN command. So far, nothing obviously wrong (the obvious abuse of the cc65 inline assembler set aside).

What happens if you try this instead?

Code: Select all

prints("\fload\"");
WriteEntry();
prints("\",8,1\n");
*(char *)631 = 19;
*(char *)632 = 131;
*(char *)198 = 2;

Note this still needs some refinements as neither 8 as fixed device address nor 1 as fixed secondary address for an 'absolute' load are appropriate in all situations ...