Cbmsh - A Unix-like shell for the commodores

[pallas]

Currently it's a standalone program with the basic built-in commands like ls, more, source, cp, mv, etc. It can execute "scripts" but only containing the built-in commands or launch other programs (no language constructs). It has working wildcard expansion, aliases and some other features.

[Boray]

Ok, I guess that can be useful if you are used to those commands and maybe even more if you have some sort of big modern storage for your vic. I always use my vic menu on Shema's blue cartridge myself: http://user.tninet.se/~pug510w/datormuseum/vicmenu.html

[Mike]

I'd also like to point out (once again), that when you're working with the VIC-20 itself - regardless whether on real hardware or in VICE -, what you see at the READY prompt is already a command line shell. You can even execute shell scripts there, in CBM BASIC!

The BASIC V4 extension adds some comfort so you don't have to remember the (sometimes strange) syntax of the CBM DOS command channel, and you are able to view the current directory without destroying the current program in memory. Single file and whole floppy copying programs are not provided, but you can take any programs available for the VIC-20 that are up to the task. For an example, here's a 'shell script' that copies a whole disk with a file-based method (REL files and direct access sectors are not copied): (link). It always copies between two drives, but you can use the FE3 RAM Disk for a single drive copy (by first copying the source disk files to the RAM Disk, and then from there onto a new disk).

[pallas]

I agree with all of you, maybe it's a useless program.
Nevertheless I'm having fun making it and I think it's a cool project; and since I do not do it for work, that's enough for me to go on

[Mike]

[...] maybe it's a useless program. Nevertheless I'm having fun making it and I think it's a cool project [...]

No worries. Most of us (i.e., the active coders on the VIC-20) do it mainly because of the fun factor. That's the spirit!

I'd still like 40 column support, though.

[pallas]

program execution now works, even though for +8k prg only (will expand to unexpanded in the future).
fitting 16k works as well, but with less available commands.

so now the todo list is as follows:

- ls -l: show file size and type
- sd2iec support for subdirs and full paths
- make prg execution work for unexpanded prgs (and +3k)
- additional commands: find, df, free, ...

some possible future developments:

- history
- 40 columns

[pallas]

OMG this code is full of memory leaks! and with 16k it's more severe than ever!

There are a lot of malloc()s without free(), pointers passing from function to function, uninitialized pointers and counters... it's a nightmare

It's really a pity because the program is almost ready, but on 16k if you run "ls" 4 or 5 times, the ram gets full...

[pallas]

If you wonna have a look at what I've done so far, grab this:

http://www.opbyte.it/cbmsh/cbmsh-0.1.tgz

There are bugs: some commands do not support filenames with paths in them, on the c64 you need to type "run" to run the programs, and others. Some thing are untested and may work, like opening various kinds of disk images.

But it's usable and I want to hear your feedback

(If you want to compile it, you need a svn version of cc65 between december and febraruary, because after that it will not work)

[pallas]

new version 0.2:

http://www.opbyte.it/cbmsh/cbmsh-0.2.tgz

changelog:

- Fixed "cd .." on non-vice drives, it is automatically translated to "cd _" ("_" is the left arrow)
- Changed loading mode to "use keyboard buffer": smaller routine, faster and more compatible (works on c64)
- Added c128 target
- fixed "ls -l" on non-vic20 targets
- can now run vic-20 unexpanded and +3k programs
- fixed "cmp"
- optimizations

[pallas]

new version 0.3:

http://www.opbyte.it/cbmsh/cbmsh-0.3.tgz

changelog:
- added support to run some cart files in prg format
- added "free" builtin command
- added limited "pwd" command, see README
- fixed "cd .." and "cd" with full paths on sd2iec
- fixed running programs whose load command did a carriage return (now clears the screen in advance)
- fixed paging on "ls -l" with too long lines
- optimizations (mostly for size)

[Mike]

I just tried to run MINIPAINT from the FE3 RAM Drive with the FE3 in VICE. While trying to change into the RAM Drive configured as drive #9, cbmsh fails with '9: unknown error'.

Specifically, here's how I proceeded:

- with WinVICE 2.4, I mounted the FE3 firmware image with 'File > Attach cartridge image ... > Final Expansion image' (file name: fe3firmware.prg)

- within the FE3 boot screen, F1 for memory manager, I/O register ticked ON (x), Wedge wicked OFF (.), All RAM (F7),

- mounted drive #8 of VICE to a host directory containing the FE3 RAM Drive files, and started it by running 'fe3rd.prg'.

- changed the drive # of the RAM Disk to 9, by POKEing a 9 into address 3974 (see messages during init),

- loaded 'copy.prg' which I put in the same directory,

- now mount 'minipaint.d64' as drive #8,

- run copy.prg, srv dev. = 8, dst dev. = 9 ... this copies the whole contents of 'minipaint.d64' into the FE3 RAM Disk.

BTW, up to this point everything's o.k. and I can run MP from the RAM Disk without any problems.

- remount the host directory, which also contains a copy of 'cbmsh-vic20-24k.prg', load it and run it.

It responds with:

Code: Select all

cbmsh 0.3
>unit
8*  D:£WinVICE 2.4.2
0 free
9   fe3 - ram driver
408064 free
>unit 9
9: Unknown error
>

MINIPAINT is run fine by cbmsh from the *.d64 image itself.

Greetings,

Michael

[pallas]

Hello,

The "unit" command, when run with one argument, does just this:

Code: Select all

if (chdir(argv[1]) < 0) perror(argv[1]);

"Unknown error" also sounds weird.

Does the ram disk work well with other cc65 compiled programs?
We could make a simple C program with just chdir() in it to see if it's a cc65 specific problem.

(If you are wondering why I'm using chdir() and getcwd() instead of poking and peeking a memory location, I've tried that already, but it clashes with the cc65 libraries)

[Mike]

Does the ram disk work well with other cc65 compiled programs?

I remember during the beta-test phase Kananga and I stumbled across some issues with CBM-Command - don't remember which ones, and whether they could be resolved at the end, though.

OTOH, the FE3 RAM Disk neatly installs into the KERNAL vectors in a similar way to drive speeders, actually it can even chain to SJLOAD - RAM Disk and SJLOAD can co-exist in memory.

If there's some incompatibility related to cc65, it must be because the produced code bypasses the KERNAL vectors with some functions. At least cbmsh somehow manages to scan the directory of the RAM Disk, otherwise we wouldn't even see the title string and remaining space information after the unit command without parameters.

Too bad the maintainer of cc65 seemed to have thrown in the towel some days ago, so there's no direct way to report the problem with chdir().

[pallas]

I had a look at the sources (syschdir.s + subroutines) but I'm not good enough on 6502 asm to debug it.
Anyway there is at least another similar problem: if you try to change (or even access) an unexisting device, it then starts returning errors even on good ones.
It's really a pity that cc65 development is stopped but let's hope a new maintainer can be found and a new stable release made in the near future.
Or, assuming the last stable snapshot is good, I could make cbmsh compatible with that, but it's not a solution I like because it's like walking backwords.

[pallas]

On a side note, do you think the "unit" command should be renamed to "dev"?
I used the "unit" term because it's used by cc65, which covers many non-cbm systems as well so it must be generic, but I understand the most used cbm term for it is "device", shortcut to "dev".