Look!!! I found something!

The SOCoCo-80 Project

A Possible Eureka Moment

Big Indian Little Indian – Why slap my Papoose!

I think I have an answer to the Dynamic RAM write problem. This is going to get complicated and it hasn’t been verified yet. But, it looks to be a very curious and possible solution.   Let me first explain the problem. The driver that I’m using for the DRAM was written by another. The data transferred is in 32 bit wide segments. To discriminate the data into an 8 byte data segment I used address lines 15-2 for the DRAM address and A1-A0 to pull out the 8 bit data (4 8 bit blocks in a 32 bit data word). This is simple enough and assuming the driver works as I thought, all would be well.   But, what I was getting was data coming in in places where it shouldn’t be in th 32 bit field. For instance trying to read data bits 16-23 would read back on bits 8-15. Things weren’t coming back correctly. I thought I found a solution on the read function by re-sequencing the data read in a case statement. This worked fine but I still couldn’t explain it. When I got to the write function, things really got strange. I was reading data that wasn’t even in the blocks I was reading in. Then when I wrote the data out, it was in the wrong locations. Arrrg.

RTFM – Read the F’ing Manual

I had some free time today so I glanced at the datasheets for the Dynamic RAM on the DE-1 board. I found that the original author was using a 2 word data burst mode. This means that 2 16 bit data words will appear on the bus in a 2 clock sequence. Now here’s the kicker. In 2 word burst mode the A0 bit determines the order in which the data comes in sequentially. Since I’ve been sending A1 from the CPU as A0 to the RAM, the burst would change the order of the data every other word.   OK, I know this is complicated but now that I see this, it makes sense. This also explains why in the original authors test code he/she increases the address by 2. This forces the A0 to always be at zero (reset starts the address at 0) – All even addresses.   The fix would be to fix A0 to 0 in my address pass to the driver. This needs to be tested but we’ll see. If this doesn’t work, I’m going to change the driver initialization to use Burst mode 1 which sends one 16 bit word at a time.   ..and away we go --- TESTING!!!! Wooo Hoo

© 2013 – Franklin Laboratories

                                               

                                   

"DRAM DRAM - Oh Tatoo, you're so funny"

The SOCoCo-80 Project

DRAM is a Tough Nut to Crack

Dram operation

Well, it’s been a few weeks since my last post. I haven’t forgotten about the project. I had a few life bumps to deal with. That being said (or typed in this case), I have made some strides with the project. As I mentioned before, this project is going to happen in phases. Phase one was to develop a working SOC using a 6809 model as it’s CPU template. Phase two will be a hardware component for the Color Computer. I’m still on phase one.   The video uses the SDRAM of the DE-1 board. Dealing with the timing between the CPU and the video is not for the faint at heart. I decided to use the Dynamic RAM (DRAM) for the CPU. DRAM unlike SRAM has to be processed by a procedure sequence. This process includes initialization, read access, write access and refresh. There’s also burst functionality and bus width problems to deal with.   In my search for an easy solution nothing I tried fit until I came across a small test module by someone named lsilvest. He/She wrote a three part module that tests the DRAM on the de-1 board. I used one of his/her modules as a driver base. Then I wrote my own interface core. This core seems to work except I’m having some issues with the write cycle. I hope to have those issues cleared up soon.   One thing about using DRAM is that because it’s a “procedural” device, I have to slow the CPU way down to allow the RAM to go through its motions. The DRAM root frequency is 133.3MHz. The controller has to allow for clock cycles to complete tasks. The interface controller is then running at 50MHz to allow the DRAM controller to do it’s thing. Now, to interface with the CPU, I have to run the CPU even slower to allow the interface module to do its thing. I haven’t determined what speed I can run the CPU at yet but it looks like it’s going to be around 12MHz or so. We’ll see. Once I get the CPU running fully with DRAM and after I get the video linked to the CPU, I will return to the DRAM driver and make it work more efficiently. This, hopefully, will allow the CPU to run faster.

© 2013 – Franklin Laboratories

The Video is Working

<!--[if gte mso 10]> <![endif]

The SOCoCo-80 Project

It’s Working!!!

Most Graphic Modes Are active – few more to go

It’s been a few days since my last post. I’ve been working hard on the video functions. As I posted before, I’m going to finish the video and worry about the CPU sync later. Although, I’m thinking about that repeatedly as I move forward with the project. I have some really good successes over the last few days. Although the pesky 1st pixel is still a problem, it’s effect isn’t as drastic as before. It is showing up in all modes and I'm convinced it’s a timing problem somewhere. I thought I found it but, no. The video function simulates correctly I see no anomalies anywhere. Moving on I went through and finished several video modes. Below are some screen shots of the 640x480 256, 64, 16 and 16 gray color modes. These photos were taken with my Acer tablet camera so they’re not the best in the world. They do show the different levels of color dithering needed to make a good picture. The procedures to create these images are as follows… Open the files in Photoshop Convert to the specific index mode using custom palettes (or Window for 256 color mode) Save as a BMP file with the “Flip Row Order” flag set. Photos need to be saved upside down. With a binary editor, remove the metadata (top file info – See web for more info. Load it in the SRAM The Screen Shots: 640x480x256 Colors  640x480x64 Colors 640x480x16 Colors 640x480x16 Gray Levels (Note: the white border was on the original photo)

Text Mode Seems to Work

The text mode was the next hurdle. I have done a text character generator before but as I rewrote all my video drivers, this will be no exception. I decided to incorporate the driver into the video function and not make it a separate function as I did before. The text character generator consists of a ROM table and some code. It samples the RAM each horizontal bit. Through some clever bit manipulation it calculates the proper ROM address for the font table. After getting the ROM data, it determines if the bit should be ON or OFF. If ON, it selects the proper foreground color to display and if OFF it selects the proper background color. The photo below shows the result. The colors depend on the mode (16/2 color mode). In 16 color mode, it gets the color from the same 16 color palette that the graphics mode uses. In two color mode, it uses a 2 palette register. The image below is just some garbage in RAM along with some text I grabbed from the blog. This is just to show how it looks. 80x25x16 Color Text Mode  80x25x16 Color This one is all green text just like the old monochrome monitors. I did this just for fun. Well, that’s all for now…

© 2013 – Franklin Laboratories

                                               

                                   

--> -->

A New Video Mode

The SOCoCo-80 Project

Back to the Drawing Board

Rethinking the Video Controller

With my work on the DDr functionality and it’s complexities, I decided to take a brain rest and take another look at the video. Although in the past, I had a working prototype of the video controller with many modes working, it wasn’t complete. So, I decided to finish the video driver as a way to relieve some brain pain.   Taking the code in an earlier blog, I created a test project. I actually used the code from the blog because in an effort to clean up my project files, I deleted my video source files. Silly me. I placed the function in this new project and fired her up. And to my shock… No Video (well sort of)!!!   What? This was working fine when I posted it. I spent two days trying to track down the problem. I was convinced it was a timing problem. I was getting video colors but no access to the video RAM. No pictures were showing after I downloaded them. Looking at the specs of the RAM chip, I noticed that the valid data area was about 8 nsec after the address lines were stable. My code was reading immediately. To correct the problem, I split the clock into two phases. i_CLOCK and i_eCLOCK where i_eCLOCK is 90 degrees lagging i_CLOCK. I placed the data fetch function in the i_eCLOCK, fired her up and BINGO… same problem.   Man was this frustrating. What could be wrong. It worked before. I also noticed when it was working. I was passing control signals through an mmu function. This was my attempt at interfacing the video and CPU. My new thought was that somehow the mmu delays were just right to get the RAM to work. This would be a problem because the access was to sensitive to hardware changes.   It was late on Saturday, while watching the Blackhawks win against Boston I was parooszing the test code. HOLY CRAP!!! I see it!! It’s right in front of me! The problem wasn’t in the video code, it was in the quickie test function I wrote. I declared the RAM address bus as an input not an output. Changing this to an output made everything all good again. My code worked fine. However for now, I plan on leaving the 90 degree lag in the timing.

A New Mode

Continuing to finish the video driver I am organizing it for a typical CPU interface. I added a chip select, Read/Write, Data In, Data Out (wishbone) and Register Select lines. These will operate as any digital interface chips signals will. The RegSel lines will connect to the CPU lower address lines to allow the selection of several registers. Data In, Data Out and R/W are self-explanatory and the chip select will act as a strobe. This may change to a clock signal later.   One by one, I wrote and tested each video mode. I started with the graphics modes because they are the easiest to implement. Basically they all work the same way. The code generates a RAM address based on the horizontal and vertical counters in the sync generator. The data from the RAM is then read in at the location of the address. After some discrimination processes, a color value for the Red, Green and Blue is calculated based on the mode. These values are puked to the hardware for display.     640x480x64 colors 320x200x64 colors    These modes are one pixel per byte where the byte is divided:                                                                         xxBBGGRR The 2 bits for each color gives 4 levels of that color (4*4*4=64 total colors). The two “xx” bits are not used and are ignored.   320x240x256 colors 640x480x256 colors  One would think that this would be the easiest to implement but it’s not. Researching this mode I discovered that there a couple of approaches that can be taken. Either calculate the color based on some formula or have a look-up table. I opted for the look-up table. Using a ROM simulator I created a 2 byte per color register. The table was hand written in a text editor and the values were that of the standard Windows 256 color BMP tables from PhotoShop. I used this table to make it easier to transfer pictures from other computers as it seems to be one of the main standards.   320x240x16 colors 640x480x16 colors    This mode will use a “user programmable” palette register group. Just like the CoCo, a 16 register group will be assigned to each nibble in the video memory. The palette register will actr as a look-up table for each of the 16 values in the nibble.                                                                         Xxxx yyyy   This poses a small problem though, the other modes above has 1 pixel per byte. This mode (and others to follow) will have 2 pixels per byte. I needed to make some changes in the way I was creating the RAM address calculations to facilitate these modes. It complicated the source a bit but it works fine.   320x240x16G 640x480x16G             These are two new modes I added from the original specification. This is basically a 16 level grey (or is it gray?). mode. I implemented it just because it wasn’t too far from the 16 color mode and it just took me about a hour to test.     I still have some work to do on the driver. The text modes and the 2 color modes are next. But, with looking at the timing with a larger magnifying lens, I’m thinking that I might be able to go back to doing this entirely in static RAM, CPU and Video. It’s looking like what I thought was a RAM speed problem may have been the way I implemented the MMU. I will put the CPU back in and rewrite the MMU controller once I get the video done.   Oh, one more thing… I had to change the video timing generator slightly because that pesky extra pixel showed it’s ugly face again. I found another counting error that needed some attention. I won’t say it’s fixed (been there – done that) but it seems somewhat better.   I do plan on posting the code later this week. I might wait until I get the text modes working though. I haven’t decided yet.   We keep moving forward…

© 2013 – Franklin Laboratories