KryoFlux Java Library

[Feltzkrone]

I'd like to inform you that Daniel Jameson has started developing a KryoFlux Java Library called KryoTools.

It was created because of the need to produce APD image files for dumped Acorn disks. That format is capable of representing protected disks at a level comparable to what G64 does store for C64 disks but unluckily there is no official file format description for it. Although the library which is inspired by keirf's work is not at a stage which can be called stable or mature, it is a first start to work with STREAM files in Java and I'm sure that Daniel will appreciate any form of contribution.

If you are interested, please take a look at the original thread in the stardot.org forums where you will also find a link to the source hosted on Github:
http://stardot.org.uk/forums/viewtopic.php?f=12&t=6020

[drdanj]

Hello,
that's me

There's a description of the APD format as I have it in the "APDWriter" class. APD was designed to capture all the information necessary to allow emulators to deal with protected ADFS discs on the archimedes/riscpc. In its original incarnation by Tom Walker APDs were generated using the output from rawread on the amiga, this was then transferred across to a PC and parsed as sd, dd and qd (at least as I understand it) and combined into a single file with an index structure for the tracks. The APDs I've been generating from mfm encoded disks have been (touch wood) fine, just a few issues with some where there are interdispersed FM encoded tracks with nested sectors. We are looking into whether that's just a misunderstanding of the format though.

All input welcome. The library itself is very definitely "academic grade".

d.

[mr.vince]

Nice! I'd like to address one thing, just to clarify: if we could we would be supporting all systems at once. But since we are all fully employed and KF and Softpres is neither full time, nor paid for business (in terms of a regular job), we need to define goals for the short and long term.

Keep up the good work.

[drdanj]

Oh, indeed, absolutely understood, hence me not bugging and just getting on with it - it's not particularly fair to demand format x or y when it's clear that there's a plan that's being followed by people who are only doing something in their spare time. Everyone has their favourite thing they'd like to see supported but you can't please everyone instantly.

d.

[drdanj]

Hello,
This is progressing quite nicely (apart from the ugly code at the moment), but I've been having a bit of consternation with some tracks that are mixed MFM/FM and also FM. Would someone be able to take a quick look at the dump of a single track for me and double check that I'm correct when I think there's a write splice in two of the FM sectors? This is a protection track, half MFM, half FM with nested sectors in the FM section...

If so, let me know where to stick the raw file for that track.

Many thanks

Daniel.

[Feltzkrone]

If so, let me know where to stick the raw file for that track.

PM sent.

Edit: And I'd like to help you getting rid of ugly code as soon as possible, but currently I'm busy with quick insight and organizing a bunch dumps made on behalf someone else. I guess some class(es) dealing with bit-level data representation and operations would be helpful as a first step.

[drdanj]

[
PM sent.

Edit: And I'd like to help you getting rid of ugly code as soon as possible, but currently I'm busy with quick insight and organizing a bunch dumps made on behalf someone else. I guess some class(es) dealing with bit-level data representation and operations would be helpful as a first step.

Thanks. And yes . It's very "academic" quality, as in "just make the bloody thing work". I've been torn in different directions for representations of things basically because of the lack of unsigned primitives, integers being massive, booleans probably being stupid etc etc . It's a proper mish-mash, but it really does need sanitising. I freely confess to not being a trained java programmer, more an academic java hacker!

d.