Vampire 500 project started

[Lord Aga]

Holy smokes that's fast
Way to go Majsta

[majsta]

Yap it is a fast but it could go a lot faster, today's plan is to fix some chip controller bugs and to finally start interfacing IDE.

[Cobe]

Reason for me to get A500, cause A600 is rare here as you know.
And of course to play 2,5 kilo ratz like rabbit Ziveo brate!

[Adrian Browne]

Is there a benefit to getting the vampire 500 as well as an apollo board? Or should I just wait for the apollo board? (if the apollo board happens)

[pandy71]

When and where i can place my order?
Is there any planned version for DIY (PCB + components)?

[majsta]

Project is not finished yet, like you know i didn't worked too much on this design and now i have problems with IDE detection procedure again. There is a lot of documentations but so far I have no idea how to implement that.

After all of that is done and fully tested then we can talk about future plans, production etc...

So far INTENA and INTREQ are giving me nightmare.

[Zetr0]

@majsta

My friend, I am very pleased to see you back on this project, its very exciting and I look forward to seeing your results.

I am just getting to grips with the Zorro2 bus arbitration so I feel your pain my friend, but persevere we must - the results are worth it.

I have a little experience with FPGA's maybe talking through the problem will help - just hit me up in PM =)

[majsta]

Hi

Problem is that I want to build IDE controller without sending any information's to Amiga what is going on. So now I m not so certain that I must follow all of the procedures regarding INT2, OVR or asserting AS when IDE controller is accessed. For now I need to understand how to bring up scsi.device by writing to some register or something. For tomorrow I decided to go with A600 and measure all needed signals. What is confusing me that TG68 is constantly in 01 mode(decoding internally without any external access) when DA2000 is accessed(part of IDE detection space). So actually I cant start any read/write to IDE because of that.

I don't know the same problem like last year I was talking about.

[pandy71]

Hmmm - stupid question but what with other IDE implementations on non Gayle equipped machines? Perhaps You can take just code?

[Promilus]

@pandy - actually CFIDE68k from Mika and other similar interfaces bases on Gayle state machine (so it basically emulates Gayle IDE component). In other instances (some turbo cards) there's external fixed logic IC (IDE controller) which can't be simply copied into FPGA. Gayle-style is used in most implementations because it is directly supported by KS2.05+ withouth any custom libraries etc. All others non-standard solutions are more problematic.

[majsta]

Yes, I need to use Gayle logic because of auto boot option.

[majsta]

Ok I will report problems here and maybe someone can help.

$DA3018 (Control) is something now I see as a problem and there is no info about it. So if we go like this:

IDE_select <= '1' when
cpu_addr(23 downto 12)=X"DA0" or -- $DA0000 - $DA0FFF
cpu_addr(23 downto 12)=X"DA1" or -- $DA1000 - $DA1FFF
cpu_addr(23 downto 12)=X"DA2" or -- $DA2000 - $DA2FFF
cpu_addr(23 downto 12)=X"DA3" -- $DA3000 - $DA3FFF
else '0';

We will have redirect that complete space to the IDE controller and since he don't follow regular Amiga bus cycle(in my case) we are blocking everything.
1. What is $DA3018 and who is looking there and what is he searching for?
2. Another problem, why don't I see bit 15 set on $DAA000 shouldn't scsi.device set it there automatically?

[Shadowfire]

Originally Posted by majsta

Hi

Problem is that I want to build IDE controller without sending any information's to Amiga what is going on. So now I m not so certain that I must follow all of the procedures regarding INT2, OVR or asserting AS when IDE controller is accessed. For now I need to understand how to bring up scsi.device by writing to some register or something. For tomorrow I decided to go with A600 and measure all needed signals. What is confusing me that TG68 is constantly in 01 mode(decoding internally without any external access) when DA2000 is accessed(part of IDE detection space). So actually I cant start any read/write to IDE because of that.

I don't know the same problem like last year I was talking about.

INT2 - its an open-collector type of signal with a pullup resistor on the motherboard.
From the point of view of a slave device, you assert it by driving the pin with a "0", and de-assert it by driving "Z" (which will cause the HDL to tristate the pin).

The INT2 line feeds into one of the custom chips, which manages the IPL0:2 lines that the 68000 sees. DO NOT try to drive IPL0:2 directly. Run a jumper wire to INT2 somewhere and let the custom chips deal with the processor interaction.

AS* is asserted by the current bus master at the start of bus cycle. Unless your device is doing DMA, you will never assert AS*.

XRDY and OVR: The onboard custom chip logic AUTOMATICALLY generates a DTACK* acknowledgement for ANY bus cycle at the conclusion of S7. XRDY and OVR are two means to stop this, which are used if you need to introduce wait states (i.e. the device is slow and will take more than 3 clock cycles to respond with data). If you can guarantee that you will always respond within a standard 68000 bus cycle, you don't even need to worry about XRDY, OVR, or DTACK, since the chips will complete the cycle on their own.

[Don_Adan]

$DA3018 ; (read) alt status, doesn't clear int
$DA3018 ; (write) device control - int/reset

[table]

; auxiliary status register bit definitions
BITDEF WDC,INT,7 an interrupt is pending
BITDEF WDC,LCI,6 last command ignored
BITDEF WDC,BSY,5 chip is busy with a level 2 command
BITDEF WDC,CIP,4 command in progress
BITDEF WDC,PE,1 a parity error was detected
BITDEF WDC,DBR,0 data buffer ready during programmed I/O

; control register bit definitions
BITDEF WDC,DMA,7 DMA mode is enabled for data transfers
BITDEF WDC,WDB,6 direct buffer access for data transfers
BITDEF WDC,HA,1 halt on attention (target mode only)
BITDEF WDC,HPE,0 halt on parity error enable

; source ID register control bits
BITDEF WDC,ER,7 enable reselection
BITDEF WDC,ES,6 enable selection (target or multiple initiators only)
BITDEF WDC,SIV,3 source ID valid

; command register control bits
BITDEF WDC,SBT,7 enable single byte transfer mode

[/table]

[Toni Wilen]

[table]

These appear to be WD SCSI chip bit definitions, not used in any IDE based Amiga. And they aren't directly addresssable anyway (via DMAC only)

[NMI]

Originally Posted by Shadowfire

DO NOT try to drive IPL0:2 directly. Run a jumper wire to INT2 somewhere and let the custom chips deal with the .

Since the idea is to hide the IDE-interface (Gayle) from the rest of the system, not adding a wire-cludge to the motherboard for the int2-signal and doing the int/ipl0:2 arbitration in the fpga seems like a neat idea. Especially since the CPU is also software in the fpga.
So why shouldn’t (can’t?) it be done like that?

[pandy71]

Originally Posted by NMI

Since the idea is to hide the IDE-interface (Gayle) from the rest of the system, not adding a wire-cludge to the motherboard for the int2-signal and doing the int/ipl0:2 arbitration in the fpga seems like a neat idea. Especially since the CPU is also software in the fpga.
So why shouldn’t (can’t?) it be done like that?

Yes, more or less this correct - not sure however if there is problem with hardware or scsi.device behavior (where scsi.device is coded to use Gayle and to detect Gayle presence in particular, HW linked way). Previously Majsta have problem with DTACK and Gary behavior (IIRC) - as Gayle and Gary see Amiga space in different way.
Idea to hide IDE from Gary is more than reasonable (no problem with adding additional wires from CPU to Gary or Paula, way faster bus arbitration as all access are internal and not system limited).

[majsta]

Yes that is the goal. I will explain everything and publish the code when is done and then you will see what I have in mind. Best thing there if I get this to work, then I will easily add USB support to A500 using the same principles. But something is stopping me and it seems that no one can help since everyone things regular way respecting concepts build 15 years ago. There is one sentence I read somewhere why we have to tell Amiga motherboard everything what is going on? This sentence is in my mind all the time, because with FPGA you have choice to fake everything you want beyond regular rules.

[Shadowfire]

I'm not saying that it couldn't be done inside the FPGA, you would need to build another priority encoder and pass through higher priority external IPL* signals to your core.

But there will be no performance improvement by doing this. Your time savings is whatever your IPL* synchronizers are costing (2 cycles) less the added delay through your new priority encoder logic, and those cycles are insignificant compared to the execution time of ANY interrupt service routine (and I seriously doubt that changes with the Apollo core). Please note that I will not debate this point (as I can already see that coming), if you wish you can disassemble/trace the ISR and count instructions. NO CPU IN EXISTENCE has IRQ service response routines that short without having a separate shadow register set for IRQ's (and therefore doesn't need to save/restore processor state).

Asserting the IRQ2* line on the motherboard does NOT impact the machine's performance, IPL* lines are not (directly) tied to bus transactions.

When all is said and done you've managed to save yourself one jumper wire. Ask yourself, is it worth whatever time you're spending on this, to eliminate one wire? If it is, hey, go for it. If it isn't, run the wire and work on more important things.

[pandy71]

Originally Posted by Shadowfire

When all is said and done you've managed to save yourself one jumper wire. Ask yourself, is it worth whatever time you're spending on this, to eliminate one wire? If it is, hey, go for it. If it isn't, run the wire and work on more important things.

But why (please ignore your comment about discussion) - interrupt arbitration is important from mobo perspective however as this is local CPU resource and it not even exposed out of FPGA then why bother mobo with IPL (and this is not only related to single wire).

I think that issue is somewhere in scsi.device - so Majsta missing something that is required from scsi.device perspective.