Econet for Atom

[hoglet]

I did an exhaustive search and found quite a few more instances of *N.

Code: Select all

Found *N. in AIR ATTACK file AIRATTA
Found *N. in AIR ATTACK (JS) file AIRATTA
Found *N. in BLITZ file BLITZ
Found *N. in CHESS file COPY
Found *N. in CHESS file ERROR
Found *N. in GALAFORCE (C)(32K) file CGALA
Found *N. in GALAFORCE (C)(32K) file MGALA
Found *N. in GALAFORCE (M)(32K) file CGALA
Found *N. in GALAFORCE (M)(32K) file MGALA
Found *N. in GOKKAST 1 file GOKKAST
Found *N. in GOKKAST 2 file GKKST2
Found *N. in HARD HAT HARRY (32K) file HARRY
Found *N. in JACKPOT (32K) (R) file JACKPOT
Found *N. in JET SET MINER (C) file CMINER
Found *N. in JET SET MINER (C) file MMINER
Found *N. in JET SET MINER (M) file CMINER
Found *N. in JET SET MINER (M) file MMINER
Found *N. in REPTON (32K) file LOADER

I'm thinking it might be best to try to add this command to the Econet ROM.

Dave

[KenLowe]

I'm confused. Why does *N. fail with Econet, but *NETMON works?

[hoglet]

I'm confused. Why does *N. fail with Econet, but *NETMON works?

The Atom Econet ROM contains a built-in *NOTIFY command, and it will run this if passed *N.

The error is actually then because no parameters are supplied.

Dave

[KenLowe]

I'm confused. Why does *N. fail with Econet, but *NETMON works?

The Atom Econet ROM contains a built-in *NOTIFY command, and it will run this if passed *N.

The error is actually then because no parameters are supplied.

Dave

Ah, ok. That makes sense. Would it not be better to modify the files you identified to use *NONOM in place of *N. - instead of updating the ROM?

[hoglet]

Ah, ok. That makes sense. Would it not be better to modify the files you identified to use *NONOM in place of *N. - instead of updating the ROM?

Maybe it would be better, but there are a couple of gotchas...

There also may be instances in machine code files that I've missed. These are harder to find, because you would search for just <N> <.> <0D> (i.e. no star). This will have a huge number of false positive matches, due to N. being a abbreviation for NEXT in BASIC. Doing it in the ROM would fix these as well. But it needs people to be using the modified ROM, which I agree is bad.

I'd also need to somehow (manually?) check that each instance was a pure BASIC program with no machine code appended to the end. Because this will increase the size of the BASIC program by three characters.

Edit: Although on reflection, I might be better to just replace *N. with REM as this is the same number of characters. Ideally I'd update the archive build scripts so the patching is done automatically, but only in the Econet builds.

Dave

[KenLowe]

Hi Ken,

*N. is *NOMON

GALAFORCE also checks the AtoMMC joystick in the joyinit routine at #4CF8 and the joyget routine at #4D16.

You can edit the CGALA file but you must use *SAVE 2900 5563 CE86 to save it.
Be sure that the basic loader doesn't exceed #3000 because the assembler game starts at #3000.

You can find all sources of my conversions here: https://github.com/oss003?tab=repositories

Greetings
Kees

Aaargh. This is fighting me every step of the way!

I'm not sure if this is a PiFS issue, or a NFS issue. Anyway, I'll try a more simple *SAVE filename start end and then manually adjust the .inf file that gets created with the correct exec address.

Edit: Ok, so that simpler *SAVE with less parameters, followed by manually adjusting the exec address in the .inf file worked, but it shouldn't be this difficult!!!

[oss003]

Don't know if this is also working for the Atom: *SAVE CGALA 2900 +2C63 CE86

[hoglet]

I'm not sure if this is a PiFS issue, or a NFS issue.

I think it's a PiFS issue, as the *SAVE command works for me...

This is with Level 3 file server version 1.26 that has the Atom commands added back in.

Note, the second parameter needs to be the end address + 1 (i.e. the range is exclusive of the specified end address)

Dave

[KenLowe]

Don't know if this is also working for the Atom: *SAVE CGALA 2900 +2C63 CE86

Yes, the Atom also supports the +len field. But that's still not working correctly if I include the exec address! I've posted the logs in the PiEconetBridge development thread:

viewtopic.php?p=380691#p380691

[KenLowe]

I'm not sure if this is a PiFS issue, or a NFS issue.

I think it's a PiFS issue, as the *SAVE command works for me...

I agree. I've posted some logs in the PiEconetBridge development thread.

This is with Level 3 file server version 1.26 that has the Atom commands added back in.

Hmmm. Not sure how the PiFS deals with Atom commands. I don't even know how it would determine that the commands are actually coming from an Atom. Hopefully it'll make more sense to @cr12925! I wonder why the Atom commands were removed in the first place???

Note, the second parameter needs to be the end address + 1 (i.e. the range is exclusive of the specified end address)

Yes, I noticed this the other day when I was saving the patch for MMINTRO. When using the *SAVE command you provided, the PiFS was saving one extra byte, so I had to shorten the end address by one byte. PiFS is definitely not replicating what the 1.26 server is doing!

[hoglet]

Hmmm. Not sure how the PiFS deals with Atom commands. I don't even know how it would determine that the commands are actually coming from an Atom. Hopefully it'll make more sense to @cr12925! I wonder why the Atom commands were removed in the first place???

The Beeb will never ask the fileserver to parse *LOAD *SAVE or *CAT commands, as these are built in to NFS.

The only reason for these commands is to support the Atom, so in theory the syntax should be consistent with the Atom.

Yes, I noticed this the other day when I was saving the patch for MMINTRO. When using the *SAVE command you provided, the PiFS was saving one extra byte, so I had to shorten the end address by one byte. PiFS is definitely not replicating what the 1.26 server is doing!

Both the Atom and the Beeb treat the end address in this way I think, so I would image all Acorn file servers do as well.

The Atom doesn't actually allow the +length form of SAVE, but I think there would be no harm if the Econet file server allowed it. The Acorn file servers don't though.

I've got the automatic patching of abbreviated formats of *NOMON working now, so that will be included in the next dev build of the archive.

(BLITZ in the above list was a false positive, cause by 810N.)

Dave

[KenLowe]

Yes, I noticed this the other day when I was saving the patch for MMINTRO. When using the *SAVE command you provided, the PiFS was saving one extra byte, so I had to shorten the end address by one byte. PiFS is definitely not replicating what the 1.26 server is doing!

Both the Atom and the Beeb treat the end address in this way I think, so I would image all Acorn file servers do as well.

This is what I see when I try to save using the end address format from my Atom (excluding the exec part for just now, which causes other issues!). This is different to what you saw on the L3FS. The beeb works fine with the PiFS so, again, this looks to just be an issue with the way the PiFS is dealing with the Atom SAVE function.

Saving from Atom to PiFS

As a complete aside, I'm so looking forward to getting a new keyboard working (I'm waiting for prototype bits to arrive). I'm really struggling with the original keyboard. Some keys are very sensitive, and others are a bit intermittent - sometimes they just work, and other times they need a bit of persuasion. And I don't have a working numeric '6' key stem, so any time I need to type '6' I've got to short out the two springs with my long nose pliers! I guess I could solder on a switch in the short term.

[KenLowe]

Right, I think I've found out what's going wrong in the bridge. It appears that the reload and exec addresses are being parsed the wrong way round:

viewtopic.php?p=380731#p380731

I'll try fixing that this evening, and see what difference it makes!

[hoglet]

Ken,

I've rolled up all my fixes so far into new development snapshot:
viewtopic.php?p=380775#p380775

If you can get the *LOAD parsing issue on PiFS fixed, I would expect most titles to work now, and any that don't can be logged as defects.

I've resolved the reliability issue I was seeing, where maybe one on 20 file loads would fail. It turns out an Econet clock of 200KHz is just a bit too fast, at least for my Atom. Reducing this to 150KHz make it totally reliable.

I've also done diassemblies of each of the library commands, with a few to updating them to the Exxxx release:
https://github.com/hoglet67/AtomEconet/ ... y/commands

I'm still not happy we have a good story here for accomodating different versions of the Atom Econet ROM, as these commands are really tightly coupled.

Dave

[KenLowe]

Ok, it took me a while to figure out that the service runs a copy of the bridge that's been saved to the /usr/sbin directory. I couldn't work out why the changes I made weren't working. Once I copied the latest compiled version over to /usr/sbin, things started to work:

PiEconetBridge running with a patched fs.c file

I'll create a pull request for these changes.

[KenLowe]

I've rolled up all my fixes so far into new development snapshot:
viewtopic.php?p=380775#p380775

If you can get the *LOAD parsing issue on PiFS fixed, I would expect most titles to work now, and any that don't can be logged as defects.

Thanks for doing this. Unfortunately, I'm having issues unpacking the zip file. I had the same issue with the development one you provided the other day.

Firstly, I tried to extract the zip on my PiFS. The files would unpack ok, but the .inf generating utility produces an error.

Next up I tried JGHs ZiptoInf utility on my Windows laptop, but again this generated errors. Note that the .inf files generated by ZiptoInf are not actually compatible with PiFS, but that's another topic altogether! However it does give an indication that something may not be quite right with the archive.

Both of these utilities work fine with the older v12.0 of the software archive. Any thoughts as to what's going wrong here?

I've resolved the reliability issue I was seeing, where maybe one on 20 file loads would fail. It turns out an Econet clock of 200KHz is just a bit too fast, at least for my Atom. Reducing this to 150KHz make it totally reliable.

I'm also running my clock at 200KHz (5us period / 1us mark), but I've not seen any reliability issues - yet! I'm using my bridge to generate the clock signal.

[hoglet]

Both of these utilities work fine with the older v12.0 of the software archive. Any thoughts as to what's going wrong here?

That's strange, because there hasn't been any changes to the ZIP generation Java code since v12.0. But it's possible I'm using a more recent JVM now, which conceivable might affect the ZIP generation.

Is there any clues from the error messages as to what the problem is?

I'll do a bit more testing tomorrow.

Dave

[KenLowe]

Both of these utilities work fine with the older v12.0 of the software archive. Any thoughts as to what's going wrong here?

That's strange, because there hasn't been any changes to the ZIP generation Java code since v12.0. But it's possible I'm using a more recent JVM now, which conceivable might affect the ZIP generation.

Is there any clues from the error messages as to what the problem is?

I'll do a bit more testing tomorrow.

Dave

It's a bit odd. The script that runs on the Pi is a PERL script. I'm not familiar with PERL, but I can just about work out that it's checking the first 4 bytes of the file, looking for PK\3\4 and failing at that point:

Code: Select all

while(1)
{

  # Get the header.  At least we hope it's the header

  sysread($fh, my $header, 4);

  # This is the start of the central directory, which is after all the
  # data, and isn't needed.  So we can stop here
  last if $header eq "PK\1\2";

  # This better match
  die "Section does start PK<03><04>: $header\n" unless $header eq "PK\3\4";

This is the error I get when I run the script:

Code: Select all

pi@raspberrypi:~/econetfs/0PIBRIDGE-00 $ perl parse_acorn_zip.pl ASA_V12.01_ECONET.zip | bash
Section does start PK<03><04>: ▒▒u▒
pi@raspberrypi:~/econetfs/0PIBRIDGE-00 $

The odd thing is if I load the zip file into a hex editor the first 4 bytes look fine:

Code: Select all

c:\Users\Ken Lowe\Desktop\ASA\AtomSoftwareArchive_20230110_1544_12.01_ECONET.zip
0000 0000: 50 4B 03 04 14 00 08 08  08 00 85 7D 2A 56 00 00  PK...... ..à}*V..
0000 0010: 00 00 00 00 00 00 00 00  00 00 09 00 18 00 41 53  ........ ......AS

Ignore the fact that the file names are a bit different, I renamed the file when I copied it over to the Pi. I'm using the original file name in the Windows hex viewer.

The ZiptoInf questions if it's a 'Damaged ZIP file?'

[hoglet]

Thanks for that example.

Yes, I'm seeing the same with parse_acorn_zip.pl

This gives me something to go on...

Dave

[hoglet]

Hmm, as well as PK<03><04> entries, in the latest zip file there are also PK<07><08> entries, which is the signature for a "spanned archive". It's these that are confusing parse_acorn_zip.pl

I'll need to investigate what's going on here, but it's probably a result of me using a later JVM.

[KenLowe]

Ah, ok. So it's looking at more than just the first 4 bytes of the file! That's what was confusing me.

[hoglet]

Ah, ok. So it's looking at more than just the first 4 bytes of the file! That's what was confusing me.

This does seem to be down to changes in the Java libraries.

Rolling back from openjdk-17 to openjdk-11 seems to have fixed it, and the parse_acorn_zip.pl script is now happy.

I've re-packed the 12.01 release and re-uploaded it to github:
https://github.com/hoglet67/AtomSoftwar ... tag/V12_01

Dave

[KenLowe]

This does seem to be down to changes in the Java libraries.

Rolling back from openjdk-17 to openjdk-11 seems to have fixed it, and the parse_acorn_zip.pl script is now happy.

I've re-packed the 12.01 release and re-uploaded it to github:
https://github.com/hoglet67/AtomSoftwar ... tag/V12_01

Thank you. That's fixed it for me here too. It's also now working with JGHs ZipToInf again.

[KenLowe]

Argh! There's always some issue to deal with! I've just powered up my Atom and it's no longer booting correctly. It displays ACORN ATOM, but then just hangs. Previously it would have also reported the AtoMMC. If I press CTRL BREAK, I get the command prompt, and from there I can successfully enable Econet by typing ?#BFFE=2 and pressing BREAK. If I try switching back to AtoMMC with ?#BFFE=6 and then pressing BREAK, it hangs again.

Where should I look next?

[hoglet]

Where should I look next?

When you switch over to Econet is everything reliable? i.e. Can you boot the Archive menu and run large games?

On the quite frequent occasions when I have had this problem, it's been a bad connection on PL8 and/or an IC pin piercing the 20 way IDC cable between the Atom and the AtoMMC. Just wiggling the cable usually sorts it for a week or two.

But I would expect this would also break Econet.

Dave

[KenLowe]

Where should I look next?

When you switch over to Econet is everything reliable? i.e. Can you boot the Archive menu and run large games?

On the quite frequent occasions when I have had this problem, it's been a bad connection on PL8 and/or an IC pin piercing the 20 way IDC cable between the Atom and the AtoMMC. Just wiggling the cable usually sorts it for a week or two.

But I would expect this would also break Econet.

Dave

Yes, Econet is working just fine. Archive and games load fine.

I reprogrammed the YARBB flash in case that had become corrupt, but that didn't seem to make any difference (I should have done a verify before programming it, but in my haste, I forgot).
I then unplugged my Econet / AtoMMC board, but that didn't make any difference. I'm not sure if that would cause it to fail, anyway.
I then plugged the Econet / AtoMMC board back in (accidentally, whilst the Atom was still powered up), pressed BREAK, and it started working again!

I've power cycled a couple of times now, and it's rebooted ok ever since.

I wonder if this might be to do with the fact that I'm missing the transistor on the Econet IRQ line???

[hoglet]

I wonder if this might be to do with the fact that I'm missing the transistor on the Econet IRQ line???

I don't see how that would cause these symptoms.

It does sound like a bad connection.

I have never in ~8 years of using AtoMMC had the PIC become corrupted.

The AtoMMC ROM will hang if the AtoMMC hardware is not present, so that part is normal. It will also hang of the AtoMMC hardware doesn't respond to the heartbeat command with alternative #55/#AA values.

If it happens again, do a Ctrl-BREAK then type in the following program:

Code: Select all

10 FOR I=1 TO 10
20 ?#B400=#FE
30 PRINT &?#B400'
40 NEXT
50 END

You should see alternating #55 / #AA values.

Dave

[KenLowe]

If it happens again, do a Ctrl-BREAK then type in the following program:

Code: Select all

10 FOR I=1 TO 10
20 ?#B400=#FE
30 PRINT &?#B400'
40 NEXT
50 END

You should see alternating #55 / #AA values.

Will do, thanks.

With the Atom running again, I was able to test a couple of games from Econet more thoroughly. Firstly, Manic Miner is now loading properly. I still have issues with the Galaforce games when trying to load from my PiFS, but that's down to the fact that PiFS doesn't support quotation marks being used around the file name. If I remove the quotation marks in lines 80 & 90 then it loads fine. The *N. issue is now fixed.

Thanks!

[KenLowe]

I've just powered the Atom up, and it's frozen up once again. After a CTRL BREAK:

Screen grab

[hoglet]

Reading back the high byte of the address (&B4 in this case) is what you see when nothing is driving the data bus. So something is definitely not right with the AtoMMC side of things.

Does the PIC activity LED flash once when you press BREAK?

Dave