It seems I have no sound at all. It boots, it moves, I can see moving, but distorted sprites. I changed audio pin (to 14) in 2 places. and video pin to 8 in config file. In my configuration I can only place the accessory boards into 0 or 8. Maybe I have to find another version of this game and try it.
What tool I have to use to compute these checksums?
@pik33 said:
It seems I have no sound at all. It boots, it moves, I can see moving, but distorted sprites. I changed audio pin (to 14) in 2 places. and video pin to 8 in config file. In my configuration I can only place the accessory boards into 0 or 8. Maybe I have to find another version of this game and try it.
Double check that, no sound at all is odd, too (the audio config that actually matters is the one in neoyume_lower. Double check). Could also mean that the Z80 program is getting bungled.
What tool I have to use to compute these checksums?
If you have 7-Zip installed, you have a "CRC/SHA" context menu. Any checksum will do. Alternatively, Linux (or windows with git bash) command line has md5sum *.bin
As said before, I too would find a P2 board (could be an Edge carrier or just a P2+PSRAM standalone board) with hardwired connectors arranged in a sensible manner appealing.
Anyways, I fixed the ADPCM, I think. No more dud notes, pops and random electrofarts. Also optimized the memory arbiter a bit. It turns out there are plenty of cycles during the setup phase to perform the target address calculation.
0.04 does the same video garbage in my configuration as 0.03. I tried also vga3x and HDMI: it's all the same. Combinations of PSRAM delays gives either the same garbage, or a yellow screen, or no boot at all
I wouldn't have expect 04 to fix it . Only thing I can think of is that it's not loading the graphics correctly. The graphics, ADPCM and 68000 program all come from PSRAM, so only the program working is really very strange.
I've built a binary for VGA/Audio on basepin 8 (USB on pin 16 still), try that, to rule out any silly compiler issues.
That looks like the reads are being glitched, which to me makes no sense (in the context of the 68k program running just fine). Surely a headache. Will have a deeper think tomorrow.
For today, here's a little video of me being bad at Samurai Shodown, because why not? Notice how the audio isn't brapped at all. It like actually works.
@rogloh said:
Well done on the latest audio work. What's left now?
Figure out if it actually works on any hardware that isn't mine (don't you have an EC-32MB, too? And I think @VonSzarvas also had a setup that worked for MegaYume). Maybe I really do have a rare double yolk P2.
Add game selection (currently you just uncomment the one you want...)
Figure out compact way to store game metadata (Name and ROM mapping, basically) (very obnoxious that the format we're stuck with is MAME romsets, which is very unhelpful for anything that isn't a one-off arcade board)
Maybe implement some of the missing features (timer IRQ and scanline register come to mind)
Goad someone into making a USB driver that can actually handle a second controller
Relatedly, mayhaps build a SNES adapter board (I have a terrible homemade arcade stick that can work as one). Would need to order some of them MOSFETs to build the level shift circuit (5V CMOS inputs lmao) and another pair of extension cords to cannibalize.
For game development, I think something like Andre LaMothe's P1 Hydra (with updated connectors) would be useful -- but then, I'm not a gamer.
I would venture a guess that more games were developed fro the DemoBoard than for the Hydra, at least that is what it seemed like in the Forums, but then I didn't have one, and I had 2 DemoBoards. The great thing about the Hydra was not the Hydra itself, it was the book, IMHO. Yeah the connectors were handy, but it wasn't anything special. The cartridges were almost never used, because they were expensive, and we have microSD for pennies. Was there even any games that used the special network port?
@Wuerfel_21 said:
As said before, I too would find a P2 board (could be an Edge carrier or just a P2+PSRAM standalone board) with hardwired connectors arranged in a sensible manner appealing.
I would somewhat agree. Here are some of my observations:
Standard 9-pin joysticks can be implemented with just 2 pins each because of the ADC's at our disposal. I say 2 because they could also double as serial ports.
2-TX/RX
4-SPI/microSD
4 2-DB9 Joystick/Serial ports
10 HDMI
5 - VGA \
2 - Audio out > can be and adapter on HDMI port
1 - Audio in
8-4 USB ports
18 pins PSRAM
4 - PS/2 Keyboard & Mouse
sum(above) = 58 pins.
But consider this, retro gaming has gotten really big lately with people wanting to relive their earlier gaming experience. Also retro programming has picked up lately also, with a company (Retro Games Ldt) launching The C64 Mini, The C64 Maxi, and The A500 Mini I personally bought the The64 Mini and Maxi, but looking back I wish I would have bought a system that would emulate all of them, like The MISTer.
Launching into that market could possibly sell a LOT of units and bring people into P2 programming if there was emulators already running, and a good book for it like there were for the Hydra, and the Propeller Manual that came with the DemoBoard.
@hinv said:
Standard 9-pin joysticks can be implemented with just 2 pins each because of the ADC's at our disposal. I say 2 because they could also double as serial ports.
2-TX/RX
4-SPI/microSD
4 2-DB9 Joystick/Serial ports
10 HDMI
5 - VGA \
2 - Audio out > can be and adapter on HDMI port
1 - Audio in
8-4 USB ports
18 pins PSRAM
4 - PS/2 Keyboard & Mouse
sum(above) = 58 pins.
Sometime ago I sketched this board with KiCad:
With hdmi, vga, audio, usb and ps/2 connectors for keyboard and mouse (like a PC), an SD card socket that replicates the P2-Edge onboard for easy access and two additional USB ports for game controllers (don't think anyone need the real SNES controllers as of today...). I have some doubts about the hdmi and the licensing if/when associated with audio (is there an HDMI driver with audio support ?) and the requirements on the P2 side (highest clock speed and limitations), VGA-to-HDMI converters are easy and inexpensive enough to obtain. Two (or more) "expansion slots" to break-out all free pins for add-ons like high-quality DAC, more RAM, wireless network, etc.
Through hole to be sold as an easy to solder kit (maybe).
I'll never be able to complete this project in a reasonable time, so all I can give are suggestions for anyone that want to venture into this.
Maybe we can split the thread if there is enough interest to avoid polluting this.
For the Amiga platform, I bought an A500plus, which is the best you can get to upgrade with the PiStorm which makes some of the old Amiga games actually a LOT more fun & playable, especially the ones with 3D graphics. The PiStorm emulated the MC68000 processor(at over 100MHz even), Fast RAM (even as large as 500MB), ROMs, Hard Drives, networking and USB keyboard & mouse, and Retargetable graphics(for bigger/more current monitors), all in the Raspberry Pi.
Then there is also The Minimig 1.81 that can do the hardware of the A500plus with more modern ports and can even use the PiStorm which gives the owner the fastest performance you can get on Amiga without the lag/gitter of software emulation.
So what if there was a P2 based Pi hat that provided chipset emulation and ports of the Amiga and other gaming platforms that had the memory of the P2-ES32MB.
The Raspberry Pi interface of the PiStorm uses 26 pins.
32MB PSRAM 18pins
VGA, 5pins
Audio out, 2pins
Audio in, 1pin
1 USB, 2 pins (the Pi has more but this one would be lower latency If needed)
2 DB9 ports, 4pins
2 PS2 ports, 4pins
Debug Serial TX/RX, 2pins (can debug be reassigned so that 64&63 are on the Pi connector for boot/debugging from Pi by default?)
Let the Pi do the microSD, most of the USB, HDMI, etc since it can do those better anyways.
A small board that plugs into the top of the Pi 40-pin interface could provide SPI flash, MicroSD slot and FTDI interface for a stand-alone P2 setup.
@Wuerfel_21 is there any ports/features I have missed that you needed for your emulations?
@macca said:
... I have some doubts about the hdmi and the licensing if/when associated with audio
There won't be any explicit licencing to do uncompressed stereo PCM over HDMI. Those licences will be for 5+1 compression and the likes. Just like with SPDIF.
@macca said: Maybe we can split the thread if there is enough interest to avoid polluting this.
I think "Console Emulation" is what we are talking about, and also a great way to get more eyes on the P2.
Also "Console Emulation" using a Raspberry Pi as a base for it's fast processor could rope in people from the Pi community also.
And then there is the Amiga and other retro computer/console communities that could get roped in to if the P2 helped rejuvenate their favorite retro games.
Also putting it in the form of a Pi hat could eliminate the requirement for microSD, flash, PropPlug and/or power supply and at the same time be tied into a development platform already supported with flexprop(with some slight modifications for loading).
I think split is needed. There are 2 big topics now: a P2 software emulators of retroconsoles, and a retroemulator board (which is also one of my dreams)
A Raspberry Pi P2 board format can be also convenient
@hinv said:
Also "Console Emulation" using a Raspberry Pi as a base for it's fast processor could rope in people from the Pi community also.
IMHO, if I have to use a Raspberry Pi, I'll run the emulator on it.
What's the point of using a P2 if the Raspberry can already do everything ?
And then there is the Amiga and other retro computer/console communities that could get roped in to if the P2 helped rejuvenate their favorite retro games.
We have the 68000 processor, we have a Paula-like (don't know how much like) audio driver, we need the video driver and the Amiga can run on the P2.
I haven't thought super thoroughly about Amiga (partially because a computer emulator ensues a lot more fiddly boring stuff like disk drive emulation than a cartridge game system), but the big problem is that there's too much RAM to keep it all in Hub (unless you wanna go with an unexpanded A1000, lol) and having the external memory writeable causes a number of issues (native word size is 32 bit, exec queue needs to be invalidated/updated for self-modifying code, etc).
In other news, I made a simple scripting system for game loading (since the ROM mapping can be all over the place and you can't tell from the MAME dump alone). Not super sophisticated though.
Old hardcoded load:
New scripted load:
I've also thrown a few more games at it, so here the current compatibility list:
Game
Status
Metal Slug
Works
Metal Slug 2
Would work (needs bigger PSRAM to load all graphics)
Samurai Shodown
Works
Samurai Shodown 2
Works
Twinkle Star Sprites
Works
Ironclad
Works (need to rename files to fit in 8.3)
Neo Drift Out
Glitched graphics (fricking height 33 quirks again, I bet), sound seems to die after one game
Cyber-Lip
Doesn't boot
Viewpoint
Hangs immediately
Zed Blade
Works
Sengoku 2
Can't figure out how the graphics are supposed to be mapped. Also hangs.
What's the point of using a P2 if the Raspberry can already do everything ?
Raspberry can "do everything" using a Linux This means (1) slow start (2) input, picture and audio lag where picture lag<>audio lag. While coders do their best the overall opinion is that FPGA emulators are always better.
P2 is not exactly an FPGA but it have a lot of common things with it. There are 8 cogs, there are 64 smart pins, they run in parallel like an FPGA. There is no Linux, it starts in miliseconds, it can have very low audio lag, it is fully possible to synchronize audio and video.
Paula-like (don't know how much like) audio driver
It runs at original Paula frequency and it can directly accept Paula's sample periods without any translating. Internally it simulates as exactly as it can the Paula's method of outputting samples. What is different is the register structure and additional features (more channels, non-integer periods, 16-bit samples, channel synchronizing). Then it lacks Paula's method (PWM) to control channel volume, I multiply it instead. This low frequency PWM adds some distortion to the Paula' sound.
What is needed to make a "real" Paula out of it is a procedure, like this used in SIDCog, which can translate the real Paula registers to the internal driver's format. All additional stuff should be removed. I don't know if the loop time saved by reducing channel numbers to 4 and removing all not needed things will be sufficient to implement PWMed volume control but this is not critical.
disk drive emulation
They did a RPi Pico based FDD controller in Adafruit so why emulate if we can use the real thing? This thing is waiting until I can find some more free time Then I have several thousands of floppy disks
What's the point of using a P2 if the Raspberry can already do everything ?
Raspberry can "do everything" using a Linux This means (1) slow start (2) input, picture and audio lag where picture lag<>audio lag.
Not necessarily, there is always the bare metal option. Linux is a helper that makes all the "boring" things available, but nothing prevents you from writing CPU code like a microcontroller.
There are frameworks ready to use for the onboard peripherals, and if I remember correctly, that there are at least a ZX Spectrum and C64 bare metal emulators available.
What's the point of using a P2 if the Raspberry can already do everything ?
Raspberry can "do everything" using a Linux This means (1) slow start (2) input, picture and audio lag where picture lag<>audio lag. While coders do their best the overall opinion is that FPGA emulators are always better.
P2 is not exactly an FPGA but it have a lot of common things with it. There are 8 cogs, there are 64 smart pins, they run in parallel like an FPGA. There is no Linux, it starts in miliseconds, it can have very low audio lag, it is fully possible to synchronize audio and video.
Yea, that's the big strength here: FPGA-like latency, while theoretically being quite low-cost.
I do think you can get a Pi to boot Linux and load MAME faster than a P2 can load one of my emulators, but certainly not with the default raspbian image lmao. If the P2 had access to full speed 4bit SD bus, it would probably be faster.
What's the point of using a P2 if the Raspberry can already do everything ?
Raspberry can "do everything" using a Linux This means (1) slow start (2) input, picture and audio lag where picture lag<>audio lag.
Not necessarily, there is always the bare metal option. Linux is a helper that makes all the "boring" things available, but nothing prevents you from writing CPU code like a microcontroller.
There are frameworks ready to use for the onboard peripherals, and if I remember correctly, that there are at least a ZX Spectrum and C64 bare metal emulators available.
Of course they are: I use one of this called Ultibo. But.. these Linux based emulators are hard to port because of (often not necessary) dependencies. I ported a libmad mp3 decoder to Ultibo: the main work was to find and remove all these printfs to logs and stderr. After this the library works and I have a bare metal player using (converted) Winamp skins.
Still, after several years of playing with Ultibo, in my opinion P2 is much better platform for a retroemulator than a Pi if only its processing power is sufficient to do the job. Amiga should fit, at least A500/600.
I haven't thought super thoroughly about Amiga (partially because a computer emulator ensues a lot more fiddly boring stuff like disk drive emulation than a cartridge game system), but the big problem is that there's too much RAM to keep it all in Hub (unless you wanna go with an unexpanded A1000, lol) and having the external memory writeable causes a number of issues (native word size is 32 bit, exec queue needs to be invalidated/updated for self-modifying code, etc).
You bring up a good point. Most Amiga games expect 512KB of memory. I don't know how fast that could be paged in/out of PSRAM as there seems to be a bit of overhead latency for small transfers. What about keeping the HUB for Chip RAM(the RAM of the Amiga that is shared between the 68000, Agnus, Gary, Paula and Denise) and loading everything else from PSRAM? https://www.cypherpunk.at/download/eagle/32c3/AMIGA/A500_BD.png
There is the issue of the ROM as well, which is 256KB at minimum.
@hinv said:
Also "Console Emulation" using a Raspberry Pi as a base for it's fast processor could rope in people from the Pi community also.
IMHO, if I have to use a Raspberry Pi, I'll run the emulator on it.
What's the point of using a P2 if the Raspberry can already do everything ?
Because anything running linux/windows sucks at emulating things in real time unless there is a HUGE abundance of resources. I've played with PiMiga2.0 on the Pi400, and am not really impressed with the performance as it is a bit jittery, laggy.
And then there is the Amiga and other retro computer/console communities that could get roped in to if the P2 helped rejuvenate their favorite retro games.
We have the 68000 processor, we have a Paula-like (don't know how much like) audio driver, we need the video driver and the Amiga can run on the P2.
The fun here is to run everything on the P2!
Well, without the Pi, it drives costs up to have to have an FTDI or CP102 chip, Flash, MicroSD, and still you need something to develop on since the P2 is not self hosting(yet).
Also the Musashi 68000 emulation on a Raspberry Pi 3B+ is somewhere equivalent to a 700MHz 68030, and emu68k (bare metal 68k emulator for pistorm) is like a 3000MHz 68030. Even though it was 16bit, the 68000 was a bit weak for the Amiga, and some games demanded more.
Comments
This I got at the first run:
Now that's interesting: It boots up but the graphics are garbled? That's surely odd. Can you post checksums of all your mslug rom files?
EDIT: is the sound garbled, too? Or is it just the graphics?
It seems I have no sound at all. It boots, it moves, I can see moving, but distorted sprites. I changed audio pin (to 14) in 2 places. and video pin to 8 in config file. In my configuration I can only place the accessory boards into 0 or 8. Maybe I have to find another version of this game and try it.
What tool I have to use to compute these checksums?
Double check that, no sound at all is odd, too (the audio config that actually matters is the one in neoyume_lower. Double check). Could also mean that the Z80 program is getting bungled.
If you have 7-Zip installed, you have a "CRC/SHA" context menu. Any checksum will do. Alternatively, Linux (or windows with git bash) command line has
md5sum *.binI downloaded another version with the same effect. Maybe I need to use a newer flexprop? I didn't recompile it for several days.
I'm currently using the official 5.9.11 build (from May 21st), but a slightly older version shouldn't be an issue.
EDIT: Also, you're using VGA or HDMI?
VGA, as it was configured (only pin changed to 8, where I have it connected). Let's compile 5.9.11 and try again
Edit: It's 5.9.12, video is as it were before, but then I have now audio - sampled effects, no music (I don't know if it should be any)
For game development, I think something like Andre LaMothe's P1 Hydra (with updated connectors) would be useful -- but then, I'm not a gamer.
As said before, I too would find a P2 board (could be an Edge carrier or just a P2+PSRAM standalone board) with hardwired connectors arranged in a sensible manner appealing.
Anyways, I fixed the ADPCM, I think. No more dud notes, pops and random electrofarts. Also optimized the memory arbiter a bit. It turns out there are plenty of cycles during the setup phase to perform the target address calculation.
0.04 does the same video garbage in my configuration as 0.03. I tried also vga3x and HDMI: it's all the same. Combinations of PSRAM delays gives either the same garbage, or a yellow screen, or no boot at all
The board is this new P2-EC32MB rev. B
I wouldn't have expect 04 to fix it
. Only thing I can think of is that it's not loading the graphics correctly. The graphics, ADPCM and 68000 program all come from PSRAM, so only the program working is really very strange.
I've built a binary for VGA/Audio on basepin 8 (USB on pin 16 still), try that, to rule out any silly compiler issues.
Maybe the video can help to find what can cause the problem. I am going to sleep now
That looks like the reads are being glitched, which to me makes no sense (in the context of the 68k program running just fine). Surely a headache. Will have a deeper think tomorrow.
For today, here's a little video of me being bad at Samurai Shodown, because why not? Notice how the audio isn't brapped at all. It like actually works.
Well done on the latest audio work. What's left now?
@JonnyMac said:
I would venture a guess that more games were developed fro the DemoBoard than for the Hydra, at least that is what it seemed like in the Forums, but then I didn't have one, and I had 2 DemoBoards. The great thing about the Hydra was not the Hydra itself, it was the book, IMHO. Yeah the connectors were handy, but it wasn't anything special. The cartridges were almost never used, because they were expensive, and we have microSD for pennies. Was there even any games that used the special network port?
I would somewhat agree. Here are some of my observations:
Standard 9-pin joysticks can be implemented with just 2 pins each because of the ADC's at our disposal. I say 2 because they could also double as serial ports.
2-TX/RX
4-SPI/microSD
4 2-DB9 Joystick/Serial ports
10 HDMI
5 - VGA \
2 - Audio out > can be and adapter on HDMI port
1 - Audio in
8-4 USB ports
18 pins PSRAM
4 - PS/2 Keyboard & Mouse
sum(above) = 58 pins.
But consider this, retro gaming has gotten really big lately with people wanting to relive their earlier gaming experience. Also retro programming has picked up lately also, with a company (Retro Games Ldt) launching
The C64 Mini, The C64 Maxi, and The A500 Mini I personally bought the The64 Mini and Maxi, but looking back I wish I would have bought a system that would emulate all of them, like The MISTer.
Launching into that market could possibly sell a LOT of units and bring people into P2 programming if there was emulators already running, and a good book for it like there were for the Hydra, and the Propeller Manual that came with the DemoBoard.
Sometime ago I sketched this board with KiCad:
With hdmi, vga, audio, usb and ps/2 connectors for keyboard and mouse (like a PC), an SD card socket that replicates the P2-Edge onboard for easy access and two additional USB ports for game controllers (don't think anyone need the real SNES controllers as of today...). I have some doubts about the hdmi and the licensing if/when associated with audio (is there an HDMI driver with audio support ?) and the requirements on the P2 side (highest clock speed and limitations), VGA-to-HDMI converters are easy and inexpensive enough to obtain. Two (or more) "expansion slots" to break-out all free pins for add-ons like high-quality DAC, more RAM, wireless network, etc.
The P2 Edge mounted horizontally to make it more compact, but it would be wonderful to use this module https://forums.parallax.com/discussion/174317/new-p2-module when available as a replacement.
Through hole to be sold as an easy to solder kit (maybe).
I'll never be able to complete this project in a reasonable time, so all I can give are suggestions for anyone that want to venture into this.
Maybe we can split the thread if there is enough interest to avoid polluting this.
For the Amiga platform, I bought an A500plus, which is the best you can get to upgrade with the PiStorm which makes some of the old Amiga games actually a LOT more fun & playable, especially the ones with 3D graphics. The PiStorm emulated the MC68000 processor(at over 100MHz even), Fast RAM (even as large as 500MB), ROMs, Hard Drives, networking and USB keyboard & mouse, and Retargetable graphics(for bigger/more current monitors), all in the Raspberry Pi.
Then there is also The Minimig 1.81 that can do the hardware of the A500plus with more modern ports and can even use the PiStorm which gives the owner the fastest performance you can get on Amiga without the lag/gitter of software emulation.
So what if there was a P2 based Pi hat that provided chipset emulation and ports of the Amiga and other gaming platforms that had the memory of the P2-ES32MB.
The Raspberry Pi interface of the PiStorm uses 26 pins.
32MB PSRAM 18pins
VGA, 5pins
Audio out, 2pins
Audio in, 1pin
1 USB, 2 pins (the Pi has more but this one would be lower latency If needed)
2 DB9 ports, 4pins
2 PS2 ports, 4pins
Debug Serial TX/RX, 2pins (can debug be reassigned so that 64&63 are on the Pi connector for boot/debugging from Pi by default?)
Let the Pi do the microSD, most of the USB, HDMI, etc since it can do those better anyways.
A small board that plugs into the top of the Pi 40-pin interface could provide SPI flash, MicroSD slot and FTDI interface for a stand-alone P2 setup.
@Wuerfel_21 is there any ports/features I have missed that you needed for your emulations?
There won't be any explicit licencing to do uncompressed stereo PCM over HDMI. Those licences will be for 5+1 compression and the likes. Just like with SPDIF.
Not yet.
@macca said: Maybe we can split the thread if there is enough interest to avoid polluting this.
I think "Console Emulation" is what we are talking about, and also a great way to get more eyes on the P2.
Also "Console Emulation" using a Raspberry Pi as a base for it's fast processor could rope in people from the Pi community also.
And then there is the Amiga and other retro computer/console communities that could get roped in to if the P2 helped rejuvenate their favorite retro games.
Also putting it in the form of a Pi hat could eliminate the requirement for microSD, flash, PropPlug and/or power supply and at the same time be tied into a development platform already supported with flexprop(with some slight modifications for loading).
I would love other opinions on it.
I think split is needed. There are 2 big topics now: a P2 software emulators of retroconsoles, and a retroemulator board (which is also one of my dreams)
A Raspberry Pi P2 board format can be also convenient
IMHO, if I have to use a Raspberry Pi, I'll run the emulator on it.
What's the point of using a P2 if the Raspberry can already do everything ?
We have the 68000 processor, we have a Paula-like (don't know how much like) audio driver, we need the video driver and the Amiga can run on the P2.
The fun here is to run everything on the P2!
I haven't thought super thoroughly about Amiga (partially because a computer emulator ensues a lot more fiddly boring stuff like disk drive emulation than a cartridge game system), but the big problem is that there's too much RAM to keep it all in Hub (unless you wanna go with an unexpanded A1000, lol) and having the external memory writeable causes a number of issues (native word size is 32 bit, exec queue needs to be invalidated/updated for self-modifying code, etc).
In other news, I made a simple scripting system for game loading (since the ROM mapping can be all over the place and you can't tell from the MAME dump alone). Not super sophisticated though.
Old hardcoded load:
New scripted load:
I've also thrown a few more games at it, so here the current compatibility list:
Raspberry can "do everything" using a Linux This means (1) slow start (2) input, picture and audio lag where picture lag<>audio lag. While coders do their best the overall opinion is that FPGA emulators are always better.
P2 is not exactly an FPGA but it have a lot of common things with it. There are 8 cogs, there are 64 smart pins, they run in parallel like an FPGA. There is no Linux, it starts in miliseconds, it can have very low audio lag, it is fully possible to synchronize audio and video.
It runs at original Paula frequency and it can directly accept Paula's sample periods without any translating. Internally it simulates as exactly as it can the Paula's method of outputting samples. What is different is the register structure and additional features (more channels, non-integer periods, 16-bit samples, channel synchronizing). Then it lacks Paula's method (PWM) to control channel volume, I multiply it instead. This low frequency PWM adds some distortion to the Paula' sound.
What is needed to make a "real" Paula out of it is a procedure, like this used in SIDCog, which can translate the real Paula registers to the internal driver's format. All additional stuff should be removed. I don't know if the loop time saved by reducing channel numbers to 4 and removing all not needed things will be sufficient to implement PWMed volume control but this is not critical.
They did a RPi Pico based FDD controller in Adafruit so why emulate if we can use the real thing?
This thing is waiting until I can find some more free time 
Then I have several thousands of floppy disks
Not necessarily, there is always the bare metal option. Linux is a helper that makes all the "boring" things available, but nothing prevents you from writing CPU code like a microcontroller.
There are frameworks ready to use for the onboard peripherals, and if I remember correctly, that there are at least a ZX Spectrum and C64 bare metal emulators available.
Yea, that's the big strength here: FPGA-like latency, while theoretically being quite low-cost.
I do think you can get a Pi to boot Linux and load MAME faster than a P2 can load one of my emulators, but certainly not with the default raspbian image lmao. If the P2 had access to full speed 4bit SD bus, it would probably be faster.
Of course they are: I use one of this called Ultibo. But.. these Linux based emulators are hard to port because of (often not necessary) dependencies. I ported a libmad mp3 decoder to Ultibo: the main work was to find and remove all these printfs to logs and stderr. After this the library works and I have a bare metal player using (converted) Winamp skins.
Still, after several years of playing with Ultibo, in my opinion P2 is much better platform for a retroemulator than a Pi if only its processing power is sufficient to do the job. Amiga should fit, at least A500/600.
No way
8 seconds was the best on a RPi3, RPi4 needs more, to get the emulator running. Then you still have to load your game from the same SD.
@Wuerfel_21 said:
You bring up a good point. Most Amiga games expect 512KB of memory. I don't know how fast that could be paged in/out of PSRAM as there seems to be a bit of overhead latency for small transfers. What about keeping the HUB for Chip RAM(the RAM of the Amiga that is shared between the 68000, Agnus, Gary, Paula and Denise) and loading everything else from PSRAM? https://www.cypherpunk.at/download/eagle/32c3/AMIGA/A500_BD.png
There is the issue of the ROM as well, which is 256KB at minimum.
Because anything running linux/windows sucks at emulating things in real time unless there is a HUGE abundance of resources. I've played with PiMiga2.0 on the Pi400, and am not really impressed with the performance as it is a bit jittery, laggy.
Well, without the Pi, it drives costs up to have to have an FTDI or CP102 chip, Flash, MicroSD, and still you need something to develop on since the P2 is not self hosting(yet).
Also the Musashi 68000 emulation on a Raspberry Pi 3B+ is somewhere equivalent to a 700MHz 68030, and emu68k (bare metal 68k emulator for pistorm) is like a 3000MHz 68030. Even though it was 16bit, the 68000 was a bit weak for the Amiga, and some games demanded more.