<![CDATA[FPGA Arcade — C64]]> http://www.fpgaarcade.com/punbb/index.php Wed, 15 Aug 2018 21:07:09 +0000 PunBB <![CDATA[Crispy's NTSC C64 Core]]> http://www.fpgaarcade.com/punbb/viewtopic.php?id=1351&action=new Thanks for the feedback!

Wed, 15 Aug 2018 21:07:09 +0000 http://www.fpgaarcade.com/punbb/viewtopic.php?id=1351&action=new
<![CDATA[VICE testbench]]> http://www.fpgaarcade.com/punbb/viewtopic.php?id=1341&action=new "But you really need to do actual debugging and reverse engineering on such kits to know or even slightly imagine what pain in the a* it can be to find nasty bugs and what is needed for that."

sure thing. it was my primary job for a decade now - that testsuite (and the respective fixes in chameleon and/or VICE) didnt come from nowhere smile

Mon, 23 Apr 2018 21:56:18 +0000 http://www.fpgaarcade.com/punbb/viewtopic.php?id=1341&action=new
<![CDATA[Upgraded to latest ARM firmware now C64 doesn't work]]> http://www.fpgaarcade.com/punbb/viewtopic.php?id=1305&action=new I think it's the arm firmware which is at issue, not the core.
I'm away travelling for a few days, but I'll try an copy the latest over to the release area.
update - just tried to build and there was an issue. I'll look at is asap, sorry.

Sun, 30 Jul 2017 19:34:56 +0000 http://www.fpgaarcade.com/punbb/viewtopic.php?id=1305&action=new
<![CDATA[Ultimate-64]]> http://www.fpgaarcade.com/punbb/viewtopic.php?id=1298&action=new Have you tried the CC64 core ...?

Fri, 14 Jul 2017 12:01:42 +0000 http://www.fpgaarcade.com/punbb/viewtopic.php?id=1298&action=new
<![CDATA[6502 core from visual6502.org]]> http://www.fpgaarcade.com/punbb/viewtopic.php?id=1204&action=new i'm curious how many of the edge cases it would get right... and even more, how much more resources it takes compared to a core written in vhdl directly

Tue, 08 Nov 2016 23:16:10 +0000 http://www.fpgaarcade.com/punbb/viewtopic.php?id=1204&action=new
<![CDATA[keyboard not working]]> http://www.fpgaarcade.com/punbb/viewtopic.php?id=1037&action=new Yup same keyboard work fine for the amiga. When the c64 core doesnt take any input i'm still able to use the osd w/o problem though.

It's a good old ps/2 logitech keybord

Tue, 08 Dec 2015 07:27:50 +0000 http://www.fpgaarcade.com/punbb/viewtopic.php?id=1037&action=new
<![CDATA[paddles]]> http://www.fpgaarcade.com/punbb/viewtopic.php?id=533&action=new For paddles only, this output would require to discharge the two lines via two transistors or at least two Schottky diodes to decouple them (they must/can charge with different slopes, on a real setup they would also have separate periods).

An adapter from both 9pin ports to one 9pin "paddle port" could work as well, this should also work for mice.

I can try these two variants - at least to learn if it would work in principle...

It would be much easier to use the auxio pins from the expansion pins on the 2.54mm grid on the other side of the board and solder a separate 9pin connector from there for paddles. One could even solder a wire bridge from that connector to the point "behind" the protection resistor of the two pins from the 9-pin connectors (= 4 bridge wires) on the board. Doing that, the capacitor values could be also changed to match the C64/VIC-20 circuitry more closely (so it would also provide a similar charge/discharge timing).

But this will be a solution not suitable for everyone, so I currently focus on an emulation (based on usual input devices everyone should have at home).

Tue, 08 Sep 2015 14:43:57 +0000 http://www.fpgaarcade.com/punbb/viewtopic.php?id=533&action=new
<![CDATA[C65 compatibility?]]> http://www.fpgaarcade.com/punbb/viewtopic.php?id=462&action=new there is almost no software for it (the demo disks, and one or two scene demos) and that doesnt even work on all C65s (they are all prototypes, each a little bit different to the next) - which is pretty much the reason why noone bothered to implement a proper C65 emulator either.

Thu, 23 Apr 2015 14:35:43 +0000 http://www.fpgaarcade.com/punbb/viewtopic.php?id=462&action=new
<![CDATA[Video modes]]> http://www.fpgaarcade.com/punbb/viewtopic.php?id=396&action=new Is it/will it be possible to have the proper aspect ratio (I guess 4:3) when using a 16:9 screen connected through DVI? Currently the image is stretched to fullscreen.

Update: as mentioned by MikeJ in another thread, the aspect ratio is better handled by setting up the monitor/TV to 4:3.

Fri, 12 Dec 2014 18:31:36 +0000 http://www.fpgaarcade.com/punbb/viewtopic.php?id=396&action=new
<![CDATA[Disk file support for 1541 core (d64, g64, ...)]]> http://www.fpgaarcade.com/punbb/viewtopic.php?id=376&action=new http://csdb.dk/release/?id=73533&show=summary  It was on berlios.de but this project page seems to be down (or the URL is wrong), just google for 1541-Testsuite_r192.zip - better than nothing for a start...  wink

Edit: found the project again on SF:

Wed, 05 Nov 2014 18:01:02 +0000 http://www.fpgaarcade.com/punbb/viewtopic.php?id=376&action=new
<![CDATA[Cartridge support (crt, ...)]]> http://www.fpgaarcade.com/punbb/viewtopic.php?id=382&action=new Yes, I do this already for C64/VIC-20 when loading CRT or PRG files on the fly via OSD. Halt/Reset behaviour can be controlled with the loadselect option in INI files, I would do it also for a save option there...

Mon, 06 Oct 2014 05:26:42 +0000 http://www.fpgaarcade.com/punbb/viewtopic.php?id=382&action=new
<![CDATA[C64 & 1541 download package for Replay board (preliminary versions)]]> http://www.fpgaarcade.com/punbb/viewtopic.php?id=364&action=new New release. All Lorenz CPU tests pass incl. undoc. opcodes, as well as most (and especially important) CIA tests. Fixed a VIC-II interrupt issue caused troubles with some games (or intros in front of games) causing them to stall. Many more games will work now, only very few might not work. Please note this is a PAL core, so pure NTSC games won't work (like on a real PAL C64).

-- Relates to SVN version 1082 --

Sun, 28 Sep 2014 19:50:36 +0000 http://www.fpgaarcade.com/punbb/viewtopic.php?id=364&action=new
<![CDATA[C64 Test Code]]> http://www.fpgaarcade.com/punbb/viewtopic.php?id=327&action=new

Sorry, but how hard can it be to have at least one comment line at the begin of the program to tell what it does? I don't speak about a 10 page article for each and every program. Independent of program complexity, this is something every serious programmer does automatically, because it is trivial to do as well and required by any proper coding guideline I know.

well :) generally i agree, and often when i touch those programs, i add either a readme (which i prefer) or some comments into the code... in many cases the lack of comments is simply heritage from the dark ages =)

however, when the code is something like

ldx #0
stx $dc04
lda $dc04
sta result,x
bne loop

(this is basically what the ciavarious tests do in a bunch of variations) then IMHO a one line comment ("cycle exact timer A latch and count test") isnt really useful at all - you'll have to read the code anyways, or give a rather lengthy description on what exactly happens (in every single cycle) or the description will be rather useless. And well, for anyone who tries to implement a cycle exact CIA, it shouldnt take longer to understand that code than reading the respective description =P

It is simply waste of time to read through sources of others just to get out what they do, especially when I am looking for a specific test for an actual HW problem to fix (and not setting up a regression test). At the end I save my time and just start coding the test myself, especially if it is a simple one, before spending my time to browse through several files to check what it does (and even worse when figuring out it is -hopefully not- useless stuff as you mention  )

thats a different problem imho (picking a test for some specific problem you have) - personally i find reading through individual readmes or sourcecodes equally annoying... which is why i also started adding readmes to individual directories that explain briefly what each program does.

bottom line is: sure, ideally there should be comments and readmes - however in the past people were often too lazy to write test programs, let alone comment them properly :) recently written ones should be commented and described (see eg here) as you say... and the older stuff is being updated slowly, mostly when some of the tests fail for me and i have to explain the problem to peter :=)

so i guess that you can add "people writing comments and readmes" to the above mentioned list of what i am looking for, even if i dont really expect to find them here =)

edit: coming back to your first post, i find those old diagnostic cartridges and programs from cbm pretty useless myself as well ... eg there is some "burn in" test for the CBM-II which fails in VICE ("CIA BAD!") and even after several hours disassembling i have no clue wth the problem is exactly.

Fri, 13 Jun 2014 01:24:28 +0000 http://www.fpgaarcade.com/punbb/viewtopic.php?id=327&action=new
<![CDATA[MISC]]> http://www.fpgaarcade.com/punbb/viewtopic.php?id=316&action=new Ok, I'll set something up...

Tue, 03 Jun 2014 21:25:06 +0000 http://www.fpgaarcade.com/punbb/viewtopic.php?id=316&action=new
<![CDATA[C64 & 1541 core status and compatibility list]]> http://www.fpgaarcade.com/punbb/viewtopic.php?id=299&action=new I might have one of the best fpga/c64 dudes interested in helping out with the c64 core.
What areas of the core needs work? Wolfie could you try to describe the current state? What has been done? What can be improved? What needs to be implemented?

Sun, 04 May 2014 11:04:19 +0000 http://www.fpgaarcade.com/punbb/viewtopic.php?id=299&action=new