Hi everyone!
I'm about to start implementation of 3DO hdl core, I would appreciate any advice.
This branch may be dead, but I'm posting this in a hope someone is interested in it
3DO
- vgesoterica
- Posts: 61
- Joined: Wed May 05, 2021 1:44 pm
- Has thanked: 1 time
- Been thanked: 38 times
- kathleen
- Top Contributor
- Posts: 421
- Joined: Fri Jun 26, 2020 4:23 am
- Location: Belgium
- Has thanked: 243 times
- Been thanked: 138 times
Re: 3DO
Would be very nice to have this core on the Mister.
I was owning one back in the days and I'm sad to have sold it. Fining one now is hardly not possible or it costs a lot.
I'll really appreciate a 3DO core as well !
Thank you in advance for your work on this.
かすりん
Re: 3DO
still have my 3DO, got it when i had my A1200 back in 1993/4 ( ish ) my jaw dropped when i loaded nfs and played road rash way to late into the night ( compared to my Amiga games, have you seen outrun on the Amiga lol so bad )
there where some dreadful games but also some gems, my dad was amazed at the full motion video especially in road rash and had a load of fun playing return fire with him.
unfortunately i then saw doom on my dads 486 and that was that lol no 3do went into storage.
pretty scared these days tuning on any of my original hardware and a 3DO implemented on the Mister would be awesome.
Re: 3DO
cathrynmataga wrote: ↑Wed Jan 11, 2023 4:50 am3DO has an FPU, and I don't believe anyone has done an FPU for any core on Mister? Right? I think creating an FPGA FPU is advanced level.
Hi,
Whilst not specific to MiSTer, although I do own a fully kitted out one, I have written an FPU for my Risc-V project on the ULX3S. It presently handles conversions integer <-> float, changes in precision, half/single/double <-> half/single/double, along with < and =, min/max, sign maniplulation, + - * / sqrt and a*b+c (and variations thereof).
It is written in Silice https://github.com/sylefeb/Silice which translates into Verilog, but it is (hopefully) readable, and could form the basis of an FPU for MiSTer.
Whilst the maximum my code can handle is double-precision (64-bit), it should not be too difficult to allow the handling of extended-precision (80-bit) which would be required for 68881/68882 and x87 FPUs.
To allow for ease of handling multi-precision formats, my code expands all floating-point numbers into double-precision bitfields and then repacks them to the required precision at the end. It is not fully compliant with the IEEE754 standards, and there may be a few errors in it, but it is sufficient to run a Risc-V RV64GC CPU for my little project.
Writing an FPU has been a challenge, but a fun one, and I hope that it could prove useful for other areas.
Code is here: https://github.com/rob-ng15/PAWSv2/tree/devel see https://github.com/rob-ng15/PAWSv2/blob ... 4/FPU64.si for the floating-point unit.
Rob.
Re: 3DO
robng15 wrote: ↑Fri Mar 31, 2023 9:29 amcathrynmataga wrote: ↑Wed Jan 11, 2023 4:50 am3DO has an FPU, and I don't believe anyone has done an FPU for any core on Mister? Right? I think creating an FPGA FPU is advanced level.
Hi,
Whilst not specific to MiSTer, although I do own a fully kitted out one, I have written an FPU for my Risc-V project on the ULX3S. It presently handles conversions integer <-> float, changes in precision, half/single/double <-> half/single/double, along with < and =, min/max, sign maniplulation, + - * / sqrt and a*b+c (and variations thereof).
It is written in Silice https://github.com/sylefeb/Silice which translates into Verilog, but it is (hopefully) readable, and could form the basis of an FPU for MiSTer.
Whilst the maximum my code can handle is double-precision (64-bit), it should not be too difficult to allow the handling of extended-precision (80-bit) which would be required for 68881/68882 and x87 FPUs.
To allow for ease of handling multi-precision formats, my code expands all floating-point numbers into double-precision bitfields and then repacks them to the required precision at the end. It is not fully compliant with the IEEE754 standards, and there may be a few errors in it, but it is sufficient to run a Risc-V RV64GC CPU for my little project.
Writing an FPU has been a challenge, but a fun one, and I hope that it could prove useful for other areas.
Code is here: https://github.com/rob-ng15/PAWSv2/tree/devel see https://github.com/rob-ng15/PAWSv2/blob ... 4/FPU64.si for the floating-point unit.
Rob.
This deserves a whole thread itself. Nice job!
Re: 3DO
The 68881 and 68882 are able to perform a lot more operations than Risc-V requires, including remainder, sin, cos, tan, log and pow operations, plus they have the ability to work with packed binary numbers.
So there would still be a lot of work required, extended-precision support, which would be the easy part, as well as the more complex operations listed above.
- LamerDeluxe
- Top Contributor
- Posts: 1239
- Joined: Sun May 24, 2020 10:25 pm
- Has thanked: 887 times
- Been thanked: 284 times
Re: 3DO
robng15 wrote: ↑Fri Mar 31, 2023 8:27 pmThe 68881 and 68882 are able to perform a lot more operations than Risc-V requires, including remainder, sin, cos, tan, log and pow operations, plus they have the ability to work with packed binary numbers.
So there would still be a lot of work required, extended-precision support, which would be the easy part, as well as the more complex operations listed above.
I see, I can imagine those functions would be quite complicated to implement.
Re: 3DO
I think the traditional way to implement them is via a microcode ROM that runs through the simpler operations to obtain the required result.
As Risc-V doesn't require them in the fpu I've not had to implement them.
Re: 3DO
The other issue is timings. Most software for the Amiga would be developed to use exact timings for the FPU, which is definitely an added complication.
I am unable to find any information about the maths co-processor in the 3DO graphics chip, so I've no idea what abilities the FPU would need.
- LamerDeluxe
- Top Contributor
- Posts: 1239
- Joined: Sun May 24, 2020 10:25 pm
- Has thanked: 887 times
- Been thanked: 284 times
Re: 3DO
robng15 wrote: ↑Sat Apr 01, 2023 9:59 amThe other issue is timings. Most software for the Amiga would be developed to use exact timings for the FPU, which is definitely an added complication.
I am unable to find any information about the maths co-processor in the 3DO graphics chip, so I've no idea what abilities the FPU would need.
I think most software that supported an FPU on the Amiga didn't rely on the timing of the instructions. In my experience it was mostly 3D animation software that supported an FPU.
- salamantecas
- Posts: 108
- Joined: Sat Feb 26, 2022 8:31 pm
- Has thanked: 110 times
- Been thanked: 14 times
Re: 3DO
FPGAzumSpass wrote: ↑Thu Jun 11, 2020 3:55 amThe 3DO has 2 external SRAMs for VRAM, each of them bigger than internal BRam of the Cyclone 5 FPGA.
So don't expect a 100% cycle accurate core with the Mister platform, but that's true for most newer consoles.(Gen5+)CPU side looks better, could probably use a stripped down version from the GBA, as it's an older ARM.
Overall it should be possible if you don't mind a few quirks and tricks to make it work.Creating it will be a pain, as there is no good opensource emulator where you could look up how things work and i didn't found documentation with a quick search.
So you probably need someone who wants to reverse engineer AND create HDL from it or a team.
It would be a fantastic idea if it born of your hands using the tricks you consider necessary. 3do is something that must be preserved because it is part of the history of video games. I have used it a lot and in the end the hardware ends up failing, I would really like to see a core of your hands doing the magic possible, I hope you dare to do it one day, thanks