MiSTer FPGA Forum

Seems that the T65 implementation (the CPU of the current c64 core) is actually capable of being a 65C816. Need to generate a new clock pulse for the 20 Mhz somehow (the PLL already has 3 setup and could potentially clock divide the 1mhz into 20), but it might be possible to change the mode of the CPU to be the 65C816 and get somewhere near the Sup...

Should be noted that the CPU that get's used in the SuperCPU is the 65C816... which happens to be already implemented in the SNES MiSTer core ;) https://github.com/MiSTer-devel/SNES_MiSTer/tree/master/rtl/65C816 More information here: http://mclauchlan.site.net.au/scott/C=Hacking/C-Hacking12/cmdcpu.html Things of note: - WDC W65C816S 16 bit micropr...

MSU-1 won't happen on the official normal SNES core unless someone forks the SNES core and rips out all the addon chips and makes a SNES-MSU-1 separate core. The core is using 90% of the FPGA's space basically as is, without MSU-1. It's the second largest behind ao486. Not necessarily. It's entirely possible that a smaller FIFO buffer could be use...

The issue will be around how the RAM itself will be implemented. If we had enough FPGA space, then it would be pretty straight forward. The obvious alternative is to use the SDRAM instead, but the complexity is a bit higher and I am not sure about the latency of reads and writes.

Ah, done!

I'd love to change the subject of this thread to just be X68000 beta... Any idea how I can make that happen?

Would a possible work-around be to use the existing bootrom functionality?

You could:

1) Copy the rom you want to boot to bootrom (for NES core: `boot1.rom = NES Cart file. Can be used with boot0.rom (BIOS) in place`)
2) Start appropriate core

Sounds awesome @puu!!!! Having more space on the de10 and using the ao486 cpu things will be helpful I am sure! Keep us posted! Do you have a Patreon?

@puu have you got a build of PC98 core so far?

suverman wrote: ↑Sun Jun 07, 2020 3:39 am Is MIDI output possible easily at this stage on the core? Midilink on MiSter is pretty incredible

Don’t see why not... be good to sort out 15khz video output... 24khz down to 15khz would also be nice somehow?

@grabulosaur

In the user_io file, there is a sd handling loop. This loop is used to stream data across. For snes msu1, I hijacked the loop, making it call a separate function in support/snes... this allowed me to do specific sector sizes - either smaller or larger than 512 bytes.

Do you have your source code available for the main sd card HD stuff?

One thing we could definitely reuse this for is the MD+... but I know there’s some real aversion to that one

If you did manage to do audio on the linux side i think that would make this the first software with FPGA hybrid emulation? I already had cd track playing, but as I said, that doesn’t allow for proper looping... the msu1 audio files have a header that can be used to specify a repeat/loop point. That loop point is a byte offset into the audio file....

After connecting my MiSTer to a pvm, I’m noticing everything is in yellow, including the OSD. Seems to be described here: https://github.com/MiSTer-devel/MSX_MiSTer/issues/23

Anyone have this issue as well? Any kind of work around?

I’d be keen to help get fdd working off the main sd card if you want, @puu @grabulosaur?

I do wonder though, if we can find an audio library that can handle seamless looping and volume control on the linux side. perhaps we could do all of the audio stuff in linux, leaving more fifo space for video... hmmmm

It ends up being quite a complicated player really, games can turn looping on and off during playback too, so the song might loop 3 times, and on the last, the loop is removed and the full audio is played out. To be completely seamless, the fifo buffer needs to have the right audio data in it at the right time, else there will be a noticeable hiccu...

I had the linux side playing cd tracks in my first experiments. It worked, but there is the problem of looping. The audio player I was working with did not support arbitrary loop points in the audio file :( the msu1 also supports pausing, fade in and out, it must cope with missing tracks too, with a fall back to playing the original music. In the e...

I can certainly look to put the audio side of the msu1 into the latest SNES core. This isn't the latest code, but it's a good indication of how audio was done at least, and highlights some of the things that need to be scrutinized. For MiSTer_Main, I split the snes SD handling and polling out to a separate 'support' file - so glad that Sorg took up...

To mount disks (d88), I simply load files into FDD0 and FDD1 - Additional disks (disk 3) may need to be loaded into FDD0 when prompted by the game. You can eject the HDD0 if you like, but I think I was able to load disks with it still attached.

Not sure exactly why it was working originally. But here are the steps to get it working again: - Formatted my second sd card back to scratch - Copied all the disks and hdf onto it - Copied the 4mb, 6mb, 8mb SRAM onto it - Copied latest working core 20200522 onto main SD card - Started core, hit F11: ***Made sure that I marked FDD0 and FDD1 as 'Eje...

I found this site quite useful as a simulation environment for checking basic verilog things out: https://8bitworkshop.com/v3.5.1/?platform=verilog Great for testing state machines or quickly checking some logic... It's an open source product too, and I have wondered if it might be possible to make it into a MiSTer specific setup. For example, we c...

Sorgelig wrote: ↑Wed May 27, 2020 9:07 pm Also can load aged CD into 60x CD-ROM drive and guess will it explode or not.
I suggest to start from Sapphire. Exploding the $2000 CD is awesome.

Hahaha, so true!

SNES core is already quite large and take ages to compile. Adding such resource and performance hungry thing such as MSU-1 will definitely affect the overall core stability. As i've told many times, MSU is quite useless feature. If it could be some small thing like add and don't notice it, then i would add. But such large thing as MSU - i'm pass. ...

I agree with this, it's certainly something that could be implemented. If the ARM side of the DE-10 Nano was configured to mount a CD to a file directory, the FPGA core would simply read the files off the CD as if it were any other mounted media. Now a modern dvd/cd drive generally operates at a much faster speed than the original TG-16 would have...

OK, thanks puu, I will try removing the SRAM file entirely and setting it to none. Will report back if that solves the problem.

Reading a cd on-the-fly would only work in the same sense that retron's read carts, by ripping them and then loading the ripped roms. There's a 0% chance the cd drive will operate with the correct seek and read times that cores need to behave properly, so you're better off simply ripping your discs to files and not adding silly overhead for illusi...

From what I remember of the original spec (which seems hard to find now), it's tricky to properly implement MSU-1 in hardware without independent storage devices for data and audio. Performing a data seek does not stop audio streaming, and vice-versa. So for full compatibility you need to be able to perform any pattern of seeking and streaming ope...

I had setup and was running the 20200513 build of the beta core and everything was working. I was able to load harddrive files from the second SD, browse for a game, and boot them. I was even able to boot .d88 disk images. Then all of a sudden, it stopped working. Perhaps I ran the update script, I can't remember. Has anyone else experienced simila...