Category - Amiga-VSC

Posts related to Amiga Video Scan Converter.

1
Bug Katcher on Agnus
2
EEVBLOG does a video teardown on the Amiga 500!
3
progress on amiga vsc made this weekend, VSYNC problem persists
4
Cause of most of my noise is likely a sample error
5
Video artifacts present in scan doubled video
6
Removed the black bar, amiga VSC is starting to work much better
7
Getting closer….
8
Yay! Initial shots from the VSC!
9
finally got some work into the VSC
10
switching design from DRAM to ALTRAMs

Bug Katcher on Agnus

I swear I already posted about this but heck if I can find the post.  Anyways, here’s a photo of a bug katcher installed on Agnus on a Commodore Amiga 500.

This gives me the ability to attach a logic analyzer to Agnus which is normally difficult because of the PLCC package that Agnus uses.  You insert the bug katcher into the PLCC socket on the amiga motherboard, and then plug agnus into the katcher.  You can then attach the logic analyzer leads to the labelled (very nice) pins on top of the bug katcher. And speaking of labels, how cool are the HP logic analyzer leads that are also color coded and also labelled with the numbers.  In both cases, this really helps prevent making mistakes when hooking up the test equipment.

The one I’ve got is here.

http://www.emulation.com/pdf/F4535.pdf

bug_katcher_installedbk_in_action

EEVBLOG does a video teardown on the Amiga 500!

Dave just posted this! I’m so glad to see him take this on!

http://www.eevblog.com/2013/03/13/eevblog-438-amiga-500-retro-computer-teardown

progress on amiga vsc made this weekend, VSYNC problem persists

Worked on the Amiga VSC this past weekend at Notacon with my super smart friend Brian P.  We made some progress, including eliminating all but the smallest HSYNC related bugs.

There is still a problem that is haunting us with VSYNC where the screen is shifting up and down constantly.  We have not uncovered a clue to what the problem is despite many theories and attempts.

I’ll post a picture and new video soon.

 

Cause of most of my noise is likely a sample error

I haven’t put much time lately into the amiga VSC but I put in a little tonight.

I’ve got the image cleaner than it has been, but there is still noise on the left hand side, and a left-center band of scrolling red dots.

These dots are sampling error for sure because when they occur, usually the two samples that I take don’t agree.  I should be able to get more than one 10ns sample of a 140ns data, and so perhaps something is drifting until it gets onto a signal boundary, and then comes back again.  I’d like to see this in the data itself, so perhaps I need more captures.

I submitted the current code to the SVN repo….

 

Video artifacts present in scan doubled video

I uploaded a video to youtube that shows some video artifacts happening with the scan doubled video.

The entire video shakes as if interlaced, but it’s not. Original res 320×200(15.7khz), doubled to 640×400.(~31khz)

There is a colored wavy pattern across the white sections.

Video showing artifacts

On a monitor directly attached to the amiga, the screen is very stable, crisp, and nice looking. 🙂

 

Removed the black bar, amiga VSC is starting to work much better

Here’s a screen shot of the amiga vsc in action.  As you can see, there’s been much improvement from the last session.

Even though I am now passing the amiga’s VSYNC through the FPGA to the monitor, I wasn’t resetting my Y coordinate in my hvsync generator module. What this meant was that the module thought it was blanking when it wasn’t — spitting out a scrolling black bar.  On receipt of a VSYNC from the amiga, I now adjust the Y coordinate appropriately. (set it to 435, for what it’s worth)

 

 

Getting closer….

So a few versions later, trying some different failed attempts, I am finally starting to get a little closer.  Here’s the best video I’ve got so far, but my image is still scrolling.

If I can fix the scrolling issue, which I suppose is related to VSYNC, then maybe things might be looking better.

The things that give me hope are:

  • Size is basically correct, taking up the whole output screen.
  • Colors all look right
  • Text is basically readable
  • Some artifacts around the edges of the graphics, but nothing too horrible

Yay! Initial shots from the VSC!

So I got everything hooked up tonight, and the good news is that I have definitely made some progress!

It appears to work, although the video is currently scrolling with multiple video problems, but I definitely have something to work with!

finally got some work into the VSC

Ok, so I’ve finally got some work done on this tonight.

I’ve decided to go to a 4-line buffer system because it’s a more round number than 3 — makes everything easier to deal with.

I’ve gotten rid of the dram controller, and all associated circuitry. Create (4) dual-port rams, instantiated my amiga video acquisition module.

Good progress tonight. Still have to create the write FSM for grabbing the data from the amiga module and writing it into the correct line buffer. Should be easy but at 1:33am local time, I’ve got to sleep.

I wanted to keep the work modularized and so I needed what I believe is called a (one-hot?) decoder — which takes a single write enable signal, and a 2-bit select signal for the write bank, and then outputs four separate signals so that only one of the signals is enabled at a time. All are sitting on standby, but only one line buffer will only be written to, every 320 pixels. All are being fed an x-coordinate for a write address.

 

I haven’t had a chance to simulate this, but I think it’ll work.  Here’s my code:

module wren_decoder(
select,
bank_wrens,
master_wren
);</code>

input [1:0] select;
input master_wren;
output reg [3:0] bank_wrens ;

always @ (select or master_wren)
begin
if (master_wren) begin
case (select)
2'd0 : bank_wrens = 4'b0001;
2'd1 : bank_wrens = 4'b0010;
2'd2 : bank_wrens = 4'b0100;
2'd3 : bank_wrens = 4'b1000;
endcase
end
else begin

bank_wrens = 4'b0000;

end

end

endmodule

If master_wren is disabled, then all four rams see wr_enable disabled.

If master_wren is enabled, then based on the bank selection, the correct ram is enabled for writing.

Each ram gets their wr_enable signal tied to bank_wrens[0], bank_wrens[1], and so on......

Look ok?

 

switching design from DRAM to ALTRAMs

So as my last couple posts alluded to, I’ve been having problems with my DRAM-based design.

My controller isn’t dual-port.

And I’ve been trying to wrap my head around a time-slot method for arbitration.  And optimizing memory controllers.

Then it struck me — my incoming and outgoing data rate access to the memory is exactly the same.  Because my output is twice the resolution, but half the frequency, the per-frame time is the same for 640×400 @ 32khz as for 320×200 @ 15.7khz.

So if the data rates are the same, what’s stopping me from just putting a little buffer in-line, and forgetting all this complicated DRAM access time issues?

I ran it past my super smart friend Brian, and he’s thinks it’s a fine idea.  He recommended perhaps a three line buffer, using separate rams for each line, cycling through each buffer for each incoming/outgoing line.

I’m convinced that the simplest solution is always the best solution which leaves less room for error.

I’m excited about having a new way of moving forward on this. I’ve been stagnant for a couple weeks but that is changing soon enough.