Preview: cbmshell, an interactive file processor

[srowe]

I was going to amend my request to "If I were to write a 6502 disassembler in Python 3, could you integrate it?'

And, yeah, data's always going to be an issue. That's the way it goes.

If if works on a stream of bytes then it should be easy enough to integrate a separate disassembler module. I prefer to structure my code that way, cbmshell already uses nearly half a dozen modules just to have a clean interface between functions.

[chysn]

Then, perhaps, instead of a disassembler, a way to pipe a stream to a program of your choice. Maybe have a simple configuration file where command names are mapped to script paths. This configuration file would be read when cbm-shell is started, and would look something like this:

Code: Select all

disassemble:/usr/bin/6502disassembler

And then used like this:

Code: Select all

(cbm) disassemble 1:ISR
$1800 sei
$1801 lda #$0d
$1803 sta $0314
$1806 lda #$18
$1808 sta $0314
$180b cli
$180c rts
$180d etc...
(cbm)

The output from a TAP or D64 file could be piped to anything this way.

[srowe]

Then, perhaps, instead of a disassembler, a way to pipe a stream to a program of your choice.

Already supported

https://cbmshell.readthedocs.io/en/late ... xtern.html

[chysn]

Then, perhaps, instead of a disassembler, a way to pipe a stream to a program of your choice.

Already supported

https://cbmshell.readthedocs.io/en/late ... xtern.html

Cool! So if I want to dump a stream of bytes (as opposed to "list"), is there a way to do that? To facilitate disassembly?

[srowe]

Cool! So if I want to dump a stream of bytes (as opposed to "list"), is there a way to do that? To facilitate disassembly?

Not at the moment, I just need to a cat command then you can do something like

Code: Select all

(cbm) cat 0:PROG | disassembler

[srowe]

I've released version 1.4 which implements cat (as well as fixing the empty TAP file bug)

I can recommend the very simple disassembler dxa

https://www.floodgap.com/retrotech/xa/ (bottom of the page)

it even defaults to extracting the load address from the first two bytes of the file

Code: Select all

(cbm) cat 0:MYPROG | dxa

[chysn]

That's great, I'll give that a shot later today.

I already have dxa, as I use xa as my cross-assembler.

[chysn]

I've released version 1.4 which implements cat (as well as fixing the empty TAP file bug)

Hey, srowe, can you please double-check my copy syntax here? The goal is to copy a prg file from a .D64 onto my local file system, so that I can drag it onto an SD card for transfer to my physical VIC.

Code: Select all

$ cbm-shell
(cbm) attach colourtest.d64
Attached colourtest.d64 to 0
(cbm) directory
0 "COLOUR TEST     " 00 2A
3    "LUMA TEST"        PRG
4    "COLOUR TEST"      PRG
1    "LUMA PAL"         PRG
1    "LUMA NTSC"        PRG
2    "PAL ENGINE"       PRG
1    "NTSC ENGINE"      PRG
652 BLOCKS FREE.
(cbm) copy 0:"LUMA TEST" luma.prg
Destination 'luma.prg' is not a drive or directory
EXCEPTION of type 'TypeError' occurred with message: 'NoneType' object is not iterable
To enable full traceback, run the following command: 'set debug true'
(cbm) 

I also tried the forms

Code: Select all

(cbm) copy 0:"LUMA TEST" ./luma.prg

and

Code: Select all

(cbm) attach ./
Attached . to 1
(cbm) copy 0:"LUMA TEST" 1:luma.prg

with the same result.

[srowe]

The quotes need to enclose the drive number so

Code: Select all

(cbm) copy "0:LUMA TEST" ./luma.prg

You have tab completion available so 0:LU<tab> should expand and quote appropriately.

[chysn]

The quotes need to enclose the drive number

Thanks! Okay, on to the next question (sorry)!

When I drag colortest.d64 into VICE and load "LUMA TEST",8, I get a BASIC program that can be run.

But when I use cbm-shell's copy to move luma.prg to my local filesystem, I don't get something that can be run on my VIC-20, I get a detokenized text file of a BASIC program. It's no longer actually a PRG file, which would be tokenized and have an address header. What's going on here?

Edit: Oh, I might need to use --type PRG, let me try that....

Edit Again: Yep! Awesome!

[chysn]

srowe, this is really nice! Kind of a game-changer when it comes to slinging Commodore files around.

[chysn]

OK, now I'm trying to go the OTHER direction. I have a PRG file on the filesystem that I want to add to a new tape file. Here's my session. Can you tell where I'm going wrong?

Update: Please disregard. The solution is to use all capital letters for the destination file, like

copy --type PRG easy.prg 0:EASY.PRG

Code: Select all

$ cbm-shell
(cbm) attach easy.tap
Attached easy.tap to 0
(cbm) copy --type PRG easy.prg 0:easy.prg
EXCEPTION of type 'UnicodeEncodeError' occurred with message: 'charmap' codec can't encode characters in position 0-3: character maps to <undefined>

[srowe]

Character encodings are one of the most awkward matters to deal with

https://cbmshell.readthedocs.io/en/late ... odecs.html

The translation is used for both the contents of BASIC files and file names.

I decided to use upper case/graphics as the default codec as that's what the system boots with. You can switch to lower case/upper case using

Code: Select all

(cbm) set encoding petscii-c64en-lc

[chysn]

Character encodings are one of the most awkward matters to deal with

Believe me, I feel your pain! Uppercase is fine, I just have to remember it. It would be much harder for me to remember the encoding switch command.

Thanks!

[chysn]

Is there a limitation of the TAP format that prevents it from having multiple files with the same filename?

Obviously, when you record to tape with a C2N, you can use the same filename over and over and over again. It doesn't care because it doesn't know. But if I use the copy command in cbm-shell, I get this error when using a filename that's already in the TAP file:

Code: Select all

EXCEPTION of type 'TypeError' occurred with message: open() got an unexpected keyword argument 'record_len'

So the question is, is this a bug in cbm-shell, or is that something the TAP format disallows?