KrzysioCart Micro SD - a revolution for fans of the Pegasus / Famicom console.

In the last e-mail you wrote that you managed to repeat your mistake, I have such a proposal, namely when you want to take your business seriously and in the direction you like (you can see that you like retro) and that your people should take your people seriously so that someone will be more willing to invest in your product, you must show that there is contact and you solve potential problems, and for this purpose, I seriously suggest Mr. what does not work, popular bugs, ideas and proposal, proposed update, Current work progress (until I looked here recently, I had no idea that you are already selling on a new board), the problem is with you, you did a great job for one a guy who took up the challenges on his own, here I can only congratulate you on your self-denial, but there is a terrible problem with the flow of information, how would you embrace such Not closed forum is once that you would not have to answer the same question again, because sooner or later you will find yourself in this forum, you cannot refine anything yourself without the help of others, the more that you do not do these carts for yourself, Mr. Krzysztof you only sell them and it's not cheap.


Edit: Mr. Fashion, this spelling proposal of yours detected all 3 errors, I gave the bodies even though uncle Google did not detect them, I seriously try to write grammatically correctly, but it's difficult when you live abroad for many years, and I tried to do so and I checked the entire post 2 times before.

Edit 2: I've already corrected these 3 bulls.

Moderated By dondu:

In fact, the spell-checking algorithm did not detect such an obvious error as "knockin". I corrected the error, I will report the problem to the admin.

mobor wrote:

Ronin64 wrote:

mobor wrote:

upload the entire NES romset to it

Are these ROMs from emuparadise or Nintendo adding them?

You tried to flash your intellect but it did not work ... And the content on this SD card for this Pegasus is where? From the Nintendo Store?

Nintendo itself once shot itself in the knee in a similar matter, posting "own" games, in some new generation console compilation, publishing them from pirated sources ... let's say what we want, but it looks quite ambiguous. [The funny thing is that it was easier for them to get Roma from outside than their own library]

On the original Nintendo Famicom HVC - 001 + av mod works fine, interestingly, the original Golden Four does not work, the gray image, and Krzysio Cart flies without any problems.

You can stick to the finish, fitting the housing, but sandpaper + cleaning milk and raspberry cartridge almost original P

Added after 1 [hours] 26 [minutes]:

I downloaded a working rom 168 in 1 from http://www.gry-pegasus.xaa.pl/0-9.html

On the Nintendo Entertainment System, the NESE-001 1985 works well, you only need to buy a 60 to 72 pin adapter and a game case.
In the middle of the cartridge housing there is both the adapter and KrzysioCart.
After the appropriate modification, there is even access to the SD card.

I bought two Krzysiocart Micro SD on August 31.

Something happened with one of my flashcarts, the message "SD READ BOOTSEC FAILURE" The SD card with games is 100% functional because I bought 2 and on the second copy the SD card fires up properly.

I replied 5 minutes ago that it is enough to send it, then I will check what it is for free, I do not know for what purpose you write to me in 3 different places - the forum is not a place for this type of private discussions.

I bought two.
It turned out that the RAM bone was lost in one copy.
I wrote a little panic to Krzys, and quickly got an answer.
Sent, fixed, what else do you want? I would highly recommend !!


A small, free homemade 60 pin to 72 pin adapter to play pegasus games on the original NES.
Surprisingly, the original Golden Five and 168 in 1 do not work rom from neta + KrzysioCart everything works.

For the more inquisitive, I will say that for a long time I had the intention of introducing a few modifications to the selector software (i.e. the part of the code responsible for operating the menu and the entire user interface) in KrzysioCarta
* The main reason was to add a save persistence in the case of games that support saving and have a battery in cartridge releases, e.g. Kirby, Final Fantasy),
* I also wanted to make some smaller changes according to the suggestions (e.g. automatic cursor movement when we hold the arrow or in the case when there are a lot of files in the folder - speed up the transition to the next screens),
* and also correct some minor bugs (e.g. in some rare cases, after entering a directory, and then going back to a higher level, from some point on, items may be displayed incorrectly)

Simply adding a battery to the cartridge would not solve the issue of preserving the record:

* First, because the selector also uses this memory for its own purposes and the data saved by the game would be erased.
* And even if you eliminated the use of this memory, after selecting a new game, the save from the previous game would be erased with the new one.
So a different approach was needed.

Of course, I had to start all the work by reviewing and analyzing the code that I hadn't looked at for 1-2 years. Unfortunately, with assembler it is so, that sometimes and after 2 days, looking at a fragment, I wonder not what it is responsible for, but whether I wrote it at all )

The first step was to streamline the testing process. Believe it or not, the work cycle so far has been as follows:


Testing in the emulator was not possible, because the cartridge uses a memory card and also programs an internal flash-rom. However, I said enough and added my mapper definition to the emulator, which emulates both flash-rom (sending programming / deleting commands) and the memory card (sending all necessary SPI commands). Any hard disk image file can be selected as the "content" of the card.

The advantage is not only the speed of testing, but most of all the possibility of debugging - checking which command was sent to the card, which command to the flash-rom. And when "something" is written on the card, but it does not work as expected, you can preview the difference in sectors before and after writing.

-

In order to implement the save game functionality, it was necessary to add a number of functionalities:
* adding the SPI (CMD24) command to write the sector to the memory card,
* adding a file / directory search function for a given name in a given directory to know if, for example, there is already a SAVE file for a game
* modification of the existing function of reading the cluster from the FAT partition, taking into account checking whether we are at the end of the cluster - useful when we want to create a new entry in the directory, and the current entries already fill the entire cluster
* added function to find the first free cluster in a FAT partition
* adding the function of extending the existing FAT chain in the partition with a newly found free one
* adding the function of creating a new entry (file / directory) in a given directory, taking into account the need to create entries with a long name (LFN - Long File Name).
I had quite a headache with the latter, because Windows, despite creating such entries, did not want to take into account the long name, and always displayed the short name (8 + 3). Additionally, testing with CHKDISK found errors. For the uninitiated, I would like to remind you that the content of each directory is stored in the cluster in the form of direntry entries. Each of these entries takes 32 bytes and contains, among others, the following information:
* name (8 + 11 characters), which is what DOS used to display
* starting cluster where file / directory starts
* file size in bytes
* date of creation / modification / last access
* attributes (archival, read-only, system, hidden).
To create something with a longer name, Windows adds dummy entries (called LFN - Long File Name). Each of such entries stores information about 13 characters from the name, so e.g. when creating a file "Ala ma cat.txt", the system will create 3 entries for such a file in this order

So why were there so many problems with it? There are some tricks:
a) the need to correctly calculate the CRC checksum from the short name and place it in each LFN entry
b) The fields in the last LFN entry after the trailing 00 character (marked with an asterisk) must be FF (marked with `).
c) If the name is 26 characters, the system will create two LFN entries (there will be no third entry with only trailing zero and the rest of the FFs)


* need to generate short name from long name. Initially, I wanted these names to follow "good rules", ie the first six letters, a tilde and a number, eg MOJPLI ~ 1. This, however, would entail the necessity to re-search the directory to see if such a name exists, and if it does, then another search to see if there is MOJPLI ~ 2, etc. operations, e.g.

Looking for another idea, I accidentally checked that Windows does not stick to these "good rules" anyway - e.g. when the long name includes regional characters (e.g. "oż"), its DOS name is 0C707 ~ 1 despite the fact that the long name and so is shorter than 8 characters. Then I had the idea that the short name does not have to be related to the new one in any way. All you have to do is make sure that it is unique in a given folder - and it's great to take the hexadecimal cluster number as the name of the starting cluster number - it is just 8 characters long.
Of course, someone seeing something like this could be surprised or laugh a lot, but who uses DOS nowadays? Besides, what's the difference, if it works anyway


The very transfer of the content of WRAM memory to the memory card (and the other way round) is also not easy, because the functions of the memory card and FAT support also use this memory as a temporary one. Therefore, it was necessary to use one of the unused areas of the flash-rom as a temporary storage location:
* When transferring WRAM-> MemoryCard, the program must program the contents of the WRAM memory in the flash-rom, and then gradually save from the flash-rom to the memory card
* At KartaPmem-> WRAM, the program first programs the flash-rom with data read from the card, and then, just before starting the game, it rewrites them from the flash-rom to WRAM.

Finally, just testing whether the WRAM memory content is restored correctly was also troublesome on ready-made games, because it required, for example, passing the first level in Kirby, because only then the player's location was saved.
So I had to write my ROM for the test, which calculates the CRC from the data stored in the WRAM and if the user asks for it - it generates a new memory content:


Tips:
* In FAT16, the root directory is not stored in the cluster, but just after the allocation tables. As a result, the maximum number of entries is limited in advance and this must be taken into account (checked) when creating a new entry
* By the way, I found the cause of the previously described error related to going back to the main directory: the system puts two (invisible to the user, unless using DOS) entries in each folder:. and .., pointing to the current folder and a higher-level folder.
For some reason in FAT32, if .. points to the root folder, then its cluster number in this entry is 0, not 2. As a result, cardij, wanting to list the contents of the folder at a higher level, reads the cluster pointing to ".. "and reads the contents of cluster 0, which is garbage. (which is funny - in FAT16 it worked, because for the sake of simplicity I assumed that in fact the root directory cluster is number 0)
* Finding the first free cluster - in the case of FAT16 partitions, the maximum number of clusters is 2 ^ 16 - 2 i.e. 65534

Fixes (improvements) compared to the previous version:
* the cartridge has a battery that stores the contents of the internal RAM memory when you turn off the console. After restarting, the memory content is automatically transferred to the micro SD card (to the! SAVE directory), and when you select the same game again sometime, the save state is restored. Selecting another one when it DOES NOT CAUSE the loss of the previous write state. The files with the saved state can then be read on the computer and, for example, finish the game on the emulator or the other way round - the game started on the emulator can be finished on a real console.
* adding support for mapper 30 - now it is also possible to play games created with NesMaker - a program facilitating game development or other unofficial titles with a size of 512 kB using mapper No. 2 (e.g. Battle Kid 2),
* displaying subtitles was previously implemented as: 1) disable image generation, 2) display, 3) enable image generation, which caused flashing. Currently it is: 1) wait for vblank 2) view.
* Display the names of buttons "A", "B", "SELECT" as graphics instead of text on the main screen
* Holding down the down / up / right / left button scrolls continuously
* When going to the next page with the list of files, the information from the previous function call is used, thanks to which the screen appears faster
* Unicode characters> 127 (regional) will be displayed as a dash instead of something random.
* wide range of housing colors with a choice of your favorite color



And for die-hard NESmaniaków - soon a version adapted for the NES console:

Hi, I have been writing a pegasus game as a hobby for some time and I bought a new cruciform card with a write option to test whether the game will work on a real console and not only on an emulator The game works fine, but I noticed one thing that I wanted to ask out of curiosity. Namely, when I tested the game on the emulator earlier, I noticed that the values in WRAM are filled with 0x00 by default. So, taking the easy steps, I found that I would be checking if there are any saved game states based on whether the first byte from the address where I am keeping the save is non-zero. After starting the game on the console with krzysiocart it turned out that the game claims that there are already some saved game states, surprised I copied the .sav file to see what it looks like. And it looks like it is written by bytes 0x60 to 0x7F repeated 256 times each.



I don't mind, of course, I've already changed the game code to make it work properly I just wanted to ask, out of curiosity, why is it that the initial values in WRAM when the game is launched for the first time are not different .

The emulator gives the option of choosing how to initialize the RAM at startup (although I don't remember if it only applies to RAM from $ 000- $ 7ff or $ 6000- $ 7fff.


Imagine you have a cartridge with no memory at $ 6000- $ 7fffi, and the game is trying to read the cell value from that address, e.g. $ 6005. What will he see?
Data reading can be performed using various instructions, e.g.
LDA $ 6005
LDA $ 6000, X; X = 5
LDX $ 6005
LDA ($ 02), Y; $ 02 = $ 05, $ 03 = $ 60, Y = 0
However, the common feature of all these instructions is that before the read cycle at $ 6005, the last value on the data bus was the high byte of the $ 6005 address, or $ 60. Why?

For example, for the instruction "LDA $ 6005" the command code is "$ A9 $ 05 $ 60"
The processor executing this command will generate the following read cycles:


Some of the games, for unknown reasons (programmers' error? Deliberate action "obstructing" something) behave in this way - they try to read something from the memory, which in fact is not in this cartridge. This is what, for example, Battle Toads does - and if the value read is different than expected, the game will crash (surprisingly not immediately, but after the first level)

Therefore, each WRAM memory cell in my cartridge is initialized with the value corresponding to its older address byte before starting the game, i.e.
$ 6000 -> $ 60
$ 6001 -> $ 60
...
$ 6100 -> $ 61
This method of initialization is to "pretend" the "open bus" phenomenon, that is, to imitate the behavior if this memory was not there.


If you care about the consistency and correctness of the record, be sure to calculate a checksum of the saved data and also save it in the RAM, and then compare whether it is actually equal to what it should be.

Thanks for the answer, I'll use a checksum. (I should have done this from the beginning, but laziness got the better of me now I have a lesson)

Thanks also for the in-depth explanation, I did not think before what happens when we want to read a value from memory that is not there. It makes sense now.
If I understand correctly, how do we read the value from the address $ 6101 without WRAM like this:

LDX # $ 02
LDA $ 60FF, X

We will load the value of $ 60 into the accumulator, not $ 61? So your solution does not simulate the open bus phenomenon 100%? (yes, I know, I'm picking on, it probably couldn't have been done better: p)

One more question, if we don't have WRAM, how does it work with CMP for example? If we use:

CMP $ 6005

the accumulator will be compared to the value of 0x60 and flags will be issued on this basis?

And as for the Christopher Robin, it's a great job at an affordable price, keep it up!

Quote:

We will load the value of $ 60 into the accumulator, not $ 61? So your solution does not simulate the open bus phenomenon 100%?

Unfortunately, yes, but only the emulator can mimic such things (of course I could turn off RAM for all mappers that do not use RAM by default, but even FCEUX does not).
An interesting issue, because it does not only apply to RAM, but also e.g. unused bits in the joystick port - e.g. some games reading $ 4016 expect a value of # $ 40 or # $ 41 (e.g. Paper Boy)

Quote:

One more question, if we don't have WRAM, how does it work with CMP for example? If we use:

CMP $ 6005

From the outside, the CMP instruction from the LDA is no different - the processor has to perform the same read cycles to get the value from memory, so it will behave the same.

Krzysio, well done, finally an update to this project. Could use some fabulous stickers, a free servie project website for example, which would bring the legend to life, wouldn't it?
I am writing not without reason, maybe you will have a rom update for the version without batteries? - based on free chip memory, in flash memory.

For ripping freaks (of course, with their own original nes ) roms I give my code for self-compilation (I have compiled for debian, if someone can not, I will share) eg in linux - for self-identification of roms supported by KK.

After saving the attachment, e.g. to a file named 'kk.cpp', compile it (under linux - in another system, the code requires changing the forward slashes):


we change the attributes of the compiled file to executable



we copy the kkk file to our rom directory, go to this directory (cd [directory]) and from there we issue the command:



next, the list.txt file will be created, we process it in eg Libre Office, loading the file into Calc (Excel) as .txt with division into columns.
In the workbook, we create a sheet with the list of supported mappers (first topic of this thread) and in the new column of the sheet with the list, we add the formula "countif", which means the supported mappers on our list of files.

Further processing is to create a bash / .bat script, which will copy the selected files to us, move them to the selected folder - the script can be done using Libre / Office.

The code was created on my initiative and I make it available (without any benefits in connection with the KK project) on an open source basis, if you want to extend it, let me know, it will be nice. I helped? leave a trail, thx.

I see that KrzysioCart is still being sold. Therefore, I have a question - what is the issue of PCB thickness at the moment? The original version (i.e. the one made by hand) was a bit thicker than the connector in Pegazus. Has it been corrected?

It was certainly not thicker, the first version (on a home-made PCB) was also 1.2mm thick.
Then there was another version from the factory, in HASL technology
And now (and it has been for a long time) it is a version with gold-plated contacts (ENIG).

In total, there were probably about 8 different versions of the tiles, differing in minor details.
All versions were 1.2mm thick, I always took care of that because I know that thicker plates push the contacts apart.

phanick wrote:

All versions were 1.2mm thick, I always took care of that because I know that thicker plates push the contacts apart.

I know you said that and I believe you meant well, but I have a home-made KrzysioCarta plate myself and I know that it cracked the contacts in my Chinese Famicon with Aliexpress. That's why I don't take KrzysioCart out of it anymore. It is possible that it is not a matter of PCB, but a thick layer of tin, so this problem may not be present on the new KrzysioCarts.

Anyway, I wanted to make sure.

Are there plans for more mappers?

It is not possible, I have never tinned the contacts in any cartridge. The first versions were made in housings that held the slot quite tightly, so if the cartridge is difficult to insert / remove from the slot, that may be the reason.
If the cartridge has been sitting in the console non-stop for several years, the contacts may change their shape (memory effect), but also a lot depends on the quality of the socket.

In this version of the cartridge (with once programmed logic) it is not possible to fit more mappers, but currently working on a different version in which the FPGA (different) will be reprogrammed after each game load and then the number of supported mappers will not be limited.