Eckhard Stolberg
-
Content Count
953 -
Joined
-
Last visited
Posts posted by Eckhard Stolberg
-
-
That's right. With my 7800 console that was modified to be a cartridge reader I read out the entire 6502 addressing space. And there wasn't anything at $2800-$2FFF. Also I think the manual actually says that the RAM mirror is at $2800-$3FFF, which can't be true, because the HighScore Cart uses $3000-$3FFF for it's ROM.
Again, a 24 pin (4K) cartidge in an unmodified NTSC 7800 will result in the BIOS locking the system into 2600 mode because the RAM test will fail due to cart ROM shadowing. Dual-boot 2600/7800 carts are therefore impossible.Are you sure about that? The RAM test at $F8E7 is running from within the 7800 BIOS. While the BIOS is enabled, the cartridge is disabled by setting A12-A15 low. So no cartridge should interfere with the RAM test. Also when the RAM test fails, it locks the 7800 into 2600 mode. But it does so in the middle of the BIOS ROM without transfering control to the cartridge. This results in a crash. So if 24 pin cartridges could make this RAM test fail, then no 2600 cartridge should work on the 7800.
But if Bruce is right and the mode-select byte reacts to all mirrors of the TIA, then a dual-boot cartridge would be kind of pointless, because you couldn't do much in 2600 mode.
Ciao, Eckhard Stolberg
-
To switch banks, just hit the hotspots; like this:org $DD00 rorg $FD00 ;--this location doesn't matter; just as an example. sta $1FF9
Writing to the ROM isn't a good idea, as it might cause bus conflicts. It's better to use "CMP $1FF9", "BIT $1FF9" or "NOP $1FF9" instead.
BTW vdub_bobby, did you already try if changing this would fix the problems with Reindeer Rescue on NMOS EPROMS?
Ciao, Eckhard Stolberg
-
I don't think Dynamics ripped off anyone. Dynamics is a company that imports electronics from Asia and sells them in Germany. In the 1980s they sold the Competition Pro joysticks in Germany for example. So I'm pretty sure that they were officially distributing the OnBase games under the Dynamics name before OnBase decided to go with their own Bomb brand instead. Otherwise the OnBase games in the Dynamics catalog probably wouldn't have come in Bomb cases.It's much closer to the source (Taiwan) than Dynamics.Dynamics most probably ripped Bomb-Onbase.
Ciao, Eckhard Stolberg
-
My multistandard-TV is like that that too. In the on-screen menu I can only select various types of PAL and SECAM. But the TV will still display an NTSC picture through RF. Only for sound it expects the same carrier frequency as the selected PAL standard for the channel, which is different from the sound carrier frequency for NTSC.
I was able to get sound from my NTSC 2600 and 7800 consoles by tuning the sound carrier frequency like Mitch suggested. I think the sound carrier frequency for PAL-B is the closest to NTSC, so the range of the variable inductor might be big enough to get sound from your 5200. If it isn't, then you need add another inductor to the board like Mitch said.
Ciao, Eckhard Stolberg
-
There is a bit in the mode-control byte which switches between BIOS-ROM and cartridge. I think when the BIOS is selected, the console will pull A12-A15 low on the cartridge port. So you could disable the cartridge at any time until the mode is locked.How does the 7800 work to disable the cartridges from appearing at $F000 during bootup? It gates the upper address lines somehow, right? Could code running out of RAM access other RAM by temporarily disabling the cartridge?The RIOT RAM is mapped in at $0480-$04FF in both modes (7800 and 2600). So you could run code from there to switch between modes. I'm not sure if the internal RAM keeps it's data in 2600 mode though. You would have to test that yourself.
Since games weren't supposed to freely switch between modes, there is no hardware support for that. But there is a flag in 7800 mode that lets you test if the console is in the vertical blank. You might be able to use that to find out when it might be the best time to switch modes.Is there any way to get the Maria and TIA 'in sync' with each other to allow glitch-free switching between them?
On the 7800 it's the console that decides how many scanlines a frame should have. PAL consoles do more lines than NTSC consoles. Since you can find out when the 7800 is in vertical sync and there is a WSYNC command in 7800 mode too, you can easily count how many lines the console does between two vertical sync periods. The Asteroids game that is build into the PAL 7800 uses this method to find out what type of console it's running on and to set up it's output accordingly.My basic thought is that it might be nice to have a 2600 cart that could take advantage of 7800 features when they're available but would run just fine on either machine. One feature that should be doable without anything too fancy would be NTSC/PAL autodetect (do the various versions of the 7800 BIOS leave different stuff in RAM based upon machine type?) But otherwise, things like being able to do the Strat-O-Gems instant replay without needing a memcard would be cool as well.Ciao, Eckhard Stolberg
-
Did they all use the same board type from PixelsPast, or did someone use his own design? And did they all have problems with the cartridges on their systems too, or do the games only fail on your consoles?I don't know about the chips. The test boards were made by AtariAge, Packrat and a local friend of mine. All have got the same problem with VCS/2600jr.
Very strange. Did you try different power supplies with your VCSs, or did you always use the same? And what exactly happens when the game doesn't "start"?Yes. Neither of my VCS or 2600jr starts the carts on every try. BTW: a test on a "Gemini" clone system lets the cart start always...Ciao, Eckhard Stolberg
-
The mode-select byte is mapped in at $0000-$001F. Therefore you can't do TIA sound in 7800 mode when the mode isn't locked. In 2600 mode you could use the TIA mirror at $0040-$007F though.You do have to avoid writing to low addresses (I forget which range) as it will latch it into one mode. And since those addresses are frequently used, you probably can't do much in 2600 mode before you have to access one of them.
The RAM is mapped in at $1800-$27FF. Therefore only half of it would conflict with a cartridge that doesn't use A13-A15. Parts of the not-conflicting RAM are used for zeropage RAM and stack RAM though, so you really wouldn't have too much RAM left to create your display lists in.Even worse, in 7800 mode, the RAM will conflict with a cartridge that doesn't use A13-A15 for address decoding! So it's impossible.
Unfortunately the RAM is tied with the MARIA. If you disable MARIA support, you also don't get the 4K of internal RAM. Also in TIA mode you get the same TIA mapping as on a 2600. This means that the TIA and the RIOT are mirrord at every even 4K page. Therefore you can only use the odd 4K pages for your code.A 7800 game that uses the TIA is easy enough, as long as you never lock the mode port, just encrypt the last 4K properly. It's like a 2600 with up to a full 48K of RAM/ROM plus the internal 4K RAM.
Atari did develop some bankswitched 2600 games on their 7800 development cartridge this way. In the Cuttle Cart 2 you could use the 48K 7800 game type and put your code only in the odd 4K pages of the ROM image.A 2600 game with extra address lines (using A12 as the chip select) works out like how many larger 2600 games were developed, with an ICE and lots of RAM. You get up to 32K of space, some of which may be cartridge RAM, at every other 4K page. This could be moderately useful for developing 8K or 16K 2600 games. But the Cuttle Cart 2 doesn't have support for this memory mapping (not that it couldn't), so you're on your own.Ciao, Eckhard Stolberg
-
The 2600 starts the game right away while the 7800 first goes through it's BIOS. So maybe your cartridge is a little too slow with setting the initial bank? Then the startup vector might get read incorrectly on the 2600.
Also I think vdub_bobby had some strange problems with Reindeer Rescue when using CMOS EPROMs for the cartridge. They might be caused by using write instructions for triggering the bankswitching hotspots. Do you use CMOS EPROMs, and/or do you trigger the hotspots with STA instructions?
And did you verify that the game really does start from both banks? The Cuttle Cart and z26 allow you to chose the starting bank for F8-bankswitching games.
BTW, did you try your cartridge on more than one VCS?
Ciao, Eckhard Stolberg
-
I'd agree, Eckhard, except that 128 is a lot. Assume Paul writes his music tracker and you can save songs to the MemCard. I could easily save 50+ songs to the Memcard. But lose my handwritten sheet and spend a month doing other things and when I came back I'd never find any of them again. I'd have to go through and load each of 50 songs and recreate the master list. I doubt anyone would go to the trouble and, if they had to, they'd probably be soured on ever using the Memcard again.No-one would stop Paul from saving song names in his files, if he feels they are useful. And his tracker could easily check all 128 files in the background for it's file signature and only let you select proper tracker files by name in it's loading dialog. You only wouldn't be able to display these names in other programs, because they all would use their own format for naming and identifying their files.
Having a standard file naming scheme would only be useful when you need to be able to delete other program's files to be able to save your data to the file area on the MemCard. But if for example you wanted to create a savegame state for a RPG, but your MemCard was already filled with tracker songs that you created months ago, then filenames like "MUS.MYSONG23" probably wouldn't be too helpfull for deciding which file to delete anyway.
Ciao, Eckhard Stolberg
-
Are filenames or standardized file identifyers really nessessary. Each file has the same size and each memcard has the same number of files. So it would be quite easy to identify each file by it's index number. If programs just let the user select which file number to save data to or load data from, users could keep track of the contents of their memcards on a sheet of paper. Richard could even have an official printable memcard directory sheet for download on his website.
No matter how clever you design the file identifiers, there is still a possibility that a program accidentally loads invalid data. And if the program has to check the data anyway, why not allow it to freely identify it's own files too. That way batari could for example put $BB in the first and last byte of each bB file, and supercat could put the ASCII representaion of "GEMS" at the start of each Strat-o-Gems play save file.
If filenames were used, every program that wanted to be able to overwrite other program's files would have to include a text based file browser. I think that this would be unnessessary complex considering how limited the VCS is with processing power and RAM and how bad it is with displaying text. If files were only selected by their index number, even a simple 4K program could use the file area in the memcard.
The only thing that might be helpful would be a 128 bit list in the Atarivox/memcard status block to mark used files. That way a program could have a "This file is already in use. Do you really want to overwrite it?" type of warning when the user selects a certain file.
Ciao, Eckhard Stolberg
-
I think Marco has one of those too. IIRC you connect the Atari power cable to the cartridge. Then you connect the cable form the cartridge to the power connector on the VCS. There should also be a button on the back of the cartridge that lets you interrupt the power to the VCS.
By turning the VCS off and on again you change between the the 6 games. So the button on the back of the cartridge lets you cycle through the games as well.
As Marc said, this is a store demo cartridge. In the VCS demo stands in the shops the VCS was locked behind glas. Only the button on the cartridge and the controllers were accessible to the customers. That way customers could try out the different games on the cart without being able to mess up the console itself.
Ciao, Eckhard Stolberg
-
I might be interested. But I'm wondering if the keyboard and the programs would work with the PAL 7800. Or will special PAL versions of the programs be available?
Ciao, Eckhard Stolberg
-
There is no further mention of pin 14 anywhere, so is it also soldered down, or bent back up? The way it looks, I'm assuming that last sentence in step 5 was supposed to read Solder down pins 1, 7, and 14. Now bend up pin 8.So, if somebody here who has done this already could chime in and set me straight, I'd appreciate it.
You are correct. Pin 14 needs to be soldered down too. BTW, you might want to go here and get the second version of the devkit. It contains newer software. Pin 14 is still not mentioned in the manual though.
Ciao, Eckhard Stolberg
-
I have just installed the latest version of z26 and downloaded all of the KidVid Audio Packs for Bernstein Bears and Smurfs. I can play Smurfs but I can't get the audio to start during gameplay. I know you're suppose to hit 1, 2, 3 to start the corresponding tapes but nothing happens. Any tips?z26 is probably not finding the Kid Vid audio files. It only looks for them in the current working directory. So depending on how you are starting the emulator you should put the audio files in the same directory as the binaries or in the same directory as the z26 executable.
Ciao, Eckhard Stolberg
-
I get no response (no message, no nothing) when I try to play a compiled game with Stella October 5, 2005 build via the 2600IDE program. But if I try to run Stella by itself (doubleclicking on the icon in the folder), it says STELLA.EXE is linked to missing export KERNEL32.DLL:GetFileAttributesExA, which apparently is available only in Win98 and up.I think the Stella nightly builds still come with SDL.DLL version 1.2.8. Did you try to go to www.libsdl.org and download SDL.DLL version 1.2.9 and see if it works better with Stella on Win95?
By the way, my experiments with E7 bankswitching on the z26 emulator show that a routine located at the hotspots can be executed, I believe without affecting which bank is selected. Thus, the twelve hotspot bytes can contain a routine, plus they can be used to switch banks using a fake read or fake write.This should work on real hardware, since the ROM bank at the hotspots is fixed and wouldn't change when the hotspots get accessed.
This won't work on real hardware and it probably will not work in fututre versions of z26 either. In the emulator we have to handle read and write accesses seperately. No E7 game tried to write to the extra RAM by read accesses to the write hotspots. Therefore we didn't implement a handler for this case in the E7 handler for read accesses. This is why you can still read from the ROM there. On real hardware there is no difference between read and write accesses. So a cartridge shouldn't return anything on an access to the extra-RAM write addresses.
Ciao, Eckhard Stolberg
-
The changelog for SDL 1.2.9 (which was released in August) says that the SDL.DLL was fixed to work in Win95 again. So there probably only was a problem with how SDL.DLL 1.2.8 was compiled.
Ciao, Eckhard Stolberg
-
Most modern PAL TVs also support SECAM. But they usually wouldn't autodetect a SECAM signal. You have to maually enable it for each channel in the on-screen menu. If you don't do that, you wouldn't get a picture from your SECAM VCS at all.
Ciao, Eckhard Stolberg
-
A game would probably read one sample value per scanline at most. So you'll have at least 76 cycles to generate a new sample value. But in the display kernel scanlines it would be difficult for a VCS game to spare the cycles needed to trigger the sample generation. Therefore it would be better, if you could return the current sample value immediately and then generate a new sample value for the next read later.
The game would need 3 cycles to write the sample value into the TIA volume register, and it takes a couple more cycles to set up a new instruction to read from any of the hardware registers on your cartridge, so you should have enough uninterrupted time to generate a new audio sample after a value was read.
Ciao, Eckhard Stolberg
-
So you're saying that RAM+$FF,Y is equivalent to RAM,Y but with an extra address cycle added because of crossing a page boundary?RAM refers to $F000 and RAM+$FF refers to $F0FF. With the Y-register ranging from $00 to $FF you will never cross a page boundary in the first case, but you will always cross a page boundary in the second case except when Y=$00.
In the absolute-indexed addressing modes the 6507 will first add the contents of the index register to the low byte of the destination address and access this address. Only if the addition has overflown, it will increase the high byte of the destination address and access the corrected address too. This is were the extra cycle comes from.
So if Y = $80, then a LDA $F0FF,Y will first read from address $F07F (triggering the SC write) and then read from $F17F (the extra cycle after fixing the high byte).
You can save a zero, but you can't save a $FF. And you always have to add 1 to the value that you want to store. If you can live with these limitations, it's a clever way to save a byte for the NOP. But it probably is only really usefull for storing fixed values at fixed addressed. Or for easily decreasing values at fixed addresses as supercat pointed out.
Ciao, Eckhard Stolberg
-
I don't know if Suntek or Rainbow Vision ever released a version of Farmyard Fun, but I'm pretty sure it was originally created by/for ITT Family Games. In the early 1980s there was a German TV series for children called 'Pumuckl'. The main character in Farmyard Fun looks exactly like Pumuckl, and the game even plays the title melody from the TV series. I don't think the Pumuckl series got distributed much outside of Germany, and ITT Family Games seems to have had a license to produce games based on it.
The player sprite in Zoo Fun also looks like Pumuckl. This game uses the same display kernel as Panda Chase by Homevision. Zoo Fun is not a hack of Panda Chase though. It seems to be done by the same programmer who used the same display code for both games. Therefore I think that both, Zoo Fun and Farmyard Fun, were written by Homevision to be included in ITT's Pumuckl game series.
Ciao, Eckhard Stolberg
-
There are times the above formulation will work. If it's desired to decrement a memory location if it's non-zero (and leave it alone if zero) one could use:ldy memoryloc cmp $0FFF,y cmp dest_address
If the memory location holds 10, the second instruction would generate reads to $0F09 and $1009. If it holds zero, the second instruction would only access $0FFF (not hitting the write trigger) and the third instruction would be harmless.
But you still have the problem that there are not enough address cycles between the two CMPs because the access to the 'write trigger address' is still the last cycle in the first CMP. Therefore the write would go the address of the opcode byte of the instruction after the second CMP. You either have to put a NOP between the two CMPs, or you have to use $10FF,Y on the first CMP and make sure that Y is never zero.
Ciao, Eckhard Stolberg
-
Yes, you are right. The last thing the BIOS does is to place the control byte value in the write buffer and then jump to some code in RIOT RAM that accesses $1FF8 and then jumps to the game's start address from the header. So accessing $1FF8 indeed is harmless if your game hasn't accessed $1000-$10FF at all before. But like $1FF9 you probably wouldn't get the proper byte back from a read of $1FF8.
Ciao, Eckhard Stolberg
-
RAM = $F000 VALUE_TO_STORE = $80 DESTINATION_ADDRESS = $F100 (whatever) ;value comes from X LDX #VALUE_TO_STORE CMP RAM,X; preps the value for the write CMP DESTINATION_ADDRESS; does the write ;value comes from Y LDY #VALUE_TO_STORE CMP RAM,Y; preps the value for the write CMP DESTINATION_ADDRESS; does the write
No, Eric is right. These examples would only work if DESTINATION_ADDRESS was $1FF8, because writes to the SC config address will always happen immediately. And that's the only way writing is done this way in the Commie Mutants code too.
There are several cases of the following code though:
RAM = $F000 VALUE_TO_STORE = $80 DESTINATION_ADDRESS = $F100 (whatever) ;value comes from Y LDY #VALUE_TO_STORE CMP RAM+$FF,Y; preps the value for the write CMP DESTINATION_ADDRESS; does the write
In this case you would write $7F to $F100. The reason for that is that the first CMP will need an extra cycle because it is crossing a page boundary for any Y-value other than $00. In this case the 6507 will first access $F07F (this will trigger the writing) and fix the high byte of the destination address. Then it will access $F17F. This is the extra address cycle that is needed for the access to DESTINATION_ADDRESS to be the 5th address cycle after the access to the writing trigger address.
Ciao, Eckhard Stolberg
-
Accesses to $1FF8 are harmless until the first access to the range $1000-$10FF. I believe accesses to $1FF9 are harmless, but won't return correct data; not sure about that one, though.Accesses to $1FF8 will always change the state of the SC to whatever value was in the write buffer last. If $1000-$10FF wouldn't get accessed at all, that would be the initial value of the write buffer. But since the SC BIOS needs to access the 'load trigger' addresses during the loading process of the game, the value in the write buffer at the start of your game will depend on which byte was read from tape last.
You are correct about $1FF9 though. That byte only returns the audio input in bit 7. Accessing it doesn't change anything in the SC config.
I don't think there are any technical reasons for Starpath's choice of trigger addresses. They probably just were carefull when chosing only addresses in the cart's address space, since they had to reverse engineer the inner workings of the VCS and didn't know exactly what all those unused addresses in the lower half of the VCS's address space were doing.
Ciao, Eckhard Stolberg
Does somebody know what the reason for this problem may be? How do 7800 and VCS/2600jr vary in starting a cartridge?
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Xevious?
in Atari 2600
Posted
The CC audio converter software has an option to skip "empty" data pages to speed up the transfer process. Do you use this feature for the Xevious ROM?
The Xevious ROM has some "empty" pages where all bytes are $00. When I patched them to $ff, the game started to act strangely in z26 too. I didn't get "buildings", but the enemies behaved differently and the screen started to jump occasionally. So depending on what the state of the CC RAM is for the not-transferred pages before loading the Xevious binary, you might get strange things like the "buildings" to appear.
Ciao, Eckhard Stolberg