ruud.baltissen_at_abp.nl
Date: 2006-06-09 14:21:22
Hallo allemaal,
I want to share some ideas with you how I think the PC should be programmed. And if interested, you can discuss them with me.
For those who are not familiar with PC-Flop:
The 1541 is in fact just a little computer with an onboard drive. Only one IC, a 6522, controls _all_ operations regarding the drive. So the idea rose to replace all the electronic and mechanical parts behind the 6522 with a computer so one doesn't need to use floppies anymore.
The connections:
6522 LPT
Name Meaning pin name pin
---- ------- --- ---------- ---
PA0 2 D0 2
. .
. .
PA7 9 D7 9
CA1 BRDY 40 Strobe 1 (O)
PB7 SYNC 17 Initialise 16 (O)
PB4 WPE 14 Auto feed 14 (O)
PB0 Stp1 10 Select 13 (I)
PB1 Stp0 11 Paper out 12 (I)
PB2 Mtr 12 Acknowl. 10 (I)
CB2 Mode 19 Busy 11 (I)
CA2 SOE 39 Error 15 (I)
The first idea is that the 1541 can only operate in two modes: the motor is running or it is not. If the motor isn't running, no special attention of the PC is needed. Therefor this is the time the user can perform his own operations like 'changing' a disk.
When the motor is running, there are two situations: the drive is stepping the head or it isn't. If it is, the pointer to RAM containing the data has to be changed.
If the head is not stepping then again there are two situations: the drive is reading or the drive is writing. But whatever the drive is doing, during this action the interrupts of the PC should be disabled.
The next part most probably will arise the majority of questions, remarks etc.
You probably already noticed that two signals are missing: the bitrate signals. The 1541 needs them for a technical reason. The speed under the head near the middle of the floppy disk is slower then the one of the surface near the outside of the disk. There has to be a certain gap between each bit of a track. A faster speed means we can write the bits faster to the disk and make optimal use a track. For this reason the first track contain 21 sectors and the ones near the middle of the disk only 17. The bitrate mechanism takes care of this.
I once calculated (IIRC) that at the highest bitrate, the bytes arrive at about 27 uSecs interval and at the lowest speed at 32 uSecs interval. Some years ago I thought I had to emulate these intervals as well. And lacking enough input ports, I decided to set the interval using software.
But because of the 1541LPT project I found out that, beside stting the interval, the 1541 doesn't do anything at all with it except it just waits for the 'Byte Ready' signal and then reads/writes the next byte. So IMHO I don't have to emulate these intervals at all.
What happens if you use another bitrate then the original one for a certain track? You'll get read errors. You can make it worse by using different bitrates on different intervals of the track. What programs would do that? IMHO only programs in need of a copy protection. Does this type of protection affect my project? I first thought 'no' but a remark of Wolfgang changed my mind.
Consider a program that only changes the bitrate and for the rest does nothing. A copier (or whatever) reading the track of a floppy with the original bitrate will run in trouble sooner or later. But PC-Flop will record the byte given the moment it outputs the 'Byte Ready' signal which on its turn is outputted WHEN IT SUIT PC-FLOP! Same with reading the data again.
But what if a program counts the cycles between two bytes? Then I must admit that I'm in trouble. But then my counter remarks are:
- what copy program is able to detect this kind of copy protection?
- this means I have to remember the bitrate setting of every part of the track some how. I that worth the effort and trouble?
Not being able to cope with this specific copy protection, I realise that I loose compatibility of course. But how much compatibility? Or better, how many programs won't run?
Thanks for your input!
--
___
/ __|__
/ / |_/ Groetjes, Ruud
\ \__|_\
\___| URL: Ruud.C64.org
=====DISCLAIMER=================================================================
De informatie in dit e-mailbericht is vertrouwelijk en uitsluitend bestemd voor de geadresseerde. Wanneer u dit bericht per abuis ontvangt, verzoeken wij u contact op te nemen met de afzender per kerende e-mail. Verder verzoeken wij u in dat geval dit e-mailbericht te vernietigen en de inhoud ervan aan niemand openbaar te maken. Wij aanvaarden geen aansprakelijkheid voor onjuiste, onvolledige dan wel ontijdige overbrenging van de inhoud van een verzonden e-mailbericht, noch voor daarbij overgebrachte virussen.
The information contained in this e-mail is confidential and may be privileged. It may be read, copied and used only by the intended recipient. If you have received it in error, please contact the sender immediately by return e-mail; please delete in this case the e-mail and do not disclose its contents to any person. We don't accept liability for any errors, omissions, delays of receipt or viruses in the contents of this message which arise as a result of e-mail transmission.
Message was sent through the cbm-hackers mailing list
Archive generated by hypermail pre-2.1.8.