DotDash Password System

[+Gemintronic]

This is what I call my "DotDash" password system concept. I guess I'm just brainstorming here so feedback is appreciated.

 

The standard kernel can handle displaying 16 digits and 8 dots or dashes in the middle. Each two digits are the tens and ones place in an 8-bit number. A single dash/dot/blank represents the hundreds place being the 2 1 or 0 respectively. So, a dash (200) + 4 (40) plus 7 (7) would equal the value 247.

 

Input could be something like: UP/DOWN to change number or dot/dash. LEFT/RIGHT to go backwards and forwards through the password - from first row to dot/dash row to final numeral row. Pressing LEFT on the first digit of the first row backs up to the title screen. Pressing RIGHT on the last digit in the last row confirms the password and goes in game.

 

This system would provide 8 8-bit values for a save game system using the most bare standard kernel.

 

NOTE: This does not include any hack detection or checksum. That would be up to the programmer to "waste" a value inside the password for checksum/anti-cheat.

Edited September 5, 2012 by theloon

[GroovyBee]

Interesting idea but I think some mileage could be had from the use of "Radix 40".

[+Gemintronic]

Interesting idea but I think some mileage could be had from the use of "Radix 40".

 

I know not of this Radix 40 you speak. Is it some form of symbolic compression? A Google search turned up Radix 50 which somehow compresses 3 characters out of 40 character types into one 16-bit value.

[GroovyBee]

40 is 50 in octal . Its used to compress three characters into an unsigned 16 bit word. The characters can be upper case "A" to "Z" (so 26 there) and digits "0" to "9" (another 10 there) which leaves 4 remaining for punctuation. To compress you do the following :-

 

X x 1 +

Y x 40 +

Z x 1600

 

Where X, Y and Z are any of the indexes representing the characters in the range 0 to 39.

[+Gemintronic]

I'm still a bit shakey on the math, but, it seems a system using 40 unique characters would only need 6 symbols per row and no need for dots or dashes.

 

ABC

123

 

This would be more legible since I could use more pixels per symbol. However, the end-user would be stuck with potentially pressing UP 40 times to go from the first character to the last - just for a single symbol in the password. Hmmn.. Also, storing the graphics for 40 unique characters may be alot?

Edited September 5, 2012 by theloon

[GroovyBee]

If you go for left/right moving a decade and fire to select then you don't need all that many stick movements.

[+Gemintronic]

With 40 characters (6 symbol) passwords it's quite a bit more roomy. Thanks!

[GroovyBee]

With 40 characters (6 symbol) passwords it's quite a bit more roomy. Thanks!

 

No probs! You might need to roll your own 16 bit arithmetic for multiply and divide. I'm not sure if bB supports it.

[+Random Terrain]

I think my brain is the size of a peanut, so I don't understand any of the above or how you would use it.

[+Gemintronic]

I'm planning on using the SaveKey to save game data on future games. As a backup for people who don't have SaveKeys I'd like to make a password system. I was originally thinking two rows of numbers and one row of dots and dashes would be easy to input. This is the mock up in the beginning. I don't understand the maths behind Radix-40 but I DO understand symbolic compression. Meaning, if I use 40 different symbols for each space in a password I only need the end-user to input 6 elements. Thus the mock-up at the end.

 

The net result is a password system that "saves" 8 8-bit variables.

Edited September 6, 2012 by theloon

[GroovyBee]

The biggest number you could represent in radix 40 (using a 16 bit word) would be (39*1600)+(39*40)+39 or 63999. A 6 digit password only allows you to save 4 bytes of data. I'm sure Melody carts can have a serial flash on them but I'm not sure if the 2600 can write to it directly (the ARM coprocessor probably can). If writes are possible you wouldn't need a SaveKey and you could save quite a bit of data almost transparently to the game player. I say "almost" because some serial flash chips need quite a bit of time for erasing and writes to complete so you might have to save data over several VBLANKs.

[+Gemintronic]

The biggest number you could represent in radix 40 (using a 16 bit word) would be (39*1600)+(39*40)+39 or 63999. A 6 digit password only allows you to save 4 bytes of data. I'm sure Melody carts can have a serial flash on them but I'm not sure if the 2600 can write to it directly (the ARM coprocessor probably can). If writes are possible you wouldn't need a SaveKey and you could save quite a bit of data almost transparently to the game player. I say "almost" because some serial flash chips need quite a bit of time for erasing and writes to complete so you might have to save data over several VBLANKs.

 

Doesn't that 4 bytes of 16-bit values translate to 8 8-bit values?

 

No one has made available libraries in BatariBASIC to access any extra storage in the Melody/Harmony board (yet). There is actually code for the SaveKey. I hope my password engine can also be used too.

[GroovyBee]

Doesn't that 4 bytes of 16-bit values translate to 8 8-bit values?

 

Every 3 characters can be encoded into 16 bits (8 bits to a byte so that is 2 bytes). So a 6 digit password could only decode to 4 bytes.

 

No one has made available libraries in BatariBASIC to access any extra storage in the Melody/Harmony board (yet).

 

OK... Well... You could always do it .

[+Gemintronic]

I could. If I was a tool builder. I'm just the tool user (for now). Sometimes I'm just a tool, really!

 

I think a compromise might be just having 16 password elements going from 0 - F. That way the end-user only needs to toggle the joystick 16 times to go from end-to-end in symbol selection. Storing 16 "sprites" shouldn't make a big dent in available ROM either. The 3x5 font actually doesn't look bad, either.

Edited September 6, 2012 by theloon

[GroovyBee]

Just use left/right to go up/down a decade (10 characters) in radix 40.

[orange808]

Depending on your needs, it seems like it would make more sense to use the built in score display in bB to get the password from the user.

[+Gemintronic]

Depending on your needs, it seems like it would make more sense to use the built in score display in bB to get the password from the user.

 

It's definitely an option. However, now the password would have to be 6 characters in length. With the screenshot I posted earlier I get 16 characters.