Welshworrier

And here is a 'bodge version' of the jagonly source code with an attempt at trying to detect and correct the uart error by sending the main traffic as 2 nibbles with bit 6 set. Volatile now used for ticcount and consistancy check modded to actually use the integers of x and y position as interim computational values before converting to byte. Baud rate set as 115k...well because it's worth a try. Two extra functions defined that split a byte up and send as two nibbles and tag as either high or low nibble, and one that received the data in the same way. https://mega.nz/#!cUMBBBbS!oKSSXt11vep5GqzDuJb7Kis-qDiVu-n9GOCgY1JgIXA Minimal changes in effect but will send a larger packet across the serial link, internally it will be the same. If someone could compile and try that would be nice Now off to work I go.

Bugger, yes I'm afraid, I copied the wrong link and it's on my laptop - can't access mega off this phone and so will have to do it in the morning (about 6 hours time). Then again.... due to my neighbours having a blazing row I've now got out of bed Link with key: https://mega.nz/#!UJM1hSIK!cAPMgFcovllvb2VeaeRruohBvCNek8LbT0QTETV7XFU I've had a really stupid idea btw - if you only send the data 6 bits per byte (0..5) and set bit 6 to 1, any uart error would move it to the top bit and be easily identifiable. It would negate the need for the ack cycle at an increase of about 2 bytes per packet.

Oddly enough that's pretty much what I had just finished writing for a test - typical - I'll attach my version if you want to see where I was going. Probably only difference is I try and resync after a transmission if the first byte is incorrect. One thing I did notice is that there is a potential 'gotcha' in the use of ticcount between the jagonly.c file and doomdefs.h - it shows up as a volatile in the doomdefs but not in the jagonly file. There are also a few oddities in the original code as an unsigned is set to negative in a few functions ('c' in __mulsi3, FixedMul, FixedDiv). Will try and have a look at your code tomorrow morning. Link (as I can't upload attachments) https://mega.nz/#!UJM1hSIK!cAPMgFcovllvb2VeaeRruohBvCNek8LbT0QTETV7XFU

I've had a bit of a look at the source code and, even though I'm quite a novice at Jag coding I've written quite a bit of serial comms stuff over the years, there are a few issues that look suspect. Doing the maths on the byte transfers: 6 bytes * 2 * 15 frames a second max = 180 bytes of data a second (approx 2k baud) You could probably drop the xfer speed down to 19200 with negligible impact. As the uart only has a one byte buffer this would lessen the chance of overrun/error though as you are polling for the data there might be a game impact. Looking at the Doom source shows how flaky the network comms are anyway - any single byte transmission error kicks the network game out. You may be better redoing the entire protocol BTW: consistancy = players[0].mo->x ^ players[0].mo->y ^ players[1].mo->x ^ players[1].mo->y; consistancy = (consistancy>>8 ) ^ consistancy ^ (consistancy>>16); As consistancy is defined as a byte earlier on in the function.............. When you tried the "if (inbytes[5] != inbytes[1] ^ inbytes[2] ^ inbytes[3] ^ inbytes[4])" you might want to ensure the precedence by bracketing the xors in case of compiler feature i.e. if (inbytes[5] != (inbytes[1] ^ inbytes[2] ^ inbytes[3] ^ inbytes[4])) Interesting to see how it all pans out

Those carts just bank switch the top addressing lines so that each game then 'lives' in it's own address space. They still share the same eeprom save game space though.

Your mission, should you choose to accept it, is to write a bit of software on a pi or arduino to transfer serial data to and from a packaged network message. Then write a server to connect to and distribute to the connected units

The ac adaptor will still have to down convert the mains voltage even if the jag it's not on (in case you do switch it on). The adaptor will not be converting at 100% efficiency and some of the wasted energy will be seen as heat. When the jag is switched on then more current will be drawn through the adaptor and so even more heat will be generated.

When the BBC were looking around for a computer to endorse they were offered up the spectrum by Sinclair and a new machine, based on the proton iirc, from acorn. Beeb chose acorn much to the annoyance of Clive Sinclair. Outside the schools market there weren't that many BBC owners as a proportion of the market, not really helped by the Beeb's distain for using computers for anything as unworthy as gaming There were a lot of other niche computers that appeared in the same timeframe: Jupiter ace, camputers lynx, memotech mtx, and of course the msx series but the American machines from commodore, and to a lesser extent Atari, alongside the spectrum won out.

That's what I was on about, I'd imagine it's just used for address decoding so it should be possible to rev-eng it relatively easily.

The spectrum got a lot of people into programming into the UK. It came out at a time when the BBC were promoting computing, and had the BBC micro going into schools. Cost of BBC micro was about 3 to 4 times that of the spectrum and so lots of parents bought them. This in turn meant a massive bedroom development culture on the very limited hardware. It also meant lots of potential sales for software and so companies sprung up to cater for them. I had a spectrum for about 2 months, along with the Atari 400, if you could buy 1 Atari game for 20 plus quid or 10 spectrum games for the same price, some of which were real classics, then you can understand the interest.

Coleco Chameleon Flashback edition:

Have people got the PEEL code though?

Interesting that he said that the linked clip (uploaded 26th March 2016) was from a few years ago - perhaps he could then explain how it's got Batman Arkham City shown running on a surface 3 (launched May 2015) at 1:26. - Which runs at about 20fps on the i5 version allegedly I call shenanigans.

From memory (and not in the hidden gems vids): Ultimate shooting collection (including Karous) Rayman Raving Rabbids (trilogy) Monster Hunter Tri Archer Mcleans Mercury Revolution Heinz Wolffs Gravity Vertigo Bomberman Land Epic Mickey Smash Brothers Brawl (which also had the advantage of being a method of installing the HBC) FYI Believe it's about 3TB of drive space these days unless you add the GC stuff too.

I believe this auction tells us something about him..... http://www.ebay.com/itm/Lot-of-8-Seventeen-Magazines-2014-Mostly-Mint-Unread-condition-/311593977135 Because it's important they smell new

or score multiplier based on speed of ship?

Or change the game mechanic slightly? Have it so that the engines of the ship charge up at a certain rate, and that if they are not depleted through thrusting then you'll get to a stage where the ship explodes.

Addendum - I've been searching around for eeprom jaguar docs and see that 16bit is the correct organisation. This means that pin 6 would need to be connected to VCC (Pin 8 ). Most (all?) of the eeproms should have the org pin in x16 mode by default if not connected, but if you are having issues it would pay to be certain. With your programmer not supporting the larger chips, extra address bits are required to be clocked in because of the address space - the cell address sequence will be 10 bits instead of the 8 for a x66 (9 in 8 bit mode). I wrote some eeprom programmer software a few years ago that handled all the 93c chips - I'll dig it out and see how I handled it.

The c86 has two memory configuration modes - 16bit and 8 bit. The organisation depends on the voltage on pin 6, connected to VSS gives you 8 bit, VCC gives 16 bit. I'd guess your programmer is set to let pin 6 float and so it's trying to access as 16 bit but sending the 8 bit clocking pattern. Might be worth you trying to lift the leg of pin 6 out of the programmer socket and connecting it to pin 5 (VSS) to force to 8bit mode. Edit: Looking at the eeprom circuit board picture seems to show it as unconnected - wonder if that might be your issue, with a c66 it doesn't need connecting as that is 8bit only. Simple check is to put a blank eeprom in and connect pin 6 to 5 as well and see if it works

Doubt if the OP will reply due to this thread amongst others http://atariage.com/forums/topic/246579-jaguar-cd-repair-by-onalok/

If you listen carefully he just says it's infrared not blutooth which causes one of the problems. He's not bemoaning the lack of blutooth but the fact it uses infrared for the control. I thought the same, If you listen to the dialogue with that in mind it sounds even more suspect after spotting it The resemblance to a 'sex aid' is explored in his review of Video Speedway:

As the owner of a Philips CDI 220 I can honestly say the controller was utterly useless - trying to actually use it for any of the CDI games was a nugatory effort. The lag was in the region of a good half to three quarters of a second, and diagonal movement was a legendary event sung of by remote tribes as part of their oral history. People would gather around the log fires and sing of the time they managed to return a ball in international tennis. But I digress... I sold the CDi and a load of games a few years ago to the guy who does those reviews - He basically loads a retro game and then plays it - usually badly while giving a running commentary

It seems that the postalgamer concept suffered a name change and another attempted launch in April 2012 as EKGaming.com http://www.gamasutra.com/view/pressreleases/169057/ There is also the 'everything but games' retro auction site from February 2009 http://www.worldamazingrecords.com/2009_02_08_archive.html http://www.vendazzle.com Oddly enough someone updated the record for that site in September last year.

It meant that you didn't have a one 2 one relationship between the vertical and horizontal scales and so when looking at the header descriptor for the bmps you couldn't just jump straight to 0x26 (for example), you ended up having to do 0x22 for second row and then use the 5th column for the data you needed - your xaxis values were not the actual lowest nibble values but offsets. If you had done it at 0x10 width then it would have mapped and been easier to see what the header offsets were as all docs tend to specify the byte offest e.g. https://en.wikipedia.org/wiki/BMP_file_format. As a result, you would have quickly seen that the xpixels per metre field and the ypixels were incorrect. It's not a criticism, just an observation that would have helped you get the answer quicker.

Looking at the display could I suggest making the hex displays 16 bytes wide instead of 17 - I'd spent ages looking at the values before I realised why the offsets I was calculating were all wrong (that way all the embedded offsets will be easier to navigate) Edit: Just realised it was hex workshop in the PNG