Sadly not pretty pictures right now, but I am actively working on fixing the C65-mode bitplanes. This largely consists of making some changes to work out how far the data is getting through the pipeline, resynthesising, and then repeating until I find where the bitplane data is reaching the bit bucket. What I know so far, is that bitplane mode turns on, and that the bitplane complement bits work just fine. It just seems that the bitplane feeders are either not activating when they should, or that they just receive (or just output) all zeroes.
Of course this debug process means I sit around waiting 1 - 2 hours for synthesis sometimes, so in those gaps I am implementing GeoRAM and REU emulation. These turn out to be not that hard to do. GeoRAM is just trivial to implement, because of its super-cheap design. The REU is also fairly easy to implement because its functions are quite easily mapped to the C65's DMAgic. So I am just implementing it as a special front-end to the DMAgic interface in the CPU. The only new feature to add here is the verify mode of the REU, which DMAgic lacks. So it is quite likely that I will have these two RAM expansion controllers working fairly soon -- of course it would then be REALLY nice to have the 128MB DDR2 RAM working, so that they can be usefully used.
In any case, the hypervisor will be able to control the size of each RAM expansion, and point them to the same or different places anywhere in the full 28-bit address space. This means that you will be able to do weird things like point the REU expansion memory to the C64-mode 64KB of RAM, or to colour RAM, or to any other weird location you might choose.
You said " This means that you will be able to do weird things like point the REU expansion memory to the C64-mode 64KB of RAM, or to colour RAM, or to any other weird location you might choose. "
ReplyDeleteReply: Isn't that dangerous? Is it advisable? Is it safe?
It's a bit like bungy jumping: Sure its' dangerous, but it can be fun to try, anyway ;) Of course the Hypervisor would normally set things up for you so that this isn't how things are arranged -- but it is technically possible to do.
DeleteI will ply it safe :)
DeleteGreat! :) I am really looking forward for 128M RAM support, also some kind of ZP based addressing to allow linearly addressing the full RAM space. With some kind of ZP cache (hmm) it would be even quite fast! Especially with the ability to auto increment/decrement feature as well. It's always good to so see how many nice new features can be read on C65GS/MEGA65 btw :) Great work! Thanks.
ReplyDeleteSo there is already 32-bit ZP indirect addressing mode (I talk about it in one of the other posts on the blog). I keep thinking about a ZP cache, but have yet to implement it.
DeleteAh, hmm, so I may be lost somewhere, my last memory was about "on the TODO list" state :) Great, thanks :)
DeleteOriginal REU has some issues (memory holes, CPU stun etc.) which could be mitigated in Your design. Also, up to 16MB REU implementations existing today are historically horrible designs (512KB memory pages) . Hope You'll do some good hardware from engineers point of view :)
ReplyDeleteMy plan is that the REU emulation will provide access to 16MB of contiguous memory, although I might have to offer emulation of the 512K page bug/feature. The CPU will be suspended during DMA still, because in fact on the MEGA65 the DMAgic is part of the CPU.
Delete