Jump to content

JetSetIlly

New Members
  • Content Count

    32
  • Joined

  • Last visited

Community Reputation

30 Excellent

1 Follower

About JetSetIlly

Contact / Social Media

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Well spotted. These are the references: "Artificial Intelligence", by Patrick Henry Winston https://courses.csail.mit.edu/6.034f/ai3/rest.pdf (I think that must be a later edition because the page number she references isn't meaningful.) "Some Studies in Machine Learning Using the Game of Checkers" http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.368.2254&rep=rep1&type=pdf
  2. Carol Shaw has uploaded photographs/printouts of her original source for Video Checkers to the Internet Archive. Not had chance to read it yet but it's fully commented by the looks of it. https://archive.org/details/VCScheckersA/page/n1/mode/2up Exciting stuff
  3. First effort at CRT post-processing: * suggestive bend on the screen * scanline shadows * color separation TODO: * scanlines to follow tube contours * meaningful color separation * anti-aliasing * phosphor fade Still getting to grips with GLSL but it's okay I think.
  4. Also this post from AtariAge in 2008. on edit: my mistake. on second reading, that post is talking about reading rather than writing.
  5. It depends which RAM mirror you read from. In the case of the primary mirror, allowing the PC to get to $0100 will mean the next instruction loaded is an ORA command (byte code $01). That's without collisions. With collisions, the opcode will variously be $11, $21 or $31. None of which would be particularly useful. As far as I can see, there's no useful mirror/opcode/collision combination that would result in a branch command or jump command. Which is a shame, because that might actually be useful.
  6. Ahh. Okay. That makes sense. My next step then, is to add the code that will set the PA7 when the correct conditions are met. Yeah. It is slow. That's partly a consequence of the choice of language (garbage collecting etc.) Sorry about that 😕 The project began as a learning exercise (for both the language and the 2600) and I never expected it to get to the stage it is. Thanks for trying it out though, that pleases me greatly.
  7. I've been playing with these ideas this evening and they seem to fix the timing issues I was seeing in https://github.com/stella-emu/stella/issues/108 . I now get the correct values as reported to be seen on the real hardware. Just as a point of note, when setting a new timer, the bit pattern that is used to clear TIMINT seems to differ depending on whether TIMINT is already off or not. As far as I can tell, if TIMINT is currently on, it is cleared with but pattern 0x00. If it has already been cleared it is given the bit pattern 0x40 You can see this difference in test2.bas.bin and testTIMINT_withDelay.bin In test2.bas.bin if TIMINT is cleared with 0x00 then the incorrect value is written to RAM register 0xd7. When 0xd7 is later tested for the overflow bit it will never reach the correct branch. This results in the incorrect number on the display (000249 instead of 064249) It would be nice to see the schematics for the RIOT chip to see what's going on and whether it matches the observations. on edit: this is of course, wrong. the difference is to do with PA7 interrupt. more edit: if we say the pa7 flag is set at startup (ie. before TIMINT is ever read) and only reset when TIMINT is read for the first time, then that satisfies all the timer test cases.
  8. Out of interest, where does the value 276 come from?
  9. He-Man is a good example of this technique too.
  10. I've not tested what happens when it reaches 99. That's your challenge 🙂
  11. Haha. Ta. It's a dumb game but I got fun out of writing it and it's fun to play.
  12. Before working on Gopher2600 I created a version of Flappy Bird as a way of learning about the 2600. I've uploaded the source code to GitHub. Nothing special but I think it's fun. https://github.com/JetSetIlly/Atari2600-Flappy-Bird (Screenshot taken through Stella because Gopher2600 doesn't support TV effects yet. The game really needs phosphor fade due to my excessive use of flicker.) flappy.bin
  13. I've been hard at work getting together the graphical debugger for Gopher2600. As you can see from the latest screenshot below pretty much everything is now accessible through a GUI. The line terminal is still available and can be still be used for more "advanced" operations, such as watches, scripting and more complicated breakpoints (simple PC breakpoints can be added by double clicking in the Disassembly window). Source code and x86 linux binary on Github https://github.com/JetSetIlly/Gopher2600/releases/tag/v0.1 My next step is to use the debugger to help me develop a 2600 ROM/game. That way I can see what other tools will be helpful. I think the framework I've developed is pretty flexible so it should be easy to add specialist features as and when needed.
  14. It's interesting that Stella can let the CPU run for many cycles before the rest of the VCS "catches up". Am I reading that correctly? The approach I've taken in gopher2600 is a very strict three TIA ticks for every CPU tick, as and when the CPU tick happens. I'm a little surprised it can work any other way TBH. Are there any advantages to Stella's approach?
  15. Are there any non-test ROMs (ie. games) that rely on this behaviour?
×
×
  • Create New...