News:

Printed Amstrad Addict magazine announced, check it out here!

Main Menu
avatar_zhulien

Ram and rom, wouldn't it be nice...

Started by zhulien, 13:35, 28 October 22

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

zhulien

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

zhulien

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.

eto

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€.




zhulien

35 euro is cheap. I remember buying 4mb ram for my amiga 1200 for... au$800

If only I had a time machine

andycadley

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?

zhulien

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).

eto

I'm still curious to find an application for the CPC where >512KB makes a difference.



TotO

4MB RAM is not CPC standard. 4MB ROM is not Plus standard. :)
"You make one mistake in your life and the internet will never let you live it down" (Keith Goodyer)

andycadley

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.

Prodatron

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.

GRAPHICAL Z80 MULTITASKING OPERATING SYSTEM

GUNHED

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.
http://futureos.de --> Get the revolutionary FutureOS (Update: 2023.11.30)
http://futureos.cpc-live.com/files/LambdaSpeak_RSX_by_TFM.zip --> Get the RSX-ROM for LambdaSpeak :-) (Updated: 2021.12.26)

GUNHED

Quote from: TotO on 22:41, 28 October 224MB RAM is not CPC standard. 4MB ROM is not Plus standard. :)
Who defines that?
http://futureos.de --> Get the revolutionary FutureOS (Update: 2023.11.30)
http://futureos.cpc-live.com/files/LambdaSpeak_RSX_by_TFM.zip --> Get the RSX-ROM for LambdaSpeak :-) (Updated: 2021.12.26)

TotO

#12
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.
"You make one mistake in your life and the internet will never let you live it down" (Keith Goodyer)

GUNHED

Quote from: TotO on 13:47, 03 November 22
Quote 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
http://futureos.de --> Get the revolutionary FutureOS (Update: 2023.11.30)
http://futureos.cpc-live.com/files/LambdaSpeak_RSX_by_TFM.zip --> Get the RSX-ROM for LambdaSpeak :-) (Updated: 2021.12.26)

TotO

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. :)
"You make one mistake in your life and the internet will never let you live it down" (Keith Goodyer)

GUNHED

Quote from: TotO on 13:54, 03 November 22
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. :)
Wrong, you talked about Amstrad first, now you talk about dk'tronics. That's two different companies.
http://futureos.de --> Get the revolutionary FutureOS (Update: 2023.11.30)
http://futureos.cpc-live.com/files/LambdaSpeak_RSX_by_TFM.zip --> Get the RSX-ROM for LambdaSpeak :-) (Updated: 2021.12.26)

TotO

#16
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.
"You make one mistake in your life and the internet will never let you live it down" (Keith Goodyer)

eto

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.


PulkoMandy

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. 

GUNHED

Quote from: TotO on 14:12, 03 November 22
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.
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.
http://futureos.de --> Get the revolutionary FutureOS (Update: 2023.11.30)
http://futureos.cpc-live.com/files/LambdaSpeak_RSX_by_TFM.zip --> Get the RSX-ROM for LambdaSpeak :-) (Updated: 2021.12.26)

zhulien

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.

zhulien

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. 

GUNHED

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
http://futureos.de --> Get the revolutionary FutureOS (Update: 2023.11.30)
http://futureos.cpc-live.com/files/LambdaSpeak_RSX_by_TFM.zip --> Get the RSX-ROM for LambdaSpeak :-) (Updated: 2021.12.26)

andycadley

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.

zhulien

#24
Quote from: andycadley on 19:50, 03 November 22
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.
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.

Powered by SMFPacks Menu Editor Mod