Re: New firmware for PLC TIB DD-001 3.5" drive

On Wed, Aug 16, 2023 at 5:40 PM <ruud_at_baltissen.org> wrote:

> Witam Maciej,
>
> Cześć!

(disk change signal)

> but I couldn't find it. OK, a part hadn't been disabled yet but
> filtering bit 7 shouldn't have been easy to miss.
>
> So my question: have you run into a check of these pins?
>

No, it's not used by the software for anything.
For high-level operations (LOAD, SAVE, scratch, rename) directory or FAT is
always loaded before use, so it's stateless.

seconds of the last one, the ID of the drive was checked. I haven't
> found anything (yet) that looks like a check but there must be
> something, if it was just a read of the floppy for the very forst time.
>

I read somewhere that the volume serial number from boot sector was also
used to recognize the disk change, so I modified format procedure to
randomize it.

Here are some (new) notes I put in my own disassembly:
> ; - only a 3,5" 720 KB DD FDD can be used, not a 5.25" 360 KB one
> ;   ##### can that be changed?
>

I think so. Apart from possibly different settings for controller (data
rate?) it needs different mapping of FAT clusters into tracks & sectors,
but that could be done.

; - only ONE drive can be used
> ;   ##### can that be changed?    ---> you already mentioned using a
> jumper, but what about software?
>

I can't test it on my cartridge. It seems that we need to use drive select
(unit select) bits from operations register and map C= device 7 to unit 0,
device 6 to unit 1 or something like that. That would be sent to controller
together with track/sector/head parameters before any I/O operation.
Can we access operations register with current hardware? I'm not sure
without going back to schematic and datasheet.

; - a directory sector is stored in the RAM under the $Dxxx area
> ;   ##### what about loading big programs, won't they overwrite things?
>

Yes, they will. Right now only loads up to $D1FF (or above that work area)
will work because of that.
During LOAD the firmware goes back to FAT buffered in this area to get the
number of next needed cluster.

That's something on my list to be improved, because we don't need the whole
FAT once the file was found.
We only need from FAT the list of clusters (up to 128 bytes) where file
data was and that can be stored somewhere safe in low memory area during
LOAD.

; - Some RS232 variables are used, meaning: we cannot use RS 232
> anymores
> ;   2023-08-09: ??? which ones?
> ;   ##### if so, what about using more tape variable etc.?
>

Yes, I reorganized this a lot and moved more stuff into locations used by
tape or temporary BASIC area on zero page.
I replaced "TapeBuffer+<offset>" labels with more meaningful names, mostly
recovered from scans of original documentation. They can be now freely
relocated as we wish.
Some of these locations are used by one function only (like 5 bytes
allocated for disk format routine) that could be shared with other
procedures.

; - bad: I/O port of 6510 is manipulated but not restored with original
> value
> ; - bad: video control register is manipulated and not restored
> ; - inconsistent use of Carry for reporting an error
>

Yes. Without going through the code and carefully documenting every
procedure I just don't know what is the expected environment. Does this
function need interrupts or screen enabled or disabled? Do I need to
initialize controller beforehand? How about the read/write procedures in
the stack area? Totally not clear. On the high level it works fine, the
problems start if you want to read or write a single sector.

Of course I thought about some improved hardware with extra RAM but,
> let's face, who will be waiting for it?
>

True, I keep thinking about this. I wish this device hadn't been such a
failed product in the past.
It's fast. It is simple, probably cheap to make even back then, and cheap
to use.
Someone could have cloned it and sold pirated versions. It could have
played the role of something like SD2IEC in the late 90s/early 2000s.

ytm