RISC OS on IGEPv2

Another question: I tried to get darkwood going but the game informed me that the gamemodes module is not 32bit compatible. I then proceded to download Gamemodes2 module from the ROOL site, renamed it Gamemodes and replaced it in game, but it still said it wasn’t 32bit compatible. Is it possible that some of the modules in binary form on the ROOL website are only 26bit?

Are you sure it’s not Darkwood itself that RISC OS is complaining about? As far as I know it isn’t 32bit compatible, so would probably only run under Aemulor (and you’d have to wait for Adrian to finish the new version of Aemulor first).

I’d really like to see what RISC OS can do with this 1GHz chip¹... so I’ve been trying to run Dare Devil Denis by Michael Foot²! Not being too good with MakeModes, I’m struggling to define a 640×256 screen mode. (BTW, I was able to successfully fudge a 640×512 for Chuckie Egg!) Mode 15 is unavailable via the boot sequence. However, it is available (albeit letterboxed) by booting the ROM image to the Supervisor prompt. This sort-of permits the game intro to run, although the attempt at Mode 7 doesn’t completely work. However, starting the game produces the following errors:

Screen mode not available

Postmortem requested
fc1414ac in anonymous function
519d0 in anonymous function
2e324 in anonymous function
16ce4 in anonymous function
1a048 in anonymous function
1cf40 in anonymous function
1d8b8 in anonymous function
fc15f164 in unknown procedure
50c40 in anonymous function
fc15f164 in unknown procedure
  Arg2: 0x0002f274 193140 -> [0xe1a0c00d 0xe92ddbf0 0xe24cb004 0xe24dcc49]
  Arg1: 0x00065dbc 417212 -> [0x6e757221 0x67616d69 0x00080065 0x00065dc8]
fc131958 in shared library function
80e4 in function ___init

Do we have any MDF experts here? (And/or people who can shed light on the other errors – I’ll probably contact the author too… or try recompiling the source myself.)

Edit: And I get the same “Module ‘GameModes’ is not 32-bit compatible” error when I try that.

¹ I know the IGEP is available at 1GHz but here I’m using a BeagleBoard-xM

² Sorry, but I grew up on games like this :-)

After a bit of searching for an alternative GameModes etc. I then tried TIB. Jeffrey, your FP241W MDF allows the game to run, although the Mode 7 intro is displayed less correctly (i.e. monochrome and with an unexpected font) than from the no-boot setup described above.

You’ll need a 640×500 screen mode for teletext modes to work.

You’ll need a 640×500 screen mode…

Thanks – I missed that from your MDF. I now see there are a couple on the 6502Em site too.

Edit: And on the late Paul Vigay’s site too.

Hi folks,

Has everyone survived the festive period? I plan to try and sort out the last of the issues with the Devkit’s NIC in the next few weeks. Any other IGEPv2/OMAP news?

No IGEPv2/OMAP news from me.

I may do the wireless for IGEP next. If there is interest?

I don’t even own an IGEP, but I’m certainly interested in RISC OS getting wifi support.

[Edit: There’s a BB post too.]

To do this properly would need a wireless module that handled all the userland wireless interaction. With SWI’s for signal strength, WEP/WPA key handling, station finding etc. All the stuff that doesnt get done by DCI. Then we could have individual modules for each wireless card that could use this API and develop desktop apps to use the wireless module.

Lots of work.

If/when any developers are willing/able to look into this, I’ll be able to test with the above TB dongle on a BeagleBoard. (And potentially on the TB v1 itself, although that could require soldering a serial cable to it.)

I’m going to continue the wireless discussion here: http://www.riscosopen.org/forum/forums/5/topics/574

In other news.. I’m confident i’ve found the issue i had in the DevKit8000’s NIC. I just have a few minor issues and some cleanup and its good to go.

My acceptance test was: -

(a) to hold up against a flood ping from a linux box for 10 minutes with out loosing more than 5 packets. (b) to transfer a 500mb file from an NFS server and back with no corruption.

The issue I was seeing was a 32/16bit buffer rollover. I’ve been able to use 32bit transfers on the NIC but it means i need to rewind the input buffers. This worked fine except on buffer rollover. Seems to be working perfectly now.

3:26am… sleep time.

Is there anyone else out there with a DevKit8000 who can test my changes? Obviously I cant ask Tank as I have his board!

Nailed the DM9000 NIC Driver.

$ sudo ping 192.168.0.22 -f
PING 192.168.0.22 (192.168.0.22) 56(84) bytes of data.
............^C
--- 192.168.0.22 ping statistics ---
2400492 packets transmitted, 2400480 received, 0% packet loss, time 1101018ms
rtt min/avg/max/mdev = 0.284/0.419/84.186/1.286 ms, pipe 7, ipg/ewma 0.458/0.305 ms

Next!

Nailed the DM9000 NIC Driver.

Well done, Stephen! “Next” should be fun!

EtherGEP version 0.45.

Update for IGEPv2 and DevKit8000

http://www.vavi.co.uk/EtherGEP045.zip

Feedback would be helpful.

Hi Stephen, I tried the flood ping test with EtherUSB on a couple of different chips, one Asix and the other Moschip. In both cases, they kept up for 20-30 seconds or so and then became overwhelmed. After another 10 seconds or so, the devices both refused to so anything until I reset them by restarting EtherUSB.

Given that this happens with two different chips, my guess is that I’m not doing something which needs to be done w.r.t. USB. However, I’d just like to check to see if you have experienced anything similar, as this would point to problems with other parts of EtherUSB.

That sounds very familiar to the issue I was seeing with the DM9000.

The issue i had was that eventually (after 20-30 seconds) a TX was initiated by the OS while a TX write loop was happening causing a TX overlap. This caused the chips’ TX buffers to get out of step and was sending crap.

The way I found to diagnose this was

ping address -i 0 -s 500

This then actually told me when a ping reply packet was not as expected (and printed the portion of the reply that was broken – which showed an ARP header in the middle of my ping reply) but otherwise behaved like a flood ping.

The fix was to put a mutex lock/guard on my TX loop and return &err_tx_blocked if the card was already at work transmitting.

Not sure how relevant this is as you arent using interupts as far as I can tell but you could probably use the diagnosis method to some effect.

I also recommend wireshark to look and see what the device is trasmitting when it gets into a bad state.

Jeffrey,

What are the chances of being able to put a generic SDIO interface into the HAL? So we can talk to mmc type devices over specific GPIO pins? This would be very useful for pretty much any OMAP stype board?

Thoughts?

I expect Jeffrey or Dave Higton will have a more informed viewpoint than me, but as I see it the problem as usual is to determine how much of the SD(IO) driver code goes in the HAL and how much lives outside of it. The most obvious point to split it from my (still quite limited) understanding is when the code moves from the host driver initialisation to actually sending commands to the SD card using that host driver. But Dave’s code already does a lot more than that, out of necessity, to get the CMOS file read from the card. Perhaps there can be some overlap? If the HAL were to present a higher-level API to the OS than this, the code in there could end up getting pretty large, I think.

For my 2 cents worth…

Data access via SDIO should be abstracted to the HAL. Everything else should be done in “userland”. So if i want to talk to some GPIO pins using an SDIO protocol i should be able to do that via HAL calls.

Should I be able to choose which GPIO pins i am talking to via the calls? open to debate.

IIRC SDIO doesnt need interrupts? but if it did these should also be handled by the HAL.

Getting this into the HAL would make life soooo much easier for all sorts of beagle/igep applications.

I haven’t really looked at the SD/SDIO specs, but from what I’ve picked up so far it looks like it would make sense to have the HAL SDIO API handle things at the SD protocol level. I.e. “send this command”, “check if card present”, “set card voltage”, “check write protect pin”, etc. A RISC OS “SD manager” module could be placed in charge of all the SD interfaces, and contain the logic necessary to initialise cards. Once a card is detected/initialised it can then send out a service call to allow card type specific drivers to take over control. E.g. an SD/MMC filesystem would listen out for any standard SD/MMC cards being inserted, an SDIO wifi driver would listen out for a list of known SDIO wifi modules (perhaps interrogating each card itself if SDManager isn’t able to report enough type information), etc. These driver modules would probably interact with the cards via SDManager SWIs rather than talking to the HAL directly.

Fitting something like that into the HAL should be quite easy. However I’m not really sure why you’d want to use GPIO pins to talk to an SDIO device (or whether it’s feasible to implement SDIO via GPIO at all) – why can’t you just use one of the MMC interfaces? AFAIK all OMAP boards expose at least one of the spare interfaces on the expansion headers.

Thanks for that Jeffrey,

The OMAP doesnt have nearly enough IO for my liking. So just thinking ahead. For now just using the MMC interfaces is fine.

What are the chances of being able to put a generic SDIO interface into the HAL? So we can talk to mmc type devices over specific GPIO pins? This would be very useful for pretty much any OMAP stype board?

First, the OMAP 3530 has three dedicated SD/SDHC/MMC interfaces on chip. You don’t need to dedicate any GPIO lines to the task (OK, strictly you appear to need one if you want to detect the write protect signal from the SD connector). It also has a very large number of GPIO lines, although only a small number of them appear to be taken out to connectors on the BeagleBoards, IIRC.

If you really did try to talk to MMC type devices via GPIO, you would find it somewhere between extremely difficult and impossible; the SD/MMC protocol is only partly documented for zero cost, and OMAP’s inbuilt SD/MMC interfaces implement all the lowest level stuff for you. I couldn’t have got what I did to work using GPIO.

Do you mean that you want an SDIO card of some kind in order to expand the available I/O pins?

SDIO, from what I remember of the search I did a few months back, doesn’t exactly seem to have set the world on fire. There don’t appear to be many SDIO cards, and what there are appear to be quite expensive. If you know differently, I would appreciate some pointers! Because they are so rare and expensive, I find it difficult to believe that it would be worth building that much capability into the HAL.

Perhaps if you let us know more specifically what you would like to achieve, we can offer some ideas as to whether SDIO is the best way to achieve it.

What i actually want is a CPU bus brought out to a sensible connector. Why this is such an issue to get from the hardware folk baffles me. ;)

On the SDIO front. What you have working is probably fine for what we need. I think I already outlined what i’m trying to achieve but here goes again. I want a generic module or HAL api for talking to SDIO hardware ports. Preferably in the ROM.

Once i have that i’ll write the wireless driver for the IGEP. I’m happy to make a start and ask for revisions of the module as needed once a first cut that can talk to the IGEPs wireless SDIO port is available.

Until thats available i’m working on a Verilog floating point unit and possibly a 166Mhz accelerator card for an Amiga.

As I said above, what I’m working on is simply getting the firmware uploaded onto the card. (Right now I’m not working on anything because I’m away from home, and anyway my free time is very limited, but I’ll get back to it soon.) I think that’s within the realms of what’s possible for me – we’ll see! Once I’ve done that, I’ll probably have a pretty good idea of what a generic SD(IO) driver would look like and /maybe/ I’ll be able to look at putting some code into the HAL for it. But (as I’m sure everyone here’s already aware) I work at about a tenth of the pace of everyone else, so nobody should hold their breath.

On the SDIO front. What you have working is probably fine for what we need. I think I already outlined what i’m trying to achieve but here goes again. I want a generic module or HAL api for talking to SDIO hardware ports. Preferably in the ROM.

Yeah, we all know what you mean, I’m sure. As Dave said, you’ve basically got to use the SD/MMC host driver that’s built into the OMAP. So what we’d probably end up with is some sort of RISC OS module that more or less just piped SD commands (I’m talking about the numbered CMD#xx-type commands here) through to the HAL, which in turn loaded them into the necessary registers for the OMAP to send them off to the attached SD(IO) card(s).

I’m not sure how bulk data transfers would be handled, though. Probably via DMA. That would presumably be important for something like a wireless driver which will need a fast throughput.

Anyway, in the meantime if anyone else has the inclination to work on this, it’d be good if they got in touch. Otherwise I’ll just carry on at my own snail’s pace.

Until thats available i’m working on a Verilog floating point unit and possibly a 166Mhz accelerator card for an Amiga.

Good luck! ;-)

I think I already outlined what i’m trying to achieve but here goes again. I want a generic module or HAL api for talking to SDIO hardware ports.

I take it this is the wireless driver, via SDIO?

I’ve just been looking again for SDIO cards. The good news is that I can see some SDIO wifi cards for around GBP22 inc. PP. Almost tempts me to buy one – at least I’d be able to make my SD/SDHC/MMC code detect SDIO - but in reality I wouldn’t be able to do anything else with it.

Anyway, back OT: a module looks much more sensible to me than building so much code into the HAL.

I see the cheap SDIO wifi cards are based on the Mediatek MT5911N chipset. Do you have data or open source library code for that?