Loading ...
Sorry, an error occurred while loading the content.

Re: FPGA-64 with Optional Board + Custom Extender

Expand Messages
  • Peter
    Hi, ... VHDL/FPGA check FPGA-64 check C-One no check So it is 2/3 on topic ;-) More on topic as most off-topic posts ehh never mind.. ... Your welcome! We
    Message 1 of 5 , Mar 30, 2009
    View Source
    • 0 Attachment
      Hi,

      --- In cone_cores@yahoogroups.com, "Magnus Wedmark" <magnus.wedmark@...> wrote:
      >
      > Hi all,
      >
      > I'm using a Digilent/Xilinx Spartan-3E 1600E MicroBlaze Starter Kit card together with my own Extender card dubbed ArcadeExtender and trying to get FPGA-64 rolling on it. Hope this doesn't rule me out from this community or makes this post be off-topic.. otherwise tell me!

      VHDL/FPGA check
      FPGA-64 check
      C-One no check

      So it is 2/3 on topic ;-) More on topic as most off-topic posts ehh never mind..

      > It is working out quite well with FPGA-64, the 64 is booting BASIC and an example PacMan-cart (In VHDL form) that I've got from Peter also work! Thanks Peter! It uses a soft-SID that I've incorparated into the FPGA which I found on the net. How do you guys normally handle SID, hard-SID?

      Your welcome!
      We (C-One owners) can put a real SID chip on the C-One board.

      > I'm mapping 64 KByte of BRAM into the C64 as usual, also having the PacMan-cartridge where cartridges go: $8000. As it is mapped just now it doesn't actually autostart, I just start it with "SYS 33696" from BASIC so that also works!

      Then your mapping is not 100%. As the ROM should autostart. Could it be that it is invisible for a while due to a bug in $0000/$0001 I/O mapping or the memory emulation (the kernal will look for a "CBM80" identification in the 8000 area very early in the startup). Reading at $8000 till $9000 will read from ROM. Writing will write to the ram below it. With the registers at $00/$01 you can switch the ROM in and out of the memory space. Details are in the C64 reference manual (or somewhere on the internets). I think somebody typed (or OCRed) the C64 ref man as I have a .txt version. Try to google for it.

      > It also maps Kernal+Char+BASIC as a usual C64 but using BRAM.
      >
      > Now I want to be able to test more stuff (read programs/games/demos) easily and my setup does not really make use of the SD-Card today... I've written a C# program to convert a given *.PRG file to a VHDL file that can be used to exchange the main RAM in the VHDL. Then this is used when rebuilding the FPGA-64 and should make it boot with the particular program loaded into memory but it does not work as expected. As I understand, there maybe a problem with Bank switching

      Ok in a PRG the first two bytes are the load offset (normally $01 and $08) you need to strip those of the file and place the rest of the data at $0801 onwards. When the kernal loads a file from disk in also updates a bunch of pointers and such that tell the basic interpreter the begin and end of the program. If that isn't done you won't see anything with LIST, but if it is a assembler program you can still type the "SYS <addr>" yourself to let it run.
      That would be sys 2061 in your example.

      >that makes the memory NOT be placed correctly. I've tried a small SID+Graphics-demo I found on the net located at $0801 of which I would like to be at least be able to hear the output from.. The PRG-file works when dropped into VICE but does not seem to be mapped correctly when using FPGA-64. What happens in VICE when you drop a file on it? What happens in the real 64 when you load a PRG-file? It seem to autostart in VICE.. How do I get the FPGA-64 to use RAM at $0800 and forward? As I recall didn't the BASIC interpreter start using mem at $0800 so maybe the program starts with a SYS.. IN the binary the program seem have the char "2061" within itself..
      >
      > I've tried to Google it and find out what is missing/clicking but for now I don't know where to look. I can supply the exact PRG.file if anyone want try it out!

      Studying the ROM disassembly of the tape/disk load and save routines in the kernal might help. Though it requires some 6502 assembly knowledge to follow.

      > I'm using FPGA-0.20 as this was the version that was available when I looked at the project before.

      It is kinda old, but should be able to run most programs. Keep in mind that some games require the read-only registers of the SID. They use the SID as random number generator if these are missing it won't work. I did at one time implement a emulation of these registers. It should be in 0.20 search for sidrandom. If the soft-sid you use has them you don't need the emulation ofcourse.

      >
      > Hope you guys have any idea to get my FPGA-64 get going with Bank switching and the Soft-SID! That would be great!

      You can also send a mail to pwsoft at syntiac dot com (thats me) with specific questions about fpga-64.

      >
      > Keep up the good work done here! I would love to give back anything if there is anything I could do or share?
      >
      > Best Regards
      > Magnus
      >

      Hope it helps,
      Peter
    • Magnus Wedmark
      Ahh nice! I mananged to fix the problems! The problem with the Pacman-Cartridge was self-inflicted when comparing to the original I replaced one character in
      Message 2 of 5 , Apr 5 1:15 AM
      View Source
      • 0 Attachment
        Ahh nice! I mananged to fix the problems! The "problem" with the Pacman-Cartridge was self-inflicted when comparing to the original I replaced one character in the "CBM80" sequence to be able to both have PacMan in memory and still boot with the prompt.. but this not my main problem either.

        The Main memory of the C64 was, and is still in 0.27, created as:

        type testMainRamDef is array(16383 downto 0) of unsigned(7 downto 0);

        which makes the memory be instanciated backwards so to speak. This is not a problem when starting with empty memory, but will become troublesome when/if trying to start with some initialized memory. Either one has to init the memory backwards or..

        By switching it to:
        type testMainRamDef is array(0 to 16383) of unsigned(7 downto 0);
        everything works like a charm. Thanks Mikael (friend offlist) for pointing this out to me! I had been staring a little bit too long on the lines to see it..

        So now my SID-example is sound great! One smaller problem now is that everything executes just a tad too fast so this is the next problem to fix. By looking at the readme's for newer versions of FPGA-64 cores it seems like this has been fixed, is that correct?

        The infrastructure of FPGA-64 seem to have changed quite alot between 0.20 and 0.27 (especially concerning vicii) and the file 'fpga64_xess_xsa3s1000.vhd' that I use as basis for porting FPGA-64 to my hardware-setup seem orphaned (not updated). Is there any plans on updating that file or has anyone already done it? I will try it myself but it is a little bit of a guessing game.. A bigger question might be, will there be any more open source for FPGA-64 now that 0.28 became closed?

        Thanks, Best Regards
        Magnus

        --- In cone_cores@yahoogroups.com, "Peter" <pwsoft@...> wrote:
        >
        > Hi,
        >
        > --- In cone_cores@yahoogroups.com, "Magnus Wedmark" <magnus.wedmark@> wrote:
        > >
        > > Hi all,
        > >
        > > I'm using a Digilent/Xilinx Spartan-3E 1600E MicroBlaze Starter Kit card together with my own Extender card dubbed ArcadeExtender and trying to get FPGA-64 rolling on it. Hope this doesn't rule me out from this community or makes this post be off-topic.. otherwise tell me!
        >
        > VHDL/FPGA check
        > FPGA-64 check
        > C-One no check
        >
        > So it is 2/3 on topic ;-) More on topic as most off-topic posts ehh never mind..
        >
        > > It is working out quite well with FPGA-64, the 64 is booting BASIC and an example PacMan-cart (In VHDL form) that I've got from Peter also work! Thanks Peter! It uses a soft-SID that I've incorparated into the FPGA which I found on the net. How do you guys normally handle SID, hard-SID?
        >
        > Your welcome!
        > We (C-One owners) can put a real SID chip on the C-One board.
        >
        > > I'm mapping 64 KByte of BRAM into the C64 as usual, also having the PacMan-cartridge where cartridges go: $8000. As it is mapped just now it doesn't actually autostart, I just start it with "SYS 33696" from BASIC so that also works!
        >
        > Then your mapping is not 100%. As the ROM should autostart. Could it be that it is invisible for a while due to a bug in $0000/$0001 I/O mapping or the memory emulation (the kernal will look for a "CBM80" identification in the 8000 area very early in the startup). Reading at $8000 till $9000 will read from ROM. Writing will write to the ram below it. With the registers at $00/$01 you can switch the ROM in and out of the memory space. Details are in the C64 reference manual (or somewhere on the internets). I think somebody typed (or OCRed) the C64 ref man as I have a .txt version. Try to google for it.
        >
        > > It also maps Kernal+Char+BASIC as a usual C64 but using BRAM.
        > >
        > > Now I want to be able to test more stuff (read programs/games/demos) easily and my setup does not really make use of the SD-Card today... I've written a C# program to convert a given *.PRG file to a VHDL file that can be used to exchange the main RAM in the VHDL. Then this is used when rebuilding the FPGA-64 and should make it boot with the particular program loaded into memory but it does not work as expected. As I understand, there maybe a problem with Bank switching
        >
        > Ok in a PRG the first two bytes are the load offset (normally $01 and $08) you need to strip those of the file and place the rest of the data at $0801 onwards. When the kernal loads a file from disk in also updates a bunch of pointers and such that tell the basic interpreter the begin and end of the program. If that isn't done you won't see anything with LIST, but if it is a assembler program you can still type the "SYS <addr>" yourself to let it run.
        > That would be sys 2061 in your example.
        >
        > >that makes the memory NOT be placed correctly. I've tried a small SID+Graphics-demo I found on the net located at $0801 of which I would like to be at least be able to hear the output from.. The PRG-file works when dropped into VICE but does not seem to be mapped correctly when using FPGA-64. What happens in VICE when you drop a file on it? What happens in the real 64 when you load a PRG-file? It seem to autostart in VICE.. How do I get the FPGA-64 to use RAM at $0800 and forward? As I recall didn't the BASIC interpreter start using mem at $0800 so maybe the program starts with a SYS.. IN the binary the program seem have the char "2061" within itself..
        > >
        > > I've tried to Google it and find out what is missing/clicking but for now I don't know where to look. I can supply the exact PRG.file if anyone want try it out!
        >
        > Studying the ROM disassembly of the tape/disk load and save routines in the kernal might help. Though it requires some 6502 assembly knowledge to follow.
        >
        > > I'm using FPGA-0.20 as this was the version that was available when I looked at the project before.
        >
        > It is kinda old, but should be able to run most programs. Keep in mind that some games require the read-only registers of the SID. They use the SID as random number generator if these are missing it won't work. I did at one time implement a emulation of these registers. It should be in 0.20 search for sidrandom. If the soft-sid you use has them you don't need the emulation ofcourse.
        >
        > >
        > > Hope you guys have any idea to get my FPGA-64 get going with Bank switching and the Soft-SID! That would be great!
        >
        > You can also send a mail to pwsoft at syntiac dot com (thats me) with specific questions about fpga-64.
        >
        > >
        > > Keep up the good work done here! I would love to give back anything if there is anything I could do or share?
        > >
        > > Best Regards
        > > Magnus
        > >
        >
        > Hope it helps,
        > Peter
        >
      • Peter
        Hi Magnus, ... Ok. ... And it is only 1/4 of the necessary memory needed for a complete C64 emulation. But that was the biggest block that I could fit into the
        Message 3 of 5 , Apr 5 3:20 AM
        View Source
        • 0 Attachment
          Hi Magnus,

          --- In cone_cores@yahoogroups.com, "Magnus Wedmark" <magnus.wedmark@...> wrote:
          >
          > Ahh nice! I mananged to fix the problems! The "problem" with the Pacman-Cartridge was self-inflicted when comparing to the original I replaced one character in the "CBM80" sequence to be able to both have PacMan in memory and still boot with the prompt.. but this not my main problem either.

          Ok.

          >
          > The Main memory of the C64 was, and is still in 0.27, created as:
          >
          > type testMainRamDef is array(16383 downto 0) of unsigned(7 downto 0);
          >
          > which makes the memory be instanciated backwards so to speak. This is not a problem when starting with empty memory, but will become troublesome when/if trying to start with some initialized memory. Either one has to init the memory backwards or..

          And it is only 1/4 of the necessary memory needed for a complete C64 emulation. But that was the biggest block that I could fit into the 3s1000 fpga. You should really switch to using external memory to get the full 64k.

          >
          > By switching it to:
          > type testMainRamDef is array(0 to 16383) of unsigned(7 downto 0);
          > everything works like a charm. Thanks Mikael (friend offlist) for pointing this out to me! I had been staring a little bit too long on the lines to see it..

          I will make the same change in my archive to help future users.

          >
          > So now my SID-example is sound great! One smaller problem now is that everything executes just a tad too fast so this is the next problem to fix. By looking at the readme's for newer versions of FPGA-64 cores it seems like this has been fixed, is that correct?

          Yes, but that is a C-One specific fix. The C-One lacks any PLLs or DCMs to scale the clock. I've created a little circuit that does fractional clock division. The result however is a clock with a lot of jitter. Not a real problem for the CPU, but it is for the video. So I've also added a new scandoubler (called fpga64_scanconverter) that can 'un-jitter' the video signal. Some people reported problems with this however. Some TFT screens don't like the resulting video signal (it is not VGA compliant). It steals a few pixels from each scanline to have some spare time at the end to compensate for the time creep caused by the jittered clock.

          You probably have a newer FPGA on your board so you should use PLLs/DCMs to fix the speed properly and keep using the simple scandoubler.

          >
          > The infrastructure of FPGA-64 seem to have changed quite alot between 0.20 and 0.27 (especially concerning vicii) and the file 'fpga64_xess_xsa3s1000.vhd' that I use as basis for porting FPGA-64 to my hardware-setup seem orphaned (not updated). Is there any plans on updating that file or has anyone already done it? I will try it myself but it is a little bit of a guessing game.. A bigger question might be, will there be any more open source for FPGA-64 now that 0.28 became closed?

          Most are cosmetic changes in the signal names. What did change is the way the bus is switched between the VIC and CPU. The VIC has an extra signal that tells when it needs the bus. This fixes a weird graphic artifact in some DMA-delay effects.

          I've made a gentleman agreement with Jens not to release any fixes I do on the VIC-II emulation until the Chameleon cartridge is available on the market. This forced me to make FPGA-64 closed sourced for the last bug-fix release. But the whole project starts to get obsolete now we have decided to release a Chameleon core for free for the C-One plus extender-board. I try to keep as much open as possible. I did for example release the 800x600 test core under LGPL license. And a sdram controller example for the extender-board is underway.

          If you run into problems stitching the new code into your obsolete 0.20 tree let me know. I probably can help explaining why and how pins have changed. But comparing the cone_top between 0.20 and 0.27 should give all the answers in principle.

          Peter

          >
          > Thanks, Best Regards
          > Magnus
        • Magnus Wedmark
          ... OK i just copied the row I had from 0.20 to get the correct reference for you. On my card I actually used (65535 downto 0) by because of I missed the
          Message 4 of 5 , Apr 13 11:58 AM
          View Source
          • 0 Attachment
            > And it is only 1/4 of the necessary memory needed for a complete C64 emulation. But that was the biggest block that I could fit into the 3s1000 fpga. You should really switch to using external memory to get the full 64k.

            OK i just copied the row I had from 0.20 to get the correct reference for you. On my card I actually used (65535 downto 0) by because of I missed the connection of the MSB it only mapped 32767 of those.. after fixing that the BRAM wasn't big enough both for RAM+BASIC+KERNAL+CHAR+PACMAN but that was correct..

            > I've made a gentleman agreement with Jens not to release any fixes I do on the VIC-II emulation until the Chameleon cartridge is available on the market.

            OK no problem! I understand and are grateful for ALL code that actually are open already!

            I though I would give feedback to partly good result! I managed to squeeze in 47104 bytes of RAM together with BASIC+Kernal+Char ROM's into my Spartan-3E 1600E based card which makes a more complete C64 although some memory is missing. 100% of BRAM used but about 17% of the logic.

            After testing some games the small game H.E.R.O. booted and worked great. I've been trying out the C64DTV-fixed games as these come in easily translated PRG-files which suits my C64 that is missing secondary storage right now.

            The clock problem could be me connecting the clock in/out incorrectly on the DCM I've used (thanks Mikael) so I'm just rebuilding to try and fix that problem. The strange thing is that it still gives me VGA-picture?? but after looking at the Hz-info on the monitor it gives me 49.5Khz-80Hz so maybe that explains the whole clock problem! :-)
          Your message has been successfully submitted and would be delivered to recipients shortly.