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

jaholmes

Members
 View Profile  See their activity

  • Content Count

    36

  • Joined

  • Last visited

Posts posted by jaholmes

  1. Posted

    Not necessarily jaholmes, Bb and the ASDK present framebuffers to the lazy developer where they can plot pixels in a very small memory footprint.

     

    I was just talking about the amount of command data streaming by, not the size of the buffers needed. However, a mutable 12x12 byte array--assuming you want full color pixels--is already beyond the capability of the Atari 2600 hardware. 96x192, as just a random pick, would be nearly 20kb. I'm not sure what trickery could be used to work around the need for some (relatively) fat buffers in that case--at least in the MCU address space. The command buffers obviously needn't be anywhere near that large.

    • Like 1

  2. Posted

    Cool! That makes plenty of sense. How do the buffer sizes correlate with the cartridge address space, do you think? I guess they wouldn't need to be very large, as they could be filled extremely quickly by your IRQ handler from a single, logical staging area in the MCU's RAM. Perhaps their size is chosen to keep your FPGA cheap. I'm imagining a situation where a C++ developer wants to think of the screen as having a frame buffer associated with it, and wants to just start plotting pixels all over the place without regard for the beam. Obviously, if you wanted to support such a thing, then we're talking 10's of kbs worth of commands and multiple buffer swaps and refills, which a lazy C++ dev might want hidden from him/herself.

  3. Posted

    Yeah, I was thinking the former, although the logger solution might be better. But if you bring out the results of two completely independent tests--one for a known address, another for known data at that address--as two pins, I think you'd get a good picture of the relative timing. Of course, your known data might appear at other addresses, but if your scope is triggering on the address, that shouldn't matter.

  5. Posted · Edited by jaholmes

    If the VHDL code is doing what I think,it should already be latching the snooped data. I don't think it's a problem because the address bus changes before the data bus. When the address bus changes the data is latched. I could be completely wrong though.

     

    regarding the ink and sticker. That was a $3 TV from the thrift shop. I suppose I could remove the price tag.

    Nah, leave it on. Adds character. :)

     

    On the latching, I'm just wondering about these things:

    • As implemented, I believe you have a transparent latch, so as soon as the address matches SWCHA's %0001010000000, your LEDs start to reflect whatever is on the data bus. Which, at that point, is probably nothing you want to see. From a look at the 6532's timing diagrams, the address could easily become valid 300-400ns before the data bus stabilizes, so you could be seeing ~400ns worth of garbage. Or maybe just nothing. Since the LEDs in the video look stable, I'd tend to guess it's the latter. A scope would obviously tell.
    • Instead, you could do an opaque latch only when the address transitions away from %0001010000000, but you would need to guarantee the validity of the data at that point, which from the timing diagrams, is a tad troublesome. The 6502 appears to stipulate a minimum 10ns "hold time" on the data bus before the address bus goes invalid, however the state of the data bus after the address bus goes invalid doesn't have many guarantees attached to it. At that point, one begins to wonder about the propagation delays in your 74LS245s, which have no documented minimum, but can go as high as 12ns. Stick a fast one on the address bus and a slow one on the data bus, and you're probably in trouble.

    It's a pity that Phi2 isn't brought out to the cartridge. That would be awesome. Without it, it seems like a worthy endeavor to reduce the propagation delay of your logic level translation circuitry as much as possible. 10's of ns might bring about interesting or "impossible" data.

  6. Posted · Edited by jaholmes

    Very cool! (Separately, you may have to share the story of the tag and ink on your TV screen, and why you haven't removed them. :))

     

    One thing that springs to mind, though you've probably thought of it: The final versions of your "stuff" and "snoop" operations are going to require some calibrated delays. There may be a very nontrivial gap, for instance, between the appearance of a valid address and the reasonable assumption of valid data--easily a half-cycle or more. While you're reflecting the data lines to LEDs, this is pretty irrelevant, but when you're trying to latch a value for future use, it'll be harder.

     

    But perhaps not all that much harder, assuming the FPGA is clocked like 10x+ the rate of the 6502.

  9. Posted

    And just for kicks--for those situations where C++ just doesn't feel 'retro' enough, and yet you still want a somewhat casual development experience--you could drop a 6502 core into your FPGA. :) Clocked at 32+MHz, you're sure to win the beam race, even with the sloppiest of coding. You could name the cartridge simply "Overclocked", and the label artwork could be a photo of a heatsink/fan assembly. :)

    • Like 2

  12. Posted · Edited by jaholmes

    This sounds like a neat project with a lot of potential. I guess I'm still wondering what it actually means to "stuff the bus", though. Except in situations where a ROM would normally drive the data bus, you wouldn't be driving any busses, and so you're really just emulating a ROM. Presumably you'd have some set of well-written template kernels--chunks of 6502 machine code with all the operands missing--which would be populated in realtime by the FPGA based on some "operand memory", which would be the analog of the TIA from the standpoint of the ARM code. Or am I off in the weeds?

     

    Actually, thinking about this some more, you'd obviously need to be a bit more than a ROM emulator in order to deal with input, for instance. I guess, since the FPGA would know when it had just handed the CPU an instruction to read from the RIOT's address space, it could snoop the result from the data bus directly when it saw the address go by. There'd be no need to preserve the resulting register state in the 6502; the next instruction could safely blast over it. Hmmm... the possibilities...

  13. Posted · Edited by jaholmes

    Hi, ResolaQQ - That's very cool!

     

    I think people tend to disparage new emulators in situations where mature ones already exist, but emulators are fabulous computer science projects, and taking the time to produce one is something worthy of admiration. Back when the NES emulator scene was exploding in the late 90's, I accepted the challenge and wrote my own NES emulator--of course, with no shortage of prior art to benefit from! It really expanded my appreciation for these machines as well as for the game developers.

     

    I never released my emulator, named Syntendo, because the sound emulation never reached a state I could be proud of, and the sound of those old games was a big part of my own enjoyment. Ironically, the name Syntendo was shortly thereafter taken by somebody else for a project that emulated nothing but the NES's sound chip. :) (Guess we just need to glue the two halves together!)

     

    I hope you'll keep working on and enjoying your emulator project!

     

    Take care,

    Aaron

    • Like 1

  14. Posted

    I suspect the INC WSYNC thing might be similar to on the computer... it asserts /RDY but the thing with that signal is the 6502 will allow any pending writes to occur before recognising it, the behaviour is deliberate to allow such read/modify write instructions to be able to complete properly before the CPU is snoozed.

     

    Ah, that makes sense. I suppose WSYNC was a bad example!

     

    How about setting the stack pointer to the address of some TIA registers and executing a BRK. :)

     

    Could you link to the topic you pulled that quote and image from?

     

    +1

     

    Electrically, it's difficult to see how the CPU address and data lines could be manipulated in this way. Is this perhaps talking about manipulating the TIA's internal address and data lines?

  15. Posted · Edited by jaholmes

    Sheet #2 of the TIA schematic shows that all of the data and address lines coming in are latched at the start of a write cycle, so changing the address in the middle wouldn't have any effect as far as I can tell. Also, unfortunately, the address and data lines drive both high and low, precluding any obvious attempts and bus-mastering from the cartridge. Hmmm.

     

    There might be some interesting read-modify-write exploits. Does 'INC WSYNC' cause you to wait for two HBlanks? I would think that it would. Not that such a thing would be all that useful, but maybe there are useful ones...

  16. Posted

    The reason, as stated in post 68, is Melody Version 1 has the parts that are used for a certain circuit that all Harmony carts have.

    Most Melody carts have this vestigial hardware and also allow SF2 to run.

    Version 2 Melody boards removed these parts as they were not even used, but it turns out that having them there prevented this brownout situation so even though those parts weren't used, they caused something unintended to happen which made Stay Frosty 2 run.

     

    Gah! Thanks for pointing that out. Batari's post started out with a bit of a speculative tone, which caused me not to read all the way to the bottom. I see now the error of my ways.

  17. Posted · Edited by jaholmes

     

    I have a new-to-me Light Sixer with a red Atari Service label on the bottom; I suspect it was a factory repaired unit at some point in its history. When I take it apart to examine it this weekend, I might be able to confirm this one way or another.

     

    Just to be clear, and per the "please ignore" in my previous post, I've confirmed through examination of photos and diagrams in the Field Service Manual that the "inductor and capacitor over C201 and R206" in the Manual is not referring to the inductor Albert is referring to. So definitely don't perform this Atari-suggested modification expecting it to resolve the Stay Frosty 2 issue. I don't think it's related.

     

    But it is interesting anyway. :)

     

    I still look forward to knowing the Ultimate Answer to the Stay Frosty 2 issue.

  20. Posted

    Google and Bing image searches haven't been as productive as I'd expected. I was hoping to avoid tearing apart my heavy sixer just to answer a few basic questions about component layout, but most of the photos I'm finding of the motherboards just aren't all that great. Anybody know where I might find a few really nice motherboard photos? Of a six-switch unit! Doesn't have to be a "heavy"; any sixer will do.

     

    Thanks,

    Aaron

  21. Posted · Edited by jaholmes

    (EDIT: Please ignore this post; I found this picture which clearly shows the location of the FSM mod below to be different from the location of the mod Albert discusses earlier. The FSM mod location lies between the 6507 and 6532.)

     

    Actually...

     

    (Sorry for the double post!)

     

    ...is the sixer mod being discussed here the same one discussed in Field Service Manual? In section 3-2 of the FSM, I see the following:

     

     

    Atari requires each 2600/2600A model returned for service to be checked for certain conditions. In some instances, a unit must be modified to conform to Atari standards. These changes are summarized below:

    • (snip)
    • Check for an inductor and capacitor over C201 and R206. Cut the inductor and cap out, being careful not to cut C201 or R206 leads.
    • (snip)

     

    If so, then I guess it's worth mentioning that Atari's solution was to remove, not bridge, the inductor. Although it would be great if somebody with a board in front of them could confirm that this is the same inductor. Anybody?

  23. Posted · Edited by jaholmes

    That's interesting. The board on this one has the heavy plastic. I love it

    Here's an interesting thread. Check out the first post, too, however the post I'm linking to is another instance of a Sears Tele-Games light sixer with what appears to be "heavy" guts. The board is tan, unlike your green one, but is otherwise very similar. (It has the additional capacitor and resistor, the finned heatsink on the regulator, etc.--characteristics the first post in the thread associates with heaviness. :))

     

    Very interesting stuff!

     

    It's hard to know what to make of it all. I don't think it's quite as cut-and-dried as the first post suggests, as others in the thread describe sending in light systems for service and getting heavy boardsets back, or sending in heavy systems for service and getting a light cases back.

     

    I guess the most important thing would be: Have fun with it!

     

    One of my best friends growing up had a Tele-Games sixer. Lots of fond memories...

  24. Posted

     

    Which 2600 games didn't work on a Gemini?

    Oh boy... *strains to remember*... I seem to recall Astroblast was one. IIRC, it would frequently hang or start up in a unresponsive state. There were a couple of others that consistently misbehaved. Whether these were software compatibility issues or physical issues with the cartridges--or something else--I can't know for sure at this point.

  25. Posted · Edited by jaholmes

    The Coleco Gemini!

     

    Ok-ok-ok, the Atari 2600. :)

     

    But, when I was five years old, I got a Gemini for Christmas, not a 2600. The Gemini was plenty good, except when I'd borrow a 2600 cartridge from a friend and discover that it didn't work. That was rare, though. I do have an actual 2600 system now, but it's a recent eBay purchase.

     

    I don't really have a next-favorite Atari system, unless you count the Atari 800 (My uncle had one, and when I'd visit him, that's what I'd play).

AtariAge
Forums
Store
General
Follow AtariAge

Copyright ©1998-2021 AtariAge

×
×
  • Create New...