Treating headerless files as binary when reading (is that possible?)

[Cwiiis]

I've just bumped into this issue where because my binary files have no header, the firmware functions treat them as ASCII and can return read errors even when the read was successful, presumably because it's read an ASCII EOF byte or something similar... Is there any way to trick the firmware functions to treat headerless files as binary so that you can still respect the error flags when reading them? I suppose it's not a big deal to just add headers, but I'd rather not if I can get away with it Of course, ignoring the errors is also an option (and is my current work-around), but I can see that biting me in the butt down the line...

[reidrac]

I do it in speccy and MSX using cassette, and requires knowing the size of the block you want to read.

I don't know if you can do the same on the CPC, but it should be easier just adding the header (that's what I do on disc).

I guess on cassette the header makes it slower, but the firmware is slow anyway. I think most people use the Topo loader instead.

[Squeekboxandj]

It's been a long while since I've had to do this but from memory you call routine &BCA1. You'll need to code a short assembler language loader. Use Maxam or something similar and load file length and memory start address into the registers. 
I did a quick search on this site and Arnoldemu looks to have posted back in 2009 the info you need. 
Good luck. 

[McArti0]

Code Select Expand

5 save"file.bas@,a
10 openin "file.bas"
15 v%=0
20 while not eof
21      gosub 101:?v%,chr$(v%):                  rem read one char/byte
25      size%=&100:a%=&c000:gosub 256:  rem load 1-256 bytes: Value 0 as 256.
30 wend
40 closein
50 end
100 rem
101 CALL &BFFC,&E9DD,&C9,@v%,&3200,&BC80,&CD00:RETURN
256 CALL &BFF3,&C9,&F910,&1312,&BC80,&CD00+(size% AND &FF),&600,a%:RETURN


[Prodatron]

Hi Cwiiis,

if you can run SymbOS with SymShell you can use this command line tool called "AHEAD":

http://www.symbos.org/appinfo.htm?00041

It can add and remove Amsdos binary headers for one or multiple files.

If you want to add a header, you can optionally specify the begin/length/execution address. If you don't specify it, it will just take the length of the file and use 0,0 for begin/execution.

You cannot view this attachment. You cannot view this attachment.

[Cwiiis]

Hi Cwiiis,

if you can run SymbOS with SymShell you can use this command line tool called "AHEAD":

http://www.symbos.org/appinfo.htm?00041

It can add and remove Amsdos binary headers for one or multiple files.

If you want to add a header, you can optionally specify the begin/length/execution address. If you don't specify it, it will just take the length of the file and use 0,0 for begin/execution.

You cannot view this attachment. You cannot view this attachment.

Oh, this is fantastic! A great solution that gives me an excuse to mess about in symbOS every now and again too

[Cwiiis]

symbOS worked a treat fwiw, and is definitely how I'll be doing this going forward... A quick question, is it possible to alter the path automatically when in the shell? Having to type the full path for the extra shell commands, or execute them from their default directory is a bit awkward and I presume they're in a separate directory in the applications zip for a reason(?)

[Prodatron]

Good idea for the next version!

Currently it starts in the path where you execute it (so usually in the symbos directory). You could place a 1line batch file there, which will just change the directory with CD xxx .

Maybe I should add an option when starting SymShell with attached parameter. This parameter is actually executed, but SymShell will be closed directly after execution. With a new option this could be prevented.

[Cwiiis]

Good idea for the next version!

Currently it starts in the path where you execute it (so usually in the symbos directory). You could place a 1line batch file there, which will just change the directory with CD xxx .

Maybe I should add an option when starting SymShell with attached parameter. This parameter is actually executed, but SymShell will be closed directly after execution. With a new option this could be prevented.

That's handy to know too, I didn't really mean the current path so much as the execution path environment variable though - maybe that isn't a thing in symbOS though? If it isn't, it'd be nice for the shell