Jump to content


+AtariAge Subscriber
  • Content Count

  • Joined

  • Last visited

  • Days Won


Posts posted by playsoft

  1. 11 hours ago, flickertail said:

    Though in my desperation, I thought that it might be a casting issue anyway. So I tried the following instead:

    int16_t tempX = (atm_report.leftJSX / 512) + 64
            tempX = 255 - tempX
    uint8_t valueX = (uint8_t) tempX;

    ...but this didn't work either.

    This is OK for negative values, but positive values generate a byte value in the range 127..192.

  2. 11 hours ago, flickertail said:

    I thought about that, but the atm_report.leftJSX and .leftJSY are already defined as int16_t data types inside the atari_modern_report_t struct.

    I didn't mean that you should change the types in the structure, but that you should change the casts in the section of code I quoted.



    // 'atm_report' is a USB reporting Struct
    // leftJSY leftJSX are uint16_t data types that report joystick X,Y axis values
    int32_t tempY = (int32_t) atm_report.leftJSY;
    int32_t tempX = (int32_t) atm_report.leftJSX;


    // 'atm_report' is a USB reporting Struct
    // leftJSY leftJSX are uint16_t data types that report joystick X,Y axis values
    int32_t tempY = (int16_t) atm_report.leftJSY;
    int32_t tempX = (int16_t) atm_report.leftJSX;

    Or this which is a bit clearer:

    // 'atm_report' is a USB reporting Struct
    // leftJSY leftJSX are uint16_t data types that report joystick X,Y axis values
    int16_t signedJSY = (int16_t) atm_report.leftJSY;
    int16_t signedJSX = (int16_t) atm_report.leftJSX;
    int32_t tempY = (int32_t) signedJSY;
    int32_t tempX = (int32_t) signedJSX;

    When the MC reports a negative value your code currently generates a byte value in the range 192..255. With the change it will be 64..127.

  3. 14 hours ago, flickertail said:

    I tried wiring them as rheostats (as that's how the original controller pots seem to be wired), I've tried wiring them as actual digital pots. When wired as rheostats, they seem to work as expected... except... they only work in one direction.

    I think this is probably down to the joystick code.

    On 1/1/2022 at 10:04 PM, flickertail said:

    Some info about the MC's joystick output:

    • Horizontal (X)
      • Full Left Value: -32,XXX
      • Full Right Value: 32,XXX
      • Centered: 0
    • Vertical (Y):
      • Full Up Value: -32,XXX
      • Full Dn Value: 32,XXX
      • Centered: 0


    On 1/1/2022 at 10:04 PM, flickertail said:

    Joystick C Code

    // 'atm_report' is a USB reporting Struct
    // leftJSY leftJSX are uint16_t data types that report joystick X,Y axis values
    int32_t tempY = (int32_t) atm_report.leftJSY;
    int32_t tempX = (int32_t) atm_report.leftJSX;


    So the MC value is signed 16-bit but held in an unsigned 16-bit variable. However casting an unsigned 16-bit to a signed 32-bit will always result in a positive value. I would expect the joystick to work for right and down because positive values are OK, but not left and up.


    If you change the casts to int16_t it will tell the compiler to treat the value as signed first, then it should automatically convert it from signed 16-bit to signed 32-bit (or you can do 2 casts or add interim int16_t variables).


    Also, while I doubt it will make any noticeable difference, I'd change 32767 below to 32768 because the range of a signed 16-bit value is -32768 to 32767:

    On 1/1/2022 at 10:04 PM, flickertail said:
    tempY = (tempY + 32767) / 512;
    tempX = (tempX + 32767) / 512;



  4. 15 hours ago, Danjovic said:

    From the strict point of view of hardware I see no problem on that, and I believe that this is the next step that a game would do after detecting a "one button" controller attached.

    Thanks for taking a look at this. I downloaded the 7800 source code that is available for some of the old commercial games and the 2 button games I examined followed the software guide when a 1 button joystick is detected (i.e. leave the CTLSWB bits configured as outputs and set the SWCHB bits high). The 1 button games tended to configure everything as inputs by setting CTLSWB to $00 at initialisation, although some did not appear to set CTLSWB at all. I did not find (I may have missed them) any 1 button games which initialised by setting the bits in CTLSWB and SWCHB. It just seemed a bit strange having the 2 different approaches.

    15 hours ago, Danjovic said:

    As far as I understand if weren't for such guidance we could have three button joysticks.

    I do seem able to read all 3 buttons of my joy2b+ compatible joystick by configuring as per a 1 button joystick (either method!) and reading INPT4/1/0 (all bit 7 = 0 when pushed).

  5. 18 hours ago, Jaden (JRH) said:

    I wanted to save music and sounds for later on in the project, but it's definitely something I needed help with. So, I really appreciate you doing this for me. I'll be sure to credit you in the game for helping with music.

    It's just a test, put it aside until you are ready and then see if it's something you can use, but please don't credit me if you do since it's mostly @dmsc's code.


    18 hours ago, Jaden (JRH) said:

    My only issue is that the music is a little bit slow during gameplay. Probably some weird issue with PAL/NTSC conversion or something. But still, this is really nice. Thanks!

    For some reason I thought it was PAL timing so I slowed it down under NTSC. The attached does the reverse, NTSC timing speeded up under PAL.



  6. You are off to a good start, Jaden. Don't know if you needed a hand including the RMT tracks, but hopefully this might be of use. I ran the RMT files through RMT2LZSS and they "compress" using LZ8 pretty well. Actually the resulting LZ8 files are slightly larger than the RMT files but they require a lot less RAM during playback. I took the LZ8 player by @dmsc and added a wrapper for inclusion in 7800basic.


    I updated your code so that it plays the BGM all the time. The LZSS player code is in lzss_player.asm and exports two functions; lzss_init to be called at initialisation and lzss_process to be called every frame. To change tracks set the lzss_request variable with a value of 0 for silence, 1 for BGM, 2 for HurryUp and 3 for LevelClear. To add more tracks you'll need to create the LZ8 files, include them at the start of lzss_player.asm and update the track tables.


    Music plays on Dragonfly (A7800, JS7800 & BupSystem) but not on Concerto which I don't think supports [email protected] for 48K ROMs. You can pad it out to a super game ROM where [email protected] is supported but even then it seems a bit hit and miss whether it will function correctly.


    • Like 3

  7. 2 hours ago, Stephen Moss said:

    The Jaguar controllers use Row Column Addressing, the device reading the controller pulls the relevant row low (0V), allowing the pressed state of the buttons on that Row to be sent to the console for reading, there are 4 rows in total each outputting 6 bits of data.

    Could it be fully read like the 2600 keypad controller by using both controller ports - configure the 4 joystick direction pins in port #1 as outputs to select the row with the 6 TIA inputs on ports #1 and #2 used to read the data?


    If so is it just a wiring loom, would any other components be needed? (not that I am thinking of doing anything with it now, but it might be something to play around with in the future).

  8. When in 2 button mode and you detect a 1 button joystick, the 7800 Software Guide says "the game should turn off two button support for that joystick by setting the appropriate SWCHB bits high".


    It's probably best to follow the Software Guide, but is there any reason why you wouldn't do this by clearing the bit in CTLSWB and making it an input?

    • Like 1

  9. 7 hours ago, flickertail said:

    Thanks for all this info. I've been out of town for work, so I haven't been able to respond. I'll play around with things and see where it goes.

    No problem. If you end up needing some test software then PM me.

  10. Another interesting idea might be to bring analog joysticks to the 2600/A8/7800. It could drive the POT lines like it would with the 5200 (but using +5V and trimmers) and map 5 buttons to the joystick directions and trigger inputs. The 5200 games which make use of analog input could be ported to the A8 and retain analog control.

  11. 2 hours ago, flickertail said:

    I read your post on the other thread about the 12 pin. I thought he 12 pin just dead. It's good to know that the track pad uses it. I've been using a 15 wire cable for my test, so I stopped using the 9 pin for power, and now I'm using the 12 Pin for power. The PI turned on, and the controller looked to be fired up as well.


    Unfortunately, it still didn't seem to control the game... but I'm sure I just made a programming mistake. It'll just take some troubleshooting to straighten it out.

    It's probably not the case, but if you use pin 12 for power AND to drive the POT lines then they won't read as $E4 when POT common is disabled (then if the game you are testing does Trak-ball detection it might think you are using one).

  12. There is a trak-ball guide here:




    The second paragraph under Hardware Configuration is saying that when Pot common is disabled the trak-ball returns stationary values which should be in the range $69..$7C.


    If you read a standard 5200 controller with Pot common disabled you will get a value of $E4, so that's how games can automatically detect the presence of a trak-ball.


    Edit, this is what Pole Position does:

        6011: A9 00             LDA #$00
        6013: 8D 1F C0          STA CONSOL
        6016: A5 11             LDA $11
        6018: C9 E4             CMP #$E4
        601A: F0 04             BEQ $6020

    Clearing bit 2 of CONSOL disables Pot common and $11 is the shadow variable for POT0.


    However the code isn't quite right, it should write to CONSOL and then wait a couple of frames for the VBI to actually read the POTs. It gets away with it on a real cart but needed a hack to work from the Atarimax Ultimate SD where the menu program has previously enabled POT common.

  13. There's a good description of the 5200 controller ports pinout here:




    Edit, note this part:



    The analog joystick is very much like having a pair of paddles, one each for horizontal and vertical coordinates. The difference is that while paddles use the 5V source for the common voltage, the 5200 analog stick has its own dedicated pin. This is because the stick has a definite center, while the paddles do not. To get consistent behavior with any combination of individual stick and individual console, they could have put trimmers on the stick so the user can adjust the center position. Instead of making each stick adjustable to suit the console, they gave the pots a tightly regulated voltage that"s adjustable within the console. That"s what the tiny little trimmer hanging out near the power on/off switch does. Not that big one; that"s for adjusting the color phase delay.


  14. The i/o pins can't be configured like the 2600/7800/A8 but I don't know if you could make use of the POT common line?


    This is controlled by software and is normally enabled at initialisation and never touched again. As far as I know the only reason for it to be software controllable is for trak-ball detection; if you read the POTs without enabling POT common you get different values from a joystick and a trak-ball.


    You usually read the joystick once per frame. You read the POTn registers and store their values in RAM. You then write to POTGO to start another POKEY POT scan.


    I wonder if disabling POT common for a few cycles then enabling it before writing to POTGO could be used to signal a rumble request? I don't think this would affect a standard joystick as POT common is enabled before the POKEY POT scan is started. With your USB interface, if you can trigger an interrupt on the POT common line, then when you see it go from high to low that is a rumble request.



    • Like 2

  15. 1 hour ago, glurk said:

    Thanks Paul.  I wasn't even going to ask you.  I've never owned a 5200 and don't even especially like them.  :)


    I looked at the conversion reference, and I won't be doing one.  In fact, I've already started work on something new.  But if another programmer actually wants to convert this, I don't think it would be an enormous effort.  So if someone is serious about taking that on, I'll make my source code available to them.


    For now, I'm going to be using the knowledge I've gained from this one to (maybe) work on another new game!

    Well, I did end up giving it a quick go and it did convert easily.


    The only issue I had was a start up race condition. A routine at $AB47 is called which enables the VBI. Then a routine at $A701 is called which sets the vertical position of the plane. Should the VBI get in before the $A701 routine you end up with an extra image of the plane at the top of the screen. I got around this by syncing to the top of the screen before passing control to your code.


    It seems to play correctly, I used * & # for select and option.


    • Like 2
    • Thanks 5

  16. On 11/22/2021 at 11:31 PM, BIGHMW said:

    A would-be 5200 conversion would utilize the * key for the barn clearance, the # key for the amount of geese spawn, and the "0" key to select level, the bottom fire button would be the throttle while the stick moves up or down. Paul Lay (a.k.a. @playsoft) can do the conversion while @glurk would retain full rights. I know I have both an XEGS and a 5200 but Big Sexy enthusiasts would dig this game as much as I do. @glurk would you be OK with a conversion of this???

    @BIGHMW I have moved on from the 5200, so it's not for me. I would appreciate it if you would stop mentioning me whenever you ask for a 5200 port since it puts me in an awkward position.


    @glurk if you are interested in doing a 5200 port there is @ClausB's guide from ANALOG Computing, Transporting Atari Computer Programs to the 5200. Also @phaeron's Altirra Hardware Reference Manual. If it is something you decide to go ahead with and have any questions please feel free to PM me.



    • Like 5

  17. What the Atarimax Ultimate SD provides is:


    (1) An interface to read data from files on the SD card into the ROM area.


    Although I used .hyb/.dat pairs in AtariBlast! and the other demos, there is no reason why you couldn't use a .bin file and read from many different files.


    There is one significant restriction in that you must disable the ROM before you update it. So your code must be running from 5200 RAM as must be any graphics data displayed (alternatively disable the screen).


    (2) An interface to write data from the ROM area to files on the SD card.


    For this to be of use you do need to use the .hyb format, since you need to be able to change what's in the ROM area.


    Being able to read and write files on the SD card gives you the ability to store high score tables, save states and say, load/save pictures with a 5200 paint program, the sort of things you can do on an A8 with a disk drive.


    (3) Although I don't know them, there must be interfaces for reading and traversing the directories on the SD card, since the Atarimax menu program has this functionality.


    (4) The hybrid format which is the Atarimax's own bank switching scheme. Hybrid files must be 512K and have the .hyb file extension.


    The cart area is split so that $4000..$7FFF is banked and $8000..$BFFF is fixed.


    There is one range of bank switch registers which allow you to select 16K banks in the $4000..$7FFF area, standard 16K bank switching functionality.


    There is another range of bank switch registers which allow you to select 8K banks, with $4000..$5FFF providing write access and $6000..$7FFF providing read access to that 8K bank. There are more details here:




    While this effectively provides additional RAM, it's main use is for writing data to the SD card rather than porting A8 games because of the restrictions associated with it. 

  18. 14 hours ago, BIGHMW said:

    Wouldn't it be more feasible if AtariMax offered downloadable firmware upgrades so that 8-bit files, in .xex, .car, or .rom, can also work provided they can be operated on the maximum 16K of RAM??? You would think that they would work.

    I wouldn't! I would think if it were feasible it would have been done by now (and as a PC app rather than embedded firmware on a SD cart).

    14 hours ago, BIGHMW said:

    But also, is it possible, that certain 8-bit titles, that work within the 16K RAM, but, have more than 32K ROM, can be recoded to a .hyb file that we know the AtariMax supports also??? This can open the door for TONS of more 8-bit titles for all of US 5200 owners to enjoy as well so that we won't need to get an XEGS (like I had to last year) just to play THOSE???

    You don't need the .hyb format for that. @Wrathchild has been doing this for years, converting such titles as Dropzone using the bank switching scheme from M.U.L.E. which can be produced as a physical cart or run on the Atarimax Ultimate SD (it supports the M.U.L.E. format in 64K/128K/256K/512K variants). Conversions such as these are the most difficult things to do on the 5200, requiring a lot of time and dedication. It may take many years to do the conversion and get all the bugs sorted out, so I doubt he wants to do TONS of them for you.


    As a non-programmer the only A8 games you can state as definitely possible to convert to the 5200 are those which run on a 16K 400/600XL. Configure Altirra as either of these 16K machines and see if the game works. If not then you need a programmer to analyse the game. Unfortunately such analysis is not simple, having to look at all aspects where the game may need RAM (screen buffers, character sets, P/M graphics, variables,  self modifying code etc.) which is why such questions aren't normally answered with any authority.

    • Like 1

  19. On 10/14/2021 at 7:14 PM, Giles N said:

    But is this a game that couldn’t be put on an individual 5200-cart, even if had inbuilt extra mem., or is it ‘just’ that no-one produces such carts…?

    As Harvey mentioned, one of the A8 versions runs as a 8mbit/1024K cart. Had there been a 1024K cart for the 5200 I would have targeted that. As there wasn't, it was a choice of having less levels in a 512K cart or using the programming API in the Atarimax Ultimate SD to load the data off the SD card for each level individually.


    8 hours ago, Giles N said:

    And its good to see the different ROMs, so lonely, so forgotten and ignored, now reemerge from dark dusty digital shelves of long-unused AtariAge posts dwelling right there on the treshhold of collective retrogaming-amnesia… that very shrouded mist from which only the most hardy of retrogames have ever returned from.

    It had it's day in the sun and was enjoying it's retirement. Nothing wrong with that.

    • Like 1

  20. I'm not sure about the 5200 version of AtariBlast! posted earlier in this thread because it only seems to be a .hyb file, it should be a .hyb and a .dat file.


    The final 5200 version (with the updated music) can be downloaded from:




    More recently there was a thread about where to obtain 5200 homebrews and conversions. I posted a .zip file of everything I'd done which included AtariBlast!:




    What the 5200 needs is for someone to maintain an archive list/rom pack like @Trebor does for the 7800. I also vaguely remember there being plans for an AtariAge homebrew database at some point.

    • Like 1

  21. I've not done anything with the demo since it was originally posted, other than to include the music posted by Jaden and Synthpopalooza. I had planned to investigate what I could do for the expanding formation but ran out of time as I wanted to complete Runner Bear for the 2020 New Year Disk. After that I totally lost interest in 5200/A8 programming, it seemed to become a chore rather than a rewarding pastime. Later, Darryl got me interested in the 7800 after seeing what he had achieved with Popeye. I've enjoyed looking at different hardware and have started a couple of 7800 projects.


    • Like 2

  22. I did nearly everything in parallel by restricting the A8 to only using the first 16K as RAM and not using the O/S. Then it's the same with a few bits of conditional code to handle the controllers/keys differently.


    Scramble was released on the 5200 first because I'd spent a long time play testing/tuning parameters in NTSC to get to a point where I was reasonably happy with it. I'd not done any play testing in PAL, only sanity tests to make sure the graphics were OK and that it didn't crash. However the game felt very different under the slower PAL frame rate and I couldn't face going through all that play testing again so soon. I released the 5200 version (as it's NTSC only) and thought I would take a break and do something else, maybe return to do the PAL play testing at a later date if there was interest in an A8 version but unfortunately it didn't work out that way.


    • Like 5

  23. 3 hours ago, BIGHMW said:

    Yes, believe it when i say that while yes the analog joystick version of the 5200 edition of this XEGS staple works, the trak-ball hack (included below) has pretty much no response at all, both came in my complete set of 5200 ROMs for my Atarimax (and yes I DID pay for them) I picked up a couple of years ago, in which now makes the total of over 360 titles for Big Sexy. If there's anyone that can help correct the problem, I have attached both the joystick version (in which uses the analog technology of the stock controller) and the trak-ball version as well, the one that doesn't work.

    bughuntjoy.hyb 512 kB · 1 download bughuntgun.hyb 512 kB · 1 download bughuntball.hyb 512 kB · 1 download


    The forum search function can be useful when you have problems. Search for Bug Hunt (this forum, all words) and you would have quickly found:




    As @SoundGammon says, the trak-ball should be connected to the second port.


    I don't recall ever publicly releasing the light gun version.

    • Like 1

  24. 17 hours ago, BIGHMW said:

    Thanks @playsoft! So after looking through that and studying it does that mean even I, can port over A8 games to Big Sexy or is my education/skill level not good enough to do so, as I hate to ask others to have to do it for me, I have always wanted to be more self-sufficient. (I have developmental and psychiatric issues) There are plenty of A8 ports that'll work on the 5200, like Bug Attack, to name one, and quite a few others as well.


    I DO own a 65XE, and an XEGS (picked up in November and December respectively last year) as well as the 5200 (since 1983) as well. I also own a Dell Inspiron with Windows 7 Pro that I can (if necessary) transfer .xex, .car, .atr, and .rom files and convert them to .bin, .hyb, or .rom very easily.

    You would have to learn to program first but I think anyone can do that with study and practice. A lot of us here learnt programming when we were kids, writing in Atari BASIC initially, learning 6502 assembler and including some machine language routines in our BASIC programs, then finally writing programs completely in assembler.


    Obviously this took a number of years and as older adults we might not learn as easily as we did when we were young and your issues may not help. But it is a path you could follow, perhaps to start with spend a year or so learning Atari BASIC with the goal of writing a simple game and see how you get on with that, whether it is something you enjoy or not.


  • Create New...