Topic: Cartridge support (crt, ...)

Can't wait to get my FPGA on my hand (Hey Mike what's up tongue), I want to run the C64 core as much as I want to use the Amiga one. Can you mount .CRT in the core? Thanks!

ɃºïȠǥ!

Re: Cartridge support (crt, ...)

Very good question! I might even move this in a separate thread about cartridge support as it might need some discussion how to handle it or what to do with them.

An answer for now: yes and no... wink

AFAIK, the CRT is a format telling the emulator about the type of cartridge to be emulated "on the c64 part" (and may embed some ROM code as well). So it is a kind of "setup file" which made perfectly sense for a software emulator (I think it came from the CCS64).

On a FPGA, the hardware needs to be actually "there" to be used, so the core needs to support all types of cartridges in HW the crt allows and enables the cartridge required directly in HW (usually done via the OSD menu). So first step is to set up all the the HW first - some might be easy, some a little harder - but it can / probably will be done for all these cartridges.

Next it would require to set it up that way that the user loads via OSD a c64 FPGA core via a "c64.ini" setup file and then load a CRT file afterwards (again via OSD) to reconfigure the underlying FPGA hardware again. That sounds more like a overhead - so this concept does not really fit anymore to a HW approach like the Replay is...?

On Replay, you can select the cartridge (once it is implemented) directly in the OSD menu and set up a INI file to directly load it. This can "do more" than a CRT file, it can also configure further HW "beside" cartridge stuff (like the 1541 setup, kernal/basic/dos ROMs of the mainboards, parallel cables for speed loaders, scanlines on the video output, etc.). See the VIC-20 for example, where this is already done for some memory modules and the super expander (and thus several INI files for the core exists one can select), but also for the C64 INI options for using jiffy dos on C64+1541 exist already.

So what might be more practical, would be probably a simple converter for the PC to generate the proper INI settings from CRT files and just extract relevant (ROM) information. These can be then used on Replay boards in one step. At least for "normal cartridge" setups as mentioned in the CRT documentation this could be done already without any modifications on Replay side. I'll take a look in a silent minute, need to find some of these crt files...

For the C64 I am also about to get my hands on a 1750 expansion to implement it as add-on to the core to run GEOS properly (as soon as I have fixed the last small issues with the CIA hardware), so there will be then a simple enable line in the OSD, that's all one will see (and hopefully need) for this option there. big_smile

/WoS

Re: Cartridge support (crt, ...)

Wolfgang, let me know if you need any info on the REU.  I supported the 1700, 1764, 1750, and the various GeoRAM units with my programs.

Re: Cartridge support (crt, ...)

AFAIK, the CRT is a format telling the emulator about the type of cartridge to be emulated "on the c64 part" (and may embed some ROM code as well). So it is a kind of "setup file" which made perfectly sense for a software emulator (I think it came from the CCS64).

well, not really - back when the format was invented, what you said was the idea - but over time people learned that it is not practical, so emulators also implement each cartridge type seperately, just like you would do in FPGA. you can basically take the crt files as "rom dump with a header", extract the cartridge ID from them, and load the rom data... and ignore the other info. the only exception to that are standard 8k/16k cartridges (type 0) where you'll actually have to use the exrom/game setting to find out how they work exactly.
if you need to know how a cartridge works, have a look at the implementations in the VICE source (src/c64/cart), each file contains a short description of the hardware in comments. i recommend starting with something simple like "ocean" type (which also has some of the most interesting games...)

Re: Cartridge support (crt, ...)

I opened the cartridge support thread here to keep the compatibility/testing thread clean and allow to continue discussions on it - that's good. wink

@gpz: Thanks, I have the CRT file format description which explains quite some options.

Nevertheless, beside uploading ROM data for generic cartridges (which would be somehow similar) there are significant differences:

- On a FPGA you can't dynamically simply switch in/out or exchange function blocks on the fly without some impact as you can do in the software world (simply speaking by switching some pointers in an API or instantiating other classes). The HW needs to be still there in the FPGA at any time but disabled - this has at least impact on timing plus adds complexity of the core build/setup (and a clever idea to do that and still keep compatibility). Would be similar to connecting several modules on a real C64, even if there would be a way to multiplex them and allow different ROMs for same setups, the number will be limited. Or why a PC has a limited amount of card slots...

- Even if the FPGA design supports some of the HW required for the crt: a) processing the format on the FPGA is no practical/generic way and b) it is also not the goal to let the ARM doing all kinds of emulation for file formats due to limited resources compared to ressources emulators can use (this would be also the only way to support different core setups for the FPGA based on the type selected in the CRT - in case several C64 core+cartridge setups are needed).

- The Replay approach allows to use all kind of cores, so ARM/OSD support has to be as generic and lean as possible. It is also no practical approach to code too much core-specific handling into the framework. Each FPGA core update (not only c64, but any core) would then require to update the ARM flash for new features or in a w.c. some cores will even require to flash the ARM first with a special setup if the handler code exceeds the available memory limits. This would not be really fun to use if you always need to check if the firmware fits to the core on your sdcard, so it is also not my favourite solution.

Thus I explained how it could be done in a "better" way (for a Replay-like setup), which is convert crt files to ini + rom files (and maybe using also a selection of a core setups). So instead of doing a lot of OSD configuration (or load a c64 ini and then a crt file) one just loads directly an ini file and gets directly a core with the cartridge "inserted". So for simple cartridges which do not need any special bank switching HW this should be (partly) possible already (I checked already some basic diagnosis cartridges earlier)  - without changing anything on the Replay.

/WoS

Re: Cartridge support (crt, ...)

yeah i understand... on chameleon we have the luxory of a dedicated C64 related menu program, which does all the crt file format parsing (we do have a bunch of cart types in the hardware at once though, and switch between them using a global flag, doesnt seem to be all that costly at all regarding fpga resources). however, should be easy enough to make a little command line tool that parses the crt files and writes out plain binaries plus additional info (you could hack up "cartconv" from VICE, which basically does all that already)

Re: Cartridge support (crt, ...)

yeah i understand... on chameleon we have the luxory of a dedicated C64 related menu program, which does all the crt file format parsing (we do have a bunch of cart types in the hardware at once though, and switch between them using a global flag, doesnt seem to be all that costly at all regarding fpga resources).

I never said it is not possible, but I saw a lot of implications for a generic approach. I own a Chameleon, it is not at all generic and not really easy to use and I would not take it as reference for this. That was one reason for me that I use/used it quite rarely and never could really motivate me to implement one of my cores for it... I don't want to bash it - it is still an excellent C64 implementation (and the reference I'd say), nice C64 cartridge replacement and it can also run a few other cores (if I was able to get them on the cartridge).

My proposal was focussing on providing support somehow without spending too much on changing the framework to support one file format out of many just for the C64 (especially as long as many other things need to be fixed as well). An dedicated handler approach in the ARM flash would be also "generic enough" if more than one emulator out there beside one for the C64 (meaning Atari, Apple, ...) use the CRT format as well (or a very close variant of it to keep all together in one handler). I had some thoughts on a generic "DLL" like loader for the ARM as well (similar to my flasher implementation). But I don't see a such simple solution, which is still generic (=useful for many other cores) and not starting to add specific handlers for each and every format introduced by any new core until the ARM flash is exhausted.

So why not join me and implement that part for the Replay core to implement support some of the cartridges for the FPGA? It sounds to be a simple task for you and I can meanwhile continue fixing other things. If you don't have access to the SVN, I can send you the C64 sources and you can send me back the changes. I have also no problem if you start working on a complete different implementation for the Replay (FW + FPGA) - another problem solved and people will be happy wink

however, should be easy enough to make a little command line tool that parses the crt files and writes out plain binaries plus additional info (you could hack up "cartconv" from VICE, which basically does all that already)

Ok, it is be also a big help if you can set up this crt to ini/bin converter for now until we have the time to work out something better. It will also help to implement the required changes/options for different cartridges to the FPGA core in the first place. Thanks in advance!!! big_smile


Every approach is OK with me as long as it helps to get the things done or to have a first implementation running on the board to test and discuss further.

/WoS

Re: Cartridge support (crt, ...)

So why not join me and implement that part for the Replay core to implement support some of the cartridges for the FPGA?

uh, sorry, no - seeing how i am working on fixing chameleon things (and getting paid for it) that doesnt seem to be a good idea =P i refuse to even look at other peoples vhdl for that matter - i cant afford to even theoretically be able to copypaste from it smile

as i told mike before, i am mostly here to share ideas on testing and debugging, i cant (and shouldnt) actually help with working on your cores.

Re: Cartridge support (crt, ...)

The downside of Jen's model - restrictive and divisive, in my opinion.
Hopefully the open approach will win out in the end - at least every user has the option to fix any bug they wish wink
/Mike

10

Re: Cartridge support (crt, ...)

Or implement missing bugs to get it closer to the real thing tongue

/WoS

11

Re: Cartridge support (crt, ...)

at least every user has the option to fix any bug they wish

i dont know - looking at the 1541u, that didnt quite work out... i wouldnt count on it.

Re: Cartridge support (crt, ...)

I guess that depends who you talk to.  I made changes to the 1541U without any issues.

13

Re: Cartridge support (crt, ...)

yet it still fails on eg the lorenz suite.

14 (edited by JimDrew 2014-11-19 14:24:51)

Re: Cartridge support (crt, ...)

I will have to try that and fix any failures.  I already ran though that suite (and others) when developing the u1541.

15

Re: Cartridge support (crt, ...)

Checked in some experimental changes to the ARM FW and C64 core. I set up an experimental c64_crt.ini file containing a CRT loader menu.  Only standard 8k/16k ROM cartridges work (CRT type 0, ROM @ $8000...$9FFF/$BFFF, C64 ROM @ $E000...$FFFF), any attempt to load an "illegal" CRT throws an firmware error and causes the board to reboot (you need a serial terminal connected to the Replay to get out why it didn't work out).

I tried more recent CRT files like "micro hexagon" and "monster buster", they start up fine so far.

Requires to update the ARM FW and C64 core with this latest build (on SVN only yet). I still saw some VIC memory mapping issues with Ultimax 8k/16k mode CRTs (like Clown, Pinball Spectacular, ...), need some more debugging on these before I can do a proper ARM FW and C64 core release here on the forum...

/WoS

16

Re: Cartridge support (crt, ...)

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...

/WoS

Re: Cartridge support (crt, ...)

There is an IO on [6]. Maybe short [5] and [6] together?

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

18

Re: Cartridge support (crt, ...)

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...

/WoS

Re: Cartridge support (crt, ...)

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

20

Re: Cartridge support (crt, ...)

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).

/WoS

21

Re: Cartridge support (crt, ...)

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...

/WoS

Re: Cartridge support (crt, ...)

Maybe Easyflash support? So we can run Prince of Persia?

Re: Cartridge support (crt, ...)

Good link, took me to some SID test code :
http://codebase64.org/doku.php?id=base:sound_fx_routine

24

Re: Cartridge support (crt, ...)

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).

/WoS

Re: Cartridge support (crt, ...)

There is flash - the SD card wink You can use FileIO to write back to the source file if you are brave.