Hello, and welcome to C++ Weekly.
I'm your host, Jason Turner.
I'm available for code reviews, contracting,
and on-site training.
Now, in the last episode, we had some fun writing some assembly
code to draw some pixels to the screen in our C++ box.
Now, in this episode, I'm going to enhance the C++ box source
so that I have a random data device that we can read from
during emulation time.
So I'm going to start by going into this memory map here.
And this memory map file gives us the location
of all of the things in memory.
And so we didn't play with this in the last code,
but you can change the width and the height
of the screen bits per pixel.
That's not implemented yet.
But we can modify some of these things,
and we can have access to a real kind of memory map being
built up for this thing.
And we have down here where the default screen buffer is,
and it is two megabytes from the top.
So like I said before, it's got 10 megabytes total.
The screen buffer starts at eight megabytes.
That's two megabytes from the top of the RAM.
So that worked exactly as we expected it to.
But we're going to add a new memory location here.
And so this screen buffer one, this
is the one that says what is the current screen buffer.
So it is possible, actually, to write to this memory location
and change which screen buffer that you are currently
displaying if you wanted to play around and do double buffering
kind of techniques as you are having fun learning how to do
kind of hardware-related code in C++ and arm assembly.
But for this example here, I want to add a random device.
And it's going to be 32 bits.
I want to make it four bytes wide.
And it's going to start at the last place plus four.
So the last one started at register start area.
And that was here.
That's going to be--
that should be four bytes past the last register, which
is also 32 bits.
And this is going to be 32-bit pointer to--
no, not 32-bit pointer, 32 bits of random data.
That's the only guarantee we're going to make here.
So I have now created this here in my memory map file.
I'm going to go over here.
And this should be pretty straightforward.
I already have a random device set up.
And that is used for showing the static.
If you saw before when you don't have the valid program running,
then you see static on the screen.
So this random device is already here.
And it is for generating bytes of data.
I want to create four bytes of data.
I have a random device.
And let's see if we can put it to use.
So I have a for loop here that goes through
and it does each operation that needs
to be executed in the CPU emulator
while there is time remaining for the current frame.
So I'm trying really hard to emulate
30 million instructions per second,
and locking it at 30 frames per second.
So I hopefully have enough time in here--
and let's go ahead and see if we do--
to write some random data to a random device.
And let's do that after the instruction is executed.
Ultimately, this may end up proving
to be a mistake to do this as four separate operations,
but we're going to see what we get out of it.
Actually, on second thought, instead
of writing this as four bytes as once,
let's go ahead and create a new distribution that
gives us 32 bits.
Now that should work.
Let's give this a quick compile.
All right, now we actually have one other place
where this needs to be done because we have a single step
mode.
So this gives us one other thing to potentially refactor here,
because right now the single step code is starting
to look a little bit redundant.
But on the single step mode here, I
need to also update that random memory location
before updating the display.
So, all right.
I'm going to launch this with an example of these rotating
colors that I currently have set up.
So this may have had a significant performance
impact on our emulation, but we're
going to go ahead and test it and see
if we got what we wanted before we concern ourselves
much more with this.
OK, there I go.
I think we are seeing what we wanted to see.
I'm getting now a random noise on the green channel
of each pixel on each frame being updated
by reading from this random memory location
that we had just set up.
So that is location 10, which I believe is right.
Let's go ahead and put this back on a slightly different
location and see if it's no longer--
yeah, that's no longer random.
Location 10 is where that first bite of random noise
is coming from.
And that is going just on to the green channel here.
So that was kind of fun.
We added this.
I'm going to have to play with the performance implications
of it a little bit, but hopefully this was a little bit
of an interesting diversion from our normal C++ Weekly kind
of content.
And I hope you liked this episode.