F18A programming, info, and resources

[matthew180]

The F18A is in-stock and can be ordered. There are quite a few people waiting this time around, so note that it may take me 4 to 5 days to get your board(s) shipped. I will fulfill orders as fast as I can.

[matthew180]

Spending the weekend getting caught up on F18A orders... Funny to think some of these will go all over the world like the U.K., Austria, Czech Republic, and Canada just to name a few.

 

Eleven are for the CV, twelve for the 99/4A.

 

[+Schmitzi]

+1

[+jedimatt42]

+1

 

That's funny +1 is still a win for the 4A.

 

-M@

[+Schmitzi]

Yes, I have just ordered my 2nd one

[BJGuillot]

So... I finally got up courage to try to update my F18A and it seems to have failed.

 

Current rev is 1.5, trying to bump it to 1.8.

 

It seemed to start out OK, but then got stuck in the same spot for about 5 minutes (see attached picture). I pressed space bar to see what would happen and the TI reset back to the title screen.

 

When I start EA to go run the DSK1.F18AUPD program again, it seems to load for a few seconds, and then immediately jumps back to the title screen. I tried to re-start it five times just for good measure, but it just keeps reseting.

 

I have not power cycled the machine yet, and fear that if I do, it will be dead.

 

Is there any last minute advice anyone has for things to try before I reset the power and find out it's dead?

 

[i am using a NanoPEB (NANOPEB-SIO V1), loaded from the EA cartridge. The F18A dsk update file had been loaded into volume 40 and I mounted DSK1 to volume 40.]

 

 

[BJGuillot]

Quick update: I'm not sure what happened, but on about the 8th time trying to re-run F18AUPD, it let me get back into the program. Unfortunately, it keeps dying with the "FILE CRC" error in different places. The furtherest it has gotten so far is about 25% through the bargraph (usually fails much sooner). I'll keep trying to run it as long as it lets me.

 

Does the FILE CRC mean there is an issue reading the file off of the NanoPEB, or that it read a chunk of the file, wrote it to the F18A and than it fails verification from what was expected in the file?

[Asmusr]

As far as I remember the updater program is reading the entire file into an unused part of the flash memory on the F18A. Only if it succeeds without any CRC errors it is copying the file into the real part of the flash. So there should be no problems power cycling until that critical moment when the flash is written for real.

 

If you have a speech synth between the TI and the nanoPEB try removing it. Also try to clean the connector on the nanoPEB.

[BJGuillot]

Thanks for the reply. After several attempts, I finally did a "what the heck" moment and tried power cycling it, and it still comes up. I've tried a few things, taking the speech synthesizer out of the loop, even tried using a second NanoPEB I had. I've tried swapping the CF cards between the different NanoPEB's. And per your suggestion, also tried cleaning the connectors (though the look fairly pristine). No joy. Always seems to die in a different place with the "FILE CRC" error. At least the F18A is not dead.

 

Assuming I don't get it solved on my own in the next several weeks, I might bring the console to Fest West and see if it is able to update with someone else's NanoPEB or CF7. Maybe there is just something wrong with my NanoPEB's (or the console itself). I have ran into issues in the past with intermittent file corruption on the NanoPEB disks when saving large files with EA's editors, so maybe I just have duds (or a bad console). I only have one F18A, so am not able to try it on a different console.

[+InsaneMultitasker]

I haven't tried using my nano V1 to update my F18A but I have been experiencing some lockups loading programs and even while viewing text files with the included disk manager. Today I inspected the nano closely and found a stray, small chunk of solder that looked like it might have been bridging two of the memory chip leads intermittently. I'll do some more testing this week with larger files, as there is another possibly related experience here: http://atariage.com/forums/topic/261650-nanopeb-v1-rs232/#entry3706789 Hopefully Fest West can help you to find the cuprit..

[Tursi]

I've been working a lot on the updater for the last few days - you're safe at the point you are seeing the hang. It goes like so:

 

-checksum the loaded program and make sure it's correct

-verify F18A exists

-verify that the files exist on disk

 

There's no output for the above steps unless they fail.

When they are done, you finally get the 'PRESS P TO PROCEED'.

 

-erase staging area in the flash ("Clearing Sector")

-copy the disk files to the staging flash ("Staging Data") - each block is CRC'd as it's loaded.

 

Up to this point, no permanent changes have been made. Any failure to this point will not damage the F18A.

 

-the actual firmware sectors are cleared on the flash ("Clearing sector")

-the data is copied from the staging sectors to the firmware sectors ("Updating")

-the final written data is verified ("Verifying data")

 

A failure in these steps may be a problem, so this is the point where it's not safe to power cycle.

 

-the staging sectors are erased ("Cleaning up")

 

This is just a cleanup phase.

 

So yeah, if you're seeing FILE CRC, it means there's a problem reading the file from disk. Maybe your downloaded disk is corrupt?

[+Schmitzi]

I slightly remember there was an issue before, F18A-Update and NanoPeb/DSK...? slightly

But I cannot find it in the forum here. Too many hits

[BJGuillot]

So yeah, if you're seeing FILE CRC, it means there's a problem reading the file from disk. Maybe your downloaded disk is corrupt?

 

I suppose that's possible. It was originally in a zip file though, so I would assume there would have been a zip error when unzipping the file if that were the case. Also, since the FILE CRC error seems to occur at different places each pass, I wouldn't think the original file itself was corrupt, or it would have failed in the same place every time. The "F981" that originally appears on the screen when the loader first starts, is it just reading that from a spot in header or trailer of the file, or is it computing that checksum in real time? If it's computed, it seems odd that it almost never seems to fail computing the F981, but then fails in different spots when reading in the blocks.

[Tursi]

The program checksum is calculated at startup, but that's not the file CRC. The program checksum only verifies the loading software itself. So yeah, it sounds like you have a problem with the loading of the bitstream file itself.

[+arcadeshopper]

there is a bug in the nano that conflicts with the f18a that is not a f18a model.. I had this exact problem and he patched his device to not use vdp ram the f18a needs

your boot screen on your ti should say nanopeb v1 f18 or like that.. if it does not then probably that's your issue ..

 

Greg

Edited March 5, 2017 by arcadeshopper

[Tursi]

Does anyone have a dump of the F18A enhanced NanoPEB DSR? I'm curious what he actually changed.

[+arcadeshopper]

He added a delay to the startup to let the f18a finish before doing nano stuff

 

Sent from my LG-H830 using Tapatalk

[matthew180]

Sorry for being late to reply. The updater tries really hard to not brick your F18A, which is why it checksums everything. There is only one critical part of the update when copying the bit-stream from the staging-area of the Flash to the boot-area of the Flash, and that copy is done totally by the GPU is are very fast. The slow part is when the updater is reading each block from the disk, doing the CRC, and copying to the VRAM. Any failure during the staging and you are safe to reboot (as you found out).

 

I test the updater on real hardware using a CF7+ and have never had any problems. As others have mentioned, there does seem to be some problems with the other variations of the CF7+ (i.e. the NanoPEB). The mentioned "special delay" added to the NanoPEB, for the F18A's benefit, is confusing to me. The F18A configures itself before the 99/4A is done with its power-on reset, so what is it that the NanoPEB is doing before the system is out of reset? The system reset is available on the side-port and, IMO, any expansion should use and/or honor that signal.

[+arcadeshopper]

He added a delay to the startup to let the f18a finish before doing nano stuff

 

Sent from my LG-H830 using Tapatalk

 

It think the f18 initializes too fast for nanopeb it's expecting it to be a 9918 and take a little more time..

[Tursi]

It think the f18 initializes too fast for nanopeb it's expecting it to be a 9918 and take a little more time..

That doesn't make any sense, the 9918A doesn't have an initialization time.

 

All the theories and guesses can be eliminated in about 20 minutes work with a dump of the DSR.

[+arcadeshopper]

That doesn't make any sense, the 9918A doesn't have an initialization time.

 

All the theories and guesses can be eliminated in about 20 minutes work with a dump of the DSR.

 

I suggest you talk to Custodio then, I was unable to update the f18a with that nano installed, many errors.. replacement worked great.

 

Greg

[Tursi]

I suggest you talk to Custodio then, I was unable to update the f18a with that nano installed, many errors.. replacement worked great.

We didn't say that the Nano update didn't do something, we said we wanted to know exactly what it did. Why are you being so argumentive over this? Analyzing what code was changed to make it work could provide insight that would improve the F18A. But that needs the exact answer, "added a delay" isn't specific enough to act on.

[+arcadeshopper]

Not arguing Mike I'm just passing along what I was told and my experiences. You don't like the answer and say it doesn't make sense. I assume you're going to figure it out. I can only encourage you to do so or speak to him. I can't answer for him.

 

Sent from my LG-H830 using Tapatalk

[marc.hull]

 

It think the f18 initializes too fast for nanopeb it's expecting it to be a 9918 and take a little more time..

IIRC it's the other way. The F18 isn't ready when the nano is setting up some VDP memory (at least that was the conversation at the time.)

 

This jives with what Matthew has said about some systems needing their power up/reset extended by upping the cap value etc.

[Asmusr]

The issue about the nanoPEB - F18A compatibility makes me wonder: Is it possible for a device on the side port to write to VDP RAM directly, bypassing the CPU?