Jump to content
Have You Played Atari Today?
2600|5200|7800|Lynx|Jaguar|Forums|Store  

Welshworrier

Members
 View Profile  See their activity

  • Content Count

    471

  • Joined

  • Last visited

  • Days Won

    1

Posts posted by Welshworrier

  1. Posted · Edited by 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.

    • Like 2

  2. Posted · Edited by Welshworrier

    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.

  3. Posted · Edited by Welshworrier

    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

    • Like 2

  4. Posted · Edited by Welshworrier

    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
    • Like 1

  7. Posted

    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.

    • Like 2

  8. Posted

    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.

    • Like 1

  10. Posted

    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.

    • Like 6

  14. Posted · Edited by Welshworrier

    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.

  18. Posted · Edited by Welshworrier

    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.

    • Like 1

  19. Posted · Edited by Welshworrier

    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

    • Like 1

  21. Posted · Edited by Welshworrier

    LOL the guy on the video is complaining the CDi control is not bluetooth LOOOOOOOOOOOOOOOL

    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.

     

    There's a moment in the video when he shows up as a black shadow in front of the TV with the "commander" controller in his hand and I swear I saw something else ....

     

    CD-i_Remote_2.jpg

    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:

  22. Posted · Edited by Welshworrier

    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

    • Like 1

  23. Posted

    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.

    • Like 4

  24. Posted · Edited by Welshworrier

    generally i would agree but i didnt see the need showing the difference of 4 bytes :)

    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.

  25. Posted · Edited by Welshworrier

    that program was written by my own hand, it is my raptor object list editor

     

    it can be found here:http://atariage.com/forums/topic/233057-raptor-list-designer/?p=3419456

    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

AtariAge
Forums
Store
General
Follow AtariAge

Copyright ©1998-2021 AtariAge

×
×
  • Create New...