Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation

6 Neutral

About Kroko

  • Rank
  • Birthday 12/26/1969

Contact / Social Media

Profile Information

  • Gender
  • Location

Recent Profile Visitors

10,878 profile views
  1. $3F is a little bit difficult, because the last 2K chunk in the rom file plays a special role. It needs to be placed at the fixed bank. So you could be tempted to open the file and read the last 2K to place it in the fixed bank. If you do it like that, then it is almost sure you will not produce a working ROM if the last chunk is not exactly 2K. In my opinion, a 3F ROM that does not have a file size that is some multiple of 2K is broken.
  2. As far as I know, the last two bytes are the IRQ/BRK vector. If this vector is unused and can contain random data, I see no reason why a ROM should fail on "real hardware". In case of Harmony I guess there is also some strategy to fill internal memory from a binary file. And here there could be a problem if the size is incorrect. The ROM content may be written to the wrong memory location, but that depends on how Harmony maps the file to its memory ... So there is no answer for "real hardware". You could only tell it for some specific device ...
  3. I guess nobody really thought of ROM files with a wrong size. This sentence just means that the last 2K block found in the ROM will be the fixed block. You should start counting blocks from the beginning of the file and put the last 2K block to the fixed bank, no matter if the last block is really 2K or not. This is also what would happen if you flash the ROM to some real memory. You would not flash it "backward" but from start of file until end of file, which leaves the last two bytes undefined or empty.
  4. Sure you are right: it is 130 MB of level definitions for Sokoboo
  5. I doubt that anybody would ever need more than 512 MB on a 2600, but ... How about a 16-bit bank number ? 256 * 256 banks (2K per bank) => About 130 GB of ROM space ... 3F write bank-number lo-byte XX write bank-number hi-byte XX may be another unused hotspot from TIA space
  6. Hi Andrew, I am not sure if you would only have this problem for 3E. I think it is a general problem of the 6507 crossing page boundaries. For the write instructions STA, STX, STY, SHA, SHX, SHY the 6507 is doing the following: In cycle #4 a wrong address appears on the bus. In cycle #5 the address is fixed, but then it is too late. The bankswitching hardware always monitors the bus and if you have a wrong address on the bus, then the hardware is reacting to it. So if you were using such an instruction on the write port of the RAM area, you would first put the wrong address to the bus in case you were crossing a page boundary. In case you want to construct a bankswitching method that does not have this problem, you need to find a way to detect, the wrong dummy address from cycle #4 (which may be difficult). Or you could think of a different mechanism to read/write to the RAM (not using the Superchip approach). # address R/W description --- --------- --- ------------------------------------------ 1 PC R fetch opcode, increment PC 2 PC R fetch low byte of address, increment PC 3 PC R fetch high byte of address, add index register to low address byte, increment PC 4 address+I* R read from effective address, fix the high byte of effective address 5 address+I W write to effective address Notes: I denotes either index register (X or Y). * The high byte of the effective address may be invalid at this time, i.e. it may be smaller by $100. Because the processor cannot undo a write to an invalid address, it always reads from the address first.
  7. I have implemented 3F bankswitching for any access to bus location $003F, no matter if it is read or write. As you wrote, there is no way on real hardware to detect if somebody is doing a read or write to that location. Maybe it works on real hardware, because I am only using $3F, not the locations below $3F. Could be that the cartridges that make trouble with read access do the same thing. They would have trouble with reads from addresses below $3F as well. They may only work because these addresses are ignored... Do you have an example of how a 3F cartridge fails because of a read access to $3F (not below $3F) ?
  8. Do you think it is possible to run some assembly kernel on one core and run Linux on the rest of the cores ?
  9. I needed at least 24 free GPIO pins. Lots of people have Raspberry Pi at home, so all that is needed is a cheap adaptor to turn it into a 2600 cartridge. How popular is Arduino compared to Raspberry Pi ? Do people have these at home, too ? Now that the Pi Zero is 5$ it might be hard to find something comparable in the arduino world.
  10. Actually I have been working on a Rasperry Pi cartridge based on the B+. I had to install my own operating system on the Pi ... Linux is not fast enough. But I was finally able to use the Raspberry Pi B+ as a Pac-Man cartridge (shame on me for choosing Pac-Man). So yes, the Pi is fast enough to do this, but you need a very much optimized assembly kernel for that and there is VERY little time left for anything else but watching the bus and setting the data lines. Doing a lot of things in the background is at least difficult. There are other difficulties: The noise level you induce into the 2600 by using a Pi is significant. I was not able to receive power from the console and have a nice picture at the same time. Even not after using resistors on the dataline between the level shifters and the 2600. Only when using an external power supply for the Pi, the picture quality was acceptable. Actually I already bought a Pi Zero to see if it is possible to replace the B+ by Pi Zero. Unfortunately I had to wait a long time for the Zero and now I have no more time to work on the project ... I never ordered a PCB, but I think the Pi zero could be squeezed into a 2600 cart ...
  11. The noise might be a critical issue in the end. For the "nomal" flash cartridge that operates with a fast clock it is sufficient to put ~1KOhm resistors between the cartridge connector and the databus [D0-D7]. This removes most of the noise. But I am a bit uncertain, about your setup. You might also have to put resistors between A0-A12 and cart connector. Most likely your noise is not because of RF shielding. It is induced by the A and D bus. Try to isolate all signals you inject into the 2600 from the power supply of your FPGA board as much as you can without breaking your design. Maybe there is a better way than resistors ... I just didn't find it, yet.
  12. If you have the possibility to program 20V8 PLDs, all you need is here: http://www.grandideastudio.com/portfolio/pixels-past/
  13. If 8K works OK, then I guess the logic chip is programmed with F8 bankswitching. I don't think that the logic chip can do F8, F6 and F4 bankswitching at the same time. So for 16K you need a logic chip for F6 and for 32K you need a chip with F4 bankswitching.
  14. Your connector looks fine. The blue jumper ? what does it do ? As it is installed in the picture to me it looks as if it pulls down your PGM pin to ground. But it is hard to see. Please confirm you are not pulling this pin down to ground by the jumper! It needs to be on 5V. Can you check that none of your inverter outputs is connected to ground. Your setup doesn't look very clean
  15. I wanted you to connect the inverted Atari2600 A12 to /OE instead of /CS. A12 of your EEPROM should still be controlled by your switches. /CS is the chip select. /OE is output enable. In principle both do the same thing, but for some chips the timing is different. I have seen /OE being faster than the /CS. But I doubt that this is your issue... I was just running out of ideas ... You can also check the CS and OE timing in your chip's datasheet >> Using A12 as /CS? I dont understand. If we stuck /CS to ground, the eprom will be always enabled. >> A12 (in the eprom)is for selecting the 4K page, and in the console, inverted is for emprom's /CS. >> Can you explain a little more what you want to do?
  • Create New...