Jump to content

ApM

Members
  • Content Count

    13
  • Joined

  • Last visited

Community Reputation

8 Neutral

About ApM

  • Rank
    Space Invader

Contact / Social Media

Profile Information

  • Location
    Ottawa, ON, Canada
  • Interests
    Everything

Recent Profile Visitors

1,849 profile views
  1. So for the benefit of anyone who might stumble onto this thread in the future and get curious: Replacing the PIA with a W65C21N6TPG-14 chip from Mouser appears to have solved my SIO problems. I'm now able to boot with the FujiNet, connect it to Wifi, download disk images, and boot them. Thanks again, everyone.
  2. Alright, I pulled both the POKEY and the PIA, applied deoxit on the chips and the sockets with a toothbrush, and reseated them. No change in the machine's behaviour; my joystick program is doing the same thing, FujiNet still won't boot. (The orange LED on the FujiNet stays on indefinitely once the Atari has been powered on, even after the Atari is shut off. Not sure if that helps anyone understand what's going on.) Definitely something wrong with the PIA, but it looks like compatible replacement parts are still being made and aren't too expensive. Am going to try replacing that first, then picking up a replacement POKEY if I'm still having SIO problems. Thanks for all your help!
  3. Wrote a little BASIC program to test the joysticks and they are indeed heavily messed up: 10 FOR I=0 TO 3 20 ? STICK(I);" "; 30 NEXT I 40 ? "" 50 GOTO 10 This prints out "0 0 13 5" repeatedly, even with nothing plugged in. With a joystick plugged into jack 3 or 4 I can get the third or fourth numbers to change in response to some joystick movement, but otherwise it appears that a bunch of inputs are stuck on. From the schematic it looks like POKEY handles only the analogue inputs, which wouldn't show up in this test - not sure how to verify those from BASIC yet. Seems to me like this points the finger at the PIA as the problem though.
  4. Thanks for all the suggestions. I've traced each pin on the SIO port to the matching pin on the POKEY and PIA with a multimeter measuring resistance, following the motherboard schematics I found here: SIO 1 - POKEY 26 (Clock in / BCLK) SIO 2 - POKEY 27 (Clock out / ACLK) SIO 3 - POKEY 24 (Data in) SIO 5 - POKEY 28 (Data Out) SIO 7 - PIA 19 (Command) SIO 8 - PIA 39 (Motor Control) SIO 9 - PIA 40 (Proceed) SIO 13 - PIA 18 (Interrupt) SIO 8 shows infinite resistance when compared to PIA 39 but a second look at the schematic shows there is a transistor in the way - it's powering the motor from a 5V power source, not the chip. So that makes sense. All the other pins show near zero resistance. I noticed there is about a 9-10kohm resistance between most of the pins, ie. data in / out, is this expected? Checking the schematic it looks like all of the inputs are tied to ground with capacitors to clean out the signal - my guess is that in operation they should be appropriately isolated. But my electronics knowledge is pretty basic, so I really don't know. Regardless, this test should rule out solder / connection issues at the SIO port and at the connection between the power supply and the motherboard. Pulling the POKEY chip is _very_ difficult; it does NOT want to come out of the socket. Given that my testing is showing that the connection is solid, I don't think reseating it would help; I am leaving it be for now. POKEY looks fine; a couple of the ROMs look like they might have a little corrosion on their pins though. Any way of doing a checksum? My RAM expansion card also has the ability to override the system ROMs, I could try fiddling with that. I am getting +4.96V on the data out pin on power up, and +0.14V after performing the two pokes. Also getting +4.96V on the data _in_ pin, before and after the pokes. That's a little surprising to me. I am using external power on both the FujiNet and SDrive MAX. I did accidentally have the SDrive plugged into both external power and the Atari's 5V for a while before eventually pulling that pin, but it doesn't seem to have damaged it. I bought my FujiNet from The Brewing Academy; I don't have any reason to suspect a problem with it given the problems I'm having with everything else. Since I have no access to games, I haven't tested the joysticks at all - is there a good way to check the PIA from BASIC? Given that the COMMAND pin is wired to it, and the FujiNet seems to be reading data before it's ready, and sound is definitely still working, I'm starting to get suspicious...
  5. I recently picked up my first 8-bit Atari, a dusty old Atari 400. I've put a 48k RAM upgrade in it and it boots to Memo Pad and runs cartridge software fine. (I only have a few carts - BASIC, Pilot, and Atari Music Composer.) It came with a tape drive with a belt so worn out that the tape won't turn. I built an SDrive MAX, but it just spits out errors when I turn the Atari on, and it just boots to Memo Pad as if nothing was plugged in. I figured I must've messed up on the construction somewhere and bought a FujiNet - but that does the same thing, boots straight to Memo Pad. It has more interesting debug output - it spits out the SIO command it receives when the computer turns on. Turns out it's getting semi-random garbage instead of usable SIO messages? Half the time the checksum doesn't add up, and the other half it's trying to send random messages to device 0. These are the FujiNet serial logs from switching the machine on and off six times (the appropriate LOC producing the "CF:" debug output appears to be here in the FujiNet firmware source - device, command, aux1, aux2, checksum). [10:20:01]CF: 00 4c 2a 00 84 [10:24:29]CHECKSUM_ERROR [10:24:36] [10:24:36]CF: 00 31 53 00 00 [10:24:36]CHECKSUM_ERROR [10:24:36]Toggling baudrate from 19200 to 67431 [10:24:36]set_baudrate change from 19200 to 67431 [10:24:42] [10:24:42]CF: 00 00 00 c0 f8 [10:24:42]CHECKSUM_ERROR [10:24:47] [10:24:47]CF: 00 00 00 c0 f8 [10:24:47]CHECKSUM_ERROR [10:24:47]Toggling baudrate from 67431 to 19200 [10:24:47]set_baudrate change from 67432 to 19200 [10:24:53] [10:24:53]CF: 00 31 53 00 00 [10:24:53]CHECKSUM_ERROR [10:25:00] [10:25:00]CF: 00 00 4c 2a 00 [10:25:00]CHECKSUM_ERROR [10:25:00]Toggling baudrate from 19200 to 67431 [10:25:00]set_baudrate change from 19200 to 67431 Anyone have any advice for how to debug this at the hardware level? What parts might be causing problems on the SIO interface like this?
  6. Anyone else notice that the screenshots are pixel-perfect copies of the screenshots in AtariAge's database? =]
  7. Your Kaboom! screen looks familiar -- I was seeing the exact same pattern on my real Kaboom! cart when I had my 7800 hooked up using a NES switchbox. You could control it with the paddle and everything. Connecting it to a generic switchbox (with a switch) and using a different cable fixed the problem completely.
  8. The only other tool besides DASM that's really used for 7800 dev at this point is a78sign. I recall it being a bit annoying to build, so I put up my binary here. There's a tool floating around for creating .a78 headers as well, but I was never able to find the source to it and eventually just stuck raw header data into my assembly files. There's a thread about that someplace. And MPW under OS X? Ugh! God, why? =]
  9. The NES hardware was much easier for programmers to wrap their heads around. Basically, you have a tiled background, which you can scroll, and a handful of sprites. It's ludicrously straightforward. The MARIA is much more flexible, but it is a bit more difficult for the programmer to get something going, and probably costs more CPU time as well. Gotta set up your display list list, and all of your display lists, and your entries to point into your character background, then place your sprite data in just the right spot to be able to use holey DMA... Now to horizontally scroll, we update 30 flags in various entries scattered around the DLL... You have to do a lot more work to produce a good-looking game for the 7800.
  10. DASM works great -- the official DASM site has a MacOS X port. I've also compiled a78sign for MacOS X, you can grab it here. I've found it works nicely to build the .a78 header directly into the source file: SUBROUTINE Header ORG CodeStart - 128 .byte 1 ; Header version .byte "ATARI7800" DS.B 7 .Cartname .byte "Test";Cart title, 32 bytes max .EndCartname DS.B 32 - (.EndCartname - .Cartname) .byte $00,$02,$00,$00;ROM size, big-endian .byte $06 ;bit0 - pokey cart ;bit1 - supercart bank switching ;bit2 - supercart RAM ;bit 3 - ROM at $4000 ;bit 4 - Bank 6 at $4000 .byte 1 ;P1 controller type .byte 1 ;P2 controller type ;0 - none ;1 - joystick ;2 - lightgun DS.B 100 - 57 .byte "ACTUAL CART DATA STARTS HERE" SUBROUTINE Code ; Bank 0 ORG $8000 CodeStart ... ; Bank 1 ORG $c000 RORG $8000 ... ; Bank 7 ORG $24000 RORG $c000 ; Bank 7 always mapped in $c000 This is for a full-out, 8-bank 128kb ROM, I believe with 16kb of Supercart RAM at $4000-$7fff. (MESS and the official a78 spec don't seem to quite line up properly -- I have to say "ROM at $4000" for it to recognize that there is RAM there or somesuch. I forget exactly, it's been a while since I did this up.) Anyway, hope this helps.
×
×
  • Create New...