RetroBSD

I am thinking about implementing the EBI as a driver.

I am in two minds about how to do it. I could either:

1. Have a master "ebi" device, then individual devices that hang off it specifying the addresses, etc, or
2. Have up to 4 individual "ebi" devices which specify the addresses, and you attach devices to them.

Basically a choice between something like:



and:



In the former you configure the whole bus and it's the device's responsibility to carve it up. In the latter you carve the bus up and then attach devices to the carved up chunks.

I'm not sure which would be the best way to go. Thoughts?

Hi, by the way - been a while

_________________
Why not visit my shop? http://majenko.co.uk/catalog
Universal IDE: http://uecide.org
"I was trying to find out if it was possible to only eat one Jaffa Cake. I had to abandon the experiment because I ran out of Jaffa Cakes".

I think the first would be better for generic drivers, but i don't know what EBI is

Hi Matt,

Not sure what EBI is and is not. That said, I too have been thinking of some sort of bus.

It would be nice to just plug something in, custom hardware or whatever and have it 'just' appear on the system / web.

There lots of ideas out there. Is there something simple, easy to understand, etc.

It seems to me that a few wires go out in parallel from the 'system', including power. I plug whatever into this 'bus' and it is ready to send and receive data.

Some simple Unix type idea that 'just works'.

Glad to see your note.

Wiz

The EBI is the External Bus Interface - basically an 8086-like system bus. There's 4 dedicated CS pins for 4 address blocks (you can of course subdivide it manually if you like). So there's basically 4 devices, and you get to specify where within the EBI memory block those 4 devices are mapped, and how big a memory area they consume within that block.

So it's basically a question of do I define the bus and embed the device configurations inside the target device drivers, or define the devices and pass those to the target device drivers...

Or there is a third option - I could define just one device that covers the whole EBI memory block and divide it up manually...

_________________
Why not visit my shop? http://majenko.co.uk/catalog
Universal IDE: http://uecide.org
"I was trying to find out if it was possible to only eat one Jaffa Cake. I had to abandon the experiment because I ran out of Jaffa Cakes".

Hi Matt,

Oh I see. The CS problem seems to always need more wires.

Not sure I see a 'simple' solution. The problem area seems to be that the main CPU would like a simple test that a given peripheral needs attention and thus a dedicated wire?

The early systems I have looked at memory or i/o mapped this bit of information. So the main CPU didn't have much overhead and could be doing more useful work rather than polling flags.

Lots of fun .

Wiz

Maybe I will go for the third option actually - keep it all in software. Just define one single CS block that covers the whole memory area and allow as many devices within it as you like. Makes it more flexible. Then it's down to the device driver itself to define the memory area it's working with. It'd make the control of the EBI module somewhat simpler - just turn it on and leave it.

_________________
Why not visit my shop? http://majenko.co.uk/catalog
Universal IDE: http://uecide.org
"I was trying to find out if it was possible to only eat one Jaffa Cake. I had to abandon the experiment because I ran out of Jaffa Cakes".

EBI driver for pic32mx or mz?

_________________
Pukao Hats Cleaning Services Ltd.

Two clues for you:

1. We are in the forum "Board index » LiteBSD - Unix for microcontrollers with MMU » Kernel and Drivers"
2. The MX doesn't have EBI

_________________
Why not visit my shop? http://majenko.co.uk/catalog
Universal IDE: http://uecide.org
"I was trying to find out if it was possible to only eat one Jaffa Cake. I had to abandon the experiment because I ran out of Jaffa Cakes".

Hi Matt,

I finally got around to reading about EBI on the PIC. Seems to me it might be pretty useful for i/o types of things. Along the lines of what I was talking about earlier. I want a fast way that the PIC can read a memory location and tell whether the peripheral has its flag set, has new data, etc.

It is not clear to me how fast EBI really is and also it seems like a HUGE waste of pins on the PIC.

That said some sort of 8 bit address, 8 bit data might make some sense but also appears to be reverting the the many parallel wires of the 8088 era? I am not sure what advantage this really gives to a product?

For me the idea of plugging in some custom gizmo and having it appear in the PIC memory and also on the web 'automatically' in some simple way would be pretty useful when doing custom stuff.

Then I could add 'drivers' to post process this raw data into other perhaps more useful forms. Raw temp. becomes degrees F comes to mind.

Some PICs are pretty cheap so maybe they could be used for a cheap 'foundation module'? It would be especially nice if they could be soft programmed and reprogrammed when attached. That seems pretty far from possible at this point?

Lots of fun .

Warm regards,

Wiz

The main use I would get out of the EBI is connecting a TFT screen with a 16-bit parallel (8086) interface. Connecting a big chunk of RAM would also be nice.

The advantage of the EBI over, say, SQI (which gives similar memory mapping functionality) is that of speed. SQI gives a 4x speed improvement over SPI (but only half duplex, but that's fine), and EBI gives a 4x speed improvement over SQI.

The slew rate on the IO pins of the PIC32MZ limits them to about 50MHz (ish) operation, which is the limit the SQI interface can run at, and I guess the EBI will be about the same.

The memory mapping side of things, of course, also means that code can be executed out of external RAM or ROM (though of course not as fast as internal memory, but faster than SQI).

At present I'm using the PMP for high speed TFT screen access, but I'd like to switch to using the EBI (which uses the same pins) at some point to see if it gives me faster and more fluid access (reading data with the PMP is a bit of a pain, it's always one transaction out - you read the byte you got during the previous transaction, not the one from the current transaction).

_________________
Why not visit my shop? http://majenko.co.uk/catalog
Universal IDE: http://uecide.org
"I was trying to find out if it was possible to only eat one Jaffa Cake. I had to abandon the experiment because I ran out of Jaffa Cakes".

Hi Matt,

Sounds like a nice idea .

I have been thinking more along the lines of a cheap fone with browser as the LCD interface to our PICs. Still have yet to get it running usefully though.

I have been wondering what kind of peripheral an old laptop with a cracked screen might be for our retrobsd/litebsd boxes?

I have a stack of them. I suppose we all do? Maybe we could get a cluster going in some easy way?

Maybe mine bitcoin or do some other compute job?

Lots of fun .

warm regards,
John

There's no point in mining bitcoins any more. The electricity costs more than the value of the coins.

What to do with a laptop with a broken screen? Plug a monitor into it and install Linux.

_________________
Why not visit my shop? http://majenko.co.uk/catalog
Universal IDE: http://uecide.org
"I was trying to find out if it was possible to only eat one Jaffa Cake. I had to abandon the experiment because I ran out of Jaffa Cakes".

Hi Matt and Pito and Serge,

I am thinking of putting retrobsd on MZ. Seems like it isn't too hard. Any comments or suggestions.

From what I can see MZ still has a lot of RAM compared to the other obvious choices?

Wiz

Go for it!

_________________
Pukao Hats Cleaning Services Ltd.

Hi Pito,

Got some sketches that might work.

Now onto the PCB.

Been a long time....

Kicad or proven old tools?

I wonder what Serge is up to these days?

Lots of fun .

Wiz

Serge is well and blogging at his blog..

_________________
Pukao Hats Cleaning Services Ltd.