The DC2N diary-News archive, October 2006
01 Oct 2006
Filesystem? maybe
Morning: I decided DC2N may support a filesystem. Now I know that this doesn't cause any
delay if the highest level API just accesses flash sectors and data is stored inside either
contiguous sectors (ie. unfragmented files only) or in a deterministic way.
To make the long story short, there must be no need to read the FAT from the SD Card to
know where the NEXT part of a file is placed, since it means addictional delay. Any
such delay might compromise the hard real-time requirements DC2N itself has.
I think that being able to read/write DC2N data from/to SD Cards by means of a common card
reader would be nice and appreciated, so I'll have a go at it.
Hopefully, even in the worst scenario, I could handle a filesystem by writing a very optimized
firmware.
03 Oct 2006
Liquid crystals, mine to command
Evening: I inserted the LCD driver into the "DC2N SD Card Test Suite". Now the system
looks as follows:
Can you spot the ATMega32 on the STK500 board? ;-)
I also worked at the FAT16 support. I implemented a few primitives inside "DC2N SD Card Test
Suite". Here's a partial output of how it looks like now:
05 Oct 2006
Waves hit the rocks
Evening: the PWM feature is ready and was inserted into "DC2N SD Card Test Suite". I can
now read a sector and 'PLAY' it, in a loop.
After connecting the PWM output to the audio-in port of my laptop I could plot the resulting waveform.
The following picture refers to a train of short ROM pulses (TAP value 0x30), just read from a SD Card
sector into DC2N RAM.
Can you read the measured frequency value? Yeah, 2393 Hz!
The actual inaccuracy is due to the fact I'm using a 3.69 MHz oscillator instead of a 4/8/16 MHz crystal,
which would produce a short pulse at 2604 Hz. On a real C64 a TAP value of 0x30 corresponds to a pulse with
a frequency of 2565 Hz. Better! Anyway, the accuracy will be further improved, probably by doing a
pre-filtering of the TAP file, before writing it to the SD Card, thus freeing the DC2N firmware from doing
any computation.
Just for reference, remember that the CBM standard defines ROM long pulses as having a frequency of 1488
Hz (TAP: 0x53), medium pulses 1953 Hz (TAP: 0x3F) and short pulses 2840 Hz (TAP: 0x2B). Those values are
hard to find on C64 tapes, though.
06 Oct 2006
The first notes
Evening: Time to listen to DC2N! Wow, the starting hiss reminded me about old wonderful times!
A few shots from the oscilloscope software:
A CBM ROM med pulse followed by a short pulse
A CBM ROM long pulse!
07 Oct 2006
Single notes eventually become a melody
Morning: I added a few addictional FAT16 support primitives to "DC2N SD Card Test Suite".
Output from the "DC2N SD Card Test Suite" using my Kingston card
Output from the "DC2N SD Card Test Suite" using a 16MB Toshiba card
Afternoon: the continuous sector PLAYing is working with no issues. By using 2 read buffers
I can produce a continuous stream of pulses without delays within the SD Card read operation.
Since I'm using the single block read command, that means I could even lower the SD Card access
time by using the multiple block read command. The latter requires files to be unfragmented
on the SD Card, so I will think about it at a later time, if the fragmented files support
won't be possible all the same.
08 Oct 2006
Crystal clear waves
Morning: it's time to try the hardware with an external crystal, instead of the software clock
from STK500 at 3.69 MHz. I used one at 16 MHz to do some fine measurements. The SPI
interface is working at 1 MHz (divider = 16) and Timer 1 runs at 2 MHz (divider = 8).
Using the crystal I measured the frequency of 0x30 TAP pulses generated by my firmware/hardware
as having a frequency of 2602 Hz, in agreement with what I had expected. It's now closer to the
value it should have to be successfully read by a real C64.
A CBM ROM short pulse generated by the firmware with a 16 MHz crystal as clock source
A Biturbo tape was entirely PLAYed from the SD Card with no buffer overrun problems (in which
case the firmware would have warned me by printing a message to the serial interface).
Look at the following picture:
A BITURBO file being read from the SD Card
Afternoon: the output was saved to an audio file and is available for download as an mp3 file here. The following image refers to this
file.
In turn we can see the following CBM ROM pulses: (s, m), (m, s), (s, m), (l, m), (s, m). They
are, in turn: three bits, then an end-of-byte marker, and finally another bit.
Viewing the mp3 file in GoldWave
All I need now is a C64 to try the PLAY feature. One is on its way to join DC2N.
09 Oct 2006
Faster is sometimes better
Evening: I did a few changes inside the SD Card driver which also let me save 80 bytes about as
side effect.
I also increased the speed for serial communication to 57600 baud. I'm really satisfied about
serial transfer speed. No trasmission error occurred while sending a TAP to the SD Card.
11 Oct 2006
Finally It is here
Evening: A C64 is here for testing the DC2N hardware/firmware. I'm waiting for a 1084S monitor
and a few cables. Also I'm not wanting to break my only C2N to get the tape port connector, so
I will have to find a way to connect my hardware to the C64.
12 Oct 2006
Adding a save LED improves interaction
Evening: the SPI interface divider was decreased to 4 (SPI clock frequency is now 4 MHz) and
read operations are even faster than I had expected.
The save LED was put in place and used to check card access times. No problems met.
14 Oct 2006
16-bit TAP files, really?
Morning: Time to make the LCD show the current state of the state machine "DC2N SD Card test
suite" implements. DC2N won't require the serial connection to a PC, so the LCD will be the
preferred machine-to-man interface.
I've also been studying for the DC2N TAP dumping (same as MTap) and writing (same as C2N record)
features. Don't forget about the fact the DC2N will also be an alternative way to produce TAP files
from tapes.
Actually I'm wanting to produce 16-bit TAP files which will require a PC tool to be converted to
legacy TAP files. Support for legacy TAP files inside DC2N will come at a later time.
Evening: the first TAP dump operation was done. I saved a 16-bit TAP file to my SD Card by
reading a tape with an original C2N.
The following picture refers to a sector saved to the SD Card, corresponding to the very beginning of the
tape, where CBM ROM pilot is located.
A sector from a 16-bit TAP saved to SD Card
OK, time for some calculations: the counter frequency is 2 MHz, therefore the first pulse, whose
length in counter cycles is 0x0303, has a duration of:
length
duration = --------------- = 385.5 us => freq = 2594 Hz, TAP value = 0x2F
counter freq.
That's in total agreement with what one would expect :)
Well, let's move on and check what's after the CBM ROM pilot sequence:
Another sector from a 16-bit TAP saved to SD Card
Interesting, isn't it? Let's see what we got here in terms of CBM ROM pulses:
16-bit TAP: ... 0317, 030D, 03E8, 033B, 03E8, 0349, 03D3, 0346, 040F, 041E, 0341, 03F4, 033C, 050A, 0453 ...
Legacy TAP: ... 31, 31, 3E, 33, 3E, 34, 3C, 34, 40, 41, 33, 3E, 33, 4F, 44 ...
CBM ROM pulses: ... s), (s,m), (s,m), (s,m), (s,m), (m,s), (m,s), (l,m), ...
Basically, we have: 7 bits followed by an end-of-byte marker, then 8 bits + parity bit + marker,
and so on...
Yes, it's probably the first 16-bit TAP dump you see, and it was done using "DC2N SD Card test
suite".
15 Oct 2006
Forgetting about MS-DOS and FAT-32 partitions on your PC
Morning: a few progresses with the FAT-16 support. I decided it will be as full as possible.
Hopefully, there won't be any need to have unfragmented files on the SD Card.
When everything will be in place, one will be able to read any newly dumped TAP file from the SD Card
with a common card reader, browsing its FAT-16 filesystem. No OS/filesystem restrictions anymore for those
wanting to dump their tapes.
No Card reader? Me neither! No matter, the PC "dc2ndump" tool will be able to receive files
from the SD Card used with DC2N, through the serial interface (which I've got).
18 Oct 2006
Fully equipped
Evening: Finally I inserted the DC-DC converter inside the circuit, to power the SD Card. I have
been using the STK500 AREF output before, set at 3.3 V in AVR Studio (it's generated by a PWM circuit).
Times are mature for building a prototype now. I will work at that during the next weekend.
19 Oct 2006
A new branch is born
Evening: I decided to make a specific test suite to test the FAT-16 support: "DC2N
FAT-16 Test Suite". Eventually, the two branches will be merged.
21 Oct 2006
Tellin' 'bout a daydream of mine
Morning: As far as I know, the monitor I bought was not yet sent to me. Since I cannot
try the DC2N PLAY feature without one of those, I decided to work at the dumping feature while
waiting for it.
The first ever dumped 16-bit TAP file was transferred to my laptop through the serial interface
using my new PC tool "dc2nrec" in conjunction with "DC2N SD Card test
suite".
DC2N TAP record utility output
The 16-bit TAP file is now available for download here.
I also coded a PC conversion tool to convert DC2N 16-bit TAP files into legacy TAP files. Here
there's its output:
DC2N TAP conversion utility output
The legacy TAP v1 file I produced from my 16-bit dump is available for download here. Yes, it is.
The TAP contents are the CBM ROM files of a cheap tape I received together with my C64. If I
try to run TAPClean on it, I see some of the CBM files are correctly read and decoded.
One file doesn't even have any read/checksum error. The other files show read errors.
Well, I think it's not too bad for an ancient cheap tape that doesn't even load anymore to that
point on a real C64. Eventually, I will manually fix the TAP file and discover what's supposed to
be there :)
Part of the TAPMoni output for the TAP file I produced
By inspecting the dumps with my hex editor and with TAPMoni I realize that the main part of
the errors is caused by stretched pulses (eg. 0x39/0x3A instead of 0x36), which should not be
caused by DC2N itself, where a hardware timer is used in conjunction with a hardware interrupt.
Besides:
- multiple dumps from the same tape show errors always at the same offsets (always the
very same 3981 read errors in TAPClean), and
- the file that hadn't read/checksum errors in
the first dump hasn't any in subsequent dumps neither.
Technically speaking, I think the DC2N dump feature is properly working. I wish I had some
brilliant quality tapes here to test it again.
Wait a second! That's what DC2N beta-testers are
supposed to have ;-)
23 Oct 2006
A few discoveries
Evening: I gave a look at the chip45boot boot loader. It's
exactly what I was thinking of to let users upgrade the DC2N firmware without any expensive/hard to
find programmer!
I tested my SD Card driver with a 256MB SD Card by "Lexar Media" I had borrowed from my cousin. No
issue found.
24 Oct 2006
Fixing things
Evening: While developing a multiplatform version of dc2nconv, I fixed an error that occurred
when writing long pulses in a TAP v1 file. The firs two MSB were always 0xFF in the output file.
The newly generated legacy TAP v1 file took the place
of the old one.
26 Oct 2006
Arranging a new format
Evening: A new TAP format was designed. DC2N write/dump operations will support this new
TAP format (16-bit counter resolution at 2MHz) and a slightly customized 8-bit TAP one.
Among the new TAP header fields there are:
- 1 byte: hardware counter resolution [bit]
- 8 bytes: counter rate [Hz]
The "dc2nconv" tool was changed so that it doesn't join long pulses automatically anymore.
It will support the new TAP format as soon as I'm ready to dump some more tapes again.
27 Oct 2006
Stuff coming in
Evening: finally I received the C= 1084 monitor. Unfortunately there was a problem with the
cables I bought to connect it to my C64: I gave a wrong address number to the guy who sent them. I
will have to wait a bit more than expected.
My C= 1084 Monitor to test the DC2N PLAY feature
The USB SD Card reader I ordered is not here neither, so I cannot do big progresses with the FAT-16
support yet.
Anyway, I bought a Kingston SD Card (1 GB) and it works with my card driver as well.
28 Oct 2006
Progresses
Morning: A few more progresses with the FAT-16 support (read). I'm now able to
list the root folder contents:
Listing the contents of a FAT-16 root folder
I also got some nice pictures of the actual hardware. The pictures were taken with my cousin's
digital camera and, unfortunately, he forgot to hand me the USB cable to connect the camera to
my laptop.
Erm, wait! I told I don't need any card reader/USB cable before. I can transfer everything by
using "dc2nrec" through my serial port! Yes, a few pictures were transferred from my
SD Card to my laptop that way. Among them, there's a shot of the prototype I worked at a few
days ago. Here it is:
Study for the very first DC2N prototype
31 Oct 2006
Delay
Evening: I fixed an issue with the PLAY feature. The mp3 file I recorded before was updated with
a new capture. It's available here.
The TAP I PLAYed is a legacy TAP v0 one and the overflow pulses (0x00s) are not yet handled as they
should, but that's something that will come at a later time.
TAP v0 0x00s must not produce square waves. 0x00 means that, during the tape dump process, the
counter used to measure the length of pulses expired (that's the reason it's named "overflow pulse").
So that, when a 0x00 is met in a TAP v0 we must not generate edges for a certain amount of
time and go on like this until a non-zero pulse comes in. After the first non-zero value, the normal
behaviour (generation of square waves) applies again, unless of course a 0x00 follows.
I think this is not how emulators actually deal with TAP v0 overflow pulses, and it should be corrected
if anyone still cares. Besides, once we realize this, we see there's not any reason to prefer TAP v1 to TAP
v0, except, maybe, the confusion generated by the overflow value behind 0x00. Of course it must represent
the overflow value of the counter used to generate TAP files by the creator of this format.
In DC2N 16-bit dumps the overflow value is 0xFFFF because I use a 16-bit counter with 0xFFFF as TOP
value. Since its frequency is 2 MHz, an overflow means there was no edge during the last 0xFFFF/2000000 =
0.0327675 seconds. It doesn't mean the last pulse has a duration of 0.0327675 seconds.
When converting a 16-bit TAP file to a legacy TAP v1 with "dc2nconv", the overflow value is not
immediately converted, but subsequent overflow values are joined together, up to the first non-overflow value
(included). The sum of those values is the time elapsed (in clock cycles) between two consecutive negative
edges. No edge occurrs within two or more overflow values.
I was happy to see MTap correctly handles this conversion, even if the source code is a bit misdirecting the
reader.
I report here a snippet of the code "dc2nconv" uses to convert 16-bit counter values to TAP file
pulses. It's working the same way as MTap. MTap is more clever, but I think "dc2nconv" can be read
much more easily:
By the way, MTap has the capability to save a 16-bit TAP to be used by "dc2n conv" at a
later time. MTap has to store the measured LPT polling frequency inside the 16-bit TAP header as
"counter rate".
An interesting question is: which sort of timer was the TAP v0 format author using to dump tapes? A
16-bit one, probably. But that's not enough: we should know its frequency and the TOP value. A counter's TOP
value is not necessarily its MAX value.
<- Previous Month Next Month ->
Comers since area creation: 
- Best viewed at 1024x768
All images, files, and text on this page are Copyright ©2006 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.
