Kickflash experiences

[mboehmer_e3b]

My godness. While I spent two weeks in hospital, my friend Ratty is back again... well. I didn't expect fair behaviour from Elbox, so what.

This is what you want others to believe. You know why? Because random read access in E3B cards is so messed up that it is unusable.

Ah. Really. Unfortunately your idea of the access method used in ALGOR / ROMulus is wrong. Anyhow, in the outcome of this "unusable design" both ALGOR and ROMulus clearly won the AmigaPlus comparison test... they wrote that it even "outclassed the competitors" (page 27).
Good result for a "messed up and unusable design", don't you think?

Just watch the Algor board and see connection of address lines. Well, it is enough to read the description of the connector, to which Romulus is connected. This connector has only 5 Amiga address lines connected!

Haha. This is a good one. You know, ROMulus is located on both the HIGHWAY clockport and the expansion port.
I'm astonished that you made such a mistake while doing backward engineering.
Please download the HIGHWAY manual from my website and do your homework properly.
And, for exercising mathematics, clockports have four (4) address lines, namely A[5:2]. You know, one less than you have fingers on one hand.

In the second case, reading the selected location of the Flash memory requires a prior sending information to CPLD about the window number and the address within the window.

Moreover, a good one. Get back to Elbox laboratory and do some more backward engineering. You are wrong here, sorry.
Oh, BTW, doesn't a PCI solution from a Polnish company use exactly the banking technique you are describing here?

Algor pro IS vapourware, according to your own vapourware definition. Until today Algor pro is not available.

So the box here which arrived from the production line with ALGOR PROs must be a hoax, eh? Unfortunately I had to spend some time in hospital, so everything is delayed.

Finally, Ratty, you didn't improve. Badly done, your research. You should do better...

Anyhow, some remarks on the eFlash, just by looking at the picture in the AmigaPlus magazine:

- If speed really matters, how does it come that it doesn't support Zorro III burst mode (which is highly recommended in the spec for memory boards)? /MTCR and /MTACK lines are both missing.

- Why are the busdrivers for the data bus missing? The Macronix MX29F400 chips are not providing the required 64mA driving power on low side (according to the MX data sheet they make 2mA).

- Why is no /BERR handling included? This is mandatory for all Zorro II and III cards after the spec, to protect both expansion cards and motherboard logic from bus contention situations.

If I take the last two points, missing data bus drivers and no bus error protection... that's a "clean" design... in a heavily loaded backplane a single bus error condition could simply blast the eFlash memory chips...

One might even say that with these two clear violations of the Zorro III spec the eFlash4000 is not a Zorro III card, but something else.

Michael

[mboehmer_e3b]

Ah. One thing I did forget to comment on, Ratty:

Eflash 4000 is a clear Flash memory design. The whole eFlash memory is directly available in the Amiga Zorro III area. It opens the possibility of using the eFlash 4000 card not only during the computer start like other Flashes but also as the non-volatile Flash disk with fast random access.

.

Well, the MX FlashROM chips are 64kB sectored (besides the boot section, which is (32/8/8/16 kB). If you implement a random access file system there, guess what happens?

For changing one (1) bit of data, you have to do the following:

- read the whole 64kB FlashROM to a RAM location
- alter the bit you want to change in RAM
- do a SectorErase command on the FlashROM (timed by the FlashROM, cannot be influenced or made faster)
- write the whole 64kB RAM mirror back to flash, and in this case, word by word, with data bus polling after each write access to verify that the FlashROM did finish its cycle.

So. Let's count some cycles (you may use your fingers here, but keep in mind, five at one hand):

- 64*1024 read cycles from FlashROM
- 64*1024 write cycles to RAM
- 1 read cycle from RAM
- 1 write cycle to RAM
- 64*1024 read cycles from RAM
- 64*1024 write cycles to FlashROM
- 4*64*1024 read cycles from FlashROM (assuming that you have to poll four times only, which is optimistic)

This yields in approx 512k cycles; let's assume that the CPU is only occupied with changing your one bit, and nobody else likes to do something on the Zorro III bus. Take the time of 250ns for one access to both FlashROM and RAM, and 100ns in between cycles (the fastest Zorro III board I know of needs 190ns for one write access, namely the Picasso IV with Buster 11). So one access costs us 350ns.

We will need for the whole operation, if we only calculate the read/write times, forget about the self timed sector erase operation and omit all housekeeping of the filesystem, in total a time of 0.18sec. For writing one (1) bit.
In case of changing one byte we end up with random access times in writing of 0.18 Byte/s, or 180 miliByte/s

Pfuh. Looks like something completely useful... and this is what you are calling "fast random access"?

In case of the ALGOR / ROMulus, we have Atmel FlashROMs with 256byte sectors, and an internal write buffer of 256byte RAM, which means that you can do a "normal" write of 256bytes to the FlashROM, followed by a ProgramSector operation.

You may do the calculation for this case (change one byte in random access) as some exercise. And you may take your shoes of, if you run out of fingers, and effectively double your data bus width by this hack

Michael

[mboehmer_e3b]

Seriously, I doubt that were such a random IO mechanism designed that it would be implemented in such a way. Unless made by MS or something.

It's not MS, unfortunately, it's originating from the FlashROM technology itself. You must erase one sector before you can write to it, as you (in simple words) discharge all cells to 0xff when erasing, and charge single cells when writing. You cannot discharge single bit cells, so FlashROMs are somehow like old EPROMs - they were discharged by UV light, and charged while programming, with no possibility to remove the stored charge from the floating gate (but exposing the whole die to UV light).

Surely the mirrored area would be kept in RAM and then the rom area updated after a sufficient amount of it had been modified, or some time interval elapsed, whichever happened sooner.

In principle this would work, but then you have a RAM disk, and you will be better workig with RAD:
With the possibility to crash the machine at any time, or switch it off or reset it, you cannot gurantee data integrity with such a RAM / FlashROM mirroring.

In embedded systems such things are sometimes done, but only with small sectored FlashROMs. There are Linux versions supporting such jffs file systems.

With FlashROM cards things are different, as they usually have a serial interface and allow erasing single cells. This technique is also used in modern FlashROM based microcontroller chips.

Michael

[mboehmer_e3b]

Is there the slightest risk that this thread might get back on topic this year?

As long as Ratty is doing his FUD war and trolling here... I think no, unfortunately.

You know, talking about facts is not his issue. Just look at his answers: he ignores all facts, all questions and is repeating his assumptions and rumours. And as he is running out of arguments he is returning to the Poseidon key issue which is *completely* off topic here.
It is sad to see such things here, but obviously one has to live with him.

Michael

[mboehmer_e3b]

Well, so some more feed for the troll. Or better, some more facts to ignore for him... but as he was so kind to give a link to the datasheet which is falsifying his arguments (I love this word, even if its from Elbox

These chips work in the 16-bit mode then. In this mode MX29F400 sectors need 4k, 8k, 16k or 32k writes , but never 64k as Michael assumed.

In 16bit mode you get to a doubled worst case rate of 360miliByte. Fine.
Unfortunately only the data strobe line /DS3 is connected  to the eFlash4000, so you will have to write both FlashROM chips everytime (the /DS1 which would be needed to distinguish between word and long word accesses, i.e. between writing the one or the other FlashROM).
Almost all sectors (7 of are 64kB sized, so the 8kB, 16kB and 32kB sectors are not really relevant.

For those technically interested: take a look at Dave Haynies Zorro III spec. You can find pinouts of the Zorro III connector there to check for yourself, namely /BERR and /DS1 lines.

As you properly noted, he completely forgot that data caching may be used in such situations.

Using data caching is possible, as I also stated, but in a situation like the Amiga system, where no memory protection is available, increasing the sync times between RAM to FlashROM transfers will increase speed of the disk, but also the danger of inconsistencies between RAM and FlashROM. And with decreasing this sync time you end up in my calculation.

If you want to experience what I mean: just write a bunch of data to your system hard disk and reset while writing. You may do such jokes with a journaling file system, but not conventional ones.

Michael

[mboehmer_e3b]

Hm. Anyone seen Ratty lately? Did he run out of arguments, or has he been hit by a double dose of reality?  :lol:

Michael

[mboehmer_e3b]

Hi Adolescent,

just a remark on this, to clarify the situation (and sorry for the long posting).

Although, maybe you're not as forward as Chris and the E3B Buddies, you are quick to attack tjaoz's freedom of speech just as you are exersizing yours.

Well, for me it is a difficult situation. On the one hand I try to keep out of discussions like these, but on the other hand I cannot sit and watch like someone (in this case Rat aka tjaoz) is attacking my work and my products by just spreading things which are not the truth. Even more, he did state that he doesn't own any of these products he's talking about, so he's talking about something he has no direct knowledge about.

If you take the time (decide your own, if it is worth it) and look closer on his posts, it is always the same way of proceeding:

- advertise Elb*x products
- claim that every competitor's product is of inferior quality
- give some pseudo technical explanations
- cite from former threads and mailings, but getting cites uncomplete or out of context

If this doesn't work out, then there are some further tricks:

- refer to bad Chris Hodges disabling his key
- claim that I'm the bad guy behind this action
- claim that I do attack him
- tell that people try to cut his freedom of speech

And, like this thread showed nicely again: if you confront him with clear questions on an issue, which doesn't fit into his point of view (in this case, technical "specialities" of some hardware), these questions are completely being ignored, and in turn, he returns to the last four points (key issue, bad Mr. E3B). Or, he will swap his opinion completely (like here, first advocating a superior fast FlashROM disk on the eFlash, then proposing to use IDE to CF adaptor which is far better).

If I look back in time, I see that I could have avoided all this troubles, discussions and FUD war by asking Chris Hodges not to open the Poseidon stack to other Classic Amiga hardware solutions. It was developped on E3B hardware from the beginning (SUBWAY, HIGHWAY), with strong cooperation and quite some work involved. Simply as that.
We decided (and I emphasize the word "we" in this context) to try a common effort and avoid the situation like it was with CyberGraphics and Picasso96, offering all Amiga Classic users one solution. We have now, as all Amiga Classic USB solutions are supported by one USB stack, and I would say that users did benefit from this quite a lot.

The outcome for me is not so amusing, as you can see on this thread. Especially one competitor offering a product which would be completely useless without Chris and my work is now hitting back whereever possible. For me, I have learned my lesson on this

Michael