Firmware 0.8.0 released

[Jim Brain]

I have placed the formal 0.8.0 firmware release on jbrain.com for the
2.0 uIEC/IDE+CF, 2.3 uIEC/IDE+CF, all uIEC/CF units and all uIEC/SD
units. Here are the relevant links:

uIEC/CF, uIEC/IDE+CF v2.0 HW, uIEC/IDE v2.3 HW:

http://www.jbrain.com/pub/cbm/hw/uIEC/uIEC-firmware-0.8.0.bin

uIEC/SD HW

http://www.jbrain.com/pub/cbm/hw/uIEC/uIEC3-firmware-0.8.0.bin

To use, place the appropriate file in the root directory of the primary
drive (on uIEC/IDE, it will be the IDE master drive), and reboot your unit.

v 0.8.0 supports the following enhancements:

- direct sector access of the real storage device
- ignore DEL files in file_open
- drive mapper
- EXOS V3 fastloader support
- Implement Dreamload emulation
- RTC support
- Multi-file scratch
- Copy command
- Large buffer support
- Final Cartridge 3 freezed file fastloader support
- D71/D81 disk image support
- parse FSINFO sector for faster FAT32 free space calculation
- partial REL file support
- SD support for uIEC/IDE+CF

I encourage folks to upgrade their units to 0.8.0 as soon as possible.
Many uIEC/SD and recent uIEC/IDE users have 0.8.0PRE1 on their units,
but that is an interim release and should be replaced with this bugfixed
release.

The C128 autoboot bug has also been fixed, though it was not an issue
with the code. I accidentally left some debugging turned on in the
firmware, and the timing issues caused the bug.

Jim

--
Jim Brain, Brain Innovations (X)
br...@jbrain.com
Dabbling in WWW, Embedded Systems, Old CBM computers, and Good Times!
Home: http://www.jbrain.com

[Daniel Kovacs]

Now that the uIEC supports .d81 disk images, I wonder if the GEOS D81 disk
image from cbmfiles.com will work?

[Pete Rittwage]

Hi Jim,

I copied the file to the root of my CF card and it doesn't seem to do
anything. It powers up normally, no flashing, and it still says
"V.0.7.2.1" when I query the error channel.

I searched to see if it needed renamed and didn't find anything.

--
-
Pete Rittwage
http://rittwage.com

[Jim Brain]

Pete Rittwage wrote:
> Hi Jim,
>
> I copied the file to the root of my CF card and it doesn't seem to do
> anything. It powers up normally, no flashing, and it still says
> "V.0.7.2.1" when I query the error channel.
>
> I searched to see if it needed renamed and didn't find anything.
>
>
>

Is your CF card set to master (is the jumper block attached on the board)?

[Jesper]

Hello,

Sorry for replying Petes question but:

> Is your CF card set to master (is the jumper block attached on the
> board)?

I'm having the same problem as Pete, and yes - my CF card is set to master.

/ Jesper

[Pete Rittwage]

Jim Brain wrote:
> Pete Rittwage wrote:
>> Hi Jim,
>>
>> I copied the file to the root of my CF card and it doesn't seem to do
>> anything. It powers up normally, no flashing, and it still says
>> "V.0.7.2.1" when I query the error channel.
>>
>> I searched to see if it needed renamed and didn't find anything.
>>
>>
>>
> Is your CF card set to master (is the jumper block attached on the board)?
>
> Jim
>
>

Hi Jim,

The jumper was not installed, so I put one on it. It still doesn't
update for some reason.

Mine is a uIEC/CF only, if that makes any difference. That jumper block
(the one with just two pins is what I assume you mean) has a
hand-soldered wire that goes to the small chip on the board. This wire
appears to still be intact.

[Pete Rittwage]

Also, it's a 4G CF card that has been working fine. Single FAT32 partition.

[Jim Brain]

OK, for Pete and yourself (and it seems like someone else was having issues).

See if the following file works:

www.jbrain.com/pub/cbm/hw/uIEC/uIEC-firmware-0.8.0PRE2.bin

replace the regular bin file with this one, and the let me know if it works.  (save off the current firmware file, you may need it again)

Jim

[Jim Brain]

Pete Rittwage wrote:
> Hi Jim,
>

> The jumper was not installed, so I put one on it. It still doesn't
> update for some reason.
>

No, you cna remove that jumper. Those pins on the switches.

> Mine is a uIEC/CF only, if that makes any difference. That jumper block
> (the one with just two pins is what I assume you mean) has a
> hand-soldered wire that goes to the small chip on the board. This wire
> appears to still be intact.
>

Try the other firmware file I just sent out, and let me know. I can;t
imagine the bootloader is missing, but things sometimes happen.

Jim

[Jim Brain]

Pete Rittwage wrote:

> Pete Rittwage wrote:
>
> Also, it's a 4G CF card that has been working fine. Single FAT32 partition.
>

That might be the issue. Do you have a smaller FAT16 card you can try?

Jim

[Pete Rittwage]

That worked. It updated to 0.8.0PRE2 with no problem.

[Pete Rittwage]

I also detected you would next ask to put the final 0.8.0 firmware on
the card. I did and it upgraded to that version fine this time.

[Glenn Holmer]

On Mon, 2009-03-16 at 19:44 -0500, Pete Rittwage wrote:
> Pete Rittwage wrote:

> > That worked. It updated to 0.8.0PRE2 with no problem.

> I also detected you would next ask to put the final 0.8.0 firmware on
> the card. I did and it upgraded to that version fine this time.

Same here. I had discussed this with Jim on IRC; this worked on the
first try (both files).

--
"After the vintage season came the aftermath - and Cenbe."
Glenn Holmer (Q-Link: ShadowM) http://www.lyonlabs.org

[Jim Brain]

Yes, I was going to suggest that next.  The firmware images are the same in functionality, but it's best to put the right one on.

Technical details:

The bootloader scans all files in the root of the primary drive (master drv on IDE units, the SD card on SD units, the CF card on CF-only units.)  For every file:

1. If the filesize is not 124KB exactly, it returns
2. If the file device ID does not match the one configured in the bootloader, it returns (the CF and IDE share a device ID, since they use the same HW, but the SD verson has a different device ID)
3. If the current firmware's version number is not 0 and the file's version number is not 0 and the current version is greater than or *equal* to the file's version, it returns (this is what caused the issue.  Before the "PRE" functionality was created, which automatically sets the version of the file to 0, the firmware 0.8.0PRE1 has version of 0.8.0, which matches the current production code version)
4. If both versions are 0, and the CRC is the same, return (this is to prevent the bootloader from constantly updating the image if someone leaves the test firmware on the disk)
5. If the code is still executing, flash this image into the system.

The '*equals*' in step #3 was designed to prevent the code from re-imaging on every reboot if the user left the image file on the root of the drive.  However, the #4 step was not in the code at the time.  I think now, maybe it makes more sense to:

1. Check for 124K
2. Check Device ID
3. If both versions are not 0 and file version is < current version, return
4. If CRC is same, return
5. reflash.

That said, the issue should never occur again, as all non production firmware releases will have version = 0 from this point forward.

Well, I'm glad that fixed the issue.    Have fun with 0.8.0 and let the list know of any issues.  With 0.8.0, Ingo has added raw disk access, so folks can try their hand at mkfat32fs or mkfat16fs and the like. 

Jim

[Jesper]

Hello,

> Well, I'm glad that fixed the issue. Have fun with 0.8.0 and let the
> list know of any issues.

Worked fine for me too, thanks!

/ J