exxos's Atari, Amiga & retro forum

It is a shame that this didn't work. I think the trick is figuring out how to disable the onboard CPU and not letting it interfere but I don't think anyone has released an open source version of this trick...

alenppc wrote: 22 Jan 2019 19:23 It is a shame that this didn't work. I think the trick is figuring out how to disable the onboard CPU and not letting it interfere but I don't think anyone has released an open source version of this trick...

Yet ;)

We know for a fact that it is possible, and I bet all the pieces are out there to be found. Prepare for quite a long post. Here's what I've found so far:

The StackExchange post I linked to earlier pointed to that the easy method of using the halt signal wouldn't work, and that you instead have to manage to let the new CPU take over as the bus master.

According to the 68000 User's manual there are two ways of doing this; 3-wire and 2-wire. The 2-wire one uses only Bus Request (_BR) and Bus Grant (_BG), while the 3-wire one uses Bus Grant Acknowledgement (_BGACK) as well. I'll focus on the 2-wire method here, as it's... simpler.


Waiting for current cycle to complete should mean (guess) waiting for _AS and _DTACK going high, but I wonder if that's really necessary in this case, as I'm thinking of asserting _BR permanently. Granted, this documentation only applies to the CPU, and not to the Amiga as a whole, so there might be further steps that need to be taken, like asserting a system reset. I don't really know how much the other chips on the Amiga does on their own on startup.

majsta's blog posts on designing the Vampire 600 confirms that this should be a valid approach:

majsta wrote:Those are the stages:
1. First Finite State Machine started.
2. Complete system started with ALVC devices disabled.
3. Amiga system restarted using counters.
4. Finite State Machine who is dedicated for 3-wire bus arbitration enabled.
a) FSM check reset signal and count bus cycle.s
b) FSM asserts BR
c) FSM waits to current cycle is complete (AS and DTACK negated, BG asserted) and asserts BGACK
d) FSM release BR.
e) FSM activate reset signal who enables mini CPU who will write to color register.
4. First FSM check that reset is enabled.
5. ALVC devices are programmed to support Address Bus, AS, LDS, UDS and RW signals as output FPGA signals. In the same stage AS, LDS, UDS and RW pulled high.
6. Write dff180 to Address Bus (Amiga color register).
7.Pull AS low to indicate that valid address is placed and RW low indicating write cycle.
8.Set ALVC devices dedicated for Data Bus as output, check counter and regarding on state of counter write on Data Bus 0f00 for red and 000f for blue color enabling and disabling LED.
9. Pull UDS and LDS low to indicate that valid data is on the bus but if DTACK is low release AS, UDS, LDS and leave RW for another cycle.
10. Pull RW high and set ALVC devices dedicated for Data Bus for input FPGA signals. Restart counter and back to stage 6.

I don't know if I can pull this off, at least not on my own, but I'll sure give it a try. I really would like to solve it with 74-class logic so that the solution should be accessible to anyone. It will be easier implementing 74 logic in a CPLD at a later stage than the other way around.

The plan at the moment looks as follows:

1. Connect the A600 _BR to ground.
2. Hold the DIP64 _HLT and _RST lines low.
3. Power up.
4. Wait for A600 _BG to go high.
5. Release the DIP64 _HLT and _RST.

Dunno if it'll work :)

Edit: This is getting more advanced than a simple prototype for connecting the TF53x to the A600, but I'll keep posting stuff in this thread if it's ok with Stephen. It's somewhat terriblefire related, right? :)

8 Bit Dreams wrote: 28 Dec 2018 22:50 This adapter is indeed very interesting! What about mkl's or Kipper's 8MB ram cards? Will these work with it? If Yes - this will give A600 owners a cheap FastRam...

The adaptor doesn’t work as intended yet, but it might work for fastram cards. If you’d like I could send you an adaptor for testing, as I don’t have any such RAM card.

kludge wrote: 27 Jan 2019 15:22

8 Bit Dreams wrote: 28 Dec 2018 22:50 This adapter is indeed very interesting! What about mkl's or Kipper's 8MB ram cards? Will these work with it? If Yes - this will give A600 owners a cheap FastRam...

The adaptor doesn’t work as intended yet, but it might work for fastram cards. If you’d like I could send you an adaptor for testing, as I don’t have any such RAM card.

Yes, please, will test and report (will send You PM now)

Hey, I was _almost_ mentioned on stream ;)

This isn't really put on hold, just creeping along veeeery slowly. Haven't done much more work on it since the last post, as other projects rose up.

A thought: If all the required signals are connected to the bus CPLD of the TF530/534, I suppose the bus arbitration could be implemented there. And bus arbitration is done to take over from the on-board CPU on the CD32 with the TF330, right?

Otherwise it should be possible to add some logic, or maybe a XC9536XL or similar to my adapter board so that no custom firmware is needed. I was contacted by Edu Arana regarding this today, so I guess something could be done :)

Would it be possible to implement the bus arbitration in the bus CPLD or does it miss vital signals?

If you want, Stephen, I could send you an adapter for testing. As if you didn't have enough stuff to test.

terriblefire wrote:

What would be the preferred way of keeping the TF53x idle while setting up the bus arbitration; asserting RST and/or HALT or not letting the 7 MHz system clock through?

I’m starting to think that a CPLD is way overkill for this, and 74-logic might be as well. Should be possible with a few transistors and resistors...

kludge wrote: 19 Mar 2019 12:15

terriblefire wrote:

What would be the preferred way of keeping the TF53x idle while setting up the bus arbitration; asserting RST and/or HALT or not letting the 7 MHz system clock through?

Holding reset low is probably the best. Nothing will happen when this is the case. There isn’t much need to sequence this in my experience. Just hold the 68K BR and bgack lines low and you’re good. It will never come out of reset

terriblefire wrote: 19 Mar 2019 13:21 Holding reset low is probably the best. Nothing will happen when this is the case. There isn’t much need to sequence this in my experience. Just hold the 68K BR and bgack lines low and you’re good. It will never come out of reset

Since I don't have a TF53x going quite yet I had to test with a regular 68k DIP64. Tied the A600 68k BR and BGACK to ground, and nothing happened. Did the same thing earlier but with the "2 wire method" instead of the "3 wire method" so then I only asserted BR. The results were the same, though.

Now I tried reseting the DIP64 68k manually as well, but still nothing. Maybe the DIP 68k needs to have its BG and BGACK pulled high? Right now they are floating, because I'm lazy.

If you want an adapter to set fire to I could send you one, either just the PCB or populated with PLCC socket and headers for the DIP64.

Maybe I f:ed up making the footprint for the inverted PLCC, but I don't think so. I need to look at this again when I'm less tired, but I will probably have to admit that for now I know to little about this. :D

Maybe You messed up pinout since plcc is upside down!? Please double check!

A6oo is indeed getting not much love, its small, it fits on every table, many people are tired from unstable Furia yet don't want to spend too much cash on Vampires, they just want a good working accelerator...
have also A6oo lying around here without any use (since i do not own any accelerator card for it)..
hope Stephen will accept Your offer and take an adapter or at least take a look on the schematics..with knowledge he got on CD32 will do such adapter easily..