Part 31: KGOG-TV

Part 31 - KGOG-TV

=== Trash World Inbox ===

Best scores I got on King's Ransom Online were 37, 30 and 25. Let's see your improvements.
28/85/33. Nice clean solution, XB and XC together make quick work of the foreign EXAs, and XA does the file stuff.

The description speaks for itself. I keep forgetting about that MODI -1 T T trick to subtract one and automatically die when it hits zero. Also, the TJMP MANY is just a convenient way to make those EXAs that grabbed a weapon harmless. They'll REPL into something that links nowhere and then T hits zero (since the TEST set it to 1) and it dies.

Finally, let's go back to the elusive 24-activity solution. Both GuavaMoment and I came up with a way to do this. I'll start with my own.

The main difference from my attempt in the previous update is that I now fill the hosts with files instead of EXAs. I found files much easier to control.
I'll add some explanations in the code.
Video
The end result is 517/100/24. I had to squeeze a little bit to fit it in the 100 size limit but I didn't have to try too hard. I'm pretty sure I could save more lines if I really wanted to.

Ah, so the EXA-filling solution is possible, with patience. The main trick seems to be to slow down the fill so much that between one EXA being created and the next, there's enough time to count all of them. But, that means that when you're actually creating EXAs to fill up the host, or to clean up the remainder of the 8 EXAs that are being created, you have to wait for that slow fill as well.


=== KGOG-TV - Satellite Uplink ===

Oh. They just shut the whole game down.
Something about "hackers" or something?
I guess that means you.
People are taking this so seriously.



Three votes for real money, one for "their loss".

It is real money...

People act like the online world is different, but it really isn't.
At least as far as human behavior goes.





Next up... Ember wants us to upload a tv program? Okay.

You know what really moves people?
Art.



One vote for "That's why art is powerful", but three people didn't like where this was going.

I already don't like where this is going...

I've been working on something creative.
An abstract video piece.
It's an expression of some of the ideas I've been developing around shape, form, and color.
You'll see.
Let's get it out there.

Don't worry too much, Ember just wants her art to be seen. Seeing how recently NFTs gained popularity, I doubt Zach had even heard of them when he made this game.


OST: Behind the Scenes

The assignment:
- Align the satellite dish with the target satellite by setting the azimuth, elevation and frequency. Then transmit the data from EMBER-2's video (file 301) after encrypting it using the TV station's encryption key (file 199).
- The azimuth, elevation, and frequency of the target satellite are available in file 300.
- Note that you must align the satellite dish before transmitting any data.
- For more information see "Look to the Stars with Satellite Uplink Systems" in the second issue of the zine.

Ember, how did you even get us inside a tv transmission satellite dish?

Before I'll grab the zine, it might interest you that K-GOG has the shows "Ten Men and a Dog", "City Livin'", "Cooking for Losers", "Takedown", "Buy it, Love it", and "Futurelook 2000" lined up. Which is your favorite?



Okay, so writing to the motor registers moves the dish, while I can read the current position from the #AZIM and #ELEV registers. The encryption is quite basic as encryption schemes go, add the first value of the data to the first value of the encryption key, modulo 10000. Repeat with the second value of the data and the second value of the encryption key and so on. If there's more data than values in the encryption key, wrap around to the beginning of the key. A complication is be that EXAs are limited to 9999, so I'll need a trick for the modulo operation.

But first, let's get the sat aligned.

The EXA reads the azimuth and elevation from file 300 and makes REPLs to handle them. The frequency is easier, it can just be sent to the register right away.

The motors only can move one step at a time. So the azimuth and elevation EXAs calculate the difference between the current value and where they should be, and then either move up and down. The move loops are interwoven so that both the AZI and ELEV only need one conditional jump and can fall through otherwise. And I use the MODI trick GuavaMoment helped me remember to have the EXAs die automatically when they're done.

The uplink status on the top right says "Link: Locked" once all settings are right.

Next up is encrypting the file. To keep the activity as low as possible I think it's best if I send the dish settings over M so I can carry file 301 with me and handle that without a lot of messaging.

Let's go through it step by step.

XB is a simple EXA that grabs file 300, and sends the azimuth, elevation and frequency over M:
I could unroll that but I don't know how much space I'll have before the end so let's not optimize prematurely.

XA leaves behind an ENCRFILE EXA in the host that has the encryption key, then makes the azimuth and elevation EXAs. I moved the azimuth/elevation transmission to those EXAs to save a bit of time. It's important that the right EXA gets the right value, and this could easily go wrong here because the frequency, AZI and ELEV EXAs all ask for M around the same cycle. I could prevent that by adding some NOOPs or whatever but the unpredictable order of M's in the same cycle just happens to work out in my favour here.

Let's look at the ENCRFILE EXA next.
It grabs the file, then waits a while before it starts sending data. The main reason is because I need to make sure the dish settings are sent first. But, since I had the loop in place already I lengthened it to 49 steps, which ensures that the dish is fully set in each test case. That way, I won't try sending data before the thing is aimed at the satellite.

Anyway, after sending a key value, it waits for an incoming M. To cause this EXA to stop at the end, it dies if M is zero.
Otherwise, it tests if it's at the end of the encryption file and if so starts over from the beginning of the file. Either way it sends the next value and repeats.
After the 'main' EXA sets the frequency, it switches to local mode, then creates a SENDER EXA that will handle the actual encryption and sending logic. It grabbed the data file along the way, so now it just skips past the video title, then starts sending data locally. At the end of the file, it sends a 0 to let SENDER know it's done, and then switches back to global, voids the next encryption value from ENCRFILE and sends it a 0 (kill signal).

The sender contains the encryption logic. It makes a temporary file because it has a lot of values to juggle. First thing it does is check if the value from the data EXA is a zero, in which case it stops. Both the data EXA and this one jump to DONE to make sure they don't leave their files in the foreign host.

For the encryption, it first copies the data value to X (I needed it in T to see quickly if it was zero, but I need to free T for an upcoming test). Then the EXA switches to global mode and puts the encryption value in F. It tells the ENCRFILE EXA to get ready to send another message, and adds up the data and encryption values, saving that to the file. If the result is less than 9999, it sends the data right away. Otherwise it needs to do something tricky to get the "modulo 10000" requirement.

The SWIZ 0004 instructions return a number that contains the thousands digit of the original, in the ones place. Those can be added together. For instance, if the result is 15, that means the full result would be 15xxx, modulo 10K makes 5xxx. That's what the SWIZ 1000 does. It takes the digit in the ones place, and puts it in the thousands place. The digit is where it should be and we get the modulo operation for free.
Next I take only the lower three digits of the data and encryption value using SWIZ 0321 instructions, add everything together, and send it to #DATA.



The top percentiles are 180, 56 and 4. I'm not wasting any activity points but there are improvements for the other metrics.

There is in fact a much, much simpler way to implement the encryption algorithm. EXAs do have a range that goes beyond 10000 values - we just need to use it. It's negative numbers, of course.

I can rewrite the whole SENDER code to just this:
The data value is stored as 9999 less than the actual value. Then the encryption value is added to it. This will never overflow, since the new total will never be more than 9999.

Now there's two possibilities. Either the result is less than 0 (the total was less than 9999), in which case I can just re-add the 9999 and send to #DATA. Or it's more, in which case we would have to apply the modulo operation. Since that's equivalent to subtracting 10000, and I already subtracted 9999, I just subtract one more and that's it. No more temporary files, everything can be done in-place.

Because it's so much faster, I had to bump ENCRFILE's wait time to 55 loops. This solution clocks in at 431/76/4. Less lines of code and less cycles.

You might've already realized the next step. Since the temporarily file isn't necessary anymore, we can delete the entire dedicated SENDER EXA and have the main data one handle the encryption logic. That skips a lot of M transmissions.
360/63/4.

Now that I don't need to worry about activity anymore, I can also get rid of that annoying wait by doing the encryption in parallel with setting the dish.
253/88/7.
While SETDISH does its thing, the ENCRFILE EXA and the data one are sitting in the SECURE host, communicating in local mode. The data EXA overwrites the values in Ember's file with the encrypted values. At the end it kills the ENCRFILE EXA, hops over to the transmitter, and sends all the contents of the file.

I shuffled some code around, mostly to make sure EXAs that are finished fall through into code that makes them stop themselves. The different use of M somehow changed the order the dish EXAs receive the data in so I had to move the COPY M instructions back to the main SETDISH code.

Next, I noticed that the encryption algorithm is still the slowest step by far. The most obvious thing I can remove from it are the two cycles to check EOF. I can't unroll that loop much, I don't have a lot of lines left, but there's another way.
207/100/7. When the data EXA is at the end of the file it will die, and the GRABBER EXA can take it and send the data. I needed some NOOPs to slow the replication down enough that the KILLs work properly.

In this solution, the encryption algorithm is still the slowest step. It's possible to change that, for instance by writing the raw value to F before checking if it's negative, and handling that later, when sending the data. However, that means you can't fully unroll the sender code anymore with the @REP 24, so you need TEST EOF instructions and everything, and it slows down the whole program significantly.

So, I'll end it today with top scores of 207 cycles and 63 size.

By the way, I hadn't noticed it before but there's some sort of ad in the zine, just after the satellite dish article.



Sounds neat.

Well, what did you think?



The first vote. And for next time...

Okay, no more trying to find shortcuts.
Time for a brute-force solution to the money problem.
I know you like messing around with bank systems...