DanBoris
-
Content Count
1,086 -
Joined
-
Last visited
Posts posted by DanBoris
-
-
Dan,
I had forgotten about this thread. I actually knew this as I'm friends with JoseQ on FB and follow him. Yes he starred in a new movie that details the inner conflicts of the engineers before the shuttle Challenger disaster.
Yeah, that's how I learned about this, I saw the trailer for the movie and it lead me down this rabbit hole.
-
Vinnie,
Believe it or not, some of us still login to the old Emuviews chatroom from time to time to through a quick status update on our lives...etc. Yes, the emuviews website is still up and running and up until about 2 or 3 years ago, it was the host for my OVGE website as well. I wonder how ole JoseQ is doing these days?!
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&
-
Wonder why nobody mentioned the great "intermission" of "Drol" yet...
If you want to talk about intermssions, my favorite was the ones in Astrochase. Don't know if I ever saw all of them.
-
You clearly didn't watch the entire video
Or you could just tell us.
-
Approaching the end of the hiatus here! I'll have a new episode out this month, and hope to return to a (somewhat) regular schedule.
In the pipeline:
Episode 21: May 1982 [????: a surprise game!]
Episode 22: June 1982, Galahad and the Holy Grail
Episode 23: July 1982, theme music special*
Episode 24: August 1982: some sort of C64 comparison episode as this was our rival's release date
I'd really like to do some sort of survey of game themes, but I'll need help to do it. Ideally, it would be music of games from 1982 and earlier, so if you have ideas for games, let me know. Even better, if you can send me audio clips of the music from those games, it would improve the odds of this actually happening.
It will be great to have you back!
-
1
-
-
Mmmm...sounds logical....I wonder when ANTIC will go in hi tri-state then.......thanks for that link, very clear explanation of a lot of things,....but in the end.... I still don't know when ANTIC actually decides to send the HALT to Sally. I think it might be when something is written to DMACTL register ?
I just experimented with switching NTSC and PAL ANTICs. Must say that the feel of speed on f.i. Donkey Kong is the same when a NTSC ANTIC is in a PAL PCB compared to a full NTSC machine......I can't tell the difference of the main clock. Because I'm stubborn I also exchanged the main crystal between the systems and surely enough, as expected, you lose the color....
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.
-
Read the datasheet but it appears to me that all address lines are tri-stated ?
Now....when actually does ANTIC decide to activate the HALT ? How is the tri-state condition (high Z) activated on ANTIC ? is there one pin responsible for this or is this an internal process ?
Would removing the input clock(s) activate the Hi-z state on address- and databus ?
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
-
1
-
-
Wait a minute.....ANTIC can't write to memory so it never writes on the databus....but it does put addresses on the address bus but only does so when it has HALTed Sally, right ? And POKEY, PIA and GTIA are just slaves, they never put address on the addressbus.....
So....am I correct that following this there is no need for tri-state buffers on ANTIC ?
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.
-
1
-
-
Than wikipedia is wrong. It says it's an output on the GTIA...
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.
-
2
-
-
Oh wait.....there are thri-state buffers....looks like the busses ARE isolated from the 6502 when ANTIC is on the bus....which makes sense.
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.
-
2
-
-
But I'd actually want them to do the same thing....well....let's say they will run in "parallel" but only "output" would be "selected".
I'm thinking of switching all lines of both ANTIC and GTIA. But I'm pretty sure a lot of them won't be necessary to switch. I'd like to find out which one's I could simply hard connect without damage or mess-up....
If they are both doing the same thing, why would you want two of them? Not sure what you goal is here?
-
Yeah sorry guys, my address/databus, three-state etc. knowledge has sunk away badly I'm afraid
Suppose now, that I'd like to have 2 ANTICs and 2 GTIAs in my system and make them switchable.....
Jurgen, from your reply, purely electrically speaking...would connecting two ANTICs to the addressbus (and databus) cause problems ? I understand they both will respond at the same time when addressed ....could I use some logic with one of the address lines switched to select one of the two "piggy backed" ANTICs ? (Also ignore all the other lines for now....I know most will need to be switched).
I assume with GTIA not. You can easily only switch the CS signal, right ? And simply directly connect the address and databusses.
So I'd either need to switch all data/adress lines for ANTIC or....could include a decoding logic to select on of the two ANTICs ?
[EDIT] ANTIC isn't a real processor in the way that it doesn't write back to memory right ? So...it only reads from memory if I'm correct.
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.
-
1
-
-
I've always wondered if it would be possible to link 2 7800s together through the expansion ports and maybe play a custom version of Pole Position II head to head! Or a special 4 player version of Ballblazer!
Just dreaming here...
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.
-
M.A.M.E. has to hide behind something. Might as well be "preservation". But it only does half of the preservation, nowhere near full. Because the other half is the roms. Roms that you have to go off on a hunt for. So imagine the plight of the future digital archaeologist. the poor sap is going to have to continue searching like we do today.
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.
-
4
-
-
When you have mame running on different devices that use different base versions of mame (slower devices requiring older versions of mame), and are interested in emulating maybe 20-30 games, then managing those roms is a nightmare. The roms are not versioned in any way, which makes it hard to figure out which rom works with which emulator except through trial and error. So I don't know why they can't be versioned with a dump revision. (you have pengo dump v2, this version of mame requires dump v4) even that would help a lot.
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.
-
2
-
-
That makes sense. Still it surprises me that they can find people interested in emulating some really obscure pieces of coin-op hardware but can't find anyone interested enough to fix the fairly mainstream systems that are still broken in the MESS portion.
I would disagree a bit. I think what they should do is give the user a warning to the effect that this romset is deprecated and may be discontinued in the future if the code that supports it breaks. For the most supported romset, obtain "xx"
And the romset names should never change, instead they should be appended with a dump revision like pacman pacman_d02 pacman_d03. That would minimize all the confusion of which romset named "pacman" goes with which version of Mame, and what does it need to be named to work-- which causes so much frustration right now.
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.
-
1
-
-
I've often been baffled by the priorities of the Mame team. It's like they want to add emulation for everything under the sun, even if it's not video game hardware, but then they never seem to go back and fix broken emulation they added in the past (like Jaguar)
But in spite of adding all that bloat, they can't bother keep the code that would allow users to still load their old rom-sets when newer dumps become available. This has been a major headache for upgrading Mame
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.
-
3
-
-
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
-
1
-
-
I've been kicking around the idea for a while of using the disk images of classic games as datasources for remakes of those games. Games must have databases on the disks that layout things like towns and dungeons, npc dialogue, quest parameters, platform levels, etc. If those regions could be identified in the disk images, read as data, and then used to drive a modern game engine, it could be interesting. SCUMMVM does a very similar thing, reading the original data (usually from files, instead of disk images) and rendering the graphics and sound on modern platforms.
Thought? Crazy? Not worth it? Amazing idea?
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.
-
I know you can turn on or off the key click (POKE 731,0 or POKE 731,255), but I'm wondering if it's possible to generate the key click sound on command? Is there a bit of code to call from basic, or possibly a way in basic to generate the same or very similar noise? I don't remember my sound coding from back in the day or I'd probably be able to figure it out myself. I don't mind cheating by calling the existing key click routine
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.
-
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!
-
1
-
-
A friend brought his 800XL to me a couple of days ago saying that except for the Break key, the keyboard
was no longer working. The computer boots to a ready prompt, loads DOS if a drive is attached, passes
both self test and Super Salt tests, and plays cartridge games without any problem (so long as no keyboard
input is required). The five function keys on the right work and the power LED lights up). Sounds like a
keyboard to me; but here is the strange part... if you hold down any key for awhile, the cursor will suddenly
drop down to the next line like its reached the end of line. It never moves to the right, you never hear the keyboard 'click', and nothing else
appears on the screen. If you move the cursor down enough times the READY message will scroll up off the
screen. I'm thinking either Pokey, GTIA, or possibly Basic. Let me hear any suggestions you all might have
before I order a replacement chip(s).
Thanks,
DavidMil
Kingwood, Texas
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.
-
I was a huge fan of this game on the Apple II. This is such a great idea. You can not only export but once you figure out the full spec it could be used for a modern adaptation of the whole thing (by adding more options and gameplay).
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.
-
Back in the day I way always fascinated by Stuart Smith's Adventure Construction Set which sadly never got ported to the Atari. A while back I started to play with the MSDOS version and decided it would be fun to reverse engineer the game file format. It turned out to be a much bigger project then I though but I finally have something to show for the work. I used the information to build a Adventure Construction Set file viewer and have released it along with the C# source code. I also put together a very early draft document of the file format, but the source code is currently the best reference for the format. All this can be found on my web site:
-
1
-
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Atari 400/800 40th Anniversary Celebration at VCF East
in Atari 8-Bit Computers
Posted
This sounds great, Atari has often been under-represented at VCF East. I will definitly have to get there this year.