PyDC converter (was: dragon 32 cassette format ?)

Hardware Hacking, Programming and Game Solutions/Cheats
jedie
Posts: 655
Joined: Wed Aug 14, 2013 12:23 pm
Location: germany
Contact:

Re: dragon 32 cassette format ?

Post by jedie »

Sarah wrote:You need to set the gap flag ($FF) for ASCII BASIC.
Have i done with https://github.com/jedie/PyDragon32/com ... c47#L0R377
But why? ...or: what is the gap flag for?

GAP-FLAG if ASCII-BASIC and NO-GAPS if tokenized BASIC ?? Makes no sense, because we have the flag if ASCII or tokenized...
Sarah wrote:Your sync byte trailing the header is commented incorrectly but that won't matter; it's not required (sync bytes come before blocks rather than after them).
I have seens this "MAGIC BYTE" as terminator of blocks in other code. So i have also add it in the stream. But doesn't really make sense, because we have the block-length information, so no terminator is needed...

I have removed the MAGIC BYTE stuff.
Sarah wrote:Since this is an ASCII file the text should end with the final carriage return ($0D which I presume is what your '\r' character generates) rather than $0000.
I have also seen this in other code. And it seems to work. But maybe there is also no terminator needed? Because of existing block-length, too?

I have tested it. It works with only one \r at the end.
Maybe $0000 is in tokenized BASIC needed?

I have removed the code terminator with https://github.com/jedie/PyDragon32/com ... 2e719f6685
... too many ideas and too little time ... Related stuff written in Python:
Dragon 32 emulator / PyDC - Python Dragon 32 converter: https://github.com/jedie/DragonPy
DWLOAD server / Dragon-Lib and other stuff: https://github.com/6809
jedie
Posts: 655
Joined: Wed Aug 14, 2013 12:23 pm
Location: germany
Contact:

Re: dragon 32 cassette format ?

Post by jedie »

So it looks like this:

Code: Select all

'UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUU' # 35x Leadin bytes 0x55
'<'                                   # Sync byte 0x3C
'\x00'                                # block type: filename block (0x00)
'\x0b'                                # block length (11Bytes)
'HELLOWOR'                            # filename
'\x00'                                # File type: BASIC programm (0x00)
'\xff'                                # format: ASCII BASIC (0xff)
'\xff'                                # gap flag (00=no gaps, FF=gaps)
'u'                                   # block checksum
'UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUU' # 35x Leadin bytes 0x55
'<'                                   # Sync byte 0x3C
'\x01'                                # block type: data block (0x01)
'8'                                   # block length 0x38 (56Bytes)
'\r10 FOR I = 1 TO 10\r20 PRINT I;"HELLO WORLD!"\r30 NEXT I\r' # Basic code in ASCII format
'\x8f'                                # block checksum
'UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUU' # 35x Leadin bytes 0x55
'<'                                   # Sync byte 0x3C
'\xff'                                # block type: end-of-file block (0xff)
'\x00'                                # block length (0Bytes)
'\xff'                                # block checksum
The diff is here: https://github.com/jedie/PyDragon32/com ... ter#L4R150
... too many ideas and too little time ... Related stuff written in Python:
Dragon 32 emulator / PyDC - Python Dragon 32 converter: https://github.com/jedie/DragonPy
DWLOAD server / Dragon-Lib and other stuff: https://github.com/6809
Sarah
Posts: 177
Joined: Wed Apr 13, 2011 3:36 pm
Contact:

Re: dragon 32 cassette format ?

Post by Sarah »

jedie wrote:But why? ...or: what is the gap flag for?

GAP-FLAG if ASCII-BASIC and NO-GAPS if tokenized BASIC ?? Makes no sense, because we have the flag if ASCII or tokenized...
It's to do with how the file loads back into memory; gapped files load successively into the same memory area (cassette buffer). There's a bigger overhead whilst each block is then processed (in the case of ASCII BASIC each line needs to be tokenized into memory) than with a continuous stream, hence an inter-block gap is left to allow for the processing time and the next block always has a significant leader to allow loading to resync.

You could think of it as a sub-format byte if that helps. It's not fixed to the primary type (e.g. there are both continuous and gapped formats for machine language too even though the gapped format is rarely used and few people know it even exists). There are only specific combinations of these bytes that are supported. Set the 3 bytes to $00FFFF for ASCII BASIC and you should be fine.
jedie wrote:I have seens this "MAGIC BYTE" as terminator of blocks in other code. So i have also add it in the stream. But doesn't really make sense, because we have the block-length information, so no terminator is needed...

I have removed the MAGIC BYTE stuff.
I think you misunderstood. The 'U' byte is supposed to be there; it allows for processing overhead in continuous files, but it makes no difference for gapped files because it's always followed by (a gap and) a significant length leader anyway. I was just pointing out that your value 'U' (i.e. $55) and comment were inconsistent with each other since your comment gave the sync byte ($3C) value.

Incidentally, on a real machine (rather than under emulation) you may need to use a longer inter-block leader length.The processing overhead isn't a constant.
jedie wrote:I have tested it. It works with only one \r at the end.
Yes that's all you need for ASCII BASIC. I'm glad it works now!
jedie
Posts: 655
Joined: Wed Aug 14, 2013 12:23 pm
Location: germany
Contact:

Re: dragon 32 cassette format ?

Post by jedie »

The only bad thing is that the blocks not limited to 255 characters, yet, if source is .bas... But this will come ;)

Now i added IMHO a nice feature with https://github.com/jedie/PyDragon32/com ... bd0a4e7860

from README ( https://github.com/jedie/PyDragon32/tre ... convertion ):
With --case_convert you can convert upper and lower case:
  • if source is a file: All cased characters converted to lowercase
  • if destination is or : All cased characters converted to uppercase
So you can write a local .bas files on pc in "normal" way, like this:

Code: Select all

10 print "hello world!"
With --case_convert the content will be saved in or so:

Code: Select all

10 PRINT "HELLO WORLD!"
Other way around, vice versa.
... too many ideas and too little time ... Related stuff written in Python:
Dragon 32 emulator / PyDC - Python Dragon 32 converter: https://github.com/jedie/DragonPy
DWLOAD server / Dragon-Lib and other stuff: https://github.com/6809
jedie
Posts: 655
Joined: Wed Aug 14, 2013 12:23 pm
Location: germany
Contact:

Re: dragon 32 cassette format ?

Post by jedie »

jedie wrote:The only bad thing is that the blocks not limited to 255 characters, yet, if source is .bas... But this will come ;)
Done with https://github.com/jedie/PyDragon32/com ... 96ea0f1b11
:P
... too many ideas and too little time ... Related stuff written in Python:
Dragon 32 emulator / PyDC - Python Dragon 32 converter: https://github.com/jedie/DragonPy
DWLOAD server / Dragon-Lib and other stuff: https://github.com/6809
Sarah
Posts: 177
Joined: Wed Apr 13, 2011 3:36 pm
Contact:

Re: dragon 32 cassette format ?

Post by Sarah »

jedie wrote:@Sarah: Can you upload your sources somewhere? Maybe it can help me.
tormod wrote:Are these sources something you can share with us?
Yep, okay... here you go:
viewtopic.php?f=7&t=4354
jedie
Posts: 655
Joined: Wed Aug 14, 2013 12:23 pm
Location: germany
Contact:

Re: dragon 32 cassette format ?

Post by jedie »

Trying to convert testCC_INC.bas with PyDC into a .wav file and CLOAD it into a real Dragon results in a DS ERROR.
Loading the same WAV into XRoar works.

:cry:
... too many ideas and too little time ... Related stuff written in Python:
Dragon 32 emulator / PyDC - Python Dragon 32 converter: https://github.com/jedie/DragonPy
DWLOAD server / Dragon-Lib and other stuff: https://github.com/6809
User avatar
robcfg
Posts: 1529
Joined: Sat Apr 04, 2009 10:16 pm
Location: Stockholm, Sweden
Contact:

Re: PyDC converter (was: dragon 32 cassette format ?)

Post by robcfg »

I've been taking a look, and you're missing the 0x55 byte at the end of the file, and also, if you load the test file into xroar and csave it to a new cas file, you'll find that the file generated by xroar is contiguous where the one generated by your program has the full 0x55 leads for every block.

Hope this helps!
jedie
Posts: 655
Joined: Wed Aug 14, 2013 12:23 pm
Location: germany
Contact:

Re: PyDC converter (was: dragon 32 cassette format ?)

Post by jedie »

robcfg wrote:I've been taking a look, and you're missing the 0x55 byte at the end of the file, and also, if you load the test file into xroar and csave it to a new cas file, you'll find that the file generated by xroar is contiguous where the one generated by your program has the full 0x55 leads for every block.
Thanks!

I create a cas file with XRoar and load it into a hex editor and this it is:
1. 255x 0x55
2. 0x55,0x55,0x3C,0x00 -> filename block
3. again 255x 0x55 ! Why?
4. 0x55,0x55,0x3C,0x01 -> datablock
and then all blocks only separated with 0x55,0x55,0x3C

EDIT: The above example was tokenized.
Not i saved a .cas in ASCII... Then every block has 255x 0x55 sync bytes.
This is the difference with gaps and no gaps ?!?
... too many ideas and too little time ... Related stuff written in Python:
Dragon 32 emulator / PyDC - Python Dragon 32 converter: https://github.com/jedie/DragonPy
DWLOAD server / Dragon-Lib and other stuff: https://github.com/6809
jedie
Posts: 655
Joined: Wed Aug 14, 2013 12:23 pm
Location: germany
Contact:

Re: PyDC converter (was: dragon 32 cassette format ?)

Post by jedie »

I have made changes. So that a ASCII files has GAPS and 255x 0x55 are yield.
But still get a DS ERROR after the last data block :(

Log output of PyDC is here: https://gist.github.com/jedie/7100207
... too many ideas and too little time ... Related stuff written in Python:
Dragon 32 emulator / PyDC - Python Dragon 32 converter: https://github.com/jedie/DragonPy
DWLOAD server / Dragon-Lib and other stuff: https://github.com/6809
Post Reply