Chuck Rock (again)

Discuss ADFFS development and download test releases
PaulV
Posts: 97
Joined: Thu May 02, 2013 8:33 pm
Location: Leicestershire
Contact:

Re: Chuck Rock (again)

Post by PaulV »

JonAbbott wrote:Could it be hardware related...the WE VIDC Enhancer for example? Or a podule?


I can rule out the VIDC Enhancer. It's totally transparent if AutoVIDC isn't loaded and the Arc just has the 24MHz clock so after trying Chuck Rock with AutoVIDC unloaded I can say it's not that.

Podule wise, I've got an EtherLan 500 and Simtec IDE card installed. I'm not sure either of these cards would result in the keyboard being ignored in the way it seems to be...

I should say that when it hangs, the keyboard appears to be still working; certainly the Scroll Lock, Num Lock and Caps Lock are still working, pressing space however which should progress the game to through to the start menu has no effect.

Paul
PaulV
Posts: 97
Joined: Thu May 02, 2013 8:33 pm
Location: Leicestershire
Contact:

Re: Chuck Rock (again)

Post by PaulV »

JonAbbott wrote:Is this a UniBoot module, or did I add it? I'm not sure and will need to check.
AFAICT it's not a Uniboot module...

Paul
JonAbbott
Posts: 2938
Joined: Thu Apr 11, 2013 12:13 pm
Location: Essex
Contact:

Re: Chuck Rock (again)

Post by JonAbbott »

I've been looking at the random issue that prevents swapping to disc 2 and believe its down to ZLib trying to allocate RMA space for its temporary buffer.

There's two ways around this:

1. Add an RMAFree line to every Boot script to ensure there's enough space
2. Switch ZLib to use a DA

Option 2 is the better option in my opinion, provided it can be done in a way that works with ADFFS' implementation of DA's. It will need Jeffrey's assistance before we'll know if this is an viable option.
JonAbbott
Posts: 2938
Joined: Thu Apr 11, 2013 12:13 pm
Location: Essex
Contact:

Re: Chuck Rock (again)

Post by JonAbbott »

Do you think we should fix this before release?

Another nasty option to fix it, would be to increase the RMA by 64kb in the "Boot floppy" code, and change RMAFree / RMASize to always add 64kb on top of the value they've been passed.
Phlamethrower
Posts: 15
Joined: Wed Jun 12, 2013 9:29 pm

Re: Chuck Rock (again)

Post by Phlamethrower »

There are a few problems with switching ZLib to use a DA:

* Firstly, it's a clone of ROL's module. So although the ROOL version could be made to use a DA, the ROL one would be left using the RMA, so you'd run into issues unless you were to force everyone to use ROOL's version (although if you're only running into RMA-related issues on Arc hardware, where ROL's module won't be present, then I guess that's a moot point)
* The ZLib module is designed to be used by multiple clients at once. So how big should ZLib decide to make its DA? If the aim is to make sure ZLib never fails due to the RMA size being locked, then it will have to create its dynamic area at a size which is large enough to service all clients in parallel. And since there's no ZLib-imposed limit on the number of clients...
* ROOL's version of the module is just a wrapper around the standard zlib library, which itself is a separate component in the build system which gets used by more than just the ZLib module (e.g. compressed ROM images use it). So from a code perspective it'll be a bit ugly to have one version which uses DAs and one which uses standard C malloc/free (i.e. the RMA), as well as making it a bit trickier to update to the latest zlib version in future.
* The zlib library doesn't provide any function to allow you to determine ahead of time how much temporary working memory is going to be required for a compression/decompression operation. So there'd have to be a bit of tuning done to pick the right amount to preallocate for a particular build of the the library. I think the amount of memory required also varies based around the compression level used, so in some cases preallocation of a fixed buffer may end up wasting memory.

However, all is not lost. There are several things that could be done:

* If you use the stream interface (ZLib_DeflateInit, ZLib_InflateInit, etc.) then you can use your own memory allocation routines by setting the zalloc and zfree members of the stream struct (offsets 32 & 36, respectively). This will give you control over 99% of the memory allocations.
* The remaining 1% of memory allocations come from the code which tracks task association; for each 16 streams which are active it allocates approx 264 bytes from the RMA to track task associativity. At the moment, if no streams are active, it won't have any 264-byte blocks allocated; this introduces a chance of failure when a client comes along. It would be trivial for me to change it so that it allocates one initial block on startup and keeps it around until the module is killed, so that you're at least guaranteed to be able to create 16 streams before it will attempt any RMA allocation.
* There's also nothing stopping you from ditching the ZLib module and using the zlib library directly - that way you'll be in full control over what's going on, and can even remove the dependency on CLib if desired (all that the core compression/decompression routines require are malloc, free, memset and a division function). If all you're interested in is decompression, then you'll get a bit of a memory saving too due to dead code stripping. The decompression stub that the ROM images use is 26K, but the ZLib module is 71K (yes, the file size of the module is 46K, but it's a squeezed module, and is 71K when un-squeezed)
JonAbbott
Posts: 2938
Joined: Thu Apr 11, 2013 12:13 pm
Location: Essex
Contact:

Re: Chuck Rock (again)

Post by JonAbbott »

For the time being, I'll implement the RMA +64kb botch as it's a trivial change.

Longer term I think I need to look at a tailored module that doesn't use CLib, as that's a dependency I'd love to drop. Where can I get a copy of the ZLib module source, and the C compiler needed to compile it?

EDIT: Now implemented, updated ADFFS module and full adffs215.zip on the dev site. I've tested against Chuck Rock, which now switches disc correctly.
Phlamethrower
Posts: 15
Joined: Wed Jun 12, 2013 9:29 pm

Re: Chuck Rock (again)

Post by Phlamethrower »

ZLib module source: http://www.riscosopen.org/viewer/view/b ... mmer/ZLib/ (BSD licensed)
zlib library source: http://www.riscosopen.org/viewer/view/m ... /Lib/zlib/ (zlib licensed). This version of the source has been tweaked so it can be compiled using Norcroft (ROOL's compiler), and to add a couple of features needed for the ZLib module.

Note that the above two probably won't build in isolation; they'll be dependent on a few other bits of the ROOL build system. So if you're going to try building them it's probably best to grab the DiscDev source archive (http://www.riscosopen.org/content/downl ... s-tarballs) as that will contain everything needed to build it (the ZLib module gets built as part of the standard disc image).

Official zlib library source: http://zlib.net/ Should compile out of the box with GCC. However I've only ever built a CLib-free version of zlib using Norcroft, so I'm not sure of the exact steps that would be needed when using GCC.

Norcroft: http://www.riscosopen.org/content/sales/dde
GCC: http://www.riscos.info/index.php/GCC
JonAbbott
Posts: 2938
Joined: Thu Apr 11, 2013 12:13 pm
Location: Essex
Contact:

Re: Chuck Rock (again)

Post by JonAbbott »

Thanks for all that info, I've downloaded everything and will try the GCC route - as it's free!

I note PackMan on the Pi doesn't have the package source for GCC - is that an oversight, or does it not work on the Pi?

EDIT: I've given up already, GCC needs ELFLoader and all the links to it are dead.
Phlamethrower
Posts: 15
Joined: Wed Jun 12, 2013 9:29 pm

Re: Chuck Rock (again)

Post by Phlamethrower »

Download the sharedlibs package - ELFLoader is included in that. Here are some links which work, the ones on the GCC site do seem a bit screwy:

GCC4 - http://www.riscos.info/packages/Develop ... .html#GCC4
SharedUnixLibarary - http://www.riscos.info/packages/Library ... nixLibrary
SharedLibs - http://www.riscos.info/packages/Library ... SharedLibs
SharedLibs C support - http://www.riscos.info/packages/Library ... aredLibs-C

I'm not sure why GCC wouldn't be included in the Pi package list. I'm not sure if I've ever used it on my Pi, but it runs fine on my BeagleBoard, so it probably is just an oversight.
JonAbbott
Posts: 2938
Joined: Thu Apr 11, 2013 12:13 pm
Location: Essex
Contact:

Re: Chuck Rock (again)

Post by JonAbbott »

Thanks, GCC is now working.

The make files use amu_machine, which I'm guessing is an alias to something. I had a read of the builder docs, but that doesn't mention it, so I'm going to guess there's another package I need to install.

I have the four packages you've listed installed.
Post Reply