<![CDATA[FPGA Arcade — Cartridge support (crt, ...)]]> http://www.fpgaarcade.com/punbb/viewtopic.php?id=382 Tue, 10 Feb 2015 10:07:16 +0000 PunBB <![CDATA[Re: Cartridge support (crt, ...)]]> http://www.fpgaarcade.com/punbb/viewtopic.php?pid=4563#p4563 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...

]]>
Tue, 10 Feb 2015 10:07:16 +0000 http://www.fpgaarcade.com/punbb/viewtopic.php?pid=4563#p4563
<![CDATA[Re: Cartridge support (crt, ...)]]> http://www.fpgaarcade.com/punbb/viewtopic.php?pid=4562#p4562 Yes, I think this is a great idea.
If the CPU is hanging off the Halt signal, it will stop. Is that sufficient?
/Mike

]]>
Tue, 10 Feb 2015 00:02:44 +0000 http://www.fpgaarcade.com/punbb/viewtopic.php?pid=4562#p4562
<![CDATA[Re: Cartridge support (crt, ...)]]> http://www.fpgaarcade.com/punbb/viewtopic.php?pid=4561#p4561 Seriously, for this flash modules I think it should be sufficient to be able to read/process the CRT files others already prepared and distributed.

But what I'd like to add to the ARM FW is some DRAM snapshot feature to store the memory content of an actual running core to the sdcard (while it is halted to have a consistent state). The start address and width can be specified in the INI file (to adopt it to different cores)

On the one hand this would come in handy for the GEORAM support (like a battery backup feature as the NEORAM has), but it would be also useful to debug any code in the RAM of a running core (and capture screenshots etc.).

]]>
Mon, 09 Feb 2015 23:58:59 +0000 http://www.fpgaarcade.com/punbb/viewtopic.php?pid=4561#p4561
<![CDATA[Re: Cartridge support (crt, ...)]]> http://www.fpgaarcade.com/punbb/viewtopic.php?pid=4557#p4557 crazy man !!
/Mike

]]>
Mon, 09 Feb 2015 23:31:31 +0000 http://www.fpgaarcade.com/punbb/viewtopic.php?pid=4557#p4557
<![CDATA[Re: Cartridge support (crt, ...)]]> http://www.fpgaarcade.com/punbb/viewtopic.php?pid=4555#p4555 Hmm, taking the sdcard to read a file stored there which gets written to an emulated 29F040 on the FPGA using the C64 core which finally just writes the data on the sdcard again...

Yes, why not????  big_smile

]]>
Mon, 09 Feb 2015 23:27:50 +0000 http://www.fpgaarcade.com/punbb/viewtopic.php?pid=4555#p4555
<![CDATA[Re: Cartridge support (crt, ...)]]> http://www.fpgaarcade.com/punbb/viewtopic.php?pid=4549#p4549 There is flash - the SD card wink You can use FileIO to write back to the source file if you are brave.

]]>
Mon, 09 Feb 2015 22:45:32 +0000 http://www.fpgaarcade.com/punbb/viewtopic.php?pid=4549#p4549
<![CDATA[Re: Cartridge support (crt, ...)]]> http://www.fpgaarcade.com/punbb/viewtopic.php?pid=4546#p4546 Good point, Lizard. Easyflash is not really a CRT format "as such" as far as I can see. It is more an universal expansion using a flash-ROM, this cartridge can emulate standard cartriges and something which looks close to a Ocean cartridge (controlled via a bank register on I/O1). And it seems to have some small 256byte RAM on I/O2.

So when I have the Ocean HW, this may (hopefully) work as well for PoP - lets see how close the HW needs to be (ROM/RAM based only, as there is of course no flash to use on the Replay - so the easytools can't really work).

]]>
Mon, 09 Feb 2015 22:27:15 +0000 http://www.fpgaarcade.com/punbb/viewtopic.php?pid=4546#p4546
<![CDATA[Re: Cartridge support (crt, ...)]]> http://www.fpgaarcade.com/punbb/viewtopic.php?pid=4545#p4545 Good link, took me to some SID test code :
http://codebase64.org/doku.php?id=base:sound_fx_routine

]]>
Mon, 09 Feb 2015 21:58:51 +0000 http://www.fpgaarcade.com/punbb/viewtopic.php?pid=4545#p4545
<![CDATA[Re: Cartridge support (crt, ...)]]> http://www.fpgaarcade.com/punbb/viewtopic.php?pid=4543#p4543 Maybe Easyflash support? So we can run Prince of Persia?

]]>
Mon, 09 Feb 2015 20:44:36 +0000 http://www.fpgaarcade.com/punbb/viewtopic.php?pid=4543#p4543
<![CDATA[Re: Cartridge support (crt, ...)]]> http://www.fpgaarcade.com/punbb/viewtopic.php?pid=4542#p4542 Ok, standard 8k/16k and Ultimax 8k/16k CRT files work nicely now on the lastest SVN code I checked in. These were quite easy to set up (they set EXROM/GAME according to the header info). I tried a lot of CRT files I could find and they start up without issues (this are most of the game CRT files with max. 17kB in size - 16kB+header). Interesting also the files from the RGCD C64 cartridge development competition (e.g. here: http://www.rgcd.co.uk/).

The OSD shows also some details of the CRT. Performing a "hard" board reset when trying to load a wrong CRT file is a little harsh - I'll see how to do this in a more "human" way big_smile

I will prepare a new trial package of ARM-FW flasher + C64 core to be downloaded here soon...

Thinking of adding Ocean type CRTs as well (as gpz mentioned, seem to be also quite popular), these need some bank switching stuff and more memory - need to think about to do the DRAM mapping for these, but should be still quite straight forward.

If someone uses e.g. Simons Basic, I can implement this CRT format as well - but as I said, each format requires its own HW, this is quite some work to setup and maintain (and even makes the build more complex with each addon). So it is not really worth just for a few files out there probably no one uses (and instead of using just a d64 version of these) - so I won't do it until there is a specific request from a board user for certain CRT (sub-) format...

]]>
Mon, 09 Feb 2015 16:03:44 +0000 http://www.fpgaarcade.com/punbb/viewtopic.php?pid=4542#p4542
<![CDATA[Re: Cartridge support (crt, ...)]]> http://www.fpgaarcade.com/punbb/viewtopic.php?pid=4538#p4538 Not sure if it is worth it. I currently assume the mice requires the falling edge on the pin5 and pin9 to answer with the PWM in the proportional mode (otherwise I'd say the decoding of the SID won't/can't generate stable data if this is not synchronized). I am investigating on a real c64 to check out how this works, most descriptions found on the web are incomplete (they describe it from the programmers view, not from the HW implementation side of the "handshake" between mouse/sid).

]]>
Sun, 08 Feb 2015 22:33:09 +0000 http://www.fpgaarcade.com/punbb/viewtopic.php?pid=4538#p4538
<![CDATA[Re: Cartridge support (crt, ...)]]> http://www.fpgaarcade.com/punbb/viewtopic.php?pid=4537#p4537 Ok. I remember we discussed this before. We should change the default mount of the inductor powering the joysticks to 5V then. This can be done by moving L17 to L16.
/MikeJ

]]>
Sun, 08 Feb 2015 22:27:54 +0000 http://www.fpgaarcade.com/punbb/viewtopic.php?pid=4537#p4537
<![CDATA[Re: Cartridge support (crt, ...)]]> http://www.fpgaarcade.com/punbb/viewtopic.php?pid=4536#p4536 A pair of paddles is connected to one joyport and use pin 5 and 9 (with a pot to +5V). Yes, pin5 is ok and it works with the A/D principle the SID uses (I tried already on the Replay) but pin9 is not. They need to independently charge via the paddle resistor to measure the time on both channels, so shorting them is no option.

Using the analog ports via ARM is much to complicated and still would not simply allow to use original paddles/mice. Paddles do not provide a ratiometric voltage to be converted, they require this kind of R/C single-slope conversion mechanism and mice also provide PWM modulated signals in the "proportional mode", this ratio has to be measured via a capcom. I got out 135x type of mice probably won't work, as they require 5V and do not work with the 3.3V delivered by the Replay. So they do not even work in joystick mode (at least mine didn't).

I will try to add additional joystick ports on my expansion board to support all such commodore devices, I will also reduce the capacitor on this pins to provide a similar PWM timing as the original does...

]]>
Sun, 08 Feb 2015 22:24:03 +0000 http://www.fpgaarcade.com/punbb/viewtopic.php?pid=4536#p4536
<![CDATA[Re: Cartridge support (crt, ...)]]> http://www.fpgaarcade.com/punbb/viewtopic.php?pid=4534#p4534 There is an IO on [6]. Maybe short [5] and [6] together?

There are analog inputs to the ARM on the P3 connector.

]]>
Sun, 08 Feb 2015 20:27:06 +0000 http://www.fpgaarcade.com/punbb/viewtopic.php?pid=4534#p4534
<![CDATA[Re: Cartridge support (crt, ...)]]> http://www.fpgaarcade.com/punbb/viewtopic.php?pid=4533#p4533 Damn...  Now the old commodore cartridges (like Clown, Pinball Spectacular) work and these require paddles. Now I need to implement the paddle support for the Replay, otherwise I can't test them  big_smile

Can't use paddles directly, as  the joy_a[5]/joy_b[5] are only inputs and I can't use a slope measurement as the real C64 does sad - need to think about something...

]]>
Sun, 08 Feb 2015 19:52:59 +0000 http://www.fpgaarcade.com/punbb/viewtopic.php?pid=4533#p4533