3 ms·

What you're describing here is still CPU emulation (same as the Crusoe), not system emulation. The Amiga equivalent for what I'm hypothesizing exists here, wou

by derefr 3y ago

What you're describing here is still CPU emulation (same as the Crusoe), not system emulation. The Amiga equivalent for what I'm hypothesizing exists here, would be something that allows you to throw out the entire guts of your Amiga and replace it all with a freshly-printed PCB that has all the same ports/socket, but just one (modern, easy-to-source) chip on it, that internally emulates not only the 68000 but also all the other chips on the Amiga motherboard. And then anything you plugged into the original Amiga, would plug into this replacement board and work the same.

bitwize 3y ago
The Atari 2600+ may be closer to what you were talking about. It is an SBC running an emulator, but it has external interfaces for the real Atari 2600 cartridge and joystick ports. There are some drawbacks; the system snarfs the entire ROM image into memory in a way that's not (yet) compatible with bank-switched ROMs or more exotic carts with extra hardware like Pitfall II, rather than just mapping the ROM into the 6502 address space. But when it works it feels more authentically Atari 2600-ish than many of the emulation boxes that have been released previously.
cjdell 3y ago
Would that not just be something like a Raspberry Pi Compute Module running an emulator full screen and a custom IO breakout host board?
- derefr 3y ago
  In most designs I've seen for projects like this, the "custom IO breakout host board" isn't really just a breakout board — it has a lot of bus controller chips of its own, because most modern bus protocols are just too fast/expensive to be run over GPIO pins. These extra chips usually raise the BOM past the point where it's worth it to build such a system; as at that point it's cheaper to just source old x86 parts (controller chips, sometimes CPU as well) from e-waste. You want as much of that "motherboard logic" to be handled internal to the SoC as possible. Ideally, the board should only have the one SoC chip on it, plus jellybean parts and passives, plus ports and slots. Also, let's lean on your example of video for a moment: "running an emulator full screen" isn't nearly the same thing as emulating the host busses — in that it results in the host describing that screen down its own SoC pins using something like HDMI. Whereas we don't even necessarily want a precomposed description of the screen on a signal line. Remember, we're emulating the CPU and motherboard (and RAM, just because it's impractical not to) inside the SoC — but video support isn't actually an inherent part of an x86 motherboard. OEMs might integrate support for it onto a motherboard — but that "support" is just an embedded PCI-bus device, not some separate VGA bus. Perhaps the system this board would revitalize, does something special with the communicated changes to the video data, such that pre-composed VGA (let alone HDMI) wouldn't solve the problem. For example, what if the system uses a custom PCI video card, that takes its VRAM and renders it out each frame, by compositing it together with another input video signal (ala the "video toasters" of the era)? The only way to make that kind of thing work, is to emulate the PCI bus such that you can just plug the custom video card into one of the board's PCI sockets, and the emulated system will pick it up and use it.
rbanffy 3y ago
It's emulating more than just the CPU if it exposes the RPi filesystem to the Amiga. With access to the CPU bus, you can pretend to be a number of other peripherals as well, or lots and lots of RAM and every ROM version available on the Pi side.
- derefr 3y ago
  My point was more that there's no part of this project that actually emulates "a number of other peripherals", so it still needs to plug into a board that has working instances of all these other (no longer produced! rare! expensive!) chips on it. Consider a "field-found" repair of an Amiga, like this one: https://www.youtube.com/watch?v=V-wNbku3CeI https://www.youtube.com/watch?v=V-wNbku3CeI In the instance above, the board was able to be revived — but only after swapping out a few chips with spares! Spares that need to be sourced! But there are Amigas discovered in far worse internal condition. In those cases, the board itself is basically shot. Along with most of the chips. Often legs of DIPs are just corroded off, etc. Having a single-SoC bus-compatible board, that you could use to entirely replace the internals of an Amiga, would mean that in that particular case, you could just shake the scraps of rust that the board has become out of the case, clean up the case and peripherals (which are likely still fine), and then build a "new" Amiga by putting that new SoC board in. --- This is already a very common approach you'll see in e.g. the Gameboy modding scene — as so many gameboys are found as e-waste or in a ditch somewhere. Though the focus there isn't usually on decreasing parts cost with a one-SoC board, but rather getting perfect fidelity, since the target market is collectors who are willing to pay a high price and so a high BOM isn't as much a problem. Also, amusingly enough, as there are people creating not just new bus-compaible GB/GBC/GBA boards, but also new custom buttons + shells, and even new non-IP-restricted BIOS ROM code, a "repaired gameboy" might actually contain no Nintendo-original components whatsoever. It's more a "generic" gameboy (by analogy to generic pharmaceuticals) at that point.
  - rbanffy 3y ago
    > no part of this project that actually emulates "a number of other peripherals" It does - it's just that none of the emulated things go through the motherboard to be emulated. There is an Apple II HDMI board that can output Apple IIgs graphics from a II+ because it watches the peripheral bus for the signals a 65816 would make to setup a IIgs screen. Lots of Apple II accelerators emulate a number of things on-board and only use the socket to push peripheral IO. > then build a "new" Amiga by putting that new SoC board in. I really like this idea. A lot of the experience of a retro machine is the physical device. I've been toying with the idea of making Atari ST and Amiga keyboards with USB ports just so that the emulators would "feel" more real. I have a PC-122 keyboard and using it in combination with a 3270 emulator feels just right (even when the mainframe is running on an RPi)

by derefr 3y ago

bitwize 3y ago

The Atari 2600+ may be closer to what you were talking about. It is an SBC running an emulator, but it has external interfaces for the real Atari 2600 cartridge and joystick ports. There are some drawbacks; the system snarfs the entire ROM image into memory in a way that's not (yet) compatible with bank-switched ROMs or more exotic carts with extra hardware like Pitfall II, rather than just mapping the ROM into the 6502 address space. But when it works it feels more authentically Atari 2600-ish than many of the emulation boxes that have been released previously.

cjdell 3y ago

Would that not just be something like a Raspberry Pi Compute Module running an emulator full screen and a custom IO breakout host board?

derefr 3y ago
In most designs I've seen for projects like this, the "custom IO breakout host board" isn't really just a breakout board — it has a lot of bus controller chips of its own, because most modern bus protocols are just too fast/expensive to be run over GPIO pins. These extra chips usually raise the BOM past the point where it's worth it to build such a system; as at that point it's cheaper to just source old x86 parts (controller chips, sometimes CPU as well) from e-waste. You want as much of that "motherboard logic" to be handled internal to the SoC as possible. Ideally, the board should only have the one SoC chip on it, plus jellybean parts and passives, plus ports and slots. Also, let's lean on your example of video for a moment: "running an emulator full screen" isn't nearly the same thing as emulating the host busses — in that it results in the host describing that screen down its own SoC pins using something like HDMI. Whereas we don't even necessarily want a precomposed description of the screen on a signal line. Remember, we're emulating the CPU and motherboard (and RAM, just because it's impractical not to) inside the SoC — but video support isn't actually an inherent part of an x86 motherboard. OEMs might integrate support for it onto a motherboard — but that "support" is just an embedded PCI-bus device, not some separate VGA bus. Perhaps the system this board would revitalize, does something special with the communicated changes to the video data, such that pre-composed VGA (let alone HDMI) wouldn't solve the problem. For example, what if the system uses a custom PCI video card, that takes its VRAM and renders it out each frame, by compositing it together with another input video signal (ala the "video toasters" of the era)? The only way to make that kind of thing work, is to emulate the PCI bus such that you can just plug the custom video card into one of the board's PCI sockets, and the emulated system will pick it up and use it.

rbanffy 3y ago

It's emulating more than just the CPU if it exposes the RPi filesystem to the Amiga. With access to the CPU bus, you can pretend to be a number of other peripherals as well, or lots and lots of RAM and every ROM version available on the Pi side.

derefr 3y ago
My point was more that there's no part of this project that actually emulates "a number of other peripherals", so it still needs to plug into a board that has working instances of all these other (no longer produced! rare! expensive!) chips on it. Consider a "field-found" repair of an Amiga, like this one: https://www.youtube.com/watch?v=V-wNbku3CeI https://www.youtube.com/watch?v=V-wNbku3CeI In the instance above, the board was able to be revived — but only after swapping out a few chips with spares! Spares that need to be sourced! But there are Amigas discovered in far worse internal condition. In those cases, the board itself is basically shot. Along with most of the chips. Often legs of DIPs are just corroded off, etc. Having a single-SoC bus-compatible board, that you could use to entirely replace the internals of an Amiga, would mean that in that particular case, you could just shake the scraps of rust that the board has become out of the case, clean up the case and peripherals (which are likely still fine), and then build a "new" Amiga by putting that new SoC board in. --- This is already a very common approach you'll see in e.g. the Gameboy modding scene — as so many gameboys are found as e-waste or in a ditch somewhere. Though the focus there isn't usually on decreasing parts cost with a one-SoC board, but rather getting perfect fidelity, since the target market is collectors who are willing to pay a high price and so a high BOM isn't as much a problem. Also, amusingly enough, as there are people creating not just new bus-compaible GB/GBC/GBA boards, but also new custom buttons + shells, and even new non-IP-restricted BIOS ROM code, a "repaired gameboy" might actually contain no Nintendo-original components whatsoever. It's more a "generic" gameboy (by analogy to generic pharmaceuticals) at that point.
- rbanffy 3y ago
  > no part of this project that actually emulates "a number of other peripherals" It does - it's just that none of the emulated things go through the motherboard to be emulated. There is an Apple II HDMI board that can output Apple IIgs graphics from a II+ because it watches the peripheral bus for the signals a 65816 would make to setup a IIgs screen. Lots of Apple II accelerators emulate a number of things on-board and only use the socket to push peripheral IO. > then build a "new" Amiga by putting that new SoC board in. I really like this idea. A lot of the experience of a retro machine is the physical device. I've been toying with the idea of making Atari ST and Amiga keyboards with USB ports just so that the emulators would "feel" more real. I have a PC-122 keyboard and using it in combination with a 3270 emulator feels just right (even when the mainframe is running on an RPi)