Vampire, Gotek, 68000, misteries, doubts, questions...

[flaviosr]

Dear All,

I am trying to build a high tech Amiga, so:
° I have modified a tank mouse to make it optical with the "new" kit (great!!!);
° I have put a Gotek floppy drive and I have a question: I have tried different USB key and some work, some do not, and others sometimes work and sometimes do not so, is this normal or am I missing something? There are limits in USB key capacity?
° when I removed the CPU to put the Vampire I found an Hitachi CPU, code HD68HC000P12, a 12.5 MHz one: is this normal? I have a rev. 6A mobo (see photo), is it possible to see from the mobo the speed of the system? I would not like to discover that the mobo have been hacked and it is working @ 12.5 MHz so that I could fridge the Vampire!!!
° I have tried different ADF and some do not work (for example if I put Workbench 1.3 I receive some errors during startup even if Workbench starts): am I right and Vampire is not 100% compatible with "original" Amigas (I am supposing not even 90% compatible...);
° I have put a 4 Gb CF and I cannot make it recognised from the HD program... the strange think is that I forced Workbench 3.1 to partition it and it did the job (one partition of 8 Mb and all the rest in another partition). If I enter the partitioning program... again I cannot modify it. Some suggestions?
° [LAST] apart connecting a CD drive to the Vampire IDE channel does exist another way? For example using the MicroSD of the Vampire as a CD in some way...

Forgive me!

Thank you for your help

[guest11527]

° when I removed the CPU to put the Vampire I found an Hitachi CPU, code HD68HC000P12, a 12.5 MHz one: is this normal? I have a rev. 6A mobo (see photo), is it possible to see from the mobo the speed of the system?

This is a CMOS component, different from the NMOS version. However, just because the CPU says 12Mhz does not mean that it runs on this frequency. It is just the maximum frequency the CPU has been qualified for.

If there is no other modification on the board, then that just means that a diffferent CPU typie has been installed - it would then still run with 7Mhz.

Thus, without checking the board, it is hard to tell.

° I have tried different ADF and some do not work (for example if I put Workbench 1.3 I receive some errors during startup even if Workbench starts): am I right and Vampire is not 100% compatible with "original" Amigas (I am supposing not even 90% compatible...);

Note that Kickstart 1.3 only supports CPUs up to the 68020. This *might* be a problem, but I do not know.

° I have put a 4 Gb CF and I cannot make it recognised from the HD program... the strange think is that I forced Workbench 3.1 to partition it and it did the job (one partition of 8 Mb and all the rest in another partition). If I enter the partitioning program... again I cannot modify it.

HDToolBox does not support partitions larger than 4GB. Just create a partition that is a bit smaller than 4GB, and you will be fine.

[Iggy]

This is a CMOS component, different from the NMOS version. However, just because the CPU says 12Mhz does not mean that it runs on this frequency. It is just the maximum frequency the CPU has been qualified for.

If there is no other modification on the board, then that just means that a diffferent CPU typie has been installed - it would then still run with 7Mhz.
...

Yep, its just a Hitachi CMOS cpu. Its not very likely that the system is overclocked.
That processor, if its anything like Motorola's CMOS 68000s is probably good for even more than 12MHz.
But 68000s, no matter how highly clocked aren't going to match a Vampire, or an '020, '030, '040, or '060 for that matter.

So if you really want to build a high performing system, you're going to need an accelerator.

[IanP]

...
° I have tried different ADF and some do not work (for example if I put Workbench 1.3 I receive some errors during startup even if Workbench starts): am I right and Vampire is not 100% compatible with "original" Amigas (I am supposing not even 90% compatible...);
...

Depends what you mean by "original" Amigas and how you choose to quantify compatibility. Amigas came with a variety of different CPUs at different speeds, with different memory configurations, chip sets, expansions, operating system versions (both firmware and software), filesystems etc. Each variation introduces possibilities for incompatibilities, in that regard the Vampire is no different to any other upgrade. The Vampire adds a LOT to a basic A500 or A600 so the potential areas for poorly written software to break are considerable however the Apollo team have done a lot to minimise these and continue to make improvements (using alternative kickstarts has recently been demonstrated as a future option). The vampire is also the only option to add compatibility with AGA software to the non-AGA Amigas in the future.

[SamuraiCrow]

Keep in mind that the Vampire has a custom Kickstart image in flash memory and the ROM is not used ever.  Currently it's 3.1 compatible but a 1.3 compatible fallback mode might soon be available .

[Motormouth]

.

Note that Kickstart 1.3 only supports CPUs up to the 68020. This *might* be a problem, but I do not know.

@Thomas Richter
I have head this before, but we (where I worked) had both a amiga 2500 (ie an A2000 with an A2630 board) and an A2000 with a GVP board with 50 Mhz 68030 board, (was using lightwave and the toaster).  I never really had much issue with 030.  It most worked fine with 1.3.3 and well written workbench apps.
The only issue was some old programs that did not like high mapped 32 bit memory,  I would always map the memory high when possible and have some 16 bit ram (usually at least 2 megs) in the 8meg space for compatibility.

Now as for games that banged the copper, most did not work with even with 68020 as you can guess.


Things got squirrelly with the 68040, We had bought a fusion forty.  The 040 had to be patched to work with 1.3.  It worked fine with lightwave and the toaster (with the patches), but not with all our software.  Luckily it was lightwave we needed.

[grond]

@Thomas Richter
I have head this before, but we (where I worked) had both a amiga 2500 (ie an A2000 with an A2630 board) and an A2000 with a GVP board with 50 Mhz 68030 board, (was using lightwave and the toaster).  I never really had much issue with 030.

The 030 is almost identical to the 020. I don't see how 020 software would break on an 030. Even the 256 bytes of data cache that got added from the 020 to the 030 shouldn't cause any problems as they are write-through and the 256 bytes of instruction cache were already present in the 020 which is why the OS should clear the instruction cache when loading and dispatching code (a process which essentially is self-modifying code).

[guest11527]

The 030 is almost identical to the 020.

That's not quite the point. This is from the 1.3 exec/execbase:

Code: [Select]

/******* AttnFlags */
/*  Processors and Co-processors: */
#define AFB_68010       0       /* also set for 68020 */
#define AFB_68020       1
#define AFB_68881       4  
#define AFF_68010       (1<<0)
#define AFF_68020       (1<<1)
#define AFF_68881       (1<<4)
IOWs, the 1.3 exec did not detect and did not signal the 68030. That's what I meant that "it is not supported".   Yes, it typically makes little difference, and the cache of the 68030 (which is really the major difference from an Os perspetive) is small enough so it *typically* does not hurt.  

and the 256 bytes of instruction cache were already present in the 020 which is why the OS should clear the instruction cache when loading and dispatching code (a process which essentially is self-modifying code).

Kick 1.3 had no provision to flush caches, and no Os interface for this either. Code had to do it itself, though the 256 bytes of cache were small enough to cause trouble only in rare cases.

Thus, 1.3 worked on the 68020 by chance, not by design, and had no idea about the 68030. All that came with v37.

[flaviosr]

Depends what you mean by "original" Amigas and how you choose to quantify compatibility. Amigas came with a variety of different CPUs at different speeds, with different memory configurations, chip sets, expansions, operating system versions (both firmware and software), filesystems etc. Each variation introduces possibilities for incompatibilities, in that regard the Vampire is no different to any other upgrade. The Vampire adds a LOT to a basic A500 or A600 so the potential areas for poorly written software to break are considerable however the Apollo team have done a lot to minimise these and continue to make improvements (using alternative kickstarts has recently been demonstrated as a future option). The vampire is also the only option to add compatibility with AGA software to the non-AGA Amigas in the future.

I meant classic A500 games, like Gods, Barbarian and so on.
I read that the Vampire is a pumped (in speed) 68000 and not a 68020/030/040/060 emulation.
But he uses kickstart 3.1 and this could be a problem, and I read that in the future it would be possible to use different kickstart!
I supposed not to have problems since I use WHDLoad with different CPUs (68030, 040, 060) and I never had problems but perhaps WHDLoad has a bit of emulation... and at the moment I am not able to check WHDLoad on my Vampire...
I think I have to think about adding an internal slimDVD!
I at the very beginning with my Vampire and perhaps my email has been written too early, without so much experience from my side!

[flaviosr]

Keep in mind that the Vampire has a custom Kickstart image in flash memory and the ROM is not used ever.  Currently it's 3.1 compatible but a 1.3 compatible fallback mode might soon be available .

Sometimes, without any clear rule, my A500 starts with kickstart 1.3 (the original one)!!! I have read that it would be better to remove the original kickstart... I would try but I am a bit afraid to ruin something...

[Motormouth]

That's not quite the point. This is from the 1.3 exec/execbase:

Code: [Select]


/******* AttnFlags */
/*  Processors and Co-processors: */
#define AFB_68010       0       /* also set for 68020 */
#define AFB_68020       1
#define AFB_68881       4  
#define AFF_68010       (1<<0)
#define AFF_68020       (1<<1)
#define AFF_68881       (1<<4)

IOWs, the 1.3 exec did not detect and did not signal the 68030. That's what I meant that "it is not supported".   Yes, it typically makes little difference, and the cache of the 68030 (which is really the major difference from an Os perspetive) is small enough so it *typically* does not hurt.  


Kick 1.3 had no provision to flush caches, and no Os interface for this either. Code had to do it itself, though the 256 bytes of cache were small enough to cause trouble only in rare cases.

Thus, 1.3 worked on the 68020 by chance, not by design, and had no idea about the 68030. All that came with v37.

@Thomas Richter

Ahh, Ok I get it.

[grond]

I read that the Vampire is a pumped (in speed) 68000 and not a 68020/030/040/060 emulation.

That's not correct. The Vampire is basically an enhanced 060 with full 020 (the most complex of them all) compatibility. The only relevant piece missing for now is the MMU (which is there but not accessible by user software).

[kolla]

The Vampire is basically an enhanced 060 with full 020 (the most complex of them all) compatibility.

What grond tries to say here, is that the Apollo Core 68080, which is the CPU used on the Vampire, is basically an enhanced 060 that is compatible with software written for 020 (the most complex of them all).

Compatibility is important, compatibility between software and hardware - not between two pieces of hardware that will never run together :p

And really - 68020 is the most complex 68k?

[SamuraiCrow]

And really - 68020 is the most complex 68k?

Starting with the 040 opcodes and addressing modes were dropped to simplify the instruction set.  The 060 could not do a 32b by 32b multiply, for example.

[guest11527]

Starting with the 040 opcodes and addressing modes were dropped to simplify the instruction set.  The 060 could not do a 32b by 32b multiply, for example.

Well, the addressing mode that is missing is actually "packed decimal", which is a 68881/882 addressing mode. 64 bit integer instructions are missing, yes.

But "complexity" is not a matter of the number of instructions. The 68060 is certainly more complex than the 68020, given that it includes "one and a half" arithmetic unit, is super-scalar, includes the FPU and MMU, unlike the 68020 which micro-coded many instructions.

The 68000 is, for example, completely micro-coded, i.e. it runs on its on native "microcode" that interprets the 68000 instructions.