PyDC converter (was: dragon 32 cassette format ?)

[robcfg]

word PTR_NEXT_LINE
word LINE_NUM
byte[] TOKENISED_DATA
byte $00 End of line delimiter

'Words' are 16-bit values, two bytes, so the thing is as follows:

Code: Select all

0x1e12 Memory address of next line
0x000a Line number 10


...FOR I = 1 TO 10...

0x0 << End of line delimiter
0x1e29 memory address of the next line
0x0014 Line Number 20

...PRINT I;"HELLO WORLD!"...

0x0 << End of line delimiter
0x1e31 memory address of the next line
0x001e Line Number 30

...NEXT I...

0x0 << End of line delimiter
0x0 0x0 << end of code

Memory addresses are expressed as 16bit values, thus giving a full range of 64KB accessible by the processor.

[jedie]

Thanks!

Why is there the "Memory address of next line" information? It's useless to store/restore it on tape, isn't it?


Other question:

from http://www.onastick.clara.net/cosio.htm :

5.2 A file ID byte where:
00=BASIC program
01=Data file
03=Binary file
5.3 An ASCII flag where:
00=Binary file
FF=ASCII file

from http://www.cs.unc.edu/~yakowenk/coco/te ... ormat.html :

one byte - file type (00=BASIC, 01=data, 02=machine code)
one byte - ASCII flag (00=binary, FF=ASCII)

"machine code" file, are e.g.: from origin tapes. What are "data" tape?
And why are there two flags?
BASIC Programms can be store as Binary or ASCII ?!?!?

[Alastair]

BASIC Programs can be store as Binary or ASCII ?!?!?

Dragon's can save and load BASIC programs in either tokenised or ASCII form:

CSAVE "NAME" = saves in tokenised form
CSAVE "NAME",A = saves in ASCII format

The latter can also be used to save data in ASCII format which may be read with an INPUT# 1 command.

[jedie]

Thanks! Good to know. Currently only tokenised BASIC tested. But BASIC in ASCII should not be a big problem

I have tests some files form: http://archive.worldofdragon.org/archiv ... ragon/wav/

The file "Dragon Data Ltd - Examples from the Manual - 39~58 [run].zip" i get this code:

Code: Select all

10 PMODE 4,1:SCREEN 1,1:PCLS 5:COLOR 0,5
20 FOR I = 1 TO 1000
30 X=X+L*�ON(R):Y=Y+L*�INPUT(R)
40 IF X<-128 OR X>128 THEN 90
50 IF Y<-96 OR Y>95 THEN 90
60 LINE -(X+128,Y+96),PSET
70 R1=R1+60:R=R1/57.29578:L=L+0.5
80 NEXT I
90 GOTO 90

I should check the two "bad" caracters.

Exist there a info, witch files are BASIC or machine code?

[robcfg]

The information to know if a file is binary or ascii, and block types and such,can be found here.

Regarding the 'unknown' characters, you're misinterpretating some values. If you find a 0xFF token, that means that you have to discard the 0xFF itself, and look for the token value in the function table:

#Function tokens - all proceeded by 0xff to differentiate from operators
#Token Function
0x80 SGN
0x81 INT
0x82 ABS
0x83 POS
0x84 RND
0x85 SQR
0x86 LOG
0x87 EXP
0x88 SIN
0x89 COS
0x8a TAN
0x8b ATN
0x8c PEEK
0x8d LEN
0x8e STR$
0x8f VAL
0x90 ASC
0x91 CHR$
0x92 EOF
0x93 JOYSTK
0x94 FIX
0x95 HEX$
0x96 LEFT$
0x97 RIGHT$
0x98 MID$
0x99 POINT
0x9a INKEY$
0x9b MEM
0x9c VARPTR
0x9d INSTR
0x9e TIMER
0x9f PPOINT
0xa0 STRING$
0xa1 USR

So, this line:

Code: Select all

30 X=X+L*�ON(R):Y=Y+L*�INPUT(R)

should be translated as:

Code: Select all

30 X=X+L*SIN(R):Y=Y+L*COS(R)

[jedie]

Thx for info.

I have implement this, now, here: https://github.com/jedie/python-code-sn ... 21b#L1R511

So the complete code looks now like this:

Code: Select all

10 PMODE 4,1:SCREEN 1,1:PCLS 5:COLOR 0,5
20 FOR I = 1 TO 1000
30 X=X+L*SIN(R):Y=Y+L*COS(R)
40 IF X<-128 OR X>128 THEN 90
50 IF Y<-96 OR Y>95 THEN 90
60 LINE -(X+128,Y+96),PSET
70 R1=R1+60:R=R1/57.29578:L=L+0.5
80 NEXT I
90 GOTO 90

[jedie]

Have done some small speed improvement.

Current code here: https://github.com/jedie/python-code-sn ... _decode.py

Any help to unpack the file format and checksum stuff?

[Sarah]

For instance I have some WAV's of whole cassettes that I want to extract all the files from (CAS would do). I tried DC.EXE for this (running in DOSEMU) with variable luck, and that program is anyway dead (no source) I believe.

Oh, that's too bad! R.I.P.

I do have the DC source; some of it was used as the initial basis for DCWIN (which also has improvements and new features for controlling leader lengths).

A set of modular tools would be awesome: WAV2CAS, CAS2BAS, BAS2CAS.

I made several such converters before DC however the growing number of possibilities and common code between them became a little unmanageable, so they were all rolled into the single DC utility, intended to be a universal tool with options made available to select different behaviours if the default wasn't desired.

As mentioned by Alastair, if you want to convert between tokenised BASIC and ASCII then by far the easiest way is to use an emulated Dragon to do it for you. That way you don't have to convert all the tokens... although it would be tricky to automate.

[jedie]

@Sarah: Can you upload your sources somewhere? Maybe it can help me.

And yes, my destination is to create WAV2CAS, CAS2BAS, BAS2CAS and everything with tokenised BASIC <-> ASCII

IMHO the most steps to this have i done, yet.

Missing things are the unpack the meta data, e.g.: file type, checksum...

[robcfg]

I think that I already posted the link, but all the information regarding the .CAS files is here.

A whole program on a .cas file is saved as a series of blocks. The type of the blocks is just after the 0x3C byte. There are three types of blocks:

00=namefile block
01=data block
FF=end-of-file block

All the relevant information about the file is on the namefile block. This is as follows:

0x55 - Lead byte
0x3C - Sync byte
0x00 - Block type (see block types above)

- An 8 byte program name
- A file ID byte where:
00=BASIC program
01=Data file
02=Binary file
- An ASCII flag byte where:
00=Binary file
FF=ASCII file
- A gap flag byte to indicate whether the
data stream is continuous (00) as
in binary or BASIC files, or in blocks
where the tape keeps stopping (FF) as
in data files.
- Two bytes for the default EXEC address
of a binary file.
- Two bytes for the default load address
of a binary file.