Knowledge about extension bus required

[Paul]

Pre-info: now, end of 2013, I consider myself a QL-Newbee, not very experienced in using English.
In order to be able to make a processor card for myself that plugs into the expansion bus I am trying to collect knowledge in this threat that could help in this task.
For future conservation and as a help for me of course.
If anyone has any knowledge, even if it's obvious, please post it here.

My first information ist about where to buy the necessary plug.
For example you get it at reichelt store http://www.reichelt.de
If you search for "FL-Q 64W" you find the plug.
You pay 2,50€ plus postage for it.
Maybe this is helpful for anybody.
Kind regards
Paul

[Nasta]

Most of what you need regarding the QL expansion bus you can find in the datasheet for the Motorola MC68008 CPU. A complication is that any CPU board needs to be compatible with the protocol that the video ULA uses to access the on-board RAM. Also, unless you remove the internal CPU, you need to use the bus arbitration lines (BRL and BGL) to disable the internal CPU (strap BRL low)

[Paul]

Hi Nasta, didn't dare to hope you would answer in my thread.
Thank you very much and a merry Christmas to you.
I read about the bus arbitatation protocol in the 68EC020 manual and I will post a short form if this here in the next days.
The protocol the ULA uses for video generation is not familiar to me.
I want to use 32 bit wide ram for reading and writing.
In case internal ram area is affected I want the CPU to do 8bit writing as well.
In that case I will need to be aware that the ULA is reading the memory, I guess, because I cannot write to the ram while the ULA reads from it.
Do you have a link to a description of the ULA protocol for me?
Kind regards
Paul.
P.S. I am busy reading Dave's thread about a similar theme, but he is replacing the internal CPU.
I am still rereading your posts there and try to follow your thoughts/input but that is quite difficult for me as I can't remember what you are referring to at the end of the sentence because English is quite difficult for me.

[Dave]

I think the Nasta/Dave thread is very complete. If you have any additional questions... Feel free to ask

Also, Nasta, you have unread mail.

[Nasta]

I think the Nasta/Dave thread is very complete. If you have any additional questions... Feel free to ask

Also, Nasta, you have unread mail.

If so, it has gone missing... let me send you my email via PM, I'll watch out for it

[Nasta]

Hi Nasta, didn't dare to hope you would answer in my thread.
Thank you very much and a merry Christmas to you.
I read about the bus arbitatation protocol in the 68EC020 manual and I will post a short form if this here in the next days.
The protocol the ULA uses for video generation is not familiar to me.
I want to use 32 bit wide ram for reading and writing.
In case internal ram area is affected I want the CPU to do 8bit writing as well.

The arbitration per se is not necessary as the CPUs are not going to be sharing the bus, rather the 68008 is permanently disabled. Basically just pull BRL on the bus low, or better yet remove the 68008 (it uses up power even when disabled). There is a SLIGHT possible advantage to keeping the 68008 in it's socket, and that is that it acts somewhat as a bus terminator. However, a small board with an actual termination network that sits in it's socket would do a much better job and without the power drain.

As for 8-bit, in principle the only 8-bit memory areas that are actually needed are:

1) ROM (00000h..0FFFFh) but this can be remapped into some other memory address (same address bits 0..19, different address bits 21..23 or 31 depending on 68EC020 or full 020 being used) so the address as seen in a regular QL now appears with a prefix, like F00000h..F0FFFFh. The idea being to copy the contents of the ROm to 32-bit RAM at the same address to make it (vastly) faster. Don't forget to disable writing to that area once the ROM is copied!
No special precautions are needed re access speed to this area as long as you take account of the access time of the ROM. Better yet, replace it with a faster Flash or EPROM.

2) IO (18000h..1BFFFh). Unless you want to patch or re-write drivers internal to the OS this needs to be the same as on the original QL.

3) Video (20000h..27FFFh for screen 0 only, 20000h..2FFFFh for screen 0 and screen 1 use).
If you provide a shadow RAM, this area can be write only as far as 8-bit access is concerned, this writes the data into the on-board RAM area used for video, which is enough to make it appear on the screen. However, since most graphics operations actually only alter certain bits of the screen RAM, most access is a read - modify - write instruction sequence, not to be confused with the read-modify-write indivisible bus cycle on 68k CPUs. In the case of graphics, there is a lot of modifying between read and write, many instructions. But, the contents of the video RAM still need to be read. If it is done from the actual video RAM, this will seriously slow down a 68020, though it will still be faster than the 68008 at the same task. One way around this is to shadow this area of RAM with a fast 32-bit RAM at the same address. When the 68020 writes to 8-bit memory, it's actually quite clever and can at the same time write to 32-bit RAM. This will then make a copy of anything in video RAM in the 32-bit RAM. The trick is to let the video RAM dictate the speed (SOOOOW). However, when a read is done, it's actually done from the fast 32-bit copy. Because the 68020 has write buffering (it can go on with pre-fetched instructions internally while waiting for external writes to finish), in most cases the slow write to 8-bit screen RAM will be completely transparent and hence the 68020 is able to proceed at a MUCH faster pace, despite slow QL motherboard RAM access.
Alternatively, both rad and write can be made the usual way which will be slower but still an improvement over 68008 (especially if the 68020 cache is switched on).

For both cases 2 and 3 the video ULA will dictate the speed of access. Although IO addresses are quite fast, one of them is within the video ULA and uses the same rules for accessing as the video RAM.

In that case I will need to be aware that the ULA is reading the memory, I guess, because I cannot write to the ram while the ULA reads from it.
Do you have a link to a description of the ULA protocol for me?
Kind regards
Paul.

The way the 68k CPUs up to 68020 work, you cannot postpone a cycle before it starts, so the way this works is that the CPU starts an access cycle but the ULA keeps it wating for end of access while it's doing it's own access of the RAM. The problem is that the ULA expects the 68008 on the bus so it actually tells the CPU it can finish the cycle well in advance of when it can actually happen, taking into account that there is a delay in recognizing the signal within the 68008 CPU. With a much faster CPU the delay is a lot shorter so this faster CPU will attempt to finish the cycle earlier and this will result in data corruption. This is handled by delaying the DTACKL signal from the ULA to the CPU. The actual delay depends on the CPU clock and bus timing.

Even though Dave is replacing the internal CPU, the rules are the same. You are in fact doing the same electrically, though not like Dave, physically. In any case the 68020 bus must be isolated from the QL bus via buffers because it is not designed to operate at the speeds of a 68020, and will actually prevent the whole system from working at all.

[Dave]

Tell me about it

Happily, the '020 is a bit faster even at the same clock speed as the original QL, though MDV access still trips it up more often than not.

[Nasta]

Tell me about it

Happily, the '020 is a bit faster even at the same clock speed as the original QL, though MDV access still trips it up more often than not.

Try it with the cache switched on
But then you really have to pore through the MDV code and adjust all the timing loops.