Jump to content

playsoft

+AtariAge Subscriber
  • Content Count

    578
  • Joined

  • Last visited

  • Days Won

    2

Everything posted by playsoft

  1. This is OK for negative values, but positive values generate a byte value in the range 127..192.
  2. 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. Change: // '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; To: // '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. I think this is probably down to the joystick code. 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:
  4. 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. 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. 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. 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. lzss_player.asm
  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. test.zip
  7. 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?
  9. 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. 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: https://atariage.com/forums/topic/125406-8-bit-conversions/?do=findComment&comment=3306094 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: https://old.pinouts.ru/InputCables/JoystickAtari5200_pinout.shtml Edit, note this part:
  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.
  15. 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. barn5200.bin
  16. @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.
  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: https://atariage.com/forums/topic/221479-5200-ultimate-sd-cart-hybrid-8k-write8k-read-mode/ 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. 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). 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.
  19. 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. It had it's day in the sun and was enjoying it's retirement. Nothing wrong with that.
  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: https://atariage.com/forums/topic/217200-something-new-gtiablast-5200-wip-for-ultimate-sd-cart/?do=findComment&comment=3612319 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!: https://atariage.com/forums/topic/321728-5200-homebrew-roms-and-conversions/?do=findComment&comment=4857195 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.
  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.
  22. I was. These appear to be the last A8 builds. jaden_50.xex jaden_60.xex synth.xex
  23. 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.
  24. 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: https://atariage.com/forums/topic/125406-8-bit-conversions/?do=findComment&comment=3305738 As @SoundGammon says, the trak-ball should be connected to the second port. I don't recall ever publicly releasing the light gun version.
  25. 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...