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

DanBoris

Members
 View Profile  See their activity

  • Content Count

    1,086

  • Joined

  • Last visited

Posts posted by DanBoris

  1. Posted

    Unfortunately I discovered the problem, or at least a part of the problem. There was a loose pin on the cartridge connector that proceeded to fall out when I tried to look at it closer. I had noticed it was slightly looser than the rest when I was cleaning, but I think taking carts in and out working on the machine finished it off. It fell out when I was trying to see if it was still connected to the main board. When looking at the Odyssey from the front, it's the pin all the way at the end on the right side, back row. I think this unit might be done unless I can replace the pin or get a new cartridge connector out of another bad O2. It still responds exactly the same way, colors, squares occasionally, etc.

     

    Another worst case option is to swap the bad pin another one on the connector that is not needed. There is at least one signal that is not used by cartridges, but it is used with the voice module.

  2. Posted

    Thanks for responding! I checked the voltage at the pins you mentioned and I seem to be getting about 4.8v. I have reinserted the chips that were socketed, but it didn't seem to make a difference. I seem to be getting voltage to at least some of the cartridge connectors and they appear to be clean but this also made no difference. From what I can see the solder joints appear to be alright as well. Anywhere to go from there? Should I try resoldering the cartridge connector?

     

    Re-soldering joints would be a good next step. Yes, having a bad RAM chip, or bad processor or video chip could cause this, but I always lean towards the simple things first, dirty connections and bad solder joints.

  3. Posted

     

    When ever I think of the 5200 I always think of this game. mainly because of the movie which I have seen hundreds of times. Some one really needs to do a homebrew of this game

     

     

    An official 5200 version was half complete before the crash came and the project was abandon. The original author did start working on it again in recent years but I don't think anything ever game of that.

  5. Posted

    This probably isn't a video problem, but something preventing the game code from executing properly. First thing would be to give the cart connector a good cleaning and then check the solder joints on the back. If you have a multi-meter you can also check that you are getting good voltage to the system. Check between pins 20 and 40 on the microprocessor (IC7-8048) and be sure you are getting 5V. If any of the chips are socketed, carefully remove them and re-insert them.

  6. Posted

    Dan,

    I saw the two JACS newsletters on archive.org. Did you scan more?

     

    I've kept my JACS newsletters - I'm fairly certain I have them all. I may scan them in the near future - that would be quite a lengthy task. JACS was active for over a decade.

     

    Forrest

     

    No, those were the only to I had. I would be great to see them all scanned. The two I had were stapled in the corner so it was easy to remove the staple and run them through a sheet feed scanner.

  7. Posted

    Hey Dan, it's great to hear from a former JACS member! It's been a long time since I've seen you - you might remember me ;)

    I haven't see Bob Whipple in a long time. It's funny mentioning Bob's Beatles collection - I remember Bob showing me part of his collection once.

    PM if you want to discuss further. I still stay in touch with Mike Hopkins - you might remember him from JACS.

    Forrest

     

    Yes, I remember you, good to see you active on these forums. You should talk to Kevin about doing an interview, it would be good to have one with someone who helped run one of the user groups. BTW, do you have any of the JACS newsletters? I scanned the few I had and put them on archive.org, but it would be great to have more if you know anyone who has some.

  8. Posted

     

    Gregg Pearlman, ANTIC and STart Magazine

    http://ataripodcast.libsyn.com/antic-interview-221-gregg-pearlman-antic-and-start-magazine

    Gregg Pearlman was an editor at Antic Magazine and STart Magazine from 1986 through 1989.
    Antic magazine was devoted primarily to 8-bit Atari computers, with some emphasis on Atari ST computers. It was published from 1982 to 1990. STart magazine was dedicated primarily to Atari ST computers, with some emphasis on Atari 8-bit computers in later issues. It was published from 1986 to 1991.
    This interview took place on July 12, 2016. It in, we discuss Jim Capparell, whom I previously interviewed.
    Teaser quotes:
    "I said something like, 'Well, geez, I couldn't do this for less than 6 bucks an hour.' And I knew, immediately, that I had made a huge mistake."
    "Not exactly threatening, but he's like, 'Why don't you just fire me again?!' You know, it was desperately embarrassing."

     

     

    I was cool to hear the mention of the JACS user group since I used to be a member of that group. I also remember Bob Whipple who ran the group for part of the time I was there. It would be great if you could get an interview with him.

  9. Posted

    Is there a 64 bit assembly/disassembly package for the Atari 7800? I have only been able to find 32 bit ones, and they won't run on my current laptop.

     

     

    There shouldn't be any issue running a 32 bit app on a 64 bit machine, so it might not be the bit size that's the issue. For example I am running 64 bit Windows 10 and DASM runs just fine.

    • Like 1

  10. Posted

     

    Hello,

     

    For the last several weekends, I have been studying the 7800 docs, high quality AA forum posts including (but not limited to!) "HoleyDMA & Atari 7800", "Differences between Atari 2600 and Atari 7800 sprite colors?" and played around with the MAME emulator and the well-known "Atari 7800 sprite sample" demo by Daniel Boris (this demo was extremely helpful by the way).

     

    Now that I wrote down RAM/ROM addresses, checked memory dumps with MAME's excellent built-in debugger and memory window, I finally feel somewhat comfortable about DL and DLLs, "holey DMA", storing graphics upside down, etc. I believe I finally understand these concepts and how sprites are stored, displayed and moved. Although I have tons of things to find out and research, next thing on my list is experimenting with the various graphic modes (although I plan to stick with 160 resolution for the time being) and Indirect/Character mode.

     

    I am not completely new to 6502 asm. About ten years ago, I did a very simple demo for the NES. I've always liked Atari better and while the Jaguar is my favorite Atari console, I think the 7800 is more suitable for a first project. Right now I am only experimenting and playing, hopefully this will result in a real 7800 project later on.

    Some random questions that popped up:

     

    1) Sprite demo has DLs that take up to 64 (=40h) bytes for each zone, if I understand the following code correctly:

     

    DLPOINTH
    .byte $22,$22,$22,$22,$23,$23,$23,$23,$24,$24,$24,$24
    DLPOINTL
    .byte $00,$40,$80,$C0,$00,$40,$80,$C0,$00,$40,$80,$C0
    For the sprite demo I'd think 6 bytes would be enough (at max 1 object per zone=4 bytes + 2 bytes end DL list). Is this assumption/reasoning correct? (I did a quick test and it seemed to work, but would like to double-check if I understand these things correctly)
    2) I believe the Sprite Demo is updating the DLs even when nothing's changed. I'd assume that an efficient game will only touch the DLs if something had changed to spare cycles, correct?
    3) In 320x1 mode, that I believe Sprite Demo uses, sprites are stored like this:
    org $a000
    .byte %00111100
    org $a100
    .byte %00111100
    ...etc...
    I now understand why sprites are stored like this, but it still seems quite wasteful. I wonder whether (in this 320x1 case) i.e. bytes A001 to A0FF can safely be used to store game data?
    I have much more questions (for example, I don't know how to implement timers), but first I'll play around more first :)
    Thanks for being a great community! When I read the 7800 docs years ago, I thought I'd never master this, but I believe it is in my reach now, thanks to all great posts, articles, tools, sample code etc. on this (and other) sites.

     

     

    It's nice to see someone still using me sprite demo code!

     

    1. You are right, 6 bytes would be enough for each DL, but I setup the code presuming you would have more then one sprite in a game. To save memory you would want to size the DL's appropriately for your game.

     

    2. As Eric pointed out rebuilding only the DL's that change would be tricky. Not only will sprites move from one DL to another, they will often span two DLs. SInce most of the time you won't be able to predict how much needs to be re-built you need to allocate enough time in each cycle for the worst case anyway.

     

    3. Yes, you can use the memory for other things, but a lot of it will get filled up with graphics data.

  16. Posted

    Hey all. I'm starting this thread hoping to make a place to announce and discuss interviews with Atari people. This is sort of happening a little in various threads but it might be nice to wrangle it into a cohesive place.

     

    I do a lot of interviews for the ANTIC podcast, and Randy does many, and Rob at Player/Missile, and Wade at Inverse ATASCII has done one or two. Perhaps this thread can help you find interesting interviews that you might not have listened to otherwise.

     

    Kevin,

    Have you thought about trying to get an interview with any of Jack Tramiel's sons? That could be a really interesting interview.

  17. Posted

    I love this document from the Sorcerer file. :)

     

    It is interesting how much debate there was over the title of this game. Maybe it's just because I am used to it, but I always thought Enchanter, Sorcerer, Spellbreaker were good names for the trilogy.

     

     

     

    Date: 9 Nov 1983 1104-EST
    From: David G. Anderson <DA at ZORK>
    Subject: Re: Z5 and G/R
    To: SEM
    In-Reply-To: Your message of 9-Nov-83 1024-EST

     

    ********* D/A RESEARCH REPORT ********
    After interviewing every man, woman, child and all other life
    forms on earth, our research suggests: All six names totally and
    compeletely suck. Selected excerpts from interviews:

     

    "Spellbreaker sucks."
    Bob Thompson
    Computerland, Middle, Va.

     

    "The name Spellsaver reminds me of lifesaver, and I'm one to fidget
    when I play Infocom games. ..so that name sucks the big one."
    Rudy Boggs
    Swampland Software, Swampland TN

     

    "Damn it Jim, they can't use Transporter. That's ours. Besides, it
    sucks."
    Dr. "Bones" McCoy
    S. S. Enterprise, Space

     

    "Spellstalker reminds me of the television show Nightstalker, so
    it's been used. And that show sucked just like the name
    Spellstalker."
    Freddie Silverman
    Former president, ABC TV

     

    "Nobody knov/s anyone is Possessed until the end. That name really
    sucks. I wouldn't even use it."
    Scott Adams
    Adventure International, Florida

     

    "...except for the fact there is no reference to sorcerer, it sounds
    okay with me. With one exception, the name sucks."
    Turtle, Enchanter

     

    There you have it. A random sampling of responses from our survey.
    We look forward to serving you again in the future.

     

    Enclosed please find 1 invoice.

    D/A INVOICE
    ITEM QUANTITY PRICE
    Interview with every man, woman, 1 $857 Trillion
    child and all other life forms
    on earth.

     

    Approved, DA

     

    Note: We checked with cross-town rivial G/R on this price. They quoted us a price of 858 Trillion.

  19. Posted

    A long time ago I had dumped a bunch of my old Atari 8-bit disks, but at the time I couldn't find a tool I really liked for exploring the content of these images, so I decided to write my own tool. Over time, as I got into other 8-bit related projects I added more features to the tool as I needed them and at some point porting it from the original VB.NET to C#. Eventually I realized that I had taken this tool so far that other people might find it useful so I decided to clean it up and make it into something I could release. By other reason for releasing this is to also provide a .NET library for Atari disk manipulation that others could use to create their own tools. To that end I built the tool with all the disk images code in a separate library and am releasing the full source under the GPL 3 license.

     

    If anyone finds and problems or wants to suggest features please let me know. Here are some of the features if currently supports:

     

    • Supports XFD and ATR disk image formats
    • Supports DOS 2.0, DOS 2.5 and MegaImage file systems
    • View boot sector details and disassmbly
    • View sector data in ATASCII format
    • View disk directory even for disks with non-standard directory location
    • Add, delete and extract files from a disk, including extraction of all files at one time
    • View file contents in Hex or ATASCII
    • De-tokenize Basic files with ATASCII display, and extract in ASCII formats. Handles some forms of Basic file protection
    • View Syn Assembler files
    • View the sector map of a DOS disk
    • View the boot record of a disk along with the dis-assembly of the boot code

    You can download the installer and source herE:

     

    http://atarihq.com/danb/atari8bit.shtml

    • Like 15

  20. Posted

    Thanks for the quick reply Dan!

     

    That explains a lot about what's happening in 2600 mode. I'm still not sure how the lock bit gets set in 7800 mode since the code that is executed before it jumps to the start of the cartridge is:

     

    LF7B9: LDX #$16 ; finally, back to something important

    STX INPTCTRL ; switch out bios and use reset vector

    TXS ; on cart to start the game.

    SED

    JMP(LFFFC)

     

    Unless the lock bit is set somewhere else, which wouldn't make sense because that would yield this write to the control register pointless.

     

    I took a look at the source code for a couple 7800 games and they all lock the system into 7800 mode at start up. This makes sense since the 2600 games obviously would not know to do this, but 7800 games would have been programmed to handle this.

  21. Posted

    Hi guys, I'm new here, but my friends and I are designing a fully functioning Atari 7800 for a college class. Our design will be synthesized on an FPGA.

     

    I've looked all over the internet and can't seem to solve my confusion over the Hidden Control Register. I first learned about it on Dan B's post here https://sites.google.com/site/atari7800wiki/7800-control-register

     

    Seems pretty simple, but this explanation seems inconsistent with the BIOS code located here http://www.atarihq.com/danb/files/7800bios.asm

    My understanding is that anytime a value is written to INPTCTRL, it is writing to the Control register.

     

    Firstly, many times, the value #$16 is written to the control register, but I thought the control register was a four bit value. What is the purpose of writing a 5 bit value to a 4 bit register?

     

    Secondly, during execution of the code located at LF7D4 (though the code is actually executed from the RIOT RAM as part of the Atari 2600 initialization), there are stores and loads to TIA registers even though the lock bit on the control register has not been set. This isn't consistent with the idea that the control register can be written by storing to any address from $00-$1F.

     

    Lastly, the control register lock bit never really seems to be set. The only time I can find it set is at LF880, but that is when the self-test fails. I would expect the lock bit to be set in both Atari 2600 and 7800 initialization before we do an indirect jump to the start of the programmer's code. I suppose it's possible that the programmer is expected to set the lock bit, but it doesn't make much sense to require the programmer to do that.

     

    Can anybody shed some light on these questions? If not, is there anyone I might be able to contact or any other forum I might be able to post to?

     

    Cheers!

     

    Looking at the schematics it appears that any writes to the TIA addresses go to both the control register and TIA, this would explain the writes to the TIA you are seeing. I am not sure why they are setting bit 4 ($10) when writing to the control register. Maybe this was something that was going to be used but they changed their minds. The lock bit would be set by this code before going into 2600 mode...

     

    LF831: LDA #$FD

    STA COLUPF

AtariAge
Forums
Store
General
Follow AtariAge

Copyright ©1998-2021 AtariAge

×
×
  • Create New...