Kroko
-
Content Count
429 -
Joined
-
Last visited
Posts posted by Kroko
-
-
How long a lead time is there on this kind of design work?A difficult question. I don't have a good answer to that. Most people here are hobby designers. Depends on when they have time and if your design is similar to something they have already done.
Which is easier/cheaper: doing arbitrary slots or something more like the 2k/4×256/1k scheme?Arbitrary slots consume more internal logic resources and smaller banks need more pins. Not easy to compare. I don't think either of the two methods is especially difficult.
are we talking about gate kit chips or a PIC/FPGA level of complexity?The logic chip internals would be more complex (serial EEPROM writing algorithm and control of a bus transceiver and some way of doing a complete page dumb with just one command) It would most likely not fit into a cheap Xilinx device and that means the boards can't be easily produced anymore ... Not to speak of the development time needed for a thing like that.
I'm curious whether crossing the 256k mark with 1k banking regions is a limit on bankswitching via register writes or if 16b latches could exist?The withs of the latch is only limited by the amount of resources on the Logic Chip. There actually is no limit for one special aspect. Its the complete design that has to fit into the device.
and keep the mfg. costs under $15..20?,That is realistic, if you skip the serial EEPROM idea and keep to standard banked flash-rom together with RAM.
-
If I could bank 2k ROM/4×256B RAM/1k ROM individually somehow, (the 1K at the end to catch the RES/BRK vectors), ideally with an instruction saying, "mirror such-and-such a RAM page into persistent (flash/EPROM/...) storage," that would be great.The 4×256B RAM could just be a 1k RAM cache to a serial EPROM facility, actually, especially if I could swap a page of RAM to/from EPROM within the vblank interval... or asynchronously. ** This assumes that the black magic I just read about doing RAM without doubling address space for reads v. writes is actually doable? ... else that's understandable, but even 2×256B is usable...I have not tested the magic writes myself, but supercat is confident that it works. And my feeling is, that I have to try it and see what happens
Of course, the more ROM the better...Its nice to know what you need in an ideal world, but I also do need to know what you think is the minimum for your project. There are always some compromises necessary on the 2600 (and you want to be able to pay for it)
For example if you would really need the magic writes, then it would be necessary to interface all 8 datalines. This leads to a situation where you have less lines available for your Rom Space, or where you have to live with larger "bank" sizes (> 256 byte).
There is only a limited number of I/O lines on the logic chips and it does not make sense to use a device with more than 44 pins for a standalone board (Because that is what I think can be produced by hand)
This is just off-the-cuff, but if some sort of memory manager could do background DMA copies between ROM, RAM, and EPROM, that would provide some killer solutions.I have to think about that, but my feeling is that this will at least be complicated.
I'd want to handle at least, oh... 128k or 256k "ROM" area, maybe 8k .. 16k of "RAM" working storage, and then, say, 4 savegames of 8/16k each... well, that's some odd sizes, chips don't come in 168k or 336k sizes, and I'd assume this would probably all end up on a single flash chip?If you don't insist on the magic writes, that Rom/Ram size is not a problem
If so, could something monitor the CPU clock and do bus sharing like the way the 6510 and VIC-II chip share accesses to RAM in opposite phase... and, then do DMA copies of memory regions asynchronously to the CPU's accesses, so that the program could just request a block copy from the working storage area into the save game area, and then periodically check a flag (say, during vblank interval) to determine if the transfer has been completed yet.Or would it be more economical to make it as an EPROM for the ROM areas, a RAM chip for the RAM areas, and have a serial EPROM off to the side somewhere to mirror the RAM? Again, it'd be nifty to just send an offline command like, "dump RAM page (x) into EPROM page (y) and I'll be back in (n) cycles with your next orders."
In order to copy something to RAM, the bus must be available for the cartridge. That means nothing shall drive the bus, while the cart is working on a memory copy. I am not sure how you would make sure, that the bus is absolutely free for a longer time period ? The alternative is, to disconnect the bus from the VCS while the cart does the copy. But that requires some additional chips which makes it more expensive. And you need a routine that runs in VCS Ram to wait for the copy to finish. Maybe by polling a hotspot ?
OK, ... this is all really off-the-cuff sketches, and I really don't know what the limitations are, or have the slightest idea of what the production costs would be for something like that.The question is, what would you be willing to pay for your game and what part of that can be hardware costs. If you come up with a limit, then its much easier to judge if it is realistic or just a dream
And that leads to the question of whether there's an existing similar bank-switching mechanism that something like this could be based offThe memory dump is new. Maybe a CC2 could do things like that, but nothing else I know of (and the price is 200$). The bankswitching itself is not a big problem. To be honest, I would think about using AtariVox or the EPROM sticks. I don't say its not possible to design a device with internal writable eprom, but it may be too expensive.
-
Perhaps for the sequel (..?!) we'll put the electronics gurus to the test to come up with a good bankable RAM solution
What do you need and what do you think is a reasonable price for that ? And I need to know how many boards you need.
-
Post the binary, then I can try it on the Krokodile. Are you using CLEAN START ? I would like to have a look at the startup vectors and the startup code for both banks.
-
The different console versions came with different power supplies.
They were 9V (+ in the middle). But there have been 400mA
versions for the 6-switch and 500 mA for the junior IIRC.
9V and 500 mA is the best choice and should work for every console.
You also have to take into account that the cartridge you plug into the
Atari also needs power. When the console was designed, they didn't
think about Pitfall II cartridges which need a little bit more power than
a PacMan cart.
I would not buy anything below 500 mA. If the supply can handle more
current, that does not hurt the console. It is just a bit more expensive.
I am running my consoles with a 1000mA supply at 9V and never had
trouble with that.
-
Thus, in theory, adding six wires and a jumper to the board might allow for in-circuit programming of the CPLD--not an unreasonable mod.But unfortunately there is not a single free pin on the microcontroller. Even if I found free pins for double usage I don't like how I would have to connect these wires to the controller and how this would become an entirely different device. I am using this method already for some prototypes, but I will not use it with the Krokodile. Also because I don't think it is very likely that 4A50 works stable with a 5V part. The possibility to upgrade the CPLD is nice, but for me it is not reasonable to add it at this stage of the project.
-
What pins do you have on the microcontroller?None of the JTAG pins
-
I've got another batch of PCBs for my 4A50 schemeYea, I am following your blog about that. The way you are writing RAM sounds promising, in case it really works. But as you might have noticed, the CPLD on the Krokodile is a 5V part which is not good for this kind of RAM writing, or ?
The Krokodile itself will not change a lot in the near future. But I am working on a few other things that might be finished 10 years from now
. One of the boards I am thinking of, might be able to support your way of RAM writing because a 3V part is used. Maybe I have enough free lines to interface all datalines .... -
Forgive me if I've asked this, but do you connect the Xilinx JTAG pins to anything useful (like the microcontroller)? If so, would it be possible to reprogram it from the PC? I know it would be a fair bit slower than just loading a game into flash, but it would both mitigate the hazards of including newer software in the new units (since field bug fixes would be possible) and would also make it possible to support schemes which you presently cannot (since it would not be necessary to simultaneously support all the other schemes).With Verns help, I have designed a board that acts like this already. But its curretly not more than a prototype. The Krokodile does not follow this strategy. All it does is already on the chip. The CPLD is not reprogrammed. When I designed the Krokodile back in 2003, I didn't even know that this was possible ...
-
Yes, or at least I think so. The 7800 startup BIOS triggers the multicart game selection hotspot. There is no easy way to fix this. There is a great device available for the 7800 as you know
Buy it and support Chad so he can continue to make great stuff in the future. The Krokodile is 2600 only, though it works fine on the 7800 if you use it as standalone cart. -
Any chance of adding support in the new batch for games it won't currently play?I have not decided yet, if I will change the firmware at all. There have not been any problems with the current version and a change always has some risks. On the other hand, I found a way to include E7 bankswitching in the new revision. I am not sure what to do right now...Something tells me i should let it as it is and something tells me I should support E7 if possible ...
Almost all E0 games have been converted to schemes the Krokodile already supports and also the two FE games are converted. So the big holes are still E7, which I could probably close in the next revision, AR and F0. F0 is not worth the effort, because there is just one Rom (which sucks). Supercharger and E0 currently simply don't fit into the logic chip.
Also, would it be possible to add support for a bankswitching scheme that I don't think has been used elsewhere? We're adding a new one for a game Robert announced ...That is not very likely. Not because I don't want to, but because the space on the logic chip is very limited. If you just need 64K, then you can use EF bankswitching which was already planned for a RPG and the Krokodile supports EF already. If you need Rom together with Ram, you could use the Superchip modes, or if you need lots of RAM, you could still use 3E. Well, it has some limitations, but look at Andrew Davies not Boulder Dash. There you can see what a smart programmer can make out of this scheme.
I've been on Albert's list since April 1st, so I'm hoping to be high enough on the list to get one this time around.This time I have ordered enough PCBs. Its just a question of time. I have started to build them, but I need a lot a time for each single device, because its all hand work
I am always interested in new bankswitching ideas. Please PM me with the details
-
-
I am working on it. I almost received all parts. Except for the power connector. I hope to get it soon, but I am only a small customer for the producer of this part, and it seems as if I could have to wait a little before they ship the parts ... well, I have enough work with the rest of the parts
-
If you just start the ROM in an Emulator, it will be treated as F6, which MIGHT make it crash. But together with a 8K board from AtariAge, the ROM has to work. It will behave just like the 8K rom. There can not be any difference if you ask me. So yes, try again
-
-
Even there, however, the bus keeper can hold the bus in a valid low state for 1.5 cycles which I think is adequate margin.ok, thats sounds like it is long enough ...
If you were using a 95C72XL and wanted extra confidence, you could put series resistors on all the data lines going to the CPLD and have it latch and drive them. Alternatively you could use a 74HCT373 along with eight resistors (this was my plan until I found out that the 95C36XL had the bus keeper built in). One caveat in either case: the bus keeper circuit must either be disabled during zero-page fetches, or must be weak enough to allow the TIA to pull D6-D7 high since it's not very strong.I would rather like to keep it as simple as possible
-
The cartridge looks for A0 transitionsOk, now I understand
One more question: Which circuitry is going to hold the databus content after you pull down the NWE line ? Are the CPLD inputs going to do that ? And does that mean that a board wanting to support this method would need to connect all 8 data lines to the CPLD ?
Can this behaviour of the CPLD be seen somewhere in the Xilinx datasheets ? I fear some µA leakage current could already corrupt the bus content, or ? I would like to get a feeling about this ability to "hold" the bus content.
-
carts would not be dual-usable as both PAL and NTSC because of the different clock rates.I think that magic write idea is quite interesting. If it works reliably, then this could really be something very interesting for future board designs. But I don't understand one thing there. Can you explain please, why a difference of 8 ns for the whole cycle or 4 ns of one half cycle makes it necessary to have different designs for PAL and NTSC ? The 8 ns seem to be not very important, or ? And of course the timers on the VCS board are not so very accurate as well. Do you think they are better than 0.1% ?
Or maybe I didn't get the point ?
-
-
I thought the 64K cartridge was based on the Krok Cart and that it supported extra RAM? Isn't that what Andrew Davie's Boulderdash written for?This is the 3E (64K ROM and 32K RAM) prototype I made in case Andrew gets the license to release notBD on cartridge. I wanted to do all I can to make notBD on cartridge possible. On the other hand, I have currently no plans to mass produce this special board unless Andrew needs it for not BD, also because I will be busy with the next Krokodile run for the next few month ...
The 64K board design that Albert has available is not supporting RAM. It is just the next logical step that comes after F4 to support 64K instead of 32K.
-
For 64K Atari style bankswitching, the hotspots have already been defined. They are $1FE0 - $1FEF. Thats why Paul (or somebody else ?) called it EF Bankswitching. I think Alberts prototypes use the same hotspots, or ?
-
Hello all. I've been writing this 2600 emulator for a while now, and I've been looking at the TIA schematics to resolve som subtle timing issues when writing the TIA registers during the active scanline. I do have some questions regarding certain gate structures in the schematics, the phase of all the clocks in the system, and the write timing of the 6502 to the TIA in general. Is this the appropriate place to ask such things, and if so, is there anyone here who may know these things? I've read many documents on the Web describing the TIA, but unfortunately many seem contradictory, or simply do not have this kind of detail. Thanks.For detailed questions you should contact Adam Wozniak. He is currently working on a 2600 on a FPGA and I guess he knows every little detail. There is also a mailing list, but its quite silent there... I think Adam has TIA VHDL code available that might answer some of your questions if you take a look at it.
-
Where is the waiting list?Should be somewhere on Alberts computer
You need to contact Albert and tell him you want to be on the list. -
Doesn't look like I'll be playing Defender II anytime soon.It is not only F8 switched, but it also uses extra RAM. That makes things even more complicated
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Problem making "A-VCS-tec Challenge" boards
in Homebrew Discussion
Posted