SRQ/Fast Serial Support

[Pete Rittwage]

I see that there was discussion years ago about this, and it seemed to be
implemented, but never became official?

http://www.commodore128.org/index.php?PHPSESSID=63fd18173ac6cb3be54787003e493d2f&topic=3739.25

Does anyone have a binary merged with 10.3 with fast-serial support, or
easy directions how to compile changes?

I have an original uIEC/CF, if that makes a difference. I thought I
understood from previous conversations that it may work with my old
device, but NOT the newer SD-version?

-
Pete Rittwage

[Ingo Korb]

"Pete Rittwage" <pe...@rittwage.com> writes:

> I see that there was discussion years ago about this, and it seemed to be
> implemented, but never became official?

There is a "minor" problem: I don't think it is possible to implement
fast serial on the existing hardware without opening the possibility for
data corruption or throwing out major pieces of functionality.

Background:
CP/M for the C128 assumes that a drive that is not fast-serial-capable
is always a 1541. I'm currently not sure if it will still read
double-sided 1571 disks in this mode, but at least for the 1581 the CP/M
disk format differs enough from the 1541 format that the computer will
read and/or write to completely wrong locations when it accesses the
directory, resulting in a corruption on writes if the drive misses a
fast serial capability check.

The check for this capability is built into the standard protocol:
Before starting the normal serial protocol to select a specific drive on
the bus, a single byte is sent over the fast serial connection - that
means the drive must always be able to receive this byte without any
prior warning. This is easy to do with a hardware shift register, but
there is none available for this job on any hardware that runs
sd2iec.

If the shift register is emulated in software, the data from the
bus must be read at most three microseconds after the clock edge to
ensure it is still valid. This is possible on the current hardware only
if the CPU is fully dedicated to the job with no other interrupts
interfering. As noted above, from the drive's point of view the fast
serial detection happens without warning, so the CPU would need to poll
for the fast serial data in the place where it is currently just
idling.

Disabling all interrupts at this point would also disable the regular
timer interrupt which is responsible for things like the LED blinking on
errors and checking the buttons used for disk swaps. Not disabling the
timer interrupt could result in a missed fast serial check from the
computer, which in turn would result in CP/M detecting the drive as a
1541 and possibly corrupting a D81 image file. I really do not want
features in the code that come with an unavoidable chance of corrupting
data - IIRC I calculated the probability of missing the fast serial
check at about 0.5% of all drive accesses.

Things would be much easier with either some external hardware that
implements the shift register and signals a received byte to the CPU
which can then read it with much more relaxed real-time
constraints. Another possibility would be to use a CPU with multiple
interrupt priorities, e.g. a Cortex M3. On that CPU the fast serial
clock line could be connected to an interrupt-capable input and the
priority of this interrupt can be set to the highest level so it would
run even when the timer interrupt is currently active.

On the AVR simulating the second approach by re-enabling interrupts at
the beginning of the timer interrupt still wouldn't work because at 8MHz
the additional worst-case latency for the second interrupt would still
be too much. It might be possible at 16MHz, but this wouldn't help
existing users either and part of the code base is cycle-counted
assembly built for 8MHz. That's a large effort for a feature that only a
very small number of people would ever use.

TL,DR: Unavoidable data corruption if enabled, few people need it

Oh, and quite a few sd2iec-based devices don't even bother to connect
the SRQ line to the AVR (two I remember off-hand: C64SD infinity, 1564).

-ik

[silv...@wfmh.org.pl]

On 2013-05-10, at 20:53, Ingo Korb wrote:

> "Pete Rittwage" <pe...@rittwage.com> writes:
>
>> I see that there was discussion years ago about this, and it seemed to be
>> implemented, but never became official?
>

> [...]
>
> TL,DR:

SLBGR! [*] Thanks!

--
SD!


* - Suprprisingly Long But Great Read!

[Pete Rittwage]

That's unfortunate. I thought it might be a nice license-free (and
slightly faster) alternative to the Jiffy protocol.

So I understand completely- the bug is only seen with CP/M, because it
sends this byte, gets no acknowledge (because we aren't or can't look for
it) and assumes it is a 1541 drive? So the D81 can become corrupted on
writing because it mistakenly believes the drive is a 1541?

CP/M on the 64 or 128? Does anyone *really* use that? :)

-Pete

> --
> You received this message because you are subscribed to the Google Groups
> "�IEC Users Discussion Group" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to uIEC-users+...@googlegroups.com.
> To post to this group, send email to uIEC-...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

[geneb]

On Sat, 11 May 2013, Pete Rittwage wrote:

>
> CP/M on the 64 or 128? Does anyone *really* use that? :)

I think it would be really great to be able to use CP/M 3.0 on the 128
with the uIEC. There is an astonishing amount of CP/M software out there
and it works great on the 128.

g.


--
Proud owner of F-15C 80-0007
http://www.f15sim.com - The only one of its kind.
http://www.diy-cockpits.org/coll - Go Collimated or Go Home.
Some people collect things for a hobby. Geeks collect hobbies.

ScarletDME - The red hot Data Management Environment
A Multi-Value database for the masses, not the classes.
http://www.scarletdme.org - Get it _today_!

[silv...@wfmh.org.pl]

> CP/M on the 64 or 128? Does anyone *really* use that? :)

On a 64 - no. Unless by "use" you mean trying to boot it once in a blue moon ;-)

On a 128 - yes.

--
SD!

[Terry Raymond]

Hey guys wow I think I might have CP/M on an original disk,

So are these new patches to make CPM bootable on SD2uiec ?

I think I booted CPM once on my 128 but I could never find much other software

Written for CPM.  If there is support for SD2uiec I might try it out

On my 128DCR's.

I have the earlier CF& IDE uiec would this work with CPM and other software, I assume

Only image files are supported, Wish would work with stand alone files.

Terry Raymond

--
You received this message because you are subscribed to the Google Groups "µIEC Users Discussion Group" group.

[Ingo Korb]

Terry Raymond <traym...@gmail.com> writes:

> Hey guys wow I think I might have CP/M on an original disk,
> So are these new patches to make CPM bootable on SD2uiec ?

You don't need any patches to boot CP/M from sd2iec if you use a D64 or
D71 image.

-ik

[Ingo Korb]

"Pete Rittwage" <pe...@rittwage.com> writes:

> So I understand completely- the bug is only seen with CP/M, because it
> sends this byte, gets no acknowledge (because we aren't or can't look for
> it) and assumes it is a 1541 drive?

I've just checked the sources again - if the drive does not use fast
serial, it can never be detected as a 1581 by CP/M because it uses the
sector size bits from the fast serial status word to decide if it's
talking to a 1541/71 or a 1581 (let's ignore MFM disks in a 1571 for
now...).

> So the D81 can become corrupted on
> writing because it mistakenly believes the drive is a 1541?

Yes - in this situation CP/M should try read track 1 sector 0 to check
if it starts with "CPM" to decide between the old C64 CP/M format and
the higher-capacity C128 variations. Since the 1581 CP/M disks use a
small auto-boot program to redirect the boot sector to track 40, there
won't be a CBM signature in this sector, so the system assumes a C64
CP/M disk.

From CP/M's point of view such a disk uses 256 byte sectors and reserves
the first two tracks for the system. Allocation units are 1K, the
directory has 64 entries. The 1581 CP/M format uses 512 byte sectors, no
reserved tracks, 2K allocation units and 128 directory entries. Any
write to the directory of the misdetected disk would write somewhere
into the data area of the D81 image, reading the directory would return
random data.

> CP/M on the 64 or 128? Does anyone *really* use that? :)

I don't think there is anything else that absolutely requires burst mode
to work (only for D81 images in case of CP/M) and that is the only
reason why I would consider adding so much "mostly dead" code to the
firmware.

If there is other C128 software out there that doesn't work with a drive
that does not support fast serial mode(*) it is possible that it could
also suffer from problems when the drive randomly decides to not support
fast serial mode for the current access.

-ik
(*) ignoring foreign disk format tools like Little Red Reader as they
wouldn't be useful with an SD drive