This may be slightly off topic but we need a Linux backend that doesn't take over the video on powerup so that DE10-Nano developers can develop their core quicker and when it's final they can make a version that goes through the MISTer video processor. I can't even imagine having to flip those tiny DIP switches all the time using a paper clip and fiddling with the fragile MicroSD card all the time, either. If I can boot up in HPS mode with this stealth Linux but develop the FPGA design and test it by programming the .sof, this would be nice.
cocotower wrote:This may be slightly off topic but we need a Linux backend that doesn't take over the video on powerup so that DE10-Nano developers can develop their core quicker and when it's final they can make a version that goes through the MISTer video processor. I can't even imagine having to flip those tiny DIP switches all the time using a paper clip and fiddling with the fragile MicroSD card all the time, either. If I can boot up in HPS mode with this stealth Linux but develop the FPGA design and test it by programming the .sof, this would be nice.
Is there such a Linux build available?
Stop to rape the tiny switches
Are you sure you've tried to develop for MiSTer? Looks like no.
To access the files on SD card - connect the network cable and use FTP/SSH to manipulate the files on SD card.
Use USB Blaster port (near HDMI) to upload your cores directly from Quartus as a SOF files.
Linux has no access to video at all. It's done on FPGA side.
I can attest that the terminal and FTP works pretty well from a computer. It's actually pretty neat to fiddle with Linux while the FPGA core is running. I highly recommend using that Ethernet port
Sorgelig wrote:You can find discussion about build environment here: http://www.atari-forum.com/viewtopic.php?f=117&t=32441
ARM part runs a normal Linux, thus Linux environment for code compilation is more natural and easier to setup. But compiling under windows is also possible.
Although i'm not sure what you are going to do with 68040 emulation alone. It's not about CPU emulation only, it's also about connection ARM and FPGA parts.
Thanks, I will have a look. Well, a 68040 emulation that had a ROM in the memory map, video memory, chipset addressing, etc. could be interpreted on the FPGA side and output video, play sound, etc. This is how I made EMPLANT's Mac emulation (and later FUSION). One task was the CPU core and the other tasks handled individual functions.
JimDrew wrote: Well, a 68040 emulation that had a ROM in the memory map, video memory, chipset addressing, etc. could be interpreted on the FPGA side and output video, play sound, etc. This is how I made EMPLANT's Mac emulation (and later FUSION). One task was the CPU core and the other tasks handled individual functions.
May be it's better to move this discussion to dedicated thread: http://www.atari-forum.com/viewtopic.php?f=117&t=32674
From my point of view, the connection point between FPGA and ARM emulations should lay at the same place as in real A1200, i.e. expansion port. ARM part will plug to Minimig as an 680x0 accelerator with it's own FastRAM memory. I think, changes in Minimig should be minimal in this case.
Off topic, but Replay2 has a large 28nm Spartan7 device on board plus all the usually goodies - high quality analog video/audio as well as dvi/hdmi.
DDR1 memory of compatibility with the current board + 512MB DDR3.
It won't be as cheap as the DE10, but it will be available in volume for those who want it. Layout is progressing well.
Different approach with the separate ARM chip - Iike to keep the FPGA part simple. I appreciate some like the embedded CPU.
I'll release the rest of the code as soon as it's out, no point helping out the vampire boys.
/Mike.
Sorgelig, while I'm here..
I haven't finished my 68000 cycle accurate code yet, and my new core is system verilog based.
As a stop-gap, I've re-written and tidied up the TG68K (renamed as M68K so I can track it). It's in regression testing now. Ping me and I'll send you a copy for testing as soon as it's running.
cocotower wrote:This may be slightly off topic but we need a Linux backend that doesn't take over the video on powerup so that DE10-Nano developers can develop their core quicker and when it's final they can make a version that goes through the MISTer video processor. I can't even imagine having to flip those tiny DIP switches all the time using a paper clip and fiddling with the fragile MicroSD card all the time, either. If I can boot up in HPS mode with this stealth Linux but develop the FPGA design and test it by programming the .sof, this would be nice.
Is there such a Linux build available?
Stop to rape the tiny switches
Are you sure you've tried to develop for MiSTer? Looks like no.
To access the files on SD card - connect the network cable and use FTP/SSH to manipulate the files on SD card.
Use USB Blaster port (near HDMI) to upload your cores directly from Quartus as a SOF files.
Linux has no access to video at all. It's done on FPGA side.
Ok, this sounds much better than what I thought might be required. So, I don't have to make an RBF file or use the ARM suite?
Newsdee wrote:The GB core is another one of my favorites, thanks Sorgelig!
unfortunately it's far from perfect...
May be because it supports only MBC1. I think it's not hard to add other MBC chips - they are well documented. I just have no time to do it. May be someone will pick it up and improve.
Newsdee wrote:I can attest that the terminal and FTP works pretty well from a computer. It's actually pretty neat to fiddle with Linux while the FPGA core is running. I highly recommend using that Ethernet port
I have only had my MiSTer setup for one day but already agree with you, I have been managing the file structure and uploading via ftp and debugging via serial at the same time as watching some amiga demos and running other cores, very fun, and very useful, and very cool
fpgaarcade wrote:Off topic, but Replay2 has a large 28nm Spartan7 device on board plus all the usually goodies - high quality analog video/audio as well as dvi/hdmi.
DDR1 memory of compatibility with the current board + 512MB DDR3.
So Spartan7 or Cyclone V ?
Does it really change every day?
fpgaarcade wrote:
Sorgelig, while I'm here..
I haven't finished my 68000 cycle accurate code yet, and my new core is system verilog based.
As a stop-gap, I've re-written and tidied up the TG68K (renamed as M68K so I can track it). It's in regression testing now. Ping me and I'll send you a copy for testing as soon as it's running.
Out of curiosity, did you change anything in the instruction decoder from the tg68k?
