KFA-4000ATX - design your own Amiga

[bebek]

Or it would be easier not to talk about at all . 2MB CHIP is all we need here

[Mrs Beanbag]

oh it's plenty easy to TALK about it! DOING it is an entirely different matter, of course!

But you are right, this is off-topic, but it has got me thinking.

[PJM]

If this was me - I would place all the custom chips in an fpga (already kinda done) and run a standard 68k processor. I would add an sd card slot directly to the board and perhaps even spec a PCI slot and perhaps usb. You can also add dvi or hdmi support by speccing one of the many 'co processers' used in similar designs that would be invisible to the AMIGA side. Also this method would increase your appeal to the Apple and Atari worlds, maybe even the Sega one.

All the rest of the wishes everyone has I would add in a later version of the board. The most important thing is to focus on the core of what you want the board to be. Forget a physical AGA chipset as the chips are rare and an fpga allows more flexibility. Most of all good luck!

[pandy71]

Originally Posted by Mrs Beanbag

Yes indeed, but as you already point out, this requires software support.

Fast CHIP is (should be?) software transparent, with fast memory transfer, current 2MB limit is not so painful.

Originally Posted by Mrs Beanbag

We wouldn't be able to use more memory in existing programs that require Chip RAM, for instance ProTracker. Also it could make things awkward from a multitasking perspective, since each program may have to swap things in and out constantly, Chip RAM will have to be continuously allocated/deallocated by the OS which has its overhead.

Yes and No, MMU adress translation may be compatible with old software (transparent from HW perspective) - imagine each AUD pointer mapped in different area - HW (and i assume SW) doesn't check (? im wrong?) sum of pointers (how large memory in total is addressed by them).

Originally Posted by Mrs Beanbag

But really we still don't even escape the problem. If we make the Chip RAM access by CPU such a speed, suppose a new accelerator was developed that had Fast RAM of an ever higher speed. Then Chip RAM is a bottle neck again. We just kicked the can down the road.

From CPU perspective there will be no CHIP/FAST difference - all memory is FAST.

Originally Posted by Mrs Beanbag

Usually graphics cards do have their own RAM, the CPU has to push graphics data in over the PCIe bus, and the graphics card typically has less memory than the motherboard so the Amiga is not all that different really.

Usually modern card is able to push data in both directions by DMA, some graphics card may have more memory than mobo RAM.

Originally Posted by Mrs Beanbag

I really don't know what you mean by this MMU suggestion. The chip set would be able to remap Chip RAM accesses by the hardware? This could end up a nightmare very quickly. Re-implementing Agnus/Alice with a wider bus would be easier.

Yes and no, depends - address translation based on registers and I/O MMU configuration can be transparent form SW/HW perspective at least when classic approach is used.
But to close this OT - i don't believe that anything like this is necessary - classic (OCS/ECS) 2MB CHIP is OK - AGA is a different story but some small improvements are possible without destroying backward compatibility.

[bebek]

Originally Posted by PJM

If this was me - I would place all the custom chips in an fpga (already kinda done) and run a standard 68k processor. I would add an sd card slot directly to the board and perhaps even spec a PCI slot and perhaps usb. You can also add dvi or hdmi support by speccing one of the many 'co processers' used in similar designs that would be invisible to the AMIGA side. Also this method would increase your appeal to the Apple and Atari worlds, maybe even the Sega one.

All the rest of the wishes everyone has I would add in a later version of the board. The most important thing is to focus on the core of what you want the board to be. Forget a physical AGA chipset as the chips are rare and an fpga allows more flexibility. Most of all good luck!

This is not about new commercial product. The aim is to bring back to life BER A4000 mainboardswith damaged PCB and most likely good custom IC's.

[PJM]

Originally Posted by bebek

This is not about new commercial product. The aim is to bring back to life BER A4000 mainboardswith damaged PCB and most likely good cur=tom IC's.

Removing components from the existing board will be tricky if not impossible without damage to the components.

[bebek]

Originally Posted by PJM

Removing components from the existing board will be tricky if not impossible without damage to the components.

Not really, you can remove them without any damage to PCB or components with right tools and skills . Put them back and take them out again with same result .

[Mrs Beanbag]

Originally Posted by pandy71

Fast CHIP is (should be?) software transparent, with fast memory transfer, current 2MB limit is not so painful.

software would have to be written to do the transfer. it won't happen by magic.

Yes and No, MMU adress translation may be compatible with old software

who loads the MMU with a translation table?

From CPU perspective there will be no CHIP/FAST difference - all memory is FAST.

All memory would only be as FAST as the chipset. Fast maybe, by current Chip RAM standards, but however fast it is we'd be stuck with it.

But to close this OT - i don't believe that anything like this is necessary - classic (OCS/ECS) 2MB CHIP is OK - AGA is a different story but some small improvements are possible without destroying backward compatibility.

Well we are talking about AGA machines here. The thread is about a new A4000 clone.

[PJM]

Originally Posted by bebek

Not really, you can remove them without any damage to PCB or components with right tools and skills . Put them back and take them out again with same result .

Removing without damage to PCB - yes. Removal without damage to components - you will end up killing some not all but some components. Also with the age of the components/PCB etc they won't come off as easily as you'd hope.

It's a lot of effort - you'd be committing years to a project like this and potentially thousands of pounds. I'm not kidding either. Good luck.

[Mrs Beanbag]

what is the problem here... people remove and resolder SMT components all the time, it takes some practice but you don't need to invoke demons or sell your soul Satan or anything

[Jope]

Yep, I don't get it either. They can take the amount of heat required for removal/reinstallation. Naturally if you're going to install/remove the same component a hundred times, your yield will go down. :-)

[pandy71]

Originally Posted by Mrs Beanbag

software would have to be written to do the transfer. it won't happen by magic.

It can be done in transparent way (from old software perspective - for example Audio can be mapped to different area, acces to adress may be trapped and modified on the fly depends from context - tricky but doable - more advanced version of WHDLoad/Enforcer)

Originally Posted by Mrs Beanbag

who loads the MMU with a translation table?

You, trough some control software (new app with presets related to apps).
But once again - from my perspective 2MB of CHIP is OK.

Originally Posted by Mrs Beanbag

All memory would only be as FAST as the chipset. Fast maybe, by current Chip RAM standards, but however fast it is we'd be stuck with it.

As we now main difference between FAST and CHIP from CPU perspective is that CHIP access cycles need to be shared with chipset - any CPU code located in this area and any CPU access are limited by chipset activity - all UMA architectures are at some point limited but imagine that you can do 100 - 300MBps transfer to chip even is old chipset is able to do maximally 7 - 14MBps

Originally Posted by Mrs Beanbag

Well we are talking about AGA machines here. The thread is about a new A4000 clone.

You can't separate software from HW - i pointed this earlier - i don't think for example that such refreshed Amiga need to modify chipset - this is no longer necessary - we should use PC peripherals widely available (so accommodate interfaces as USB, PCIe as much as possible, drivers should use as much as possible code from Linux), and HW changes should focus how to deliver old data (generated by OCS/ECS/AGA) to PC peripherals (so they can be used directly with PC peripherals.

Originally Posted by PJM

Removing without damage to PCB - yes. Removal without damage to components - you will end up killing some not all but some components. Also with the age of the components/PCB etc they won't come off as easily as you'd hope.

He can use preheater and hot air station to rework - this id common - regular practice today with significantly more complex chips...
[ Show youtube player ]

[Mrs Beanbag]

Originally Posted by pandy71

It can be done in transparent way (from old software perspective - for example Audio can be mapped to different area, acces to adress may be trapped and modified on the fly depends from context - tricky but doable - more advanced version of WHDLoad/Enforcer)

Hardware can't possibly know that data coming from the CPU is to be used for audio or graphics. Software will have to be programmed to do so. Neither does Agnus/Alice make it known to the data bus that it is requesting audio or graphics data, and the Blitter can be used to copy either. You would have to completely re-implement Agnus/Alice, in which case you might as well just add a couple more address lines, which would be trivial.

Besides this won't allow a graphics program more graphics, or a music program more samples. So it is pointless anyway. WHDLoad is only for games, and games won't need more Chip RAM anyway, and it works by modifying the software. Someone would have to sit down and rewrite bits of the code for every game.

[pandy71]

Originally Posted by Mrs Beanbag

Hardware can't possibly know that data coming from the CPU is to be used for audio or graphics. Software will have to be programmed to do so. Neither does Agnus/Alice make it known to the data bus that it is requesting audio or graphics data, and the Blitter can be used to copy either. You would have to completely re-implement Agnus/Alice, in which case you might as well just add a couple more address lines, which would be trivial.

Besides this won't allow a graphics program more graphics, or a music program more samples. So it is pointless anyway. WHDLoad is only for games, and games won't need more Chip RAM anyway, and it works by modifying the software. Someone would have to sit down and rewrite bits of the code for every game.

HW can be designed to know (especially if preconfigured) - DMA cycles are deterministic, RGA access is deterministic.
WHDLoad was used as example (with HW this can be on the fly modified).

[Mrs Beanbag]

so you would actually reproduce Agnus's DMA cycle logic in order to know what kind of data it was asking for, well it is possible in theory but our "simple" MMU is now getting very complex, and in any case it only solves half of the problem. We still won't know what sort of data the CPU is trying to write. And what if someone tries to use Blitter to copy sounds (perfectly legal)? It would still only give us 2Mb of graphics and 2Mb of sounds per application. And if we're going to all this trouble, it would be just as easy to add a couple more address lines to Agnus and dispense with the MMU altogether (which is not a trivial thing to implement in the first place).

"WHDLoad was used as example (with HW this can be on the fly modified)." - really i just don't know what you are talking about here, i'm beginning to wonder if you know how computers work.

[pandy71]

Originally Posted by Mrs Beanbag

so you would actually reproduce Agnus's DMA cycle logic in order to know what kind of data it was asking for, well it is possible in theory but our "simple" MMU is now getting very complex, and in any case it only solves half of the problem. We still won't know what sort of data the CPU is trying to write. And what if someone tries to use Blitter to copy sounds (perfectly legal)? It would still only give us 2Mb of graphics and 2Mb of sounds per application. And if we're going to all this trouble, it would be just as easy to add a couple more address lines to Agnus and dispense with the MMU altogether (which is not a trivial thing to implement in the first place).

"WHDLoad was used as example (with HW this can be on the fly modified)." - really i just don't know what you are talking about here, i'm beginning to wonder if you know how computers work.

Please tell me how computer works - perhaps you are right - glad to learn.

[Mrs Beanbag]

Computers just blindly push data around exactly the way they are programmed. They can't tell the difference between graphics and sound (because whatever the data represents to us, it's all just binary numbers on disk or in RAM), and they can't rewrite your programs for you to do what you meant instead of what you wrote.

[pandy71]

Originally Posted by Mrs Beanbag

Computers just blindly push data around exactly the way they are programmed. They can't tell the difference between graphics and sound (because whatever the data represents to us, it's all just binary numbers on disk or in RAM), and they can't rewrite your programs for you to do what you meant instead of what you wrote.

So you need to program some action (data pushing)?

[bebek]

Gentelmen, this conversation is not for this thread. Your visions are great but please move it somewhere else .

So many replays and I had little answers to my original problem

[pandy71]

Originally Posted by bebek

Gentelmen, this conversation is not for this thread. Your visions are great but please move it somewhere else .

So many replays and I had little answers to my original problem

Sorry, please accept my apologies.

How I see it:

- only pin headers for serial and parallel ports on mainboard,

wise decision, go for modern level converters (not 1488/1489) - they simplify power and provide higher transfer rates capabilities

- no Video Slot or ISA slots

this is unwise - video slot can be not populated but for sure should be present on mobo, ISA is nice to have.

- PS2 or USB socket for mouse (not sure which one is the best and available as open source)

go for headers - final solution can be applied later

- 15-pin VGA type socket for RGB output

OK but i would add header on mobo to connect something - just in case

- no audio filter

55kHz filter (at least integrator) is required (Paula is designed in particular way)

- M6242 clock

bit outdated but...

- SIMM socket for 2MB chip and 1 or 2 SIMM sockets for FAST memory

FPM? PS2 style?

- depending on the size it will be 4 or 6 layer board, aiming to have components on one, top side only but it may happen that on two.

would try to squeeze on 4 - 6 will be expensive