Jump to content


  • Content Count

  • Joined

  • Last visited

Everything posted by DanBoris

  1. This sort of reminds me of the algorithm the Telengard uses to generate it's maze. It uses a algorithm based on your current location in the maze and three hard coded constants. They must have had to hand tune those constants until they got acceptable mazes. You can read the details here: http://atarihq.com/danb/Telengard.shtml
  2. This sounds great, Atari has often been under-represented at VCF East. I will definitly have to get there this year.
  3. Yeah, that's how I learned about this, I saw the trailer for the movie and it lead me down this rabbit hole.
  4. I hate to bump and old thread but I just stumbled across the answer to this question. Looks like JoseQ went into film-making as actor, director, writer, producer, etc. https://www.imdb.com/name/nm5256812/?ref_=fn_al_nm_1 I was friends with him back in my emulator author days and he used to host a web site for me. When I saw the name on IMDB I figured it was unlikely the same person, but I am connected to him on LinkedIn and his photo there matches one of his resume photos.. http://www.lmtalent.com/page/texas_talent?talentid=2160&name=Jose%20Quinones&
  5. If you want to talk about intermssions, my favorite was the ones in Astrochase. Don't know if I ever saw all of them.
  6. ANTIC sends the Halt when it needs to read from memory. These memory reads happen at specific times during each scanline. As the documentation I linked to shows, the exact pattern on the memory reads is dependent on the scanline graphics mode and other configuration settings.
  7. I would assume the address bus would be in input mode whenever it isn't halting the processor since it needs to decode the bus to check for register writes. As for when it activates Halt, check out the Altirra Hardware Reference which has a lot of information about ANTIC timing. http://www.virtualdub.org/downloads/Altirra%20Hardware%20Reference%20Manual.pdf
  8. The address bus on the ANTIC is used for both input and output, so when it's not doing output there would be internal circuitry that would stop if from driving the bus so it can read from it.
  9. Probably because it's also wrong in the pin list in the official Atari documentation, but it is correct in the pin characteristics list and the GTIA internal schematics show it as an input.
  10. Yeah, the 400 and 800 have the tri-state buffers. The XL and later systems have a special version of the 6502 called the "Sally" which has the tri-state buffers built in.
  11. If they are both doing the same thing, why would you want two of them? Not sure what you goal is here?
  12. In theory you could probably have two ANTICs on the bus at the same time but they would always have to be doing exactly the same thing. You could probably come up with some logic to address one or the other, but the problem is when they go to read from memory to fetch video data. Unless they were doing exactly the same thing, they would push different addresses onto the bus which would totally mess things up. You are correct that the ANTIC doesn't write to memory, it only reads.
  13. The expansion port on the 7800 only brings out video signals and a couple misc control signals from the CPU so there is no way to use it for interfacing. The joystick ports on the other hand can be configured for either input or output so in theory you could connect two machines through their second controller ports.
  14. Why do you feel the team needs to "hide" behind anything? Preserving ROMS is a totally different thing that comes with significant legal challenges, not something a team of volunteer developers want's to deal with. MAME does the next best thing, and provides a tool that can verify that the ROMS you have found are what was in the original machine. I got involved in the MAME development close to 20 years ago, and I have seen these type of "attacks" on the project since day one, but I can never understand people who attack the project because it doesn't work they way they want it to. MAME is written by a group of hobbyists that do it because they enjoy doing it, and they do what they want to do. If people don't like it, they don't have to use it, or they can go off an try to write something better (which has happened in the past). Constructive criticisms is fine, but statements like "they're doing some bullshit development system" and "Some idiot with "pet-project" mentality" are by no means constructive.
  15. Because you are assuming that the primary goal of MAME is to make an emulation platform that is easy for everyone to use which is not the case. The preservation aspects, In most cases, take precedence over user experience.
  16. Not really surprising at all, emulating a system from scratch is fun, debugging someone else's code, not so much. What you suggest about the roms just makes things more complex from a development standpoint. Since the goal is to preserve the most accurate rom set possible, it makes sense to drop support for something that is not the best known set.
  17. The way thy MAME team worked in the past when I was active, and I assume it still works this way, is that there are just a large group of people who contribute the game/system drivers and they work on whatever most interests them. There is no one handing out tasks for people to work on so there is no single entity setting priorities. If someone worked on a driver for a while but lost interest before the bugs were worked out, no one is going to tell them they have to finish that before they move on to something else. Not supporting older rom-sets is actually a good thing, since it encourages people to get rid of the inaccurate sets thus helping to preserve the more accurate ones. In an ideal would you wouldn't want any invalid ROM images to be floating around on the net, only ones that were correct.
  18. I am trying to thin out my collection a bit and have a bunch of ST Log Magazines that I would like to give to a good home. The list of issue dates is below. If you are interested please private message me. Dan 3/89 1/89 11/88 10/88 8/88 7/88 6/88 4/88 9/87 7/87 6/87 5/87 4/87 2/87 12/86 11/86 10/86 9/86 8/86 7/86
  19. This is very common for PC games, there are a lot of re-creation projects that use new code along with game data from the original games.
  20. The keyboard speaker is controlled by writing either a 0 or an 8 to the GTIA register at address 53279 (D01F). This simple pushes the speaker cone out or pull it back in, so you have to continually change the value to make a sound. You can do this through BASIC, but you really need machine language to control it effectively.
  21. One of the most frustrating situations I remember running into when writing and emulator was this: - Game A doesn't work, game B does. - Troubleshoot the problem with A, implement fix - Game A now works, but game B no longer works! I specifically remember having this come up in both my 2600 and 5200 emulators. I also remember back when we didn't have a full understanding of how BCD math was supposed to work in the 6502, until some eventually documented the exact behavior of the CPU flags. As for one specific emulation challenge, the mathbox processor in I-Robot!
  22. Sounds like a problem with the POKEY chip which does the keyboard scanning. The Start, Select, Reset and Option keys are handled by a different chip. The break key is handled by the POKEY but in a different way then the other keys which might explain why it works.
  23. The viewer tool actually does have the beginning of play functionality which is just limited to moving around the map at the moment, but I would like to expand it further in the future.
  • Create New...