41CL: Plugging a Module from RAM rather than FLASH?

[burkhard]

In the course of working on the OSX3 problem I described on a different thread, it occurred to me it might occasionally be useful in debugging to upload an old version of a ROM from an old ROM zip file from the PC host → the 41CL. I assumed that once in the 41CL RAM, I should be able to have the MMU point to a RAM address (rather than a flash address) to find that ROM image. In this way, I'd be able to try an old version(s) of something without actually flashing back in old content.

So I tried to do this using clupdate's "upload" command and the YIMP command at the 41CL.
Rather than try OSX3 which is a bank-switched ROM I decided to instead practice with something simpler, CHEMUSER (CHEM) which is a single 4K page / single bank ROM.

PROCEDURE
1. I pulled CHEMUSER.ROM out of rom_files_180928.zip and placed it in the same working folder (Win7) as clupdate.
2. From mem_ref.pdf, it looked like the address range of 0x807000→0x80FFFF was free as User RAM and this would be a safe place for me to play. I hadn't myself knowingly put anything there, so I figured anywhere in there would be OK.
3. I chose 0x80F000→0x80FFFF to import the 4K CHEMUSER
4. In ALPHA, I entered 80F000-0FFF to set both the start address and the total length of file (minus 1)
5. I executed SERINI followed by BAUD48 at the 41CL
6. From a DOS command window on the PC, I ran java -jar clupdate-1.1.0.jar --upload CHEMUSER.ROM COM1 4800
7. I then quickly executed YIMP on the 41CL
8. Everything seemed to transfer OK (all 4K words... 8192 bytes in total), and clupdate reported a CRC of 0x03DE24BE, which was correct per mem_ref.pdf.
9. I decided to run YCRC on what made it into RAM to see if that was correct. I stuck 80F into ALPHA and then executed YCRC. No luck--it was a totally different number.
10. I pressed on ahead and decided to try to plug and run it anyhow. I put "–80F B" into ALPHA in order to point the MMU Page B to a single page starting at RAM physical address 0x80F000 and then executed PPLUG. It gave no error.
11. Running CAT2 I saw nothing new. Running PGCAT, it now showed "B: " (with nothing following the colon) rather than "B: NO ROM". It did not say "B: CHEMUSER" as I might have hoped...
12. I have tried repeating things, but now when I attempt to upload from PC → 41CL using YIMP exactly as before, I immediately get (no delay) the error OVERRUN, which I don't know how to solve.

QUESTIONS
a. Is the basic idea of plugging a ROM into the MMU from RAM rather than FLASH a sound one?
b. Did I do some procedural error?
c. Why is the CRC of the file that left the PC correct, but that stored in RAM not? I know a page of "00" yields a different CRC than a page of "FF". Should I have "initialized" the RAM with all FF or something like that before the XEQ YIMP? (rationale: I'm not sure if YIMP takes everything or just what isn't empty so maybe starting with all FF is better).
d. Why did subsequent re-attempts yield an immediate "OVERRUN" displayed on the 41CL?
e. How do I recover from these persistent OVERRUNs?

Thanks!

[Monte Dalrymple]

(11-02-2018 06:47 PM)burkhard Wrote:  QUESTIONS
a. Is the basic idea of plugging a ROM into the MMU from RAM rather than FLASH a sound one?
b. Did I do some procedural error?
c. Why is the CRC of the file that left the PC correct, but that stored in RAM not? I know a page of "00" yields a different CRC than a page of "FF". Should I have "initialized" the RAM with all FF or something like that before the XEQ YIMP? (rationale: I'm not sure if YIMP takes everything or just what isn't empty so maybe starting with all FF is better).
d. Why did subsequent re-attempts yield an immediate "OVERRUN" displayed on the 41CL?
e. How do I recover from these persistent OVERRUNs?

Thanks!

a. Yes, I debug this way all the time.
b. No, everything looks right. You need to be running in Turbo50 to keep up with
the serial data.
c. Something went wrong somewhere in the transfer. That's what the CRC error
is telling you. No need to initialize the RAM before YIMP if you are transferring
the entire 8k bytes.
d. Something went wrong with the serial transfer and there is a latched overrun
condition.
e. SERINI will clear the latched error condition, but you'll also need to redo the
baud selection after that command.

[burkhard]

(11-03-2018 12:35 AM)Monte Dalrymple Wrote:  b. No, everything looks right. You need to be running in Turbo50 to keep up with
the serial data.

Hi Monte, I definitely did not take any special steps to engage Turbo mode (let alone Turbo50), so maybe this is the source of my problem. It's not automatically built into YIMP, correct? Should Turbo50 be utilized when flashing PC to 41CL as well? I don't think it's mentioned to engage Turbo in the clupdate text file, but maybe I just missed it.

I should mention I didn't see OVERRUN on the initial upload, but only in repeat attempts after the first. The first time it seems to go through without error, but the CRC tests bad.

I had repeated the same bad CRC results (well not sure if it was the same bad number each time, but it was incorrect) a few times, but it was different sessions, with SERINI between them. Now I understand that it was the SERINI between sessions that cleared the OVERRUN error. That's really helpful, thanks!

I'm tied up until Monday unfortunately, but will retry it then with Turbo50.

Thanks!

[Monte Dalrymple]

YIMP does not automatically engage 50x turbo mode.

[burkhard]

(11-03-2018 03:08 AM)Monte Dalrymple Wrote:  YIMP does not automatically engage 50x turbo mode.

Ahh, yes, I see now in the YNFX manual that Turbo50 is recommended for all serial operations. I didn’t do that when I updated the flash either, which now gives me some concern. So far, the CRCs of the modules I have checked all tested OK, but I wonder if there are messed up ones in there as well.

Should I reflash everything?
Or is there a way to CRC check the whole 0x000-0x3FF of flash memory in a single operation?

Thanks!

[rprosperi]

(11-03-2018 12:09 PM)burkhard Wrote:  Or is there a way to CRC check the whole 0x000-0x3FF of flash memory in a single operation?

Thanks!

Yes, the FLCHK? command is used to do exactly that. See page 32 in the CLUPDATE manual; also, the examples in the back of the manual give you the steps leading up to using the FLCHK? command. Also, note that this command actually marks invalid blocks for update, making a repair, if needed, easy to then follow-up with.

Good luck.

[Monte Dalrymple]

(11-03-2018 12:09 PM)burkhard Wrote:  

(11-03-2018 03:08 AM)Monte Dalrymple Wrote:  YIMP does not automatically engage 50x turbo mode.

Ahh, yes, I see now in the YNFX manual that Turbo50 is recommended for all serial operations. I didn’t do that when I updated the flash either, which now gives me some concern. So far, the CRCs of the modules I have checked all tested OK, but I wonder if there are messed up ones in there as well.

Should I reflash everything?
Or is there a way to CRC check the whole 0x000-0x3FF of flash memory in a single operation?

Thanks!

The various commands in YUPS automatically switch to 50x turbo when executing.

[burkhard]

(11-03-2018 03:41 PM)Monte Dalrymple Wrote:  

(11-03-2018 12:09 PM)burkhard Wrote:  Ahh, yes, I see now in the YNFX manual that Turbo50 is recommended for all serial operations. I didn’t do that when I updated the flash either, which now gives me some concern. So far, the CRCs of the modules I have checked all tested OK, but I wonder if there are messed up ones in there as well.

Should I reflash everything?
Or is there a way to CRC check the whole 0x000-0x3FF of flash memory in a single operation?

Thanks!

The various commands in YUPS automatically switch to 50x turbo when executing.

Perfect info, Monte! Thanks so much.

[burkhard]

(11-03-2018 01:20 PM)rprosperi Wrote:  

(11-03-2018 12:09 PM)burkhard Wrote:  Or is there a way to CRC check the whole 0x000-0x3FF of flash memory in a single operation?

Thanks!

Yes, the FLCHK? command is used to do exactly that. See page 32 in the CLUPDATE manual; also, the examples in the back of the manual give you the steps leading up to using the FLCHK? command. Also, note that this command actually marks invalid blocks for update, making a repair, if needed, easy to then follow-up with.

Good luck.

Thanks, Bob! I am on the iPod at the moment, but will check the YUPS manual when I’m at a real computer. That sounds exactly what I was looking for.

[burkhard]

(11-03-2018 02:10 AM)burkhard Wrote:  

(11-03-2018 12:35 AM)Monte Dalrymple Wrote:  b. No, everything looks right. You need to be running in Turbo50 to keep up with
the serial data.

Hi Monte, I definitely did not take any special steps to engage Turbo mode (let alone Turbo50), so maybe this is the source of my problem. It's not automatically built into YIMP, correct? Should Turbo50 be utilized when flashing PC to 41CL as well? I don't think it's mentioned to engage Turbo in the clupdate text file, but maybe I just missed it.

I should mention I didn't see OVERRUN on the initial upload, but only in repeat attempts after the first. The first time it seems to go through without error, but the CRC tests bad.

I had repeated the same bad CRC results (well not sure if it was the same bad number each time, but it was incorrect) a few times, but it was different sessions, with SERINI between them. Now I understand that it was the SERINI between sessions that cleared the OVERRUN error. That's really helpful, thanks!

I'm tied up until Monday unfortunately, but will retry it then with Turbo50.

Thanks!

OK, I tried this again using my same procedure steps at top, but now with Turbo50 set (and verified to be 50 via TURBO?).
Unfortunately, I still get a different YCRC checksum every time I execute the upload from PC→41CL RAM.

When I am doing the upload, the feedback in the clupdate DOS window looks fine:
•It gives the proper checksum,
•opens COM1,
•waits 5 seconds before starting transfer,
•transfers 8192 bytes as 2408 2408 2408 968 = 8192
•closes COM1.

On the 41CL side, I am a little less sure all is OK. I get "RECEIVING", but then after clupdate is done and the host closes the COM port, the 41CL just eventually reports "TIMEOUT". I'm not sure if this is normal or if the 41CL should know that the host has completed and report back "TXFER DONE" or anything like that. The terminal "TIMEOUT" doesn't feel "warm and fuzzy" to me.

The suggested use of SERINI (and it seems an OFF-ON power cycle) did seem to clear the OVERRUNs when they occur. They don't occur every time, though. In any case, I don't see any notice of them having happened until afterward if I retry the YIMP; then the 41CL reports it's in an OVERRUN state.

Thanks, all.

[burkhard]

(11-05-2018 03:55 PM)burkhard Wrote:  OK, I tried this again using my same procedure steps at top, but now with Turbo50 set (and verified to be 50 via TURBO?).
Unfortunately, I still get a different YCRC checksum every time I execute the upload from PC→41CL RAM.

UPDATE!
I think I might have figured it out.
In all the problematic tries I have chronicled, I had plugged the 41CL 9 pin cable directly into COM1 serial port on the docking station of my Dell M4800 laptop. The laptop itself doesn't have an old school serial port, so I only get one if it's in the docking station (also Dell, not an off-brand or anything).

Well, on a lark, I decided to borrow a USB↔Serial Converter and plugged it directly into the laptop (not using the docking station) where it was seen as COM6. I did everything else the same, and voilà, it now works fine. I can YIMP the CHEMUSER ROM into RAM verify its CRC correctly and then PLUG it into a port where it works fine. I even tried it a couple of times to be sure I just didn't get lucky once.

So, no idea why that is, but the extra USB↔serial gadget between the 41CL and the host PC fixed everything.

Hope that helps somebody...

[Monte Dalrymple]

The symptoms sounded like the PC serial port wasn't behaving right... like it was
bursting the bytes rather than pacing them. The 41CL, even at 50x, can't really
handle continuous back-to-back bytes at 4800, but the clupdate program paces
the data so that the 41CL can handle it.