Welcome, Guest. Please login or register.

Author Topic: C128 in an FPGA?  (Read 9708 times)

Description:

0 Members and 1 Guest are viewing this topic.

Offline dirkv

  • Newbie
  • *
  • Join Date: Dec 2007
  • Posts: 6
    • Show only replies by dirkv
Re: C128 in an FPGA?
« Reply #44 from previous page: March 29, 2013, 09:53:42 PM »
Publish the sources so everyone can see that is your work.
 

Offline ferrellsl

Re: C128 in an FPGA?
« Reply #45 on: March 29, 2013, 09:57:48 PM »
@kamelito

I'm with you 100%.  It's so rare that anyone recreates our old 8-bit loves that it's hard not to get pushy or impatient about it......sorry if I sounded harsh.
 

Offline ferrellsl

Re: C128 in an FPGA?
« Reply #46 on: March 29, 2013, 10:01:15 PM »
@Gaula92 and FrenchShark

Amiga.org is such a lively and colorful place!  There's more drama here than on a b-grade soap opera!  I hate to admit it, but sometimes I surf this board just for the drama.  Thanks for keeping it interesting!
 

Offline FrenchShark

  • Full Member
  • ***
  • Join Date: Jan 2004
  • Posts: 181
    • Show only replies by FrenchShark
    • http://www.arcaderetrogaming.com
Re: C128 in an FPGA?
« Reply #47 on: March 29, 2013, 11:20:32 PM »
Quote from: dirkv;730742
Publish the sources so everyone can see that is your work.


`include "arg_defs.vh"

module Agnus /* verilator tracing_off */
(
  // Main reset & clock
  input             rst,        // Global reset
  input             ram_rdy,    // SDRAM ready
  input             clk,        // Master clock (28/56/85 MHz)
  // Generated clocks
  output            cck,        // CCK clock
  output            cdac_r,     // CDAC_n rising edge
  output            cdac_f,     // CDAC_n falling edge
  output            c7m_r,      // CPU 7 MHz clock rise
  output            c7m_f,      // CPU 7 MHz clock fall
  output            ena_28m,    // 28 MHz clock enable
  output      [2:0] cyc_28m,    // 28 MHz cycle number
  output     [11:0] cyc_ram,    // RAM sequencer cycles
  // Configuration
  input             cfg_ecs,    // OCS(0) or ECS(1) chipset
  input             cfg_a1k,    // Normal mode(0), A1000 mode(1)
  input       [3:0] cfg_chip,   // Chip RAM size (512 KB - 8 MB)
  // Interrupt
  output            int3_n,     // Level 3 interrupt (Blitter)
  // Video beam position
  output      [7:0] hpos,       // Horizontal position
  output            lol,        // Long line (228 cycles)
  output            eol,        // End of line
  output      [8:0] vpos,       // Vertical position
  output            lof,        // Long field (263 or 313 lines)
  output            eof,        // End of field
  output            pal_ntsc_n, // PAL (1), NTSC (0)
  // DMA / Chip RAM control
  input             dmal,       // DMA request from Paula
  output      [8:1] rga_out,    // Register address bus out
  input      [15:0] db_in,      // Data bus input
  output reg [15:0] db_out,     // Data bus output
  output     [15:0] db_out_er,  // Data bus output (early read)
  output     [22:1] addr_out,   // Chip RAM address output
  output            bus_we,     // Chip RAM write enable
  output            bus_req,    // Chip RAM requested by Agnus
  output            dma_req,    // DMA requested by Agnus
  output            ram_ref,    // Chip RAM refresh request
  // Cache control
  output      [4:0] chan_out,   // DMA channel number
  output            cache_hit,  // DMA cache hit
  output            flush_line, // Flush current write cache line
  // Address decoding
  input       [8:1] rga_in,     // Register address bus in
  input             rregs_dmac, // DMACONR decoding
  input             rregs_vp,   // VPOSR decoding
  input             rregs_vhp,  // VHPOSR decoding
  input             wregs_copc, // COPCON decoding
  input      [10:0] wregs_blt,  // BLTxxxx decoding
  input             wregs_cjp1, // COPJMP1 decoding
  input             wregs_cjp2, // COPJMP2 decoding
  input             wregs_cins, // COPINS decoding
  input             wregs_diwb, // DIWSTRT decoding
  input             wregs_diwe, // DIWSTOP decoding
  input             wregs_ddfb, // DDFSTRT decoding
  input             wregs_ddfe, // DDFSTOP decoding
  input             wregs_dmac, // DMACON decoding
  input             wregs_bplc, // BPLCON0 decoding
  input             wregs_beam, // BEAMCON decoding
  input             wregs_diwh, // DIWHIGH decoding
  input             wregs_fmod  // FMODE decoding
);
// Clock input frequency : 28/57/85 MHz
parameter MAIN_FREQ = 85;

// Internal wires
wire        w_cdac_r;
wire        w_cdac_f;
wire        w_cck;
wire        w_ena_28m;
wire  [2:0] w_cyc_28m;

wire  [7:0] w_hpos;
wire        w_lol;
wire        w_eol;
wire  [8:0] w_vpos;
wire        w_lof;
wire        w_eof;
wire        w_vblend;
wire  [1:0] w_strb;
wire        w_refr;

wire        w_ptr_rd_ena;
wire  [9:2] w_ptr_rd_rga;
wire [22:0] w_ptr_rd_val;
wire        w_mod_rd_ena;
wire  [8:1] w_mod_rd_rga;
wire [22:1] w_mod_rd_val;
wire        w_pos_rd_ena;
wire  [8:2] w_pos_rd_rga;
wire  [8:0] w_spr_vstart;
wire  [8:0] w_spr_vstop;
wire        w_ptr_wr_ena;
wire  [8:2] w_ptr_wr_rga;
wire        w_cpu_wr_ena;

wire        w_cop_dma;
wire [22:1] w_cop_pc;
wire        w_cop_hit;

wire        w_one_dot;
wire        w_ptr_inc;
wire        w_ptr_dec;
wire        w_mod_add;
wire        w_mod_sub;

wire  [4:0] w_chan_out;
wire        w_bst_ena;
wire        w_blt_last;
wire        w_bus_we;

//////////////////////////////////
// Register memory write access //
//////////////////////////////////

reg        r_regs_wr_p2;
reg  [8:1] r_rga_p2;
reg [15:0] r_db_in;

always@(posedge rst or posedge clk) begin
  if (rst) begin
    r_regs_wr_p2 <= 1'b0;
    r_rga_p2     <= 8'hFF;
    r_db_in      <= 16'h0000;
  end else if (cdac_r) begin
    // Global write to register memory
    if ((rga_in[8:1] != 8'hFF) && (rga_in[8:5] != 4'h0))
      r_regs_wr_p2 <= 1'b1;
    else
      r_regs_wr_p2 <= 1'b0;
    r_rga_p2 <= rga_in;
    if (cck) r_db_in <= db_in;
  end
end

assign w_cpu_wr_ena = r_regs_wr_p2 & cck;

/////////////////////
// Registers read //
////////////////////

wire        w_BBUSY;
wire        w_BZERO;

wire [15:0] w_DMACONR;
wire [15:0] w_VPOSR;
wire [15:0] w_VHPOSR;

always@(posedge rst or posedge clk) begin
  if (rst) begin
    db_out <= 16'h0000;
  // Rising edge of CDAC_n with CCK = 0
  end else if (cdac_r & ~cck) begin
    db_out <= ( w_DMACONR & {16{rregs_dmac}} )
            | ( w_VPOSR   & {16{rregs_vp  }} )
            | ( w_VHPOSR  & {16{rregs_vhp }} );
  end
end

// DMACONR bits
assign w_DMACONR[15:12] = {    1'b0,  w_BBUSY, w_BZERO,    1'b0 };
assign w_DMACONR[11:8]  = {    1'b0, r_BLTPRI, r_DMAEN, r_BPLEN };
assign w_DMACONR[7:4]   = { r_COPEN,  r_BLTEN, r_SPREN,    1'b0 };
assign w_DMACONR[3:0]   = 4'b0000; // Bits 4-0 are in Paula

// VPOSR bits
`ifdef AGNUS_PAL
assign w_VPOSR[15:8]    = { w_lof, 7'h20 }; // 8372 rev 4 PAL
`else
assign w_VPOSR[15:8]    = { w_lof, 7'h30 }; // 8372 rev 4 NTSC
`endif
assign w_VPOSR[7:0]     = { w_lol, 6'b000000, w_vpos[8] };

// VHPOSR bits
assign w_VHPOSR[15:8]   = w_vpos[7:0];
assign w_VHPOSR[7:0]    = w_hpos[7:0];

//////////////////////////
// DMA control register //
//////////////////////////

reg       r_BLTPRI;
reg       r_DMAEN;
reg       r_BPLEN;
reg       r_COPEN;
reg       r_BLTEN;
reg       r_SPREN;

wire      w_BPLEN;
wire      w_COPEN;
wire      w_BLTEN;
wire      w_SPREN;

always@(posedge rst or posedge clk) begin
  if (rst) begin
    r_BLTPRI <= 1'b0;
    r_DMAEN  <= 1'b0;
    r_BPLEN  <= 1'b0;
    r_COPEN  <= 1'b0;
    r_BLTEN  <= 1'b0;
    r_SPREN  <= 1'b0;
  end
  // Rising edge of CDAC_n with CCK = 1
  else if ((cdac_r) && (cck)) begin
    if (wregs_dmac) begin
      if (db_in[15]) begin
        // Set
        r_BLTPRI <= r_BLTPRI | db_in[10];
        r_DMAEN  <= r_DMAEN  | db_in[9];
        r_BPLEN  <= r_BPLEN  | db_in[8];
        r_COPEN  <= r_COPEN  | db_in[7];
        r_BLTEN  <= r_BLTEN  | db_in[6];
        r_SPREN  <= r_SPREN  | db_in[5];
      end
      else begin
        // Clear
        r_BLTPRI <= r_BLTPRI & ~db_in[10];
        r_DMAEN  <= r_DMAEN  & ~db_in[9];
        r_BPLEN  <= r_BPLEN  & ~db_in[8];
        r_COPEN  <= r_COPEN  & ~db_in[7];
        r_BLTEN  <= r_BLTEN  & ~db_in[6];
        r_SPREN  <= r_SPREN  & ~db_in[5];
      end
    end
  end
end

assign w_BPLEN = r_BPLEN & r_DMAEN;
assign w_COPEN = r_COPEN & r_DMAEN;
assign w_BLTEN = r_BLTEN & r_DMAEN;
assign w_SPREN = r_SPREN & r_DMAEN;

/////////////////////////
// Address computation //
/////////////////////////

wire        w_next_line;
wire [22:1] w_ptr_inc_val;
wire [22:1] w_ptr_val;
reg  [22:0] r_ptr_wr_val;
reg  [22:1] r_addr_out;
reg         r_cache_hit;
reg         r_flush_line;
reg         r_bus_we;

assign w_next_line   = w_one_dot                            // One dot mode
                     | w_mod_add                            // Add modulo
                     | w_mod_sub                            // Subtract modulo
                     | ( (&w_ptr_rd_val[3:1]) & w_ptr_inc)  // Increment 7->0
                     | (~(|w_ptr_rd_val[3:1]) & w_ptr_dec); // Decrement 0->7
assign w_ptr_inc_val = { {21{w_ptr_dec}}, w_ptr_inc | w_ptr_dec };
assign w_ptr_val     = w_ptr_rd_val[22:1] + w_ptr_inc_val;

always@(posedge rst or posedge clk) begin
  if (rst) begin
    r_ptr_wr_val <= 23'd0;
    r_addr_out   <= 22'd0;
    r_cache_hit  <= 1'b0;
    r_flush_line <= 1'b0;
    r_bus_we     <= 1'b0;
  end else if (cdac_r & ~cck) begin
    // Muxer between DMA pointer and Copper's PC
    if (w_cop_dma) begin
      // Copper DMA
      r_addr_out  <= w_cop_pc & { cfg_chip, 18'b111_11111111_1111111 };
      r_cache_hit <= w_cop_hit & r_BSTMODE[4];
    end else begin
      // Other DMA
      r_addr_out  <= w_ptr_rd_val[22:1] & { cfg_chip, 18'b111_11111111_1111111 };
      r_cache_hit <= (w_ptr_rd_val[0] | w_bus_we) & w_bst_ena;
    end
   
    // Write cache flush
    r_flush_line <= (w_blt_last | w_next_line | ~w_bst_ena) & w_bus_we;
   
    // Write enable (Disk or Blitter)
    r_bus_we <= w_bus_we;
   
    // Compute next address (with cache hit flag)
    if (w_mod_add) begin
      // Add modulo
      r_ptr_wr_val[22:1] <= w_ptr_val + w_mod_rd_val;
    end else if (w_mod_sub) begin
      // Subtract modulo
      r_ptr_wr_val[22:1] <= w_ptr_val - w_mod_rd_val;
    end else begin
      // Increment/decrement address
      r_ptr_wr_val[22:1] <= w_ptr_val;
    end
    r_ptr_wr_val[0] <= ~w_next_line;
  end
end

assign addr_out   = r_addr_out;
assign chan_out   = w_chan_out;
assign cache_hit  = r_cache_hit;
assign flush_line = r_flush_line;
assign bus_we     = r_bus_we;

....

does it look like Minimig to you ?
 

Offline FrenchShark

  • Full Member
  • ***
  • Join Date: Jan 2004
  • Posts: 181
    • Show only replies by FrenchShark
    • http://www.arcaderetrogaming.com
Re: C128 in an FPGA?
« Reply #48 on: March 29, 2013, 11:55:14 PM »
And for the fun the scheduler ROM of the VIC-II :

LIBRARY IEEE;
USE IEEE.STD_LOGIC_1164.ALL;
USE IEEE.STD_LOGIC_ARITH.ALL;
USE IEEE.STD_LOGIC_UNSIGNED.ALL;

ENTITY video_vicII_rom_sched IS
  PORT(
    -- ROM clock
    clock : IN  STD_LOGIC;
    -- ROM address
    addr  : IN  STD_LOGIC_VECTOR(7 DOWNTO 0);
    -- ROM read enable
    rdena : IN  STD_LOGIC;
    -- ROM data
    dout  : OUT STD_LOGIC_VECTOR(29 DOWNTO 0)
  );
END video_vicII_rom_sched;

ARCHITECTURE rtl of video_vicII_rom_sched IS

  TYPE ROM_type IS ARRAY(0 TO 255) OF STD_LOGIC_VECTOR(29 DOWNTO 0);

  CONSTANT sched_rom : ROM_type :=
  (
------------------------------------
-- NTSC chip (65 cycles per line) --
------------------------------------

--                                       cycle: access: hcount:
    "001110010111111110000000000100", -- 13/14    VIC     000 \
    "001110010111111110000000000000", -- 13/14    CPU     004  | Refresh
    "001110000111111110000000000100", --   15     VIC     008 /
    "001110000111111110000000000001", --   15     CPU     00C \
    "001110000111111110000000000010", --   16     VIC     010  |
    "001110000111111110000000000001", --   16     CPU     014  |
    "001110000111111110000000000010", --   17     VIC     018  |
    "001110000111111110000000000001", --   17     CPU     01C  |
    "001110000111111110000000000010", --   18     VIC     020  |
    "001110000111111110000000000001", --   18     CPU     024  |
    "001110000111111110000000000010", --   19     VIC     028  |
    "001110000111111110000000000001", --   19     CPU     02C  |
    "001110000111111110000000000010", --   20     VIC     030  |
    "001110000111111110000000000001", --   20     CPU     034  |
    "001110000111111110000000000010", --   21     VIC     038  |
    "001110000111111110000000000001", --   21     CPU     03C  |
    "001110000111111110000000000010", --   22     VIC     040  |
    "001110000111111110000000000001", --   22     CPU     044  |
    "001110000111111110000000000010", --   23     VIC     048  |
    "001110000111111110000000000001", --   23     CPU     04C  |
    "001110000111111110000000000010", --   24     VIC     050  |
    "001110000111111110000000000001", --   24     CPU     054  |
    "001110000111111110000000000010", --   25     VIC     058  |
    "001110000111111110000000000001", --   25     CPU     05C  |
    "001110000111111110000000000010", --   26     VIC     060  |
    "001110000111111110000000000001", --   26     CPU     064  |
    "001110000111111110000000000010", --   27     VIC     068  |
    "001110000111111110000000000001", --   27     CPU     06C  |
    "001110000111111110000000000010", --   28     VIC     070  |
    "001110000111111110000000000001", --   28     CPU     074  |
    "001110000111111110000000000010", --   29     VIC     078  |
    "001110000111111110000000000001", --   29     CPU     07C  |
    "011110000111111110000000000010", --   30     VIC     080  |
    "011110000111111110000000000001", --   30     CPU     084  |
    "011110000111111110000000000010", --   31     VIC     088  |
    "011110000111111110000000000001", --   31     CPU     08C  |
    "011110000111111110000000000010", --   32     VIC     090  |
    "011110000111111110000000000001", --   32     CPU     094  |
    "011111000111111110000000000010", --   33     VIC     098  |
    "011110000111111110000000000001", --   33     CPU     09C  |
    "011110000111111110000000000010", --   34     VIC     0A0  |
    "000110000111111110000000000001", --   34     CPU     0A4  | 40 characters fetch
    "000110000111111110000000000010", --   35     VIC     0A8  |
    "000110000111111110000000000001", --   35     CPU     0AC  |
    "000110000111111110000000000010", --   36     VIC     0B0  |
    "001110000111111110000000000001", --   36     CPU     0B4  |
    "001110000111111110000000000010", --   37     VIC     0B8  |
    "001110000111111110000000000001", --   37     CPU     0BC  |
    "001110000111111110000000000010", --   38     VIC     0C0  |
    "001110000111111110000000000001", --   38     CPU     0C4  |
    "001110000111111110000000000010", --   39     VIC     0C8  |
    "001110000111111110000000000001", --   39     CPU     0CC  |
    "001110000111111110000000000010", --   40     VIC     0D0  |
    "001110000111111110000000000001", --   40     CPU     0D4  |
    "001110000111111110000000000010", --   41     VIC     0D8  |
    "001110000111111110000000000001", --   41     CPU     0DC  |
    "001110000111111110000000000010", --   42     VIC     0E0  |
    "001110000111111110000000000001", --   42     CPU     0E4  |
    "001110000111111110000000000010", --   43     VIC     0E8  |
    "001110000111111110000000000001", --   43     CPU     0EC  |
    "001110000111111110000000000010", --   44     VIC     0F0  |
    "001110000111111110000000000001", --   44     CPU     0F4  |
    "001110000111111110000000000010", --   45     VIC     0F8  |
    "001110000111111110000000000001", --   45     CPU     0FC  |
    "001110000111111110000000000010", --   46     VIC     100  |
    "001110000111111110000000000001", --   46     CPU     104  |
    "001110000111111110000000000010", --   47     VIC     108  |
    "001110000111111110000000000001", --   47     CPU     10C  |
    "001110000111111110000000000010", --   48     VIC     110  |
    "001110000111111110000000000001", --   48     CPU     114  |
    "001110000111111110000000000010", --   49     VIC     118  |
    "001110000111111110000000000001", --   49     CPU     11C  |
    "001110000111111110000000000010", --   50     VIC     120  |
    "001110000111111110000000000001", --   50     CPU     124  |
    "001110000111111110000000000010", --   51     VIC     128  |
    "001110000111111110000000000001", --   51     CPU     12C  |
    "001110000111111110000000000010", --   52     VIC     130  |
    "001110000111111110000000000001", --   52     CPU     134  |
    "001110000111111110000000000010", --   53     VIC     138  |
    "001110000111111110000000000001", --   53     CPU     13C  |
    "001110000111111110000000000010", --   54     VIC     140  |
    "001110000111111110000000000001", --   54     CPU     144  |
    "001110000111111110000000010010", --   55     VIC     148 /
    "001110000111111111000000010000", --   55     CPU     14C \
    "001110000111111111000000011000", --   56     VIC     150  |
    "001110000111111111000000010000", --   56     CPU     154  |
    "001110000111111101000000001000", --   57     VIC     158  |
    "001110000111111101000000000000", --   57     CPU     15C  | Idle cycles
    "001110000111111101000000001000", --   58     VIC     160  |
    "001110000111111101000000000000", --   58     CPU     164  |
    "001110000111111001000000001000", --   59     VIC     168  |
    "001110000111111001000000000000", --   59     CPU     16C /
    "001110001111111001000000100000", --   60     VIC     170 \
    "001110000111111001000001000000", --   60     CPU     174  | Sprite #0 fetch
    "001110000111110001000010000000", --   61     VIC     178  |
    "001110000111110001000100000000", --   61     CPU     17C /
    "001110000111110011001000100000", --   62     VIC     180 \
    "001110000111110011001001000000", --   62     CPU     184  | Sprite #1 fetch
    "011110000111100011001010000000", --   63     VIC     188  |
    "011110000111100011001100000000", --   63     CPU     18C /
    "011110000111100111010000100000", --   64     VIC     190 \
    "011100000111100111010001000000", --   64     CPU     194  | Sprite #2 fetch
    "011100000111000111010010000000", --   65     VIC     198  |
    "011100100111000111010100000000", --   65     CPU     19C /
    "011100000111001111011000100000", --   01     VIC     1A0 \
    "011100000111001111011001000000", --   01     CPU     1A4  | Sprite #3 fetch
    "000000000110001111011010000000", --   02     VIC     1A8  |
    "000000000110001111011100000000", --   02     CPU     1AC /
    "000000000110011111100000100000", --   03     VIC     1B0 \
    "000000000110011111100001000000", --   03     CPU     1B4  | Sprite #4 fetch
    "001000000100011111100010000000", --   04     VIC     1B8  |
    "001000000100011111100100000000", --   04     CPU     1BC /
    "001000000100111111101000100000", --   05     VIC     1C0 \
    "001000000100111111101001000000", --   05     CPU     1C4  | Sprite #5 fetch
    "001100000000111111101010000000", --   06     VIC     1C8  |
    "001100000000111111101100000000", --   06     CPU     1CC /
    "101100000001111111110000100000", --   07     VIC     1D0 \
    "101100000001111111110001000000", --   07     CPU     1D4  | Sprite #6 fetch
    "101100000001111111110010000000", --   08     VIC     1D8  |
    "101100000001111111110100000000", --   08     CPU     1DC /
    "101100000011111111111000100000", --   09     VIC     1E0 \
    "001100000011111111111001000000", --   09     CPU     1E4  | Sprite #7 fetch
    "001100000011111111111010000000", --   10     VIC     1E8  |
    "001110000011111111111100000000", --   10     CPU     1EC /
    "001110000111111111000000000100", --   11     VIC     1F0 \
    "001110000111111111000000000000", --   11     CPU     1F4  |
    "001110000111111110000000000100", --   12     VIC     1F8  | Refresh
    "001110000111111110000000000000", --   12     CPU     1FC /
------------------------------------
-- PAL chip  (63 cycles per line) --
------------------------------------
<...>
  );

BEGIN

PROCESS(clock, addr, rdena)
BEGIN
  IF (rising_edge(clock)) AND (rdena = '1') THEN
    dout <= sched_rom(conv_integer(addr));
  END IF;
END PROCESS;

END rtl;

I "stole" it from this excellent document :http://www.filegate.net/cbm/6-tech/pal_time.txt I am a bad guy :-D
 

Offline FrenchShark

  • Full Member
  • ***
  • Join Date: Jan 2004
  • Posts: 181
    • Show only replies by FrenchShark
    • http://www.arcaderetrogaming.com
Re: C128 in an FPGA?
« Reply #49 on: March 29, 2013, 11:59:21 PM »
Quote from: ferrellsl;730744
@Gaula92 and FrenchShark

Amiga.org is such a lively and colorful place!  There's more drama here than on a b-grade soap opera!  I hate to admit it, but sometimes I surf this board just for the drama.  Thanks for keeping it interesting!

Anytime dude. I am glad you like it.
In case you missed it, there is one piece here : http://www.minimig.net/viewtopic.php?f=9&t=552&start=30
hurry up before the admin deletes it.

Regards,

Frederic
« Last Edit: March 30, 2013, 12:02:16 AM by FrenchShark »
 

Offline gaula92

  • Sr. Member
  • ****
  • Join Date: Dec 2007
  • Posts: 373
    • Show only replies by gaula92
Re: C128 in an FPGA?
« Reply #50 on: March 30, 2013, 12:28:14 AM »
Quote from: FrenchShark;730750
Anytime dude. I am glad you like it.
In case you missed it, there is one piece here : http://www.minimig.net/viewtopic.php?f=9&t=552&start=30
hurry up before the admin deletes it.

Regards,

Frederic


Publishing snippets of code in a forum doesn't prove anything.
You're using Minimig code under the hood and you didn't publish the modified sources in exchange: that's ILLEGAL as the Minimig is GPL.

You actions and reactions speak for themselves.
 

Offline FrenchShark

  • Full Member
  • ***
  • Join Date: Jan 2004
  • Posts: 181
    • Show only replies by FrenchShark
    • http://www.arcaderetrogaming.com
Re: C128 in an FPGA?
« Reply #51 on: March 30, 2013, 09:43:39 AM »
Quote from: gaula92;730754
Publishing snippets of code in a forum doesn't prove anything.
You're using Minimig code under the hood and you didn't publish the modified sources in exchange: that's ILLEGAL as the Minimig is GPL.

You actions and reactions speak for themselves.

I think I have the RIGHT to publish whatever I want from my work.
Since you do not know sh*t about verilog, I will explain to you WHY MY Agnus implementation is different from the Minimig one :
- One master clock at 86 MHz, the others clocks are just clock enable. Why 86 MHz ? because it is the SDRAM clock and 3 times the real Agnus master clock.
- One address generator instead of 6. It saves a lot of resource.
- DMA address related registers are stored in block RAM, it saves a lot of LUTs on Altera architecture.
- A DMA cache that saves 80% of the SDRAM bandwidth.
- It follows the Amiga bus timing : RGA on one cycle, DATA on the next cycle. It also has the early read feature for the Blitter D channel and the Floppy read. That also makes it incompatible with the Minimig chip ram bus.
- True short/long line in NTSC mode. May I remind you that the MCC216 has also a S-Video option ? So, not generating exactly 15734 Hz line rate in NTSC with the exact chroma frequency makes the TV displaying B&W.
- It takes only 10k LEs whereas the DE-1 one barely fits in 22k LEs (I must be a magician) :
http://i1359.photobucket.com/albums/q791/frenchshark/Core_size_zpscf2c088a.png.
Numbers speak for themselves.

How do I achieve that ? With reverse engineering:
http://i1359.photobucket.com/albums/q791/frenchshark/IMG_2972_zps7b329952.jpg
http://i1359.photobucket.com/albums/q791/frenchshark/IMG_2975_zps71b6e04b.jpg
(for example, it takes around 2 weeks to recreate Denise)

Thanks to a friend I have also a C64, an Atari ST and an A500 I can experiment with.
So, one day there will be an Atari ST core but I am sure that gaula92 will say that it got stolen from somewhere else.

Internet if full of stupid people.

too bad.

Frederic
« Last Edit: March 30, 2013, 09:47:11 AM by FrenchShark »
 

Offline yakumo9275

  • Sr. Member
  • ****
  • Join Date: Jun 2008
  • Posts: 301
    • Show only replies by yakumo9275
    • http://mega-tokyo.com/blog
Re: C128 in an FPGA?
« Reply #52 on: March 30, 2013, 12:29:42 PM »
Quote from: FrenchShark;730765
I think I have the RIGHT to publish whatever I want from my work.


not when it involves GPL code you've modified.  by modifying the minimig core to add your own agnus core, your agnus core becomes GPL code because you have made a derivative work of a GPL work.

The GPL requires release/publication of all derivative works when asked for it.

The GPL is what allowed you to use the minimig core in the first place. The GPL requires you give back all your changes.

Congrats for writing a new agnus core, I'm sure its not easy, and your doing a lot of hard work on your device, but that does not make you compliant with the GPL.
--/\\-[ Stu ]-/\\--
Commodore 128DCR, JiffyDOS, Ultimate 1541 II, uIEC/SD, CBM 1902A  Monitor
 

Offline FrenchShark

  • Full Member
  • ***
  • Join Date: Jan 2004
  • Posts: 181
    • Show only replies by FrenchShark
    • http://www.arcaderetrogaming.com
Re: C128 in an FPGA?
« Reply #53 on: March 30, 2013, 01:17:12 PM »
Quote from: yakumo9275;730772
not when it involves GPL code you've modified.  by modifying the minimig core to add your own agnus core, your agnus core becomes GPL code because you have made a derivative work of a GPL work.

The GPL requires release/publication of all derivative works when asked for it.

The GPL is what allowed you to use the minimig core in the first place. The GPL requires you give back all your changes.

Congrats for writing a new agnus core, I'm sure its not easy, and your doing a lot of hard work on your device, but that does not make you compliant with the GPL.


Maybe you do not get it : I have my own Paula, Denise, Agnus and Gary, it is not derivative work.
The Agnus chip I wrote cannot work with the Minimig HDL : different clocking scheme, different bus protocol. The same for Paula and Denise. Gary is designed to interface with a SDRAM controller and has autoconfig logic for Fast RAM. Between Gary and the chipset, there is a DMA cache.

I started with Denise (see the previous links), then Paula. I ran the two chips on my A2000 HW with different games and demos.
After that I wrote Agnus and simulate the 3 chips together using test copperlist.
BTW, the neat feature on the Amiga is that you can exercise the chipset without a 68000.
Finally I wrote Gary and the 8520 then connected the J68 core.
And I have done more simulations like this one :
http://i1359.photobucket.com/albums/q791/frenchshark/snapshot0111_boot_menu_3_zps541996cc.png?t=1364648469

Not one verilog module is from Minimig source.
 

Offline gaula92

  • Sr. Member
  • ****
  • Join Date: Dec 2007
  • Posts: 373
    • Show only replies by gaula92
Re: C128 in an FPGA?
« Reply #54 on: March 30, 2013, 02:56:11 PM »
Quote from: FrenchShark;730776
Maybe you do not get it : I have my own Paula, Denise, Agnus and Gary, it is not derivative work.

Thay may be true for an unreleased core, but the core running in your commercial product HAS BEEN a primitive Minimig for almost two years.
You have been selling a product with GPL code closed and expanded without opening back the sources.
And the fact that this product is badly built is just and additional problem.

You also left the buyers of your product without support or updates: people having problems with the C64 core were left without critical fixes, and the Amiga core stalled for almost two years also.
Even when you offered some kind of support, that irritating Retrofan with stupid phrases like "long live retro!" and no technical knowledge was all we got.

No: this is NO WAY of dealing with users. Look at other projects, like MikeJ's FPGA Arcade, Turbo Chameleon 64 or the original Minimig V1.1 board: thanks to their transparent, open-source nature, we are getting mature and stable products with a good and active community behind them.

In the other hand, your product is obscure, unsupported and faulty after all this time. You get what you deserve.
« Last Edit: March 30, 2013, 03:10:01 PM by gaula92 »
 

Offline FrenchShark

  • Full Member
  • ***
  • Join Date: Jan 2004
  • Posts: 181
    • Show only replies by FrenchShark
    • http://www.arcaderetrogaming.com
Re: C128 in an FPGA?
« Reply #55 on: March 30, 2013, 04:19:29 PM »
Quote from: gaula92;730781
Thay may be true for an unreleased core, but the core running in your commercial product HAS BEEN a primitive Minimig for almost two years.
You have been selling a product with GPL code closed and expanded without opening back the sources.

Finally, is it primitive or expanded ? Do you want the modified Minimig ? Fine, you will just discover that all the modifications were already posted on the minimig.net website.
Minimig is also a commercial product and it will cost you just the double to get only a board (if you can find one).
Do you really think I am making money doing that ?

Quote

And the fact that this product is badly built is just and additional problem.

You also left the buyers of your product without support or updates: people having problems with the C64 core were left without critical fixes, and the Amiga core stalled for almost two years also.

Critical fixes on the C64 ? On lot of points, it is better than the others cores.
I know I have one bug on the sprites and one on the scrolling. It is just an issue for some tricky demos and few games.

I cannot work on everything 24/7, I have a life. Moreover, I do not get motivated when I read your BS.

Quote

Even when you offered some kind of support, that irritating Retrofan with stupid phrases like "long live retro!" and no technical knowledge was all we got.

I am not responsible of others' behaviours.

Quote

No: this is NO WAY of dealing with users. Look at other projects, like MikeJ's FPGA Arcade, Turbo Chameleon 64 or the original Minimig V1.1 board: thanks to their transparent, open-source nature, we are getting mature and stable products with a good and active community behind them.

In the other hand, your product is obscure, unsupported and faulty after all this time. You get what you deserve.


It looks like you are the only one spreading your sh*t on the forums. I get positive feedback from a lot of people.
 

Offline gaula92

  • Sr. Member
  • ****
  • Join Date: Dec 2007
  • Posts: 373
    • Show only replies by gaula92
Re: C128 in an FPGA?
« Reply #56 on: March 30, 2013, 05:09:25 PM »
Quote
Finally, is it primitive or expanded ?

Primitive in the sense that you took an early Minimig core and expanded (adapted) it to work with your product.

I don't think you get much positive feedback: ask other MCC-216 users around in the Lemon64 forums, where you started announcing your product years ago, if you dare.
Bashing me won't change these facts:

"Your currently available Amiga core, wich has been available for almost two years, and wich you SOLD as part of your product, is a modified Minimig core, and is ILLEGAL as you never released the sources, even if you are working on your own Minimig implementation now".

"You chose cheap materials and the MCC-216 is easy to break: power button, power supply are very bad quality"

"You and Retrofan retired from the unofficial support forums months ago, thus leaving users without any kind of support, with broken cores."

Now if someone gives positive feedback, well, better for you. But I wouldn't recommend anything from you and I for one will stay away from whatever you come up with. There are FAR better alternatives.

As an angered ex-mcc216 owner, my hatred comes from your actions. I don't know you nor had anything against you to begin with. If you had proceeded as expected (by opening up your modified Minimig sources, fixing critical C64 bugs like keyboard problems and disk writting, etc) I would be a proud user giving good feedback as I do with the Minimig V1.1 board, the FPGA Arcade or the TC64, wich are great products.
You have been claiming that your product is also an AppleII implementation. You advertise it as souch here:

http://arcaderetrogaming.com/shop/category_100/ClassicComputer.html?sessid=iAfQ4wXcKUTiBSvQrUBQREQhvRV8zBwrp0kisg6KYhqh0s1jP7klTm2cp3P9LKjY&shop_param=cid%3D%26

..but the sad fact is that it won't even load an AppleII disk image.
Should we ask AppleII core developer what he thinks about you, by the way? Do you want me to ask him and post the answer here? ;)

I'm not spreading s h i t: after being scammed once, I'm just trying to inform other people about what you did so they can judge.
« Last Edit: March 30, 2013, 05:19:40 PM by gaula92 »
 

Offline FrenchShark

  • Full Member
  • ***
  • Join Date: Jan 2004
  • Posts: 181
    • Show only replies by FrenchShark
    • http://www.arcaderetrogaming.com
Re: C128 in an FPGA?
« Reply #57 on: March 30, 2013, 06:36:09 PM »
Quote from: gaula92;730787
Primitive in the sense that you took an early Minimig core and expanded (adapted) it to work with your product.

I don't think you get much positive feedback: ask other MCC-216 users around in the Lemon64 forums, where you started announcing your product years ago, if you dare.
Bashing me won't change these facts:

"Your currently available Amiga core, wich has been available for almost two years, and wich you SOLD as part of your product, is a modified Minimig core, and is ILLEGAL as you never released the sources, even if you are working on your own Minimig implementation now".


Amiga core is not SOLD, it is just free of charge, like others cores.
If you have to pay extra for some cores, it is because of software licensing (ROM, games, etc...). You can buy the bare stuff and populate the SD-Card with the necessary cores and files if you know how to get the files.

Quote

"You chose cheap materials and the MCC-216 is easy to break: power button, power supply are very bad quality"

$1.34 for a switch I do not call that cheap.
http://octopart.com/r13-529bl-05-bgg-shin+chin-20074423
Price does not mean quality anymore with 90% of electronics parts coming from china.

Quote

"You and Retrofan retired from the unofficial support forums months ago, thus leaving users without any kind of support, with broken cores."

Now if someone gives positive feedback, well, better for you. But I wouldn't recommend anything from you and I for one will stay away from whatever you come up with. There are FAR better alternatives.

That's great I will not get any more complains then.

Quote

As an angered ex-mcc216 owner, my hatred comes from your actions. I don't know you nor had anything against you to begin with. If you had proceeded as expected (by opening up your modified Minimig sources, fixing critical C64 bugs like keyboard problems and disk writting, etc) I would be a proud user giving good feedback as I do with the Minimig V1.1 board, the FPGA Arcade or the TC64, wich are great products.
You have been claiming that your product is also an AppleII implementation. You advertise it as souch here:

http://arcaderetrogaming.com/shop/category_100/ClassicComputer.html?sessid=iAfQ4wXcKUTiBSvQrUBQREQhvRV8zBwrp0kisg6KYhqh0s1jP7klTm2cp3P9LKjY&shop_param=cid%3D%26

..but the sad fact is that it won't even load an AppleII disk image.
Should we ask AppleII core developer what he thinks about you, by the way? Do you want me to ask him and post the answer here? ;)

I'm not spreading s h i t: after being scammed once, I'm just trying to inform other people about what you did so they can judge.


I was in contact with Alex. I gave him all that was necessary for porting the core.
I did not write the apple 2 core. If he has something to say, he can send me an e-mail.
You can post whatever you want here : just be cautious there are forum rules so do not cross the red line.
 

Offline juga

  • Newbie
  • *
  • Join Date: Jul 2011
  • Posts: 6
    • Show only replies by juga
Re: C128 in an FPGA?
« Reply #58 on: March 30, 2013, 08:40:35 PM »
Hi. I am a happy owner of three MCC-216 VGA and one MCC-216 S-Video.

I mostly use them with the C64 core done by Frenchshark, and will start tinkering with the Amiga core once it is launched.

The C64 core works pretty well with old and new C64 games, some of the most important features it has are:

- PAL and NTSC C64 models supported
- Stereo 8580 SIDs support with filters
- Perfect smooth scrolling if your monitor supports the MCC resolutions / refresh frequencies
- 1541 emulation with read and write support of D64 images, with good compatibility with fast loaders
- Support of mount of up to 10 d64 images for multi disk games
- Very fast reset and startup of the C64 core: less than 4 seconds boot including the d64 images mount
- Supports very well the JiffyDOS rom and JiffyDOS 1541II rom for fast loading of d64 images
- Swap joysticks feature (swap ports 1 <-> port 2): only needs one joystick
- Proprietary USB joypad support
- Mouse support (PS2 mouse)
- Very nice and colorful menu for selecting the games / disc images
- Very good games compatibility (above 90% based on tested games)

I wrote down an article on lemon64 forum with some tips for using the C64 core, it has almost all you need to know to use it (strengths and weaknesses too), you can read it here:
http://www.lemon64.com/forum/viewtopic.php?t=34194&start=550

The MCC-216 works very well for me and for many other people, you can check the customer’s feedback from Ebay buyers:
http://feedback.ebay.com/ws/eBayISAPI.dll?ViewFeedback2&userid=arcaderetrogaming&ftab=AllFeedback&myworld=true

For a C64 fan that wants to run games on new hardware I would definitively recommend it, and I expect that the new Amiga core that it is coming will be great too.

Regards, Juan
 

Offline FrenchShark

  • Full Member
  • ***
  • Join Date: Jan 2004
  • Posts: 181
    • Show only replies by FrenchShark
    • http://www.arcaderetrogaming.com
Re: C128 in an FPGA?
« Reply #59 on: March 30, 2013, 09:03:29 PM »
Quote from: juga;730798
Hi. I am a happy owner of three MCC-216 VGA and one MCC-216 S-Video.

I mostly use them with the C64 core done by Frenchshark, and will start tinkering with the Amiga core once it is launched.

The C64 core works pretty well with old and new C64 games, some of the most important features it has are:

- PAL and NTSC C64 models supported
- Stereo 8580 SIDs support with filters
- Perfect smooth scrolling if your monitor supports the MCC resolutions / refresh frequencies
- 1541 emulation with read and write support of D64 images, with good compatibility with fast loaders
- Support of mount of up to 10 d64 images for multi disk games
- Very fast reset and startup of the C64 core: less than 4 seconds boot including the d64 images mount
- Supports very well the JiffyDOS rom and JiffyDOS 1541II rom for fast loading of d64 images
- Swap joysticks feature (swap ports 1 <-> port 2): only needs one joystick
- Proprietary USB joypad support
- Mouse support (PS2 mouse)
- Very nice and colorful menu for selecting the games / disc images
- Very good games compatibility (above 90% based on tested games)

I wrote down an article on lemon64 forum with some tips for using the C64 core, it has almost all you need to know to use it (strengths and weaknesses too), you can read it here:
http://www.lemon64.com/forum/viewtopic.php?t=34194&start=550

The MCC-216 works very well for me and for many other people, you can check the customer’s feedback from Ebay buyers:
http://feedback.ebay.com/ws/eBayISAPI.dll?ViewFeedback2&userid=arcaderetrogaming&ftab=AllFeedback&myworld=true

For a C64 fan that wants to run games on new hardware I would definitively recommend it, and I expect that the new Amiga core that it is coming will be great too.

Regards, Juan


Thanks Juan. You don't have to to do that.
Be careful you will get some bashing from some guys here :-).
Moreover, your only 3-post count will look suspicious, maybe it is me writing this comment :-)
Anyway, with any product, you cannot get 100% of the customers happy, that's a rule.

Regards,

Frederic