Writing a binary file from PCW Locomotive BASIC

[JonB]

Hi

I need to write a binary file on the PCW from a BASIC program. I can't find a manual for this version of BASIC anywhere online and I'm away from my printed manuals.

I tried OPEN and PRINT# but this only seems to like 7 bit ASCII characters. I used "O" mode, but can't find a description of the other modes.

I also tried SAVE "file", B, start_addr, length per the 6128 manual (I found a download) but it is not implemented on the PCW so it gives a syntax error.

Could anyone have a look in the PCW manual for me and let me know how to do this, please? My binary data is currently in a memory block from &HD000 and it's 4096 bytes long.


Thanks
JonB

[GeoffB17]

Jon,


Checking my manual, which I do have to hand...


You need something like this..


open "R", #1, "FILE.BIN", 1
field #1, 1 as data0
count = &HD000
for i = 1 to 4096
  data1 = peek(count)
   data2 = chr$(data1)
   lset data0 = data2
  put #1
  count = count + 1
next
close #1


I might have got some little bits wrong, maybe I should actually do it, but why spoil your fun.


Important things, use a RANDOM file, with record length of 1 byte.
Get the data from RAM 1 byte at a time, write data to the file 1 byte at a time.   PUT command will default to next record anyway.


That (or something VERY like) should give you a binary file of the m/code.


Geoff


PS bits re LSET now added.

[JonB]

That's pretty non intuitive. What's wrong with open "WB", 1, "file.com" then print #1 chr$(byte)?


Thank you, Locomotive Software...


Geoff, again, thank you. I'll give it a whirl. Main thing here is to limit the amount of typing, because this program is the one I mentioned to retrieve the uIDE FID driver from the DOM image and reconstitute it on A: and users will have to manually type it into their PCWs. So KISS approach applies...

[JonB]

Well, Geoff, the only problem was that data0 should be a string, but other than that:

Code Select Expand


open "R",#1,"file.bin",1
field #1,1 as data0$
for addr%=&HD000 to &HDFFF
  lset data0$=chr$(peek(ddr%))
  put #1
next addr%
close #1


It's slow, but appears to work. Banzai!

Cheers
JonB

[1024MAK]

Well, Geoff, the only problem was that data0 should be a string, but other than that:

Code Select Expand


open "R",#1,"file.bin",1
field #1,1 as data0$
for addr%=&HD000 to &HDFFF
  lset data0$=chr$(peek(ddr%))
  put #1
next addr%
close #1


It's slow, but appears to work. Banzai!

Cheers
JonB

Jon, have you lost an 'a' from the variable used by the PEEK function?
Should it be

Code Select Expand


lset data0$=chr$(peek(addr%))

?

Mark

[JonB]

Yeah, typo.


Program appears to work but there's a bug somewhere. Gonna hunt & destroy!

[GeoffB17]

Jon,


Found your bug yet?


Is the resultant file the right length, 4096 bytes?


One thing to check, is addr% ok as an int?   Maybe it's too big, might actually be running as minus.   May need to be SNG, ! rather than %, i.e. addr!   INT can be -32768 to +32767, and I think the addr range you're using is over 32767 and will therefore be treated as minus.   So the count +1 will go the wrong way.


Geoff

[JonB]

Yeah, I noticed, and you're probably right.


I could change them all to floating points, but first need to have a good look at the diffs between the fid and recreated fid. I have a "suspicion".... (he said, mysteriously.)

[JonB]

Looking at the Mallard manual, it seems to imply that a 2's complement integer can be turned into a positive value under certain circumstances, but it's not clear what these are. Section 2.9 and 2.10 pertain here.


A short program:

Code Select Expand


for x%=&HD000 to &HD500
if x% mod 16 = 0 then print: print hex$(x%,4);" ";
print hex$(peek(x%),2);" ";
next x%


This produces a hex dump of the bit of memory where the binary file is loaded to. If the variable x% wasn't incrementing properly, the line addresses would be wrong. But it works. So I think when you PRINT X% it gets interpreted as a negative number during the print formatting, but it's still a positive 16 bit integer for the purposes of incrementing and peek().


At least, that is what the evidence suggests.

[GeoffB17]

Hmm, yes.  Probably?


Seems that Mallard Basic does not allow the explicit definition of an integer as 'unsigned', but in certain places (such as PEEK and POKE) the system accepts that the integer MUST be unsigned (cannot have a minus memory address) so the value is interpreted as unsigned.   I assume that the value is still STORED as signed.


This conversion may well take place within the PEEK or POKE code?


It may well work, but seems to me that there may be a hazard lurking there.


I would tend to follow KISS.   Using Integer type will gain a little speed, but it that so vital here?


Geoff

[JonB]

Finally got it working!


I will update the WIKI with the program. You will need to type it in yourself. And it will only work if you have one of my DOMs, because I will load the driver onto each one before shipping.