FastBoot/FastLoad on Pravetz 8D/Disk II

[iss]

Apple nibbles are '5+3' for the old 13 sector format, and '6+2' for the 16 sectors format which we are using.
First are read 256 octets, they hold 256 x 6-bit bytes and next 86 octets give additional 2 bits.
I succeeded to fix loading with help of temp 256-bytes buffer without any speed impact!
Here is demo:

Here are image and sources:

fastpic.dsk.zip

(53.21 KiB) Downloaded 37 times

fastpic.src.zip

(2.64 KiB) Downloaded 38 times

[iss]

I've created simple utility which prints the order of sectors in each track. It's based on the loading routine. The sector number is extracted from the address field. I expected to see some interleave but the result shows natural order ... which puzzles me .
In Oricutron:

And with real controller and SDFloppy II, here some 'skew' between tracks is visible:
Here is image and source:

mapper.zip

(3.83 KiB) Downloaded 38 times

Additionally, after an 'archaeological excavation I found a mammoth' - real DISK][ drive - it looks dirty, ugly and heavy .
I'll try to resurrect it and will post the result.

[Scalex]

I think that the "lack" of mechanical parts of the SD floppy (no real disk rotation, no moving of the read-and-write head) tends to smooth the performances.

As for the results of your mapper (btw good job!), I think the Oricutron emulation of the DISK II part explains that. Since there is no emulation of the rotation of the disk, the program "simply" waits for the next sector to be read so we have a perfectly growing order systematically... (OK, this is probably a somewhat simplistic explanation ).
On the other hand, what I do not understand is why we also systematically have sector 0E read for the first track. I launched Oricutron with the mapper several times and always got the same result. Always the same, yes, but why 0E ?!

Btw so far, there was really no need for a sophisticated emulation of the DISK II part in Oricutron since I suppose everything that existed at the time should boot without problems. So my words are not a criticism!

Nevertheless, i would like the opinion of people of this forum: for you, can Oric (/Pravetz) with Disk II (or SD floppy more speficially) be considered as a attractive platform for future development? Are there any advantages over Microdisc or Jasmin?

[ThomH]

I've created simple utility which prints the order of sectors in each track. It's based on the loading routine. The sector number is extracted from the address field. I expected to see some interleave but the result shows natural order ... which puzzles me .

I always try to avoid reading other people's implementations before writing my own but luckily I have just more or less completed my DSK file handling so it felt like an ideal moment to offer a second pair of eyes.

Disk.c seems to count through sectors in ordinarily numerical order, i.e. it'll populate the disk with s_idx 0, then s_idx 1, then s_idx 2, etc. S_idx is the physical sector number.

disk_pravetz.c seems to produce at physical index n:

• a sector that announces itself to be logical sector n;
• but which contains the contents of the on-disk sector located at interleave[n].

So there's no physical interleaving, and now per-track skew.

[iss]

@ThomH: Yep, you are right - there is no physical interleaving on real disks too.

Else bringing the old DISK][ back to life is almost done I'll post pictures/video of the result soon.
I've created small utility for calibration of the rotation speed. It's based on old utility for Apple ][ which I disassembled and extract what I needed. It works very nice and I'll post the image and the sources, but I just realized that may be there is a problem with the routine for time delay (which is from Apple's monitor), because of the difference of the main clock - Oric 1.0MHz vs. Apple 1.0205MHz. This is the original wait code:

Code: Select all

FCA8: 38      WAIT  SEC
FCA9: 48      WAIT2 PHA
FCAA: E9 01   WAIT3 SBC #$01
FCAC: D0 FC         BNE WAIT3 ;1.0204 USEC
FCAE: 68            PLA       ;(13+27/2*A+5/2*A*A)
FCAF: E9 01         SBC #$01
FCB1: D0 F6         BNE WAIT2
FCB3: 60            RTS

[ThomH]

Well, the sneak preview gossip from my emulator is attached. I've not implemented any track skew, but still see the results as attached from your mapper.dsk so is it possible that Oricutron just doesn't preserve disk position when stepping tracks? i.e. each swing of the head magically resets the disk back to the start of the track?

There are a bunch of pitfalls and issues that are going to keep this in development for the time being, but your fast boot disk works properly and I can try NIB and/or WOZ versions if and when it'll be helpful. The emulator attempts proper timing throughout — the Disk II shift register is shifting based on the speed that the disk is spinning, the rotation is independent of the stepping, etc — so if there's anything I can time or anything else I can offer, let me know.