The current publicly available sources for the Minimig project only support the ECS chipset, there’s not yet any support for AGA. (The Minimig core used by the FPGA Replay board *does*, apparently, have robust AGA support, but the sources haven’t yet been released to the wider world.)
So I decided to have a go at adding a little AGA functionality myself.
Compared with the ECS chipset, the AGA chipset doesn’t actually add that much complexity. The extra features are basically:
- Colourtable extended from 32 entries to 256. There are still only 32 colourtable registers, and they’re accessed in banks, which are selected in another register.
- Colourtable entries are now 24-bit deep rather than just 12. A select bit in another register determines whether colourtable writes go to the most- or least-significant 12 bits.
- There are now 8 bitplanes instead of 6
- Bitplane data can be exclusive-ored with a mask value. This enables some neat tricks with “copper chunky” modes, among other things.
- Sprites can be high-res
- Data can now be fetched 32-bits at a time, double-pumped or both, giving an effective 64-bit datapath.
The easiest place to start is the colourtables, which in the present Minimig design are stored in registers. Since the colourtable was about to balloon from 32 12-bit entries to 256 24-bit entries, I migrated the colourtable to a pair of M4Ks – one to take the upper 12-bits of each colour, the other to take the lower 12-bits.
I also implemented enough of the BPLCON3 and BPLCON4 registers to support colourtable bank selection and masking.
I’ve also created a small Copperlist demo in ADF format for testing, which can be found here.
This demo simply uses lower-bit entries and palette masking as a test – the following screenshot shows how it looks under ECS and under AGA.
(Note that while the colourtable entries store 24-bits, they’re still only displayed as 12-bit, because that’s all the DE1 Board’s VGA output can handle without extra dithering, which will come later.)
A git repo containing the current code is here, while a binary can be found here.
Please note that this is highly experimental – there are timing inaccuracies compared with the real chipset, extra-half-brite mode is currently broken. (and the normal Minimig boot text is missing as a result of another experiment to reduce the size of the boot ROM!)
hi MMrobinsonb5, just an off the cuff thought given im not a HW dev…
given today’s bits and plains options, why are we/you Open Hardware minimig devs starting with OCS, then AGA bits 24-bit deep 8 bitplanes etc
for instance the x264/ffmpeg digital video Encode/decode devs x264 now does generic 8bit,9bit and 10bit output,even though im told x264 uses integer 8bits,16bits and 32bits SIMD math routines on the internal de-packed RGBA
and OC today we have 2K/4K/and 8K super HD RED CAMS on the horizon and mass produced super/ultra HD screens coming with the latest 2K/4K screens are now coming with 10bit native (if you pay the price for that now)….
why you and all the other guys not start at AAA/AA+ and work down to AGA/OCS by throwing away the higher bits like the video devs, its not like you need to keep strict comparability while you prototype i assume
doesn’t todays FPGA come with integer 8bits,16bits and 32bits SIMD math capability’s ?
perhaps the core point im trying to ask is isn’t it better to set the video processing bar bit’s and planes as high as we know today’s kit will be in 5 years and work down from there so you don’t have to totally redo the effort when these higher specs come along and everyone wants some of that.
, “be better not just good enough” seems to be the mistake many commercial devs make, especially AMD and the pro ARM SOC guy’s making phones to beat apple.
didnt dave/carl/others give enough data regarding AAA/AA+ to impliment it to as least some degree in FPGA years ago ?
Good questions – and the best concise answer I can give is “because I’m a beginner, and still on a steep learning curve”! FPGAs were a closed book to me a year ago, and I started all this mainly because I wanted to be able to fix a problem with the Turbo Chameleon 64’s Minimig core (and I finally managed it a couple of weeks ago!)
As for why we re-invent a 27-year-old design and not something more modern: probably because (a) it’s possible for one person to understand the workings of the entire design, (b) it’s something a lot of us are familiar with from teenage years – never underestimate the power of nostalgia! – (c) there’s a large library of ready-made software we can test against, and robust emulators for comparison.
Having said that, as time allows I do plan to add some trickery to the Minimig core – I’d like to add hardware assist for JPEG and MP3 decoding, for instance – but again mostly as a learning exercise, not as part of any desire to be on the leading edge of research!
ohh i totally forgot to post the thing i came here to do, that being pointing you to using/interfacing the Transputer FPGA cores as its still going you know as XCORE and doesn’t seem to get mentioned these days and lots of open HW code, check these videos out to grasp its potential ( especially today given the x86 market place is in turmoil failing MS,AMD etc as the BIG x86 vendors scramble to take up ARM cortex A8 market hardware options ASAP) to help and massively expand minimig/arcade/Opencores
Hey, I posted this on the minimig discussion board….did you ever see these!!!?
Like the guy stated in the earlier post….this looks like there are some maybe Commodore proprietary Harware Descriptor Language files from the AAA prototype the Nyx…or what ever it was…also other HDL files for various glue logic and some struff for the AA chipset and the never completed A3000+…
I wonder if the guys at Natami used these or just did it all from scratch…