Discussion: Using Initial Object Positions for Random Seeding

[JeremiahK]

I had a thought earlier about theoretically using the object positions at startup to seed a random number generator. Since the objects' positions are determined by timers which you can only reset, not read, you would have to use collision detection against the playfield. Since the playfield only gives you 4-color-clock precision, you could perform some HMOVEs followed by another collision detection to get exact precision. At least, that's the theory. It would probably take a bit of ROM space to do, so it may not be practical for small games, or any games, for that matter. Regardless, it is a fun idea.

 

Are the object positions actually random at startup? I would assume they are always unknown, but are they usually set to the left edge of the screen?

 

I wrote a simple program that does no CLEAN_START, simply sets object colors and clears some TIA registers, including the playfield.

The kernel draws 5 rows, first drawing Player0, then Player1, Missile0, Missile1, and Ball. Player/Missile0 is blue, Player/Missile1 is green, and Ball is red.

 

Running this in Stella always puts all objects on the left edge of the screen, but frying Stella will randomly move the objects a bit (they stay close to the left edge, though).

 

Harmony (1.06) won't draw Player0 at all, Player1 is always in the center, Missile0 can be anywhere on the screen, Missile1 is always a bit left of Missile0, and Ball is always with Missile1. I am guessing that this has to do with the Harmony cart, however, and it wouldn't act this way if you wrote an EEPROM. If anyone has an EEPROM burner, I would love to know how this code runs.

ObjPosTest.bin

ObjPosTest.asm

Edited December 19, 2017 by JeremiahK

[alex_79]

Running this in Stella always puts all objects on the left edge of the screen, but frying Stella will randomly move the objects a bit (they stay close to the left edge, though).

Randomization of TIA initial state will be probably added to Stella in the future:

https://github.com/stella-emu/stella/issues/249

 

Harmony (1.06) won't draw Player0 at all,

Since the players are always positioned in the visible area of the scanline, the only explanation for this is that VDEL is enabled (at least for player 0) by the Harmony menu software. Try clearing VDELP0/VDELP1/VDELBL before writing to the graphic registers.

 

I am guessing that this has to do with the Harmony cart, however, and it wouldn't act this way if you wrote an EEPROM. If anyone has an EEPROM burner, I would love to know how this code runs.

You can test the startup condition of the TIA using an Harmony cart, but you must flash the rom in single game mode. (you'll have to reflash the bios after that to return to normal mode).

If you load it from the menu, the latter will influence the results.

 

This is something to keep in mind: this method of setting the seed might fail in all cases where the game isn't executed at the console power-on (multicarts with menu, supercharger, etc..)

 

 

I tested the rom (on a 7800: I'd have to check, but I'm quite sure the 7800 bios doesn't initialize the TIA registers at all) and positions seems indeed to be random, but all the objects are always visible, so maybe the VDELxx flags are always cleared at startup?

Edited December 17, 2017 by alex_79

[ZackAttack]

You could have a variable that is frequently incremented during the title screen and then use its value as the seed when the button is first pressed.

[+nanochess]

The RAM contains trash at start of game, one good way is to add all these bytes and use the resulting value as seed for a LFSR

[JeremiahK]

Thanks for testing this, Alex.

 

 

Since the players are always positioned in the visible area of the scanline, the only explanation for this is that VDEL is enabled (at least for player 0) by the Harmony menu software. Try clearing VDELP0/VDELP1/VDELBL before writing to the graphic registers.

 

Ah, I forgot about the VDELxx registers.

 

You can test the startup condition of the TIA using an Harmony cart, but you must flash the rom in single game mode. (you'll have to reflash the bios after that to return to normal mode).
If you load it from the menu, the latter will influence the results.

 

Good to know. I can't do this at the moment, as I am using Arch Linux and am in the process of adding a HarmonyCart package to the Arch User Repository.

 

 

You could have a variable that is frequently incremented during the title screen and then use its value as the seed when the button is first pressed.

 

Yep, I think that's how most games do it. I think that would be sufficient for most projects, but I would personally want a bit more randomness if I was making a game that needed a lot of random numbers, say a dice or card game. I have for example played the homebrew Yahtzee game, and for some reason, the first roll seems to frequently be the same, although I'm not sure how the random numbers are done in that game.

 

 

The RAM contains trash at start of game, one good way is to add all these bytes and use the resulting value as seed for a LFSR

 

That's a good idea, but I believe I remember hearing that certain systems (like the 7800 and Jr) will clear RAM at startup.

[alex_79]

I can't do this at the moment, as I am using Arch Linux and am in the process of adding a HarmonyCart package to the Arch User Repository.

In the meantime you can just compile the harmonycart software without installing it in the system directory. It works just fine. (P.S. I'm using arch too!)

[JeremiahK]

Just to be clear to you all, I'm not neccesarily asking for help on how to do random numbers (although all suggestions are greatly appreciated). I have read up on random number generation in this forum, the Dig, and atarimagazines.com, and I have a pretty good idea on how they are traditionally done on the 2600. I haven't done any random number generation yet, but I would probably do an LFSR, using all the user input (or lack therof) to manipulate the number in different ways every frame. I will rename the thread to make it sound more like a discussion vs a question.

 

If it is in fact true that all 5 objects are always set to random places, and that they can each be at any location from 1-160, this would potentially give us a completely random number in the range of 1 to 160^5. That is over 104 billion options, which is obviously overkill for the 2600. I would probably take a tenth of both player objects' positions (each giving 16 equally possible outcomes) and combine them to get a perfect fair value from 0-255. You could also do this with the missiles, if you have a 16-bit LFSR, to get a value from 0-65535.

[JeremiahK]

In the meantime you can just compile the harmonycart software without installing it in the system directory. It works just fine. (P.S. I'm using arch too!)

 

Nice! I love the Arch Way.

[+nanochess]

 

 

That's a good idea, but I believe I remember hearing that certain systems (like the 7800 and Jr) will clear RAM at startup.

 

Forgot that the INTIM register contains a pseudorandom value at startup.

[+SpiceWare]

Take a look at step 10 - "Random Numbers"

 

One thing that helps when using an LFSR is to keep reading values at a regular rate, even if you don't need the value. What this does is impose an element outside of the Atari's control - namely the time it takes the human to do things: hit the RESET switch to start a game, collect the next box, etc. I've added this to VerticalBlank

 

VerticalBlank:
        jsr Random
... 

 

That also has an LFSR posted by batari that can be used for 8-bit or 16-bit based on how much RAM you allocate for it. There's a bit of Q&A about that blog entry as well, so be sure to read the comments.

[JeremiahK]

Did you have to set up any drivers for the HarmonyCart, Alex? I now have the software installed, but it is not detecting the Harmony cartridge.

[vidak]

(I also use Arch linux, and I love it)

[alex_79]

Did you have to set up any drivers for the HarmonyCart, Alex? I now have the software installed, but it is not detecting the Harmony cartridge.

No, I think it worked out of the box. You'll need read/write access to serial ports. If you haven't already, add your user to group "uucp".

 

Also check that the virtual serial port (/dev/ttyUSBx) is created when you connect the usb cable. If not, try other cables (the Harmony might be picky about the cable, see here)

 

[+SpiceWare]

Had the same problem with the Harmony when I set up my new laptop for 2600 development. cd-w had me run the utility via root (ie: put sudo before the command) and it worked, which confirmed it was a security issue.

 

He sent me this link which has instructions on how to fix the security. I had to reboot after issuing the adduser command for it to take effect, though in hind sight just logging out and back in may have worked.

[JeremiahK]

Thanks for the tips. I am busy today, but I'll try to check it out later.

I guess I underestimated the number of 2600 developers using Arch. It makes sense, really. Arch is a very powerful OS for developers, as it puts you in control of everything, and let's be honest, you almost have to be a developer to get it running.

I use the i3 window manager to tile my windows so I can easily have 3 .asm files, my file browser, firefox, and a terminal open at all times. It works perfectly, almost like having a complete IDE.

Edited December 18, 2017 by JeremiahK

[JeremiahK]

...If you haven't already, add your user to group "uucp"...

 

Thank you so much, this was all I needed to do. I flashed my program to the cart, and it is working correctly.

[+SpiceWare]

I guess I underestimated the number of 2600 developers using Arch. It makes sense, really. Arch is a very powerful OS for developers, as it puts you in control of everything, and let's be honest, you almost have to be a developer to get it running.

 

I've been using Ubuntu as a guest in VirtualBox as the C compiler we're using isn't available for OS X. I'm not familiar with Arch, what are the benefits over Ubuntu? Can it run as a guest in VirtualBox?

[JeremiahK]

Arch has its pros and cons, the biggest con being that it is a pain to install your first time. There is an installation guide on their site, though, that tells you everything you need to know. It is a minimalist distro, so when you install it, you basically have nothing but the OS, no GUI at all, terminal only. You then install your graphics drivers, Xorg, and whatever window manager and programs you want. If your program isn't in the official repositories, you can probably get it from the user-maintained AUR, or build from source.

 

Arch has its own package manager, pacman, which is quite powerful. You can update every program in your system by running one command. Arch is a rolling-release distro, meaning that it is constantly being updated rather than having a new version released every several months, and you always have the latest kernel. This is good, but I have heard that sometimes it can break your system, although this has never happened to me. The official software repositories are always up-to-date. Firefox, Audacity, Blender, you name it, as soon as a new version is released, it is available in Arch. I used Mint before, which is built off of Ubuntu, and the software was always several versions old. I think this was to keep the system stable, but my system broke anyway, and that is when I switched to Arch.

 

Arch is x86_64 only, so I don't think it will run in VirtualBox. Although if you're going to all the trouble to install it, I would recommend dual-booting anyway. Arch is the kind of thing that is a little hard to get into, but once your in, you never go back.

[+SpiceWare]

Hmm, sounds like when a friend & I first tried Linux in the early 90s on his state-of-the-art Pentium system. I believe we downloaded something like 35 floppy images while on campus. Installation went OK but to get X Window working required you to know the dot clock of the video card, which wasn't easy to find.

 

VirtualBox runs 64-bit just fine. Main concern for me is Guest/Host integration for shared folders and such. I keep all my source in a shared folder on my Mac as it gets backed up via Time Machine. This also let me set up multiple Virtual Machines with different compiler versions as they optimize differently, which can be useful when you're tight on space:

 

The size of custom2.bin will depend upon which C compiler you installed.

• 2011.03-42 - 8136 bytes
• 2012.03.56 - 8308 bytes
• 2012.09.63 - 8224 bytes
• 2013.05.23 - 8224 bytes

[JeremiahK]

VirtualBox runs 64-bit just fine.

Nice, I thought it was 32-bit only for some reason.

[ZackAttack]

Nice, I thought it was 32-bit only for some reason.

 

It appears that way if you try to create a Linux VM and hardware virtualization is disabled in the bios. Once you enable the virtualization setting in the bios it will allow you to create 64bit machines. Most consumer class computers ship with this bios setting disabled for security and reliability reasons.

[+SpiceWare]

Hmm, so I should probably set up 32-bit VM for Spice C as I'm planning to host a ready-to-use VM on my site.

[JeremiahK]

I updated the test program. Now it calculates the position of Player 1. The way I do this is by enabling only one "pixel" in the playfield, and also one "pixel" in Player 1. Then I shift Player 1 to the right by 1 color clock over and over until a collision is detected, keeping track of the number of shifts. Right now, I am not taking into accout the fact that the playfield is copied, giving only a value from 1-80, not 1-160. I can easily add a way to check which side of the screen triggered the collision by enabling the mirrored playfield and then re-checking for a collision.

 

If you notice, Player 1 is now always placed in 1 of 2 positions, corresponding to where the collision occured. The bottom of the kernel displays the generated random number in binary.

 

I know this is all kind of pointless as it would be much easier to simply grab INTIM at startup, and use the time that the game is started by the player for 16-bit LSFR's, but I want to see if my idea actually works. Call it a puzzle to be solved. It could actually be useful if somebody wanted to use some overkill 24-bit or 32-bit LSFR's for some odd reason.

ObjPosTest.bin

ObjPosTest2.asm

Edited December 21, 2017 by JeremiahK