The DC2N diary-News archive, February 2007
01 Feb 2007
Let's rock
Evening: back home for a short while, I will dedicate my free time to the DC2N.
The complete FAT-16 write support will be under test soon. I already compiled-in parts of it and they work as
expected.
02 Feb 2007
More dumping
Afternoon: I spent a few hours working at the dumping feature to integrate the FAT16 write support.
Dumping process (hard mode)
03 Feb 2007
Another milestone
Morning: The FAT-16 write support was tested by dumping a tape to a valid FAT-16 file that was then
read from the SD Card using my card reader. This one was the first attempt, and it was successful!
06 Feb 2007
BOST
Morning: Thanks to the help I'm receiving from Peepo and enthusi, I decided to write a test program
that should be able to estabilish if the DC2N circuit was correctly mounted and if the MCU is operating as it
should.
The BOST firmware is available for download as srec file, so it can be flashed on the MCU by means of the
bootloader, chip45boot.
DC2N BOST
The BOST doesn't require the circuit to be fully mounted. It's better to mount it following some steps. Peepo
and enthusi are giving me the help I need to write down what to mount, in which order, where, and how to test
that.
08 Feb 2007
Dump, before it's too late
Morning: I have been dumping some tapes, among which there's "Vendetta". I wanted to
dump the latter because it produces a 8MB file. That is excellent to try the FAT-16 write support since
its FAT chain spans over multiple flash sectors. Well, the FAT-16 writing operations were successfull!
TAP files and DC2N
dumps at the FAT-16 dir listing
The reason of concern is somewhere else and is due to time: TAPClean wasn't able to recognize any file inside my
dumps of "Vendetta". Of course, since the CBM ones aren't decoded, it cannot extract the encrypted
values needed to decode Cyberload files neither.
So that, I decided to have a try with exam20: At least I would have been able to check the
CBM ROM files.
After some fine tuning (exam20p -r 31 3d 4f -t 7 vendetta.tap) I was able to correctly decode the CBM part without
read errors. You see, I had to use a low tolerance and to choose custom pulsewidths.
What I'm trying to say is that I think this tape of mine suffers the effects of time. In fact, when I first
dumped it years ago, it was ok. So dump your tapes before it's too late!
Dumping "Vendetta" with DC2N
I will of course try to dump again both sides of "Vendetta" soon for it's one of my preferred
games on the old C64. Strange enough, some games I never liked too much produce clear dumps that get fully
recognized in TAPClean.
Evening: heh, the TAP files converted from my dumps of "Vendetta" load fine in VICE. The
C64 didn't complain that much I see ;)
09 Feb 2007
Mounting and testing
Morning: I mounted the stop button and the bootloader jumper. The first one now lets me stop the hard play
process whenever I want. The latter means I had to change the bootloader so now it's started when its jumper
is removed and a reset/power-cycle occurrs.
DC2N was stopped after loading a game in hard play mode
Also, while playing my dump of "Vendetta" in VICE I realized this game, as Turbo Charge, has a
bug that enables the datasette motor for a few instants while playing. DC2N will check for false motor activations
and ignore them, so that there will be no need to stop it while playing such games ;)
Btw, my dumping tests show that the C2N counter speed variation are strongly influenced by the tape length.
So that I decided to remove the emulation of C2N counter speed variation in DC2N for now. The DC2N counter speed
is now constant.
Evening: I tried to inspect both my oldest "Vendetta" dump and the latest one in TAPMoni.
After looking at the bars I realized that the deep difference between those dumps is that... they were
produced with different C2Ns! Yes, there are wider and broken bars in the latest dump, which means the
datasette heads are differently aligned!
Thin bands in the oldest
dump (C2N head is properly aligned)
Wider and broken bands in the latest
dump (C2N head is not properly aligned!)
Before dumping a batch of tapes it's wise to check the head alignment!
You may use TAPMoni after dumping a few tapes to know if the head of your datasette is properly aligned or even
better use the C64 native head-alignment tool to align it. I made the latter available here as TAP file to be able to load it with DC2N, thus avoiding complex/unreliable
mechanisms actually available to transfer data to the C64.
Btw, I'm working at a fix for TAPMoni that will solve the threading issues.
10 Feb 2007
TAP Moni
Morning: I fixed the threading issues in TAPMoni (GUI version), so that it's available for Windows and Linux,
and it should work nicely.
Afternoon: I've been modifying the SD Card driver and I think I will soon do that again for rising the write
speed during the dump/write operations, by using some different SD Card commands.
While doing so, I've been dumping my tapes of "Turrican" and "Turrican II". All files were
99% recognized in TAPClean. TAPMoni shows thin bars as well.
12 Feb 2007
TAP Version 0 supported
Morning: TAP Moni DC2N edition is now available.
Watching a DC2N 16-bit
dump in TAP Moni
Afternoon: DC2N can now dump tapes as TAP v0 files directly. I introduced the required
corrections to convert the 16-bit samples to TAP values in a smart and fast way. The accuracy is very high: The
maximum difference between a recorded pulsewidth and its real value is below 0.5 microseconds. We know that 100
microseconds is the shortest pulsewidth a real datasette hardware can detect. DC2N maximum error is 200 times
shorter!
I dumped "Ultimate Combat Mission" to a TAP v0. It's available here.
Watching a DC2N TAP version 0
dump in TAP Moni
Of course, there won't be support for TAP v1. As I said elsewhere in this diary, TAP v0 does the job excellently and
the TAP v1 format is not suitable for being used in conjunction with real-time systems.
13 Feb 2007
Crossing boundaries
Morning: While dumping a tape, an SD Card problem showed up: the firmware was busy writing a block to
my 1GB SD card when there was the need to write next one. Fortunately in such cases DC2N stops the process and asks
the user to debug by means of the console interface (connected to a serial terminal).
I deleted the incomplete dump and tried again. The problem showed up again, darn.
By doing some low level debugging, I saw that somehow writing to block #114688 took a bit more time than writing
elsewhere. After some calculations, I recognized that 114688 equals 28*4096. 4096 is the size of a WP group in SD
Cards, and I suspect that stepping from block #114687 to #114688 means to cross some flash memory chip boundary,
which may require some bank switching, thus introducing an additional delay.
The tape I was dumping uses a Turbotape 250 clone, which means I was lucky enough: If I had crossed flash
memory boundaries while importing a tape that used longer pulses, this problem would not have occurred at all!
Anyway, now that I know my SD card shows this behaviour I decided to keep some data at the boundary crossing, so
that future dumping operations won't meet the problem I had at that point. Of course, there should be some
more boundary crossings elsewhere on my SD Card, but they do not seem to occurr frequently. I dumped at least
20MB consecutively and I did not stumble over that problem. I will of course try to dump a batch of Turbotape
250 tapes consecutively to find out more.
14 Feb 2007
Compliance to standards
Morning: I was here thinking about what to say about the compliance of DC2N dumps to the TAP v0 format,
when I realized that this format leaves a few open questions about how dumps have to be generated.
I will summarize here those questions and tell you how DC2N deals with them. Clock cycles refer to the C64 PAL
Frequency.
- long pulses: when a pulsewidth (ie. the delay between two triggers) is longer than (or equals)
20000 clock cycles (which is too much to fit in a single TAP byte), it's splitted into
20000-clock-cycle-long overflow pulses, coded with 0x00s. What if the pulsewidth, once
splitted such way, has a short remainder?
- the greatest pulsewidth that fits in a TAP byte is 0xFF * 8 + 3 = 2043 clock cycles. What about
pulsewidths whose length is in the range 2044-19999 (I will call this range "obscure
area")? There's no value that can code them accurately in TAP v0.
Here there are my answers:
- I checked MTap code and I saw it just rounds long pulses up to an integer number of 0x00s in TAP v0 files.
Fortunately, by default MTap produces TAP v1 files that offer a better accuracy, if required.
OK, but DC2N doesn't supports TAP v1, so that it attempts to preserve that remainder I discussed above
just as it is. I say it's an "attempt" because the length of the remainder may fall within
the "obscure area", which brings us to the following point. We can do better in DC2N only
if we use the native DC2N format.
- OK, I recognize this is a flaw in TAP v0 format. DC2N codes these pulses with an overflow pulse,
just as MTap does. As I suggested above, if we need a better accuracy, we should use TAP v1 or
the DC2N format.
Even if I think it is very rare to find data pulses that fall within the "obscure area",
I don't accept compromises when talking about tape preservation.
After thinking a bit about that, I found three different solutions to this issue:
- ONLY support the native DC2N 16-bit format, then either have it supported by emulators,
or convert it to TAP v1 with the available PC software I made
- support a slightly customized TAP v0 format in which the overflow value 0x00 is 2044 clock
cycles, then either have it supported by emulators, or convert it to TAP v1 with a
new PC software
- support TAP v1 in DC2N
Of course, I prefer the first solution since it's the most accurate one and because I already coded
a conversion tool to convert the DC2N format dumps into TAP v1 files. Since I do not expect
any custom format will ever be used in emulators, the second solution is equivalent to the first one.
Honestly I am not excited by the idea of having to support TAP v1, which was not intended for being
used with a real-time system.
Alas, if the TAP v0 format was handled using the right overflow value, everything would have been
easier!
Btw, the DC2N I am working at is shown here:
The DC2N system I am working at
15 Feb 2007
Compliance, chapter 2
Morning: I realize it's pointless to provide mixed accuracy in TAP v0 generation, so that I decided to make
DC2N TAP v0 generation fully compatible with MTap: any pulse whose duration is longer than 2044 clock cycles is coded
using one or more overflow values, 0x00s.
A funny thing is I have been dumping "Turrican II" 6 times, then "Turrican" 2 times, and
finally "Turrican II" 3 times, but no SD Card timing issue was met. I guess the critical boundary crossing
was done while writing the CBM files that do not require such a fast SD Card block writing as Turrican loader does.
Btw, Turrican loader uses the same pulses used by Turbotape 250, very short ones.
I also decided the final version of the DC2N format for 16-bit dumps:
| Offset |
Size |
Description |
| 0x00 |
12 bytes |
ID string: "DC2N-TAP-RAW" |
| 0x0C |
1 byte |
Format version: actually only version 0 is defined |
| 0x0D |
2 bytes |
Reserved for future needs |
| 0x0F |
1 byte |
Counter resolution [bit]: 16 actually |
| 0x10 |
4 bytes |
Counter rate (LSBF) [Hz]: 2000000 actually |
| 0x14 |
any |
16-bit (counter resolution) data values (LSBF) |
Each data value is the delay, expressed in clock cycles, between two consecutive falling edges of the C2N read line
signal.
Whenever a 0xFFFF is met, it means the next data values should be summed to this one to build up the total delay, up
to the first non-0xFFFF value (included). Anyway, we don't really require to deal with that since the dc2nconv software
converts DC2N 16-bit files to legacy TAP v1 files, which are already supported by many emulators and tools.
16 Feb 2007
PCB job
Evening: I worked at the PCB design since together with Peepo I was able to correct the layout of some
components in the previous PCB and I chose a different SD Card socket.
18 Feb 2007
PRESS RECORD & PLAY ON TAPE
Afternoon: The RECORD feature was added. I wrote a BASIC program on my C64 and saved it to the SD Card by
issuing a SAVE"DC2N TEST!" command. Then I checked it with TAPClean: 100% recognized! And what a quality
I saw in my hex monitor!
19 Feb 2007
TURBO TAPE 64
Morning: I loaded the "Turbo Tape 64" utility with DC2N on my C64 and I tried to save a BASIC
program with its turbo saver. Then I tried to verify and reload the turbo file on the C64: Everything worked!
"Turbo Tape 64" utility, main screen
After saving the file to my HD I tried it in TAPClean: 99% recognized. Its quality is shown below:
PULSE FREQUENCY TABLE
0x19 (1)
0x1A (16071)
0x28 (2095)
Pretty clean, heh?
22 Feb 2007
CBM silence
Morning: after RECORDING some files from my C64 to DC2N I was able to measure the small silence between
CBM header and data (many thanks to Peepo for suggesting me to measure it): 0xA279A clock cycles at 2MHz, which
become 0x500A0 clock cycles at C64 PAL CPU frequency. That's 333 ms about (332,749 ms).
Afternoon: thanks to the files I recorded from my C64 I found a way to correctly handle TAP v0 overflow
pulses while playing TAP files! No more flashing borders while a train of them is being reproduced, just as it
happens with real tapes!
In fact, a train of overflow pulses is a silence, and DC2N can now produce it correctly. I tried the new feature
with "Back to the future 2" and I didn't meet the issue I had been experiencing when I first tried to
properly handle overflow pulses! Yay!
Evening: I was here disassembling the KERNEL save routines of the C64 to know more about CBM loader and
guess what? I found nice confirmations to some numbers I gave to the C64 community before:
- F7BA LDA #$69 ; set 105 sync patterns
STA $AB
JSR $F86B ; write block to tape
- F767 LDA #$14 ; 20 sync patterns
STA $AB
A sync pattern is a sequence of 256 "short" pulses, so that, since one additional sync pattern is written to
tape than the ones set in $AB, we have:
(0x69+1) * 256 = 0x6A00 = 27136 pilot pulses for header, and
(0x14+1) * 256 = 0x1500 = 5376 pilot pulses for data!
Ok, it's not a new thing, but it's now confirmed ;)
The MOTD is "CBM silence" and inside the cassette write
routine we read:
- F8B3 LDX #$FF
F8B5 LDY #$FF
F8B7 DEY
BNE $F8B7
DEX
BNE $F8B5
Well, the busy cycle above consumes about 0x50000 clock cycles. So it is the 333 ms delay the C64 inserts at the
very beginning of Header and Data blocks!
Yes, it can be found before the Header part as well and not just between Header and Data! Thanks to DC2N with which
I recorder files from my C64 to SD Card, I can now confirm these timings and give a new contribution to our
knowledge of the CBM loader.
Stay tuned for more will be discovered by the KERNEL disassembing. Something may
change our view of the CBM file structure just because the viewpoint is changing: Facing the source code and not the
files :)
<- Previous Month Next Month ->
Comers since area creation: 
- Best viewed at 1024x768
All images, files, and text on this page are Copyright ©2006-7 Luigi Di Fraia. All Rights Reserved.
Use of the matherial provided by means of this page is prohibited without the explicit permission of the owner.
