install windows on osx bootcamp partition using boot camp

I have found a wonderful, in depth guide to installing windows on the boot camp partition on your osx machine.  It uses a trick in parallels and it appears to be more successful then doing it with vmware.

Here is the link to the tutorial: 

The writer of the tutorial says that you have to modify the master boot record (MBR) which can be tricky if you aren't familiar with using the terminal.  (There is also that feeling of messing with something that you don't really understand....)

Here is the link to the forum I found the link in:

According to the original poster, you can install it without fiddling around with the mater boot record.  All you need is to install rEFIt and I guess it will magically find the windows partition.

It is unknown whether he quit parallels as per the tutorial or let it completely install, before restarting his computer to boot windows.

spartan 6 uart

After downloading the drivers I tried to find the FTD in the "/dev/tty.*"

I did not find it.  However after I plugged in the FPGA's uart something new appeared.

typing "/dev/tty.*" revealed a new port:

/dev/tty.usbserial-A700h2To

When I unplug it, the port disappears and when I plug it back in, it reappears.

in this example, it shows a port that contains the characters "...ftd..."

This tells me that either the company decided to use a radically new name

OR

I didn't really need to download the driver.

One way I can find out is by plugging it in to my other mac to see if it shows up.

what ever the answer is, it isn't a big deal.  what IS a big deal is that I am able to send and receive information from this port.

UPDATE:
I tried pluging in my spartan 6 uart to my other mac but the usbserial-A7.... did not appear.
However, after installing the driver, it appeared.

So yes, the Driver IS necessary.

osx serial communication using "screen" command in terminal

UPDATE
*Apparently minicom would be the osx equivalent to cutecom.
*USB to serial communication has many different drivers. and it all depends on what chip is being used.  I used to find a lot of site talking about a usb to rs232 wire and what made the wire work was a small chip inside of it.  Two big companies made those chips, PL and FTD.  In order to do serial com in terminal you first need the right drivers.  The driver must be the one for the corresponding chip.
Since I was using a spartan 6 I had to take a look at the documentation to find out which chip.  When I plugged it in to my windows machine, it would automatically download the drivers so I never gave it much of a thought.  However, I do not believe osx does this.  The spartan 6 documentation said that the uart had a ftd chip so I went ahead and downloaded the osx driver.
===============
In linux we have cutecom.
In windows we have hyperterminal/terminte
of osx, we have neither.

The purpose of these programs is to help will serial communication such as rs232 protocol.
In my UART fpga lab i had to send a byte of data to the cutecom.  If I did
the protocol correctly, the byte would show up on the screen.
(i.e. fpga sends the char "x" the cutecom shows x)
The reverse also works.  The cutecom can send the fpga the byte
(i.e. cutecom sents char "Z" the fpga shows "Z" in the led's)

I really do wonder why there isn't a nice program for osx.  After searching for it on google
it appears that there are special adapters for rs232 to usb.  Its not really what I was looking for.

IF there was no program like cutecom then there had to be at least SOME way to communicate with the
usb com.

Apparently  you can use the actual terminal

http://www.tigoe.net/pcomp/resources/archives/avr/000749.shtml

I believe a good side project would be to create your very own "cutecom" for the osx.
You would have to figure out how to use it though.....

look into it by using "man screen"

--===========================
--original doc reproduced below
-------------------------------------------

Serial Communication in OSX Terminal

I knew it had to be possible to view serial data in the OSX terminal window, but I'm not enough of a unix geek to figure it out. Finally, a little googling told me what I needed to know. Here's how to read and send serial data from the terminal in OSX.
First, open Terminal. If you've never used it before, it's under Applications/Utilities/Terminal. Next, type

ls /dev/tty.*

to get a list of all of your serial ports. Pick the one that you want to open. For example, my list looks like this:

/dev/tty.BTRS232                        /dev/tty.Tigoe6630-AppleAgent-1
/dev/tty.Bluetooth-Modem                /dev/tty.Tigoe6630-Dial-UpNetwor-2
/dev/tty.KeySerial1                     /dev/tty.modem

And I know from previous experience that /dev/tty.Keyserial1 is my Keyspan USB-to-serial adaptor. It's connected to a PIC at the moment. The PIC's programmed to read one byte of serial data at 9600 bits per second, then send back three bytes, "A", "B" and "C".
Knowing the serial port, you can just type screen portname datarate to show the serial data on the screen. In my case, it was:

screen /dev/tty.Keyserial1 9600

Then I started typing bytes at the PIC, and it sent bytes back to me. Whee! No need for zTerm! To quit the screen app, tyoe control-A, then control-\.

how to install windows without dvd drive

you can use VMWARE to install it into the boot camp parition

http://forums.macrumors.com/showthread.php?t=601414

I haven't tested it personally, but from the looks of it, the people in the forum say they were able to get it to work.  The answer is in the post by colin which is reproduced below.

=====================================

I'm working on installing Windows 7 without a DVD (broken SuperDrive here) using VMWare Fusion and the instructions provided by melchior.

I think I've figured out a way to make VMWare install Windows 7 to the Boot Camp partition.

I'll try and see if it works, and if it does I will post instructions.

Edit:

Great news, I got the Boot Camp partition to show up in VMWare Fusion when installing windows. I'm going to install it! 

Here's what I did:

Step 1: Installed VMWare, opened up the application to make sure everything worked correctly, then quit.

Step 2: I created a folder in the root of my hard drive (Macintosh HD) entitled "Virtual Machines"

Step 3: I typed the following into Terminal:

Code:

cd /Virtual\ Machines

Then..

Code:

/Library/Application\ Support/VMware\ Fusion/vmware-rawdiskCreator print /dev/disk0

A list of my computer's partitions appeared, then I typed..

Code:

/Library/Application\ Support/VMware\ Fusion/vmware-rawdiskCreator create /dev/disk0 3 windows7 ide

You can see a screenshot of Terminal after typing in these commands below.

After that, I opened up VMWare Fusion. I chose to make a new machine, I hit Continue Without Disc.

I chose Use existing virtual disk, then selected windows7.vmdk out of the Virtual Machines folder in root of Macintosh HD. 

VMWare asked me if I wanted to convert the disk into an "updated" version, I chose not to convert the disk image.

After that, I unchecked "automatically open machine when VMWare starts", then hit finish. I opened up the settings for the newly created virtual machine, and changed the disc to point to my Windows 7 ISO file.

I started the machine, and VMWare successfully recognized my Boot Camp partition and I'm installing Windows 7 onto the partition right now.


Screenshot of Terminal after typing in commands:



Update:

Setup completed successfully in VMWare and rebooted. I'm going to try and natively boot off of this, if it doesn't work I'll try winclone (I think winclone might set the partition to active when it copies the flies to the partition, that's why that "trick" causes the partition to become bootable again).

Side note: The reason why you type disk0 into Terminal instead of the actual ID of the Boot Camp partition (usually it's disk0s3) is because the VMWare Raw Disk Creator considers the Boot Camp partition a "special" partition and tags it with a 0 rather than using the usual disk0s3 stuff.

Attaching bram to vga

The VGA is working and as a hard coded test, I created some colorful squares
using
rgb_o <= "111" when within_range else "000";

Now it is time to use something that has the potential to change over time.

I used a BRAM to store the color values for each pixel.
Although I wasn't about to harness 8 bit color, at least I was able to get 3 bit color.

I hard coded a few colors into the bram and viola! they showed up in the screen!

below is the state machine I used to test my bram.  The purpose of this
state machine is to  add things to the BRAM and then the VGA timer would read that bram.
This snippit of code only showes how I added something new to the bram.

The screen showed 3 squares of the expected size.  However, there were some random artifacts such as dots being missing or dots being missing colored or dots being in places where they shouldn't.  I believe that
it is mainly a side effect of a poorly written process.  The snippit below was meant to be quick and dirty, so it is rather unorthodox.
--==========================================

process(clock)
constant max_val: integer := (hdisp_size*vdisp_size);
variable cnt: integer:= 0;
variable color_var: std_logic_vector(2 downto 0):= (others => '0');
type states is (init,x_sq, y_sq);
variable st: states := init;
variable x_var,y_var: integer:= 0;
variable coordinate:integer:= 0;
begin
if clock = '1' and clock'event then
case st is
when init => st := x_sq;
when x_sq =>
if x_var >= hdisp_size then st:= y_sq;
x_var := 0;
else st:= x_sq;
x_var := x_var + 1;
end if;
when y_sq =>
if y_var >= vdisp_size then st := x_sq;
y_var := 0;
else st := x_sq;
y_var := y_var +1;
end if;
when others => st:=init;
end case;
coordinate := x_var + y_var*hdisp_size;
if x_var >=0 and x_var < 15 and
y_var >= 0 and y_var < 44 then
color_var := red_c;
elsif x_var >= 20 and x_var < 300 and
y_var >= 40 and y_var < 200 then
color_var := cyan_c;
elsif x_var >= 300 and x_var < 320 and
y_var >= 200 and y_var < 240 then
color_var := green_c;
else
color_var := black_c;
end if;
end if;
write_data_s <= color_var;
write_addr_s <= conv_std_logic_vector(coordinate, write_addr_s'length);
end process;


--==========================

Next, I should try adding another Bram that will hold on to the objects.  As a small example I must use the coe file that was used to make mario.  Then I will have to use easyBMP to convert more pictures into their bram equivalent.

quarter VGA (qVGA) 320 by 240 resolution

The default for vga is 640 by 480.  There are tons of documentation about how to get this timing correct and there are tons for larger resolutions.

However, there is hardly any mention of 320 by 240.

The reason I needed that resolution was because I needed to make a pixel matrix that would hold the color
value for each coordinate.  The pixel matrix exists in memory and unfortunately my spartan 6 doesn't have a lot of it.

The purpose of this blog entry is to document the qVGA timings that I have found through trial and error.


 hdisp_size = 320;  //This specifies the width of the screen
 hpw_size = 48; // pulse width
 hbp_size = 28; // back porch
 hfp_size = 4; //front porch

 hsync_period = 400//this specifies the number of clock ticks before going back to zero.  ie. 0 to 399


 vdisp_size = 240; // this specifies the height of the screen
 vpw_size = 1; //pulse width
 vbp_size = 15; // back porch
 vfp_size = 4; // front porch

 vsync_period =  260;// this specifies the number of clock ticks before going back to zero. ie 0 to 259

The h clock will tick every 80 ns
the v clock will tick every 63.84 us

The screen I was using was quite finicky when it came to the right pw, bp, or fp values, but after awile I started to notice a trend.

The screen should refresh 60 hz to 60.5 hz.
In reality I got 60.48 hz.

The numbers MUST conform to that timing constraint or else it will not work properly.
When the screen resolution was 640 wide, we would need to count up to 800.
At first I mirely set it to 320 wide and made it count to 800 (and increased the bp,pw,and fp to accomodate it).    This made big black margins
to appear on the left and right side of the screen

The same happened with the height.  Originaly i had it at 480 and had it count to 521.
Then I changed it to 240 and increased the bp,pw, and fp to keep the counter counting up to 521.
This made top and bottom margins.

Although it worked, i was more interested in taking over the entire screen.

The h_sync had to cycle every 32 us. which means that you have to count from 0 to 399 in 32 us.
originally would count to that number in 16us so I basically clock divided the h clk.

The v_sync had to cycle every 16640 us.  which means that you have to count from 0 to 259 in 16640 us.
I also clock divided the v_clk.


*****
important observation
******
for a long time I had been missing a margin.  I had thought my value for the fp,bp, or pw were offset.
but in reality, it was because I was sending color when I wasn't suppose to.  I tried sending the color outside of the 320*240 grid and as a result, the screen tried to adjust to fit it in.  The screen doesn't know where coordinate (0,0) is located so it will need to guess based on when it gets a color.  If this theory is true,
then it would be wise to always place a background.  A very light background.

VGA with add shape, add image, with matrix transformations

After getting the VGA to work I've started to come up with a plan to
created a device that would show wither shapes or images to the screen.
I've decided that all the objects would exist as data on BRAM

At first I thought of using a "pixel matrix" which was a 640 by 480
std_logic_vector.  It was huge and synthesis too an extremely long
time.  I am not sure how long it would have taken because I did not
let it finish.  After 2 hours of letting it freeze and go.  I had to quit it.
If it was this complicated for the machine then it means I am doing
something really inefficient.

So then I thought of using bram.  I was hesitant because i remembered
that memory took a long time to synthesis too.  But BOY was a wrong.
It only took a few minutes to synthesize a memory of my choosing.
first I made a a bram  1 by 307200.  It worked but this method would
only allow black and white.  I tried 8 by 307200 , but unfortunately
I hit my constraint.  There wasn't enough ram in my device to do this.

Several ideas bounced around in my head.  maybe i could use some sort
of mux that would play with an FPGA object.

I scrapped that idea because it would lead to something rigid.  If I
wanted to add shapes via UART, then I would need to think of a
different plan.

The new plan was to get rid of the pixel matrix idea.  The idea was
to use opcodes to specify what shape it was or what image it was.
It would include the coordinates, the dimensions and/or some other pixel
data.  The rest of it would be generated by the fpga using a fancy
algorithm.  An algorithm that I haven't thought of at this moment.

There are two categories, shapes and images.  Images take up quite a lot of
space because each pixel needs to be accounted for.  Shapes don't take up
much space at all.  A square would probably take at most two words
to describe.

The header for both would have the same format.  The opcode would
differ in order to tell the control what it is dealing with.
Below is a pictorial version of what I am talking about:
                                 
                                   | upper left corner |
opcode | scale | rotate | x coord | y coord |
4 bit     | 3 bits | 5 bits | 10 bits   | 10 bits  |

A header would be one word and would contain the upper left corner,
the rotation factor and the scale factor.  These three pieces of information
are extremely value able and would be used in the matrix transformations.

These three pieces would have to affect the pixel data what would come
after it.  Remember how I said that a square would take as little as two
lines?  well the next line would be its pixel data.  One way i can do it
is by specifying the width and the height.  However, if I want a shape
that is more custom I would have to specify the coordinates of the points.
Here is a new idea that might be better.

What if I wanted to make a parallelogram?  The width and the height
would be used to set the dimensions of the "plate" that the shape
will be on.   The points would exist in relation to the "plate"
if it was a 10 by 10 plate then I would specify the points as if I was
drawing on a 10 by 10 grid.

ie.  a triangle on the 10 by 10 grid  p1(2, 4) p2(0,10) p3(10,10)

When I move the triangle all I have to do is move the plate.  the points
would not have to change.  They are in relation to the plate, so if the plate
moves, the points move with it.  Everything would be in relation to that
upper left corner.  So theoretically, I should be able to rotate everything
and scale it.

images would be a similar story.except that all the pixels of the image would
be considered a point.  it would be a point on the "plate".  the points
would exist in relation to the upper left corner.  The side effect is that they
take up a lot of space.

in order to deal with this i needs to separate the shapes from the
images.  the images would have a larger page and the shapes would
have a smaller page.

I believe the limit is 900000 bits  so i have to divide it up in a way that
can help share the ram.

for shapes
32*(8)*(2**6) = (wordsize)(shape _lines)(shape pages)

each word is 32 bits.  the number of lines it is allowed is 8.  the number
of pages allowed is 64.  that would take 16k bits.

for images
32*(2**10)*(2**3)  = (word size)(image_lines)(image pages)

each word is 32 bits.  The number of lines it is allowed is 1024.
The number of pages allowed is 8.  That would take about 262144 bits

======
before i forget, the line right after the header should be about the
dimension of the plate.  it will always be a rectangle.

So tell me again about how the pixel data is suppose to look like?
I have two choices

choice 1
opcode | color | relative x | relative y |
4 bits    | 8 bits | 10 bits     | 10 bits     |

choice 2
opcode |    | color |    | color |    | color |
4 bits    | 2 | 8 bits | 1| 8 bits | 1 | 8 bits |

choice two would be ideal for space saving.  It might be good
for images.  It would be as if I am naming each color of pixel
from left to right; top to bottom.

The first choice would name a spot on the plate to color.
This would be best for shapes.  but it can also be used for images.
This would be a good choice because everything would be similar
and require less components to decipher it.  it also brings ups the
possibility of shading it in a polygons.


=====
Eventually I'll have to decide  on which one to pick in order flesh everything out.

Once I have it I can start fleshing out the components that I will need in order to make this dream a reality.  Gosh, I never thought I'd be diving in to operating system concepts
just to do this.  I'm glad that i am thought.  It makes me think
as a computer scientist.  I'm glad that this very important class
is coming back up.  It lets me practice the idea of paging.

HA! maybe this is a step toward making an of run onto of the
FPGA after i get a cpu to start running on it.  I could probably use
the BOOK's code and from there I dunno I haven't thought that
far out.

vga

It is a wonderful day because I have figured out the vga timer once again.  

The problem probably had something to do with the PES clock.

The first few moments, the output would be undefined.  The

screen I tested on probably saw that undefined ness and put up

a flag that said "problem" and refused to work.  After I took

care of that problem it all started to work.  Its funny how that little 

small start of undefined signal messed everything up.

Another thing that contributed to the problem was that the h counter and

v counter were not counting at the right time.  The v counter should 

increment when ever the h counter was reset to zero.  But for some 

reason, it would increment when h counter reached 400.  

These two problems were eventually solved.  The first one was solved 

by modifying the pes_clock such that  clock_out was given its value soon

after starting up.  It used to have to wait until the process reached its 

max count before giving it a value.

The second was solved by making the the v counter count on the

falling edge of the v_clk.  Even though it gave a warning during synthesis

all I care is that it works.