[CSDb] - User Forums - Release id #197710 : Transwarp v0.64

You are not logged in - nap

CSDb User Forums

Forums > CSDb Entries > Release id #197710 : Transwarp v0.64

2020-11-22 17:12

Krill

Registered: Apr 2002
Posts: 2982

Release id #197710 : Transwarp v0.64

General Q&A thread, also report problems and error logs here.

... 162 posts hidden. Click here to view all posts....

2020-12-14 22:36

Krill

Registered: Apr 2002
Posts: 2982

Quoting Oswald

transfering while stepping track, awesome idea :) remembers me when I tried to "stream" load vector anim, and it always stopped for track stepping haha.

I think stepping itself is not to blame for the hiccup. =)

The normal* stepping duration in Transwarp is $90 (144) bycles, that's a fifth (18%) of a revolution, or 4 sectors. So for a regular interleave 4 loader, that means just one missed block. Plus they would use shorter stepping times, usually around $30-$40 bycles. (The $90 setting was determined experimentally, it was the safest setting across all test drives.)

However, the loader you used probably did not load blocks out of order, and then the mean waiting time for a block after trackstep is half a revolution, a tenth of a second, and the worst case double that time.

* With secondary addresses >= 2, the track step times for either or both half-track steps can be increased for drives with particularly long settle times or slow steppers, in order to counter stepping-related loading problems.
Bits 3..1 increase the overall stepping time: +2 = $a0, +4 = $b0, +6 = $c0, ..., +14 = $0100 bycles.
Bits 7..4 increase the time between first and second half-track step: +16, +32 etc. would shift the relation further towards the overall stepping time.
So loading a Transwarp file with ,8,255 would be pretty slow. =)

Having the secondary address take on more meanings than just loading to BASIC start or saved address, i was slightly dismayed to see BiGFoot use ,8,8 out of an old learned habit. =D

2020-12-14 22:45

Count Zero

Registered: Jan 2003
Posts: 1940

https://codebase64.org/feed.php

Tap tap tap ... oh, thats the sound of my drive sometimes recently - not the frequency of your codebase submissions! :)

2020-12-15 05:00

ChristopherJam

Registered: Aug 2004
Posts: 1409

load ,8,8

considered harmful!?

2020-12-15 09:15

Krill

Registered: Apr 2002
Posts: 2982

Quoting ChristopherJam

load ,8,8
considered harmful!?

Nah, can be considered wholesome, but only if you have a rather wonky drive that would give you retries (transient read errors) and slowdowns (missed blocks) after stepping with the default settings. =)

Otherwise just an unnecessary throttle.

2020-12-17 10:27

Krill

Registered: Apr 2002
Posts: 2982

A few words about the encoding scheme.

As is easy to see, it works with plain d64 images, effectively storing 224 bytes of data in a standard Commodore GCR disk block.
Also, attentive readers of the source might have noticed that just a single decoding table of $ae bytes with $69 entries ($45 spare gap bytes) is used.

Here's how it works:

Commodore GCR encodes 4 bit raw nibbles to 5 bits on disk, or 4 bytes raw to 5 bytes on disk.
Enumerating all possible values these 5 bytes can take, we get:

11111111 11222222 22223333 33333344 44444444
  $60      $60      $79      $60      $60

That's about 6.58 bits of entropy for the 4 outer GCR bytes each, and 6.92 for the middle GCR byte.
However, the possible values the bytes may have are determined by their predecessor (except the first byte).
After "decorrelating" these 5 sets of values, we are left with

11111111 11222222 22223333 33333344 44444444
  $40      $60      $19      $60      $40
   6       6.58     4.64     6.58      6

So we can store 6 + 6 + 4 + 6 + 6 = 28 bits of data without interdependencies of the individual 5 GCR bytes in the same space where Commodore GCR encodes 32 bits.

When combining these reduced sets of possible values for all 5 GCR bytes, we get a

heat map:
00: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- 08 08 08 -- 08 08 08 -- 08 08 08
30: -- -- -- -- -- 08 08 08 -- 08 08 08 -- 08 08 08
40: -- -- -- -- -- -- -- -- -- 18 19 19 -- 19 19 18
50: -- -- 13 13 02 1b 1b 1a -- 18 1b 1b 02 1b 1b 0a
60: -- -- -- -- 02 0a 0a 0a -- 18 1b 1b 02 1b 1b 1a
70: -- -- 13 13 02 1b 1b 1a -- 18 1b 1b 02 13 11 --
80: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
90: -- -- 03 03 02 07 03 06 -- 04 03 07 02 07 03 02
a0: -- -- -- -- 02 0e 0a 0e -- 1c 1b 1f 02 1f 1b 1a
b0: -- -- 13 13 02 1f 1b 1e -- 1c 1b 1f 02 1f 19 08
c0: -- -- -- -- -- -- -- -- -- 18 19 19 -- 19 19 18
d0: -- -- 13 13 02 1f 1b 1e -- 1c 1b 1f 02 1f 1b 0a
e0: -- -- -- -- 02 0e 0a 0e -- 0c 0b 0f 02 0f 0b 0a
f0: -- -- 03 03 02 0b 0b 0a -- 08 0a 0a 02 02 -- --
length 0xd9, offset 0x25, used 0x8a, density 63.6%, unique 0x0d
longest gap 0x13, gap space 0x2a

The byte values here are just a bitfield to show which of the 5 GCR bytes may take on the index value.

Now, it takes a bit of trial and error for carefully picking 6-bit values to assign to each byte in a table like this, such that:
- each of the 4 outer GCR bytes can reach all 6-bit values from $00 to $3f
- the middle GCR byte can reach all 4-bit values from $00 to $0f.

There are many possible variations to satisfy these constraints, and the final decoding table can also be somewhat smaller than the heat map, as there are more than $40 value bytes to choose from across all 5 GCR bytes. So secondary goals are:
- minimise table size
- maximise gap space to stuff with code and data.

2020-12-17 12:37

Oswald

Registered: Apr 2002
Posts: 5095

still trying to understand this, after 10 minutes I understood what you mean in the first part by bit entropies but still not understanding how your table works. how do you encode data into krill gcr ?

2020-12-17 12:56

Krill

Registered: Apr 2002
Posts: 2982

Quoting Oswald

how do you encode data into krill gcr ?

There are 5 different encoding tables for the 5 GCR bytes. 4 of them have $40 entries, 1 of them has $10 entries.

These encoding tables map raw 4- or 6-bit values to encoded GCR bytes.

The constraint is that an encoded GCR byte must map to exactly one decoded value for all 5 GCR bytes (in order to use just one single decoding table). Luckily, the values in the decoding table need not be unique, as in the same value may appear in multiple slots.

E.g., a specific GCR byte value may appear for the first GCR byte but is impossible for the fifth, and vice versa. Those two specific GCR values are allowed to decode to the same raw value, however.

2020-12-17 21:01

Oswald

Registered: Apr 2002
Posts: 5095

*processing*

2020-12-17 21:34

Krill

Registered: Apr 2002
Posts: 2982

Not sure where i've lost you. 8-bit GCR value goes into table, 6 bits come out, 1 out of 5 times, 4 bits come out. Repeat. =)

2020-12-17 23:09

Oswald

Registered: Apr 2002
Posts: 5095

fex: "The constraint is that an encoded GCR byte must map to exactly one decoded value for all 5 GCR bytes"

Previous - 1 | ... | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | ... | 18 - Next

Refresh

Subscribe to this thread:

You need to be logged in to post in the forum.

Search the forum:
Search for in
All times are CET.

Search CSDb

Advanced

Users Online

Bitbreaker/Performers
New Design/Excess
MWR/Visdom
cobbpg
mutetus/Ald ^ Ons
blitzed
Flashback
zbych
Walt/Bonzai
Da Snake
Zardax/Artline Designs
JEZ
Guests online: 105

Top Demos

1 Next Level  (9.7)
2 13:37  (9.7)
3 Coma Light 13  (9.6)
4 Edge of Disgrace  (9.6)
5 Mojo  (9.6)
6 Uncensored  (9.6)
7 The Demo Coder  (9.6)
8 Comaland 100%  (9.6)
9 What Is The Matrix 2  (9.6)
10 Wonderland XIV  (9.5)

Top onefile Demos

1 Layers  (9.7)
2 Cubic Dream  (9.6)
3 Party Elk 2  (9.6)
4 Copper Booze  (9.6)
5 Dawnfall V1.1  (9.5)
6 Rainbow Connection  (9.5)
7 Morph  (9.5)
8 Libertongo  (9.5)
9 Onscreen 5k  (9.5)
10 It's More Fun to Com..  (9.5)

Top Groups

1 Booze Design  (9.3)
2 Oxyron  (9.3)
3 Performers  (9.3)
4 Triad  (9.3)
5 Censor Design  (9.3)

Top Coders

1 Axis  (9.8)
2 Sailor  (9.8)
3 Graham  (9.8)
4 Lft  (9.8)
5 Crossbow  (9.8)

Page generated in: 0.068 sec.