Amiga.org
Amiga computer related discussion => Amiga Hardware Issues and discussion => Topic started by: leirbag28 on June 02, 2006, 04:03:50 AM
-
Why is it possible to have 8mb ChipRAM on WinUAE but not on a Regular Amiga?
As far as I am concerned I belive its possible without even using a gfx card.............I think All an Amiga needs is a WinUAE ChipRAM emulator.
By that I mean surely even a Plain Amiga can emulate the code or instructions that WinUAE uses to be capable of having 8mb ChipRAM..............as long as one has more than 8mb FastRAM to be used as ChipRAM.
Im so sure its possible in one way or another. If not that way...then maybe with an external gfx card kinda like a SUPER Graffitti or DCTV. and of course it being 100% compatible with all software
Its Possible!
-
The Amiga 4000 was to have the 8MB Chip capability, it has got the jumper for it, but 8MB of chip was never implemented.
Winuae has it there for.. reference :).
The A4000 chip ram, uses PC style Simm, but only addresses the 2MB.
-
WinUAE could probably have 1GB of chipmem if the programmer(s) felt like implementing it. But if you want it in real hardware then you need to make a new Agnus/Alice chip with a wider address bus.
-
The 2MB chipmem on real Amigas is a hardware limitation. As DamageX said, if you want to increase the chipmem then you have to replace the hardware.
With WinUAE, they have adjusted the emulation so it can access more memory than a real Amiga, which is why you can have 8MB of chipmem.
--
moto
-
Motorollin and the others are right, its the whole AGA/ECS/OSC chipset that would need to be updated to support 8MB, the chip ram address bus is a seperate one from the normal CPU bus and it simply doesnt have enough address lines to support 8MB.
You would need to upgrade all the chipset with one extra address bit to get 8MB chipram and unless you have the AGA designs that aint gonna happen. (And even if you did the A4000 was the only one with the extra address line on the motherboard, so on any other Amiga you would need to run a wire between each custom chip, carrying the extra bit.
The Boxer lifted the Chip Ram limit if I remember correctly, all memory could be assigned as Chip ram if needed.. because the Enhanced AGA chipset had the full 32bit address bus running to it.
for UAE its easy, as they emulate the chipset and motherboard routing so they could make it 32bit if needed.
Oh and why did you post the same question on aw.net?
-
Why is it possible to have 8mb ChipRAM on WinUAE but not on a Regular Amiga?
Emulation of a chipset is not bound to physical limitations of the original.
As far as I am concerned I belive its possible without even using a gfx card.............
No it is not.
I think All an Amiga needs is a WinUAE ChipRAM emulator.
By that I mean surely even a Plain Amiga can emulate the code or instructions that WinUAE uses to be capable of having 8mb ChipRAM..............as long as one has more than 8mb FastRAM to be used as ChipRAM.
It means running full UAE on your amiga. Ever tried that? Hint: It is slow. Very slow. Even the fastest classic is way too slow to reach even fraction of A500 speed.
You can't just fork out "chipram emulator", because there isn't one. The whole UAE is required.
Im so sure its possible in one way or another. If not that way...then maybe with an external gfx card kinda like a SUPER Graffitti or DCTV. and of course it being 100% compatible with all software
No, it is not possible in HW.
Its Possible!
No, it isn't.
-
Is it just me or is there once every 6 months a discussion about this ? :lol:
-
If you had an MMU I guess you could use the Fast ram as "virtual" chip ram in the same way it would normally use HD space as virtual memory, swapping blocks of fast ram into chip ram when needed. Although what with the custom chips having direct access to it (do they even go through the MMU?) it would be too difficult to know what chip ram was already in use. Swapping out chip ram the hardware was using might result in some weird happenings.
It would be ok if you were to only use the processor on the extra chip ram, but why the hell would anyone want to do that?
Maybe the OS could be updated so there were extra Exec library functions for declaring chip ram as "asleep" and ok to swap out. But that would mean all the software would have to be rewritten to use it.
-
Isn't it the same problem as begging and requesting for the Commodore 64 to have more than 64KB of RAM internally? I want my Commodore 64 to have 128 MB of internal RAM and produce more than 16 colors, and I want it to be 16 bit and not 8 bit. As if you are unhappy with what it is and want to change it.
-
Im sure most of you are more technically adept than I am.
But I believe it is possible.
Oli_HD wrote:
for UAE its easy, as they emulate the chipset and motherboard routing so they could make it 32bit if needed.
---------------------------------------------------------------
Ok then, it is time to create UAE for Amiga....to emulate the 32 bit needed for the chipRAM and have the rest of the emulation for everything else run natively since it is a real Amiga.............keeping everything still running smooth :-)
Oli_HD wrote:
Oh and why did you post the same question on aw.net?
-------------------------------------------------------------------
Its posted there also to get more variations of opinions............all the intelligent Amigans dont all necessarily hang out in Amiga.ORG only :-D
Leirbag28 wrote:
Quote:
As far as I am concerned I belive its possible without even using a gfx card.............
Piru wrote:
No it is not.
-----------------------------------------------------------
Then if it is not possible without a gfx card....it is possible with one as we already know..............so my solution in hardware would be.............create a gfx card thats accessed through RTG I suppose, but isnt a gfx card but only the ChipMem part of it and how it is accessed. And Whalla! you have more chipRAM on an Amiga! and less expencsive than a full gfx card. This would be the equivalent of taking a Picasso Board and leaving all necessary connections but removing the unecessary components and just the ChipRAM and how it is acccessed and all that pertains to it.
Piru wrote:
You can't just fork out "chipram emulator", because there isn't one. The whole UAE is required.
----------------------------------------------------------
Well then....one will have to be created to take care of that :-)
Tricky wrote:
If you had an MMU I guess you could use the Fast ram as "virtual" chip ram in the same way it would normally use HD space as virtual memory, swapping blocks of fast ram into chip ram when needed.
---------------------------------------------------------------
Ah......now we are getting somewhere :-) thanks for open mindedness :-)
foody wrote:
Re: 8 Mb CHIP RAM on All Amigas
Isn't it the same problem as begging and requesting for the Commodore 64 to have more than 64KB of RAM internally? I want my Commodore 64 to have 128 MB of internal RAM and produce more than 16 colors, and I want it to be 16 bit and not 8 bit. As if you are unhappy with what it is and want to change it.
---------------------------------------------------------------
No, its not the same..............Im happy with my Amiga...and want to keep on being happy with it............since no one is creating New Amigas.............I believe I can at least have my Amiga keep up as much as possible so that I can continue using it with pleasure...............PC's are horrible. If anyting, I will upgrade to an INTEL MAC with Bootcamp to Run Windows XP natively......and Run WinUAE also....and have the best of all 3 worlds..........and all this on a Mac which is definitely more of a pleasure to use that a PC.
-
HellCoder wrote:
Is it just me or is there once every 6 months a discussion about this ? :lol:
I thought this was a resurrected thread from the last time :-)
-
I belive that is not possible, but :) fblit what it does? would it be possible to to assign more memory to graphics with it ?
Maker of it said that he would try to make driver similar like graphicks cards for it?
Fblit have fastest graphics display, compared at any zorro II graphics cards. I've heard that difference is not big to zorro III cards
Napalm is playable with it much faster than any zorro II graphics, if we forget screen flickering
-
leirbag28 wrote:
Ok then, it is time to create UAE for Amiga....to emulate the 32 bit needed for the chipRAM and have the rest of the emulation for everything else run natively since it is a real Amiga.............keeping everything still running smooth :-)
You can't do that... because the emulator would be using Fast ram to store graphics and sound, which is what chip ram is for. The graphics and sound hardware only has access to chip ram, not fast ram, so you wouldn't be able to use the native hardware, you'd have to emulate that as well. VERY slow. If at all possible on standard ECS/AGA chipset. You'd have to emulate the processor as well to trap accesses to the hardware registers.
You can't emulate just one part of the system, because it's all interconnected, in hardware.
Swapping chip ram into fast ram could be done, as I said, but it would need a new OS to handle it, and an MMU (which isn't standard), and all the programs would have to be rewritten to tell the OS it doesn't need to use that bit of chip ram just now... plus copying large blocks of RAM is slow... especially chip ram... your computer would crawl if it did this on every task switch.
But then you could write programs that work like that anyway, and copy their chip ram into and out of fast ram when needed, without any changes to the OS or hardware.
What you COULD do, however, is make a new OS that can basically run four "virtual amigas" that you can switch between. They wouldn't all be able to run at once though, each one would have its own 2meg chip ram allocation, which gets swapped out when you switch manually from one to the other.
With an MMU maybe it could be made that all four run simultaneously, but you'd only be able to see or hear one at a time.
-
@Tricky
Although what with the custom chips having direct access to it (do they even go through the MMU?)
Nope, only CPU accesses use MMU. Custom chip accesses always access the physical mapping.
-
@utri007
fblit what it does? would it be possible to to assign more memory to graphics with it ?
No.
FBlit just makes all non-displayable bitmaps to reside in fast memory and replace hardware blitting with CPU operations. It doesn't give you any more chip memory, but it reduces usage of it, leaving it for other purposes, and speeding up system (fast memory is, err, faster).
So in a sense FBlit is the best you can get without replacing the whole hardware.
And really, fast gfxcard is much better option, you get truecolor modes aswell.
-
Then if it is not possible without a gfx card. it is possible with one as we already know so my solution in hardware would be create a gfx card thats accessed through RTG I suppose, but isnt a gfx card but only the ChipMem part of it and how it is accessed.
This is not possible. External hardware cannot take over the custom chips inside the amiga.
The only way would be to replace the whole amiga motherboard and chipset.
-
Piru wrote:
@Tricky
Nope, only CPU accesses use MMU. Custom chip accesses always access the physical mapping.
I thought they might. This doesn't affect the four virtual amigas scenario though, as on switching you'd turn off the display and sound, copy the entirety of Chip ram into Fast ram, copy the new Chip ram block out of Fast ram, and restore the display. The MMU can map access to the hardware registers though, I take it, so it would just point the previous virtual machine's DFF000 range into some reserved fast ram, where it will happily carry on without doing anything... as long as it doesn't try to use the blitter, of course! But then there's FBlit.
It would also rely on software being fully system friendly in order to work properly.
-
@leirbag28
Before continuing with this debate, would you be kind enough to explain what would one use the 8MB chip memory for? What benefits does 8MB chip memory offer?
-
Then if it is not possible without a gfx card....it is possible with one as we already know..............
Where do you get the strange idea that you could use even one kb more ChipRAM with an installed GFX-card.
so my solution in hardware would be.............create a gfx card thats accessed through RTG I suppose, but isnt a gfx card but only the ChipMem part of it and how it is accessed.
Ah, now I see. You confuse the GFX RAM on an graphicscard with Chip RAM. GFX RAM ist more like Fast RAM, so it is not surprising that there is as (PPC only) CGX driver for AGA.
Though Chip RAM is used to store GFX-data it is only a fraction of it's duties. This part can easyly taken off of the chip RAM, thats how RTG systems work. But it only works for software that goes through the OS.
As for AmigaUAE. Three is an UAE-port for AmigaOS but only the fastest classic PPCs are barely able to reach simpe A500 speed.
Anyway whats the point of haveing more then 8 MB of chip RAM ? You might be able to open more screens in higher Resolution in PAL/NTSC but the chipset wouldn't get any faster, so eventually you could watch at the monitor an see how the screen is updated line by line.
-
Piru wrote:
@leirbag28
Before continuing with this debate, would you be kind enough to explain what would one use the 8MB chip memory for? What benefits does 8MB chip memory offer?
Hahahaha! I was thinking exactly this, but I'm more interested in just solving the problem! I'm addicted to thinking.
It's driving me crazy!
-
Here is another option.
Why not just use the FBLit (http://www.aminet.net/search.php?query=fblit) hack and have some of the stuff normaly loaded into the chipram get moved into the fast ram. This is really the only option at this point.
I use it and I get 1.8 meg of free chipram with my OS3.5 64 colour workbench in Highrez NTSC and a nice workbench background.
-
Piru wrote:
FBlit just makes all non-displayable bitmaps to reside in fast memory and replace hardware blitting with CPU operations.
That is why fblit only speeds up a system when the CPU is beefy enough. In fact it is an example of the lacking chipset. The whole idea about amiga being offloading the CPU which made it a better computer than it's competitors in the day. FBlit does the opposite. It offloads the blitter and lets the cpu take care of things. If you cant beat em join em I'd say ;)
Piru wrote:
@leirbag28
Before continuing with this debate, would you be kind enough to explain what would one use the 8MB chip memory for? What benefits does 8MB chip memory offer?
I think only workbench related things can benefit from this. More screens open, webbrowser graphics that sort of thing. Games and such count on only having 2MB so most of the time it is useless having 8MB.
Powerhungry addicts want to drool over their workbench when it reports the ammount of RAM they don't use. More unused RAM feels better I guess.
-
"Powerhungry addicts want to drool over their workbench when it reports the ammount of RAM they don't use. More unused RAM feels better I guess."
For myself its needed because The Toaster/Flyer software needs at least 1.6mb of chipram in order to function properly. I dont like running my workbench under NTSC Highres mode because it looks aweful as everything is so large and bulky.
-
But I believe it is possible.
Then you are wrong.
Ok then, it is time to create UAE for Amiga....to emulate the 32 bit needed for the chipRAM and have the rest of the emulation for everything else run natively
The problem is this: The chipset requires that any bitmap that is displayed or blitted, and any sound samples must be in physical chip ram. The chips that create the display and output the sound have a physical limitation on the amount of memory they can actually read. They have no memory mapping unit, they just have a memory bus that is limited to 512Kb, 1Mb or 2Mb depending on which revision. This limitation is to do with physical pins on physical chips and wires between them. To increase the amount of chip memory, you'd have to make a new revision of the Amiga chipset with extra chip ram address pins, and make a new motherboard to use them.
To emulate 8Mb chip ram on the Amiga, you have to emulate the whole Amiga chipset, and the 68k just isn't fast enough to do that, especially emulating AGA on AGA would be really slow, and actually really crap since you'd be limited to 256 colours (or possibly you could use HAM-8, but you're talking minutes per frame here now, rather than frames per second). You can't emulate 8Mb chip ram and expect the real chipset to use the emulated chip ram, because they physically cannot address that much ram. To them there isn't that much ram in the whole world.
since it is a real Amiga.............keeping everything still running smooth :-)
No. Its not possible.
Then if it is not possible without a gfx card....it is possible with one as we already know
No. An A1200 with a 32Mb gfx card still only has 2Mb chip ram. The Amiga chipset can't directly access any RAM on the gfx card at all. The graphics chipset on the graphics card can't access the amigas chip ram usually either.
Well then....one will have to be created to take care of that :-)
What? A piece of code that physically adds pins to chips and tracks to motherboards?
If you had an MMU I guess you could use the Fast ram as "virtual" chip ram in the same way it would normally use HD
Ah......now we are getting somewhere :-) thanks for open mindedness :-)
Nope, you're not getting anywhere. It is simply not possible to get the chipset to see outside of chip ram, it is physically directly attached to chip ram and not through any kind of memory management unit. No amount of software can fix this.
-
i think the last time this argument ran through amiga.org i tried to get the arguer to understand that the problem really is with the hardware. the os has no problem with 8megs of chipram. the hardware is incapable of it. any software to remidy the situation would result in an enormously slow bloated mess. as in probably 10 to 12 megs of fast ram being used and data being shifted back and forth from actual chip to fast. i told them to prove it possible. no proof yet.
emulating chip ram is worse than the lack of chip ram in the first place. there are ways around 2meg of chip problems. and if you absolutly have to have 8megs, use winuae.
-
KThunder wrote:
any software to remidy the situation would result in an enormously slow bloated mess. as in probably 10 to 12 megs of fast ram being used and data being shifted back and forth from actual chip to fast.
Depends how often you have to switch between frames. It takes 31/50 of a second to copy 2megs of chip ram to fast ram, or back again (I just timed it!! although that's on my 25MHz '060 but I'd expect chip ram to be a bottleneck anyway). I guess that's acceptable if it only happens when you switch between one app and another (or one set of apps and another), if you don't have to switch all that often.
-
@Tricky: There's no point in using a MMU for the chipset (not the normal, CPU integrated one of course, but one you build for that purpose).
1) An MMU can help mapping logical memory to physical memory - provided the address space of logical memory is larger than the amount of physical memory, so when a currently not existing page is accessed, you stop access, load the contents to physical RAM and then map it to where you need it. The Amiga's chip mem address space is equal to the physical RAM (2MB), so there's no sense in that.
2) If a page miss occurs, you need to stop access (using an exception) for loading the data to RAM. So how do you do that while the frame is displayed or the sound is played?
3) Chip RAM access by the chipset is realtime, that's the whole point of creating chip RAM in the first place: define memory that can be accessed in a defined manner. The CPU is stalled when the chips need the bus. Fast RAM on the other hand can be accessed by the CPU without being slowed by chip access.
-
@Zac67
That's not what I just suggested.
I'm suggesting a scheme where you can MANUALLY switch between completely different 2Mb banks of chip RAM, that are used by entirely independed sets of programs. When you switch, all the programs in your current frame stop.
The MMU only comes in if you want the programs to still run in the background. You remap the custom chip hardware register address range (which is written to by the processor, not the hardware) to an area of fast ram, so the other programs aren't accessing the hardware anymore, even though they don't know this. You also map the chip ram into fast RAM. The hardware NEVER ACCESSES this fast RAM while the program is in the background, because the hardware registers are mapped to empty space for these processes, although the program itself can still write to what it thinks is chip ram. You only see or hear the frame you're working on at the time.
-
OK, but
- How does the OS now which part of code owns which parts of chipram? What happens if the user drags a screen?
- Chip registers ARE being written to be chips (i.e. by Copper). No big deal when it comes to color registers, but what about Copper controlled blits? Of course you could use the MMU to supervise access to the 'virtual' registers, but then again you'd have to emulate chipset behavior...
Apart from that I don't like the idea of [d]paging[/d] banking chipmem very much, sorry. I'd rather use an RTG card for graphics and a DMA capable sound card. What else would you need chipram for? The whole scheme was engineered for a highly efficient, low cost, yet high performance graphics machine. Technology has moved on since.
-
A lot of things like scandoublers/ff and '030 accelerators for the A600 feature a chip that sits on top of another chip and bypasses the original.
I wish people would stop saying "can't be done". With enough resources and ideas I'm sure something could be worked out.
Trouble is, with BVision and PIV cards the urge to develop a hardware based solution to the 2MB limit is not strong enough.
I heard once there was an '040 sidecar for the A500 and the Bodega Bay tower for A500 allowed A2000 GFX cards right?
I can see that more ChipMem would be handy for classic apps, especially killer apps you'd like to 'nourish' with all the tricks you can use!
FBlit conflicts with things though and is a severe hack, I don't think Shapeshifter likes it.
Shame the AGA plans were lost, it could have made for great fun over the last decade. Didn't Mick Tinker have the plans for BoXeR? What happened to his work...
The fake GPU idea is a good one, tricking the Amiga into using GFX card memory as ChipMem - maybe with some sort of FBlit/Hardware combo. The board could have lightning fast DDR memory.
-
@Zac67
The program will have to patch the OS memory allocation functions. Although each "page" will have its own set of programs running, you won't be able to mix programs from one page with programs from another. So if you drag the screen down, you'd get nothing! (Or another program that was running on the same page.) There would be some other method of doing it, maybe a key combination.
Chip registers won't be written to by the copper lists of programs that are in a background page, because their copper lists will not be active. Besides, programming the blitter from there is not a very OS friendly thing to do... OS friendly blits, however, could be taken over by FBlit, and the fast-ram mirror of the blitter busy bit could be held at 1 to ensure any programs that do try to access it the naughty way have to wait until you look at them again.
The MMU would just divert writes to hardware registers elsewhere so they don't actually do anything, it doesn't try to simulate their behaviour in any way. (At least not the "write" registers anyway, the readable ones could be updated periodically.) Although when a page is switched back, the values there could be loaded into the real registers.
Why do I want to do this? I don't really... just sounded like an interesting problem to solve!
-
First of all, the OS doesn't care how much chip RAM you have. Memory is just tagged as different types and it allocates whatever type you want from the memory list.
It's the hardware that cares. The custom chips only have access to one buss of the dual buss architecture... chip RAM.
Without a redesign of the custom chipset you won't be able to have more. Minimig wouldn't have such a limitation.
-
The fake GPU idea is a good one, tricking the Amiga into using GFX card memory as ChipMem - maybe with some sort of FBlit/Hardware combo. The board could have lightning fast DDR memory.
It's a very bad idea, reading graphics card memory is even slower than chip memory.
Ok I don't mind people having their dreams, but when the ideas conflict with reality I feel obliged to comment.
-
by Piru:
It's a very bad idea, reading graphics card memory is even slower than chip memory.
Ok I don't mind people having their dreams, but when the ideas conflict with reality I feel obliged to comment.
Ok, it's been said that the A4000's ChipMem resides on a removeable 72-pin SIMM right?
So what if a larger SIMM was used, possibly of a higher nanosecond rating then a piggy-back chip placed over Agnus?
:idea:
If you can add a 10 MIPS 32-Bit '030 to a 16-Bit 68000 A600 then I'm sure that at the very least the old 2MB/8MB jumper on the A4000 could be hacked.
Surely GFX card memory is only slower than the crap 80ns ChipMem memory because it has to go through the Zorro bus, what if it could bypass this with a piggyback board?
:inquisitive:
I think the Power Flyer and internal scandoublers work in a similar way. There are ROM switchers so why can't a MiniMig style Agnus switcher be thought through?
Just for laughs of course, to prove we can!
(http://www.amiga.org/uploads/cavt402e47c9927d1.jpg)
:laughing:
-
Ok, it's been said that the A4000's ChipMem resides on a removeable 72-pin SIMM right?
So what if a larger SIMM was used, possibly of a higher nanosecond rating then a piggy-back chip placed over Agnus?
The system would still only see 2MB of chip memory. The memory speed would not be faster.
For any benefits all custom chips would need to be adjusted, not just agnus. Also, it is likely that various address lines are not even physically connected, considering the maximum memory is 2MB. Basically you'd end up replacing the whole motherboard and chipset anyway.
Surely GFX card memory is only slower than the crap 80ns ChipMem memory because it has to go through the Zorro bus
Actually this is generic. Graphics card memory access speed is highly asymmetric (writing is fast, reading is very slow). This is the same for modern gfxcards aswell.
-
Piru wrote:
@leirbag28
Before continuing with this debate, would you be kind enough to explain what would one use the 8MB chip memory for? What benefits does 8MB chip memory offer?
----------------------------------------------------------------------
Capital punishment
Super StreetFighter 2 Turbo
Hired Guns
NAPALM
T-ZERO
SCALA MM300
ELan Performer
ViewTeck
Workbench and All Multitaking applications
Digital Sound Studio (Tracker requires all samples in Chipmem)
Video Toaster (can sure use more chipMEM)
And so many Applications...........I love running 10 apps at once if possible....and still be able to execute SLAMTILT or Capital punishment without having to reboot.
WinUAE is a perfect example. I can open so many Apps on it.......one can prove how excellent Amigas are at multitasking if we had more ChipRAM.
Someone here said even with a Gfx card the limit is only 2mb Chip.................hmmmm Im pretty sure I have read you can have 4mb with a CyberVision64 or Picasso and having a Gfx card benefits the Video Toaster as it uses the extra chipMEM from the Card to run.
And Yes! where there is a will, there is a Way.....PiggyBacking Chips on one another just might work!
I have heard "It cant be done" in the Amiga community so many times...and they were all wrong.
One has to think of things that have not yet been created.
For example Compact Flash cards and Memory Sticks and SD cards and such were said to be not possible to use on the Amiga. but we can use them now....all that was required was drivers. Same with USB.......now we have USB.............USB couldnt be done on the A600.....I have a Clockport in my A600 now ready for USB
ECS Amigas were said to display a Max of 16 colors in hires Interlaced........yet Broadcast Titler 2.0 displays 320 at once using a trick..........different screens on one screen. Awesome! this same concept has been applied to games and can be applied even more if we had more ChipMEM
I have ran out of ChipMEM trying to display a large JPEG.
Never forget! Amiga Makes It Possible!
and Why? cuz we have a strong community that loves this machine.
-
hmmmm Im pretty sure I have read you can have 4mb with a CyberVision64 or Picasso
Nope, this is absolutely not the case. 2MB is the limit. Seriously.
PiggyBacking Chips on one another just might work
Not a bad idea, but still the answer is no. The trouble is that Agnus/Alice has many different DMA channels and stores different addresses for each one. When Agnus/Alice accesses chipmem, there is no way for any other piece of hardware to know which DMA channel is being served, so there is no way for any other piece of hardware to provide relevant additional address bits.
-
Not a bad idea, but still the answer is no. The trouble is that Agnus/Alice has many different DMA channels and stores different addresses for each one. When Agnus/Alice accesses chipmem, there is no way for any other piece of hardware to know which DMA channel is being served, so there is no way for any other piece of hardware to provide relevant additional address bits.
-------------------------------------------------------------------------
@DamageX
That kind of makes sence and I probably can see that being the case. But maybe there is a way through software telling the Systems and OS that the rest of the ChipRAM is somewhere else and is Virtual Memory..........redirection.....................invisible to all Applications and games.
-
@leirbag28
Someone here said even with a Gfx card the limit is only 2mb Chip. hmmmm Im pretty sure I have read you can have 4mb with a CyberVision64 or Picasso and having a Gfx card benefits the Video Toaster as it uses the extra chipMEM from the Card to run.
No.
For example Compact Flash cards and Memory Sticks and SD cards and such were said to be not possible
Can't remember anyone saying these would be impossible. It was just lack of drivers, obviously possible.
Same with USB
Was always possible if someone just created the HW. Someone did. The only way to get more than 2MB chip memory is by full hw emulation or total recreation of all hardware (minimig could have more than 2MB, but it won't. It will be A500 compatibility device).
ECS Amigas were said to display a Max of 16 colors in hires Interlaced, yet Broadcast Titler 2.0 displays 320 at once using a trick
Obviously possible since you can change palette registers with copper. This never was impossible.
But:
this same concept has been applied to games and can be applied even more if we had more ChipMEM
No, it can't.
I have ran out of ChipMEM trying to display a large JPEG.
Use a program that reduces the picture size to fit the screen.
But maybe there is a way through software telling the Systems and OS that the rest of the ChipRAM is somewhere else and is Virtual Memory redirection invisible to all Applications and games.
No, there is not.
Really there isn't.
-
Sigh...
Look, any chipmem access by the chipset works like this:
- Agnus generates the address to the chip bus (for the 'DMA')
- the data gets transferred to the chip that needs it
All address registers for the custom chips reside within Agnus (hence its name from Address Generator). The registers are 21 bits wide and the address bus is 21 bits wide (not precisely since we address words/longwords, but that doesn't make a difference).
There's absolutely no way to make Agnus see more than 2 Megs - apart from redesigning it of course. A redesign would need
- additional address lines to CPU bus switch
- additional address or select lines for RAM control
- enlarged address registers
- additional or larger RAM chips
The whole idea about virtualising chipmem and swapping it when needed won't work, it leads to the exact same problems there are with resource tracking within AmigaOS - there's simply no way.
And: Before you engineer a special MMU for the chipset, it'd be much simpler and more efficient to redesign Agnus (wouldn't need a major OS rewrite). So, go ahead and ask Dennis to share his Minimig work with you to build a (nearly) drop in replacement for Agnus.
-
leirbag28 wrote:
Someone here said even with a Gfx card the limit is only 2mb Chip.................hmmmm Im pretty sure I have read you can have 4mb with a CyberVision64 or Picasso and having a Gfx card benefits the Video Toaster as it uses the extra chipMEM from the Card to run.
Gfx card memory is not chip memory, it can't be accessed by the custom chips.
-
Zac67 wrote:
Sigh...
Look, any chipmem access by the chipset works like this:
- Agnus generates the address to the chip bus (for the 'DMA')
- the data gets transferred to the chip that needs it
All address registers for the custom chips reside within Agnus (hence its name from Address Generator). The registers are 21 bits wide and the address bus is 21 bits wide (not precisely since we address words/longwords, but that doesn't make a difference).
There's absolutely no way to make Agnus see more than 2 Megs - apart from redesigning it of course. A redesign would need
- additional address lines to CPU bus switch
- additional address or select lines for RAM control
- enlarged address registers
- additional or larger RAM chips
something tells me that you can't get away with only redesigning agnus. The custom chips themselves, when requesting data use 21 bit addresses ? so they should be upgraded as well for the extra address line ?
-
@Zac67
It is possible to track memory resources on the Amiga. You could patch the memory management functions in exec.library. Normally AmigaDOS doesn't keep track of any memory reserved, it only keeps track of what's left. But you could insert a patch that before reserving the memory, gets the current process handle, and stores that somewhere in a table along with the address and amount of memory reserved.
I was considering writing such a patch, not to expand chip RAM, but just so that you can free up any memory reserved by programs that they forgot to free up when they exited.
However, if you can do this, then when the chip memory gets full, we can look at this table and see what programs we can "swap out". You'd have to put the entire process to sleep (including taking its screen out of the screen list), as it would have no way to access any chip memory it reserved while it was swapped out. So you wouldn't have full multitasking anymore, but you could get back to the old program when the new one frees up its chip memory.
Realtime switching with full multitasking obviously isn't an option as a program's chip memory can still be accessed by the hardware even when it isn't the current process, and furthermore, it takes far too long to copy memory around like that (it would have to be physically copied into and out if chip/fast ram on every process switch).
But maybe there is a compromise option, that allows you to effectively use more than 2Mb of chip ram, but only a maximum of 2Mb at any one time. We could do it manually with some sort of "task manager" like Windows has. You see a window with a list of all the current programs and how much chip ram they are using, and can put individual processes to sleep in fast ram when you want to, and bring them back later.
-
To summarise for those who can't take the hint :-)
1. The custom chips are physically only able to see a maximum of 2MB of chip RAM.
2. The only way to change 1. is to replace the custom chips and make extensive changes to the motherboard. Since nobody has the plans for the custom chips, I don't think replacements will ever be available.
3. Since the allocation of memory isn't handled by an MMU, you cannot swap memory out.
4. Even if it was possible to use software to swap memory out, this would require the OS to be running. As soon as you run software which turns off the OS (read: a game), you lose your swapping ability, and you're back to 2MB of chip RAM.
5. This idea of emulating the chip RAM is silly. How would your software know it is supposed to use the emulator when it wants to use some chip RAM? It wouldn't, so it would just address the chip directly and totally ignore your emulator.
I understand this dream, as it would be great to lose the distinction between chip and fast mem, and pool all available RAM for use by any software or hardware. But sadly, it's just not possible. If you really, absolutely must have more than 2MB of chip RAM, use UAE.
--
moto
-
There are only exactly 2 ways of getting more than 2MB chip:
a) emulate it, problem is, even a A4000-CSPPC+Voodoo3 running MorphOS or an OS4-beta will hardly reach A500-speeds(as you would need to run a full version of UAE).
b) create your own uber-Agnus/Alice out of a programable chip, remove the onboard Agnus/Alice, place a piggyback-PCB with the new chip and 6 extra MB into the free space. This might work, this might also end in the need of recreating Denise,Gary and Paula too.
None of them makes really sense.
But since I'm in the mood:
c) use a PC + UAE and somehow hack a PCI_2_Zorro-adaptor and a VGA_2_VideoSlot-adaptor. Now that sounds like a fun project, and should even be able to the toaster. But then just buying a the PC-Toaster might be easier.
-
@moto
3. it is possible, but only by physically copying it from one to the other, which can take some time. (about 31/50 of a second for the full 2Mb on my machine.)
-
@Tricky
How would existing software know how to swap memory out of chip RAM to free up space?
--
moto
-
motorollin wrote:
@Tricky
How would existing software know how to swap memory out of chip RAM to free up space?
--
moto
Well it wouldn't. I'm beginning to wonder if anyone's actually reading my posts.
There would be some sort of "Task manager" that lets you manually swap out an entire program to sleep in fast ram until you manually bring it back. You could also use this to close a program that had crashed but left its window open.
I'd like to write a whole load of error trapping for AmigaDOS - many more things are possible once you can keep track of which process reserved which bits of memory.
-
Not a bad idea, but still the answer is no. The trouble is that Agnus/Alice has many different DMA channels and stores different addresses for each one. When Agnus/Alice accesses chipmem, there is no way for any other piece of hardware to know which DMA channel is being served, so there is no way for any other piece of hardware to provide relevant additional address bits.
Actually, that's not entirely true. As long as the OS set up the DMA it would be possible to block all bank switches until all DMA transfers finish. For a lot of things it's possible.
The problem is, the OS isn't always aware of how the hardware is setup. When you setup the copper, it just keeps trying to do it's thing without the OS. Imagine what happens if the copper is stepping through a copper list and suddenly it's replaced with some other data because you swapped RAM banks.
In *theory* you could stop the copper, save the state it's in, switch banks, setup the alternate copper list, etc...
In reality, you don't set up the hardware strictly through the OS and some hardware registers are read only. It makes it impossible to save/restore the state of the hardware for a CHIP RAM bank swith.
Even if it were possible the computer would waste a lot of clock cycles on the context switch and everything else comes to a hault just so someone can say "look what I can do". Even if it were possible, it's not practical since it would require an OS rewrite.
The whole CHIP/FAST mem thing was really sort of a hack to get around the slow buss speed of the day. Now you could design a new chipset that uses 1 buss and all RAM could be CHIP or FAST. Minimig or something like it is the only way you will ever see this happen.
-
I really didn't want to do this, but I just checked the A4k schematics to make sure I'm not telling crap.
- Alice is actually connected to all 32 address bits - this surprises me
- Alice has 10 DRAM address bits, 11 with the '8 MB' jumper set - that's enough for 8 MB (no surprise here)
- Paula just has a register address bus of 8 bits, no data address lines
- Lisa likewise
Like in OCS/ECS there's no bus arbitration for the chips. Alice knows who wants what and uses the static (prioritized) 'DMA channel' scheme to ensure timely data delivery. It generates the addresses and Lisa/Paula read the data.
It was possible to expand a 1st generation A500 to 2 MB chipmem by exchanging Agnus, and the A4k schematics talk about a '8 MB Alice'. I see no reason why you'd need anything more than a new (non-existant) Alice and RAM.
-
@Tricky
So you're saying if you are running low on chip mem and want to run an application which requires more chip mem than you have free, you could MANUALLY put an application which is using chip mem to sleep, which would suspend its execution and move all of its memory from chip mem to fast mem?
That might work, but the problems will start when you want to wake the application up again and something has filled the chip mem with data. Even if there were enough bytes free to move the sleeping application back in to chip mem, because there is no memory management, how could you guarantee that the re-awoken app would be able to find all of its data in RAM again, once it had been moved back to a different location in chip RAM?
--
moto
-
jdiffend wrote:
Even if it were possible the computer would waste a lot of clock cycles on the context switch and everything else comes to a hault just so someone can say "look what I can do". Even if it were possible, it's not practical since it would require an OS rewrite.
It would require patching of a few Os functions. I know exactly which ones, and how to do it. I might even actually do it one day, but I'm kind of busy at the moment. Shouldn't take long once I get my head to it though.
It would take time to switch contexts, obviously, but not unbearably so, in my opinion, as long as you didn't have to do it often. It would be useful, too - instead of closing one program to open another, you'd be able to get back to your original work without having to save and reload it each time. That's got to be worth the occasional 1/2 second wait (takes longer than that to load a program and your work into it anyway).
-
motorollin wrote:
Even if there were enough bytes free to move the sleeping application back in to chip mem, because there is no memory management, how could you guarantee that the re-awoken app would be able to find all of its data in RAM again, once it had been moved back to a different location in chip RAM?
--
moto
Hmm, that's a good point. You'd have to put it back exactly where you got it from. Which might mean putting any other program to sleep that happened to occupy that area. Either that, or it's back to my original idea of switching between complete 2Mb banks of chip ram. But it may be possible to write an "intelligent" memory allocation algorithm that tries to make sure that it is possible to switch as many sleeping programs back as possible.
But obviously if you had to put A to sleep to run B, it stands to reason that you have to put B to sleep to run A again.
-
@Tricky
It is possible to track memory resources on the Amiga. You could patch the memory management functions in exec.library. Normally AmigaDOS doesn't keep track of any memory reserved, it only keeps track of what's left. But you could insert a patch that before reserving the memory, gets the current process handle, and stores that somewhere in a table along with the address and amount of memory reserved.
I was considering writing such a patch, not to expand chip RAM, but just so that you can free up any memory reserved by programs that they forgot to free up when they exited.
Actually there are several problems here. Processes pass memory between each other, and there even is concept of orphan memory in AmigaOS. Also, various memory is accessed by multiple processes at the same time. Thus, this doesn't work.
However, if you can do this, then when the chip memory gets full, we can look at this table and see what programs we can "swap out". You'd have to put the entire process to sleep (including taking its screen out of the
screen list), as it would have no way to access any chip memory it reserved while it was swapped out. So you wouldn't have full multitasking anymore, but you could get back to the old program when the new one frees up its chip memory.
Won't work, there's more to this than just memory allocation. How can you know if blitter isn't currently working on the memory? How can you tell that audio hardware isn't playing sample from the memory? How can you tell that custom display (poking hardware directly) isn't using the memory for planes and copper list? How can you tell that floppy DMA isn't currently reading to or writing from the memory?
The only way to have this working would be to have full virtualization of the system. Then you'd need to emulate much of the hardware anyway (at least copper), so in the end it would be much easier with full emulation.
-
Piru wrote:
Actually there are several problems here. Processes pass memory between each other, and there even is concept of orphan memory in AmigaOS. Also, various memory is accessed by multiple processes at the same time. Thus, this doesn't work.
When do these things happen? Do they go through the OS to do it? If so, could patch those functions too. Of course only shared Chip RAM is a problem - fast ram would be unaffected. Don't know why programs would communicate via chip ram, unless they're sharing graphics or sound.
"How can you know if blitter isn't currently working on the memory?"
Call Ownblit() and Waitblit().
"How can you tell that audio hardware isn't playing sample from the memory?"
You're supposed to tell the OS you want to use it, but I guess not everyone bothers (I don't). In any event, it's only of aesthetic, rather than functional, consequence. (Might make unexpected noises but it isn't going to crash).
"How can you tell that custom display (poking hardware directly) isn't using the memory for planes and copper list? "
That's a bit naughty isn't it? "Proper" applications wouldn't do this. Games do, but you'd have to be on the workbench screen anyway to run the task manager, and the workbench manages its own copper lists. Must remember not to put the workbench to sleep...
"How can you tell that floppy DMA isn't currently reading to or writing from the memory?"
I'll have to look into that.
-
@Tricky
When do these things happen?
Example of OS use: Various structures are allocated and passed to library/device. Other processes use the structures when they call the library functions. This is common practice in most libraries/devices. Chip memory is less likely to be used like this, but it can happen if some chip memory buffers are needed.
Do they go through the OS to do it?
Some do, some don't. There is no way to patch these since you have no way of knowing where and when these things are used.
The point of this thing is to allow one to run games after running lot of applications. So it would need to work with those nasty apps I'm afraid.
OwnBlit()
This onle works for OS friendly apps. You can't OwnBlit() if you have disabled or are in the middle of interrupt (OwnBlit() uses a semaphore locking).
it's only of aesthetic, rather than functional, consequence. (Might make unexpected noises but it isn't going to crash).
Actually it migth crash or at least stop the application from continuing if it uses audio interrupts (when swapping it back).
That's a bit naughty isn't it? "Proper" applications wouldn't do this.
Nothing naughty about it. It's common practice to take over the system in OS fiendly way and then display your own hardware screen. Example: hwstartup.asm (http://www.iki.fi/sintonen/src/hwstartup/hwstartup.asm)
-
Piru wrote:
The point of this thing is to allow one to run games after running lot of applications. So it would need to work with those nasty apps I'm afraid.
That's not how I interpreted the point of this thing, but nonetheless, I don't see how a game would cause any trouble that way, as usually the only way (if any) to get back to the system is to quit out, so you'd never get the chance to swap it out of the system anyway.
This onle works for OS friendly apps. You can't OwnBlit() if you have disabled or are in the middle of interrupt (OwnBlit() uses a semaphore locking).
The task manager won't be on interrupts. It will be started probably from an AppIcon on the workbench. It will also call Forbid() when it starts, so even if another program has started the blitter, it won't be able to start it again because it won't be running anymore. Waitblit() will then suffice to ensure the blitter is no longer in use.
Actually it migth crash or at least stop the application from continuing if it uses audio interrupts (when swapping it back).
I might have to put a lot of disclaimers on this...
Also, as for interrupts, if an interrupt happens to be in Chip ram, I'll need to make sure its vector is removed from the Interrupt Server when swapping that chip ram out. Although there's not usually much need to put an interrupt in chip ram, but of course the interrupt may access chip ram, and how to know this? Interrupts may defeat me...
Nothing naughty about it. It's common practice to take over the system in OS fiendly way and then display your own hardware screen.
I know it's common, but the official commodore line was always that you weren't supposed to use the hardware directly.
Even still, as I already said, you'd need to be on the workbench screen to swap the app out anyway so this won't apply.
-
motorollin wrote:
1. The custom chips are physically only able to see a maximum of 2MB of chip RAM.
----------------------------------------------------------
I don't believe that...........if this were True, how is it that an A500 wich was created before 2mb CHipRAM existed is able to see the 2mb ChipRAM from a MegaCHIP add-on without changing any of the customs chips?
Also how is Workbench 1.3 able to see it?
Neither Workbench 1.3 nor the custom chips needed to be told there was extra ChipRAM...........it just detected it.
-
Read my post - max amount of chipmem depends on Agnus/Alice and nothing else.
AmigaOS doesn't really care how much chipmem there is and where - it detects the first 2 MB as chipmem and additional RAM can very easily be flagged MEMF_CHIP.
-
I don't believe that...........if this were True, how is it that an A500 wich was created before 2mb CHipRAM existed is able to see the 2mb ChipRAM from a MegaCHIP add-on without changing any of the customs chips?
Those expansions did change custom chips - they swapped the old 512K or 1MB Agnus with the then-new 2MB version that had been built for A3000s, A600s, and A500+s.
In the case of the 4000, at the *very least* the 2MB Alice would have to be replaced with an 8MB Alice (which does not exist).
-
@Tricky
It will also call Forbid() when it starts, so even if another program has started the blitter, it won't be able to start it again because it won't be running anymore. Waitblit() will then suffice to ensure the blitter is no longer in use.
Not quite. For example the blitter queue of the OS itself is run from interrupts. Forbid() + WaitBlit() doesn't guarantee that further blits won't happen.
Also, as for interrupts, if an interrupt happens to be in Chip ram, I'll need to make sure its vector is removed from the Interrupt Server when swapping that chip ram out. Although there's not usually much need to put an interrupt in chip ram, but of course the interrupt may access chip ram, and how to know this? Interrupts may defeat me...
You misunderstood. Audio interrupt occurs when the sample playing has finished, where the interrupt code is located is irrelevant.
I know it's common, but the official commodore line was always that you weren't supposed to use the hardware directly.
It was? Where did they say that? If so, why did they publish hardware reference manual with examples on how to use the hardware directly?
Even still, as I already said, you'd need to be on the workbench screen to swap the app out anyway so this won't apply.
I wouldn't consider this very usable solution then.
-
when will the madness stop??? :crazy:
-
@leirbag28
I don't believe that.
Believe it.
if this were True, how is it that an A500 wich was created before 2mb CHipRAM existed is able to see the 2mb ChipRAM from a MegaCHIP add-on without changing any of the customs chips?
Oh really? Well what is this Agnus 8375 chip (http://www.amiga-hardware.com/download_photos/megachip_1_big.jpg) doing on the board then?
Also how is Workbench 1.3 able to see it?
Workbench calls AvailMem(MEMF_CHIP). Kickstart 1.3 has always supported upto 2MB chip memory.
Neither Workbench 1.3 nor the custom chips needed to be told there was extra ChipRAM. it just detected it.
Wrong. Workbench just reports what exec library tells it via AvailMem. Depending on the revision of the agnus it can only see 512KB, 1MB or 2MB chip memory. However, it can not see more than 2MB. Even if you plugged in a new agnus that would do more than 2MB it would still not work.
Further even if you did, kickstart ROM would not see the chip memory above 2MB (it only scans upto 2MB).
Even if you fixed this, the 8MB chipmem would break all Zorro II autoconfig devices having memory.
-
Hi Everyone,
I suppose this is off topic but I had a retarded thought.
How about getting some sli like action going? Make a custom circuit to plug into the Denise socket that reads the incoming signals then splits the display jobs in two, sending maybe the 0-5 bitplane graphics to a Denise and the 6-11 bitplanes into another Denise. Then wire the resulting graphics to the video hybrid (Resistor network) through the socket. This probably wouldn't allow more chipram but the display refresh could be faster and maybe compatible with everything.
Regards
John
-
Yeah, Dave tried that in the early 90s: AAA (http://www.amigahistory.co.uk/amigaaaa.html)
-
by Piru:
Use a program that reduces the picture size to fit the screen.
leirbag28: Get Visage and unbracket the tooltype [SCALE] in the Visage.info - this will give you the function to speedily scale and display 24-bit images to your current screen resolution (or a screenmode of your choice).
I like the way when programs iconify they free masses of ChipMem, some programs like DeluxePaint even offer to 'CloseWB'. I suppose this is a form of iconifying the OS, shame it didn't have this feature in the 'Window' menu of Workbench.
by motorollin:
1. The custom chips are physically only able to see a maximum of 2MB of chip RAM.
Well according to the Commodore manual, the A1200 is "only able to see a maximum of" 8MB of FastMem but an '030 in the trapdoor slot allows for greater address range.
A redesigned chipset piggybacked onto the motherboard could be put onto a single chip cheaply and be of enormous benefit and curiosity.
by motorollin:
4. Even if it was possible to use software to swap memory out, this would require the OS to be running. As soon as you run software which turns off the OS (read: a game), you lose your swapping ability, and you're back to 2MB of chip RAM.
It's not normally possible to boot a CD-ROM on Amiga before CD0: has been mounted and a CD filesystem loaded - Phase5 PPC cards had a ROM allowing you to view CC0: in the early boot menu. Any software intervention to get a replacement Agnus working with 8MB ChipMem could utilise a variety of early-boot techniques. There's another thread discussing the possibility of using a GFX card in the PCMCIA slot from a HP handheld PC.
Talking of UAE is just lazy, this discussion is about Amiga hardware not IBM x86 clones - a bit of fun and wonder, pushing boundaries and considering new possibilities is what leirbag28 is trying to encourage...
... and if the outcome has made someone consider the future of the MiniMig then that's a good thing. A totally redesigned A1200/3k/4k on a small chip/PCB would be so cool! Let's see how this OCS thing works out... then ECS/AGA is a possibility!
Decades after the C64 ceased production we have people doing far out things with it... people will be hacking the Amiga by the time men have landed on Mars probably!
:-D
EDIT:
So what are the chances of a replacement Lisa/Agnus to allow for 8MB? If the A500 MegaChip used an A2000 Agnus then couldn't a redesigned A4000 Agnus on a PIC chip or something be achieved?
Imagine an A1200 accelerator like the PowerVixxen or Dragon being touted with 8MB ChipMem/1GB FastMem/512MB GPU Mem/Faster CPU and a nice sized NAND chip with 2GB of solid state access.
:lol:
-
Imagine having 256 Megs of DDR2 Chipmem.
Imagine running a 68080 @ 2000 MHz.
Imagine an Amiga Two - 64 bit architecture, of course.
Imagine AmigaOS 5.0.
Dream on. :roll: Some things just don't happen out of thin air.
-
At the end of the day, an 8Mb Alice would only be able to see 8Mb in an A4000, since its the only Amiga motherboard in existance with enough address pins wired to the Alice chip.
Leirbag, just face it. The only things that would get you 8Mb of chip ram in any way compatible to existing amiga os & apps are:
1) Run UAE
2) Make an 8Mb Alice (and possibly revised other chips), and put them in an A4000
3) Emulate the whole chipset on the 68k (which is basically 1)
And thats it. All of the "so-called" impossible things you mentioned (memory cards, USB etc.) were feasible if someone came up with the hardware and drivers to do it. 8Mb chip ram is something different.
With appropriate glue hardware you can interface pretty much any peripheral to an Amiga (or C64, or anything with some IO ports). You could add a firewire port to a ZX81, but it wouldn't actually be useful ;-) ). But 8Mb chip ram just isn't possible in the way you want it to be done. It just isn't.
In fact, i'll say this. If you don't want to run AmigaOS, or any Amiga apps on it, you can add terabytes of chip ram to an Amiga. Its easy, you just put a PCB on the motherboard over the chip ram chips that has address decode logic that includes banking. Lets say, for example, writing a number between 0 and 4294967295 to address $C banks in a different 1Mb bank into the upper 1Mb of chip ram address space, and you actually had that much RAM on the board. Thats more than 4000 terabytes of chip ram.
Great. Except that AmigaOS and its apps simply would not be able to use it. You'd have to patch amiga os, and pretty much rewrite all of your software. It just wouldn't work. So get over it.
Edit: And before you say "Great! We've just got to fix the problem with software compatibility and its solved!", don't. Fixing it is more work than it gains you.
You'd have to change exec to remember the upper memory bank number for every task. That parts easy and has almost no speed penalty.
The problem is that AmigaOS and its apps expect to be able to pass memory pointers to each other. Now, you could pass 64bit pointers instead of 32 (32bit address, 32bit chip bank), but now you have to patch _every_ single Amiga application individually that you want to run, because every single amiga app and API uses 32 bit addresses, and you wouldn't be able to run a single existing binary natively without modification.
-
@Piru
Re: 8 Mb CHIP RAM on All Amigas
@leirbag28
Quote:
I don't believe that.
Believe it.
Quote:
if this were True, how is it that an A500 wich was created before 2mb CHipRAM existed is able to see the 2mb ChipRAM from a MegaCHIP add-on without changing any of the customs chips?
Oh really? Well what is this Agnus 8375 chip doing on the board then?
------------------------------------------------------------------
Replacing the Agnus is obvious....Im only replying to those that suggested it needed Denice and other chips replaced with the MegaCHIP doesnt have and still works! correct?
Quote:
Also how is Workbench 1.3 able to see it?
Workbench calls AvailMem(MEMF_CHIP). Kickstart 1.3 has always supported upto 2MB chip memory.
--------------------------------------------------------------------
So your saying Commodore knew they would eventually invent the ECS that would have 2mb ChipRAM so allowed wb 1.3 and up to support it? sounds unlikely to me.
Nevertheless.....I believe its Possible....if a new Agnus needs to be made and it works.............then its possible.
-
Workbench believes whatever exec tells it. If AvailMem( MEMF_CHIP ) returned 128Mb, workbench would say you had that much chip memory. I could write a patch right now that did that. You'd still not have more than 2mb chip ram, though.
-
@leirbag28
Replacing the Agnus is obvious....Im only replying to those that suggested it needed Denice and other chips replaced with the MegaCHIP doesnt have and still works! correct?
...to get more than 2MB.
Naturally upto 2MB doesn't need total chipset replacement, because the whole system was designed to have maximum of 2MB.
So your saying Commodore knew they would eventually invent the ECS that would have 2mb ChipRAM so allowed wb 1.3 and up to support it?
Yes.
sounds unlikely to me.
Since you're not believing anything I say anyway: Take kickstart 1.3 image and disassemble it from offset $208. You find this:
lbC000208 lea (0).w,a0
lea ($00200000),a1
lea (lbC00021A,pc),a5
bra.w lbC000592
A0 contains the start address for memory scan, A1 the end address. $200000 is 2097152 in decimal, or 2MB.
-
Someone mentioned the "more chip memory" with the MiniMig - how's that possible?
-
@B00tDisk
"more chip memory" with the MiniMig - how's that possible?
It emulates all the custom chips in software, so it could easily be adjusted to support more chip memory, just like UAE.
-
@Piru
What's the problem with Denise/Lisa? Don't they just take what they're given by Agnus/Alice?
-
I'm starting to think this thread is a wind-up :lol:
@leirbag
Please, please prove us all wrong by re-designing the custom chips, rewriting kickstart and extensively modifying an A4000 motherboard. When I see the board, and watch the machine boot with no startup sequence and report 8MB of chip RAM, then I will believe it is possible :roll:
--
moto
-
With regard to 2 MB chip ram I run out of chip memory when trying you open large graphic files or pictures even when opening files on a graphics card. Any way around this?
-
The files you are opening, are the opening on to an RTG screenmode, or a native Amiga screenmode?
If they are opening on an Amiga screenmode then the app may use chip RAM. Try FBlit, it may be able to move the graphic in to fast RAM. Alternatively, open the graphic on an RTG screenmode and it should use fast RAM.
--
moto
-
A500 WAS able to handle 2MB chip. You needed....
1) 2MB Agnus
2) Perform motherboard trace modifications
One day I'll get out the instructions for my 4MB trapdoor expansion.
-
@leirbag
Please, please prove us all wrong by re-designing the custom chips, rewriting kickstart and extensively modifying an A4000 motherboard. When I see the board, and watch the machine boot with no startup sequence and report 8MB of chip RAM, then I will believe it is possible :roll:
moto
I cannot see that is ISNT possible, talking about Minimig, if someone was to give Dennis the specifications so he can apply them to the Agnus section of the Minimig core.
Problem being, is then you need 8MB of ram on the minimig board for Chipmem, PLUS fastram.. and I believe that Dennis (last I heard) is running low on transistors on the core for the package he is using to store the chipset on.
-
whiteb wrote:
if someone was to give Dennis the specifications so he can apply them to the Agnus section of the Minimig core.
They don't exist...
--
moto
-
whiteb wrote:
I cannot see that is ISNT possible, talking about Minimig, if someone was to give Dennis the specifications so he can apply them to the Agnus section of the Minimig core.
IMHO,the big problem will be compatibility with existing hardware.
The way UAE adds 8Mb of chip mem is to simply add another 6Mb at $200000(plus associated address decoding).
But this memory range is already reserved for other things like the PCMCIA slot on the A1200/600 and ZorroII memory boards, and there's really no other place it can be added inside the 24bit address range.
And you're stuck with a max of 2Mb fast mem if you're using a 68000 or 68ec020..plus you'd have to hack expansion.library to stop it configuring any boards into the 'new' chip mem area.
-
Any suggestions of using MiniMig to create a replacement chipset for an existing Amiga motherboard won't come to anything, either. The schematics are not available for the chipset, and the MiniMig doesn't aim to emulate the chipset at a hardware level. It really only emulates the chipset at a register level so AmigaOS can run on it.
-
Hey all-
I think most of you are on-target here for the question, but I'll summerize.
The basic issue around existing chips is ONLY Agnus/Alice. There are internal and external limits to memory addressing on any device.
For the external world, on the chip bus, there are actually two: the limits on the system address bus to Agnus/Alice (how much of the CPU bus can the chips see) and the limits to addressing of the memory chips themselves on the multiplexed DRAM bus. Internally, there's the secondard issue of how much memory Agnus/Alice can directly access in DMA.
The reason upgrades were possible at some point in time was simply that these two didn't match. It was fairly easy, for instance, when going from thin Agnus to Fat Agnus, to allow a larger CPU and memory address bus.. that was all new logic, and kind of on the periphery of the chips (in the thin Agnus circuitry, much of this stuff was done in the system, not the chip anyway).
So an Agnus chip might allow CPU access to 1MB of memory, but only 512K of that could actually be chip memory, since the internal addressing counters in Agnus only supported 512K of address space. Once you had a similar design with more bits for actually memory addressing directly by Agnus/Alice, all of that addressed memory could be chip RAM. If you added more address bits still, that wouldn't help, since then the external interfaces would be limited in address space (much like the 68000 was logically 32-bit inside, but only brought out 24-bits worth of address space).
It's only Agnus/Alice in question, due to the way the chip work together. Agnus is generating all of the chip RAM addresses, regardless of what's happening on the chip bus. Sometimes, it's a memory cycle from the main CPU, sometimes it's a display fetch or audio cycle, sometimes a blit cycle, etc. In conjunction with the memory address bus there's the register access bus (RGA bus), which is seen by Paula and Denise/Lisa.
The specific register access code tells the whole chip bus what kind of access this is. Sometimes, it's Agnus or the CPU writing to a register physically located in another chip, which means there's no DRAM cycle at all. On a video fetch, for example, the memory access will be put out from Agnus's video counters, and the RGA code tells Denise to read the DRAM bus and shift that value into one of the bitplane shift registers. Same idea with Paula accesses... all of the memory access/counting stuff takes place in Agnus or Alice. So that's the one chip that would need to change if you wanted more chip memory.
Even AAA worked much the same, with the Andrea chip doing the Alice/Agnus piece. There was some additional complexity, like dealing with the line buffer chips (Linda), the ability to handle VRAM or dual Linde/Monica pairs to support a 64-bit graphics bus (the graphics data bus wasn't always the same as the main chip databus), but the basic idea was similar.
In an emulator, of course, you can try to perfectly emulate an existing Amiga chip, but there's no reason you can also emulate chips that never existed. If it's a simple thing, like more Chip RAM, the OS already supports it, maybe with a little help (eg, it may not detect 8MB automatically, but it knows what to do with it when it's there).
The 8MB/2MB jumper in the A4000 was put in there based on the identical jumper in the A3000+. When we were working out the last details of the AA chipset (we == me, Bob Raible, Victor Andrade, and George Robbins), Bob was building Lisa in CMOS, Victor was doing Alice in NMOS. The NMOS design limited the changes that could be made ... Agnus was already close to the limits of that technology. We hoped to be able to do a followup AA+ with a CMOS Alice, and if so, that was going to handle at least 8MB of Chip RAM. So we stuck the means for that into the early design, and we (meaning mostly Greg Berlin and Scott Schaeffer, with a little of my help) carried it forward into the A4000. But there was never a chip built that could use it.
If someone built an add-on that could perfectly replicate the function of the custom chips, there no reason they couldn't support 8MB of Chip RAM, of course. However, this is inherently a hack, because the only place you can all the signals needed to replace the three chips is at the chip bus itself. You'd have to physically replace the custom chips, you couldn't do this on a Zorro card, at least not without big software changes (interrupts you can't generate on the expansion bus, things like that).
-Dave
-
@ hazydave
Thanks, Dave!
@ all
The master has spoken. End of discussion :-D
-
:bow:
One thing confuses me though: in the A4k, Alice has the complete address bus connected, so in theory you would 'only' need to
- redesign Alice for larger registers
- the 11 DRAM bus lines should be enough for 8 MB
- put in an 8 MB PS/2
and off you go (apart from OS/Zorro issues).
-
Nice to see your input here Dave, thanks :-)
-
Piru wrote:
Not quite. For example the blitter queue of the OS itself is run from interrupts. Forbid() + WaitBlit() doesn't guarantee that further blits won't happen.
So you are saying there is no way to wait until the blitter finishes? I find that rather hard to believe. Surely a lot of games rely on the OS not suddenly using the while its running. At least nothing more will be added to the queue whilst you are in forbid mode.
You misunderstood. Audio interrupt occurs when the sample playing has finished, where the interrupt code is located is irrelevant.
No I think you misunderstood me. I know what the problem is with audio interrupts, and I wasn't disagreeing with you. I was saying that there may be a lot of other interrupts that also may access chip ram and cause a problem.
I know it's common, but the official commodore line was always that you weren't supposed to use the hardware directly.
It was? Where did they say that? If so, why did they publish hardware reference manual with examples on how to use the hardware directly?
That's what I was always led to believe, at least for O/S friendly applications. I guess they publish the hardware details for games writers.
Even still, as I already said, you'd need to be on the workbench screen to swap the app out anyway so this won't apply.
I wouldn't consider this very usable solution then.
I don't see why, as you have to be on the workbench screen anyway to run another program.
-
hey dave,
what do you think of the minimig project? most of us think its pretty cool but i dont think i saw your opinion on it anywhere.
-
@Tricky
So you are saying there is no way to wait until the blitter finishes?
Sure there is, but your proposals are not working.
I don't see why, as you have to be on the workbench screen anyway to run another program.
You say it is possible to write such "swap" program. I still think it's not very stable solution, various things can easily break it. Lets agree to disagree, shall we?
I will hold my POV until you provide a working chipmem extender program. :-)
-
Piru wrote:
You say it is possible to write such "swap" program. I still think it's not very stable solution, various things can easily break it. Lets agree to disagree, shall we?
I don't even think we need to go as far as that. You are exactly right, it wouldn't be fool proof, but it would be interesting to see if it could be done at all. As I said, I'd have to write a lot of disclaimers in the readme!
I will hold my POV until you provide a working chipmem extender program. :-)
That's fair enough. I have other things to write just now, but I'll write a memory tracker patch as a first step soon as I finish Mr Beanbag.
-
@Tricky
Basically, for your "4 banks of chipram" approach to work, you'd have to have 4 completely independant instances of AmigaOS running, 3 of which are suspended.
The problem I see with this, is DOS. Imagine if you swapped instances while someone was accessing the disk. In the new instance, you delete some files, maybe even files that were open on the other instance.
Whoops! You've just corrupted your hard disk.