FX CAST Atari ST core

[ijor]

Announcement: viewtopic.php?f=28&t=34554

Please comment and ask questions here.

[witchmaster]

Nice job! This core makes the MISTer even better!

[troed]

*stunned*

o_O

wow

[joska]

Amazing! Is there any chance to get this core on the MIST as well?

[olin]

Congrats!

Out of curiosity - did you use the designs recently uncovered here: http://www.chzsoft.de/asic-web/ in order to replicate cycle perfect chips?

[christos]

Amazing! Is there any chance to get this core on the MIST as well?

What Joska said!

[frost]

What troed said !

[ijor]

Amazing! Is there any chance to get this core on the MIST as well?

A MIST version is planned. Support for copy protected images might not fit and probably would have to be dropped.

The remaining main issue is ram storage for TOS. On MiSTer, I am beling lazy and storing TOS on internal FPGA RAM. That much sheer amount of RAM the FPGA on the MiSTer board has. MIST doesn't have, not nearly, that much internal RAM, so ROM must be stored on external DRAM. There is enough external RAM, that's not the main problem. But moving ROM to external RAM is not trivial if I want to maintain cycle accuracy. This is because the ST can access ROM and RAM concurrently. Not impossible to solve, but not that simple.

[ijor]

Out of curiosity - did you use the designs recently uncovered here: http://www.chzsoft.de/asic-web/ in order to replicate cycle perfect chips?

Not really. I made my own reverse engineering that included chips decap long before. Also, unfortunately, the archive includes schematics for a single chip (MSCU that is only for the STE), plus Blitter.

[ReedSolomon]

Congrats on getting the beta released should be fun to start testing

[MasterOfGizmo]

Wow ... a cycle exact 68k is something a lot of projects have a use for. The fpgagen is one of them. Very exciting.

[cacophony]

Out of curiosity - did you use the designs recently uncovered here: http://www.chzsoft.de/asic-web/ in order to replicate cycle perfect chips?

Not really. I made my own reverse engineering that included chips decap long before. Also, unfortunately, the archive includes schematics for a single chip (MSCU that is only for the STE), plus Blitter.

Are you planning on releasing the source code for the 68k so that other projects can benefit ?

[olin]

Not really. I made my own reverse engineering that included chips decap long before.

That's even more impressive.

Also, unfortunately, the archive includes schematics for a single chip (MSCU that is only for the STE), plus Blitter.

Well, at least it can help someone to implement/verify parts of STE if that ever will be someone's goal.

[cmdrpds]

Announcement: viewtopic.php?f=28&t=34554

Please comment and ask questions here.

Just wanted to say thanks ijor!

[ijor]

Are you planning on releasing the source code for the 68k so that other projects can benefit ?

I do, but it won't be today. I'd like to wait a few days, just in case the public release exposes any possible bugs in the 68K core. I also need to think and decide which open source license to use. I'm not a GPL fan, but not sure there is anything better. According to what I read some time ago, FPGA cores aren't really fully copyrightable as software. So it might not matter too much after all ...

Anyway, if any developer for a major known core based on the 68K wants to start some testing, I don't mind giving him early private access to the source.

[Sorgelig]

Is it 68000 or 68010/20/30?

[ijor]

Is it 68000 or 68010/20/30?

Bare 68000 only. You probably need almost completely separated cores for the other processors, if you want cycle accuracy. There is probably not much in common between the 68030 (or even the 68020 for that matter) and the 68000 at the gate level. The 68010 is very close to the 68000, but I guess there is not as much interest in the 68010.

[Newsdee]

Fantastic news! Congrats on a major first release, Ijor!

[cacophony]

Are you planning on releasing the source code for the 68k so that other projects can benefit ?

I do, but it won't be today. I'd like to wait a few days, just in case the public release exposes any possible bugs in the 68K core. I also need to think and decide which open source license to use. I'm not a GPL fan, but not sure there is anything better. According to what I read some time ago, FPGA cores aren't really fully copyrightable as software. So it might not matter too much after all ...

Anyway, if any developer for a major known core based on the 68K wants to start some testing, I don't mind giving him early private access to the source.

Great to hear! I would imagine having a cycle accurate 68k is going to benefit a lot of other cores going forward.
I'm also excited to try out your Atari ST core, so thanks for doing it

[Shamus]

Great news Ijor - and many thanks for your efforts! The ST has definitely been missing on the MISTer system.

However, with my setup I cannot test the core because I do not get a video signal. I am using MISTer's HDMI out to connect it to DVI in of my 1280x1024 LCD monitor (dvi_mode=1 and video_mode=4 in MISTer.ini) with beautiful image quality in all tested cores. Will you look into the video out issue?

[ijor]

However, with my setup I cannot test the core because I do not get a video signal. I am using MISTer's HDMI out to connect it to DVI in of my 1280x1024 LCD monitor (dvi_mode=1 and video_mode=4 in MISTer.ini) with beautiful image quality in all tested cores. Will you look into the video out issue?

Sorry, I'm afraid DVI is currently not supported. I will try to implement it for a future build. Sorry again.

[weirdocollector]

Fantastic news! Congrats on a major first release, Ijor!

Just wanted to join this !! Congrats !!

[ijor]

I moved the posts not specific to this core, but more related to generic 680x0 cores to a separate thread: viewtopic.php?f=117&t=34568

[breiztiger]

hi

sorry for the question but

why only scp format and not ctraw from kryoflux ?

ipf support is it possible ?

thanks for your core

[ijor]

sorry for the question but

No need to apologize at all. Good questions

why only scp format and not ctraw from kryoflux ?
ipf support is it possible ?

Well, SCP is, by far, the simplest of the low level formats and the easiest to process by FPGA logic.

RAW Kryoflux images, being split in multiple files and with the "out of bounds" index pulse data are really a PITA for a FPGA core. They would need to be pre processed by software. Of course, we have a very powerful CPU at the Arm side, so this could be implemented in the future. It might be easier perhaps to just implement a converter that you could run on a PC though.

CTR images could be a nice option because they are rather compact, but the CTR format is, AFAIK, not documented. I am guessing it might require software pre processing as well.

IPF support would require to port the IPF library to the ARM (may be there is a port already), and again it would need additional pre processor before it reaches the FPGA core. One problem is that the IPF library API doesn't seem to be fully documented. The API documentation seems to correspond to older versions of the library. I didn't look at that for quite some time, so it might have been changed. But yes, in theory, and thanks again to the powerful ARM CPU that the MiSTer has, it should be possible.

Edit: I do am performing some software pre processing for SCP images as well. But that is very minimal and lightweight.