Hard Drive (Default Events) *New* [Anatomy Video]

[lcyGamma]

If it can store data in 8 different states(colors), then it's not storing data in binary. It's storing data in octodecimal, right?

Looked it up, and yeah I think you're right.

This seems pretty cool though, it'll just be hard as hell to translate octodecimal values into decimal ones.

Thanks, and yeah. I'm gonna release a document that lists the timings the hard drive sends information back. You really have peck at what relays you want to acknowledge.

[Ad Bot]

[Jam_Jar]

If it can store data in 8 different states(colors), then it's not storing data in binary. It's storing data in octodecimal, right?

This seems pretty cool though, it'll just be hard as hell to translate octodecimal values into decimal ones.

It's count in Octal. And because of that it makes it quite easy actually to convert from binary to Octal. For example, the binary representation for decimal 83 is 01010011, which can be grouped into (00)1 010 011 – so the octal representation is 123. Do get this you just figure out the 3bit values and concatenate the numbers.

You know how to convert (Deanery > Binary > Octal), but now to go from (Octal > Deanery).
Each place in octal is a power of eight.

123 = 1x8²+2x8¹+3x8⁰

By working this out you can see that 123 is equal to (64 + 16 + 3 = 83) in deanery (decimal base10).

To go from this Deanery to binary is easy, just do it the normal conversion. Each place in binary is a power of 2.
2⁷    2⁶    2⁵    2⁴    2³    2²    2¹    2⁰       - Base Indicie
128  62   32   16    8     4     2     1         - Base Value
0     1     0     1     0     0     1     1         - Binary Example

I'm not sure if it's bad of good. Using octal could be a burden or a really useful tool for sizing down data storage! One octal digit it equal to 3 binary digit so you can see it as being much more efficient in storage terms. The one downfall I could see is if another piece of hardware someone makes uses binary, then it'll need a decoder to convert to and from each base which may slow things down. I still thing having octal is a good thing though :D Lowers the space needed to store large amounts of data which is a bonus and leaves sufficient space for an elegant casing. c:

[lcyGamma]

Indeed, the thinking was if it has several values you get more out of a smaller space.

But I'm no engineer of course lol. Didn't even know what octadecimal was until Seventh mentioned it. :?

[aludane]

Will modifying the case void my warranty? I'm looking for a compact system builder's case so I can have two of these together in my space-station


8⁸ is 16777216, you could implement some cool stuff with this.

[Jam_Jar]

Slightly updated my previous post to explain how it works and it's benefits.
Sounds perfect for the job, Aludane, with the amount of space saving Octal has done :D

In just a single of of these, you could potentially store 5 bytes of data or 40bits, which is not bad for it's space usage.

[SeventhSandwich]

Thanks, and yeah. I'm gonna release a document that lists the timings the hard drive sends information back. You really have peck at what relays you want to acknowledge.

Just a piece of advice if you're gonna make this harddrive communicates through a wire: You should probably change it so that each memory brick stores a value as 1 or 0 (red or green), because otherwise it will be literally impossible to read data from the harddrive.

You could send octal data out using parallel communication, but the little slot on the side of your harddrive isn't big enough for 8 lines of bricks.

[SeventhSandwich]

Lowers the space needed to store large amounts of data which is a bonus and leaves sufficient space for an elegant casing. c:

Yeah, but it'll be impossible to read data from the hard drive.

[lcyGamma]

Its not impossible, it works as I've used it already in tests.

It just requires the builder of a reading device to separate the relays by using events that toggle and wait for relays at given times.

For example:
3 relays sent in 300ms
800ms of nothing
4 relays sent in 400ms
800ms of nothing

(timing is hypothetical for the example)

[SeventhSandwich]

Its not impossible, it works as I've used it already in tests.

It just requires the builder of a reading device to separate the relays by using events that toggle and wait for relays at given times.

For example:
3 relays sent in 300ms
800ms of nothing
4 relays sent in 400ms
800ms of nothing

(timing is hypothetical for the example)

The first demonstration you should add of this harddrive's capabilities is to showcase how well it's reading/writing works.

So first, you should make a device that lets you take a number between 0 and 16777215 (the highest decimal value of 8 bits of octal data) and write it to the harddrive. Then, make another device that reads the data from the harddrive (in octal form, so 00000000 to 77777777) and prints it in decimal.

If it can do that, I will be highly impressed.

[lcyGamma]

I think you guys may be taking the octadecimal thing too literally. I don't fully understand it so I can't comment on if it is relevant or not to this build.

15 blocks > 8 values per brick

A memory brick can therefore send 1 to 8 relays back

The drive can hold a total value of 120 (8 x 15).

It can be used for a number of things. To store images, settings, or act as a form of variables.

Don't over-hype it or you'll be disappointed. :s

There are 3 ways one could read:
> Have a brick that toggles itself in sync with the hard drive time to read a section of specific data it has previously written
> Have the computer read all data based on timing and toggling
> Have the computer use all 15 blocks as one massive variable and have 120 different responses based on how much is written

[lcyGamma]

Dev guide is now available.

I just need to check the reading mechanism again. I may have neglected to factor in the delay for the projectiles to all pass through, which might bugger the cable. Would require a simple fix of slowing down the speed in which each memory block sets off.

[SeventhSandwich]

The drive can hold a total value of 120 (8 x 15).

Or you can treat each brick like it's a digit and make it so the drive can hold a single value anywhere between 0 and 16777215.

The way you're doing it is vastly under-utilizing the power of reading & writing data from bricks.

I actually like the idea of using octal numbers to store data in a brick, seeing as it takes less bricks to just make a converter. However, here's how the harddrive should work.

Instead of having 15 blocks that store data, you should have 8. Each block represents an octal digit, each block representing a digit in an octal 'byte'. When you write to the harddrive, it should copy each digit of the number you're sending to the corresponding brick. So for the device I was talking about earlier, here's how it would work:

The player enters in the number 5983. A decimal to octal converter presumably placed behind the console converts the value to 00013537. Then, it sends over the data digit by digit. '7' goes to the first brick and gets stored as the color corresponding to '7'. '3' goes to the second brick and gets stored as the color corresponding to '3'. And so on and so on.

Later, the player decides to read from the harddrive and the data is sent over from the bricks to a Octal > Decimal converter. 00013537 is converted back into 5983, which the screen displays on the screen.

Don't ask me how to do that last part though because that's why no one uses octal values.

[lcyGamma]

Probably beyond my mathematical abilities. I'll see what I can do, I think I partially understand how it might work but I can't see it coming together as an evented system yet.

[SeventhSandwich]

Probably beyond my mathematical abilities. I'll see what I can do, I think I partially understand how it might work but I can't see it coming together as an evented system yet.

If you can really send over values greater than 1 using relays, this should be fairly easy to do.

[Jam_Jar]

Yeah, but it'll be impossible to read data from the hard drive.

Why is it impossible? There's a way to decode and code the data between binary and octal if need be.
If you store 1 and 0 in the drive, in this case red and green:
8 bricks taken up in the drive to create an 8 bit number between 0 and 255
and
7 bricks taken up in the drive to create a 7 bit number between 0 and 127

For a start this makes it horrible to work with because you have a 7 bit number partnered with it. In the world of computing 8 bit numbers are used, which is a byte. 1024Bytes is a KiloByte and 1024Kb is a MegaByte and so on. If you could add an extra storage brick onto it, it'd make it easier in a sense you have two clean 8 bit numbers. At the moment though it doesn't, it has 15 which fits in nicely with a multiple of 3.
If you were to use 5 * 3 bit binary numbers you could have 5 values stored in the drive between 0 to 7.
In my opinion, if I was to create hardware to link to this, I'd find this horrible to work in.

If you use octal which it is at the moment, you can store full 8 bit numbers in the same 3 blocks. So I can store overall 5 8 bit binary numbers in the drive using octal. Creating a decoder shouldn't be difficult. If a standard decoder and coder is created, then whenever someone makes a component they wont have to reinvent the wheel.