Wouldn't it be nice to have a single mx4 card with...
- 4mb rom
- 4mb ram compatible with current expansions but also pageable as a new standard at c000
- 8kb ram if any left over in the multiface 2 area
Just 1 board with all our rom and ram needs instead of multiple for ram and multiple for rom...
Isn't ram cheap these days? Yeah you could make 16mb or 32mb ram too, but 4mb means some cool software could load from sdcard into high memory and dma for plus machines without conflicts and have lots of animations for all CPCs
BTW if you have 16mb ram, that can switch complete lots of 64kb like we can already, then we can have 256 x 64kb tasks i believe with no disabling of interrupts during superfast 64kb context switches.
Quote from: zhulien on 13:35, 28 October 22Isn't ram cheap these days?
what do you define as "cheap"? 4MB RAM that can easily be used with a CPC will be around 35€.
35 euro is cheap. I remember buying 4mb ram for my amiga 1200 for... au$800
If only I had a time machine
Quote from: zhulien on 14:09, 28 October 22BTW if you have 16mb ram, that can switch complete lots of 64kb like we can already, then we can have 256 x 64kb tasks i believe with no disabling of interrupts during superfast 64kb context switches.
I'm not sure that's entirely feasible. In reality you'd have to do a fair bit of work to preserve register state, figure out what the next task you need to switch to is etc. And running 256 tasks is going to start to feel like swimming in molasses too, because everything is only getting 1/256th the CPU time...
I still remain unconvinced that there is a practical use for more than around 512K of RAM on an 8-bit system and even that is pushing it. And the dearth of examples for any 8-bit system tends to suggest that's the case. Is anyone really going to create 4Mb of animation frames for a game that only a handful of people would be able to play?
256 tasks yes is overkill, but it is possible. I mentioned 4mb would be nice which would give you 64 tasks of 64kb each. My MOS already does multitasking in 16kb blocks, but 64kb makes things easier because you can just push the registers and swap the memory as a whole, the pop them - and if the memory is swapped in a single instruction, then we don't need to turn off interrupts while swapping - we can either disable or block (without disabling) when pushing / popping.
the use is multiple - if it can be switched to upper memory, i could imagine a future music tracker on plus machines having lots of DMA sample RAM without DMA issues, but if mapped in normal ways, then of course, it would behave as normal DkTronics ones do - but... the cavet that differs from current 4mb expansions - is letting you swap 64kb chunks as an option for every 64kb block, not only some of them (currently we can only do that for the first 512kb - giving 8 64kb tasks).
I am unsure how Symbos does this, but I can think of a few ways it might. Since each RAM can be switched instantly to the next, then think of each 64kb as a linked list where the context switcher differs ever so slightly in each 64kb - that goes to the next in round-robin fashion. Remember, swap the memory as a whole, the next instruction just continues (although from another bank).
I'm still curious to find an application for the CPC where >512KB makes a difference.
4MB RAM is not CPC standard. 4MB ROM is not Plus standard. :)
RAM mapped outside of the "normal" way isn't going to be visible to the Plus DMA. And you can't switch tasks in a single instruction, you need to store the state of all the registers, including the stack pointer, figure out what the next task is and switch to that bank. And that's probably going to involve at least one 64K bank being dedicated to process management and a significant chunk of time to task switching.
Nothing comes for free, ever.
Quote from: andycadley on 23:40, 28 October 22you need to store the state of all the registers, including the stack pointer, figure out what the next task is and switch to that bank. And that's probably going to involve at least one 64K bank being dedicated to process management and a significant chunk of time to task switching.
Nothing comes for free, ever.
This is exactly what the SymbOS task scheduler is doing and it's working fine on a 4MHz CPC even with a lot of active tasks:
https://youtu.be/Mtlfr-ZNp20?t=60 (see starting at 1:00)
Task switching including saving and restoring register content and memory banking (yes, usually whole 64K banks) only takes a few rasterlines. It's not so much more than required for the CPC-OS interrupt handler.
Quote from: eto on 21:09, 28 October 22I'm still curious to find an application for the CPC where >512KB makes a difference.
Well, I posted that more often.
Quote from: TotO on 22:41, 28 October 224MB RAM is not CPC standard. 4MB ROM is not Plus standard. :)
Who defines that?
Quote from: GUNHED on 13:46, 03 November 22Who defines that?
Amstrad!
The A10 address line is reserved for peripherals. (Floppy Drive Controller, RS232 interface, etc.)
You don't have to implement it to decode a standard RAM expansion.
Quote from: TotO on 13:47, 03 November 22Quote from: GUNHED on 13:46, 03 November 22Who defines that?
Amstrad!
Ok, in this case we're limited to max. 128 KB (see CPC6128 and 6128plus) forever.
And what's great about it? Proper usage of RAM mode &7FC3!!! ;D ;D ;D
Quote from: GUNHED on 13:48, 03 November 22Ok, in this case we're limited to max. 128 KB (see CPC6128 and 6128plus) forever.
False, you can address up to 512K (or 2x256K as dk'Tronics does) using the same base address.
And up to 2 MB involving the A8 and A9 address lines, not used by any CPC's systems decoding. :)
Quote from: TotO on 13:54, 03 November 22Quote from: GUNHED on 13:48, 03 November 22Ok, in this case we're limited to max. 128 KB (see CPC6128 and 6128plus) forever.
False, you can address up to 512K (or 2x256K as dk'Tronics does) using the same base address.
And up to 2 MB involving the A8 and A9 address lines, not used by any CPC's systems decoding. :)
Wrong, you talked about Amstrad first, now you talk about dk'tronics. That's two different companies.
Quote from: GUNHED on 14:05, 03 November 22Wrong, you talked about Amstrad first, now you talk about dk'tronics. That's two different companies.
And I continue.. dk'Tronics use standard Amstrad addressing! (compared to Dobbertin in example)
A15 A14 A13 A12 A11 A10
Gate Array PENR/INKR (&7Fxx) 0 1 x x x x
Gate Array RMR/MMR (&7Fxx) 0 x x x x x
CRTC (&BCxx-&BFxx) x 0 x x x x
Upper ROM buffer (&DFxx) x x 0 x x x
Printer (&EFxx) x x x 0 x x
PPI (&F4xx-&F7xx) x x x x 0 x
Peripherals (&F8xx-&FBxx) x x x x x 0
Deal with that for building standard Amstrad expansions. That all.
Quote from: GUNHED on 13:46, 03 November 22Well, I posted that more often.
You were pretty vague and except for Devilmarkus' demos there was nothing I could find. If you have examples, then share the names or these programs or even better, a link.
Quote from: zhulien on 13:35, 28 October 22Isn't ram cheap these days?
Not exactly. You can find modern RAM (DDR-SDRAM) for quite cheap and it comes by gigabytes. But it requires very complex clocks and lower voltages, so a lot of extra things will be needed to get it working.
For the CPC expansions usually we use SRAM. The easiest thing is to use SRAM that is 5V compatible The chips don't get larger than 1MB (that I could find), and this costs about 10$ a piece. Larger chips are only available in 3.3V versions so some "level shifters" are needed. It's possible but your card gets more complicated.
If you work in the same way for ROM and everything else you want to add... well in the end your card costs 200$ or more, and it's easier to build a complete computer instead of a CPC expansion because you're not using very much of the CPC anymore.
Quote from: TotO on 14:12, 03 November 22Quote from: GUNHED on 14:05, 03 November 22Wrong, you talked about Amstrad first, now you talk about dk'tronics. That's two different companies.
And I continue.. dk'Tronics use standard Amstrad addressing! (compared to Dobbertin in example)
A15 A14 A13 A12 A11 A10
Gate Array PENR/INKR (&7Fxx) 0 1 x x x x
Gate Array RMR/MMR (&7Fxx) 0 x x x x x
CRTC (&BCxx-&BFxx) x 0 x x x x
Upper ROM buffer (&DFxx) x x 0 x x x
Printer (&EFxx) x x x 0 x x
PPI (&F4xx-&F7xx) x x x x 0 x
Peripherals (&F8xx-&FBxx) x x x x x 0
Deal with that for building standard Amstrad expansions. That all.
1. Well, what's the difference between dk'tronics and Dobbertin? I wouldn't know any to be honest.
2. Ok, you're fine with 2 MB (address bits 9 and 8 in addition). Agreed.
Why not 4 MB and using address bits 11 and 10 too? In real life I never had a problem with that, even though PPI does use 11. And I tested quit lots of combinations.
3. Bit 10 for pheripherials: As long as they are not addressed by this single bit it should be fine. Also here I couln't find a conflict.
A while ago I suggested (and started) a conflict list. Like usually very few users (nobody) added content anyway.
But I'm really interested in 1.
BTW: I don't see a reason to make dk'tronics the standard, there were Vortex expansions too, having additional features. Or the SF2 could do more RAM banking than people usually use.
Quote from: andycadley on 23:40, 28 October 22RAM mapped outside of the "normal" way isn't going to be visible to the Plus DMA. And you can't switch tasks in a single instruction, you need to store the state of all the registers, including the stack pointer, figure out what the next task is and switch to that bank. And that's probably going to involve at least one 64K bank being dedicated to process management and a significant chunk of time to task switching.
Nothing comes for free, ever.
I never said switching tasks in a single instruction. I said switch banks in a single instruction.
Can a plus do dma from c000 area like from ROM? I thought it could. Therefore if a RAM was pretending to be ROM but writable them I don't see why that cannot be a good thing as an option for software that wants to use it. Since CPC is designed to have 4mb of ROM, then in theory 4mb RAM can pretend to be ROM that is writable.
Fun thing: What you propose is part of SF2, it has 512 KB ROM - realized using an S-RAM. So to write in this 'ROM' you do actually bank it in a &4000 and then write to this RAM area.
Thinking of a 16 MB RAM expansion, what would it need? Ability of...
- banking in 16 KB of RAM at 0,4000,8000,C000
- banking in 2 KB blocks in every 2 KB step / page of block &8000-&BFFF.
- compatibility mode for current 4 MB expansion
Quote from: zhulien on 19:02, 03 November 22Can a plus do dma from c000 area like from ROM? I thought it could. Therefore if a RAM was pretending to be ROM but writable them I don't see why that cannot be a good thing as an option for software that wants to use it. Since CPC is designed to have 4mb of ROM, then in theory 4mb RAM can pretend to be ROM that is writable.
No, the DMA processor only ever sees the main 64K of RAM, regardless of what is banked in or out of any given address range.
Quote from: andycadley on 19:50, 03 November 22Quote from: zhulien on 19:02, 03 November 22Can a plus do dma from c000 area like from ROM? I thought it could. Therefore if a RAM was pretending to be ROM but writable them I don't see why that cannot be a good thing as an option for software that wants to use it. Since CPC is designed to have 4mb of ROM, then in theory 4mb RAM can pretend to be ROM that is writable.
No, the DMA processor only ever sees the main 64K of RAM, regardless of what is banked in or out of any given address range.
I guess then my suggestion still solves the DMA issue of the plus machines, just not giving it more DMA space. I like the idea of something like the SF2 RAM / ROM - if someone was to make a good new RAM expansion that isn't just a re-hash of the past 20 years - that would be fantastic!
Of course we still need standard 512kb RAM expansions on the market - why not, it satisfies a good minimum useful amount of RAM - and I guess 256kb if it can be made super cheap.
Quote from: GUNHED on 19:11, 03 November 22Fun thing: What you propose is part of SF2, it has 512 KB ROM - realized using an S-RAM. So to write in this 'ROM' you do actually bank it in a &4000 and then write to this RAM area.
Thinking of a 16 MB RAM expansion, what would it need? Ability of...
- banking in 16 KB of RAM at 0,4000,8000,C000
- banking in 2 KB blocks in every 2 KB step / page of block &8000-&BFFF.
- compatibility mode for current 4 MB expansion
plus the 64kb banked mode, basically the same modes of all DkTronics RAM plus the added flexibility you mentioned above - there can be multiple ways to achieve that - you could even make silly sequences of codes to output to a port like enabling plus features, this could be the plus plus ram feature set.
It is super easy to add a MMU to bank extra memory into the existing CPC 16K pages layout or to change the chunk size to 64K, 8K, 4K, 2K ... and keep the compatibility. But, there are no reason to do it as programmers will not use, because not CPC standard. :-\
Quote from: zhulien on 01:05, 04 November 22Of course we still need standard 512kb RAM expansions on the market - why not, it satisfies a good minimum useful amount of RAM - and I guess 256kb if it can be made super cheap.
there is no relevant price difference between 256K and 512K if you are using SRAMs. Both require one IC and both IC types are similar price. It could even be that you get the 512K SRAM cheaper than the 256K type.
Quote from: TotO on 08:37, 04 November 22It is super easy to add a MMU to bank extra memory into the existing CPC 16K pages layout or to change the chunk size to 64K, 8K, 4K, 2K ... and keep the compatibility
just out of curiosity: how much time do you think would need to be invested into the development of such a device? Until it's final, including testing, some basic software to prove it's working and documentation?
It's "just" configuring a CPLD, isn't it?
Quote from: Prodatron on 10:26, 04 November 22It's "just" configuring a CPLD, isn't it?
yeah....
and probably most of these further steps:
- defining a solution based on requirements and platform restrictions
- research matching components (long term availability and prices)
- design a prototype PCB
- order everything
- build personal prototype
- test prototype
- fix problems, repeat previous steps if necessary
- design final prototype PCB
- build final prototypes
- send out to testers and collect feedback
- final fixes, probably another PCB
- develop some POC software
- document
- release
My personal gut feeling would be 150-200 hours investment that someone who knows what he is doing has to spend to develop this. And probably a financial investment in the few hundred €.
I guess it will be easier to find someone, who is willing to invest time and money, if there is at least a PoC of a software that is limited by todays expansions and would truly benefit from a new expansion.
Quote from: eto on 10:16, 04 November 22just out of curiosity: how much time do you think would need to be invested into the development of such a device? Until it's final, including testing, some basic software to prove it's working and documentation?
It is the same way that I have explain to you to have 256K DRAM visible by the GA/CRTC by using a 74LS170 or a 74HCT670 to map 16x16K into the 64K address space. :) But using two circuits to be able to address a same amount of memory while reduce the chunks size. Next, it require a bit of configuration (through a CPLD to save room) and to patch the firmware to init the default pages to use (0, 1, 2, 3). I do not plane to do it, I have already done tests into the past. But, I can help you if you want.
What I think, it cost around 50€ and one week. :P
Quote from: TotO on 12:53, 04 November 22But, I can help you if you want.
Oh, thanks for the offer.
But I didn't mean that I am interested in realising this particular expansion. Not in the area of my skills. I was just curious what you think it would require as effort for you as an expert. Seems I was "a bit" off with my estimate and things are much easier once you have the expertise.
Quote from: eto on 13:20, 04 November 22Oh, thanks for the offer. But I didn't mean that I am interested in realising this particular expansion.
No problem.
For example, with a 8-bit buffer, you can map:
Same memory size:
- 32x 16K = 512K
- 64x 8K = 512K
- 128x 4K = 512K
- 256x 2K = 512K
Same chunks qty:
- 256x 16K = 4096K
- 256x 8K = 2048K
- 256x 4K = 1024K
- 256x 2K = 512K
Quote from: eto on 12:02, 04 November 22Quote from: Prodatron on 10:26, 04 November 22It's "just" configuring a CPLD, isn't it?
I guess it will be easier to find someone, who is willing to invest time and money, if there is at least a PoC of a software that is limited by todays expansions and would truly benefit from a new expansion.
I wonder if a loader for the amazing Alcon 2020 could make it run in such a RAM expansion?
forgot to mention, and this is important I think - 1 mx4 card which means I no longer need 2 just for 1mb memory & roms.