Danjovic

This is my first Atari Game(1). It is intended to be played by 3 to 5 people. One person, the host, make a question and the other players, each one holding a paddle controller shall dispute the opportunity to answer the question. The first one to press the button wins the round, and the screen blinks the winner number on screen. The next round can be engaged either by all players pressing their buttons simultaneously or by the host pressing the RESET button on the console. The game is written in Batari Basic. Thanks to the authors for this excellent tool (along with Vbb) and for the tutorials. There's a lot of things to improve, of course, like adding sound and better worked graphics! (and plenty space for that, precisely 2048 bytes) Title Screen Waiting for the players to press the button Player 1 wins Player 2 wins Player 3 wins Player 4 wins (1) but not my first Atari Homebrew. (2) two paddles are required but the game can also be played using track and field controllers, or eventually ordinary joysticks for two players QuizGame.bin

Thanks!! I will try that!!

Well at the end I wrote the sampling routine in Basic. __sampleSNES rem initialize ports SWCHB{2} = 0 : rem disable transistors Q6 (for 7800) SWCHB{4} = 0 : rem disable transistors Q5 (for 7800) SWACNT = 3 : rem enable pins UP/DOWN to work as outputs SWCHA = 3 : rem make pins clock (UP) and latch (DOWN) to go high rem sample first 8 bits temp1 = 8 __sampleH SWCHA = 0 : rem latch down, clock down snesButtonsH = snesButtonsH * 2 if !joy1fire then snesButtonsH{0} = 1 SWCHA = 1 : rem latch down, clock up (next bit) temp1 = temp1 - 1 if temp1 > 0 then goto __sampleH rem sample next 8 bits temp1 = 8 __sampleL SWCHA = 0 : rem latch down, clock down snesButtonsL = snesButtonsL * 2 if !joy1fire then snesButtonsL{0} = 1 SWCHA = 1 : rem latch down, clock up (next bit) temp1 = temp1 - 1 if temp1 > 0 then goto __sampleL rem sample 17th bit __bit17 if !joy1fire then bit17{7} = 1 else bit17{7} = 0 SWCHA = 3 : rem latch up, clock up return

Thanks ! that should explain the vertical bars, but I went down on another rabbit hole, lol!! My workaround was to read the INPT5 to register A, then rotate register A, but it did not worked the way I expected because I came across a really strange behavior, probably in the emulation. Let me explain better ( reducing the code to a minimum) : First the code without the workaround. At the end of execution the state of the snesButton variables will follow the state of the fire button input, as expected because I am shifting in the logic state of the fire button. for the button released snesButtonsL ; = %11111111 snesButtonsH ; = %11111111 for the button pressed snesButtonsL ; = %00000000 snesButtonsH ; = %00000000 lda #$c3 ; initialize sta snesButtonsL ; = %11000011 sta snesButtonsH ; = %11000011 SMPSN0: rol INPT5 ; ror snesButtonsL ; ror snesButtonsH ; dey ; bne SMPSN0 ; On the other hand, with my workaround, no matter the state of the fire button input I always have the outputs like only one shift was performed, just once snesButtonsL ; = %10000111 snesButtonsH ; = %11000010 lda #$c3 ; initialize sta snesButtonsL ; = %11000011 sta snesButtonsH ; = %11000011 SMPSN0: lda INPT5 ; WORKAROUND rol a ;rol INPT5 ; commented ror snesButtonsL ; ror snesButtonsH ; dey ; bne SMPSN0 ; The most bizarre is that the state of these variables won't be different even if I do something like this lda #$c3 ; initialize sta snesButtonsL ; = %11000011 sta snesButtonsH ; = %11000011 SMPSN0: lda, #$ff rol a ror snesButtonsL ; ror snesButtonsH ; dey ; bne SMPSN0 ; This behaviour is teh same on either Stella and Z26..

I am working on the SNES function for my homebrew joystick tester and two bars are appearing on the sides of the screen (see attached picture) I have tracked down the problem to the instruction rol INPT5 and can I think of a workaround, but I could not understand why do this would affect the TIA (at least in Stella emulator). Any thoughts? asm lda #$0 ; 2 clock down, latch down sta SWCHA ; 4 make both latch and clock down ldx #$01 ; 2 clock up, latch down ldy #16 ; 2 16 bits lda #$ff ; 2 Initialize with no button pressed sta snesButtonsL ; 5 if necessary to gain a few microseconds sta snesButtonsH ; 5 from latch/clk down till first bit sample lda #$0 ; 2 SMPSN0: rol INPT5 ; 5 sample data stx SWCHA ; 5 clock up ror snesButtonsL ; 5 take some time assume ror snesButtonsH ; 5 sta SWCHA ; 4 clock down dey ; 2 next bit bne SMPSN0 ; 2 repeat stx SWCHA ; 5 clock up, next edge to read 17th bit rol INPT5 ; 5 sample data, 17th bit on Carry rol bit17 ; 5 temp1 bit 0 contains 17th bit value. should be zero for SNES lda #$03 ; 2 both clock and latch up sta SWCHA ; 5 finish sampling end

Paddles and standard joysticks can coexist. get someone to build ou a Y cable, or build it yourself, and you will not even need to flip the switch.

I am working on a Test Cart for joysticks and keypads to help with the development of one of my projects. On the splash screen press SELECT to start the test. It will read the state of DIFFICULTY switches being A for joystick and B for keyboard and enter one of the following modes. Left: Joystick, Right: Joystick Left: Joystick, Right: Keyboard Left: Keyboard, Right: Joystick Left: Keyboard, Right: Keyboard It can test joysticks with omega booster. The button state is show using 2 methods: - The score counter shows the logic state of the TIA inputs (1/0) in the following order: - The second method is graphical and consider the fire button active low while the thumb and trigger buttons are active high. The keyboard is straightforward. The program runs nicely on Stella, but I would appreciate if somebody with a programmable cart can test it on the real hardware, before I burn a ROM. Both the binary and the source code are attached. Note: I have used the keyread.asm routine by CurtisP from a post from 2009, but it was necessary to modify the code to return all the SWCHA bits to 1 after reading the last row, otherwise the right joystick kept stuck to the right position. keypad_store SUBROUTINE ; LDX #%11111111 ; set all SWCHA bits back to 1 STX SWCHA ; ; STA keypads TYA ORA keypads STA keypads RTS KBTEST.zip

Thanks Randon Terrain. I have read the thread then changed the section of the standard kernel that discharges the capacitors and now the tester works both on Stella and on Z26. Additionally the code was simplified (changed the asm sections to the simpler INPTx{7} syntax! By the way, I am using the score to register the state of every button input, from joystick 1 and joystick 2. As the Fire buttons are pulled up, the logic level on idle is 1, while the other buttons are kept low being pushed high by the top Boost and the Trigger buttons. Source code and ROM attached. DualJoyTester.bas DualJoyTester.bas.bin

I am writing a simple controller test ROM and I need to show the status of the CBS Booster Grip state as well. My first approach was to read the INPT0..3 variables with inline assembly: asm lda INPT0 sta tempINPT end if tempINPT{7} then ... and of course configure Stella accordingly No need to say that it does not worked, though the generated assembly coded looked ok to me. 2031 f582 a5 08 lda INPT0 2032 f584 2033 f584 85 d8 sta tempINPT 2034 f586 2035 f586 .L053 ; if tempINPT{7} then score = score + 010000 2036 f586 2037 f586 24 d8 BIT tempINPT 2038 f588 10 09 BPL .skipL053 2039 f58a .condpart10 2040 f58a f8 SED 2041 f58b 18 CLC 2042 f58c a5 93 LDA score 2043 f58e 69 01 ADC #$01 2044 f590 85 93 STA score 2045 f592 d8 CLD 2046 f593 .skipL053 Then I did another test, and used INPT4 on the inline assembly, and I could verify that the code worked (also for INPT5) asm lda INPT4 sta tempINPT end if tempINPT{7} then ... Then my question is: Does anybody have already performed the reading of the BoosterGrip buttons using Batari Basic (during the development) ? If so, is there any special procedure that I have to perform ? Thanks!

Waiting for the SNES connector

Super Sudoku by Raphael Assenat https://www.raphnet-tech.com/products/super_sudoku/index.php

Yes.

Working on the prototype, starting with the PCB.

If you're on diy check this:

The additional holes (with small diameter) are just vias to route the signals from one side of the board to the other. No need to solder anything on them.

Of course, not the tool proposed in the topic, just a simple check (of its presence on the I2C bus) and a brief count of its usage slots (considering that the first byte of any 64byte slot will be different from 0xFF from a blank eeprom.

What went through my mind is a diy version, arduino based talking on (virtual) serial port. btw does anybody knows of a homebrew rom to detect/check the savekey on the ATari 2600?

No problem at all !!!

Thanks Mike. I am always happy to contribute somehow.

The square inch version is very stable. I don't sell it, sorry. It is an open source project, anyone can make it even for selling to other people (as long the original work is credited somehow). Well, unless you are able to somehow modify the mapping of the buttons on the 8bitdo receiver, you're stuck with that. Have you tried to use a classic controller?

With the present PCB a diode will be necessary, but not "only" the diode. The firmware should be modified to push a "high" on either POT1/POT2 pins in response to the Z/C controls (and add support for other controllers than the Nunchuck). The reason for the diode is due to a project decision that was fine for the 2600: When I designed my adapter I have routed to DB-9 connector all the signals necessary to program the micro-controller, including the pin (RA3/MCLR) that happens to work as an input. A diode will allow another pin to push the 5V signal on the POT1 line while isolating it from the 12V received by the MCLR pin at the time of programming the chip (with the board connected to a programmer). Of course, a solder jumper can be added to the PCB layout to allow reroute the pin after the micro-controller is programmed. The link to the project page is on the link that I have posted (full URL is https://hackaday.io/project/7944-at26-chuck) and all the sources are availabe at the project's github repository (https://github.com/Danjovic/AT26-Chuck)

it looks like a version of the early models of my AT26-Chuck , apprently with less features. I see no problem on replicating an open source project, even for profit, as long as the original work maintain its credits. At least the device is being offered for cheap, which is a good point :). My latest PCB was shortened to better hold the nunchuck connector, and reduce the stress on the Atari connector. BTW the firmware can be modified , and a diode shall be added to support two buttons on POT lines to mave it compatible with 7800.

Suggestions: - simply bend the terminals on both sides, and solder them on pcb. Many Sinclair computer projects have been made like this. - use a small pcb with tracks on both sides and a via interconnecting every terminal and solder it on the main proto cart board. the "sandwich" will have twice the thickness of a pcb board and it should be easier to solder the connector without bending the terminals.

There was some spare space on the board under the Arduino, perfect to add an EEPROM (savekey).