Amiga.org
Amiga News and Community Announcements => Amiga News and Community Announcements => Amiga Hardware News => Topic started by: Spidi on March 08, 2017, 04:44:53 PM
-
Wicher family of products will soon expand with the launch of a brand new model: Wicher 500i.
This new turbo card has been designed specifically for Amiga A500/A500+ computers.
It is intended to be installed inside your Amiga and significantly increase its potential.
Specifications:
CPU: MC68000/68010
Max. clock: 50MHz
RAM: 1-8 MB SIMM 72 (FPM,EDO)
IDE controller
SPI controller
Performance for MC68000 and CPU clock 50MHz (SysInfo 4.0, AIBB 6.5).
Mips: 4.40
Dhrystones: 4222
IDE transfer: ~3.1MB/s
RAM transfer: ~6.94MB/s
View details http://retro.7-bit.pl
(https://retro.7-bit.pl/css/images/Wicher500i_350.png)
Video (https://www.youtube.com/watch?v=A6-r4OQP9Sc), Frontier running on the Wicher500i 000@50MHz (https://youtu.be/WWG1BVmYEXU)
-
Wow... this is fantastic! I had no idea about this or your other products.
-
How much?
I see it is mentioned as useful in amiga 1000, I wonder how kickstart would be handled.
-
How much?
I see it is mentioned as useful in amiga 1000, I wonder how kickstart would be handled.
Usual way. Hold between fingers and insert disk carefully. :)
Joke, sorry if you didn't laugh.
On topic - I am seeing a lot of bare A500 mothrboards on eBay lately. I guess the keyboards are getting hard to get fixed now. So it is nice to see someone still giving support.
-
Actually that is how I have been doing it, a lot of my disks have issues. Took a while to find a good disk to write a kickstart disk.
I really need an ide solution not wanting to use gotek.
-
oh wow.. NICE! More expansions for an A500. Very interesting!
-
How do you get a 68000 to clock at 50 MHz?
I've never seen even the HC versions pushed that high.
The depressing part is an '020 or '030 at half that speed would still dust a 50 MHz 68000's fanny.
And...there are 50 MHz '030 components.
-
The depressing part is an '020 or '030 at half that speed would still dust a 50 MHz 68000's fanny.
And...there are 50 MHz '030 components.
I think this is another one of those "homebrew" type projects, along the lines of the TerribleFire, etc. The designers are starting with an '000 and hopefully moving up from there as they learn. ;)
-
I think this is another one of those "homebrew" type projects, along the lines of the TerribleFire, etc. The designers are starting with an '000 and hopefully moving up from there as they learn. ;)
Still, where the heck do you find 50MHz 000s?
I've seen 66MHz CPU32 derivatives, but nothing this overclockable with an 000 or 010 designation.
And yeah, working with '020 and '030 cpus is SO much more complicated, but there are some operations that are up to 6 times faster.
-
Overclocking HC version.
-
Overclocking HC version.
I didn't know they could be pushed that far.
But its always been known that Motorola greatly under rated them, so...
-
The original 68HC000 in Supra Turbo 28 clocked happily to 28MHz - I did see some mentions that somebody did clock it to 42 MHz. Those CMOS chips were very tolerant.
-
What is a spi controller and what is the practical usage of it on an A500?
-
On topic - I am seeing a lot of bare A500 mothrboards on eBay lately. I guess the keyboards are getting hard to get fixed now. So it is nice to see someone still giving support.
You can get new membranes for £23.50 including delivery.
http://www.sellmyretro.com/offer/details/%2Abrand-new%2A-commodore-amiga-a500-~~-a500%2B-keyboard-membranes-2871
-
What is a spi controller and what is the practical usage of it on an A500?
General purpose serial port for devices is my understanding.
Only high speed though - used a fair bit for ad hoc networking. Wireless and wired (wireless is probably more common). Bluetooth too.
VERY handy if you do crazy things with Arduino's etc.
Hooking up SD card reader/writers also becomes easier (and cheaper). Sometimes they come built into an LCD display with a touch screen. But only a few bucks for a simple SD card adaptor.
You can get new membranes for £23.50 including delivery.
http://www.sellmyretro.com/offer/details/%2Abrand-new%2A-commodore-amiga-a500-~~-a500%2B-keyboard-membranes-2871 (http://www.sellmyretro.com/offer/details/%2Abrand-new%2A-commodore-amiga-a500-%7E%7E-a500%2B-keyboard-membranes-2871)
OOh... I checked a few days ago when they mentioned new A1200 membranes! Couldn't find, thank you! :)
OK, got an A1000 keyboard I can hook up - but it's not ideal (even if they do seem to last forever).
-
What is a spi controller and what is the practical usage of it on an A500?
In external version Wicher500 I connected RTC DS1306 (https://www.youtube.com/watch?v=BZEe5gkAY-0)
-
In external version Wicher500 I connected RTC DS1306 (https://www.youtube.com/watch?v=BZEe5gkAY-0)
I did not know SPI real time clock existed.
Nice fact about SPI devices - is already a lot of open source C code to support them.
So should be fairly straightforward to get Amiga drivers written.
I doubt SD card would be bootable, would be much much more difficult?
But cheap network or WiFi should happen pretty quick. :) Faster than PlipBox.
I did say thank you to TerribleFire for putting SPI on his accelerator, so thank you too Spidi. I think there are enough A500s out there to support the 2 different styles - TF is quicker but not so easy to get quantities of 68030 chips these days, especially at high speed.
-
The original 68HC000 in Supra Turbo 28 clocked happily to 28MHz - I did see some mentions that somebody did clock it to 42 MHz. Those CMOS chips were very tolerant.
I know about the Supra, and I have heard the claims of higher clocks, I've just never heard of anyone pushing one to 50MHz.
I'd love to know if they are overvolting it.
-
I know about the Supra, and I have heard the claims of higher clocks, I've just never heard of anyone pushing one to 50MHz.
The problem is that not all of the chips will make it to 50Mhz. There are good samples, and there are bad samples, depending on the quality of the die. Note that it can clock the CPU *up to* 50Mhz, not that it runs *always at* 50Mhz. If you're lucky, it will. Otherwise, it will run at a slower speed, in "worst case" at the nominal speed of the CPU.
-
The most annoying thing about a 50MHz 68000 is all the software that require 020+.
Btw, Minimig v1.1 can push the 680SEC00 to 49MHz.
-
The most annoying thing about a 50MHz 68000 is all the software that require 020+.
Btw, Minimig v1.1 can push the 680SEC00 to 49MHz.
Yaqube managed to get a stable 56.72Mhz but only one of his Minimigs was able to go that fast.
-
Yeah, the rest of us run it at 49MHz or 42MHz, iirc.
Anyways, it's a bit annoying to have such a fast and stable system and not being able to use a lot of the software I want :)
-
The most annoying thing about a 50MHz 68000 is all the software that require 020+.
Something like cyberpatcher/oxypatcher that trapped and patched code to run on 68000 would be great.
Back in the day I had a supra turbo 28mhz and wrote a couple of patches. One was for unaligned reads that a jpeg datatype used, but otherwise it ran fine on the 68000. It happened infrequently, so using the exception was good enough.
-
Any word on pricing?
-
Something like cyberpatcher/oxypatcher that trapped and patched code to run on 68000 would be great.
The result would be still very slow, and not very compatible. To list you a couple of problems this idea has:
First, while the 68060 had a separate exception for "instructions it should have implemented, but did not", the 68000 does not. Any advanced instruction just triggers the "invalid isntruction" exception, regardless of whether this instruction is valid on some member of the 68k family or not. Unfortunately, the same exception is used for debugging, and "true" invalid instructions.
Second, the result would be very slow. Remember, there is no support for extended instructions in the 68K, so it would have to decode these instructions manually, execute them manually, and write the results back manually. While the 68060 has enough horsepower to do that, the 68K does not.
Third, tools like MuRedox depend on the fact that the unimplemented instructions are all at least four bytes in size, so it can replace them by a 16-bit JSR instruction. That is not always the case here.
-
First, while the 68060 had a separate exception for "instructions it should have implemented, but did not", the 68000 does not. Any advanced instruction just triggers the "invalid isntruction" exception, regardless of whether this instruction is valid on some member of the 68k family or not. Unfortunately, the same exception is used for debugging, and "true" invalid instructions.
As long as the handler looks for the emulated instructions first, then I don't see this as a big deal.
Second, the result would be very slow. Remember, there is no support for extended instructions in the 68K, so it would have to decode these instructions manually, execute them manually, and write the results back manually. While the 68060 has enough horsepower to do that, the 68K does not.
If the instructions were patched on the first use to jump into generated code then the overhead wouldn't be that great & it would run way faster than not being able to run it at all.
Third, tools like MuRedox depend on the fact that the unimplemented instructions are all at least four bytes in size, so it can replace them by a 16-bit JSR instruction. That is not always the case here.
Just move the following instruction as well in that case, using offsets that will trap if jumped to directly. I'll grant you that it's way more complex at that point.
-
Too much patching going on already, OS3.x needs a serious cleanup.
Software should very well be able to ask the OS what CPU they are running on, and use optimised functions accordingly.
-
Too much patching going on already, OS3.x needs a serious cleanup.
Software should very well be able to ask the OS what CPU they are running on, and use optimised functions accordingly.
It can already, it's too much of a pain. What you want is a compiler which can generate mixed binaries and have the OS load the correct code for each.
That doesn't help with software written in the last 30 years though.
-
If the instructions were patched on the first use to jump into generated code then the overhead wouldn't be that great & it would run way faster than not being able to run it at all.
Actually, the overhead is rather big. The exception is a minor detail in the overall story.
Just move the following instruction as well in that case, using offsets that will trap if jumped to directly. I'll grant you that it's way more complex at that point.
Ok, then let's make a compuation: Two instructions to be emulated together, so around 2^32 possible combinations. Ok, not exactly, there are less instructions, but you get the picture.
There is another problem, though. The MuRedox trick only works because it can relocate the last 32K of the addressing space to RAM, by means of the MMU. Now, the 68K only has a 24bit address space, and the first 32K are for exception vectors and chip memory, and the last 32K are ROM.
Hence, you'll need a full 32-bit jump, or 6 bytes, not just four bytes.
Anyhow.... If anyone wants to attempt this, go ahead. I even have here a partial solution which emulated a couple of instructions for the first Phoenix core, so you get a full EA decoder already, and an implementation of the bitfield instructions. You "only" have to fill in the rest... (-:
-
Too much patching going on already, OS3.x needs a serious cleanup.
Software should very well be able to ask the OS what CPU they are running on, and use optimised functions accordingly.
but the current software doesnt ask the os what cpu it is running on. instead it relies on the user to choose the right version of the binary for the cpu by hand. awful! the only solution i can think of is a cpu that is backwards compatible or almost fully backward compatible to all 68k cpu versions out there. the closest realisation of which is apollo fpga core, for what ive heard.
-
but the current software doesnt ask the os what cpu it is running on.
Uncarefully written software, as usual. If done properly, the software has to check, and uses optimized functions where possible. This is not a choice the user should make.
-
Uncarefully written software, as usual. If done properly, the software has to check, and uses optimized functions where possible. This is not a choice the user should make.
uncarefully, right, im not advocatting that, as you might have noticed, but the situation ist that is actegory that fits almost all software written for amiga. the hell of cpu optimized library versions as example.
-
Well, one could have hoped that the OS itself would be more "carefully" written, but no.
Does the OS even provide anything for software to detect CPU capabilities?
-
Well, one could have hoped that the OS itself would be more "carefully" written, but no.
Actually, the Os is. There is only one dependency I recall where one particular Os function (somewhere in graphics, if I recall) requires a 68020 or up, and this is a conditional assembly which is only used for Kickstarts for machines that came with a 68020 or up. So it's really not that bad. It just means that you cannot plug in a 68K into a machine that was designed to run with a 68020 or up.
Does the OS even provide anything for software to detect CPU capabilities?
SysBase->AttnFlags exists since ages.
-
Uncarefully written software, as usual. If done properly, the software has to check, and uses optimized functions where possible. This is not a choice the user should make.
"Nice software" with different versions for FPU type / processor type were seen as using less memory and system resources back then.
I am not saying you are wrong on this Thomas - rather, I am saying the goalposts have shifted a LONG way.
One phone tech request I had a to answer a fair bit was "can I have a switch to select any possible processor type." The answer I gave was "theoretically, before you switch on, but an accelerator card with all processor types would not fit inside the space available."
Things are a bit different today, but the contesting demands still remain..
-
"Nice software" with different versions for FPU type / processor type were seen as using less memory and system resources back then.
Yeah, having a single binary with:
if (68000)
{
}
else if (68020)
{
}
All over the place would be horribly inefficient for memory and cpu usage.
The ideal would be a compiler that can target multiple cpus in one pass and output different hunks that only get loaded if that cpu was available.
So a binary built for 020/030/040/060, may have some routines that have the same code built for the 020 & 030, and separate code built for the 040 & 060. And others might have code shared for the 020/030/040 and separate for the 060. When loading it would make sure that the correct code was loaded and linked & in this case the binary would fail to load on a 68000 and 010.
Actually, the Os is. There is only one dependency I recall where one particular Os function (somewhere in graphics, if I recall) requires a 68020 or up, and this is a conditional assembly which is only used for Kickstarts for machines that came with a 68020 or up. So it's really not that bad. It just means that you cannot plug in a 68K into a machine that was designed to run with a 68020 or up.
Or Kickstart from an 020+ machine in an A500. I'd be interested in where it was. When the A1200 came out, I saved a copy of kickstart from a friends computer and loaded it into the phase 5 68000 14mhz kickstart ram. I probably didn't use it that much, but I don't remember having any problems with the CPU. There were some issues running with ECS, but I think a later SetPatch sorted those.
-
All over the place would be horribly inefficient for memory and cpu usage.
No, not really. Typical software has hotspots where most CPU time is spend. Optimize there, use a function pointer to call into the critical part, set the function pointers to the optimized hotspots in the init functions.
There is no overhead, and it helps. For all practical purposes, it does not make sense to compile everything for all CPUs. Most code does not matter much timing wise.
Or Kickstart from an 020+ machine in an A500. I'd be interested in where it was.
ObtainPen() (actually completely uncritical, useless optimization) and GetColorMap(). This is compiled in for all machines with an AA chipset, which were not delivered with a 68K only. Thus, Kickroms of those machines will not work with a plain 68K.
Actually, the above optimizations are completely pointless (as often), and where it makes sense, the kickstart provides a 68K and a 68020 version, but switches dynamically (graphics/Text() does that).