DanBoris
-
Content Count
1,086 -
Joined
-
Last visited
Posts posted by DanBoris
-
-
Yeah, but you need WinZip to unzip them.
I think you will find the most people who are playing around with roms and emulators probably have an unzip utility installed. There are plenty of totally free ones available for example 7-Zip
The ROMS might be zipped to save on bandwidth costs. Looking at Adventure the zipped file is 1K smaller then the unzipped file. This is not a big deal on a single download, but if you get 1000's of downloads it starts to add up.
Dan
-
Taking a shot in the dark, are you trying to run these emulators by double clicking on the executable? If so that might be part (or all) of your problem. A lot of emulators must be run from a command line, I know that MESS and the Odyssey 2 emulator work this way. Be sure to read the documentation that comes with the emulator carefully, it will usually explain the proper way to run it.
Dan
-
Has anyone ever actually seen a system or game destroyed by frying? I've never seen or heard of it and I've fried up several 2600s.Although I have never actually seen a system damaged by doing this I can think of at least two logical ways this could damage the system. First, and most obviously you could physically damage the power switch. Secondly, the time when power is being applied to an electronic circuit is when it's under the greatest stress, so the rapid powering on and off may not necessarily kill the hardware but it could accelerator its failure.
Dan
-
You can get most of that information off the parts list in the operators manual. You can find a copy here:
http://www.arcadedocs.com/vidmanuals/S/StarWars.pdf
Dan
-
Here is some information from the source code of the Atari800 emulator that might be helpful.
/* ANTIC Timing -------------------------------------------------------------- NOTE: this information was written before NEW_CYCLE_EXACT was introduced! I've introduced global variable xpos, which contains current number of cycle in a line. This simplifies ANTIC/CPU timing much. The GO() function which emulates CPU is now void and is called with xpos limit, below which CPU can go. All strange variables holding 'unused cycles', 'DMA cycles', 'allocated cycles' etc. are removed. Simply whenever ANTIC fetches a byte, it takes single cycle, which can be done now with xpos++. There's only one exception: in text modes 2-5 ANTIC takes more bytes than cycles, because it does less than DMAR refresh cycles. Now emulation is really screenline-oriented. We do ypos++ after a line, not inside it. This simplified diagram shows when what is done in a line: MDPPPPDD..............(------R/S/F------).......... ^ ^ ^ ^ ^ ^ ^ ^ ---> time/xpos 0 | NMIST_C NMI_C SCR_C WSYNC_C|LINE_C VSCON_C VSCOF_C M - fetch Missiles D - fetch DL P - fetch Players S - fetch Screen F - fetch Font (in text modes) R - refresh Memory (DMAR cycles) Only Memory Refresh happens in every line, other tasks are optional. Below are exact diagrams for some non-scrolled modes: 11111111111111 11111111112222222222333333333344444444445555555555666666666677777777778888888888999999999900000000001111 012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123 /--------------------------narrow------------------------------\ /----------------------------------normal--------------------------------------\ /-------------------------------------------wide--------------------------------------------\ blank line: MDPPPPDD.................R...R...R...R...R...R...R...R...R........................................................ mode 8,9: MDPPPPDD....S.......S....R..SR...R..SR...R..SR...R..SR...R..S.......S.......S.......S.......S.......S............. mode a,b,c: MDPPPPDD....S...S...S...SR..SR..SR..SR..SR..SR..SR..SR..SR..S...S...S...S...S...S...S...S...S...S...S...S......... mode d,e,f: MDPPPPDD....S.S.S.S.S.S.SRS.SRS.SRS.SRS.SRS.SRS.SRS.SRS.SRS.S.S.S.S.S.S.S.S.S.S.S.S.S.S.S.S.S.S.S.S.S.S.S......... Notes: * At the beginning of a line fetched are: - a byte of Missiles - a byte of DL (instruction) - four bytes of Players - two bytes of DL argument (jump or screen address) The emulator, however, fetches them all continuously. * Refresh cycles and Screen/Font fetches have been tested for some modes (see above). This is for making the emulator more accurate, able to change colour registers, sprite positions or GTIA modes during scanline. These modes are the most commonly used with those effects. Currently this isn't implemented, and all R/S/F cycles are fetched continuously in *all* modes (however, right number of cycles is taken in every mode, basing on screen width and HSCROL). There are a few constants representing following events: * VSCON_C - in first VSC line dctr is loaded with VSCROL * NMIST_C - NMIST is updated (set to 0x9f on DLI, set to 0x5f on VBLKI) * NMI_C - If NMIEN permits, NMI interrupt is generated * SCR_C - We draw whole line of screen. On a real computer you can change ANTIC/GTIA registers while displaying screen, however this emulator isn't that accurate. * WSYNC_C - ANTIC holds CPU until this moment, when WSYNC is written * VSCOF_C - in last VSC line dctr is compared with VSCROL * LINE_C - simply end of line (this used to be called CPUL) All constants are determined by tests on real Atari computer. It is assumed, that ANTIC registers are read with LDA, LDX, LDY and written with STA, STX, STY, all in absolute addressing mode. All these instructions last 4 cycles and perform read/write operation in last cycle. The CPU emulation should correctly emulate WSYNC and add cycles for current instruction BEFORE executing it. That's why VSCOF_C > LINE_C is correct. How WSYNC is now implemented: * On writing WSYNC: - if xpos <= WSYNC_C && xpos_limit >= WSYNC_C, we only change xpos to WSYNC_C - that's all - otherwise we set wsync_halt and change xpos to xpos_limit causing GO() to return * At the beginning of GO() (CPU emulation), when wsync_halt is set: - if xpos_limit < WSYNC_C we return - else we set xpos to WSYNC_C, reset wsync_halt and emulate some cycles We don't emulate NMIST_C, NMI_C and SCR_C if it is unnecessary. These are all cases: * Common overscreen line Nothing happens except that ANTIC gets DMAR cycles: xpos += DMAR; GOEOL; * First overscreen line - start of vertical blank - CPU goes until NMIST_C - ANTIC sets NMIST to 0x5f if (NMIEN & 0x40) { - CPU goes until NMI_C - ANTIC forces NMI } - ANTIC gets DMAR cycles - CPU goes until LINE_C * Screen line without DLI - ANTIC fetches DL and P/MG - CPU goes until SCR_C - ANTIC draws whole line fetching Screen/Font and refreshing memory - CPU goes until LINE_C * Screen line with DLI - ANTIC fetches DL and P/MG - CPU goes until NMIST_C - ANTIC sets NMIST to 0x9f if (NMIEN & 0x80) { - CPU goes until NMI_C - ANTIC forces NMI } - CPU goes until SCR_C - ANTIC draws line with DMAR - CPU goes until LINE_C -------------------------------------------------------------------------- */ -
I have schematics for the Colecovision base unit on my web site http://www.atarihq.com/danb/Colecovision.shtml. In the upper right hand corner of page six you will see a box labeled "31", this is the audio coming from the expansion connector. It only passes through one component before getting mixed with the internal audio so it's very possible that the problem is in the expansion module itself and not in the base system.
Dan
-
A second question is: The item I am stuffing into a 2600 cartridge case runs off of 9V battery. Is there a battery that is smaller, but will last as long?!Depends on how much current the device you are powering will draw. Gernally the smaller the battery the less current it can provide. If you check out Energizer's site you will find the specifications for all thier batteries, that gives you a good idea what's available.
Dan
-
The CPU can be stopped mid-instruction, but NOT mid-clock. Since the video clock runs at 7.16Mhz and the CPU at only 1.79 or 1.19 Mhz it could take up to 5 video clock cycles before the CPU completes it's current clock cycle.
Dan
1. DMA will halt the processor mid-instruction. Video timing can't wait for anything, which is why most old computers needed means to halt the processor at short notice.Are you sure?
The offical docs say there is an uncertainty in the amount of time a DMA startup will take. It takes 5-9 video cycles to halt the CPU. That doesn't sound like the CPU will stop in the middle of an instruction....
The lineram within the maria is double buffered, and that in addition to the amount of time the video chip holds HALT low for should be plenty to aleviate the need to halt the CPU in the middle of an instruction.
Of course, I've never seen a datasheet for a 6502C, and thus don't have any way to prove what goes on at that level.
At any rate, since the MARIA is read only, it probably doesn't matter.
-
Yes, you do lose the bottom 64 bytes of RAM on both pages due to the registers.
[*]The TIA/Maria registers appear to be mapped into the Zero Page of memory, and the stack area (0x0100 - 0x01FF) is interrupted with Shadow Memory. (0x0100 - 0x013F) Does the 7800 Sally map the zero page and stack pointer to some other address, or are the Zero Page and stack pages cut down to 192 usable bytes each?Thanks again for your help!
-
-
Well, after pouring over the code for a couple hours I can confirm that there is an Easter Egg in Food Fight! Thanks to "audiemurphy" for starting me on the trail of this. Here are the steps to access the easter egg, which I have confirmed on the real hardware:
1. Play one game up to at least level 23. This is easy if you set the skill to beginner and start on level 16.
2. After that game, on the level select screen, select level 23.
3. Hold the pause button on the console and do the following sequence with the joystick: Up, Down, Right, Left, Up, Down, Right, Left.
If you do that all right it should display the message.
Dan
-
We are definitely on the trail of an Easter Egg here. By manually manipulating some memory locations as I traced through the code I was able to trigger the message. Still not sure what game conditions trigger it.
-
I took a look through the code and don't see any obvious place where the ROM locations that contain the message could be accessed. It's possible that the program tried to hide the code that displays the message, but I am not sure why he would bother since anyone reviewing the code would spot the message very easily.
I think I spoke to soon! I looked at the code again with a fresh head, turns out I was looking for the wrong thing. I am pretty sure I found a piece of code that would display the message on the screen. For anyone who is interested, the code it at location $BD03 in the cartridge.
Tracing back I find that the program gets to BB78 when you press the trigger on the title screen. From there if a bunch of conditions are met, it eventually ends up at BD03 to display the message. It will take some doing to figure out what all those conditions are.
Dan
-
So now the question is, was what the original poster saw just a glitch, or is there really some way to make this appear in the game. I will have to poke through the code of the game a bit more to figure out if it is truely an easter egg.
Dan
I took a look through the code and don't see any obvious place where the ROM locations that contain the message could be accessed. It's possible that the program tried to hide the code that displays the message, but I am not sure why he would bother since anyone reviewing the code would spot the message very easily.
Dan
-
Ok, I can't resist a mystery and since I am in the process of writing a 7800 graphics viewer I decided to tackle this one. I poked around in ROM with my graphics viewer and found the character graphics (which are not a full set a characters) and from that I managed to decode how the text in the game is stored. This lead me to this piece of text in the ROM:
BYTHE "ALCHEMIST0F FUN"KEITHSAWYER
Note that this is not stored in ASCII in the ROM so it won't show up when viewing the ROM.
A quick Google of Keith Sawyer turned up that he worked at GCC and was the lead designer on Food Fight.
So now the question is, was what the original poster saw just a glitch, or is there really some way to make this appear in the game. I will have to poke through the code of the game a bit more to figure out if it is truely an easter egg.
Dan
-
Well, It was on a 7800 system. It was written in the same font as the Food Fight logo was in.
Was it the same font as the big foodfight logo, or did it look more like the text that makes up the copyright notice and option selection?
Dan
-
Google appears to be confused - that's part of a school or university. If that's where the landfill is/was, it's not going to be so easy to dig up and find the carts.
They built a school on top of a sacred Atari burial ground!?!? Now that just asking for trouble.
Dan
-
The two most written about 2600 programmers? Frye (PacMan) and Warshaw (ET). Failure will always be more interesting than success. That is the only reason that you see these two names dropped so often.
Warshaw actually falls into both categories, ET as the failure, and Yars Revenge as the success.
Dan
-
I just got this in the mail today and just had to scan and post it!
-
At some point Exidy got into redemption games and where actually still around up until a few years ago.
Dan
-
Even programs that used character generators (e.g. Stellar Track and Dark Mage, and BASIC Programming) didn't use ASCII. Text would instead be stored as an offset into the character set. Using ASCII would require either having a minimum 59-character (blank=32 Z=90) set or else using a translation table to convert ASCII to something else. BASIC programming probably could have used ASCII (it's got an 81 character set) if the funny glyphs were given the codes of unused ASCII characters, but there still wouldn't have been much advantage. Dark Mage used a much smaller character set, and thus using ASCII would have complicated things.You are correct the cartridges you mention don't have any ASCII text in them, but Magicard does contain all the 6502 opcodes in ASCII:
ILLADCANDASLBCCBCSBEQBITBMIBNEBPLBVCBVSCMPCPXCPYDECEORINCJMPJSRLDALDXLDYLSRORAROLRORSBCSTASTXSTYASLBRKCLCCLDCLICLVDEXDEYINXINYLSRNOPPHAPHPPLAPLPROLRORRTIRTSSECSEDSEITAXTAYTSXTXATXSTYA I X) RZ ZXZY)Y() A X Y
Dan
-
-
-
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Arcades near New Jersey..
in Arcade and Pinball
Posted
Check out Ocean City NJ. They do not allow any form of "gambling" on thier boardwalk so you won't find any redemption machines in the arcades. When I was down there last year there were still a lot of classic video and pinball machines in thier arcades.
Dan